DPDPA in plain English: what the Act actually requires

The Digital Personal Data Protection Act, 2023 is India's first comprehensive privacy law. If your organization processes the digital personal data of individuals in India, it applies to you — whether you're based in Bengaluru or serving Indian users from abroad.

Most summaries drown the practical content in legal vocabulary. Here is the version an engineering or operations team can act on.

Two terms you need

• Data Principal — the individual the data is about. In most other laws this is the "data subject".
• Data Fiduciary — the organization that decides why and how the data is processed. Broadly the "controller" elsewhere.

The word fiduciary is a deliberate choice. It frames the relationship as one of trust and duty rather than mere compliance, and the obligations follow from that framing.

What the Act asks of you

• Consent and notice — collect on clear, informed consent, state the purpose, and make withdrawal as easy as giving it was.
• Purpose limitation — use the data for the stated purpose, and stop when that purpose ends.
• Data Principal rights — access, correction, erasure, and a working grievance-redressal route.
• Security safeguards — reasonable measures to prevent a personal data breach.
• Breach notification — inform the Data Protection Board of India, and affected individuals, when a breach occurs.

Organizations designated as Significant Data Fiduciaries carry additional duties, including appointing a Data Protection Officer based in India and conducting periodic data-protection impact assessments. Designation depends on factors such as volume and sensitivity of data processed.

Why the penalties changed the conversation

Financial penalties under the Act run up to ₹250 crore per instance. That figure is what moved DPDPA from a legal-team topic to a board-level one, and it's the reason readiness work is now getting budget it wouldn't have had two years ago.

Where the actual work lands

In practice, DPDPA readiness is less about drafting a policy and more about being able to answer questions about your own systems:

• What personal data do we hold, and in which systems does it live?
• What purpose did we state when we collected it, and are we still within it?
• If someone asks for erasure, can we actually complete it — including in backups, logs, and analytics?
• If a breach happened tonight, who decides, who notifies, and how fast?
• Who has access to the systems holding this data, and is that list current?

The last question is the one most teams answer worst, and it's shared with every security framework you might already be pursuing — which is the good news in all of this.

The overlap is the opportunity

If you're already working toward SOC 2 or ISO 27001, a substantial share of DPDPA's security expectations is work you have underway. Access control, encryption, incident response, and vendor management appear in all of them. The obligations that are genuinely DPDPA-specific — consent mechanics, notice, Data Principal rights, breach notification to the Board — are a smaller set than the compliance vendor pitch usually implies.

See it on your own evidence

Bring a policy document to a 20-minute call and we'll map it across your frameworks live.

Keep reading