DPDP Knowledge Hub: Practitioner Guides on Consent, Breach and Vendors

The minimum content checklist

Under Section 5(1) of the Act and Rule 3 of the DPDP Rules, your privacy notice must include:

1. An itemised list of every category of personal data you collect
2. An itemised list of every purpose for which you process that data
3. The manner in which the Data Principal can withdraw consent — with parity to how it was given
4. The manner in which they can exercise their rights under Sections 11-14
5. The manner in which they can lodge a complaint with the Data Protection Board

Why itemisation matters

'We collect personal information for service delivery' is not itemisation. The bar is closer to: 'We collect: (a) name, (b) mobile number, (c) email address, (d) device identifier, (e) location coordinates when you use our app.' Each item must be specific enough that a Data Principal can recognise it as something they have, in fact, given you.

Same standard for purposes: 'to provide the service' is too vague. 'To process your order, send delivery updates by SMS, and answer customer-support queries' is closer.

Withdrawal parity

If consent was given by ticking a checkbox at signup, withdrawal must be at least as easy — typically a one-click toggle in account settings. If consent was given via a cookie banner, withdrawal must be available through the same banner (or a clear equivalent). The clearest test: can a non-technical user withdraw consent in under 30 seconds without contacting support?

Languages

Section 5(3) requires the notice to be available in English plus the 22 Eighth Schedule languages on request. The Rules clarify that on most digital surfaces, 'on request' means a language-selector control. Best practice: detect the user's language and show the matching version by default.

What a compliant notice looks like

You can see our Privacy Notice Template (Template 01 in our library) for a fully worked example. The structure works in three layers: short summary at the top, itemised tables in the middle, contact and rights mechanics at the bottom.

The six lawful bases under Section 7

Section 7 of the DPDP Act describes six 'legitimate uses' for which a Data Fiduciary may process personal data without obtaining explicit consent under Section 6:

1. Section 7(a) — Voluntary provision: where the Data Principal has voluntarily provided their personal data for a specified purpose, and has not indicated that they do not consent.
2. Section 7(b) — State processing: where the State or its instrumentality processes for providing or issuing subsidies, benefits, services, certificates, licences or permits.
3. Section 7(c) — Statutory compliance: where processing is required for compliance with any law, judgment, or order.
4. Section 7(d) — Medical emergency: where processing is required to respond to a medical emergency involving threat to the life or health of any person.
5. Section 7(e) — Disaster / public health: where processing is required for measures during a disaster or breakdown of public order.
6. Section 7(g) — Employment: where processing is for purposes of employment, including for safeguarding the employer from loss or liability.

The under-use problem

Many teams insist on consent for processing that is clearly within Section 7(a) voluntary provision — like processing the email a customer typed into a contact form, or processing the address typed into a checkout. The result is consent fatigue (banners on banners), which itself violates the spirit of Section 6 (consent must be free).

The over-use problem

The opposite is more common and more dangerous. Marketing teams claiming Section 7(a) for sending promotional emails because the user 'voluntarily provided' their address at signup — when the user provided it for account creation, not marketing. Section 7(a) does not extend to processing for purposes other than the one for which the data was provided.

How to choose

The basis-selection test we use with clients:

1. Is processing strictly necessary for the service the user requested? → 7(a) voluntary provision
2. Is processing required by a specific law, judgment or order? → 7(c) statutory
3. Is the user being asked to opt-in to something beyond the core service? → S.6 consent
4. None of the above? → reassess whether you should be processing at all

Pillar 1: Granularity

Each purpose needs its own consent. A single 'I accept the privacy policy' checkbox covering account creation, marketing, behavioural analytics, third-party sharing and cookie-based tracking will not survive Section 6 scrutiny. The user must be able to opt into account creation while opting out of marketing. They must be able to opt into newsletter while opting out of promotional SMS.

The minimum granularity we recommend: account/service consent, marketing channel-by-channel (email / SMS / push / WhatsApp), behavioural analytics, third-party sharing categorised by partner type. Five distinct switches, not one mega-switch.

Pillar 2: Withdrawal parity

Withdrawal must be 'as easy as giving' — same channel, same number of steps, same effort. If consent was a one-click toggle, withdrawal must be a one-click toggle. If consent was given by SMS opt-in (STOP keyword), withdrawal via the same STOP keyword must work. Hiding withdrawal three menus deep, or requiring email-to-support, is non-compliant.

Test: time how long it takes a non-technical user to withdraw a specific consent. If it's more than 30 seconds, your design is non-compliant.

Pillar 3: Dark pattern avoidance

The Rules don't use the term 'dark pattern' but Section 6's requirements (free, specific, informed, unconditional, unambiguous) create the same effect. Patterns to avoid:

• Pre-checked consent boxes
• 'Accept all' as a prominent button with 'Reject all' hidden in a sub-menu
• Coloured 'Accept' buttons against grey 'Reject' buttons
• Repeated re-prompts after the user has rejected
• 'Continue with limited features' framing that implies degraded service for refusing optional consents
• Bundling unrelated purposes into a single switch

Pillar 4: The audit trail

You must be able to evidence consent on demand. The minimum log entry per consent event:

• Hashed Data Principal identifier
• Timestamp (UTC + IST)
• Channel (web, app, in-call, SMS, paper)
• Purpose code
• Notice version shown
• Outcome (granted, denied, withdrawn)

Store the log for at least the lifetime of the relationship plus your retention period. A consent record without a notice version is significantly weakened — the version is what proves what the user was actually told.

The reference design

Our Consent UX Spec (Template 03) provides a full reference architecture covering the banner, the granular modal, the preference centre, the audit JSON schema, and the API contract. Use it as a starting point and adapt to your stack.

The five stages

Every operational DSAR programme has the same five stages, however differently they're labelled:

1. Intake
2. Identity verification
3. Discovery and dependency mapping
4. Response drafting and approval
5. Delivery and audit

Stage 1: Intake

Multiple intake channels — web form, in-app self-service, email, customer support escalation, postal — all converge into a single ticket queue with a unique reference number. The reference is the Data Principal's tracking ID and your case ID throughout.

Capture at intake: which right is being exercised (access / correction / erasure / grievance), the Data Principal's stated identifier (email, account ID), the date received, and any context they've provided.

Stage 2: Identity verification

You must verify the requester is the Data Principal. Verification approaches in order of strength:

• Authenticated session (request made while logged in)
• Multi-factor verification (OTP to registered phone or email)
• Knowledge-based questions (last transaction, registered address)
• Document-based verification (Aadhaar offline KYC, DigiLocker)

Match the verification standard to the sensitivity of the data involved. Erasure of a marketing list entry needs less than erasure of a financial transaction history.

Stage 3: Discovery and dependency mapping

The single biggest cause of failed DSAR responses: the team forgot a system. The user lives in your CRM, your support helpdesk, your marketing automation tool, your analytics platform, your data warehouse, your backups — and possibly in your processors' systems.

Maintain a dependency map (per RoPA) of every system that may hold Data Principal data. The DSAR workflow walks every system on the list, collects findings, and consolidates.

Stage 4: Response drafting and approval

For complex requests, the response includes:

• What data we hold (categories and sources)
• The purpose for each category
• Whether the request can be fulfilled in full, in part, or refused
• The reasons for any partial refusal (e.g., statutory retention)
• The next-step the Data Principal can take if dissatisfied (escalation to Grievance Officer, then DPBI)

Privacy / DPO approval before sending. Legal sign-off for refusals.

Stage 5: Delivery and audit

Deliver via the channel the Data Principal requested (or their registered channel by default). Log the delivery. Close the case with full audit trail. Use Template 10 (DSAR Tracker) for a worked spreadsheet that automates the SLA calculation and RAG status.

The 90-day SLA

Rule 14(3) caps the response at 90 days. This is a ceiling, not a target. Mature programmes target 14-30 days for routine access requests, longer for complex erasure or correction. Track your distribution — if you're consistently above 60 days, your operational design is the problem.

From detection to notification: the four phases

Phase 1: Detection (T+0 to T+2 hours)

What triggered awareness: alert from monitoring, vendor disclosure, customer complaint, journalist inquiry, regulatory contact? Each requires different early-stage handling. Containment is the immediate priority — kill the access vector, isolate affected systems, preserve evidence.

Phase 2: Triage (T+2 to T+12 hours)

Cross-functional incident response team convenes (technical, legal, comms, business owner, exec sponsor). Initial scope assessment: which data, how many records, what attack vector. Severity classification: is this notifiable? The DPDP threshold is broad — any 'personal data breach' that is 'unauthorised processing' or 'accidental disclosure' triggers Section 8(6).

Phase 3: Notification (T+12 to T+72 hours)

If notifiable, two distinct notifications must go out without delay:

• To the Data Protection Board of India: detailed report per Rule 7 — nature of breach, categories and approximate number of records, likely consequences, measures taken.
• To each affected Data Principal: clear, plain-language notice — what happened, what data, what steps they should take, who to contact for help.

'Without delay' is not 72 hours. The 72-hour figure is GDPR — DPDP doesn't specify but enforcement expectations are likely to be similar. Don't wait for full investigation; send an initial notification with what's known, and update as more is established.

Phase 4: Containment, recovery, lessons (T+72 hours onwards)

Full forensic investigation, root-cause analysis, remediation plan, regulatory follow-up, customer communications, post-incident review. The post-incident review is critical — it's the evidence of 'reasonable measures' that limits liability under Section 8(5).

The communication choreography

Pre-prepared notification templates (use Template 05) save 6+ hours during a real incident. Templates should include placeholders for incident-specific data, but the structure, tone and required elements should be locked.

Internal communications: an established escalation tree, with backups for every primary contact. War-room channel established at T+0.

The decision authorities

Document who has authority to: declare an incident, escalate to the Board, initiate notification, agree settlement of any subsequent claim, communicate publicly. These decisions cannot be made for the first time during the incident.

The runbook

Template 04 (72-Hour Breach Runbook) is our 25-page reference covering all six phases (T+0 through T+30), with role-specific checklists, severity classification, decision trees and tabletop scenarios. Read it before you need it.

The collision points

BFSI institutions operate under multiple regulators. DPDP doesn't replace any of them — it overlays. The friction is most acute at three points:

1. KYC retention vs DSAR erasure

RBI's Master Direction on KYC requires 5-year retention from the end of the customer relationship. PMLA Section 12 also requires 5-year retention. A customer requesting erasure cannot have their KYC erased before this period — but you must explain this clearly in your DSAR response, not refuse silently.

Best-practice response template: 'Per [law], we are required to retain [category] for [period] from [trigger]. We have erased the data we are not required to retain — namely [list]. The remaining data is held only for the statutory purpose and is not accessible for any other use.'

2. Payment data localisation

RBI's payment-system data localisation directive (2018) requires payment data to be stored only in India. DPDP Section 16, by contrast, currently permits cross-border transfer except where the Central Government issues a country-restriction notification. Where they overlap (payment data of Indian users), the RBI rule is stricter — comply with that.

The point of confusion: many BFSI teams treat the RBI localisation as if it were a DPDP requirement. It's not. They are independent. If a future MeitY notification under Section 16 restricts non-payment data, that is an additional obligation, not a substitute.

3. Breach notification race conditions

For a single breach, you may face concurrent notification obligations:

• CERT-In: 6 hours (under the 28 April 2022 Directions)
• RBI: per Master Direction on Information Security (varies by entity type)
• IRDAI / SEBI: per sectoral cyber-security guidelines
• DPDP: 'without delay' to the DPBI and to affected Data Principals

Without an integrated playbook, the notifications go out at different times, with different scope, with different language — and can contradict each other. The simplest defence: a single incident-management process that produces all required notifications from a shared incident record.

The SDF question

Almost every meaningful BFSI institution should expect SDF designation when criteria are notified. Volume + sensitivity + sectoral exposure + sovereign-interest factors all push in that direction. Build the additional Rule 13 obligations (DPIA programme, audit cycle, India-resident DPO with board reporting) into your roadmap on the assumption that you'll be designated.

The Account Aggregator question

If you're an FIU under the AA framework: your AA-mediated data sharing is consent-based under RBI rules. Layer DPDP Section 6 requirements on top — granularity per purpose, withdrawal parity, audit trail. Many AA implementations capture the RBI consent without the DPDP elements.

The central misconception

'We're ABDM-compliant, so we're DPDP-compliant.' We hear this in every healthcare engagement. It is not correct.

NDHM and ABDM consent governs data sharing under the ABDM ecosystem. DPDP consent (Section 6) governs your processing of personal data within your facility. They overlap but neither is a substitute for the other.

Where they align

The principles are aligned: granular, purpose-limited, time-bounded consent. ABDM consent expressions (purpose, data categories, expiry) map fairly cleanly onto DPDP consent requirements. Where you've built ABDM consent flows, you're likely 70% of the way to DPDP-compliant flows for the same data.

Where they diverge

Three significant divergences:

• Scope: ABDM covers data shared via ABDM. DPDP covers all personal data you process. A patient's appointment booking data is DPDP scope but not ABDM scope.
• Withdrawal parity: ABDM consent withdrawal is via the ABDM consent manager. DPDP requires withdrawal parity with the channel of giving — your facility must offer it directly.
• Children's data: ABDM has paediatric consent flows. DPDP Section 9 + Rule 10 raises the bar — verifiable parental consent is required, not just parental signature.

The retention puzzle

You face multiple retention drivers:

• Clinical Establishments Act / state rules: 3-5 years post-discharge minimum
• NMC Regulations on Medical Records: 3 years indoor, longer for surgical / oncology
• PCPNDT Act: specific obligations for diagnostic centres
• D&C Rules: Schedule H prescription records
• NABH (where applicable): per accreditation chapter
• DPDP: erasure on request unless statutorily required to retain

The right way to handle this: a single retention schedule (Template 15) that maps each data category to the strictest applicable retention obligation, with the legal source explicitly recorded. Use it as the master reference for DSAR responses.

The HealthTech app variant

If you're a HealthTech app — telemedicine, fitness, mental health — most of the above applies. Plus: most users will be adults but a meaningful minority will be parents using the app on behalf of children. Section 9 applies to that minority. Build the verifiable parental consent flow even if the majority of users won't need it.

The bar Rule 10 sets

Section 9 of the Act requires Data Fiduciaries to obtain verifiable parental consent before processing the personal data of children (anyone under 18). Rule 10 specifies what 'verifiable' means — and the answer is: a reliable mechanism to confirm both that the consenting individual is a parent AND that they consent.

Self-declared age gates ('Are you 18 or over?') do not meet this bar. They were never sufficient under any privacy regime that takes children's data seriously, and they certainly don't meet Rule 10.

Why this is hard

The technical problem: how do you verify parental status of someone you've never met, on a device that may be the child's? The legal problem: parental consent isn't enough — you must also avoid 'tracking, behavioural monitoring or targeted advertising' of children, regardless of consent.

Four architectures we've seen work

1. DigiLocker-mediated

The parent authenticates via DigiLocker, providing identity proof and age. Their declaration of relationship to the child is captured. This is the cleanest approach for Indian users — DigiLocker has high trust, the identity is government-issued, the friction is acceptable. Recommended as primary path.

