The DPDP Handbook

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 TD
  HUB([SaaS / product company]) --> OWN[Fiduciary hat]
  HUB --> PROC[Processor hat]
  OWN --> U1[End-user accounts]
  OWN --> U2[Marketing / analytics]
  OWN --> U3[Support tickets]
  OWN --> U4[Employee / HR systems]
  PROC --> C1[Customer tenant data in product]
  U1 --> N[Sec 5 notice + per-purpose Sec 6]
  U2 --> N
  U3 --> N
  U4 --> N
  C1 --> DPA[Back-to-back DPA with customer]
  N --> SDK{SDKs / pixels / sub-processors?}
  SDK -->|Yes| MAP[DPA + data-flow map + breach SLA]
  SDK -->|No| VAULT[(Consent vault + version log)]
  MAP --> VAULT
  DPA --> VAULT
  VAULT --> SYS[CRM / ESP / ads / warehouse / product]
  SYS --> W{Withdrawal or DSR?}
  W -->|Yes| CAS([Cascade off every system + SDK])
  W -->|No| SYS
  class HUB,OWN,PROC,U1,U2,U3,U4,C1,N,MAP,DPA,SYS act;
  class SDK,W dec;
  class VAULT start;
  class CAS ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  HUB([Bank / NBFC / insurer / broker]) --> P1[KYC / AML / CKYC]
  HUB --> P2[Account / policy / loan]
  HUB --> P3[Payments / cards]
  HUB --> P4[Cross-sell / analytics]
  HUB --> P5[Collections / recovery]
  HUB --> P6[Employees / agents]
  HUB --> P7[Vendors: KYC SaaS / cloud / BPA]
  P1 --> B1[Sec 7 or mandated retention]
  P2 --> B2[Sec 6 consent for that product]
  P3 --> B2
  P4 --> B3[Fresh specific consent]
  P5 --> B1
  P6 --> B4[Employment notice + basis]
  P7 --> B5[DPA + Sec 8-2 chain]
  B1 --> REG[(Purpose + retention register)]
  B2 --> REG
  B3 --> REG
  B4 --> REG
  B5 --> REG
  REG --> CORE[Core / CRM / collections / vendors]
  CORE --> Q{Purpose ends or DSR?}
  Q -->|Law requires keep| KEEP([Retain that record class only])
  Q -->|Erase allowed| ER([Erase + notify processors])
  class HUB,P1,P2,P3,P4,P5,P6,P7,B1,B2,B3,B4,B5,CORE act;
  class Q dec;
  class REG start;
  class KEEP,ER ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

Health

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

flowchart TD
  HUB([Hospital / HealthTech / diagnostic chain]) --> CLIN[Clinical care data]
  HUB --> WORK[Workforce data]
  HUB --> CAMP[Campus / access data]
  HUB --> VEND[Vendor / partner data]
  CLIN --> ER[Emergency / trauma]
  CLIN --> IPD[IPD / admission / OT]
  CLIN --> OPD[OPD / clinics / teleconsult]
  CLIN --> PH[Pharmacy / formulary]
  CLIN --> DX[Labs / imaging / pathology]
  CLIN --> BILL[Billing / TPA / insurance]
  WORK --> EMP[Employees / doctors / nurses]
  WORK --> CON[Contract staff / residents]
  CAMP --> VIS[Visitors / attenders]
  CAMP --> CCTV[CCTV / biometric gates]
  VEND --> LAB[Outsourced labs / cloud HIS]
  VEND --> TPA[TPA / insurers / device vendors]
  ER --> B7[Sec 7 - treat first then notice]
  IPD --> B6[Sec 5 notice + purpose consent]
  OPD --> B6
  PH --> B6
  DX --> B6
  BILL --> B6
  EMP --> BHR[Employment notice + basis]
  CON --> BHR
  VIS --> BVIS[Visitor notice + short retention]
  CCTV --> BVIS
  LAB --> BDPA[DPA + breach SLA Sec 8-2]
  TPA --> BDPA
  B7 --> AGE{Patient under 18?}
  B6 --> AGE
  AGE -->|Yes| GUA[Verifiable guardian consent]
  AGE -->|No| REG[(Clinical + consent register)]
  GUA --> REG
  BHR --> REG
  BVIS --> REG
  BDPA --> REG
  REG --> SEC{Secondary use?}
  SEC -->|Research / AI / marketing| FRESH[Fresh consent OR anonymise]
  SEC -->|Care continuity only| KEEP([Stay within original purpose])
  FRESH --> REG
  REG --> DSR{DSR / discharge / retention end?}
  DSR -->|Yes| OUT([Erase or archive per clinical schedule])
  DSR -->|No| REG
  class HUB,CLIN,WORK,CAMP,VEND,ER,IPD,OPD,PH,DX,BILL,EMP,CON,VIS,CCTV,LAB,TPA,B7,B6,BHR,BVIS,BDPA,GUA,FRESH act;
  class AGE,SEC,DSR dec;
  class REG start;
  class KEEP,OUT ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

