DPDP Act FAQ — Everything Indian Fiduciaries Ask

The Act applies to the processing of digital personal data in India, and to processing outside India that is in connection with offering goods or services to Data Principals in India. It covers all commercial entities, non-profit entities, and State instrumentalities, with narrow Section 17 exemptions. There is no small-business carve-out from the Act's substantive duties — only from certain additional obligations under Rule provisions. If you process any digital personal data of individuals in India in connection with a service or product, assume the Act applies.

No. The Act applies to digital personal data — personal data in digitised form, or personal data in non-digitised form that is subsequently digitised. Paper records that remain exclusively on paper fall outside the Act's primary scope, though they may remain subject to sectoral confidentiality duties and the common-law right to privacy articulated in Puttaswamy. In practice, almost all modern records flow into digital systems eventually, so the digital-only scope is a narrow carve-out.

Yes. There is no employee-data exemption in the Act. Employee processing runs on either consent or one of the Section 7 legitimate uses — most commonly Section 7(i), performance of employment-related functions. The practical consequence is that employee DSR workflows, retention schedules for ex-employees, and performance-review data all fall squarely under DPDP, and HRMS platforms must support DPDP compliance alongside their sectoral labour-law obligations.

The DPDP Act operates in addition to sectoral laws, not instead of them. Where a sectoral law imposes a stricter obligation — such as the RBI's payment-data localisation requirement, or SEBI's data-residency rules — the sectoral obligation prevails. Where the sectoral law is silent, the DPDP Act fills the gap. In practice, regulated entities (banks, NBFCs, insurers, listed companies) run both regimes in parallel, with the DPDP Act typically the stricter of the two on consent and DSRs, and the sectoral law typically the stricter on storage, retention, and breach reporting timelines.

A Data Fiduciary determines the purpose and means of processing — it decides why and how personal data is used. A Data Processor processes personal data on behalf of a Fiduciary under a contract. The regulatory burden sits overwhelmingly on the Fiduciary: notice, consent, DSR response, breach notification, and penalty exposure all flow through the Fiduciary. The Processor's obligations run through its contract with the Fiduciary, which must bind the Processor to the Fiduciary's compliance posture.

Section 6 requires consent to be free, specific, informed, unconditional, unambiguous, and given through a clear affirmative action. Pre-ticked boxes, bundled consent, or consent extracted as a condition of unrelated service fail the test. The consent must be preceded by a notice under Section 5 that sets out, in clear and plain language, what data is processed, for what purpose, how the Principal may withdraw consent, and how they may complain to the Board. The notice must be presented in the Principal's language of preference where available.

Section 7 lists specific situations where processing does not require consent: the Principal voluntarily providing data for a stated purpose, State functions in the provision of a service or benefit, compliance with judgment or decree, response to medical emergencies, employment-related functions, and corporate restructuring under certain conditions. The legitimate uses are narrow — much narrower than GDPR's six lawful bases — and most commercial processing still runs on consent. The usual practice is to use Section 7 for employment-related and compliance-driven processing, and consent for everything customer-facing.

The Principal must be able to withdraw consent as easily as they gave it. Rule 3 requires the Fiduciary to publish a specific means of withdrawal in the notice, typically a one-click control in the user account. On withdrawal, the Fiduciary must stop processing based on that consent and must erase the data unless retention is required for a legitimate reason — a legal obligation, defence of a legal claim, or statutory record-keeping. The erasure obligation cascades to Processors and sub-Processors.

Yes — consent must be specific. A single consent that covers 'improving our services, marketing, analytics, and third-party sharing' fails Section 6. The practical approach is granular purpose-level consent toggles, with the ability for a Principal to accept some purposes and reject others. Marketing and analytics almost always require their own consent; core service delivery can usually run on Section 7(a) voluntary provision for the specific functional purpose.

Four substantive rights: access to data (Section 11), correction, completion, update, and erasure (Section 12), grievance redressal (Section 13), and the right to nominate another person to exercise the rights in the event of death or incapacity (Section 14). The right to data portability that exists under GDPR has no direct DPDP equivalent, though specific sectoral obligations may require portability-like functions. The right to object to processing is also narrower under DPDP — the Principal withdraws consent rather than objecting to specific uses.

The DPDP Rules currently specify a 30-day response window for access requests, with a 60-day extension permitted for complex requests on written notice. Correction, update, and erasure requests must be processed without undue delay, which the Board is likely to read as a timeframe measured in days rather than weeks. The Grievance Officer must acknowledge complaints within 72 hours. In practice, mature programmes operate well inside these ceilings — a 30-day DSR response is a worst case, not a target.

The Act requires reasonable identity verification before fulfilling. The practical standard is a two-factor check: the account email or phone of record plus a documentary or biometric confirmation (government ID, OTP challenge, in-session re-authentication). The verification must be proportionate — a request to view marketing preferences warrants a lighter check than a request to erase payment history. Overly aggressive verification is itself a privacy risk, and the Board will likely frown on verification routines that collect more personal data than the DSR itself.