2. Aadhaar offline KYC

The parent shares an Aadhaar offline KYC artefact (PDF or QR), which establishes their identity. Combined with a declaration of parenthood, this satisfies Rule 10. Friction is moderate; technical integration is well-documented.

3. Payment-instrument verification

The parent makes a token transaction (₹1, refunded) from a verified payment instrument linked to their PAN. This proves adult identity (KYC at the bank) and consent. Useful for paid services where payment is happening anyway.

4. Document-upload + manual review

The parent uploads ID and a relationship document (school records, passport with parent name, etc.). Manual review by a trained team. High friction, high cost — only viable for low-volume premium services.

The 'no behavioural targeting' rule

Section 9 prohibits tracking, behavioural monitoring or targeted advertising of children. This is absolute, not consent-curable. Even with parental consent, you cannot:

• Run behavioural-personalisation engines on a child user's session
• Send retargeting messages based on their browsing
• Build lookalike audiences from child user data
• Use heatmaps that capture child user behaviour

The implementation: hard-disable analytics SDKs, marketing pixels, and personalisation engines for users identified as under-18. Add child-segment exclusions to all marketing systems. This is a substantial engineering project — start it now.

The age-transition problem

When a user turns 18, consent shifts from parent-mediated to direct. Your data model must support this. Mature implementations:

• Track user age and trigger re-consent at 18
• Offer the user (now adult) the choice to retain or delete their childhood data
• Lift behavioural-targeting restrictions
• Notify parents of the transition (if they've been managing the account)

Few EdTech platforms in India have built this. It's the next frontier.

The scope problem

Most organisations underestimate vendor scope by 3-5x. The 'official' vendor list maintained by procurement covers maybe a third of the actual processors. The rest are tools onboarded by individual teams, point integrations bought without procurement, free tiers of SaaS used by departments, contractor-introduced sub-vendors.

A typical mid-sized B2C company has 80-150 processors when fully inventoried. A typical B2B SaaS company has 30-80. Both will count 20-30 in their 'official' list at the start of the exercise.

The sequencing

You cannot remediate everything at once. The right sequencing for a 12-month programme:

Months 1-2: Discovery

Survey every team. Audit network egress, OAuth apps, expense reports for SaaS subscriptions, payment-aggregator transaction lists. The output: a complete vendor inventory.

Months 2-4: Triage

Categorise vendors by risk (data sensitivity × volume × criticality). Top tier: 10-20 vendors holding the largest, most sensitive data sets. These get the deep DPA, full security review, and on-site audits if material.

Months 3-9: Top-tier remediation

Update DPAs with top-tier vendors. Vendor DDQ (Template 08) for each. Document sub-processor flow-down, breach attribution, indemnity. Average cycle time per top-tier vendor: 4-8 weeks of legal-and-procurement back-and-forth.

Months 6-12: Mid-tier

Standard DPA addendum to mid-tier vendors. Lighter DDQ. Done in batches of 5-10 at a time.

Months 9-12: Long tail

For low-tier vendors (low data sensitivity, low volume), a simpler approach: a one-page DPDP attestation, a clickwrap DPA, or a contract clause referencing your standard terms. Minimise legal cycle time on what is genuinely low-risk.

The Master DPA

Template 07 in our library is a 14-clause Master DPA aligned to Section 8(2). It covers purpose limitation, security, breach notification, sub-processors, audit rights, return / destruction on termination, and the supporting schedules. Use it as your baseline for top-tier remediation.

The processor inventory artefact

Maintain a single processor inventory: vendor name, categories of personal data, purpose, sub-processors known to you, DPA status (signed / pending / expired), DDQ score, last-reviewed date. This is the artefact a regulator will ask for first when investigating any breach involving a processor.

The 'no DPA, no go-live' policy

For new vendor onboarding, the simplest control: no DPA, no production access. Make the procurement gate the enforcement point. This stops the inventory from growing faster than you can remediate it.

The criteria

Section 10(1) of the Act allows the Central Government to designate Significant Data Fiduciaries based on:

• Volume and sensitivity of personal data processed
• Risk to the rights of Data Principals
• Potential impact on the sovereignty and integrity of India
• Risk to electoral democracy
• Security of the State
• Public order

What this means in practice

The criteria are deliberately open-ended. The Government has not yet (as of late 2025) issued a formal threshold notification, but the criteria suggest several categories of organisation are highly likely candidates:

• Large BFSI institutions (volume + sensitivity + sectoral)
• Healthcare and HealthTech (sensitivity + risk to rights)
• Telecommunications (volume + sovereignty)
• Major social platforms (volume + electoral democracy)
• Major e-commerce / D2C platforms (volume)
• Major fintech (volume + sensitivity + sectoral)
• Aadhaar-linked service providers (sensitivity + sovereignty)

Why pre-prepare?

Once designated, the Section 10 obligations apply with limited transition. Rule 13 specifies:

• DPIA before processing involving 'high risk to the rights of Data Principals'
• Annual independent audit by an empanelled auditor
• India-resident Data Protection Officer
• The DPO must report to the Board (or equivalent governing body)
• Periodic risk assessment

Building these from scratch — particularly the audit cycle and the DPO function with board-reporting — takes 6-12 months. If you're notified in (say) Q3 2027 with a 6-month transition, and you haven't prepared, you'll miss the deadline.

The pre-preparation checklist

1. Self-assess against the criteria (we've published guidance on this — see the SDF Classifier in our Tools section)
2. If likely SDF: appoint an India-resident DPO with board reporting line. Use Template 13 for the role description.
3. Stand up a DPIA programme. Run your first DPIA on the highest-risk processing activity. Use Template 12.
4. Identify and pre-engage an audit firm (one that will be empanelled when the Government publishes the panel)
5. Establish quarterly board reporting on DPDP risk. Use Template 16 for the board pack format.
6. Document everything. The audit, when it comes, will examine whether the obligations were operationalised — not just declared.

If you're definitely not SDF

Even non-SDFs benefit from running a DPIA on high-risk processing, having a designated DPO, and reporting to the Board. The disciplines are valuable; only the legal obligation differs.

The current regime

Section 16 of the DPDP Act is — by international standards — permissive. It says the Central Government may, by notification, restrict the transfer of personal data outside India to specified countries or territories. Default position: transfer is permitted. Restriction requires a specific notification.

This is materially different from the 2019 PDP Bill, which contained extensive cross-border restrictions. The Act, as enacted, makes restriction the exception.

The future regime

Several factors point toward future restrictions:

• Reciprocity considerations — countries with restrictive regimes (China) may attract Indian restrictions
• Sovereign-interest data categories (defence, critical infrastructure)
• SDF-specific obligations under Rule 13(4) — the Government can require certain personal data of SDFs to remain in India

Entities should plan on the assumption that some categories of data, for some classes of fiduciary, will be subject to localisation or transfer restriction at some future date.

The mapping exercise

Whatever the current regime, you need a complete map of your cross-border personal data flows. The map should record:

• Source system (which application, in which country, generates the data)
• Destination system (which application, in which country, receives the data)
• Categories of personal data transferred
• Purpose of transfer
• Data Fiduciary at source, Processor / Data Fiduciary at destination
• Legal basis for the transfer (consent, contract, legal obligation)
• Volumes (records per quarter)

Quick wins

While you're mapping, address the obvious risks:

• SaaS tools storing Indian customer data in non-Indian regions where an Indian region is offered — switch to the Indian region
• Analytics platforms aggregating Indian user behavioural data into global instances — investigate region restrictions or anonymise pre-transfer
• Backup destinations outside India — assess and document

The processor question

Many cross-border 'transfers' are actually processor-to-processor. The Data Fiduciary remains in India; the Processor (e.g., a cloud provider's US-based analytics service) processes outside. Section 16 still applies to this. Your DPA must address it.

The institution

The Data Protection Board of India (DPBI) is the regulator established under Sections 18-26 of the DPDP Act. As of late 2025 it has been formally constituted but is not yet fully operational. When fully operational, it becomes the central enforcement forum for the entire framework.

Composition

The Board comprises a Chairperson and other Members. The Government's emphasis on technical and legal expertise suggests members will include senior judges, regulators, and technologists. Tenure is two years, renewable.

Powers

The Board has wide powers:

• Inquire into breaches and other contraventions
• Direct urgent remedial measures
• Impose penalties up to the caps in the Schedule (₹250 Cr maximum for security failures)
• Issue directions to Data Fiduciaries
• Conduct proceedings as a digital office (significant — it's designed to operate online)

Procedural model

The Board is intended to be a digital-first regulator. Filings, hearings, evidence presentation — all conducted online. This is a deliberate choice for accessibility and speed; it also means your evidence-handling processes need to support digital production from day one.

Penalties are civil only. The DPDP Act does not create criminal offences (a notable departure from the IT Act). All proceedings result in directions and / or monetary penalties.

Appeal route

Appeals from the DPBI go to the Telecom Disputes Settlement and Appellate Tribunal (TDSAT) within 60 days of the order. From TDSAT, further appeal is to the Supreme Court on questions of law.

This route — DPBI → TDSAT → SC — is faster than the typical Indian regulatory ladder (regulator → High Court → SC). It's intended to enable a body of jurisprudence to develop quickly.

What to prepare

• Designate a single point of contact for DPBI inquiries — typically the DPO or Grievance Officer
• Document your decision-making for any contested processing — the audit trail matters more than the original decision
• Maintain the evidence chain for consent capture, security implementation, breach response. The Board will work from the documentary record.
• Test your incident-response process to ensure it produces Board-ready notification artefacts under time pressure

Early enforcement priorities

Speculative but informed by Government statements and analogous regulators globally:

• Notification compliance (did you actually report when you should have?)
• Children's data (Section 9) — high political salience
• Vendor and processor flow-down (Section 8(2)) — a high-leverage point
• Cross-border transfer compliance for SDFs once classified

The structure

The Schedule of Penalties to the DPDP Act caps civil penalties. There are no criminal offences in the Act — a deliberate departure from the IT Act. The caps:

• ₹250 crore — failure to take reasonable security safeguards (Section 8(5))
• ₹200 crore — failure to give breach notice to the Board / Data Principal (Section 8(6))
• ₹200 crore — failure to fulfil children's-data obligations (Section 9)
• ₹150 crore — failure of Significant Data Fiduciary additional obligations (Section 10)
• ₹50 crore — failure of any other duty
• ₹10,000 — failure of any Data Principal duty (Section 15) per instance

How the Board applies them

Section 33 lists the matters the Board takes into account when determining penalty quantum:

• Nature, gravity, duration of contravention
• Type and nature of personal data affected
• Repetitive nature
• Whether unjust enrichment
• Whether voluntary remediation
• Disproportionate impact on the contravener
• Effect on public

The cap is the ceiling, not the floor. Smaller, less-serious contraventions attract smaller penalties.

The compounding question

Multiple contraventions arising from a single incident can attract multiple penalties. A breach involving children's data, with delayed notification, processed by an SDF, with security inadequacies — could in principle attract penalties under Sections 8(5), 8(6), 9 and 10 simultaneously. Maximum theoretical exposure: ₹800 crore.

How to limit exposure

The factors most directly within your control:

1. Reasonable measures: Section 8(5) penalises failure of security. Demonstrating a documented, evidenced security programme (Rule 6 controls implemented, audited, reviewed) limits exposure even if a breach occurs.
2. Notification discipline: Section 8(6) penalises non-notification. Pre-built playbook, pre-drafted templates, designated decision-makers — all reduce the risk of late or non-notification.
3. Voluntary remediation: Self-disclosed contraventions, with documented remediation, attract reduced penalties.
4. Children's-data programme: Section 9 carries one of the highest caps. The single most leveraged investment is the verifiable parental consent flow plus marketing-system child-exclusion.
5. Vendor flow-down: Section 8(2) makes you liable for processor failures. Strong DPAs and a vendor-DDQ programme limit this.

The board-pack view

For board-level reporting, present penalty exposure as: maximum theoretical exposure (sum of relevant caps) versus your residual exposure after current controls. Use Template 16 for the format. The trend in residual exposure over quarters is the most useful single metric.

Phase 1 — Now

Phase 1 is the current state. The Act is in force. The Rules are notified (13 November 2025, G.S.R. 846(E)). The DPBI is constituted. The basic framework — duties, lawful basis, security, breach notification, rights — is technically applicable.

What should already be operational:

• DPDP-compliant Privacy Notice
• Consent capture aligned to Section 6 + Rule 3
• Security baseline aligned to Rule 6
• Breach response capability per Rule 7
• DSAR fulfilment workflow with the 90-day SLA tracking
• Grievance officer published
• Vendor DPAs aligned to Section 8(2)

If your programme isn't here, you're behind.

Phase 2 — ~November 2026

Phase 2 brings the Consent Manager ecosystem live. Consent Managers are intermediaries that aggregate, manage and revoke consents on behalf of Data Principals. The framework is in Rule 4 of the DPDP Rules.

This matters for:

• Businesses that intend to operate as Consent Managers — registration with DPBI, technical and operational standards
• Businesses that will integrate with Consent Managers — APIs, consent-record formats, withdrawal handling
• Account Aggregator-related businesses — the AA framework will need DPDP harmonisation

Phase 3 — 13 May 2027

Phase 3 is the crystallisation date for substantive obligations. Two years from notification of the Rules. By this date:

• Significant Data Fiduciaries are notified (or notification is imminent)
• The full Section 10 + Rule 13 obligations apply for SDFs
• Penalty enforcement reaches steady state
• The grievance-and-appeal machinery is operational at scale
• Annual audit cycles for SDFs are running

Substantive programmes that will take 12-18 months to build (RoPA, DPIA cycle, vendor remediation across 50+ processors, automated DSAR portal, encryption uplift) need to be in flight by mid-2026 to be production-ready by Phase 3.

The trap

The most common strategic error: treating 13 May 2027 as the start date and pacing accordingly. It's the deadline. A programme paced for the deadline misses the deadline by 6-12 months.

Pace for completion in Q4 2026. Use Q1-Q2 2027 for testing, audit, board sign-off and continuous improvement. Don't ship to the deadline.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

The DPDP Act is not an Indian copy of GDPR. It shares the vocabulary of notice, consent, rights and breach reporting, but it drops legitimate interests, sensitive data categories and the one-month DSAR clock, and it replaces turnover-based fines with fixed rupee caps of up to Rs 250 crore. An Indian mid-market firm with a GDPR programme for EU customers can reuse roughly a third of its artefacts as they stand, must rewrite a third, and needs to build the rest. This page sets out the 15 differences in one table, then sorts your GDPR artefacts into reuse, rewrite and build-new lists.

Is DPDP same as GDPR? Why the short answer is no

Many Indian firms serving EU customers assume that “GDPR compliant” means “DPDP covered”. In our reading that is the most expensive assumption a compliance lead can make this year.

The two laws share a lineage: a controller-style entity (controller, data fiduciary), a processor, an individual (data subject, data principal) and a regulator. Both require notice, access and correction rights, security safeguards and breach reporting.

The similarity stops at the architecture. GDPR is a broad, principle-driven regulation with six lawful bases and a large body of guidance. The DPDP Act is narrower and more prescriptive: it applies only to digital personal data, it recognises consent plus a closed list of “legitimate uses” under Section 7, and it leaves detail to the DPDP Rules, 2025 (notified November 2025) and future notifications. If you are new to the Indian framework, start with our DPDP 101 explainer.

Timing matters. Most substantive DPDP obligations become enforceable in May 2027, 18 months after the Rules were notified, with consent manager provisions at 12 months. That is the window for closing the gap.

DPDP Act vs GDPR differences: the 15-row comparison

The table below is the core of this page. Use the reuse, rewrite and build-new lists that follow to plan the work.

Row 11 is covered in our cross-border transfer guide. Two other rows deserve attention. Row 5 is where most GDPR programmes depend structurally on a mechanism DPDP does not offer. Row 9 is where an EU-tuned runbook will make you late, because DPDP requires you to tell affected individuals without delay rather than after a risk threshold is crossed. Our 72-hour breach response article walks through the Indian sequence, including how the CERT-In six-hour direction sits alongside it.

GDPR compliant company, DPDP India obligations: what changes in practice

Consider a Bengaluru SaaS company with 300 staff, EU enterprise customers and a GDPR programme built in 2019.

Lawful basis remapping

Its ROPA lists 42 activities: nineteen on “contract”, eleven on “legitimate interests”, nine on consent, three on legal obligation. Some contract entries fit “voluntary provision” under Section 7, but the marketing and analytics entries fit no Section 7 head and need consent under Section 6. That consent must be free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it, which rules out bundled consents copied from a cookie banner. Our Section 7 lawful basis explainer shows the mapping activity by activity.

Children’s data

The company runs a student edition used by some 17-year-olds, with a GDPR age gate at 16. Under Section 9 it needs verifiable parental consent for anyone under 18 and must switch off tracking and targeted advertising for that cohort. Penalty exposure for getting this wrong is up to Rs 200 crore.

Breach response

The GDPR runbook has a gate: assess risk, notify the authority within 72 hours, notify individuals only if the risk is high. The DPDP runbook has no gate for individuals. Intimation to affected data principals and to the Board goes out without delay, and a detailed report reaches the Board within 72 hours. In parallel, listed cyber incidents go to CERT-In within six hours.

Significant Data Fiduciary exposure

If notified as an SDF, the company must appoint an India-based DPO, engage an independent data auditor and run periodic DPIAs. Its EU-based DPO does not satisfy the residency requirement. Use the SDF Classifier tool to test whether your profile is likely to fall into scope.

DPDP GDPR mapping: artefacts you can reuse as-is

These carry across with little more than updated legal references.

Data inventory and data flow maps. What you hold, where it flows and who touches it does not change with the law. Add a digital-or-paper column, since only digital personal data is in DPDP scope.

Information security policies and controls. Encryption, access control, logging and monitoring, and backups are the DPDP Rules’ reasonable security safeguards almost verbatim. Confirm log retention meets the one-year DPDP floor and the CERT-In 180-day in-India requirement.

Vendor due diligence questionnaires. Add one question: can the vendor support “without delay” breach intimation?

Training on privacy fundamentals and governance structure. Purpose limitation, minimisation and need-to-know apply equally; only legal references and penalty slides change. Steering committees and escalation paths continue unchanged. See our DPDP training options for India-specific modules.

DPDP GDPR mapping: artefacts you must rewrite

These share a purpose with their DPDP equivalent but their content would fail an Indian audit.

Privacy notices and consent flows. Section 5 requires notice of the data processed, the purpose, how to exercise rights and how to complain to the Board. GDPR notices are longer, mention legitimate interests and cite EU authorities. A Section 5 notice should be shorter, purpose-specific and issued with or before the consent request. Consent flows need withdrawal as easy as consent and purpose-specific ties; rebuild rather than patch.

Records of processing. Keep the structure; rewrite the lawful basis column to Section 6 or 7 heads, add the retention trigger (erasure when purpose is served or consent withdrawn) and flag children’s data.

Processor agreements. An Article 28 DPA is a good skeleton. Add breach intimation aligned to “without delay”, cooperation with the Board, and a statement that the fiduciary remains responsible regardless of the processor. Our vendor remediation guide lists the clauses most often missing.

Breach runbook. Rebuild around three clocks: CERT-In six hours, DPDP “without delay” intimation, and the 72-hour detailed report to the Board. Remove the risk gate for individual notification.

DSAR procedure. Publish your response period (up to 90 days), add nomination requests, drop portability for India-only data, and route grievances to a named Section 8 contact before they reach the Board. The DSAR workflow article provides a template process.

Penalty and risk register. Replace turnover-percentage exposure with the fixed Schedule caps; the Penalty Exposure Estimator gives a rupee figure for board reporting.

DPDP GDPR mapping: artefacts you must build new

These have no GDPR counterpart, or one so different that starting fresh is faster.

Verifiable parental consent mechanism. Section 9 needs a verification method, a consent record, and a technical flag that switches off tracking and targeted advertising for under-18 users.

Section 7 legitimate use register. For each activity not based on consent, which Section 7 head applies and why. This replaces the LIA library and, in our reading, is the document the Board will ask for first.

SDF readiness pack. If classification is plausible, prepare the India-based DPO appointment, data audit scope and DPIA calendar now.

Retention and inactivity erasure logic. Specified large fiduciaries (e-commerce with 2 crore or more users, online gaming 50 lakh or more, social media 2 crore or more) must erase after three years of inactivity with 48 hours prior notice. Even outside those classes, Section 8 requires erasure once the purpose is served, and most GDPR retention schedules have no automated trigger.

Board-facing grievance log. The Data Protection Board is a new regulator. Keep a log of grievances, response times and escalations that can be produced on request.

Rather than drafting from a blank page, the 16 DPDP Starter Templates include notices, a breach runbook and vendor agreements aligned to the Act and Rules.

Frequently Asked Questions

If we are GDPR compliant, are we automatically DPDP compliant?

No. GDPR compliance gives you a strong foundation in security controls, data inventories and governance, but DPDP removes legitimate interests, sets the children’s threshold at 18, changes breach notification recipients and timing, and uses fixed rupee penalties. In our experience roughly a third of GDPR artefacts can be reused as-is, a third need rewriting and a third must be built new.

Can we keep using legitimate interests for marketing and analytics in India?

Not for data in DPDP scope. Section 7 provides a closed list of legitimate uses with no balancing test, and marketing or product analytics does not fall within it. Those activities will generally need consent under Section 6, with withdrawal as easy as giving consent.

Does our EU-based DPO satisfy the DPDP Act?

Only if you are not a Significant Data Fiduciary. SDFs must appoint a DPO based in India under Section 10 and must also engage an independent data auditor and conduct periodic DPIAs. Non-SDFs are not required to appoint a DPO but must publish a contact for grievances.

How do the breach notification rules differ between GDPR and DPDP?

GDPR requires notification to the supervisory authority within 72 hours and to individuals only where there is a high risk. DPDP requires intimation to the Board and to every affected data principal without delay, followed by a detailed report to the Board within 72 hours, with no risk threshold for informing individuals. CERT-In’s six-hour reporting direction applies in parallel for listed cyber incidents.

Do we need Standard Contractual Clauses for transfers out of India?

No. Section 16 permits cross-border transfers except to countries restricted by Central Government notification, and there is no SCC or adequacy mechanism. Sector regulators such as the RBI may still impose localisation on specific data sets, so check sectoral rules before assuming a transfer is free.

Related explainers

• DPDP vs GDPR: key differences

• Significant Data Fiduciary (SDF) explained

• Data Fiduciary vs Data Processor under the DPDP Act

Next step

If your GDPR programme is mature and you want a defensible DPDP position before May 2027, the fastest route is a GDPR-to-DPDP gap assessment that sorts every artefact into reuse, rewrite or build new and hands you a sequenced plan. That is what the Readiness Sprint delivers.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

A virtual DPO (vDPO) is an outsourced, named data protection officer who carries the DPDP Act’s accountability role for your organisation on a monthly retainer instead of a full-time salary. Under Section 10, only Significant Data Fiduciaries must appoint a DPO based in India who reports to the board, but every fiduciary must publish a contact person for grievances under Section 8, and most substantive obligations become enforceable in May 2027. This page covers what a vDPO does each month, in-house versus virtual, indicative INR fee bands, a 30-day onboarding plan and when a vDPO alone is not enough.

What does a virtual DPO India engagement actually cover?

A virtual DPO is not a helpline or a document library. It is a named individual, backed by a small team, who carries the DPO role under the DPDP Act and can be put in front of your board, your customers and, if needed, the Data Protection Board of India.

Section 10 requires a Significant Data Fiduciary (SDF) to appoint a DPO based in India who represents the fiduciary, is responsible to the board and acts as the point of contact for grievance redressal. Section 8 requires every fiduciary, SDF or not, to publish the contact details of a DPO or of a person able to answer data principals’ questions. In practice, a non-SDF still needs someone competent whose name sits on its privacy notice and who responds within the published grievance period, which the Rules cap at 90 days.

A vDPO fills both roles: statutory officer for an SDF, published contact person and programme owner for everyone else. If you are unsure which category you fall into, our SDF classification explainer and the SDF Classifier on our tools page walk through the factors the Central Government is expected to weigh.

What the vDPO does month by month

The value of a retainer is rhythm. A typical cycle looks like this:

Breach response is the item most clients underestimate; our 72-hour breach response article explains the sequence.

DPO as a service India: how it compares with an in-house hire

Should we hire, or should we retain? The comparison reflects what we see in practice across Indian mid-market companies.

Two cautions. First, a vDPO must genuinely meet Section 10: based in India, empowered to represent the fiduciary and reporting to the board. A foreign firm’s remote advisor does not meet that test for an SDF. Second, the DPO role does not dilute the fiduciary’s liability. Schedule penalties, up to Rs 250 crore for failing security safeguards and up to Rs 150 crore for SDF obligations, attach to the company, not the officer.

Outsourced data protection officer: what is in scope and what is not

Retainer scope is where most disappointments originate, so we set it out explicitly.

In scope. Acting as the named DPO or contact person. Owning the records of processing, consent register and vendor register. Signing off Section 5 notices and Section 6 consent flows, including withdrawal that is as easy as giving consent. Advising on Section 7 legitimate uses, particularly employment purposes. Handling rights requests and grievances. Running the DPIA cycle and liaising with the independent data auditor for SDFs. Quarterly board reporting. Breach response leadership. Monitoring Board guidance and translating it into actions.

Out of scope, unless separately agreed. Drafting the full initial document set from a blank page (that is a Readiness Sprint). Implementing security controls; the vDPO specifies, IT or a vCISO delivers. Adversarial representation before the Board beyond the statutory point-of-contact role. Complex Section 16 cross-border structuring for groups. Engineering work on consent platforms, though the vDPO reviews the design.

Where the gap assessment is long, run a fixed-scope sprint first, then the retainer to hold the position. Companies starting from little often shortcut drafting with our DPDP Starter Templates: privacy notices, a breach runbook and processor agreements the vDPO then tailors.

DPDP DPO requirement: who must appoint one and who must publish a contact

Tier one: Significant Data Fiduciaries

Section 10 lets the Central Government notify any fiduciary or class of fiduciaries as an SDF. An SDF must appoint an India-based DPO responsible to the board and acting as grievance contact, appoint an independent data auditor, and carry out periodic DPIAs. Failure on SDF obligations carries a penalty of up to Rs 150 crore.

Tier two: every other data fiduciary

Section 8 applies to all fiduciaries: publish the contact of a DPO if appointed, or otherwise of a person able to answer data principals’ questions, and run an effective grievance mechanism. The person you publish must be reachable, competent and backed by a process.

Timing

Under the phased commencement, DPO and SDF obligations become enforceable 18 months after notification, in May 2027. In our reading, waiting until the last quarter is a mistake: SDF notifications may arrive with short lead times, and a DPO appointed a month before enforcement has no record of oversight to point to. The enforcement phases explainer sets out the timeline, and the Act and Rules Explorer lets you read Sections 8 and 10 alongside the Rules.

DPO cost India: indicative fee bands

All figures are indicative, expressed as ranges, and exclude GST. They reflect the Indian market for a retainer with a named lead holding recognised privacy and audit credentials. Cheaper offerings are usually a document subscription with a shared helpdesk, which does not satisfy Section 10 for an SDF.

One-time onboarding is usually charged separately, indicatively Rs 1,50,000 to Rs 6,00,000 depending on documentation maturity, and covers the 30-day plan below. Breach response beyond an agreed annual allowance is billed at time and materials. A vDPO bundled with a vCISO is often cheaper than two retainers.

By comparison, a senior in-house privacy lead in a metro indicatively costs Rs 30 lakh to Rs 60 lakh a year all-in, before tooling and the recruitment cycle. For most companies below 1,000 staff, the retainer is the more economical and more defensible option. Test your exposure with the Penalty Exposure Estimator on our tools page before deciding how much governance to buy.

Onboarding a vDPO in 30 days

This is the plan we run.

Days 1 to 7: appointment. Board resolution appointing the vDPO or naming the contact person. Kick-off with each function and collection of existing notices, contracts and system inventories. Publication of contact details on the website and privacy notice.

Days 8 to 15: data mapping and gap assessment. Build the records of processing: what data, for what purpose, on which lawful basis (consent or a Section 7 legitimate use), where stored, which processors, retained how long. Gaps scored by severity. Preliminary SDF likelihood view.

Days 16 to 23: quick fixes. Publish or correct the Section 5 notice. Fix visible consent problems: pre-ticked boxes, bundled consent, missing withdrawal routes. Stand up the grievance mailbox and rights log with the published response period. Issue processor addenda to the top ten vendors by data volume. Confirm breach escalation and CERT-In reporting routes.

Days 24 to 30: governance. First leadership report with the roadmap sequenced to May 2027. Agree the monthly cadence, internal champion and escalation matrix. Book DPIAs for high-risk processing, particularly children’s data under Section 9 or biometric attendance in HR.

By day 30 you have a named officer, a published contact, a processing register, a gap list with owners and a board that has seen the plan.

When a virtual DPO is not enough

We re-scope engagements when a vDPO alone would give false comfort. Recognise yourself in any of these and plan for more than a retainer.

You have no security baseline. Without access control, logging, backups and encryption, the vDPO will write findings nobody can close. The Rules list these safeguards and the penalty for failing them is the highest in the Schedule. Pair the vDPO with a Cybersecurity Posture Check and an implementation owner.

You are a large SDF with regulator-facing operations. A bank, insurer, large lending platform or hospital group with regular supervisory interaction usually needs an in-house DPO supported by an outsourced team, not the reverse. The vDPO works well as deputy, auditor liaison or interim officer during recruitment.

Your group spans jurisdictions. A vDPO can hold the India role, but a group under GDPR and DPDP needs a global privacy lead who owns the conflicts, such as GDPR’s one-month DSAR window against DPDP’s published period, or GDPR’s legitimate interests balancing which has no DPDP equivalent.

Leadership wants a name, not a function. A vDPO denied information, access and authority is a liability, not a safeguard. Fix that first.

Frequently Asked Questions

Is a virtual DPO legally valid under the DPDP Act?

Yes, in our reading. Section 10 requires an SDF’s DPO to be based in India, represent the fiduciary, report to the board and act as grievance contact; it does not require an employee. A properly appointed, independent vDPO meeting those conditions satisfies the requirement, and the Section 8 contact-person duty for non-SDFs is even more clearly met.

Do I need a DPO if my company is not a Significant Data Fiduciary?

Not a statutory DPO, but you must publish the contact of a person who can answer data principals’ questions and run an effective grievance mechanism. That person needs the same skills as a DPO, and appointing one now positions you for a later SDF notification without starting over.

How much does a virtual DPO cost in India?

Indicatively, monthly retainers range from about Rs 60,000 for a small non-SDF to Rs 4,00,000 and above for a notified SDF or regulated entity, excluding GST. Onboarding is typically Rs 1,50,000 to Rs 6,00,000. These are market ranges, not quotes.

What happens if we suffer a breach during the retainer?

The vDPO leads the response: notifying affected data principals and the Data Protection Board without delay, filing the detailed report within 72 hours under the Rules, and coordinating any CERT-In 6-hour reporting. Hours within the annual allowance are covered; extended forensic or legal work is scoped separately.

How quickly can a vDPO be operational?

The officer is appointed and published in the first week, and the processing register, gap assessment and grievance process are in place by day 30. Companies starting from scratch usually add a Readiness Sprint alongside the first month.

Related explainers

• Significant Data Fiduciary (SDF) explained

• Data Fiduciary vs Data Processor under the DPDP Act

Next step

If you need a named, India-based data protection officer or a published contact person before May 2027, the fastest route is a short scoping call where we size the retainer against your data, sector and SDF likelihood. Book a vDPO scoping call at /services and we will send a written scope and indicative fee within five working days.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Employee data is the one dataset the DPDP Act touches in every Indian organisation, regardless of sector or size. Section 7 lets employers process personal data for employment purposes without consent, but that legitimate use is narrower than most HR teams assume and does not cover third-party background checks, non-essential biometrics, wellness health data or intrusive monitoring. Retention after exit is set by labour, provident fund and income tax laws first, and by the DPDP erasure duty for everything else. This guide gives HR and compliance leads a data inventory checklist, a consent-versus-legitimate-use decision table and a sample retention schedule to work from before May 2027.

Why dpdp act employee data is the compliance problem every company shares

A ten-person startup and a 40,000-person manufacturer differ in almost everything except this: both hold PAN, Aadhaar copies, bank details, salary history, medical certificates and performance records for every person they employ. Customer data varies by business model. Employee data does not.

HR data is now almost entirely digital, so it sits squarely within the Act. Under Section 4, every item must be processed either with consent under Section 6 or for a legitimate use under Section 7. There is no third option, and unlike the GDPR there is no legitimate interests balancing test to fall back on (see our DPDP 101 explainer). HR therefore needs to know, for each category of employee data, which basis it relies on, and be able to show that answer to the Data Protection Board. Most organisations we review cannot do that today.

What dpdp hr compliance requires under the Section 7 employment purpose

Section 7 lists situations in which a data fiduciary may process personal data without consent. The one HR relies on covers processing for purposes of employment, or for safeguarding the employer from loss or liability, including prevention of corporate espionage, confidentiality of trade secrets, and provision of any service or benefit sought by the employee.

In our reading, this covers the core of the relationship: onboarding, payroll and statutory deductions, leave and attendance, performance management, misconduct investigations, access control, and benefits the employee has asked for.

Where the employment purpose stops

Three boundaries recur in practice. First, the purpose must actually be employment: using employee contacts for marketing is not. Second, necessity is the operative test; blood group, religion, caste and marital status often sit in onboarding forms with no employment justification. Third, Section 7 does not switch off other duties. Section 8 security safeguards and erasure once the purpose is served, and the Section 11 to 14 rights, apply whether or not consent was taken. The Section 5 notice is tied to consent-based processing, but in practice a clear HR privacy notice is the simplest way to evidence purpose limitation for legitimate-use processing too. See our Section 7 lawful basis explainer.

When is employee consent dpdp compliant, and when is it still needed?

Employers routinely take a blanket consent signature at offer stage. Under Section 6 that consent is close to worthless: consent must be free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it. A candidate who must sign to receive an offer is not consenting freely, and one line covering “all HR purposes” is not specific.

The better approach is to rely on Section 7 for what it genuinely covers and take separable consent only where the employment purpose does not reach. The table reflects our practice view.

Anything on the consent side must be operationally reversible: an employee who withdraws consent to the wellness app must keep their job without detriment. For every category on the legitimate-use side, keep a short written record of why it is necessary. That record is your defence.

Biometric attendance and necessity

A fingerprint or face template cannot be changed once compromised. We covered the detail in our biometric attendance blog post, and the conclusion holds: an employer that considered alternatives, limited the template to attendance, encrypted it, kept it off the device vendor’s cloud unless a processor contract exists, and set a deletion date at exit is defensible. One that let the vendor’s app upload templates to an unknown server is not. The Act has no sensitive data categories, but the Board’s view of reasonable security safeguards under Section 8 will in practice be stricter for data that causes permanent harm if leaked.

Background verification consent dpdp requirements and candidate data

Candidates are data principals from the moment a CV arrives. In our reading the Section 7 employment purpose extends to prospective employment, so evaluating a CV is covered. Keeping every rejected CV for five years is not: the purpose is served when the requisition closes. A workable rule is six to twelve months tied to a documented purpose such as defending process complaints, then deletion. For a talent pool, ask for consent and honour withdrawal.

Background verification is the sharpest edge because three parties are involved: the employer, the BGV vendor, and the sources the vendor contacts (former employers, universities, courts, neighbours). The vendor is a data processor that must be engaged under a valid contract, and the employer remains responsible for what it does. The consent should name the vendor, the checks, the sources, the retention period for the report, and the candidate’s right to see and correct it. In regulated sectors, the RBI Master Direction on KYC and the RBI cyber security framework for banks push towards documented staff screening; that does not remove the need for consent, it strengthens the case for doing it properly.

Payroll, HRMS and BGV vendors as data processors

The average mid-sized Indian company we review has employee data in six to ten external systems: cloud HRMS, payroll bureau, PF and ESI consultants, insurance broker and TPA, BGV vendor, biometric device vendor, learning platform, and an offshore parent’s global HR system. Each is a processor engaged under what must be a valid contract, and the Rules list contractual measures with processors among the reasonable security safeguards, so a purchase order with no data protection terms is a gap.

Minimum contract terms in practice: processing only on documented instructions, safeguards matching the Rules (encryption, access control, one-year log retention, backups), breach notification fast enough for you to meet your own 72-hour duty to the Board, sub-processor and cross-border disclosure, and deletion at contract end. Our vendor remediation guide covers the renegotiation sequence. For subsidiaries whose global HRMS sits abroad, Section 16 permits the transfer except to countries restricted by Central Government notification; the missing contract and the missing notice to employees are usually the real problem.

HR data inventory checklist

You cannot assign a basis, a retention period or a processor to data you have not listed. Complete one row per data category, not per system.

Employee data retention india: statutory holds versus DPDP erasure

Section 8 requires erasure when the purpose is served, unless retention is necessary for compliance with law. For HR data the second half does most of the work, because labour, provident fund and income tax laws impose retention periods that outlast the employment. The Rules’ three-year inactivity erasure rule applies to specified large platforms, not to employers as such.

The schedule below is indicative and should be validated by labour counsel against the statutes applicable to your state and sector; periods differ across state Shops and Establishments rules and the labour codes as they come into force.

“Retain for tax” does not mean retain everything: keep the payroll ledger, delete the Aadhaar scan. Retention must also be enforced at each vendor, so the exit checklist needs a line per processor.

Handling employee rights requests

Employees and former employees have the same Section 11 to 14 rights as customers: access to a summary of their data and the processors it went to, correction and erasure, grievance redressal within a published period (the Rules cap it at 90 days), and nomination. The access and correction rights are framed around consent-based processing, but in practice we advise treating every employee request as if the rights apply, because most HR data is a mix of both bases anyway.

The requests that actually arrive are predictable. A former employee asking for their file during a dispute should receive a summary and the underlying documents, minus third-party data. A request to correct a performance rating can be declined with reasons where the rating is an evaluative opinion, not a factual error. A request to erase a disciplinary record can be declined while the dispute defence purpose is live, with the reason recorded. Our DSAR workflow guide covers intake and response, and Your DPDP Rights is the version you can point employees to.

The exposure for getting this wrong sits in Section 33 and the Schedule: up to Rs 250 crore for security safeguard failures, which is what a leaked payroll file or biometric database represents, and up to Rs 50 crore for most other breaches. The Penalty Exposure Estimator lets you model your own numbers.

Frequently Asked Questions

Does an employer need consent from employees under the DPDP Act?

Not for the core of the employment relationship. Section 7 allows processing for employment purposes and for safeguarding the employer from loss or liability without consent. Consent is still needed for processing outside that purpose, such as wellness programmes, third-party background checks on candidates, biometrics where alternatives exist, and use of employee photos in marketing.

Is a signed consent clause in the offer letter valid under Section 6?

In our reading, no. Section 6 requires consent to be free, specific and unconditional, and a clause that must be signed to receive an offer is neither free nor specific. Rely on Section 7 for what it covers, and take separate, withdrawable consent only for the categories that fall outside it.

How long can we keep employee data after an employee leaves?

As long as a law requires, and no longer than the purpose needs. Income tax, provident fund and labour statutes set retention periods for payroll and statutory records that typically run three to eight years. Data with no statutory driver, such as biometric templates and background verification reports, should be deleted at exit or within a short documented buffer.

Are payroll and background verification vendors data processors under the DPDP Act?

Yes. Any vendor processing employee data on your behalf is a data processor, must be engaged under a valid contract, and you remain responsible for its compliance. The contract should cover security safeguards, breach notification timing, sub-processors, cross-border transfers and deletion at contract end.

When do these HR obligations become enforceable?

Most substantive obligations under the DPDP Act, including notice, consent, security safeguards, breach notification and data principal rights, become enforceable 18 months after the November 2025 notification of the Rules, which is May 2027. Employee data inventories, vendor contracts and retention schedules take months to fix, so the work should start now.

Related explainers

• Data Fiduciary vs Data Processor under the DPDP Act

• DPDP Act vs IT Act SPDI Rules

Next step

The fastest way to close the transparency gap is a clear HR privacy notice that tells employees and candidates what you collect, on what basis, which vendors see it and how long you keep it. Download the HR privacy notice template, part of the 16 DPDP Starter Templates, and adapt it to the inventory you have just built.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

DPDP compliance for SaaS companies turns on one question: for each set of personal data you touch, are you the data fiduciary or the data processor? For customer data loaded into your platform you are almost always a processor, which means you act only under a valid contract with your customer and the customer remains legally answerable to the Data Protection Board. For your own users, prospects and employees you are the fiduciary with the full set of Section 5 to Section 8 duties. This guide covers the test, the processor-side DPA, sub-processor management and the DPDP questionnaires enterprise customers are already sending ahead of the May 2027 enforcement date.

Are you a data processor under DPDP Act or a data fiduciary?

A data fiduciary determines the purpose and means of processing; a data processor processes on the fiduciary’s behalf. The Act attaches nearly every substantive obligation (notice, consent, safeguards, breach notification, rights, erasure) to the fiduciary. The processor appears mainly in Section 8: a fiduciary may engage one “only under a valid contract”, and remains responsible for compliance regardless of that contract.

The practical test

In our reading, three questions per data set settle it:

Who decided this data would be collected, and why? If your customer, you are processing for them.

Who can repurpose it? If you cannot without the customer’s instruction, you are a processor.

Whose data principals are they? A relationship with your customer, not you, points to processor status.

Worked examples

A payroll SaaS storing salary and bank details for 400 client companies is a processor for that data: the client decided to collect it and could switch vendors tomorrow. The same company is the fiduciary for the HR managers who log in, because it chose to collect their names, emails and login logs for its own account management.

A CRM or analytics product that pools customer data to build benchmark models is harder. If it uses customer data for its own product improvement or model training, it is determining a purpose of its own, and in our reading becomes a fiduciary for that processing. The Act and Rules Explorer gives the exact statutory wording for these definitions.

What a data processor under DPDP Act must actually do

These obligations flow from Section 8 and the DPDP Rules, 2025 (notified November 2025) through your contract, plus the CERT-In Directions of April 2022 which apply to you directly.

The statutory obligation sits with your customer; the contract turns it into yours. A weak DPA is how you accept an open-ended indemnity instead of a manageable set of duties. The stakes explain why customers are aggressive: under the Schedule, failure of security safeguards attracts up to Rs 250 crore and failure to notify a breach up to Rs 200 crore. Those penalties land on the fiduciary, who will look to recover from the processor whose control failed. Our penalties Schedule explainer walks through each tier.

What a SaaS data processing agreement India customers will expect should contain

There is no prescribed DPA form. In practice the market is converging on GDPR Article 28 style documents adjusted for Indian law. A SaaS data processing agreement India customers will accept should cover the following.

Scope and instructions

Define data categories, data principals, purposes and duration. State that you process only on documented instructions, with service documentation and admin console settings counting as instructions, and carve out processing required by Indian law.

Security safeguards

Attach a security annex mapped to the Rules’ safeguard list: encryption in transit and at rest, role-based access, MFA for privileged access, centralised logging with one-year retention, tested backups, vulnerability management. Cite ISO 27001 or SOC 2 Type II if held. Promise specific, verifiable controls, not “bank-grade security”.

Breach notification timeline

The clause customers negotiate hardest. Because the fiduciary must notify the Board without delay and report within 72 hours, most enterprise customers ask for processor notification within 24 hours of confirmation, some within 12. Commit to what your incident process can deliver and define “becoming aware” carefully. Our 72-hour breach response guide sets out a timeline that works from the processor side too.

Sub-processing

Obtain general written authorisation for the sub-processors in your register, with a notice period (30 days is typical) before adding one and a right to object. Commit to flowing down equivalent terms and remaining liable for sub-processor performance.

Cross-border transfers

Section 16 permits transfers outside India except to countries restricted by Central Government notification. Disclose hosting regions and offshore support access, and commit to complying with any restriction notification. See our Section 16 cross-border explainer.

Rights assistance, exit and liability

Commit to tooling for rights requests (the customer must meet its published response period, max 90 days under the Rules), audits on notice with a right to substitute a third-party report, and deletion within a defined period after termination, confirmed in writing. Resist unlimited liability; a super-cap of two to three times annual contract value is a common commercial landing point. The DPDP Starter Templates include a vendor agreement pack adaptable to the processor side.

DPDP for B2B software: the dual-role trap

DPDP for B2B software is harder than it looks because most SaaS companies think of themselves as “just a processor” and stop there. The dual-role trap is the set of flows where you are in fact the fiduciary and nobody has noticed.

Product usage data about your customer’s users. Login times, feature clicks and session recordings collected for your own analytics make you a fiduciary for that data, needing a Section 5 notice and a Section 6 or 7 basis.

Your own employees. Section 7 provides an employment legitimate use, but safeguards, breach handling and a grievance contact still apply.

Prospects and website visitors. Form fills, cookie tracking and lead enrichment are fiduciary activities from the first byte. Read our Section 7 lawful basis explainer before assuming a legitimate use covers B2B prospecting; in our reading it usually does not.

The fix is a data inventory that assigns a role to every data set. Flows tagged “fiduciary” go through your own compliance programme: notice, lawful basis, retention, rights handling. Flows tagged “processor” go through the contract programme above. A flow tagged both, such as product telemetry, is the one to escalate to counsel. DPDP 101 is a good grounding for product and marketing teams who need to understand why.

Sub-processor DPDP flow-down and the register you must keep

Every SaaS company uses sub-processors: hosting, email delivery, payment gateways, error tracking and, increasingly, AI model providers. A sub-processor DPDP flow-down binds each of them to terms at least as protective as your own DPA, because your customer’s Section 8 responsibility runs through you to them.

Three flow-down rules

First, no personal data reaches a vendor without data processing terms. A click-through ToS is a contract, but read it: many US vendors’ terms allow product improvement uses your customers have not authorised.

Second, map each sub-processor to the data it can touch; an error-tracking tool receiving full request payloads sees far more than its category suggests.

Third, maintain a register and a change notification process; customers cannot object to what they cannot see. Our vendor remediation explainer covers vendors who refuse to sign.

Sub-processor register template

Keep the register under version control; the review date column shows customers you actually manage it.

How to answer customer DPDP questionnaires and what to put on a trust page

Procurement teams in banking, insurance, pharma and IT services are already sending DPDP questionnaires to SaaS vendors. The questions are predictable, and vendors who answer fastest win deals.

The questions you will be asked

The trust page

A public trust page reduces questionnaire volume. It should contain your role statement, hosting and residency summary, a security overview mapped to the Rules’ safeguards, your sub-processor register, your standard DPA, your breach notification commitment, certifications with dates, and a named privacy contact for grievances. “Enterprise-grade security” persuades nobody; “logs retained 12 months in Mumbai region, MFA on all privileged access” does.

Run the Readiness Checklist against both your processor commitments and fiduciary obligations before publishing; a trust page that overstates controls becomes evidence against you in a dispute. Do not wait for May 2027: contracts signed in 2026 will still be in force when enforcement begins.

Frequently Asked Questions

Is a SaaS company legally liable under the DPDP Act if it is only a processor?

The Act places statutory obligations and penalties on the data fiduciary, which remains responsible regardless of any contract with the processor. In practice a processor’s liability arrives through the DPA, including indemnities and breach notification commitments. A processor also carries direct obligations under the CERT-In Directions, including six-hour incident reporting.

Do we need a DPDP-specific DPA if we already have a GDPR Article 28 DPA?

A GDPR DPA is a good base but needs adjustment. Indian customers will expect references to the DPDP Act and Rules, breach timelines that support the fiduciary’s 72-hour report to the Board, and Section 16 transfer language. Many firms maintain one global DPA with an India addendum.

Can we use customer data to train our AI models or improve our product?

Only if the contract clearly authorises it, and in our reading that use makes you a fiduciary for that processing, with its own notice and lawful basis requirements. Aggregation or anonymisation clauses help only if the output is genuinely no longer personal data.

How quickly must a processor notify its customer of a breach?

The Act and Rules do not set a processor-to-fiduciary timeline; they require the fiduciary to notify affected data principals and the Board without delay and file a detailed report within 72 hours. Enterprise contracts therefore typically require processor notification within 12 to 24 hours of confirmation.

Do sub-processors outside India create a problem under DPDP?

Section 16 permits cross-border transfers except to countries restricted by Central Government notification, so offshore sub-processors are generally permissible. Disclose locations in your register, commit to complying with any future restriction, and check sector rules such as RBI requirements for payment data that impose localisation independently.

Related explainers

• Data Fiduciary vs Data Processor under the DPDP Act

• DPDP vs GDPR: key differences

Next step

If your customers are already sending DPDP questionnaires or redlining your DPA, a processor-side review will settle what you can commit to and where the dual-role gaps are. Our Privacy Governance Review covers your DPA, sub-processor register, security evidence and trust page in a single engagement. Book it before your next enterprise renewal cycle.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

The DPDP Act allows a data fiduciary to engage a data processor “only under a valid contract”, and the DPDP Rules, 2025 list contractual measures with processors among the reasonable security safeguards. A data processing agreement under DPDP is therefore the document that proves you controlled your vendors when the Data Protection Board asks. This guide sets out the 12 clauses a compliant agreement needs, with sample wording for six, marks negotiation red lines for each side, compares the result with a GDPR Article 28 DPA, and gives a rollout plan for existing vendors before May 2027.

Why a data processing agreement under DPDP is a legal requirement, not a nicety

The Act separates the data fiduciary, who decides purpose and means, from the data processor, who acts on its behalf. Two features matter for contracts: the fiduciary may engage a processor only under a valid contract, and it remains responsible for compliance regardless of that contract. You can outsource the work but not the liability.

The DPDP Rules, 2025 sharpen this. The reasonable security safeguards required under Section 8 include encryption, access control, logging and monitoring with logs retained for at least one year, backups, and contractual measures with data processors. A fiduciary whose vendor loses data and who cannot produce a contract obliging that vendor to protect it has, in our reading, failed the security safeguards duty itself, which the Schedule caps at Rs 250 crore. Our penalties Schedule explainer sets out the tiers.

The timeline is tight. Security safeguards and breach notification become enforceable in May 2027, and most Indian businesses have dozens to hundreds of vendors touching personal data. Each needs a contract that reflects the Act before that date.

DPDP vendor contract clauses: the 12 you cannot leave out

The Act does not prescribe a clause list the way GDPR Article 28 does. That gives drafting freedom, but the Board will judge whether your contract actually delivered the safeguards the Act expects. In practice, these 12 clauses are the minimum. Sample language is given for the six that generate the most negotiation.

1. Scope and purpose

State the categories of data principals and personal data, the processing operations, and the specified purpose. Tie the purpose to your Section 5 notice, because a processor cannot be asked to do something you never told the data principal about.

Sample clause: “The Processor shall process Personal Data solely for the purposes in Schedule 1. Any other processing requires the Fiduciary’s prior written instruction. The Processor acknowledges that Data Principals have been given notice for the Schedule 1 purposes only.”

2. Processing on documented instructions

The processor acts only on documented instructions and must flag any instruction it believes would breach the Act. This clause keeps the vendor a processor rather than a fiduciary in its own right.

3. Security safeguards

Do not write “industry standard security”. Mirror the Rules.

Sample clause: “The Processor shall implement and maintain, at minimum, the safeguards in Schedule 2, which include: encryption of Personal Data in transit and at rest; access limited to personnel with a documented need; logging of access to and processing of Personal Data, with logs retained for not less than one year; and backups sufficient to restore Personal Data within the recovery objectives in Schedule 2.”

4. Sub-processing

Require prior authorisation for sub-processors, a maintained list, flow-down of the same obligations, and full responsibility for sub-processors’ acts. Most disputes with cloud and SaaS vendors sit here.

Sample clause: “The Processor shall not engage a Sub-processor without the Fiduciary’s prior written authorisation. The Processor shall impose on each Sub-processor, by written contract, obligations no less protective than those in this Agreement and shall remain fully liable to the Fiduciary for the performance of each Sub-processor.”

5. Breach notification and assistance timelines

The fiduciary must notify affected data principals and the Board without delay and file a detailed report within 72 hours; CERT-In Directions separately require reporting of listed incidents within 6 hours. If the vendor takes five days to tell you, both deadlines are gone. The contract must set a much shorter clock.

Sample clause: “The Processor shall notify the Fiduciary of any Personal Data Breach without undue delay and in any event within 12 hours of becoming aware of it, providing the information in Schedule 3, and shall update that information as it becomes available. The Processor shall provide all assistance the Fiduciary reasonably requires to notify Data Principals, the Data Protection Board and CERT-In within applicable statutory timelines.”

Our 72-hour breach response guide shows how this clock feeds your own runbook.

6. Assistance with data principal rights

Data principals can seek access, correction, erasure and grievance redressal under Sections 11 to 14, within the period you publish under the Rules (maximum 90 days). The processor must locate, correct and erase data within a window that leaves you time to respond.

7. Retention and deletion on termination

Section 8 requires erasure when the purpose is served. The processor must delete or return data on termination or instruction, certify deletion, and clear backups within a stated cycle.

Sample clause: “Within 30 days of termination or expiry, or earlier on the Fiduciary’s instruction, the Processor shall return or securely delete all Personal Data, including copies held by Sub-processors, and shall certify deletion in writing. Personal Data in backup media shall be deleted within the Processor’s standard backup rotation cycle, not exceeding 90 days, and shall not be restored to live systems.”

8. Audit and evidence

The Board can require evidence, and Significant Data Fiduciaries face an independent data audit under Section 10. Reserve the right to request evidence and to audit on reasonable notice.

Sample clause: “The Processor shall, on 15 days’ notice and not more than once in any 12 months (or at any time following a Personal Data Breach), permit the Fiduciary or an independent auditor bound by confidentiality to audit its compliance with this Agreement, and shall provide on request the evidence in Schedule 4.”

9. Cross-border processing

Section 16 permits transfers except to countries restricted by Central Government notification. Require disclosure of processing locations, advance notice of changes, and cessation of transfers to any restricted country. Sector rules such as RBI payment data localisation may be stricter. See our Section 16 cross-border explainer.

10. Confidentiality and personnel

Personnel with access must be under written confidentiality obligations, trained, and background-checked in proportion to the data.

11. Liability and indemnity

Penalties fall on the fiduciary, so the contract is your only route to recover from a vendor. Cover indemnity for penalties and third-party claims caused by the processor, and negotiate the cap deliberately rather than accepting a fee-based boilerplate.

12. Term and survival

Confidentiality, deletion, audit rights for a defined period, and indemnity must survive termination.

Negotiation red lines in a dpdp third party contract: fiduciary versus processor

Both sides have legitimate positions. The table shows where each should hold and where it can concede.

A processor that refuses any breach notice, audit or deletion obligation cannot meet the Act. In practice, that is a vendor to replace, not negotiate with.

Data processor agreement India template versus a GDPR Article 28 DPA

GDPR-style DPAs signed with European customers or global SaaS vendors are a useful starting point, not a substitute.

In practice a GDPR DPA needs its breach clock tightened, log retention added, the Board and CERT-In named as recipients, the rights window aligned to your published period, and the cross-border clause rewritten around restricted-country notifications rather than adequacy. For a broader comparison, see our DPDP 101 primer and the Act and Rules Explorer.

Rolling out a dpa template india across vendors you already have

New vendors are easy. The harder job is the existing base. A workable rollout, with indicative timelines, looks like this.

Step 1: Inventory and tier (3 to 4 weeks)

List every vendor that receives, stores or can access personal data and tier them by volume, sensitivity and substitutability. Tier 1 holds customer or employee data at scale (payroll, cloud, CRM, support outsourcing); Tier 3 has incidental exposure, such as a courier receiving a name and address. Our Readiness Checklist includes a vendor inventory section.

Step 2: Decide the instrument (1 week)

Tier 1: a standalone agreement or comprehensive addendum. Tier 2: an addendum to the master agreement. Tier 3: standard clauses in purchase order terms. Negotiating a full DPA with 300 vendors is how programmes stall.

Step 3: Issue and negotiate (8 to 12 weeks)

Send the addendum with a cover note citing the statutory basis and the May 2027 date. Global vendors will offer their own DPDP addendum; review it against the 12 clauses rather than redlining line by line. Track responses in a register.

Step 4: Handle refusers (ongoing)

A vendor that will not sign leaves three options: accept a documented risk with a replacement plan, restrict the data shared, or exit. Record the decision. A documented risk decision is more defensible than a missing contract with no explanation.

Step 5: Evidence and maintenance

File signed agreements, sub-processor lists and evidence packs in one place, with a trigger to re-check whenever a restricted country is notified. Our vendor remediation guide covers the register format we use.

Indicative effort for a mid-sized company with 80 to 150 data-touching vendors is 12 to 20 weeks of part-time work by legal, procurement and IT. Start in 2026.

Frequently Asked Questions

Does the DPDP Act require a written data processing agreement?

The Act says a fiduciary may engage a processor only under a valid contract, and the DPDP Rules, 2025 list contractual measures with processors among the reasonable security safeguards. In our reading, a written agreement is the only practical way to evidence both. Treat it as mandatory.

Can our existing GDPR DPA with a vendor serve as our DPDP agreement?

Only partly. A GDPR DPA has the right structure but the wrong timelines, recipients and cross-border mechanics. Tighten the breach clock, add log retention of at least one year, name the Data Protection Board and CERT-In, and align the rights window to the period you publish under the Rules.

How quickly should a processor be required to notify us of a breach?

The fiduciary must notify the Board and affected data principals without delay and file a detailed report within 72 hours, and CERT-In requires reporting of listed incidents within 6 hours. In practice we recommend initial contractual notice within 12 to 24 hours of awareness, with updates as information becomes available.

Is the fiduciary still liable if the processor causes the breach?

Yes. The Act states that the fiduciary remains responsible for compliance regardless of any arrangement with a processor. The contract’s indemnity and liability clauses are your only route to recover losses from the vendor, so the cap deserves careful negotiation.

When do these contracts need to be in place?

Security safeguard and breach notification obligations become enforceable in May 2027, 18 months after the Rules were notified in November 2025. Given negotiation cycles of 8 to 12 weeks per wave of vendors, most organisations should have the programme running through 2026.

Related explainers

• Data Fiduciary vs Data Processor under the DPDP Act

• DPDP vs GDPR: key differences

Next step

The 12 clauses above are drafted in full, with schedules for data description, security safeguards, breach information and audit evidence, in our vendor agreement template, part of the 16 DPDP Starter Templates. Download the vendor agreement template and issue it to your Tier 1 vendors this quarter.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Marketing is the function most likely to draw the first DPDP Act complaint, because it touches the most people, uses the most channels and is the easiest thing for a data principal to notice and object to. Under Section 6, marketing consent must be free, specific, informed, unconditional and unambiguous, and withdrawal must be as easy as giving it. This page maps that standard to each channel, explains how to triage a CRM with no consent records, and shows how to measure campaigns without personal data. Most obligations become enforceable in May 2027, but consent collected today is what you will rely on then.

Why marketing is the fastest route to a DPDP Act marketing consent penalty

Marketing processes personal data for the company’s own benefit, and Section 7 gives it no shelter. The legitimate uses cover voluntary provision for a specified purpose, employment, medical emergencies and State functions. Promotional messaging is not on the list, and there is no GDPR-style legitimate interests test to fall back on. In our reading, consent under Section 6 is the only lawful basis for outbound marketing, obtained with a Section 5 notice that names the purpose plainly.

Volume and visibility make marketing uniquely exposed: one badly worded checkbox becomes lakhs of defective consents, and the unwanted message itself is the evidence. On penalties, marketing failures generally fall in the “other breaches” band of up to Rs 50 crore in the Schedule, and if the audience includes anyone under 18, Section 9’s ban on tracking and targeted advertising directed at children moves exposure to the Rs 200 crore band. Our penalties Schedule explainer covers how gravity, duration and repetition are weighed.

WhatsApp marketing consent under DPDP: opt-in is not the same as a phone number

Meta’s WhatsApp Business policy requires an opt-in before marketing templates are sent, and many teams treat that opt-in as proof of DPDP consent. It is not. The platform opt-in is usually a bundled line in checkout terms, an auto-ticked box, or inferred because the customer messaged first. Section 6 requires consent that is specific (marketing named as a purpose, separate from order updates), unconditional (the purchase cannot depend on it) and unambiguous (an affirmative act, not silence). A customer asking for delivery status has, at most, volunteered their number for that purpose under Section 7; they have not consented to a weekly catalogue.

The second gap is withdrawal. If a customer opted in with one tap, replying “STOP” must work across every template and every sending vendor, without a helpline call. Keep a consent record per number showing the wording shown, timestamp, source and any withdrawal event. That record is your defence when the Board asks.

Channel-by-channel consent table

The standard is the same on every channel; the mechanics differ.

On SMS: TRAI’s DLT framework is enforced by telecom operators to control spam; the DPDP Act is enforced by the Board to protect the person. A template can be DLT-compliant and still unlawful under Section 6 because the consent was never specific or was withdrawn. Run both registers, and make sure a STOP on one updates the other.

Email marketing under the DPDP Act: notice, separation and unsubscribe

From May 2027, sending to a contact without a consent record you can produce is processing without a lawful basis, however old the list.

What the notice must say

Section 5 requires the notice to describe the data and purpose and to explain how to withdraw consent, exercise rights and complain to the Board. For a marketing signup that is a short, visible line at the point of collection, not a link to a 4,000-word policy. Our Section 5 notice guide has wording that survives both legal and conversion-rate review.

Transactional versus promotional

Order confirmations, invoices and password resets can rely on Section 7 voluntary provision. Add a “you might also like” block and the same email becomes marketing. Keep the streams separate so a marketing withdrawal does not break service messaging.

Unsubscribe parity

If signup took one click, unsubscribe must take one click. Preference centres that require a login, “are you sure” interstitials, or a ten-day processing window fail Section 6 in our reading. Honour the request in the sending platform, the CRM and every downstream sync; a person who unsubscribes and receives one more email has a clean complaint.

CRM data DPDP compliance: triaging a legacy database with no consent record

“We have 8 lakh contacts and no idea where half came from. Do we delete them?” Not necessarily, but you cannot keep marketing to them as if nothing changed. We recommend a triage, run before May 2027.

Step 1: classify every record by provenance

Tag each contact with the best evidence you have: an opt-in event with wording and timestamp; a customer relationship with an order date; an event badge scan; an imported file with no source. Provenance also tells you how long you can defensibly keep the record under Section 8.

Step 2: apply a decision rule

Step 3: run the re-permission campaign properly

A re-permission campaign is itself processing, so keep it to one message per channel, name the purpose, make “no” as easy as “yes”, and treat no response as no. Indicative response rates in Indian B2C re-permission campaigns run between 5 and 20 percent, so budget for a much smaller but defensible list. Suppress non-responders during the window (you need a record of who declined), then delete once the window closes and no other purpose such as accounting, warranty or dispute requires retention. Our DPDP Starter Templates include a re-permission notice and a suppression log format.

Consent managers, records and the role they play for marketing

The Act creates a consent manager, registered with the Board under the Rules, through which a data principal can give, review and withdraw consent across fiduciaries. These provisions apply 12 months after notification, ahead of most other obligations. A consent manager will not replace your own capture, but it changes two things for marketing.

First, a withdrawal can arrive through a consent manager rather than your unsubscribe link, so your suppression pipeline needs an intake for third-party signals. Second, when a person can see every consent they have given in one dashboard, vague purposes such as “communications and offers” will look weak beside specific ones. Design consent records now with fields a consent manager could consume: purpose code, wording version, timestamp, channel, source and status. The Act and Rules Explorer traces the consent manager provisions against the Rules.

Cookie consent in India under the DPDP Act: what the banner must actually do

The Act has no cookie clause, but a retargeting pixel or analytics cookie that identifies a device and links it to browsing behaviour is processing digital personal data for marketing, so Section 6 applies. That matters for the banner most Indian sites copied from a European template and never configured.

Non-essential tags must not fire until the person acts; a banner that says “we use cookies” while the Meta pixel has already loaded is notice without consent. “Reject all” must be as visible as “Accept all”; burying rejection behind “Manage preferences” fails parity in our reading. Withdrawal must be reachable later through a persistent footer link that reopens the choice and clears identifiers set under the earlier consent.

Dark patterns to remove before 2027

The patterns we most often flag, each undermining a Section 6 condition: pre-ticked marketing boxes (not unambiguous); consent bundled into “I agree to the terms” (not specific); discounts or app access conditional on marketing consent (not unconditional); accept buttons in brand colour with reject in grey text, or confirmshaming copy such as “No, I don’t want to save money” (not free); unsubscribe links that lead to a login page (withdrawal harder than consent). Each is cheap to fix and expensive to defend.

Children and marketing

Section 9 prohibits tracking, behavioural monitoring and targeted advertising directed at anyone under 18, and requires verifiable parental consent for a child’s data. Brands with a teenage audience (edtech, gaming, fashion, snacks) should assume retargeting and lookalike pipelines will pull in under-18s unless designed to exclude them. The marketing consequence is simple: do not profile or target where you cannot rule out a child. Our DPDP 101 guide covers Section 9 in more depth.

Measuring campaigns without personal data

Consent-first does not mean measurement-blind, but it does mean moving from person-level tracking to aggregate and modelled measurement wherever the consent rate does not justify the risk.

Server-side event collection behind a consent gate counts conversions from consented users without leaking data to third-party scripts. Cohort analysis on data stripped of direct identifiers, and geo or time-split holdout tests (run a campaign in one set of cities against a matched control), give incrementality readings that need no individual tracking. Attribution can lean on first-party data you hold consent for, such as order counts by promo code, and on platform-side aggregated reports rather than user-level exports. Where a metric needs personal data, ask whether the purpose was in the notice; if not, it is out of scope until the notice is updated. Raw event logs tied to an identifier should have a defined lifetime, since Section 8 expects erasure once the purpose is served. Keep the aggregates, delete the rows.

Frequently Asked Questions

Is a WhatsApp Business opt-in enough for DPDP Act compliance?

No. The platform opt-in is a Meta policy requirement and is often collected in a bundled or inferred way. Section 6 needs a separate, specific, unambiguous consent for promotional messaging, backed by a Section 5 notice, and a withdrawal route that is as easy as the opt-in was.

Do we have to delete our whole CRM if we have no consent records?

No, but you cannot continue marketing to it unchanged. Classify records by provenance, run a single re-permission message where a genuine relationship exists, suppress non-responders and untraceable imports, and delete once the window closes and no other retention purpose applies.

Are cookie banners legally required in India under the DPDP Act?

The Act does not name cookies, but non-essential cookies and pixels that identify a device for advertising process digital personal data for a marketing purpose. That requires consent before the tags fire, a reject option as easy as accept, and a way to withdraw later, which in practice means a properly configured banner.

When do these marketing obligations become enforceable?

Consent manager provisions apply 12 months after the Rules were notified in November 2025, and most substantive obligations including notice, consent and data principal rights become enforceable in May 2027. Fix capture and withdrawal flows now rather than re-permissioning twice.

Related explainers

• what is a Consent Manager under the DPDP Act

• DPDP vs GDPR: key differences

Next step

If your signup forms, WhatsApp templates, cookie banner and unsubscribe flows were built for conversion rather than for Section 6, a short review will show exactly which screens must change before May 2027. Book a Consent UX review and we will return a screen-by-screen fix list, a CRM triage plan and the consent record schema your systems should be capturing today.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

If you hold an ISO 27001:2022 certificate, in our reading you already have most of the reasonable security safeguards that Section 8 of the DPDP Act and the DPDP Rules, 2025 demand, because encryption, access control, logging, backup, processor contracts and incident management all trace to Annex A controls. What ISO 27001 does not give you is the privacy layer: notice, consent, data principal rights, purpose-bound retention, children’s data and Significant Data Fiduciary duties. This page provides an ISO 27001 DPDP mapping table, lists the gaps, explains where ISO 27701 fits, and shows how to run one audit calendar and one evidence set for both. Security obligations become enforceable in May 2027, so the mapping belongs in this financial year.

ISO 27001 vs DPDP: two different questions about the same data

ISO 27001 asks whether information is protected against loss of confidentiality, integrity and availability. The DPDP Act asks whether personal data of individuals is processed lawfully, transparently and only for the purpose it was collected. Security is one obligation among many in the Act, and the Act does not care whether you hold a certificate. It cares whether safeguards were in place and working when something went wrong.

The overlap is real. Section 8(5) obliges every data fiduciary to implement reasonable security safeguards, and the Rules spell out the minimum, which reads like a subset of Annex A. The divergence is scope: ISO 27001 covers whatever you put inside the certified scope, while DPDP covers all digital personal data you process, including systems your Statement of Applicability excluded.

The Schedule sets its highest cap, up to Rs 250 crore, for failure of security safeguards, and up to Rs 200 crore for failure to notify a breach. Our penalties Schedule explainer covers how the Board is expected to weigh gravity, duration and mitigation.

ISO 27001 DPDP mapping: safeguard by safeguard

The table maps each safeguard item in the DPDP Rules to the Annex A controls an auditor would expect evidence for. It is a working mapping, not a legal opinion; one Rule item usually needs several controls behind it.

Two observations from applying this mapping at client sites.

First, the one-year log retention in the Rules is longer than the 180 days most Indian firms configured after the CERT-In Directions of April 2022. Your A.8.15 implementation probably satisfies CERT-In and falls short of DPDP. Change the retention setting, get the storage cost approved, and record the change in your logging standard.

Second, A.5.34 is the only Annex A control that references personal data directly, and it is a one-line requirement to identify and meet applicable privacy obligations. Under DPDP it becomes the hook on which the whole privacy programme hangs, so treat it as a pointer to a separate body of work rather than a control that is implemented because a policy exists.

The DPDP technical safeguards rule and where a certificate is not enough

The DPDP technical safeguards rule sets a floor, and the statute adds the word “reasonable”, which is where the Board’s judgement will come in. A certificate proves controls existed and were audited at a point in time. It does not prove they were applied to the right data. The most common finding in our posture checks is scope mismatch: the ISMS covers the corporate network and the flagship product, while the HR system, the marketing automation platform and the customer support tool, which hold most of the personal data, sit outside it.

The second gap is the processor chain. A.5.19 to A.5.21 require you to manage supplier security, but the Act goes further: a fiduciary may engage a processor only under a valid contract and remains fully responsible regardless of what the processor does. Every vendor touching personal data needs DPDP-specific clauses on purpose limitation, sub-processing, breach support and deletion at exit. Our vendor remediation guide explains how to prioritise the contract backlog by data volume rather than contract value.

The third gap is notification timing. A.5.26 asks you to respond to incidents; the Rules require intimation to affected data principals and the Board without delay, followed by a detailed Board report within 72 hours. Your ISO incident process may have no legal notification workstream, no Board report template and no decision rule for what counts as a personal data breach. Bolt these on to the existing runbook; our 72-hour breach response article sets out the decision tree.

ISMS privacy DPDP gaps: what ISO 27001 leaves open

The obligations below have no Annex A equivalent. An ISMS privacy DPDP extension has to be built, not mapped.

Notice (Section 5). Every consent request must be accompanied or preceded by a notice describing the data, the purpose, how to exercise rights and how to complain to the Board. ISO 27001 says nothing about what you tell individuals. Our Section 5 notice explainer is the drafting standard we use.

Consent (Section 6). Consent must be free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it. That is a product and marketing design problem with records to prove it.

Legitimate uses (Section 7). Employment purposes, voluntary provision and other listed uses allow processing without consent, but you must show which basis applies to each activity. That needs a processing inventory, which an ISMS asset register only partly resembles.

Data principal rights (Sections 11 to 14). Access, correction, erasure, grievance redressal and nomination need a workflow, a published response period (the Rules cap it at 90 days), identity verification and a request log. The Your DPDP Rights page sets out what individuals can ask for.

Retention and purpose limitation (Section 8). Personal data must be erased when the purpose is served or consent is withdrawn, subject to legal retention. Specified large fiduciaries face the three-year inactivity erasure rule with 48 hours prior notice. A.5.33 protects records; it does not delete them when purpose ends.

Children (Section 9). Verifiable parental consent for anyone under 18, and no tracking or targeted advertising.

Significant Data Fiduciary duties (Section 10). A DPO based in India, an independent data auditor and periodic DPIAs. An information security officer and ISMS internal audits do not substitute. Run the SDF Classifier to see whether you are likely to be notified.

Each carries its own penalty band, from up to Rs 200 crore for children’s obligations and Rs 150 crore for SDF obligations to Rs 50 crore for the rest. The certificate on the wall does not reduce them.

ISO 27701 India: the privacy extension and whether you need it

ISO 27701 extends ISO 27001 with a privacy information management system. It adds privacy requirements to the management system clauses and two annexes of controls, one for PII controllers and one for PII processors. The controller annex covers exactly the gaps above: conditions for collection and processing, obligations to PII principals, privacy by design and default, and PII sharing and transfer.

For an ISO 27001 India certificate holder, 27701 is the most efficient route to a privacy programme because it reuses your risk methodology, document control, internal audit and management review. You add a privacy risk assessment, a processing inventory, privacy roles and the annex controls, and your certification body audits the combined system in one visit.

Two cautions. ISO 27701 was written with GDPR vocabulary, so translate: PII controller to data fiduciary, PII processor to data processor, PII principal to data principal. DPDP has no legitimate interests basis and no sensitive data categories, and consent plus legitimate uses are its only lawful routes, so several 27701 controls need narrowing. Our DPDP 101 guide summarises the Indian definitions. And 27701 certification is not required by the Act; the Board will treat it as a way of organising the work, not as a defence in itself.

Indicative cost for adding 27701 to an existing 27001 programme in a mid-sized Indian firm is Rs 8 lakh to Rs 25 lakh in advisory and internal effort, plus certification body fees, over four to eight months.

One audit calendar for ISO 27001 and DPDP

Two separate compliance cycles double the interruption to operations and produce findings that contradict each other. Align DPDP work to the ISMS rhythm you already keep.

Use the Act and Rules Explorer when a control owner asks what the requirement actually says.

Evidence reuse: getting credit twice for the same work

The largest saving in a combined programme is evidence. Certification auditors and an independent data auditor under Section 10 want the same artefacts: a policy, proof it was applied, and proof someone checked. Access review records serve A.5.18 and the access control safeguard. SIEM retention configuration serves A.8.15 and the one-year log rule. Restore test reports serve A.8.13 and the backup safeguard. The supplier register with a clause tracker serves A.5.19 to A.5.22 and the valid-contract requirement. The incident register and post-incident reviews serve A.5.24 to A.5.27 and double as mitigation evidence when the Board determines a penalty.

Tag each evidence item in your GRC tool with both the Annex A reference and the DPDP section or rule, so one upload satisfies both audits. And add personal data fields to your asset register: data categories, purpose, lawful basis, retention period and processors. That turns an ISMS register into a processing inventory at marginal effort, and it is the document the Board will ask for first after a breach. Our DPDP Starter Templates include a processing inventory and processor agreement pack built to sit beside standard ISMS documentation.

Frequently Asked Questions

Does ISO 27001 certification satisfy the DPDP Act’s reasonable security safeguards?

In our reading it goes a long way if the certification scope covers every system holding personal data and the controls match the Rules’ listed items, particularly one-year log retention. It does not satisfy the Act by itself, because the Board will look at whether safeguards actually protected the data, not at the certificate. Notice, consent, rights and retention duties remain entirely outside ISO 27001.

Do we need ISO 27701 to comply with DPDP?

No. The Act does not require any certification. ISO 27701 is a structured way to build the privacy layer on top of an existing ISMS and reuse your audit machinery. Firms with a mature privacy function may prefer to map DPDP obligations directly without certifying.

Our logs are retained for 180 days to meet CERT-In. Is that enough for DPDP?

No. The DPDP Rules, 2025 require logs to be retained for at least one year, while the CERT-In Directions of April 2022 require 180 days within India. Configure retention to the longer period and keep logs in India to satisfy both.

When do the security safeguard obligations become enforceable?

Most substantive obligations, including security safeguards and breach notification, become enforceable 18 months after the Rules were notified in November 2025, which is May 2027. Consent manager provisions come earlier, at 12 months. Starting the mapping now leaves time for a full audit cycle before the deadline.

Related explainers

• DPDP Act vs IT Act SPDI Rules

• Significant Data Fiduciary (SDF) explained

Next step

If you hold ISO 27001 and want to know precisely how much of the DPDP security bar you already clear, our Cybersecurity Posture Check tests your controls against the DPDP Rules safeguard list, checks scope coverage of personal data systems and returns a prioritised gap list with evidence reuse noted. Book it through Aizzentec services.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

One cyber incident in India can start two regulatory clocks at once. The CERT-In Directions of 28 April 2022 require listed cyber incidents to be reported within 6 hours of noticing, while the DPDP Act, 2023 and DPDP Rules, 2025 require a personal data breach to be notified to affected data principals and the Data Protection Board without delay, with a detailed Board report within 72 hours. The regimes differ in trigger, recipient, content and penalty, and RBI, SEBI or IRDAI add a third layer for regulated entities. This article gives one timeline, one classification matrix and one runbook structure so your team is not reconciling clocks at 2 a.m.

CERT-In Directions 2022 and DPDP breach rules: what each regime actually requires

CERT-In, under section 70B of the IT Act, protects Indian cyberspace as a whole. The DPDP Act protects individuals whose personal data is exposed. Treating them as one obligation is the most common mistake we see in incident plans.

The CERT-In clock

The CERT-In Directions of 28 April 2022 apply to service providers, intermediaries, data centres, body corporates and government organisations, and expressly include cloud and VPN providers. Listed cyber incidents (unauthorised access, ransomware and malware, data breaches and leaks, defacement, phishing, attacks on cloud and payment systems, among others) must be reported within 6 hours of noticing. ICT logs must be kept for 180 days within India, clocks synchronised to NIC or NPL NTP servers, and VPN, cloud and data centre providers must retain subscriber KYC for 5 years.

The clock runs from “noticing”, not confirmation: a ransomware note found at 03:10 starts the clock at 03:10. CERT-In accepts a partial initial report; it does not accept silence.

The DPDP clock

Section 8 of the DPDP Act requires every data fiduciary to intimate a personal data breach to the Board and to each affected data principal. The DPDP Rules, 2025 (notified November 2025) set the mechanics: notify affected principals and the Board without delay, and file a detailed report with the Board within 72 hours. The principal notice must be in plain language and cover nature and extent, likely consequences, mitigation, steps the individual can take and a contact. Failure to notify carries a penalty of up to Rs 200 crore under section 33 and the Schedule, separate from up to Rs 250 crore for failure of security safeguards; see our penalties Schedule explainer.

Breach notification becomes enforceable 18 months after the Rules were notified, i.e. May 2027, while CERT-In has been enforceable since June 2022. Until May 2027 the DPDP clock is a rehearsal, but one to run now, because logging and evidence habits take a year to bed in. See our enforcement phases article.

Side-by-side

CERT-In vs Data Protection Board notification: how the triggers diverge

The practical question is not “which regulator do we call” but “which clocks has this incident started”. Four combinations exist.

CERT-In only. A DDoS attack takes your website down; no personal data is accessed. Report to CERT-In within 6 hours and record why DPDP was not triggered.

DPDP only. An employee emails 4,000 customer records to the wrong external address. In our reading this is a personal data breach, and arguably a “data leak” on the CERT-In list. Report to CERT-In when in doubt: over-reporting has no penalty, under-reporting does.

Both. Ransomware encrypts a customer database and exfiltrates records. CERT-In within 6 hours, principals and Board without delay, detailed Board report within 72 hours. Build the runbook around this scenario.

Neither. An encrypted laptop is stolen and the key is not compromised. Document the assessment and close the ticket.

The regimes also diverge on audience. CERT-In wants technical indicators. DPDP requires you to speak to affected individuals in plain language, so customer support and legal must be in the room, not just the SOC. The rights those individuals can then exercise are set out in Your DPDP Rights.

India breach notification timeline: one clock from T+0 to T+72h and beyond

Merge the regimes into one timeline and drill it. Times are from first noticing.

In our reading “without delay” is shorter than 72 hours; the 72-hour window is for the detailed report. Plan for principals to hear from you within 24 to 48 hours (indicative) once you know who is affected. The CERT-In window does not pause for weekends, so the on-call roster must include someone authorised to send the report.

For the DPDP-specific detail on the 72-hour window, including draft notice wording, see our 72-hour breach response guide and the companion breach notification 72-hour plan on our blog.

Sector overlays: RBI, SEBI and IRDAI on top of CERT-In and DPDP

Regulated entities carry a third clock. RBI-supervised entities report cyber incidents to RBI within 6 hours under the RBI cyber security framework for banks and related directions, with further expectations under the RBI Digital Lending Guidelines and the Account Aggregator framework. Market intermediaries report under SEBI’s cyber security and cyber resilience framework. Insurers report under the IRDAI information and cyber security guidelines.

A regulated entity may therefore file three reports on one incident. Do not write three runbooks. Write one, with a sector annex listing the extra recipient, format and deadline. Our banking sector post covers the RBI overlay.

Incident classification matrix: three questions in the first hour

Classify every incident against three questions within the first hour.

Print the resulting code at the top of the incident record, for example “PD-Y / CI-Y / SEC-RBI”.

Two decision rules we apply in practice. First, “plausibly involved” starts the DPDP clock: if a server holding personal data was accessed and you cannot prove the data was untouched, treat it as involved. Second, processor incidents are your incidents. The fiduciary remains responsible regardless of the processor, so a breach at your payroll vendor or cloud host starts your clock when you become aware. Processor contracts must require notice within hours, not days; see our vendor remediation article.

A single runbook structure that satisfies both regimes

One document, six sections, reviewed quarterly.

1. Activation and roles. Who declares an incident, how the on-call reporter is reached at 03:00, and the RACI below.

2. Classification. The three-question matrix, with examples from your own CRM, HRMS and cloud tenancy rather than generic ones.

3. Reporting packs. Pre-filled templates for the CERT-In report, principal notice, Board intimation and 72-hour Board report, plus a sector annex. Pre-fill entity details and standard paragraphs so only incident specifics are typed under pressure.

4. Communications. Approved holding statements for customers, employees, media and the board; no external statement without legal and the incident commander signing.

5. Evidence and logging. What to preserve and where, with retention confirmed at 180 days for CERT-In and 1 year for DPDP.

6. Closure and learning. Root cause, remediation tracker, regulator follow-ups, insurance actions and a dated lessons-learned entry.

A word on Board mechanics. The exact form of the Rules notification, the Board’s portal and any acknowledgement process will be operationalised as the Board activates. Re-check them against our Data Protection Board explainer and the Act and Rules Explorer before relying on this page, and update your reporting packs when the Board publishes its formats.

RACI: who signs what during an Indian breach

Speed fails when signatures are ambiguous. Set the RACI before the incident.

Significant Data Fiduciaries must have a DPO in India under section 10, so for an SDF the Accountable role on DPDP deliverables belongs to the DPO. For everyone else, the section 8 grievance contact should sign principal notices. If you are unsure whether you are an SDF, the SDF Classifier in our tools gives a first view.

Evidence to preserve, and why the two regimes want different things

CERT-In wants indicators and attack chain. The Board wants to know what happened to personal data and how fast you acted. Preserve for both.

Technical evidence (CERT-In focus). Firewall, VPN, endpoint and identity logs for the affected window; disk and memory images taken before rebuild; malware hashes, attacker IPs and domains; NTP-synchronised timestamps.

Personal data evidence (DPDP focus). Inventory of records and fields exposed, mapped to the number of principals; access and query logs showing what was read or exported; copies of every principal notice with timestamps; Board submissions with proof of filing; the helpline log.

Decision evidence (both). A timestamped decision log recording when the incident was noticed, when each classification question was answered, who approved each report and why any report was not filed. In our experience regulators distinguish between organisations that acted imperfectly but visibly and those that cannot show what they did.

Retain all of it for at least one year under the DPDP Rules logging safeguard, and longer if litigation, insurance or a sector regulator requires.

Frequently Asked Questions

Does the CERT-In 6-hour rule apply to a small company with no security team?

Yes. The CERT-In Directions apply to all body corporates and service providers regardless of size, with no small business exemption. Designate one person with authority to send the initial report and keep the CERT-In form and contact details in the runbook. The report can be partial; the deadline cannot be missed.

If we report to CERT-In, have we satisfied the DPDP breach obligation?

No. CERT-In and the Data Protection Board are separate authorities with separate triggers and content requirements. A CERT-In report says nothing to affected individuals, who must be notified separately under section 8 and the DPDP Rules, 2025. Treat them as two filings on one timeline.

When does the DPDP 72-hour clock start?

The detailed report to the Board is due within 72 hours of the fiduciary becoming aware of the breach. In our reading awareness starts when someone in the organisation reasonably recognises a personal data breach, not when it is formally confirmed. The intimation to principals and the Board must be made without delay, which is earlier than the 72-hour report deadline.

Are DPDP breach penalties enforceable today?

Not yet. The breach notification duty becomes enforceable 18 months after the Rules were notified, i.e. May 2027. The CERT-In Directions have been enforceable since June 2022, so the 6-hour clock is live now. Build the DPDP process today so it is tested before penalties apply.

Do we notify principals before we know the full scope?

In practice, yes, once you know a group of principals is affected, even if the full list is still being built. The Rules require notification without delay, and notifying known principals first and updating as scope grows is more defensible than waiting for certainty. Record the basis for each stage in the decision log.

Related explainers

• DPDP Act vs IT Act SPDI Rules

• DPDP vs GDPR: key differences

Next step

Two clocks are manageable when the runbook, templates and RACI exist before the incident does. Download the breach runbook template, with the merged timeline, classification matrix and reporting packs, from our DPDP Starter Templates and adapt it this quarter.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Fintechs and NBFCs already operate under a dense RBI stack: Digital Lending Guidelines, the Master Direction on KYC, the Account Aggregator framework, payment data storage rules and the outsourcing and IT governance directions. The DPDP Act, 2023 sits on top of that stack and pulls in a different direction on retention, consent artefacts, cross-border transfer and what a lending app may collect. Most substantive DPDP obligations become enforceable in May 2027, with penalties of up to Rs 250 crore for security safeguard failures. This page gives you the overlap map, a conflict table, lending app collection limits, NBFC priorities and a 90-day plan.

Why dpdp compliance fintech programmes start from the RBI stack, not the Act

Most compliance teams in regulated lenders read the DPDP Act and conclude that they already do most of it. The gap is not that RBI missed something. RBI rules were written for prudential and conduct purposes, while DPDP is written around the data principal, and the two produce different paperwork, rights and timelines for the same data.

Treat each RBI control as the baseline and ask: does it also satisfy the DPDP obligation, and if not, what is the smallest addition that closes the gap? The answer is usually a notice paragraph, a retention flag or a contract annexure, not a new system. Our Act and Rules Explorer lets you read each section alongside the Rules.

What the nbfc dpdp act overlap means for a regulated lender

An NBFC is a data fiduciary for every borrower, guarantor, co-applicant, declined applicant and employee, and usually for data received from bureaus, AA ecosystems and LSPs, because it decides purpose and means once the data lands. That makes the NBFC, not the app vendor or LSP, the entity the Data Protection Board will look at first.

First, every LSP and DLA arrangement is a fiduciary-processor relationship. DPDP requires a processor to be engaged “only under a valid contract” with the fiduciary responsible regardless, so outsourcing agreements need a DPDP annexure covering purpose limitation, sub-processor approval, breach assistance within hours, deletion on exit and audit rights. Our vendor remediation guide sets out the clause set.

Second, declined applicants. Lenders keep declined application data for fraud analysis and model retraining, but s.8 requires erasure once the purpose is served unless retention is required by law, and KYC rules say little about people who never became customers. In our reading, a written retention rule with a defined period and deletion routine is needed.

Third, Significant Data Fiduciary exposure. In our reading, large NBFCs and payment fintechs are plausible candidates once the Central Government notifies classes. SDF status brings a DPO in India, an independent data auditor and periodic DPIAs, with penalties of up to Rs 150 crore. Run the SDF Classifier now so the board has a view before designation lands.

How the digital lending guidelines dpdp overlap limits what a lending app may collect

The Digital Lending Guidelines were, in effect, India’s first data minimisation rule for apps: need-based collection, one-time access to camera, microphone or location for KYC only, and no access to files, media, contacts, call logs or telephony. DPDP sharpens the same principle through s.4 and s.6: a specified purpose, and consent that is free, specific, informed, unconditional and unambiguous.

Two DPDP rules bite harder than the RBI text. Consent must be unconditional, so a loan cannot be refused because the borrower declined an optional purpose such as marketing. And withdrawal must be as easy as giving, so a permission granted in three taps must be reversible in three taps. Our consent UX guide covers screens that satisfy both regimes.

The s.5 notice also has to be more than the app store privacy label: what is collected, for what purpose, how to exercise rights and how to complain to the Board, in plain language at first data capture.

Account aggregator consent dpdp questions: are AA consent artefacts enough?

A borrower approves an AA artefact specifying the FIP, data types, date range, fetch frequency, purpose code and expiry, and can revoke it through the AA app. It is tempting to treat that as DPDP consent. In our reading it is close but not identical, and the difference matters for the FIU, the lender using the data.

DPDP consent under s.6 must follow a s.5 notice from the fiduciary and be specific to its purpose. The artefact describes the data flow, not what the lender does afterwards. Once statement data arrives, the lender’s purposes (underwriting, fraud checks, model training, cross-sell, collections analytics) are governed by DPDP, and only the first is plausibly covered by the purpose code.

Consent manager provisions take effect 12 months from notification of the Rules, and AAs are obvious candidates to register. Until then, treat AA consent as strong evidence for the flow and keep your own consent record for everything you do next.

Fintech data localisation india: payment data, cloud regions and Section 16

Section 16 permits transfer of personal data outside India except to countries the Central Government restricts by notification. That is permissive on its own, but it does not dilute stricter sectoral rules, and three survive DPDP untouched: the RBI payment data storage requirements, the CERT-In Directions of 28 April 2022 (logs kept 180 days within India) and the RBI outsourcing directions on offshore arrangements.

The conflict is rarely the primary database. It is the periphery: analytics warehouses in a US region, support tooling abroad, a fraud vendor’s model endpoint and crash reporting SDKs that ship device data overseas by default. Each is a s.16 transfer DPDP permits, but if the payload contains payment system data or falls within RBI outsourcing scope, the RBI rule controls.

The defensible position is a single transfer register: every dataset leaving India, the recipient, the country, the DPDP basis, the applicable RBI rule and the contractual safeguard. Our Section 16 cross-border explainer covers the register format.

Conflict table: where RBI rules and DPDP pull apart

A fifth conflict is timelines: CERT-In wants incident reports within six hours, the DPDP Rules want notice without delay with a 72-hour report, and RBI has its own reporting. One runbook with three notification tracks is the only workable answer; our 72-hour breach response guide sets out the sequencing.

NBFC-specific priorities before May 2027

Security safeguards with evidence. Up to Rs 250 crore. The Rules name encryption, access control, one-year log retention, backups and processor contracts. Most NBFCs have the controls; fewer have the evidence packaged by system.

Breach notification readiness. Up to Rs 200 crore. The obligation covers every breach and the clock runs from awareness. Test the runbook with LSPs and cloud providers in the room.

Consent and notice re-papering. Every live journey (app onboarding, AA flow, web, DSA-assisted, collections) needs a s.5 notice and a consent record producible per customer. This has the longest lead time.

Rights handling. Requests need a published response period (maximum 90 days under the Rules) and a workflow that knows which records are KYC-retained. See Your DPDP Rights.

Vendor re-papering. Prioritise LSPs, DLAs, collection agencies, cloud and SaaS by whether they hold payment or KYC data. Starter clauses are in our DPDP Starter Templates.

Indicative effort for a mid-sized NBFC is 4 to 8 months and Rs 40 lakh to Rs 1.5 crore of combined cost, depending on the number of apps and LSP relationships.

A 90-day plan for fintech and NBFC teams

Days 1 to 30: map and decide. Build the data inventory by product and system, including every LSP, DLA and AA integration. Produce the overlap map and conflict table with written positions. Run the SDF Classifier and table the results with the board. Share DPDP 101 with product and engineering leads so the vocabulary is common.

Days 31 to 60: re-paper and re-engineer. Redraft notices and consent screens per journey with optional purposes defaulted off. Strip app permissions to the table above. Issue DPDP annexures to the top 20 vendors by data risk. Define retention classes with deletion routines.

Days 61 to 90: prove it. Run the breach tabletop with three notification tracks. Test a rights request that touches KYC-retained data. Build the transfer register and check every overseas SDK and SaaS flow against it. Package security evidence per system.

Frequently Asked Questions

Does complying with the RBI Digital Lending Guidelines make a lending app DPDP compliant?

Not on its own. The guidelines cover collection limits and borrower consent, but DPDP adds a formal s.5 notice, a consent standard that includes unconditionality and easy withdrawal, rights with published timelines, breach notification to the Board and processor contracts. In our reading a guideline-compliant app is roughly two-thirds of the way there.

How can an NBFC honour an erasure request when RBI KYC rules require five-year retention?

Retention required by law is recognised under the DPDP Act, so KYC and transaction records within the mandated period can be retained and the borrower told why. The request must still be honoured for everything outside that requirement, such as marketing profiles and behavioural data. Document the record classes and their legal basis so the response is consistent.

Is Account Aggregator consent the same as DPDP consent?

They overlap but are not identical. The AA artefact authorises a specific data fetch, while DPDP consent must follow the lender’s own notice and cover every purpose pursued after the data arrives. Treat the artefact as strong evidence for the flow and keep your own consent record for underwriting, fraud, analytics and any secondary use.

Does Section 16 of the DPDP Act relax RBI data localisation for payment data?

No. Section 16 permits transfers except to restricted countries, but stricter protections under other laws continue to apply, including the RBI payment data storage requirements and outsourcing directions. Payment system data stays in India; other personal data may move under s.16 with a documented basis and processor contract.

Related explainers

• Significant Data Fiduciary (SDF) explained

• what is a Consent Manager under the DPDP Act

Next step

If you run an NBFC, a lending app or a payment platform and want the RBI-to-DPDP overlap map, conflict positions and 90-day plan built for your own products, our sector Readiness Sprint does exactly that in a fixed scope. Book a scoping conversation through our services page.

Last reviewed: 27 August 2026. Basis: DPDP Act, 2023 and DPDP Rules, 2025 (notified November 2025).

Almost nobody publishes what DPDP compliance actually costs, so boards are budgeting blind. Based on our engagement experience, an indicative one-time programme runs Rs 8 to 25 lakh for a startup or SME, Rs 30 lakh to 1.2 crore for a mid-market company, and Rs 1.5 to 6 crore or more for an enterprise or Significant Data Fiduciary, with ongoing costs of roughly 20 to 40 percent of that figure each year. The biggest cost drivers are vendor count, legacy data, multi-sector regulation and consumer scale, not company headcount. Against penalty caps of up to Rs 250 crore per category, the case for budgeting now, ahead of the May 2027 enforcement date, is straightforward.

How much does DPDP compliance cost: the short answer by company size

Every figure on this page is an indicative range and represents Aizzentec’s estimate from readiness work with Indian companies: a starting point for a budget conversation, not a quote. We split the total into one-time programme cost, tooling and licences, and ongoing operating cost.

The SME band is wide because a 40-person B2B SaaS firm and a 150-person D2C brand with a loyalty app are very different jobs. The enterprise figure is dominated by remediation, not advisory fees. SDF status under s.10 adds a mandatory DPO in India, an independent data auditor and periodic DPIAs to the bill.

DPDP implementation budget: what the one-time programme actually includes

Most of the money goes here in the first 12 to 18 months. Percentages are of total one-time cost.

Assessment and data mapping (15 to 25 percent)

Discovery: what personal data you hold, where it sits, which lawful basis under s.4 to s.7 applies, and who you share it with. Two to four weeks for an SME; a quarter for an enterprise with 30 or more systems. Skipping it is the most common false economy we see. Our DPDP 101 explainer covers the concepts your team needs first.

Policies, notices and governance documents (10 to 15 percent)

Section 5 notices for each collection point, a privacy policy that matches actual processing, retention schedules, a breach runbook aligned to the 72-hour reporting requirement in the Rules, and grievance procedures under s.8 and s.13. Templates bring this down sharply; the 16 DPDP Starter Templates exist because most companies under 200 staff do not need bespoke drafting for every document.

Consent tooling and UX changes (15 to 30 percent)

Section 6 requires consent that is free, specific, informed, unconditional and unambiguous, with withdrawal as easy as giving it. That means engineering time: rebuilding sign-up flows, granular consent records, a withdrawal path and, for under-18 users, verifiable parental consent under s.9. For a consumer app this is the largest single line. For a B2B company relying largely on s.7 legitimate uses it is much smaller.

Vendor and processor remediation (15 to 25 percent)

A processor may be engaged only under a valid contract and the fiduciary remains responsible regardless. Every vendor with personal data access needs a contract review, a processing addendum and, for material ones, a security assessment. Cost scales almost linearly with vendor count. Our vendor remediation guidance sets out a tiering approach that keeps this proportionate.

Security safeguards uplift (10 to 25 percent)

The Rules list encryption, access control, logging and monitoring with logs retained at least one year, backups and contractual measures with processors. Companies already aligned to CERT-In’s 180-day log retention direction spend little here. Companies without central logging spend a lot, and this is where budgets most often overrun.

Training and change management (5 to 10 percent)

Role-based training for HR, marketing, engineering, support and leadership. Cheap relative to the rest, and the layer that most reduces the likelihood of a reportable incident.

DPDP consultant fees India: what advisors, auditors and vDPOs charge

Consultant fees are what clients ask about first and, for most companies, the smallest part of the total. Indicative ranges we observe:

A partner-led boutique typically charges 40 to 60 percent less than a Big Four firm for equivalent scope; freelancers charge less again but rarely cover security and legal drafting together. Ask any advisor what will still be true about your programme after they leave. Documentation you can defend before the Data Protection Board is the deliverable; certification theatre is not.

What inflates a DPDP implementation budget: the real cost drivers

Headcount is a weak predictor of cost. These four factors are much stronger. Cross-border transfers under s.16 are a lighter driver, since transfers are permitted except to restricted countries, but offshore vendors still need mapping; see our Section 16 cross-border explainer.

Vendor and processor count

A company with 12 processors can remediate in a month. A company with 300 needs a tiered programme and a contract factory. Each additional material vendor adds an indicative Rs 25,000 to 1 lakh in review, negotiation and assessment effort, more if the vendor pushes back on liability terms.

Legacy data

Section 8 requires erasure when the purpose is served, and the Rules impose a three-year inactivity erasure rule with 48 hours notice on specified large e-commerce, gaming and social media fiduciaries. Old CRM records and spreadsheets on shared drives need discovery, classification and defensible deletion. Legacy data can double the cost of an otherwise simple programme.

Multiple regulated sectors

A fintech that also distributes insurance must reconcile DPDP with the RBI Digital Lending Guidelines, the RBI Master Direction on KYC and IRDAI information and cyber security guidelines. Budget 20 to 40 percent extra per additional regulated sector.

Consumer scale and children’s data

Scale drives consent engineering, DSAR volumes and breach notification complexity: notifying 50 lakh users “without delay” under the Rules is an operational problem. Under-18 data adds verifiable parental consent and the s.9 ban on tracking and targeted advertising, with a Rs 200 crore penalty cap.

Build vs buy vs advisor: three ways to fund the programme

Most companies land on a hybrid: an advisor runs assessment and design, an internal owner carries execution, and tooling is bought only where volume justifies it. A common mistake is buying a consent platform before the data map exists. Sequence the spend: assess, decide, then tool.

Rule of thumb for companies under 200 staff: fewer than 20 vendors, no children’s data and a single sector means templates plus a short readiness sprint will get you to defensible. If any condition fails, budget for the mid-market band regardless of headcount.

DPDP audit cost and other ongoing costs after go-live

Once the programme closes, three recurring lines remain.

Virtual or in-house DPO. SDFs must appoint a DPO based in India under s.10. Everyone else needs a named owner for grievances under s.8. A vDPO retainer at Rs 1.5 to 4 lakh per month is the common mid-market answer; an in-house senior privacy hire is Rs 25 to 60 lakh per year fully loaded.

Annual audit. Mandatory independent data auditor for SDFs. For others, an annual review is the evidence you will want if the Board asks. Indicative: Rs 3 to 8 lakh for an SME review, Rs 10 to 50 lakh for an SDF-grade audit.

DPIA and reassessment. SDFs must run periodic DPIAs. Non-SDFs should run one for each new product, vendor or data use. Budget two to four per year for an active product company.

Add tooling renewals, refresher training and handling of rights requests under s.11 to s.14 within your published timeline (maximum 90 days under the Rules); our DSAR workflow guide helps size that. Planning ratio: ongoing cost runs at 20 to 40 percent of the one-time programme cost per year.

ROI framing: budget against penalty exposure, not against zero

Justify this spend against the exposure you already carry. The Schedule sets caps of up to Rs 250 crore for failure of security safeguards, Rs 200 crore for breach notification failures and for children’s obligations, Rs 150 crore for SDF obligations and Rs 50 crore for other breaches. In our reading the Board will calibrate to the nature, gravity and duration of the breach, but even a small fraction of Rs 250 crore dwarfs a Rs 50 lakh programme.

Consider a mid-market D2C company with 30 lakh customers, 80 vendors and no central logging, with an indicative programme cost of Rs 60 to 80 lakh. A security safeguards failure with a late notification spans two penalty categories with a combined cap of Rs 450 crore. At even 1 percent of the cap, the penalty is Rs 4.5 crore, roughly six times the programme cost, before churn and incident response. The Penalty Exposure Estimator runs this arithmetic against your own profile and produces a figure you can put in front of a board next to the budget.

Timing matters too. Substantive obligations become enforceable in May 2027. Starting in the second half of 2026 spreads cost over two financial years; starting in early 2027 means rush premiums.

A DPDP budget template you can adapt

Copy this into your planning sheet and fill it in after a readiness assessment.

Tie every line to a named owner, and keep the contingency: the assessment nearly always uncovers systems and vendors nobody listed at the start.

Frequently Asked Questions

What is the minimum a small company should budget for DPDP compliance?

For a company under 200 staff in a single sector with a modest vendor list, an indicative floor is around Rs 8 lakh for the one-time programme plus Rs 4 to 6 lakh per year ongoing. That assumes template-based documents, a short readiness assessment and existing basic security hygiene. Children’s data, consumer scale or a large vendor list pushes the figure into the mid-market band.

Do we need a DPO, and what does one cost?

A DPO based in India is mandatory only if you are notified as a Significant Data Fiduciary under s.10. Every fiduciary, however, must publish a contact for grievances and data principal requests under s.8. A virtual DPO retainer typically runs Rs 1.5 to 4 lakh per month on an indicative basis, while an in-house senior privacy hire is Rs 25 to 60 lakh per year fully loaded.

How does DPDP audit cost differ between SDFs and everyone else?

SDFs must engage an independent data auditor and run periodic DPIAs, which on an indicative basis costs Rs 10 to 50 lakh per year for the audit and Rs 3 to 12 lakh per DPIA. Non-SDFs have no statutory audit requirement, but an annual review at Rs 3 to 8 lakh for an SME is the evidence you will want if the Board asks how you demonstrate compliance.

Is it cheaper to wait until closer to May 2027?

No. Starting in the second half of 2026 lets you spread spend across two financial years, remediate vendors during normal renewal cycles and avoid rush premiums on advisory and engineering. Companies that start in early 2027 compete for the same limited pool of practitioners and pay more for less time.

Related explainers

• Significant Data Fiduciary (SDF) explained

• DPDP vs GDPR: key differences

Next step

Before you take a number to the board, put your own exposure next to it. Run the Penalty Exposure Estimator with your data volumes, vendor count and sector profile, and you will have both sides of the ROI case on one page.