EdTech

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

flowchart TD
  HUB([School / EdTech / coaching / university]) --> L1[Learner accounts]
  HUB --> L2[Parent / guardian contacts]
  HUB --> L3[Teachers / staff HR]
  HUB --> L4[Visitors / campus CCTV]
  HUB --> L5[Vendors: LMS / payments / proctoring]
  L1 --> AGE{Age gate}
  AGE -->|Under 18| PAR[Verifiable parental consent]
  AGE -->|18+| STD[Standard Sec 6 consent]
  PAR --> RULES[No behavioural tracking]
  RULES --> ADS[No targeted ads to children]
  STD --> VAULT[(Consent + age register)]
  ADS --> VAULT
  L2 --> VAULT
  L3 --> HR[Employment notice + basis]
  L4 --> VIS[Visitor / CCTV notice]
  L5 --> DPA[DPA + sub-processor map]
  HR --> VAULT
  VIS --> VAULT
  DPA --> VAULT
  VAULT --> DEL[Deliver learning - minimal data]
  DEL --> END{Exit / graduate / withdraw?}
  END -->|Yes| CAS([Erase or restrict + cascade])
  END -->|No| DEL
  class HUB,L1,L2,L3,L4,L5,PAR,STD,RULES,ADS,HR,VIS,DPA,DEL act;
  class AGE,END dec;
  class VAULT start;
  class CAS ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

Mfg

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

flowchart TD
  HUB([Manufacturer / auto / FMCG / logistics]) --> S1[Employees / contractors]
  HUB --> S2[Visitors / plant CCTV]
  HUB --> S3[Biometric attendance]
  HUB --> S4[Dealer / distributor contacts]
  HUB --> S5[Warranty / service customers]
  HUB --> S6[IoT / connected-product telemetry]
  HUB --> S7[Vendors / 3PLs / cloud]
  S1 --> B1[Employment notice + basis]
  S2 --> B2[Visitor notice + short retention]
  S3 --> B3[Workplace notice + retention limit]
  S4 --> B4[B2B contact consent / contract]
  S5 --> B5[Product notice + purpose consent]
  S6 --> B6[Owner-linked consent + purpose]
  S7 --> B7[DPA + breach SLA]
  B1 --> REG[(Unified notice / consent register)]
  B2 --> REG
  B3 --> REG
  B4 --> REG
  B5 --> REG
  B6 --> REG
  B7 --> REG
  REG --> Q{DSR or purpose ends?}
  Q -->|Yes| OUT([Fulfil DSR / erase where lawful])
  Q -->|No| REG
  class HUB,S1,S2,S3,S4,S5,S6,S7,B1,B2,B3,B4,B5,B6,B7 act;
  class Q dec;
  class REG start;
  class OUT ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  DP([Data Principal]) --> CM[Consent Manager]
  CM -->|relay / withdraw| DF[Data Fiduciary]
  DP -->|direct consent / request| DF
  DF -->|"Sec 8-2 contract"| PR[Data Processor]
  PR --> ACC([Fiduciary still accountable - Sec 8-1])
  DF -.->|"if notified Sec 10"| SDF[SDF: DPO / DPIA / audit]
  SDF --> DPB[Data Protection Board]
  DPB ==>|complaints / penalties| DF
  class DP,CM,PR,SDF,DPB act;
  class DF start;
  class ACC note;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  A([Process personal data?]) --> B{Purpose lawful and specific?}
  B -->|No| X([Stop - do not collect])
  B -->|Yes| C{Fits Sec 7 legitimate use?}
  C -->|Yes| D([Proceed on Sec 7])
  C -->|No| E{Valid Sec 6 consent?}
  E -->|No| F[Serve Sec 5 notice + capture consent]
  F --> E
  E -->|Yes| G([Process only what is necessary])
  G --> H{Purpose done or withdrawn?}
  H -->|Yes| I([Erase under Sec 8-7])
  H -->|No| G
  class A,F,G act;
  class B,C,E,H dec;
  class D,I ok;
  class X stop;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  A([Touchpoint]) --> B["Sec 5 notice<br/>plain + 22 languages"]
  B --> C["Sec 6 granular consent<br/>per purpose"]
  C --> D[(Consent vault)]
  D --> E[Wire to CRM / ESP / ads / product]
  E --> F{Withdrawal?}
  F -->|Yes| G([Cascade off everywhere])
  F -->|No| E
  class A,B,C,E act;
  class D start;
  class F dec;
  class G ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 DSR outcome

