DPDP Act Data Fiduciary Obligations: Full Checklist
A complete checklist of Data Fiduciary obligations under the DPDP Act 2023 — consent, notice, security, rights fulfilment, breach notification, and more.
- Data Fiduciaries have obligations across seven domains: lawful basis, notice, consent, security, rights, breach notification, and Data Processor contracts.
- All obligations apply to every Data Fiduciary — additional SDF obligations apply only to classified entities.
- Accuracy, storage limitation, and data minimisation are implicit in the Act's purpose limitation framework.
- Maintaining evidence of compliance is as important as achieving compliance — the Board will ask for documentation.
- A compliance gap assessment against these obligations is the foundation of your DPDP implementation roadmap.
In this guide
Lawful Basis for Every Processing Activity
Section 4 imposes the foundational obligation: every processing activity must have a lawful basis — either consent under Section 6 or a legitimate use under Section 7. Data Fiduciaries must document the lawful basis for each processing activity in their Records of Processing Activities (ROPA). While a ROPA is not explicitly mandated by name in the Act, it is the practical evidence of compliance that the Board would request in an inquiry.
Section 8(3) requires Data Fiduciaries to ensure that personal data is only used for the purpose it was collected for. Once the purpose is fulfilled, the data must be erased. This purpose limitation obligation requires Data Fiduciaries to define purposes clearly at collection time and to have a data retention policy that erases data when purposes are no longer valid.
Section 8(4) requires Data Fiduciaries to ensure data accuracy — taking reasonable steps to correct inaccuracies in personal data that could be used to affect the Data Principal adversely. Inaccurate data used in credit scoring, HR decisions, or service eligibility must be corrected when the inaccuracy is known.
Privacy Notice Obligation
Section 5 requires Data Fiduciaries to provide a notice before or at the time of seeking consent. The notice must state: the personal data to be collected; the purpose of processing; the Data Principal's rights and how to exercise them; how to raise a grievance; and how to withdraw consent.
Notices must be in clear, plain language. If you currently serve your users through a 5,000-word privacy policy full of legal boilerplate, you must redesign. The notice that accompanies a consent request must be comprehensible to a non-lawyer. A supplementary detailed privacy policy can exist, but the active consent notice must be plain.
The language obligation under Section 5 requires notices to be available in the language the Data Principal uses — which for pan-India consumer companies means support for Hindi and potentially regional languages. The Rules will clarify the extent of this obligation, but building multilingual privacy notice infrastructure is a non-trivial operational requirement.
Consent Management Obligation
Section 6 requires Data Fiduciaries to obtain valid consent for all processing not covered by Section 7 legitimate uses. Consent must be free, specific, informed, unconditional, and unambiguous — and must be evidenced. Data Fiduciaries must maintain records of consent: who consented, to what, when, through which mechanism, and whether it has subsequently been withdrawn.
Section 6(4) requires consent withdrawal to be as easy as consent giving. This is both a technical requirement (implement a withdrawal mechanism) and a policy requirement (do not create procedural friction around withdrawal). Section 6(5) prohibits charging fees for withdrawal.
Consent records are the primary evidence that the Board will request if a Data Principal complains about unlawful processing. Your consent records must be retrievable by Data Principal and must capture sufficient detail to demonstrate that valid consent was given. "We had a checkbox in our signup flow" is not evidence — you need to be able to demonstrate that on a specific date, a specific user checked that specific box for a specific purpose.
Security Safeguards Obligation
Section 8(5) requires Data Fiduciaries to implement "reasonable security safeguards to prevent personal data breach." This is a principle-based obligation — the Act does not enumerate specific technical controls. What is "reasonable" depends on the nature and volume of data, the technology available, and the cost of implementation relative to the risk.
In practice, reasonable security safeguards for an Indian B2B SaaS company processing customer data will include: encryption of personal data at rest and in transit; access controls limiting access to personal data to authorised personnel; multi-factor authentication on administrative access; regular vulnerability assessments and penetration testing; security patching within a defined SLA; and a documented incident response plan.
Data Fiduciaries are also responsible for ensuring that Data Processors they engage implement equivalent security safeguards. Section 8(2) requires Data Fiduciaries to ensure Data Processors comply with the Act's requirements by contract. Security requirements must be written into every Data Processing Agreement.
Data Principal Rights Fulfilment
Sections 11-13 require Data Fiduciaries to fulfil Data Principal rights: access (Section 11), correction and erasure (Section 12), and grievance redressal (Section 13). Section 14 requires accommodation of nominee rights.
Rights fulfilment is not a passive obligation — you cannot simply have a rights request email address and hope nobody uses it. You must have: a documented process for handling each type of request; internal SLAs for response and fulfilment; technical capability to access, correct, and delete data across all your systems; and a logging mechanism to demonstrate compliance.
The penalty for non-fulfilment of rights is up to ₹10,000 per Data Principal — which scales significantly for large user bases. More importantly, a pattern of ignored rights requests is likely to attract a Board investigation, which creates reputational damage and the risk of larger penalties for other violations uncovered during the investigation.
Breach Notification Obligation
Section 8(6) requires notification of every personal data breach to the Data Protection Board and to affected Data Principals. There is no de minimis threshold — every breach is notifiable. The expected notification timeline (from the Draft Rules) is 72 hours for the initial Board notification.
The obligation is real-time: you cannot wait to understand the full scope of a breach before notifying. The Board notification must go out within 72 hours of your becoming aware, based on available information, with a follow-up report when more detail is known. Building incident response infrastructure that supports rapid notification is a compliance necessity.
Data Fiduciaries must also maintain a record of all personal data breaches — including breaches that were immediately contained and may not have resulted in measurable harm. This breach log is evidence of your monitoring and incident management capability.
Data Processor Contracts and Oversight
Section 8(2) requires Data Fiduciaries to ensure that Data Processors process personal data only for the purposes specified in a valid contract and in compliance with the Act. Every Data Processor engagement must be governed by a Data Processing Agreement (DPA) that specifies: the nature and purpose of processing; the categories of personal data; the security requirements; the breach notification obligations; and the terms for returning or deleting data at contract end.
This obligation extends to all your SaaS vendors, cloud infrastructure providers, analytics tools, marketing automation platforms, and any other service that processes personal data on your behalf. Conduct a vendor audit: identify all processors, assess whether current contracts contain adequate DPA terms, and update contracts that fall short.
Section 8(2) makes the Data Fiduciary responsible for processor compliance. If your processor has a breach, the Data Fiduciary faces the notification obligation and potential penalty for inadequate security. Your DPAs must give you audit rights over processor security practices and require prompt breach notification from processors to you.
Frequently Asked Questions
How many of these obligations apply to a small startup with fewer than 50 employees?
Do we need a Records of Processing Activities (ROPA) like GDPR requires?
What is the minimum viable compliance programme for a startup?
Are we responsible for our customers' compliance if they are Data Fiduciaries using our SaaS platform?
How often should we review our compliance against these obligations?
Automate your compliance today
AuditPath runs 86+ automated checks across AWS, GitHub, Okta, and 14 more integrations. SOC 2 and DPDP Act. Free plan available.
Start for free