DPDP Handbook for IT Leaders

Map every personal-data stream in your sector.

Same Act — different inventories. Start with your industry map: clinical or customer journeys, employees, visitors, and every vendor that touches PII. Then attach notice, basis, retention, and cascade.

• SaaS: end-users, marketing, support, HR + customer-tenant processor hat + SDK chain
• BFSI: KYC/AML, products, payments, cross-sell, collections, staff, vendors
• Health: Emergency, IPD, OPD, Pharmacy, labs, billing/TPA, staff, visitors, vendors
• EdTech: learners, parents, teachers, campus CCTV, LMS/proctoring vendors
• Manufacturing: HR, visitors, biometrics, dealers, warranty, IoT, 3PLs

SaaS

SaaS full map: Fiduciary streams (users, marketing, support, HR) plus Processor tenant data — every SDK needs a DPA and must switch off on withdrawal.

Flowchart as text (21 connections):

1. SaaS / product company → Fiduciary hat
2. SaaS / product company → Processor hat
3. Fiduciary hat → End-user accounts
4. Fiduciary hat → Marketing / analytics
5. Fiduciary hat → Support tickets
6. Fiduciary hat → Employee / HR systems
7. Processor hat → Customer tenant data in product
8. End-user accounts → Sec 5 notice + per-purpose Sec 6
9. Marketing / analytics → Sec 5 notice + per-purpose Sec 6
10. Support tickets → Sec 5 notice + per-purpose Sec 6
11. Employee / HR systems → Sec 5 notice + per-purpose Sec 6
12. Customer tenant data in product → Back-to-back DPA with customer
13. Sec 5 notice + per-purpose Sec 6 → SDKs / pixels / sub-processors?
14. SDKs / pixels / sub-processors? → (Yes) DPA + data-flow map + breach SLA
15. SDKs / pixels / sub-processors? → (No) Consent vault + version log
16. DPA + data-flow map + breach SLA → Consent vault + version log
17. Back-to-back DPA with customer → Consent vault + version log
18. Consent vault + version log → CRM / ESP / ads / warehouse / product
19. CRM / ESP / ads / warehouse / product → Withdrawal or DPR?
20. Withdrawal or DPR? → (Yes) Cascade off every system + SDK
21. Withdrawal or DPR? → (No) CRM / ESP / ads / warehouse / product

BFSI

BFSI full map: KYC retention vs product consent vs cross-sell — schedule by record class; vendors stay on the Sec 8-2 chain.

Flowchart as text (23 connections):

1. Bank / NBFC / insurer / broker → KYC / AML / CKYC
2. Bank / NBFC / insurer / broker → Account / policy / loan
3. Bank / NBFC / insurer / broker → Payments / cards
4. Bank / NBFC / insurer / broker → Cross-sell / analytics
5. Bank / NBFC / insurer / broker → Collections / recovery
6. Bank / NBFC / insurer / broker → Employees / agents
7. Bank / NBFC / insurer / broker → Vendors: KYC SaaS / cloud / BPA
8. KYC / AML / CKYC → Sec 7 or mandated retention
9. Account / policy / loan → Sec 6 consent for that product
10. Payments / cards → Sec 6 consent for that product
11. Cross-sell / analytics → Fresh specific consent
12. Collections / recovery → Sec 7 or mandated retention
13. Employees / agents → Employment notice + basis
14. Vendors: KYC SaaS / cloud / BPA → DPA + Sec 8-2 chain
15. Sec 7 or mandated retention → Purpose + retention register
16. Sec 6 consent for that product → Purpose + retention register
17. Fresh specific consent → Purpose + retention register
18. Employment notice + basis → Purpose + retention register
19. DPA + Sec 8-2 chain → Purpose + retention register
20. Purpose + retention register → Core / CRM / collections / vendors
21. Core / CRM / collections / vendors → Purpose ends or DPR?
22. Purpose ends or DPR? → (Law requires keep) Retain that record class only
23. Purpose ends or DPR? → (Erase allowed) Erase + notify processors

Health

Health full map: Emergency, IPD, OPD, Pharmacy, labs, billing/TPA, employees, visitors/CCTV, outsourced labs — age gate + secondary-use firewall.

