The DPDP Rules Explained: Every Operational Obligation in One Place
The DPDP Act is the framework; the DPDP Rules are the operating manual. This piece walks through every major block — notice standards, Consent Managers, DSR workflows, breach notification, retention, children's data, Significant Data Fiduciary obligations, and cross-border transfers — with the practical implications for Indian Fiduciaries operating under the Rules today.
What the DPDP Rules Add to the Act, and Why They Matter
The Digital Personal Data Protection Act, 2023 is the enabling statute, but the operational substance of India's privacy regime lives in the Digital Personal Data Protection Rules, 2026. The Rules convert the Act's high-level duties into specific procedures: how a consent notice must look, what a DSR workflow must include, how breaches get notified, what Consent Managers must do, how Significant Data Fiduciaries operate, and how cross-border transfers get governed. Without the Rules, the Act is a framework; with them, it is a compliance regime.
The Central Government notified the Rules in a staged manner across 2025 and 2026, with substantive sections coming into force on specified commencement dates. The Rules' main achievements are threefold: they move the Act's abstract notice-and-consent duty into a tangible notice format, they create the operational infrastructure for Consent Managers and Significant Data Fiduciaries, and they fill in the procedural detail on DSRs, breaches, retention, and transfers. For privacy teams working on Indian compliance, the Rules are the day-to-day reference document; the Act is the appellate reference.
This post walks through each major block of the Rules — notice, consent, DSRs, breach notification, retention, Consent Managers, children's data, Significant Data Fiduciaries, cross-border transfers, and the Data Protection Board of India's procedures — summarising the obligation, the implementation detail the Rules now carry, and the practical implications for Fiduciaries. Where the Rules remain thin or ambiguous, we flag it; where they resolve ambiguities that lived in the Act's text, we highlight the resolution.
Rule 3 — The Notice Standard
Rule 3 operationalises Section 5 of the Act, which requires a Data Fiduciary to give notice to each Data Principal before seeking consent. The Rule prescribes the notice's minimum contents: an itemised description of the personal data to be processed, the purposes of the processing, the goods or services the processing enables, the specified means by which the Data Principal may withdraw consent and exercise their rights, and the means by which the Data Principal may file a complaint with the Board.
The presentation standard is as important as the content. The notice must be in clear and plain language, understandable, and complete in itself — meaning that it cannot cross-reference an external privacy policy or FAQ as a substitute for the required content. The notice must be presented to each Data Principal in their language of preference where available, with the Eighth Schedule languages explicitly contemplated. For digital services, the Rule's effect is that the consent notice is a standalone screen, not a buried link in the sign-up flow.
The operational implication is that most Fiduciaries will need to rebuild the consent flow at account creation and at material processing changes. A pre-DPDP flow that relied on a single checkbox tied to a long privacy policy fails the Rule's standalone-notice test. A compliant flow typically presents a short, purpose-by-purpose notice with granular consent toggles, in the Principal's selected language, with the receipt stored for later production on request. This is the first point in the Rules where privacy and product design meet, and the design cost of compliance is real but manageable if addressed early.
Rule 4 — Consent Managers
Rule 4 establishes the Consent Manager regime that Section 6(7) of the Act gestured toward. A Consent Manager is a registered intermediary that enables Data Principals to give, manage, review and withdraw their consent across many Fiduciaries from a single interface. The Rule sets out eligibility criteria for registration, operational obligations, security standards, and the audit regime that Consent Managers must comply with.
To register as a Consent Manager, an applicant must be a company incorporated in India with a minimum net worth, demonstrated information security capability, and a published fit-and-proper standard for its directors. Registered Consent Managers must store consent records in India, must not use personal data they handle for any purpose other than the Consent Manager function, and must publish their consent flow for independent audit. The Data Protection Board of India maintains the Consent Manager register and may suspend or deregister a Consent Manager for non-compliance.
For Fiduciaries, the Consent Manager regime is a double-edged compliance opportunity. On one hand, delegating consent capture to a registered Consent Manager offloads a slice of the DPDP operational burden — the Consent Manager carries the receipt infrastructure, the language localisation, and the user interface for consent management. On the other hand, the Fiduciary remains ultimately responsible for the lawfulness of the processing, and a Consent Manager's receipt is only as useful as the Fiduciary's integration with it. The practical approach is to treat the Consent Manager as a validated infrastructure provider, not as a compliance outsourcer.
Rules 5 to 7 — Data Principal Rights and Grievance Redressal
Rules 5 through 7 operationalise the Data Principal rights in Sections 11 to 14 of the Act. Rule 5 governs the right to access and the right to erasure. The Fiduciary must publish, on its website or app, the means by which a Principal may make the request. The Fiduciary must respond within a timeline the Rules specify — currently 30 days for access requests, with an extension of up to 60 days for complex cases on written notice to the Principal — and must verify the Principal's identity before fulfilling.
Rule 6 governs the right to correction and the right to update. The Fiduciary must process a correction request without undue delay, and the Rule imposes a lightweight evidentiary standard — the Principal must certify the correction is accurate, and the Fiduciary must correct unless it has a defensible basis to refuse. Rule 7 governs the Grievance Officer function, which every Fiduciary must appoint. The Grievance Officer must publish contact details, acknowledge receipt of complaints within 72 hours, and resolve complaints within the published timeline.
Together these three Rules convert the Act's DSR provisions into a workflow. The required infrastructure is specific: a published intake point, an identity-verification step, a fulfilment pipeline across the Fiduciary's data stores, a response template, and an audit log. Fiduciaries without this infrastructure will find themselves offloading DSR work onto email with no SLA tracking — a model that will survive the Rules only until the first user complaint reaches the Board. The build cost is upfront, but once in place the DSR workflow is one of the most repeatable compliance activities under the Rules.
Rule 8 — Breach Notification
Rule 8 is the detailed breach-notification regime that fills in Section 8(6) of the Act. The Rule imposes a two-stage filing with the Data Protection Board of India: an initial intimation 'without delay' on becoming aware of a personal data breach, followed by a detailed report within 72 hours of becoming aware. The detailed report must describe the breach, the circumstances leading to it, the measures taken to mitigate risk, the findings on causation, the remedial measures taken to prevent recurrence, and the notifications given to affected Data Principals.
User notification is addressed separately. The Rule obliges the Fiduciary to inform each affected Data Principal 'without delay' and in a 'concise, clear and plain manner' through the user account or registered contact details. The content of the user notice must include the nature of the breach, the likely consequences for the Principal, the mitigation measures the Fiduciary has taken, the self-protective measures the Principal can take, and the contact point for queries. This user-notice content standard is a notable departure from GDPR, which does not require the Fiduciary to tell the user what to do; the DPDP user notice is actionable by design.
The Rule's design assumes a mature incident response program. The 'without delay' standard for both filings is strict, and the detailed report's content obligations — causation findings, remediation evidence, user-notification audit — are demanding for a 72-hour window. Fiduciaries that have run tabletop exercises against the Rule's exact text are visibly better prepared than those that have mapped the obligations into generic incident response plans. The gap is operational rather than legal, and closing it is the single highest-leverage compliance investment under the Rules.
Rule 9 — Retention and Erasure
Rule 9 operationalises Section 8(7) of the Act, which obliges the Fiduciary to erase personal data when consent is withdrawn or the purpose is no longer being served, unless retention is required for a specified legal reason. The Rule converts this general duty into a specific framework: the Fiduciary must publish its retention schedule, must enforce the schedule in system, and must document any exceptions to the schedule with a lawful basis and review date.
The Rule also specifies the position for e-commerce platforms, online gaming intermediaries, and social media intermediaries operating at scale — a category the Rules sometimes refer to as 'notified e-commerce platforms' or similar — where retention is further time-limited after inactivity. The practical effect is a maximum shelf life for inactive user accounts in these sectors, with a mandatory erasure trigger measured in years rather than open-ended. Fiduciaries in these sectors face the strictest retention regime in the Rules.
For general Fiduciaries, the operational pattern is to publish the retention schedule as part of the privacy notice, enforce it through an automated erasure pipeline, and audit the pipeline regularly to confirm compliance. The common failure mode is to publish a schedule the organisation does not have the systems to enforce — a Fiduciary that promises deletion after 30 days of inactivity but has no mechanism to detect inactivity will struggle on first audit. The platforms that score well under this Rule are the ones that treated erasure as a system feature from day one.
Rule 10 — Children's Data and Verifiable Parental Consent
Rule 10 is the operational detail for Section 9 of the Act, which governs processing of children's personal data. The Rule defines verifiable parental consent as consent given by a parent or legal guardian using a method that provides reasonable confidence in the identity of the adult and in the parent-child relationship. The Rule lists illustrative methods: government-ID verification coupled with a sworn declaration, financial-instrument verification such as a credit card micropayment, video-call verification, or verification through a government-issued digital-identity service.
The Rule's practical bite is in the operational constraints it adds to Section 9's substantive prohibitions. Behavioural tracking, targeted advertising, and tracking directed at children remain prohibited across the board, with no safe-harbour for ad-tech routinely applied to adult audiences. The Fiduciary must have an age-gate at account creation, a parental-consent workflow for users identified as children, and a periodic audit of advertising audiences for leakage into child-flagged accounts.
The Rule's exemptions are narrow. A Fiduciary providing services exclusively to adults, with a credible age-gating process, falls outside the children's-data regime for operational purposes. A Fiduciary providing general-audience services with no robust age-gating must assume children are in the user base and apply the full Rule-10 regime. Mixed-audience services face the most complex compliance posture — the audit expectation is that the Fiduciary can produce evidence that no behavioural tracking has reached child-flagged accounts, which requires continuous audience segmentation hygiene rather than a one-time configuration.
Rules 11 and 12 — Significant Data Fiduciary Obligations
Rules 11 and 12 convert Section 10 of the Act into a specific SDF compliance program. Rule 11 governs the appointment and functioning of the Data Protection Officer. The DPO must be an individual, must be based in India, must report to the board or senior management, and must be identified in the privacy notice as the contact point for Data Principal queries. The DPO's duties include overseeing DPIAs, advising on consent flows and lawful bases, acting as the point of contact with the Data Protection Board, and reviewing processing decisions for DPDP compliance.
Rule 12 governs the independent audit obligation. The SDF must appoint a Data Auditor from a list the Board publishes, conduct an annual audit of its DPDP compliance posture, and furnish the audit report to the Board on request. The audit must cover processing activities, consent flows, DSR workflows, breach history, security controls, and SDF-specific controls such as DPIAs and algorithmic risk assessments. The Data Auditor's independence and the audit's scope are prescribed, so SDFs cannot rely on an internal audit function to satisfy this Rule.
For Fiduciaries that have been notified as SDFs — or that expect to be — the Rules convert Section 10 from a short list of principles into a dense annual compliance calendar. The DPO's workload, the Data Auditor's engagement, the DPIA cadence, and the algorithmic-risk-assessment schedule all become predictable costs. The compensating benefit is that the SDF status, well-executed, is a positive signal to regulators, enterprise customers, and investors — a Fiduciary that passes its first SDF audit cleanly has demonstrated privacy maturity in a way that no self-attestation can match.
Rule 14 — Cross-Border Data Transfers
Rule 14 is the DPDP regime's answer to the long-debated cross-border transfer question. The approach is a government-notified country-restriction model: the Central Government may notify specific countries or territories to which personal data transfer is restricted or conditional, and all other transfers are permitted subject to the Fiduciary's standard DPDP obligations. As of mid-2026, the government has notified a short list of restricted jurisdictions, with most of the world remaining in the permitted-by-default category.
This is a very different model from GDPR's adequacy-plus-SCCs regime. Under DPDP, the Fiduciary does not need to document a transfer mechanism for each flow; it needs to confirm the destination is not on the restricted list and that its contractual safeguards with the recipient meet the Act's processor-obligation standards. The result is a lighter compliance surface for cross-border processing than many Indian multinationals initially feared, though sector-specific localisation rules (RBI payment-data localisation, SEBI data-residency guidelines) continue to apply independently.
The practical read for privacy teams is to maintain a transfer register that logs the destination of each cross-border flow, the contractual safeguards in place, and the sectoral residency requirements that may constrain the flow. When the government notifies a new restricted jurisdiction, the register makes the impact assessment a mechanical exercise rather than a discovery project. Fiduciaries without a transfer register will struggle to respond to the next policy update promptly, and may find themselves accidentally in violation when a destination they routinely use is added to the restricted list.
The Rules' Open Questions and What TruePrivacy Does
Several areas of the Rules remain thin or ambiguous as of mid-2026. The algorithmic risk assessment obligation under Section 10 and Rule 12 lacks a prescribed methodology — Fiduciaries are expected to adopt recognised frameworks (NIST AI RMF, ISO 42001) and document their choice. The Consent Manager registration process is open but the practical onboarding timeline is still measured in months, so a Fiduciary cannot assume a Consent Manager will be available for every language or sector it needs. The children's-data verifiable-parental-consent methods are illustrative rather than mandatory, which creates both flexibility and litigation risk around what counts as 'reasonable confidence'.
TruePrivacy is designed around the Rules' structure as it stands. Each processing activity in the platform's RoPA carries a lawful basis, a retention schedule, a destination map, and a security control attestation that aligns to the Rules' audit expectations. Consent flows render the Rule-3 notice standard in every scheduled language with signed receipts. DSR workflows meet Rule-5-through-7 timing with full audit trails. The breach module enforces the Rule-8 two-stage filing with Principal-notification tracking. SDF controls match Rule-11 and Rule-12 obligations, with DPIA scheduling, algorithmic risk assessment templates, and Data Auditor coordination built in.
The operating thesis is that a Rules-aware platform makes compliance a day-to-day workflow rather than a periodic emergency. As the Rules evolve — new restricted jurisdictions, new SDF notifications, new Consent Manager registrations, Board decisions that interpret the Rules in specific directions — the platform updates alongside the regulation, so the Fiduciary's compliance posture tracks the Rules continuously rather than catching up on an annual cycle. That continuous-compliance model is what the Rules reward most heavily, and what we expect the Data Protection Board of India to recognise in its mitigating-factor analysis as the regime matures.
Automate your privacy compliance
See how TruePrivacy can handle DSRs, consent, and breach response — all in one platform.
Free 14-day trial · No credit card required · Setup in minutes