Data Fiduciary, Principal, Processor: DPDP Roles Explained
DPDP introduces a clear framework of who is responsible for personal data. Understanding these roles is critical for compliance.
The Three Roles
1. Data Principal
Definition: Any individual whose personal data is being collected or processed.
In plain English: The user or customer whose data you're handling.
Rights under DPDP:
- Right to consent/withdraw consent
- Right to access their data
- Right to correct inaccurate data
- Right to deletion
- Right to data portability
- Right to grievance redressal
Examples:
- An e-commerce customer whose browsing history is tracked
- A HealthTech user whose medical records are stored
- An employee whose biometric data is scanned for entry
2. Data Fiduciary
Definition: An entity that determines the purpose and means of processing personal data.
In plain English: The company or organization that decides what data to collect and why.
Responsibilities:
- Obtain informed, explicit consent before processing
- Define data collection purposes clearly
- Implement security measures
- Honor data subject rights
- Report breaches within 72 hours
- Maintain records of processing activities
- Conduct Data Impact Assessments for sensitive processing
- Appoint a Data Protection Officer (if required)
- Ensure data processors comply with DPDP
Liability: The fiduciary is primarily liable for DPDP violations. If something goes wrong, the fiduciary faces fines and penalties.
Examples:
- An e-commerce platform (Fiduciary) decides to collect customer purchase history
- A HealthTech startup (Fiduciary) decides to process patient medical records
- A SaaS company (Fiduciary) decides to use customer data for product analytics
3. Data Processor
Definition: An entity that processes personal data on behalf of the Fiduciary, based on the Fiduciary's instructions.
In plain English: A third-party vendor hired by the Fiduciary to handle data, without making decisions about why or how it's used.
Responsibilities:
- Process data only as instructed by the Fiduciary
- Implement security measures
- Ensure employees comply with DPDP
- Notify the Fiduciary of any breaches
- Delete or return data when instructed
- Allow audits by the Fiduciary
- Not use data for their own purposes
Liability: The processor is secondarily liable. They must comply, but the Fiduciary is primarily responsible for supervision.
Examples:
- AWS (Processor) storing an e-commerce platform's customer data
- Sendgrid (Processor) sending marketing emails on behalf of a SaaS platform
- Stripe (Processor) processing payment data for an online store
Fiduciary vs. Processor: Key Distinction
Data Principal → Data Fiduciary (decides purpose, liable) → Data Processor (executes instructions)
Critical Point: Even if a Processor handles the data, the Fiduciary is primarily liable for breaches or violations.
Real-World Scenarios
Scenario 1: E-commerce Platform
Data Fiduciary: The e-commerce platform (decides to collect purchase history, browsing behavior)
Data Processors:
- Cloud provider (AWS/Azure) — stores customer data
- Payment gateway (Razorpay/Stripe) — processes payment data
- Email service (Mailchimp/Sendgrid) — sends marketing emails
- Analytics platform (Google Analytics) — tracks user behavior
Liability: If customer data is breached, the e-commerce platform is primarily liable (even if AWS had the breach). The platform should have contractually required AWS to maintain security.
Scenario 2: HealthTech App
Data Fiduciary: The HealthTech startup (decides to collect patient medical records, decides to store data for 7 years)
Data Processors:
- Cloud hosting (AWS/Azure) — stores patient records
- SMS gateway (Twilio) — sends patient notifications
- Analytics vendor — tracks usage patterns
Liability: If patient data is leaked, the HealthTech startup is primarily liable. They must have proper Data Processor Agreements in place.
Scenario 3: SaaS Platform
Data Fiduciary: The SaaS company (decides what customer data to collect, decides how long to retain it)
Data Processors:
- Cloud database (Firebase, MongoDB Atlas) — stores customer data
- CRM (HubSpot) — stores customer metadata
- Backup provider (Backblaze) — backs up data
- Sub-processors: Any vendor used by the above (e.g., Google Cloud used by HubSpot)
Liability: The SaaS company must ensure all processors (and their sub-processors) comply with DPDP.
Data Processor Agreements: Critical Legal Requirement
If you use any third party to process data, you must have a written Data Processor Agreement (DPA) that includes:
- Scope: What data is processed
- Duration: How long it's processed
- Purpose: Why it's processed
- Security: How it's protected
- Subprocessors: Whether sub-contractors are used
- Data Subject Rights: How rights are honored
- Confidentiality: Non-disclosure obligations
- Audit Rights: Fiduciary can audit processor
- Deletion/Return: What happens to data when contract ends
- Breach Notification: Processor must notify Fiduciary of breaches immediately
Without a DPA, using a processor is a DPDP violation.
Special Case: You Are BOTH Fiduciary and Processor
Some companies are both:
Example: A SaaS analytics platform serving enterprises.
- For their own operations → They're a Fiduciary (decide to collect employee data, customer usage data)
- For their customers → They're a Processor (process customer data per each customer's instructions)
Responsibility: Maintain separate compliance for each role. Have DPAs with your customers clarifying processor obligations.
Key Compliance Checklist
- Identify whether you're Fiduciary, Processor, or both
- If Fiduciary: Define data processing purposes clearly
- If Fiduciary: Obtain explicit consent before processing
- If using Processors: Create written DPAs with each vendor
- If Processor: Ensure you only process as instructed
- Maintain records of all processing activities
- Document sub-processor relationships
- Establish breach notification procedures