Flowchart as text (43 connections):

1. Hospital / HealthTech / diagnostic chain → Clinical care data
2. Hospital / HealthTech / diagnostic chain → Workforce data
3. Hospital / HealthTech / diagnostic chain → Campus / access data
4. Hospital / HealthTech / diagnostic chain → Vendor / partner data
5. Clinical care data → Emergency / trauma
6. Clinical care data → IPD / admission / OT
7. Clinical care data → OPD / clinics / teleconsult
8. Clinical care data → Pharmacy / formulary
9. Clinical care data → Labs / imaging / pathology
10. Clinical care data → Billing / TPA / insurance
11. Workforce data → Employees / doctors / nurses
12. Workforce data → Contract staff / residents
13. Campus / access data → Visitors / attenders
14. Campus / access data → CCTV / biometric gates
15. Vendor / partner data → Outsourced labs / cloud HIS
16. Vendor / partner data → TPA / insurers / device vendors
17. Emergency / trauma → Sec 7 - treat first then notice
18. IPD / admission / OT → Sec 5 notice + purpose consent
19. OPD / clinics / teleconsult → Sec 5 notice + purpose consent
20. Pharmacy / formulary → Sec 5 notice + purpose consent
21. Labs / imaging / pathology → Sec 5 notice + purpose consent
22. Billing / TPA / insurance → Sec 5 notice + purpose consent
23. Employees / doctors / nurses → Employment notice + basis
24. Contract staff / residents → Employment notice + basis
25. Visitors / attenders → Visitor notice + short retention
26. CCTV / biometric gates → Visitor notice + short retention
27. Outsourced labs / cloud HIS → DPA + breach SLA Sec 8-2
28. TPA / insurers / device vendors → DPA + breach SLA Sec 8-2
29. Sec 7 - treat first then notice → Patient under 18?
30. Sec 5 notice + purpose consent → Patient under 18?
31. Patient under 18? → (Yes) Verifiable guardian consent
32. Patient under 18? → (No) Clinical + consent register
33. Verifiable guardian consent → Clinical + consent register
34. Employment notice + basis → Clinical + consent register
35. Visitor notice + short retention → Clinical + consent register
36. DPA + breach SLA Sec 8-2 → Clinical + consent register
37. Clinical + consent register → Secondary use?
38. Secondary use? → (Research / AI / marketing) Fresh consent OR anonymise
39. Secondary use? → (Care continuity only) Stay within original purpose
40. Fresh consent OR anonymise → Clinical + consent register
41. Clinical + consent register → DPR / discharge / retention end?
42. DPR / discharge / retention end? → (Yes) Erase or archive per clinical schedule
43. DPR / discharge / retention end? → (No) Clinical + consent register

EdTech

EdTech full map: age gate first; parents, staff, visitors, and proctoring vendors all land in one register with child-tracking bans.

Flowchart as text (23 connections):

1. School / EdTech / coaching / university → Learner accounts
2. School / EdTech / coaching / university → Parent / guardian contacts
3. School / EdTech / coaching / university → Teachers / staff HR
4. School / EdTech / coaching / university → Visitors / campus CCTV
5. School / EdTech / coaching / university → Vendors: LMS / payments / proctoring
6. Learner accounts → Age gate
7. Age gate → (Under 18) Verifiable parental consent
8. Age gate → (18+) Standard Sec 6 consent
9. Verifiable parental consent → No behavioural tracking
10. No behavioural tracking → No targeted ads to children
11. Standard Sec 6 consent → Consent + age register
12. No targeted ads to children → Consent + age register
13. Parent / guardian contacts → Consent + age register
14. Teachers / staff HR → Employment notice + basis
15. Visitors / campus CCTV → Visitor / CCTV notice
16. Vendors: LMS / payments / proctoring → DPA + sub-processor map
17. Employment notice + basis → Consent + age register
18. Visitor / CCTV notice → Consent + age register
19. DPA + sub-processor map → Consent + age register
20. Consent + age register → Deliver learning - minimal data
21. Deliver learning - minimal data → Exit / graduate / withdraw?
22. Exit / graduate / withdraw? → (Yes) Erase or restrict + cascade
23. Exit / graduate / withdraw? → (No) Deliver learning - minimal data