Yes, in specific circumstances. Section 17 exemptions permit refusal where erasure would prejudice an active legal right, an offence investigation, or specified State functions. The Fiduciary may also refuse frivolous, vexatious, or evidently false requests under Rule 7, with the refusal reasoned in writing. Refusals attract Board scrutiny, so the practical standard is to document the refusal basis contemporaneously and to escalate marginal cases to the DPO or Grievance Officer rather than refusing at the intake tier.

Section 2(w) defines a personal data breach as any unauthorised processing, accidental disclosure, acquisition, sharing, use, alteration, destruction, or loss of access to personal data that compromises its confidentiality, integrity, or availability. The definition covers the full CIA triad, so ransomware encryption without exfiltration qualifies, as does a misdirected email, a misconfigured bucket, or an insider overreach.

Two tracks run in parallel. To the Data Protection Board: an initial intimation without delay on becoming aware of the breach, followed by a detailed report within 72 hours. To affected Data Principals: notification without delay, in plain language, through the user account or registered contact. Neither track has a risk-of-harm threshold — every personal data breach triggers both notifications, unlike GDPR which exempts low-risk breaches from authority notification and high-risk gating of individual notification.

The Rule-8 detailed report must include an updated description of the breach, the circumstances leading to it, the mitigation measures taken, findings on causation, remedial measures to prevent recurrence, and a report on the user notifications completed. Each element is auditable, so the forensic process must produce evidence inside the 72-hour window. In practice, Fiduciaries should treat the detailed report as the primary deliverable and the initial intimation as a lightweight placeholder.

The CERT-In directions under the IT Act require reporting of a wide range of cyber security incidents, including data breaches, to CERT-In within six hours. This obligation runs in parallel with DPDP and applies whether or not personal data is involved. Run both tracks from a single incident record with a shared fact base, and keep the two filings consistent — inconsistencies between CERT-In and Board filings are a self-inflicted wound.

SDF status is conferred by Central Government notification based on factors in Section 10(1): volume and sensitivity of personal data processed, risk to Data Principals, potential impact on sovereignty and integrity of India, risk to electoral democracy, risk to public order, and State security. The government is expected to notify SDFs by sector or by scale, with large platforms, financial services aggregators, and health-tech providers likely in the early tranches.

Section 10 adds: appointment of a Data Protection Officer based in India and reporting to senior management; appointment of a Data Auditor from the Board's panel; periodic Data Protection Impact Assessments for processing with elevated risk; periodic independent audits; and undertaking of algorithmic risk assessments where processing involves automated decision-making. Rule 11 and Rule 12 convert each of these into a specific operational cadence.

For large or regulated Fiduciaries, yes — pragmatically. Enterprise procurement, due-diligence by investors, and sector regulators are already treating Section 10 practices as proxies for privacy maturity, so the operational cost of running the SDF programme precedes any formal notification. For smaller Fiduciaries, prioritise the DPO function (even in a part-time or outsourced form), the DPIA cadence for sensitive processing, and the audit trail. The remainder of Section 10 can scale with the business.

Yes, by default. The DPDP Act operates on a government-notified country-restriction model: the Central Government may notify specific countries as restricted, and transfers to all other countries are permitted subject to the Fiduciary's standard DPDP obligations. As of October 2026 the restricted list is short. Sectoral localisation rules — RBI payment-data, SEBI data-residency — apply independently and may still constrain the flow.

The destination country, the recipient's identity, the categories of data transferred, the lawful basis, the contractual safeguards, the retention period at the destination, and the applicable sectoral residency rules. Maintain the register as a living document; when the government notifies a new restricted jurisdiction, the register makes the impact assessment a mechanical exercise rather than a discovery project.

The two regimes operate independently. A transfer from an EU establishment to India must satisfy GDPR Chapter V — typically through SCCs plus a transfer impact assessment. A transfer from an Indian establishment to the EU is DPDP-neutral unless the EU is notified as restricted (which it is not, as of October 2026). Multinationals typically run a combined transfer register that satisfies both regimes with duplicative documentation but a single operational workflow.

₹250 crore per failure, for breach of the security safeguards obligation. The ₹200 crore band applies to breach notification failures and to children's data breaches. The ₹150 crore band applies to SDF-specific failures. The ₹50 crore band applies to Grievance Officer and general operational failures. The ₹10,000 band applies to Data Principal duty breaches. The Board may impose multiple penalties in the same proceeding, so a security failure plus a notification failure can stack to ₹450 crore in theory.

Section 33(2) lists the mitigating and aggravating factors: the nature, gravity, and duration of the breach; the type of data affected; whether the breach was repetitive; whether the respondent realised disproportionate gain; the action taken to mitigate; the proportionality of the penalty; and the likely impact on the respondent. The 'action taken to mitigate' factor is the single biggest lever a Fiduciary controls — a documented, prompt, complete response moves the penalty substantially down the range.

The Data Protection Board of India is operational and has issued initial procedural orders. The realistic enforcement horizon in the first eighteen months is a small number of landmark decisions — on the order of ten to twenty — rather than a wide enforcement sweep. The early docket is likely to cluster around high-visibility breaches, children's-data failures by well-known platforms, and clear-cut notification failures. Sector regulators are already treating DPDP compliance as a de facto audit criterion, so sectoral enforcement is likely to outpace the Board's own schedule for regulated entities.