The DPDP Readiness Handbook

If your company collects any personal data of people in India — names, phone numbers, email addresses, Aadhaar or PAN numbers, payment details, health information — this law applies to you. There is no small-business exemption.

The Act gives every individual (a Data Principal) enforceable rights over their data, and places binding duties on every organisation that decides how that data is used (a Data Fiduciary). Five duties matter most:

1. Collect data only with clear, specific, informed consent, and give notice in plain language.
2. Use it only for the stated purpose, and keep only what you still need.
3. Protect it with reasonable security safeguards.
4. Report any breach to the Data Protection Board within 72 hours, and tell the people affected.
5. Honour individuals' requests to see, correct, or erase their data.

Almost certainly yes. Work through these in order:

The obligations phase in. Two dates decide your planning.

• In force now The Data Protection Board of India is operational. The adjudicating body exists and is receiving complaints.
• 13 November 2026 Penalties become enforceable. Consent Manager registration opens. From this date financial penalties can actually be levied against you.
• 13 May 2027 Full compliance required. Consent, notice, security safeguards and data-principal rights must all be operational. Significant Data Fiduciary duties also take effect.

Each card gives you the duty, what it means in practice, the action to take, and — the part most guides omit — how you would demonstrate compliance if challenged.

Chapter III gives individuals rights that create operational work. Each one needs an owner and a route inside your product.

The government may notify a company as a Significant Data Fiduciary based on the volume and sensitivity of data processed and the risk involved. Three additional duties then apply:

• Appoint a Data Protection Officer based in India, reporting to the board or governing body.
• Appoint an independent data auditor.
• Conduct periodic Data Protection Impact Assessments and audits.

Penalties are set out in the Schedule to the Act and are levied per violation.

You cannot do everything at once. This order front-loads the obligations that carry the largest penalties and take the longest to build.

• Week 1 · Find out what you haveList every place personal data lives: production databases, analytics, CRM, support desk, spreadsheets, third-party tools. You cannot protect or delete what you have not located.
• Week 1 · Name an ownerAppoint the person answerable for data protection and publish their contact details. This is a legal requirement and it takes an afternoon.
• Week 2 · Fix the notice and consent flowRewrite sign-up notices in plain language. Split consent per purpose. Remove pre-ticked boxes. Add a withdrawal control.
• Week 2 · Write the breach runbookDecide now who declares a breach and who notifies the Board within 72 hours. Store the template where you will find it at 2am.
• Week 3 · Test the security safeguardsVerify encryption in transit and at rest, review who has access to production data, and confirm one customer cannot reach another's records. Get this assessed independently — it is the ₹250 crore obligation.
• Week 3 · Set retention periodsAssign every data category a purpose and an expiry. Schedule the deletions.
• Week 4 · Rehearse a rights requestRun an access, correction and erasure request end to end against a real account. Time it. Fix what breaks.
• Week 4 · Write it downCompile the evidence — notices, consent records, assessment report, runbook, retention schedule, grievance register — into one folder you could hand to a regulator or an enterprise customer.

Most of DPDP is organisational: policies, records, appointments, contracts. You can and should do that work internally — this handbook is written so you can.

One obligation is different. Reasonable security safeguards under §8(4) and Rule 6 is the only duty that can be tested from the outside rather than asserted on paper — and it carries the largest penalty. "We use encryption" is a claim. A dated report showing that your TLS is correctly configured, that account A provably cannot read account B's records, and that no personal data is exposed on a public endpoint is evidence.

RedForge is a security engineering practice built for Indian companies facing the DPDP deadline. We publish this handbook free because most of what the Act asks for is work you should do yourself — and because we would rather be judged on the one part we do exceptionally well than sell you a compliance package you do not need.

Why we built our own tooling

Security scanners have a credibility problem, and 2026 made it worse. Automated tools now generate vast quantities of confident, well-formatted findings that turn out to be nothing — so much so that major open-source projects have shut their vulnerability reporting programmes rather than keep triaging the noise. A report that says CRITICAL means very little now.

We built RedForge around the opposite instinct. Our scanner is not permitted to report a finding it cannot prove. Every candidate issue runs through a verification chain before a human ever sees it:

1. Control — establish the legitimate baseline response.
2. Mutation — change exactly one variable, nothing else.
3. Independent read-back — confirm the effect through a separate channel, not the response we just triggered.
4. Negative control — a near-identical safe request that must not fire. If it does, the result is discarded.

Anything that fails a step is marked unverified and does not become a finding. In practice this means we hand you fewer issues than a conventional scanner — and every one of them comes with the raw request and response that proves it.

What our DPDP assessment covers

We scope tightly to §8(4) and Rule 6 — reasonable security safeguards. That is the ₹250 crore obligation, and the only one that can be independently tested rather than asserted.

• Encryption in transit — TLS configuration, certificate validity, downgrade paths.
• Access control between customers — we create two accounts and prove whether one can reach the other's records. This is the single most common way personal data actually leaks, and it is exactly what Rule 6 means by access controls.
• Exposed personal data — Aadhaar, PAN, contact and payment identifiers reachable on public endpoints, in JavaScript bundles, or in archived pages.
• Third-party data flows — personal data leaving to analytics, advertising or support tools that your notice does not disclose.
• Consent and notice at the point of collection — whether a notice is actually shown, and whether trackers fire before consent is given.

What you receive

• A written assessment mapping each finding to the DPDP section it engages, with severity and remediation steps in language your engineers can act on.
• An evidence pack — raw request and response captures for every verified finding, so a regulator, auditor or enterprise customer can independently confirm it.
• A re-test after you remediate, so your final report reads as resolved rather than outstanding.

Where to start

If you want to know where you stand before committing to anything, we run a passive, read-only review that touches nothing and changes nothing on your systems, and tells you which of the Rule 6 safeguards you can currently evidence and which you cannot.