India’s Digital Personal Data Protection Act, 2023 (DPDP Act) has introduced a new vocabulary for how organisations collect, use, store, share and protect personal data.

Terms such as Data Principal, Data Fiduciary, Consent Manager, Significant Data Fiduciary, specified purpose, personal data breach and processing now have specific meanings within India’s privacy framework.

At the same time, organisations implementing DPDP compliance frequently encounter operational terms such as Consent Management Platform (CMP), Data Discovery, Data Mapping, RoPA, Data Principal Rights Management, Privacy Impact Assessment, consent artefact, purpose limitation and data lineage.

Not all of these terms are expressly defined in the DPDP Act. Some come directly from the legislation and Rules, while others are commonly used privacy, security and technology concepts.

This DPDP vocabulary guide brings these concepts together.

1. Data

Legal concept: Data broadly refers to a representation of information, facts, concepts, opinions or instructions that can be communicated, interpreted or processed by humans or automated systems.

Data is the broadest concept. Not every piece of data is necessarily personal data.

Example: A company’s product catalogue contains data, but an individual customer’s name and mobile number constitute personal data when they identify or relate to that individual.

2. Personal Data

Personal Data is data about an individual who is identifiable by or in relation to that data.

Examples can include:

• Name
• Mobile number
• Email address
• Customer ID linked to an individual
• Employee ID
• Account information
• Location information where it identifies an individual
• IP/device information where it identifies or relates to an identifiable individual
• Transaction information associated with an identifiable person

Whether a particular field constitutes personal data depends heavily on context and its ability to identify or relate to an individual.

3. Digital Personal Data

Digital Personal Data means personal data in digital form.

The DPDP framework applies to digital personal data, including personal data initially collected in non-digital form and subsequently digitised where the statutory scope requirements are met.

Examples include customer records in a CRM, employee information in an HRMS, patient records stored electronically and customer information maintained in databases.

4. Data Principal

The Data Principal is the individual to whom the personal data relates.

In simple terms:

Data Principal = the person whose data is being processed.

Depending on the business, this could include a:

• Customer
• Employee
• Patient
• Student
• Borrower
• Insurance policyholder
• Website visitor
• Mobile application user

For a child, the definition also includes the parent or lawful guardian. In specified circumstances involving a person with disability, it includes the lawful guardian acting on that person’s behalf.

5. Data Fiduciary

A Data Fiduciary is a person that, alone or together with others, determines the purpose and means of processing personal data.

In practical terms, it is usually the organisation deciding:

Why do we need this personal data, and how will we process it?

A bank processing customer information for account management, for example, would ordinarily act as a Data Fiduciary for that activity.

6. Data Processor

A Data Processor processes personal data on behalf of a Data Fiduciary.

Examples may include:

• Cloud infrastructure providers
• SaaS providers
• Outsourced processing vendors
• Communication service providers
• Managed technology providers

The distinction between a Data Fiduciary and Data Processor depends on the role played in a particular processing activity rather than merely the company’s label.

7. Significant Data Fiduciary (SDF)

A Significant Data Fiduciary is a Data Fiduciary or class of Data Fiduciaries notified by the Central Government under the DPDP Act.

The Government may consider relevant factors prescribed by the legislation when making this determination.

SDFs are subject to additional obligations, including requirements relating to a Data Protection Officer, independent data auditor and periodic assessments/audits as applicable under the framework.

Therefore:

Every SDF is a Data Fiduciary, but every Data Fiduciary is not necessarily an SDF.

8. Data Protection Officer (DPO)

Under the DPDP Act, a Data Protection Officer is the individual appointed by a Significant Data Fiduciary in accordance with the Act.

A DPO can play an important role in privacy governance, including facilitating communication around personal-data processing and supporting organisational compliance structures.

Organisations that are not designated SDFs may still assign privacy responsibilities internally, but this should not be confused with the statutory definition applicable to SDFs.

9. Processing

Processing covers a broad range of wholly or partly automated operations performed on digital personal data.

It can include activities such as:

Collection → Recording → Organisation → Storage → Retrieval → Use → Combination → Sharing → Disclosure → Restriction → Erasure → Destruction

A common misconception is that privacy compliance applies mainly when information is initially collected.

In reality, the complete data lifecycle matters.

10. Specified Purpose

A specified purpose is the purpose mentioned in the notice provided by the Data Fiduciary to the Data Principal in accordance with the DPDP framework.

This makes purpose an important architectural concept for privacy systems.

Instead of simply recording:

Customer consented.

an organisation may need to understand:

