India's Digital Personal Data Protection Act (DPDPA) has moved from statute-on-paper to phased enforcement, and it lands squarely on the desks of security and risk teams — not just legal. If your organisation processes the personal data of people in India, the operational obligations below are yours to evidence.
The shape of the law in one section
The DPDPA regulates digital personal data — data collected digitally, or collected offline and then digitised. Its vocabulary differs from GDPR's in ways that matter on exams and in contracts:
| DPDPA term | Closest GDPR equivalent | Who it means |
|---|---|---|
| Data Principal | Data Subject | The individual |
| Data Fiduciary | Controller | Decides purpose and means |
| Data Processor | Processor | Processes on the fiduciary's behalf |
| Consent Manager | — (no direct equivalent) | Registered platform through which principals give, manage and withdraw consent |
Two structural differences from GDPR are worth internalising. First, the DPDPA is consent-centric: consent (or a narrow set of "legitimate uses") is the basis for processing — there is no broad "legitimate interests" ground to lean on. Second, the consent manager is a genuinely novel construct: an accountable, registered intermediary for consent, with interoperability obligations.
Phased enforcement — why "is it in force?" has no one-word answer
Implementation is deliberately staggered through the DPDP Rules, with obligations switching on in waves rather than on a single day: institutional machinery first (the Data Protection Board), then consent-manager registration requirements, with the heaviest operational duties — notice standards, breach notification mechanics, significant-fiduciary obligations — phasing in across 2026 and 2027. The practitioner's takeaway: build now against the full obligation set, because "the rule isn't switched on yet" is a deadline, not an exemption. Verify the current phase against the latest MeitY notifications before you sign off any compliance position — the timeline has been adjusted before.
What security teams actually have to do
Reasonable security safeguards. Fiduciaries must implement reasonable safeguards to prevent breach — and, critically, the fiduciary remains liable even where a processor holds the data. Your vendor risk programme is now a statutory control. Expect to evidence encryption, access control, logging and monitoring as the baseline interpretation of "reasonable."
Breach notification — to both the Board and the affected individuals. Unlike GDPR's harm-threshold approach to notifying individuals, the DPDPA's duty to inform affected data principals applies to personal data breaches without a materiality carve-out, alongside notification to the Data Protection Board. Operationally: your incident-response runbook needs a India-specific notification branch, owned, tested and timed.
Data principal rights. Access, correction, erasure, grievance redressal, and the right to nominate. Each needs an intake channel, an identity-verification step, and an SLA — the same machinery GDPR teams built, with Indian specifics.
Significant Data Fiduciaries: the higher tier
The government may designate organisations as Significant Data Fiduciaries based on volume and sensitivity of data, risk to rights, and similar factors. Designation brings GDPR-familiar duties with Indian characteristics: appointing a Data Protection Officer based in India, independent data audits, and periodic Data Protection Impact Assessments. If you're a large consumer platform, bank, insurer, telco or health player operating in India, plan as if designation is coming.
Penalties concentrate exactly where security lives
The penalty schedule is capped per category, and the largest cap — up to ₹250 crore — attaches to failure to maintain reasonable security safeguards. Read that twice: the heaviest financial exposure in India's privacy law is a security control failure, not a consent-form defect. Breach-notification failures carry their own substantial cap. For CISOs, this is the budget argument written into statute.
Exam angles, if you're certifying
- CRISC / CISM: regulatory risk identification, third-party (processor) risk, breach-response governance, and KRIs for compliance posture.
- CISSP: Domain 1 legal and regulatory concepts — controller/processor analogues, cross-border principles, breach duties.
- CCSP: cloud contracts under DPDPA — processor obligations flow through your CSP agreements, and the shared responsibility line must be documented, not assumed.
A 90-day starting plan
- Map — inventory processing of Indian personal data: systems, purposes, processors, transfers.
- Gap-assess — consent capture and withdrawal, notice language, rights-request handling, breach runbook, vendor clauses.
- Fix the statutory minimum first — security safeguards evidence, breach notification branch, grievance channel.
- Decide your consent-manager posture and watch the designation criteria for significant fiduciaries.
- Re-verify the enforcement phase quarterly against official notifications, and treat each phase date as a project milestone with an owner.
The DPDPA is not GDPR with new labels. It is leaner, more consent-centric, and it points its biggest penalty at security failure. That makes it, unusually among privacy laws, a security practitioner's statute first.