Mfg

Manufacturing full map: employees, visitors, biometrics, dealers, warranty customers, IoT owners, 3PLs — each stream needs its own basis.

Flowchart as text (24 connections):

1. Manufacturer / auto / FMCG / logistics → Employees / contractors
2. Manufacturer / auto / FMCG / logistics → Visitors / plant CCTV
3. Manufacturer / auto / FMCG / logistics → Biometric attendance
4. Manufacturer / auto / FMCG / logistics → Dealer / distributor contacts
5. Manufacturer / auto / FMCG / logistics → Warranty / service customers
6. Manufacturer / auto / FMCG / logistics → IoT / connected-product telemetry
7. Manufacturer / auto / FMCG / logistics → Vendors / 3PLs / cloud
8. Employees / contractors → Employment notice + basis
9. Visitors / plant CCTV → Visitor notice + short retention
10. Biometric attendance → Workplace notice + retention limit
11. Dealer / distributor contacts → B2B contact consent / contract
12. Warranty / service customers → Product notice + purpose consent
13. IoT / connected-product telemetry → Owner-linked consent + purpose
14. Vendors / 3PLs / cloud → DPA + breach SLA
15. Employment notice + basis → Unified notice / consent register
16. Visitor notice + short retention → Unified notice / consent register
17. Workplace notice + retention limit → Unified notice / consent register
18. B2B contact consent / contract → Unified notice / consent register
19. Product notice + purpose consent → Unified notice / consent register
20. Owner-linked consent + purpose → Unified notice / consent register
21. DPA + breach SLA → Unified notice / consent register
22. Unified notice / consent register → DPR or purpose ends?
23. DPR or purpose ends? → (Yes) Fulfil DPR / erase where lawful
24. DPR or purpose ends? → (No) Unified notice / consent register

Six roles. Know which ones you wear.

Most companies are a Data Fiduciary for some data and a Data Processor for other data — at the same time.

• Map Fiduciary vs Processor hats
• Consent Manager is India-specific
• SDF adds DPO / audit / DPIA

Diagram 1

Sec 8-1: the Fiduciary stays accountable for the Processor's acts. Outsourcing work never outsources liability.

Flowchart as text (6 connections):

1. Data Principal → Consent Manager
2. Consent Manager → (relay / withdraw) Data Fiduciary
3. Data Principal → (direct consent / request) Data Fiduciary
4. Data Fiduciary → (Sec 8-2 contract) Data Processor
5. Data Processor → Fiduciary still accountable - Sec 8-1
6. SDF: DPO / DPIA / audit → Data Protection Board

Lawful basis: consent, or a short list of exceptions.

Only two doors — consent or a narrow Sec 7 legitimate use. No catch-all legitimate interest.

• Only consent or Sec 7 legitimate use
• No GDPR-style legitimate interest
• Purpose limitation + minimisation

Diagram 1

Run this for every data field. Lawful basis is a state you keep checking — not a one-time gate.

Flowchart as text (11 connections):

1. Process personal data? → Purpose lawful and specific?
2. Purpose lawful and specific? → (No) Stop - do not collect
3. Purpose lawful and specific? → (Yes) Fits Sec 7 legitimate use?
4. Fits Sec 7 legitimate use? → (Yes) Proceed on Sec 7
5. Fits Sec 7 legitimate use? → (No) Valid Sec 6 consent?
6. Valid Sec 6 consent? → (No) Serve Sec 5 notice + capture consent
7. Serve Sec 5 notice + capture consent → Valid Sec 6 consent?
8. Valid Sec 6 consent? → (Yes) Process only what is necessary
9. Process only what is necessary → Purpose done or withdrawn?
10. Purpose done or withdrawn? → (Yes) Erase under Sec 8-7
11. Purpose done or withdrawn? → (No) Process only what is necessary

Consent is an architecture, not a checkbox.

Granular, per-purpose, multilingual, withdrawable, logged — and withdrawal that cascades.

• Notice in plain language + 22 languages
• Withdrawal must cascade to every system
• Keep receipts / version logs