What did the customer consent to?

This is why enterprise consent architectures frequently map:

Data Principal → Purpose → Personal Data → Consent → Processing Activity → System

CONSENT VOCABULARY

11. Consent

Consent is one of the central concepts of the DPDP framework.

Where consent forms the basis for processing, it should represent a clear affirmative action and meet the requirements prescribed by the law.

An enterprise therefore needs to look beyond merely placing a checkbox on a form.

It needs to understand the complete consent lifecycle.

12. Free Consent

Consent should represent a genuine choice by the Data Principal.

Organisations should therefore examine whether unnecessary personal-data permissions are being bundled into access to a product or service.

13. Specific Consent

Consent should relate to a specified purpose.

A broad statement such as:

“I agree that my data may be used for any business purpose.”

does not represent a good purpose-specific consent architecture.

A stronger architecture separates purposes—for example, processing required to provide a requested service versus optional promotional communications.

14. Informed Consent

The individual should receive the information necessary to understand the processing for which consent is requested.

This is closely connected with the organisation’s privacy notice and consent notice architecture.

15. Unconditional Consent

Consent under the DPDP framework must satisfy the statutory characteristics, including being unconditional.

Businesses should therefore carefully evaluate consent journeys containing artificial conditions unrelated to the underlying service or processing purpose.

16. Unambiguous Consent

Consent should clearly indicate what the individual has agreed to.

Ambiguous interface designs and vague language can create compliance and evidentiary problems.

17. Clear Affirmative Action

Where consent is relied upon, the organisation should capture an affirmative action demonstrating the Data Principal’s agreement.

Examples may include appropriately designed:

• Consent buttons
• Checkboxes
• Application controls
• Digital consent workflows

The exact implementation should reflect the processing context.

18. Withdrawal of Consent

A Data Principal may withdraw consent.

Importantly, withdrawing consent should be comparable in ease to giving consent, subject to the statutory framework.

Enterprise systems therefore need to think beyond consent capture and implement:

Give → Record → Review → Modify/Manage → Withdraw → Propagate

Withdrawal also needs to reach downstream processing systems where required.

19. Consent Manager

A Consent Manager has a specific statutory meaning under the DPDP Act.

It refers to a person registered with the Data Protection Board that acts as a single point of contact enabling Data Principals to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform.

A critical terminology distinction is therefore:

Consent Manager ≠ Consent Management Platform.

A company may provide consent-management technology without necessarily being a registered statutory Consent Manager.

20. Consent Management Platform (CMP)

A Consent Management Platform or CMP is an industry/technology term rather than a separately defined statutory term under Section 2 of the DPDP Act.

A CMP generally provides technology for organisations to manage consent across digital and enterprise environments.

Enterprise CMP capabilities can include:

• Consent collection
• Purpose management
• Consent records
• Withdrawal
• Preference management
• Version management
• API-based consent validation
• Audit trails
• Website/mobile integration
• CRM integration
• Communication-channel preferences
• Reporting and dashboards

A CMP essentially converts consent requirements into an operational technology layer.

21. Consent Artefact / Consent Record

A consent artefact is an implementation concept describing the structured evidence associated with a consent transaction.

Depending on the architecture, it may record:

• Data Principal identifier
• Purpose
• Consent status
• Timestamp
• Notice/version
• Collection source
• Channel
• Language
• Withdrawal status
• Relevant data categories

This becomes particularly important when an organisation needs to demonstrate the history of consent.

22. Consent Lifecycle

The Consent Lifecycle describes the journey of consent over time.

For example:

Request → Capture → Store → Validate → Use → Update → Review → Withdraw → Retain Evidence

Consent should therefore not be treated as a one-time UI event.

23. Purpose-Based Consent

Purpose-based consent links consent to the particular purpose for which personal data will be processed.

For example:

Purpose A: Process a loan application
Purpose B: Send promotional offers
Purpose C: Share information with a specified ecosystem participant where applicable

These purposes should not automatically be treated as one undifferentiated permission.

24. Granular Consent

Granularity refers to separating different processing choices where appropriate rather than bundling unrelated purposes together.

Granularity can exist at several levels:

Purpose × Channel × Data Category × Business Entity × Processing Activity

The appropriate level depends on the organisation’s processing architecture and legal requirements.

25. Consent Validation

Consent validation means checking whether an appropriate consent or other valid processing basis exists before performing a particular processing action.

An enterprise system might effectively ask:

Is there an active permission for this Data Principal, purpose and processing activity?

This is an important bridge between privacy records and operational systems.