Diagram 1

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

flowchart TD
  A([DSR filed]) --> B{Identity verified?}
  B -->|No| R[Ask for more info]
  R --> B
  B -->|Yes| C{Which right?}
  C -->|Access| D[Data summary + sharing list]
  C -->|"Correct / Erase"| E[Update / delete + notify processors]
  C -->|Grievance| F[Route to officer]
  C -->|Nominate| G[Record nominee]
  D --> H[Respond in published SLA]
  E --> H
  F --> H
  G --> H
  H --> I([Log outcome in DSR register])
  I --> J{Unsatisfied?}
  J -->|Yes| L([Escalate to Board])
  J -->|No| M([Closed - keep evidence])
  class A,D,E,F,G,H,R act;
  class B,C,J dec;
  class M ok;
  class L stop;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  A([Breach detected]) --> B[Contain and assess]
  B --> C["Intimate affected people<br/>without delay"]
  B --> D["Intimate Board<br/>initial - without delay"]
  D --> E["Detailed Board report<br/>within 72 hours"]
  C --> F[Remediate + root cause]
  E --> F
  F --> G([Retain evidence 1 year plus])
  class A stop;
  class B,C,D,F act;
  class E dec;
  class G ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  A([User signs up]) --> B{Under 18?}
  B -->|No| N([Normal consent flow])
  B -->|"Yes / Unknown"| C[Verifiable parental / guardian consent]
  C --> D[No behavioural tracking]
  D --> E[No targeted ads to children]
  E --> F[Nothing harmful to wellbeing]
  F --> G([Proceed within limits])
  class A,C,D,E,F act;
  class B dec;
  class N,G ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

SDF

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

flowchart TD
  A([Notified as SDF?]) -->|Yes| B[Appoint India-based DPO]
  B --> C[Independent data auditor]
  C --> D[Periodic DPIA + audits]
  D --> E([Other govt measures])
  A -->|Not yet| F([Still carry full base DPDP duties])
  class A dec;
  class B,C,D act;
  class E,F note;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  A([Transfer outside India?]) --> B{On restricted list?}
  B -->|Yes| X([Do not transfer there])
  B -->|No| C{"Sector localisation?<br/>e.g. RBI"}
  C -->|Yes| D([Follow stricter sector rule])
  C -->|No| E([Transfer OK - duties travel with data])
  class A act;
  class B,C dec;
  class X stop;
  class D,E ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 TD
  A([Day 0]) --> B["Name one owner<br/>Legal+Product+Mkt+Ops+Eng+HR"]
  B --> C[Inventory by purpose + basis]
  C --> D["Consent architecture<br/>+ re-consent"]
  D --> E[Tier vendors / fix DPAs]
  E --> F([Evidence layer + breach playbook])
  class A start;
  class B,C,D,E act;
  class F ok;
  classDef start fill:#DBEAFE,stroke:#2563eb,color:#0f172a;
  classDef act fill:#EFF6FF,stroke:#3B82F6,color:#1e3a8a;
  classDef dec fill:#FEF3C7,stroke:#D97706,color:#78350f;
  classDef ok fill:#D1FAE5,stroke:#059669,color:#064e3b;
  classDef stop fill:#FEE2E2,stroke:#DC2626,color:#7f1d1d;
  classDef note fill:#F1F5F9,stroke:#64748B,color:#334155;

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 DSR 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.