Diagram 1

Capture → vault → systems → cascade on withdrawal. If marketing cannot switch off, you are not done.

Flowchart as text (7 connections):

1. Touchpoint → Sec 5 notice plain + 22 languages
2. Sec 5 notice plain + 22 languages → Sec 6 granular consent per purpose
3. Sec 6 granular consent per purpose → Consent vault
4. Consent vault → Wire to CRM / ESP / ads / product
5. Wire to CRM / ESP / ads / product → Withdrawal?
6. Withdrawal? → (Yes) Cascade off everywhere
7. Withdrawal? → (No) Wire to CRM / ESP / ads / product

The rights people can exercise against you.

Access, correct/erase, grievance, nominate — with a logged fulfilment clock.

• Access, correct/erase, grievance, nominate
• Notify processors on erasure
• Log every DPR outcome

Diagram 1

Teams skip two steps: notifying processors on erasure, and logging the outcome as evidence.

Flowchart as text (16 connections):

1. DPR filed → Identity verified?
2. Identity verified? → (No) Ask for more info
3. Ask for more info → Identity verified?
4. Identity verified? → (Yes) Which right?
5. Which right? → (Access) Data summary + sharing list
6. Which right? → (Correct / Erase) Update / delete + notify processors
7. Which right? → (Grievance) Route to officer
8. Which right? → (Nominate) Record nominee
9. Data summary + sharing list → Respond in published SLA
10. Update / delete + notify processors → Respond in published SLA
11. Route to officer → Respond in published SLA
12. Record nominee → Respond in published SLA
13. Respond in published SLA → Log outcome in DPR register
14. Log outcome in DPR register → Unsatisfied?
15. Unsatisfied? → (Yes) Escalate to Board
16. Unsatisfied? → (No) Closed - keep evidence

When it goes wrong: the 72-hour clock.

No harm-threshold escape hatch. Intimate people and the Board without delay.

• No harm-threshold escape hatch
• Intimate people + Board without delay
• Detailed Board report within 72 hours

Diagram 1

Two parallel tracks: affected people and the Board. The without-delay intimation trips teams who wait for perfect facts.

Flowchart as text (7 connections):

1. Breach detected → Contain and assess
2. Contain and assess → Intimate affected people without delay
3. Contain and assess → Intimate Board initial - without delay
4. Intimate Board initial - without delay → Detailed Board report within 72 hours
5. Intimate affected people without delay → Remediate + root cause
6. Detailed Board report within 72 hours → Remediate + root cause
7. Remediate + root cause → Retain evidence 1 year plus

The two special regimes that change your build.

Under-18 parental consent / no tracking, and SDF extras if the government notifies you.

• Under-18 needs verifiable parental consent
• No tracking / targeted ads to children
• SDF stacks on top of base duties

Children

Child gate: verifiable guardian consent, no behavioural tracking, no targeted ads.

Flowchart as text (7 connections):

1. User signs up → Under 18?
2. Under 18? → (No) Normal consent flow
3. Under 18? → (Yes / Unknown) Verifiable parental / guardian consent
4. Verifiable parental / guardian consent → No behavioural tracking
5. No behavioural tracking → No targeted ads to children
6. No targeted ads to children → Nothing harmful to wellbeing
7. Nothing harmful to wellbeing → Proceed within limits

SDF

SDF adds DPO, auditor, DPIAs — it does not replace the base DPDP load.

Flowchart as text (5 connections):

1. Notified as SDF? → (Yes) Appoint India-based DPO
2. Appoint India-based DPO → Independent data auditor
3. Independent data auditor → Periodic DPIA + audits
4. Periodic DPIA + audits → Other govt measures
5. Notified as SDF? → (Not yet) Still carry full base DPDP duties

Where data can go, when this bites, and what it costs.

Transfer OK unless blacklisted; sector rules may still force localisation. Deadline 13 May 2027.

• Transfer OK unless country restricted
• Sector localisation can still apply
• Plan back from 13 May 2027

Diagram 1

DPDP uses a blacklist, not GDPR-style adequacy. Real localisation pressure often comes from sector regulators.

Flowchart as text (5 connections):

