Introduction: Words Matter in Law
When GDPR introduced "Data Subject" in 2018, it reflected a specific legal and philosophical vision. When DPDPA introduced "Data Principal" in 2023, it signaled a deliberate departure from European frameworks. This wasn't a translation choice or regulatory preference—it was a fundamental statement about how India views the relationship between individuals and their data.
Understanding the terminology framework of DPDPA is essential not only for compliance but for grasping the Act's core philosophy. This guide provides a comprehensive glossary mapping DPDPA terminology to GDPR equivalents, explains practical implications, and explores the philosophical reasoning behind these crucial definitions.
Core Terminology Framework: DPDPA vs GDPR Mapping
| Concept | DPDPA Term | GDPR Term | Practical Difference | Implications |
|---|---|---|---|---|
| Individual | Data Principal | Data Subject | Principal = person in control; Subject = person affected by rules | Data principals have greater agency and decision-making authority |
| Organization Processing Data | Data Fiduciary | Data Controller | Fiduciary = legal trust relationship; Controller = technical decision-maker | Fiduciaries owe fiduciary duties (loyalty, care) beyond legal minimum |
| Organization Assisting with Processing | Data Processor | Data Processor | Same term; responsibilities slightly different under DPDPA | Processor liability more sharply limited under DPDPA vs GDPR |
| Information About Individual | Personal Data | Personal Data | DPDPA definition is narrower and more explicit | Excludes anonymized and aggregated data more clearly |
| Sensitive Information | Sensitive Personal Data | Special Categories of Data | Different categorization of sensitive information | DPDPA categories include financial data; GDPR includes political affiliation |
| Highest Risk Information | Critical Personal Data | No direct equivalent | DPDPA introduces unique category | Critical data cannot be transferred outside India even with consent |
| Regulatory Agency | Data Protection Board | Data Protection Authority | Independent board vs. independent authority (subtle) | Different complaint procedures and enforcement mechanisms |
| Processing for Organization's Benefit | Legitimate Interests | Legitimate Interests | DPDPA does NOT provide legitimate interests as standalone legal basis | Under DPDPA, most processing requires explicit consent |
| Request by Individual | Data Principal Rights | Data Subject Rights | Rights are broader and framed more actively under DPDPA | Individuals have more control and fewer exceptions apply |
Detailed Glossary: DPDPA Terminology Explained
1. DATA PRINCIPAL
DPDPA Definition (Section 2(c)): "Any natural person whose personal data is processed."
Key Characteristics:
- Must be a natural person (not corporate entities or government bodies)
- Applies to living persons only (deceased persons' data not covered)
- Applies to Indian nationals and foreign nationals whose data is processed in India
- No age minimum specified (unlike GDPR's 16-year consent age)
Why "Principal" and Not "Subject"?
- Principal = Agency: A principal is someone who exercises control and judgment. In contract law, a principal hires an agent to act on their behalf. This terminology implies the data principal is the "owner" of their data and the fiduciary is their agent.
- Subject = Passivity: Subject implies someone subjected to rules or authority. The framers deliberately rejected this framing.
- Constitutional Alignment: India's Constitution emphasizes individual dignity and fundamental rights. "Principal" aligns with this; "Subject" echoes colonial terminology India deliberately moved away from.
Practical Implications:
- Data principals have more active rights (not just reactive protections)
- The relationship is framed as a mandate/agency relationship, not a regulatory one
- Fiduciaries must view principals as having authority over their data, not as subjects of data policy
2. DATA FIDUCIARY
DPDPA Definition (Section 2(e)): "Any natural person, corporate body or any other entity, whether incorporated or not, as specified in regulations, which alone or jointly with others determines the purposes and means of processing of personal data."
Comparison with GDPR "Data Controller":
| Aspect | Data Fiduciary (DPDPA) | Data Controller (GDPR) |
|---|---|---|
| Legal Framework | Trust law; fiduciary duties apply | Administrative law; compliance duties apply |
| Standard of Care | Highest duty of care; similar to trustee obligations | Reasonable care; balances interests against rights |
| Scope of Responsibility | Absolute responsibility for all processing (including processors) | Responsible for determining means; processors have shared responsibility |
| Liability Model | Primary liability; virtually no exceptions | Primary liability; exceptions for processor's independent decisions |
| Duty Beyond Compliance | Affirmative duty to act in principal's best interest | Duty to comply with law; no affirmative duty to maximize individual benefit |
What "Fiduciary" Means in Indian Law:
A fiduciary is someone who holds a position of trust and is bound by law to act in the best interests of the principal. Examples include trustees, guardians, and lawyers. Key fiduciary duties:
- Duty of Care: Must exercise reasonable care, skill, and diligence
- Duty of Loyalty: Cannot use the relationship for personal benefit at the principal's expense
- Duty of Transparency: Must disclose all relevant information fully
- Duty to Account: Must maintain records and be able to justify all decisions
Application to Data Fiduciaries:
- Must process data only for stated purposes (loyalty)
- Must implement security proportional to data sensitivity (care)
- Must provide clear privacy notices and consent forms (transparency)
- Must maintain audit logs and be able to justify processing decisions (accountability)
3. DATA PROCESSOR
DPDPA Definition (Section 2(g)): "Any person, including a data fiduciary, who processes personal data on behalf of a data fiduciary."
Key Distinction from GDPR:
- Scope of Liability: DPDPA limits processor liability to failure to implement fiduciary instructions. Processor is NOT liable for the fiduciary's decision to process data.
- Sub-processor Rules: DPDPA restricts sub-processing more strictly than GDPR. Unilateral sub-processor engagement is prohibited.
- Breach Notification: Processor must notify fiduciary within 24 hours; fiduciary then has 48 hours to notify DPB within 72-hour window.
4. SENSITIVE PERSONAL DATA
DPDPA Definition (Section 2(o)): Personal data relating to:
- Medical or health condition
- Sexual behavior or sexual orientation
- Genetic data
- Biometric data for identification
- Caste, religion, political beliefs
- Financial data
- Any data involving children
Comparison with GDPR Special Categories:
| DPDPA Sensitive Data | GDPR Special Categories | Status |
|---|---|---|
| Medical/health condition | Health data | Match |
| Sexual behavior/orientation | Biometric, data concerning sex life | Partially overlaps |
| Genetic data | Genetic data | Match |
| Biometric for identification | Biometric data | More narrowly defined in DPDPA |
| Caste, religion, political beliefs | Race, ethnic origin, political opinion, religion | Partially overlaps; DPDPA adds caste |
| Financial data | NOT a special category | DPDPA more protective |
| Children's data | NOT a special category but has consent requirements | DPDPA treats as sensitive |
Practical Implication: Financial data receives higher protection under DPDPA than under GDPR. Fintech companies must implement additional safeguards for payment card details and account numbers under DPDPA than they might require under GDPR alone.
5. CRITICAL PERSONAL DATA
DPDPA Definition (Section 2(d)): Personal data as specified in regulations that cannot be transferred outside India or processed outside India.
Current Regulatory Specification (DPDP Rules, 2025): Critical personal data includes:
- Indian financial account numbers and transaction data
- Government ID numbers (Aadhaar, PAN, Passport)
- Health and medical records
- Biometric data (fingerprints, facial recognition, iris scans)
- Critical infrastructure employee data
No GDPR Equivalent: GDPR doesn't have a "no transfer" data category. Even GDPR's special categories can be transferred with proper safeguards. DPDPA's critical personal data framework is unique to India.
Strategic Implication: If your organization provides cloud backup or disaster recovery services, you cannot use a global infrastructure for Indian critical personal data. You must maintain India-only datacenters for this information.
6. DATA PROTECTION BOARD (DPB)
DPDPA Definition (Section 17-35): Independent board appointed by central government with powers to investigate complaints, direct remedial action, and impose penalties.
Comparison with GDPR Data Protection Authorities:
- Appointment: DPDPA board appointed by government; GDPR authorities are member-state independent
- Appeal Mechanism: DPDPA board decisions appealable to Supreme Court; GDPR appeals to national courts
- Enforcement Powers: DPDPA board can order deletion, levy fines, and refer for criminal prosecution; GDPR authorities can only fine and recommend prosecution
- Complaint Process: DPDPA board directly hears complaints; GDPR authorities investigate and issue decisions
DPDPA-GDPR Terminology Mapping Table (Complete)
| Concept | DPDPA | GDPR | CCPA |
|---|---|---|---|
| Individual | Data Principal | Data Subject | Consumer |
| Organization Determining Processing | Data Fiduciary | Data Controller | Business |
| Third Party Processing | Data Processor | Data Processor | Service Provider |
| Information Type 1 | Personal Data | Personal Data | Personal Information |
| Information Type 2 | Sensitive Personal Data | Special Categories | Sensitive Personal Information |
| Information Type 3 | Critical Personal Data | N/A | N/A |
| Regulatory Body | Data Protection Board | Data Protection Authority | Attorney General |
| Right to Information | Right to confirmation of processing | Right to access | Right to know |
| Right to Rectification | Right to correction | Right to rectification | Right to correction |
| Right to Removal | Right to deletion | Right to erasure | Right to deletion |
| Right to Portability | Right to data portability | Right to portability | Right to portability |
| Right to Opt-Out | Right to withdraw consent | Right to object | Right to opt-out |
Visual Mapping: DPDPA Framework vs GDPR
DPDPA Processing Flow:
Data Principal → Data Fiduciary ← Data Processor
(Provides personal data) | (Trust relationship) | (Acts on instructions)
↓
Right to Confirmation, Correction, Deletion, Portability, Withdrawal
↓
Data Protection Board (Complaint/Investigation) → Remedial Action
Key Distinction: The fiduciary relationship is between Principal and Fiduciary directly. Processor is subordinate to Fiduciary, not independent.
Practical Implications of Terminology Differences
1. Consent Form Wording
GDPR Approach:
"Your data is a valuable asset. Please choose to share your data with us for marketing."
DPDPA Approach:
"As your fiduciary, we seek your permission to use your data for marketing. You remain in control. You can withdraw this permission anytime."
Why the Difference? DPDPA terminology emphasizes the principal's continued authority and the fiduciary's subordinate role.
2. Privacy Notice Structure
GDPR: "We will process your data based on the following legal bases: [legitimate interests, contract, consent, etc.]"
DPDPA: "As your fiduciary, we will only process your data with your explicit permission. Here's what we need permission for: [specific purposes]."
3. Data Subject/Principal Request Handling
GDPR Approach: Provide access, consider legitimate interest, balance rights and freedoms
DPDPA Approach: Comply with principal's request; treat as instruction from the authority you serve
4. Internal Accountability
GDPR: Document your compliance decisions; justify legitimate interests through impact assessments
DPDPA: Document your fiduciary duty performance; justify why you followed principal's interests, not your own
Philosophy: Trust-Based Data Protection vs Rights-Based Protection
The Deep Meaning Behind "Fiduciary" vs "Controller"
The terminology choice reflects fundamentally different legal philosophies:
GDPR's Rights-Based Approach:
GDPR treats data protection as a matter of individual rights. The framing is: "Individuals have rights to their data; organizations must respect those rights." This is grounded in human rights law—privacy is a fundamental right enumerated in the European Charter of Fundamental Rights.
In this framework:
- The individual must assert their rights (right to access, right to object, etc.)
- Organizations can process data unless there's a specific right violation
- The default is: organizations can do what they want unless prohibited
DPDPA's Fiduciary Approach:
DPDPA treats data protection as a matter of trust relationships. The framing is: "Organizations are trustees of individuals' data; they must act in the individual's interest." This is grounded in trust law—the fiduciary relationship, where one party's duty is to serve another's interests above all.
In this framework:
- The organization must act in the principal's interest proactively
- Organizations can only process data for stated purposes with explicit permission
- The default is: organizations cannot process data unless authorized
Why This Matters:
The fiduciary framework is actually more protective because:
- Affirmative Duty: A fiduciary doesn't wait for the principal to complain; they act in the principal's interest. An organization can't hide behind "I wasn't violating rights; no one objected."
- No Balancing of Interests: Under GDPR, an organization can process data based on legitimate interests even without consent if they "balance" interests. A fiduciary cannot do this—the principal's interests come first, always.
- Transparency Requirement: A fiduciary must fully disclose all dealings with the principal's assets. A controller need only provide legally-required disclosures.
- Ongoing Duty: Fiduciary duties don't end once you've processed data. You must continue to act in the principal's interest during the entire retention period. A controller's duties are tied to specific processing activities.
Conceptual Implication: DPDPA's use of "Principal" and "Fiduciary" terminology signals that India views data protection as part of a broader trust relationship between individuals and organizations. This is more akin to a guardian-ward relationship than a provider-customer relationship.
Practical Checklist: Aligning Terminology in Your Organization
Internal Alignment Checklist:
- Documentation Review
- ☐ Update privacy policy to use "Data Principal" instead of "Data Subject"
- ☐ Update consent forms to use "Data Principal" and "Data Fiduciary" terminology
- ☐ Revise DPA language to emphasize fiduciary relationship
- ☐ Update employee training materials with correct terminology
- Organizational Culture
- ☐ Train privacy team on fiduciary duty implications
- ☐ Align decision-making with "What's in the principal's interest?" framework
- ☐ Review legacy processes that assumed "legitimate interests" basis (no longer available)
- ☐ Empower data principals through clear opt-out and withdrawal mechanisms
- System Configuration
- ☐ DPIA (Data Protection Impact Assessment) documentation aligned with fiduciary framework
- ☐ Consent management systems configured for explicit principal authorization (not implicit)
- ☐ Deletion procedures that reflect principal's right to deletion (not organization's retention interests)
- ☐ Audit logs that demonstrate fiduciary duty compliance
- Third-Party Alignment
- ☐ Vendor contracts explicitly name your organization as "Data Fiduciary" and vendor as "Data Processor"
- ☐ Sub-processor engagement requires explicit fiduciary approval (not unilateral vendor decision)
- ☐ Security requirements reflect "high duty of care" standard (not just "industry standard")
Common Terminology Mistakes to Avoid
Frequent Terminology Errors:
- Calling principals "data subjects"
Error: This minimizes their active role and authority
Correction: Use "Data Principal" consistently - Treating DPDPA like GDPR with "legitimate interests" basis
Error: No legitimate interests exception under DPDPA
Correction: Ensure explicit consent for all processing beyond narrow exemptions - Describing your organization as "owner" of data
Error: Under fiduciary framework, the principal owns data; you're a trustee
Correction: "We hold this data in trust for you as data principals" - Vague "reasonable timeframe" for deletion**
Error: DPDPA specifies 30 days; vagueness violates fiduciary duty
Correction: Commit to specific timelines (maximum 30 days) - Confusing "Data Processor" with "Processor"
Error: Not all third parties are "Processors" under DPDPA
Correction: Only those processing on your instruction are processors; others are independent fiduciaries - Saying "we need to process this for security"**
Error: Security is your fiduciary duty, not a legal basis for processing
Correction: "We're implementing this security measure to protect your data as fiduciaries"
Conclusion: Language as Legal Expression
The shift from "Data Subject" to "Data Principal" and "Data Controller" to "Data Fiduciary" is not semantic window-dressing. It represents India's deliberate choice to build privacy law on trust relationships rather than rights-based frameworks. This choice has profound practical implications for how organizations should approach data handling, consent, and individual empowerment.
By aligning your internal practices, documentation, and mindset with DPDPA's terminology, you're not just achieving compliance—you're embracing the Act's core philosophy that data protection is fundamentally about honoring the trust individuals place in organizations with their personal information.