26. Retrospective / Legacy Consent

“Retrospective consent” is commonly used as an implementation term for dealing with personal data already held by an organisation when new consent requirements or consent-management systems are introduced.

It is not a separately defined statutory term under Section 2.

Organisations should assess legacy datasets based on the applicable legal requirements rather than assuming that every historic record automatically requires a new consent request.

DATA GOVERNANCE VOCABULARY

27. Data Discovery

Data Discovery is the process of identifying where personal data exists across an organisation’s technology environment.

It can involve scanning:

• Databases
• Data warehouses
• File systems
• SaaS platforms
• CRM
• ERP
• Cloud storage
• Applications

The objective is simple:

Know what personal data you have and where it resides.

28. Data Classification

Data Classification categorises discovered information according to its characteristics and organisational policies.

For privacy purposes, this can include identifying personal-data elements such as contact information, financial information, identifiers and other relevant categories.

Classification policies should be mapped carefully to the terminology actually used by the applicable law.

29. Data Mapping

Data Mapping identifies how personal data travels through the organisation.

For example:

Website → CRM → Loan Processing System → Analytics → Communication Platform → Archive

Without mapping these flows, consent withdrawal, erasure and incident response can become difficult to operationalise.

30. Data Lineage

Data Lineage provides deeper visibility into where data originated, how it moved, what transformations occurred and where it ultimately resides.

Think of it as the family tree of a data element.

31. Data Inventory

A Data Inventory is an organised catalogue of data assets and processing information maintained by an organisation.

It may capture information such as:

• System
• Data category
• Purpose
• Owner
• Storage location
• Retention
• Recipients
• Security controls

32. RoPA — Record of Processing Activities

RoPA stands for Record of Processing Activities.

The term is widely used in global privacy governance, particularly in GDPR-oriented privacy programmes. It should not be represented as a separately defined statutory DPDP Act term.

Nevertheless, many organisations use a RoPA-style inventory operationally to understand processing activities and maintain privacy governance.

33. Purpose Limitation

Purpose limitation means personal data should be processed in accordance with the legitimate and specified context for which it is being processed.

Operationally, organisations should be able to connect processing to clearly understood business purposes.

34. Data Minimisation

Data minimisation is the principle of collecting and processing only the personal data reasonably required for the relevant purpose.

A useful design question is:

“Do we actually need this field?”

rather than:

“Can we collect it?”

35. Data Accuracy

Where personal data is used for decisions affecting an individual or disclosed to another Data Fiduciary, the DPDP framework creates important obligations concerning completeness, accuracy and consistency.

Data quality is therefore also a privacy issue.

36. Storage Limitation / Retention

Personal data should not simply remain indefinitely because storage is inexpensive.

Organisations need defined retention and erasure processes aligned with the applicable legal and business requirements.

A mature lifecycle looks like:

Collect → Use → Retain → Review → Erase/Anonymise where appropriate

37. Data Retention Policy

A Data Retention Policy defines how long different categories of information should remain within organisational systems and when deletion, archival or another disposition action should occur.

Retention periods may differ because other laws can independently require certain records to be maintained.

DATA PRINCIPAL RIGHTS

38. Data Principal Rights

The DPDP Act provides Data Principals with important rights and mechanisms.

These include rights relating to:

• Accessing information about personal data
• Correction
• Completion
• Updating
• Erasure
• Grievance redressal
• Nomination

These rights need operational workflows, not merely policy statements.

39. Data Principal Rights Management (DPRM)

DPRM is an implementation/technology term for systems used to receive, verify, route, fulfil and document Data Principal requests.

A typical workflow may be:

Request → Identity Verification → Classification → System Search → Approval → Fulfilment → Response → Audit Record

40. Right to Access Information

The DPDP framework gives Data Principals the ability, subject to applicable requirements, to obtain information concerning the processing of their personal data.

This creates an operational requirement for organisations to know where personal data resides and how it is being processed.

41. Correction and Updating

Individuals can seek correction of inaccurate or misleading personal data and completion/updating as provided under the Act.

Organisations therefore need processes capable of propagating legitimate corrections across relevant systems.

42. Erasure

A Data Principal may request erasure in accordance with the Act.

However:

Erasure does not always mean immediate deletion of every record.

An organisation may need to retain certain information where another law requires or authorises retention.

43. Grievance Redressal

Data Fiduciaries are required to establish an effective mechanism through which Data Principals can raise grievances.

This means organisations need more than a privacy-policy email address; they need an operational mechanism capable of receiving, tracking and resolving relevant grievances.