1. Transfer outside India? → On restricted list?
2. On restricted list? → (Yes) Do not transfer there
3. On restricted list? → (No) Sector localisation? e.g. RBI
4. Sector localisation? e.g. RBI → (Yes) Follow stricter sector rule
5. Sector localisation? e.g. RBI → (No) Transfer OK - duties travel with data

Where to actually start.

Sequence the expensive surprises early — while you still have time.

• Name one cross-functional owner
• Inventory by purpose + basis
• Consent architecture + re-consent Day 1
• Tier vendors / fix DPAs
• Evidence layer + breach playbook

Diagram 1

Five moves in order. Do not buy another tool before the owner and inventory exist.

Flowchart as text (5 connections):

1. Day 0 → Name one owner Legal+Product+Mkt+Ops+Eng+HR
2. Name one owner Legal+Product+Mkt+Ops+Eng+HR → Inventory by purpose + basis
3. Inventory by purpose + basis → Consent architecture + re-consent
4. Consent architecture + re-consent → Tier vendors / fix DPAs
5. Tier vendors / fix DPAs → Evidence layer + breach playbook

Read this first: DPDP is not an InfoSec project.

Before the clauses, the single misread that costs Indian companies the most money.

Walk into most boardrooms and DPDP gets handed to the CISO. The logic feels airtight: it's about data, data lives in systems, systems are secured by security. So the firewall team gets a new line item and everyone moves on.

Then year one arrives and the budget is blown — not on technology, but on the people and processes nobody scoped. We've watched this happen enough times that this handbook leads with the fix instead of the symptom.

A perfectly secured database can still be 100% non-compliant: encrypted, access-controlled, SOC-monitored — and holding data you never had a lawful basis to keep, for a purpose you never disclosed, with no way to honour a withdrawal request. Security is necessary but not sufficient . DPDP is a question about rights and accountability , and rights live in Legal, Product, Marketing, Customer Ops and HR — not just in the SOC.

Not the security team. Marketing owns the consent flows and the ad pixels. Product owns the SDKs and the sign-up forms. Customer Ops owns the support transcripts and the call recordings. HR owns employee and candidate records. Finance owns the billing PII. Engineering owns the logs and the vendor integrations. DPDP touches all of them — which is why a programme run from a single function under-scopes by design.