44. Nomination

The DPDP Act provides a right to nominate another individual who may exercise the Data Principal’s rights in the event of death or incapacity, subject to the framework.

This is a distinctive feature of India’s privacy law.

CHILDREN’S DATA

45. Child

For purposes of the DPDP Act, a child means an individual who has not completed eighteen years of age, subject to the statutory framework and applicable exemptions/notifications.

Organisations serving young users therefore need to pay particular attention to age-related processing requirements.

46. Verifiable Consent

The final DPDP Rules use the concept of verifiable consent in relation to specified processing involving children and persons with disability who have lawful guardians.

The implementation objective is to establish the relevant adult/guardian relationship and consent in accordance with the Rules.

47. Parental Consent

Where applicable, a Data Fiduciary must obtain the required verifiable consent of the parent before processing a child’s personal data, subject to exceptions and conditions under the framework.

This can require dedicated identity and consent workflows.

48. Tracking and Behavioural Monitoring of Children

The Act places restrictions on tracking or behavioural monitoring of children and targeted advertising directed at children, subject to the exemptions and conditions provided under the legal framework.

This has significant implications for EdTech, gaming, media and consumer applications.

SECURITY & BREACH VOCABULARY

49. Personal Data Breach

A personal data breach broadly involves unauthorised processing or accidental disclosure, acquisition, sharing, use, alteration, destruction or loss of access that compromises the confidentiality, integrity or availability of personal data.

A breach therefore does not mean only “someone stole the database.”

It can also involve inappropriate disclosure, alteration, destruction or loss of availability.

50. Reasonable Security Safeguards

Data Fiduciaries are required to protect personal data under their control through reasonable security safeguards to prevent personal data breaches.

Privacy and cybersecurity therefore intersect directly.

51. Breach Notification

Where a personal data breach occurs, notification obligations can arise toward the Data Protection Board of India and affected Data Principals, in accordance with the Act and Rules.

Organisations consequently need incident-management processes connecting:

Detection → Assessment → Containment → Investigation → Notification → Remediation → Evidence

52. Data Protection Board of India

The Data Protection Board of India is the statutory Board established under the DPDP framework.

It performs functions assigned under the Act, including dealing with matters such as personal data breaches, complaints and statutory proceedings.

53. Appellate Tribunal

The DPDP Act defines the Appellate Tribunal by reference to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT).

It forms part of the appeal mechanism under the statutory framework.

ENTERPRISE PRIVACY TERMINOLOGY

The following concepts are useful in implementing a privacy programme but should not automatically be presented as terms expressly defined by the DPDP Act.

54. Privacy by Design

Privacy by Design means incorporating privacy considerations into systems and processes during design rather than adding privacy controls only after implementation.

For example, when developing a customer onboarding application, the team considers consent, minimisation, retention, access controls and rights workflows during architecture itself.

55. Privacy Impact Assessment (PIA)

A PIA is an organisational assessment used to identify privacy implications associated with a new system, process, product or data use.

It can help answer:

• What personal data are we collecting?
• Why?
• Where will it go?
• Who can access it?
• What risks arise?
• What controls are necessary?

56. Data Protection Impact Assessment (DPIA)

A DPIA is a structured privacy-risk assessment commonly used internationally.

Under India’s framework, Significant Data Fiduciaries have additional assessment obligations as prescribed. Organisations should distinguish the exact statutory requirement from terminology imported from other privacy regimes.

57. Third-Party Risk Management (TPRM)

TPRM evaluates privacy, security and operational risks created by vendors and other third parties.

A privacy-focused vendor inventory may record:

Vendor → Service → Data → Purpose → Processing Role → Location → Contract → Security Controls → Risk

58. Privacy Notice

A Privacy Notice communicates information regarding the organisation’s processing of personal data.

It is broader than a consent button.

A mature privacy architecture distinguishes between:

Privacy Notice ≠ Consent Request ≠ Consent Record

Each serves a different function.

59. Consent Notice

A Consent Notice provides the relevant information associated with a particular consent request so that the Data Principal can understand what permission is being sought.

For enterprise systems, notice versioning is important because organisations may need evidence of what information was presented when consent was obtained.

60. Preference Management

Preference Management allows individuals to control choices such as communication channels and other configurable interactions.

For example:

Email: Yes
SMS: No
WhatsApp: Yes
Push Notification: No

However, a marketing preference is not automatically the same thing as legal consent. The organisation must map preferences to the applicable processing context and legal requirements.

61. Cookie Consent

Cookie Consent refers to the management of permissions or controls associated with cookies and similar tracking technologies.

Organisations should avoid assuming that every global GDPR cookie-banner practice automatically translates into a statutory DPDP requirement. Cookie implementation in India may involve the DPDP framework together with other applicable laws and technology considerations.

62. Consent Repository

A Consent Repository is a centralised system used to maintain consent records.

It can act as a privacy control layer between customer-facing channels and downstream systems.

For example:

Website / Mobile App / Branch / CRM

↓

Consent Repository

↓

ERP / Marketing / Analytics / Customer Service / Data Platforms

63. Consent Orchestration

Consent Orchestration means coordinating consent states across multiple applications and processing environments.

If a customer withdraws a particular permission on a mobile application, the updated status may need to propagate to CRM, campaign platforms and other relevant downstream systems.

64. Immutable Audit Trail

An immutable or tamper-resistant audit trail helps preserve evidence of privacy-related events.

It may record:

Who → What → Purpose → Action → Time → Source → Version → Status

This is primarily an implementation and evidence-management concept rather than a separately defined DPDP statutory term.

65. API-Based Consent Enforcement

In sophisticated enterprise architectures, operational systems can query a consent service before performing certain processing.

Conceptually:

Application → Consent API → Permission Check → Allow / Deny / Further Evaluation

This turns privacy from a static documentation exercise into an operational control.

A SIMPLE DPDP DATA LIFECYCLE

An organisation can understand most of the vocabulary through one lifecycle:

Discover Personal Data

↓

Classify the Data

↓

Identify the Data Principal

↓

Define the Specified Purpose

↓

Determine the Applicable Processing Basis

↓

Provide Required Notice

↓

Capture Consent Where Required

↓

Create Evidence / Consent Record

↓

Process Personal Data

↓

Apply Security Safeguards

↓

Manage Data Principal Requests

↓

Manage Consent Withdrawal

↓

Apply Retention Requirements

↓

Erase Personal Data Where Required

↓

Maintain Appropriate Compliance Evidence

This is the practical bridge between the DPDP Act as legislation and DPDP compliance as an enterprise operating model.

DPDP Vocabulary at a Glance

Term	Simple Meaning	Category
Data Principal	Individual whose personal data is involved	DPDP Act
Data Fiduciary	Determines why/how personal data is processed	DPDP Act
Data Processor	Processes data for a Data Fiduciary	DPDP Act
Consent Manager	Board-registered consent intermediary	DPDP Act
Significant Data Fiduciary	Government-notified category of Data Fiduciary	DPDP Act
Personal Data	Data about an identifiable individual	DPDP Act
Digital Personal Data	Personal data in digital form	DPDP Act
Processing	Operations performed on digital personal data	DPDP Act
Specified Purpose	Purpose stated in the required notice	DPDP Act
Personal Data Breach	Compromise involving personal data	DPDP Act
Consent	Permission satisfying statutory requirements	DPDP Act
CMP	Technology for managing consent	Industry term
Consent Artefact	Evidence/record of consent	Implementation term
Data Discovery	Finding personal data across systems	Technology term
Data Mapping	Mapping movement/use of personal data	Privacy practice
Data Lineage	Tracking origin and movement of data	Data governance
RoPA	Inventory of processing activities	Privacy practice
DPRM	Technology/workflow for rights requests	Industry term
PIA	Privacy-risk assessment	Privacy practice
DPIA	Structured data-protection impact assessment	Privacy practice
TPRM	Third-party risk management	Risk practice
Consent Orchestration	Synchronising consent across systems	Technology term
Consent Repository	Central consent-record store	Technology term
Privacy by Design	Building privacy into systems/processes	Privacy principle
Data Minimisation	Limiting data to what is necessary	Privacy principle
Purpose Limitation	Connecting processing to defined purposes	Privacy principle
Retention	Controlling how long data is kept	Data governance

The Most Important Distinction

The biggest mistake organisations can make when building their DPDP vocabulary is mixing legal terminology with technology terminology.

The DPDP Act tells organisations what legal obligations and concepts apply.

Privacy governance translates those requirements into policies and processes.

Technology then operationalises them through capabilities such as:

Consent Management + Data Discovery + Data Mapping + Rights Management + Data Governance + Security + Auditability

Understanding this distinction helps organisations avoid both extremes: treating DPDP compliance as merely a legal-documentation exercise, or assuming that installing a consent banner or privacy tool automatically makes the organisation compliant.

Ultimately, DPDP compliance is an operating model connecting people, processes, personal data, purposes, technology and accountability.