What DPDP actually is (and what it isn't)

A 2023 Act, given teeth by 2025 Rules. Short statute, big behavioural change.

The Digital Personal Data Protection Act, 2023 is India's first standalone privacy law. It governs the processing of digital personal data — any data about an identifiable individual, in digital form. The DPDP Rules, 2025 , notified on 13 November 2025, turned the principles into operating procedure: how to write a notice, how to capture and register consent, how to report a breach, how long to keep logs.

In one line: if you collect or use information about Indian individuals in digital form, you need a lawful reason to do it, you must tell people what you're doing, you must let them control it, and you must be able to prove it.

"We're GDPR-ready, so we're basically DPDP-ready."

Different shape. DPDP has no "sensitive data" category , no broad "legitimate interest" basis, but adds multilingual notices, a registered Consent Manager ecosystem, a nomination right, and penalties that go to the State — not to victims.

Six roles. Know which ones you wear.

Most companies are a Data Fiduciary for some data and a Data Processor for other data — at the same time. Mapping this wrong is where accountability gaps open.

The individual the data is about. For a child, this is the parent/guardian. Can also be a nominee acting after death or incapacity.

Decides the why and how of processing. Carries almost all the obligations. You're probably this.

Processes data on behalf of a Fiduciary, under contract. Your cloud, CRM, analytics vendor — and sometimes, you for a client.

A Board-registered platform that lets people give, manage and withdraw consent in one place. A new India-specific intermediary.

Diagram: The relationship map. The arrow that catches people out: §8(1) makes the Fiduciary accountable for the Processor's acts. Outsourcing the work never outsources the liability.

One core. Four frameworks.

If you already do ISO 27001, SOC 2 or GDPR, you've built most of the security core. DPDP's net-new demands sit around the edges — and that edge is exactly what gets under-budgeted.

The practical takeaway from this picture: don't rebuild the security core for DPDP. Your existing certifications already evidence most of §8(5) 's "reasonable security safeguards." Spend the new money on the consent layer, the rights-fulfilment layer, and the evidence layer that no security framework gives you for free.

Lawful basis: consent, or a short list of exceptions.

DPDP gives you only two doors. Consent — or one of a narrow set of "legitimate uses." There is no catch-all "we have a legitimate business interest."

This is the cleanest way DPDP differs from GDPR in day-to-day life. Under GDPR you can often lean on "legitimate interest." Under DPDP, if your purpose doesn't fit one of the specific legitimate uses in §7 — voluntary provision for the stated purpose, government benefits/services, medical emergency, employment, disaster response, and a few others — you need consent . Full stop.

"We collect it now because it might be useful later." DPDP's purpose limitation and data minimisation make speculative collection a liability, not an asset. Every field you collect "just in case" is a field you must notice, secure, justify, and erase on request. The cheapest data to protect is the data you never collected.

Diagram: "Can I process this?" — the decision you run for every data field. Note the loop at the bottom: lawful basis isn't a one-time gate, it's a state you have to keep checking.

Consent is an architecture, not a checkbox.

The cookie-banner reflex is the most common — and most expensive — way to get this wrong. DPDP consent has to be granular, per-purpose, multilingual, withdrawable, logged, and able to cascade across every system when it's revoked.

Capturing consent is the easy 20%. The expensive 80% is withdrawal that actually works . If a person revokes marketing consent, that signal has to reach your ESP, your ad platforms, your CRM, your analytics and your data warehouse — fast, and provably. A withdrawal that doesn't cascade is a breach waiting to be reported.

When the Board comes knocking, "we have a privacy policy" is not evidence. These are the operational records that prove the system works — the difference between a programme and a PDF.

The rights people can exercise against you.

Four rights you have to operationalise — and a fulfilment workflow with a clock on it.

Diagram: The DPR fulfilment workflow. The two steps teams skip: notifying processors of a correction/erasure, and logging the outcome so you can prove you complied. A right you can't evidence honouring is a right you didn't honour.

When it goes wrong: the 72-hour clock.

DPDP's breach rules are unusually strict — no "risk of harm" threshold to hide behind. A personal data breach means you tell people, and you tell the Board.

"It was minor / encrypted / we caught it fast — so it doesn't count." DPDP's notification trigger is the breach , not a harm-threshold you get to judge. Build the muscle to notify quickly and accurately, because the penalty for failing to notify §8(6) can run to ₹200 crore — independent of the penalty for the breach itself.

Diagram: The breach response flow. Two parallel obligations: the affected people and the Board . The 72-hour detailed report is the deadline everyone quotes — but the "without delay" initial intimation is what trips teams who wait to have "all the facts" first.

The two special regimes that change your build.

India sets the bar at 18 — higher than many jurisdictions. If your product can be used by minors, this is an architecture decision, not a policy footnote.

The government can notify any Fiduciary as "significant" based on the volume and sensitivity of data, risk to data principals, risk to electoral democracy and to the security of the State. The trap: assuming this only means Big Tech.

Diagram: The child-user gate. Verifiable parental consent, no behavioural tracking, no targeted ads, nothing harmful. The Rules contemplate carve-outs for certain classes (e.g. some education and health uses), but the default posture is restrictive.

Diagram: SDF obligations stack on top. A mid-size health, fintech or adtech firm processing large or sensitive volumes can be notified. And being a non-SDF doesn't lighten the base load — it just removes the DPO/audit/DPIA layer.

Where data can go, when this bites, and what it costs.

The DPDP Rules, 2025 are notified. The Data Protection Board of India is constituted and operational. Definitions and procedural provisions take effect immediately.

The registration regime for Consent Managers comes into force (≈12 months after notification). The consent-intermediary ecosystem starts forming.

Notice & consent standards, security safeguards, breach notification, retention & erasure, data-principal rights and SDF duties all become enforceable. This is the date to plan backwards from.

Penalties are cumulative across heads — a single mishandled breach can trigger the safeguards penalty and the notification penalty at once. They are paid to the State, not to affected individuals.

Diagram: Transfer is allowed by default. DPDP uses a "blacklist," not an "adequacy whitelist" — the opposite of GDPR. The real localisation pressure in India comes from sector regulators stacked above DPDP.

A D2C brand budgeted ₹35L. Spent ₹60L. Still not audit-ready.

A well-known consumer brand with a genuinely strong security posture — DLP, EDR, SIEM, 24×7 SOC, IAM/PAM, a tier-1 hyperscaler. They scoped DPDP as "incremental InfoSec." It wasn't.

Technology was the smallest miss. People and process absorbed the overrun, because that's where the real work was — discovery, re-consent, vendor remediation. Most organisations plan for tech and under-plan for discovery. That's exactly where the cost sits.

None of these were errors of judgement. They were the standard assumptions a mature security team brings to DPDP — which is precisely why they're worth naming.

Legal, Product, Marketing and Customer Ops all hold personal data. They weren't at the table.

Historical consents didn't carry forward. The gap surfaced in month four.

Same law. Very different pressure points.

DPDP is sector-neutral on paper. In practice, where it hurts depends entirely on what data you hold, who it's about, and which regulator already sits above you.

Where to actually start.

You can't do everything before May 2027 at once. You can sequence it so the expensive surprises surface early, while there's still time to absorb them.

Legal, Product, Marketing, Customer Ops, Engineering and HR — not just security. Name a single accountable owner who can convene all of them.

DLP tells you where files are. You need a record of what personal data you hold, why , and on what basis . This is the line item that always overruns — start it first.

For every collection point, is it consent or a §7 legitimate use? Anything you can't justify is a candidate for deletion, not a problem to solve.

Granular, per-purpose, multilingual, withdrawable, logged — and a withdrawal that cascades. Treat re-consent of your existing base as a Day 1 workstream.

Frequently asked questions

What is the DPDP Handbook?

It is a free guide from Complynz to India's Digital Personal Data Protection Act 2023 and the DPDP Rules 2025. It explains the law in plain English around the decisions an organisation has to make, with a flowchart for each decision and data-stream maps for SaaS, BFSI, healthcare, EdTech and manufacturing.

Who is the DPDP Handbook for?

IT heads, CISOs, compliance and product leaders in Indian organisations that collect or use digital personal data, especially MSMEs and mid-market companies deciding who owns DPDP and where to start. It is not legal advice.

Is there a legitimate interest basis under the DPDP Act?

No. The DPDP Act gives two lawful doors: consent, or a narrow list of Section 7 legitimate uses. There is no catch-all 'we have a legitimate business interest' basis like GDPR's, so every data field needs a consent or a Section 7 basis.

What does the DPDP Act require when there is a personal data breach?

There is no harm-threshold escape hatch. You must intimate the affected people and the Data Protection Board without delay, and send a detailed report to the Board within 72 hours, then remediate, find the root cause and retain the evidence.

How should consent work under the DPDP Act?

Treat consent as an architecture, not a checkbox: a plain-language notice (available in 22 languages), consent per purpose, a vault with receipts and version logs, and a withdrawal that switches off processing in every downstream system and processor. If marketing cannot switch off, consent is not done.

Can personal data be transferred outside India under the DPDP Act?

Generally yes, unless the destination country is restricted. DPDP uses a blacklist rather than GDPR-style adequacy decisions, but sector regulators can still require data to stay in India, so check sector rules as well.

Who is responsible when a vendor processes personal data for us?

You are. Under Section 8(1) the Data Fiduciary stays accountable for its Data Processor's acts, so every processor needs a data processing agreement, a place on your data-flow map, and a way to act on withdrawal and erasure.

Where should an organisation start with DPDP compliance?

In order: name one cross-functional owner, inventory personal data by purpose and lawful basis, build the consent architecture and plan re-consent, tier vendors and fix their agreements, then add the evidence layer and a breach playbook. The handbook advises not to buy another tool before the owner and inventory exist.

Is the DPDP Handbook free, and is it legal advice?

The interactive handbook is free to read and an HTML edition can be downloaded. It is for information only and is not legal advice; consult a qualified legal professional for compliance decisions.