Consent Manager Integration Under DPDP Rules 2025 — SOP

TL;DR for founders

A Consent Manager ('CM') is a Board-registered platform under Rule 4 of the DPDP Rules, 2025 that lets your users give, manage, review and withdraw consent across multiple services from one place. Rule 4 turns on 13 November 2026; substantive DPDP obligations go live on 13 May 2027. You have two tracks: use a registered CM (integration project, Rs. 15-40 lakh, 10-14 weeks) or become one (registration project, Rs. 60-120 lakh first-year, 6-9 months, minimum Rs. 2 crore net worth). A CM cannot read the personal data it routes (First Schedule Part B, item 2), must keep records for seven years (item 4(c)), cannot sub-contract its obligations (item 6), and acts in a fiduciary capacity to the data principal (item 8) — not to the businesses paying for integration. First step this week: decide track — use vs become — and run a cost-benefit gate against your consent volume and data-principal count.

Who this playbook is for

In scope — Registration track:

• Technology providers currently operating a consent layer for third-party fiduciaries
• Fintech, health-tech and identity-layer platforms building federated-consent offerings
• Standalone privacy-tech companies seeking to become India's first cohort of registered Consent Managers
• Data Fiduciaries with strategic reasons to operate an in-house CM subsidiary

In scope — Integration track:

• Data Fiduciaries operating at scale (consumer internet, fintech, edtech, healthtech) who plan to route user consent through a registered Consent Manager
• Enterprise SaaS vendors whose customers will insist on CM-routed consent
• Ecosystem intermediaries — account aggregators, health-record exchanges — whose participants need interoperable consent

Not in scope:

• Data Fiduciaries who will continue to collect consent directly through their own Section 6 + Rule 3 flows (no Consent Manager obligation — Section 6(7) is enabling, not compulsive)
• Data Processors (the Consent Manager obligations sit on the Consent Manager entity itself, not on processors it may appoint — and it cannot sub-contract under First Schedule Part B, item 6)
• Entities processing only employee-HR personal data (Section 7(i) legitimate use — consent is not the primary basis)
• Individuals processing personal data for personal or domestic purposes (Section 3(c)(i) exemption)

Prerequisites

Documents needed — both tracks:

• Record of Processing Activities (RoPA) mapping every processing activity to a Section 6 consent or a Section 7 basis
• DPIA report where processing is high-risk or SDF-candidate
• Board-approved Data-Protection Policy and Consent Management Policy
• Current privacy notice, consent UX screens and consent-log extract
• Vendor / cloud hosting inventory with regions and sub-processor chain

Documents — registration track additionally:

• Certificate of Incorporation — applicant must be a company incorporated in India (First Schedule Part A, item 1)
• Audited financial statements demonstrating net worth of at least Rs. 2 crore (Part A, item 4)
• Net-worth certificate from a Chartered Accountant computed per the "net worth" definition in the First Schedule Note (total assets less liabilities as in the books of account)
• Board resolution authorising the Rule 4 filing and identifying the Authorised Signatory
• Memorandum and Articles of Association containing provisions enforcing First Schedule Part B, items 9 and 10 (conflict-of-interest safeguards), amendable only with Board approval (Part A, item 7)
• Independent certification of interoperability and technical / organisational measures under Part A, item 9
• Fit-and-proper declarations for directors, key managerial personnel (KMP) and senior management (Part A, item 6)
• Data-security assurance report — typically ISO 27001 or SOC 2 Type II with DPDP Rule 6 mapping

Documents — integration track additionally:

• Shortlist of registered Consent Managers (published by the Board on its website under Rule 4(2)(a))
• Vendor due-diligence questionnaire covering the First Schedule Part B obligations
• Draft Data Fiduciary ↔ Consent Manager Agreement with Section 8(2) DPDP Act flow-down

Roles required:

• Executive sponsor — CEO or CPO
• Legal — General Counsel or external privacy counsel
• Data Protection Officer (if SDF or candidate) resident in India
• Grievance Officer — published contact under Rule 9 DPDP Rules
• Chief Information Security Officer
• Product manager for the consent UX
• Engineering lead for API integration and UX

Approvals needed:

• Board resolution for registration track filing, or for material integration budget
• Audit Committee sign-off on the DPIA and the integration risk assessment
• For Consent Managers: independent data-auditor engagement mirroring Rule 13(1)(b) standards, even though Rule 13 applies strictly to SDFs

Step-by-step compliance process

Step 1: Decide the track — use a registered CM or become one

What: Make the use-vs-become call after weighing consent volume, data-principal count, capital availability and strategic positioning.

Where: Executive / Board meeting.

How: For a data fiduciary processing personal data of fewer than 1 million Indian data principals and without a federated-consent business model, the use track is almost always right. The become track is justified when: (a) Consent-layer-as-a-service is the business model; (b) the entity operates a federated ecosystem (health records, financial data, mobility data) requiring interoperable consent; (c) the entity has Rs. 2 crore of locked net worth and board appetite for a specialised, lightly-profitable regulatory business in years 1-2.

Templates: Track decision matrix — data principal count, consent-events per year, fiduciary relationships, business-model dependency.

Common mistakes: Assuming CM registration is a pre-requisite for DPDP compliance (it is not); treating the CM business as a consent-management SaaS (it is a regulated, fiduciary-duty-bearing entity with Rs. 2 crore net-worth lock-in).

Step 2: (Integration track) Vendor diligence on a registered Consent Manager

What: Diligence the candidate CM against First Schedule Part B obligations and the Board's interoperability standard.

Where: Legal, security and product teams; CM vendor data room.

How: Review: (i) registration status and Board-page listing (Rule 4(2)(a)); (ii) interoperability certification under Part A, item 9(a); (iii) blind-routing design — CM must not be able to read routed personal data (Part B, item 2); (iv) record-keeping architecture with minimum seven-year retention (Part B, item 4(c)); (v) prohibition on sub-contracting (Part B, item 6) — any sub-processors for the CM itself are non-compliant; (vi) fiduciary-duty undertaking (Part B, item 8); (vii) conflict-of-interest policies (items 9-11); (viii) audit mechanism and reports to Board (item 12); (ix) change-of-control obligations (item 13); (x) operational SLAs for consent capture, withdrawal propagation and data-principal rights fulfilment.

Templates: A 40-point vendor diligence questionnaire can be requested from Veritect.

Common mistakes: Accepting the CM's claim of interoperability without the Board-page listing; missing that blind-routing is a hard architectural requirement — if the CM can read plaintext personal data, its design is non-compliant.

Step 3: (Registration track) Finalise the legal structure

What: Incorporate the applicant as a company in India (First Schedule Part A, item 1); capitalise to a net worth of at least Rs. 2 crore (Part A, item 4); draft the MoA and AoA provisions required under Part A, item 7.

Where: Registrar of Companies; Board of Directors.

How: A private limited company or LLP converted to a company is the typical vehicle. The MoA must include a principal object covering Consent Manager services. The AoA must include provisions enforcing Part B items 9 and 10 (no directorship / financial interest / employment with Data Fiduciaries by directors, KMP or senior management, with defined policies and procedures to prevent conflict of interest) — and these provisions may be amended only with the previous approval of the Data Protection Board of India. Separately capitalise the net worth via equity infusion or retained earnings; ensure the CA certificate is computed under the net-worth definition in the First Schedule Note (total assets less total liabilities as appearing in the books of account).

Templates: Draft AoA clauses in Section 6 (Templates) of this playbook.

Common mistakes: Using debt-funded capital that does not show up as net worth; grandfathering existing Board composition with directors who hold interests in Data Fiduciaries; AoA provisions that are amendable by ordinary resolution of members without DPBI approval.

Step 4: (Registration track) Prepare the Part A dossier

What: Compile the application package evidencing First Schedule Part A items 1 through 9.

Where: Governed document room, Board-page-published application format (Rule 4(1)).

How: Sections to include: (a) Applicant details — Certificate of Incorporation, PAN, TAN, registered office; (b) Capacity evidence — technical (architecture diagrams, API specs), operational (team composition, support hours), financial (audited financials, CA net-worth certificate); (c) General character — KMP fit-and-proper declarations; (d) Business plan — volume forecasts, capital structure, earning prospects; (e) Fit-and-proper certificates for directors, KMP and senior management; (f) MoA / AoA provisions per item 7; (g) Statement on data-principal-interest alignment; (h) Independent certification under item 9 — interoperability with Board-published standards (currently awaited; to be tracked via the MeitY / Board website) and appropriate technical / organisational measures for Part B item 11 (transparency disclosures).

Templates: Item-by-item compliance matrix.

Common mistakes: Submitting item 9 certification without cross-reference to the Board's interoperability framework; missing item 7 MoA/AoA lock on conflict-of-interest provisions; under-specifying item 2 "capacity" as only technical and omitting operational and financial capacity evidence.

Step 5: Design the Rule 3 consent notice schema

What: Build a notice schema that works directly and via a Consent Manager.

Where: Product and legal teams.

How: Rule 3 of the DPDP Rules, 2025 requires the Data Fiduciary's notice to: (a) be presented independently of any other information; (b) give, in clear and plain language, a fair account sufficient for specific and informed consent — including, at the minimum, an itemised description of the personal data and the specified purpose(s) of processing together with a specific description of the goods or services to be provided or uses to be enabled; and (c) give the particular communication link for accessing the fiduciary's website or app, and description of other means by which the data principal may withdraw consent (with ease comparable to giving it), exercise her Sections 11-14 rights, and make a complaint to the Board.

Operationalise as: a JSON-schema consent record covering itemised data categories, each purpose, the service / use enabled, the withdrawal URL, the rights-exercise URL, and the Board complaint channel. Store both the rendered notice (HTML / image) and the machine-readable JSON at consent time. Serve the same notice via the Consent Manager's interface in the interoperable format the Board specifies.

Templates: Sample Rule 3 notice in Section 6 of this playbook.

Common mistakes: Bundling purposes into a single "improve our services" line (void under Section 6(4)); storing only a notice version number without the rendered copy that the data principal actually saw; missing the ease-of-withdrawal requirement (withdrawal must be as easy as giving consent).

Step 6: Implement granular, unbundled opt-in and opt-out

What: Consent UX must capture a free, specific, informed, unconditional and unambiguous consent for each purpose — never bundled.

Where: Product UX and back-end consent ledger.

How: Section 6(1)-(4) DPDP Act requires consent that is clear and affirmative, limited to the specified purpose, and unbundled. Rule 3(b)(ii) requires a specific purpose and a specific description of the goods or services / uses enabled. Practical implementation: one toggle per purpose; no pre-checked boxes; no "continue to use our app = agree" patterns; no dependency of unrelated service on a specific consent; withdrawal UX that mirrors the capture UX (same number of taps).

Templates: Purpose-toggle matrix; withdrawal-UX wireframes.

Common mistakes: Bundling marketing consent into terms-of-service acceptance; forcing consent to unrelated processing as a condition of the service (void under Section 6(4)); making withdrawal materially harder than capture.

Step 7: Implement data-principal rights APIs

What: Rights fulfilment under Sections 11-14 DPDP Act read with Rule 14 — access, correction, erasure, nomination, grievance — exposed as APIs routed through the Consent Manager (integration track) or as CM-facing endpoints (registration track).

Where: Platform engineering; CM API integration layer.

How: For each right, define: (i) the data-principal-facing entry point (in-app, email, CM dashboard); (ii) the verification mechanism; (iii) the fulfilment SLA (publish in the Rule 3 notice); (iv) the audit trail. Rule 14(2) DPDP Rules requires the Data Fiduciary and the Consent Manager to prominently publish the URL or mechanism for each right on its website or app. Route withdrawal propagation downstream — once the data principal withdraws consent, the Data Fiduciary must (a) cease further processing, (b) cause every Data Processor to cease further processing, and (c) cause every Data Fiduciary to whom data was shared to cease further processing, unless retention is required by law (Section 6(6) + Section 8(2) + Rule 6(f)).

Templates: API contract schema for each right.

Common mistakes: Rights APIs that stop at the Fiduciary boundary and fail to propagate withdrawal to processors and onward fiduciaries; verification mechanisms that are weaker than the consent capture (allowing fraudulent rights requests); SLA published as a policy but not operationally enforceable.

Step 8: Build the withdrawal propagation and audit trail

What: Consent withdrawal must propagate synchronously to every downstream processor and third-party fiduciary, with a tamper-evident audit log.

Where: Consent ledger, data-pipeline stop signals, third-party webhooks.

How: Log every consent event (grant, modify, withdraw) with: timestamp, data-principal identifier (hashed), notice version / hash, purpose identifiers, platform (direct / CM), and propagation status to each processor. Retain logs for at least one year under Rule 6(e) DPDP Rules (log retention) and — for Consent Managers — seven years for consent records under First Schedule Part B, item 4(c). Use append-only storage (hash-chained or WORM) so records cannot be altered after the fact.

Templates: Log schema; propagation matrix.

Common mistakes: Overwriting consent records on change rather than versioning them; retaining the log but losing the corresponding notice version — breaking the ability to reconstruct what the data principal actually saw.

Step 9: Design the breach-notification SOP across regimes

What: A single SOP starting the CERT-In 6-hour clock, the DPDP 72-hour clock, the sectoral-regulator clock (where applicable), and any foreign-regulator clock (GDPR, state AG).

Where: Incident Response Policy + runbook.

How: On detection of a personal data breach: (a) intimate CERT-In within 6 hours under Direction (ii) of the CERT-In Directions dated 28 April 2022 (see Veritect playbook cert-in-6-hour-incident-reporting-sop); (b) intimate the Data Protection Board within 72 hours under Section 8(6) DPDP Act and Rule 7 DPDP Rules; (c) intimate affected data principals "without delay" under Rule 7(1); (d) start any sectoral clock — RBI CSITE, SEBI CSCRF, IRDAI ISNP; (e) start foreign-regulator clocks as applicable. Consent Managers themselves are subject to First Schedule Part B, item 7 (reasonable security safeguards) and must file in their own right on their own platform-level breach.

Templates: Breach decision tree in Veritect playbook cross-border-data-transfer-dpdp-sop Section 8.

Common mistakes: Filing CERT-In and treating DPDP as covered; for CMs — assuming breaches on onboarded fiduciaries are only the fiduciary's problem (item 7 puts a direct obligation on the CM).

Step 10: Implement periodic consent refresh and re-consent on material change

What: Consent is time-bound and purpose-bound; material changes require re-consent.

Where: Consent lifecycle service.

How: Trigger re-consent when: (a) a new purpose is added; (b) new data categories are collected; (c) a new processor class is appointed; (d) a new onward-sharing recipient is added; (e) a material change in cross-border transfer destination happens (see cross-border-data-transfer-dpdp-sop); (f) a fiduciary is newly onboarded onto the Consent Manager's platform (in the CM case). Refresh cadence: at least annually for long-lived continuous-processing relationships; on every material change irrespective of cadence.

Templates: Material-change decision tree.

Common mistakes: Treating re-consent as a marketing hit rather than a compliance obligation; not preserving the prior notice versions alongside the new consent.

Step 11: (Registration track) Interoperability certification and inter-CM testing

What: First Schedule Part A, item 9(a) requires independent certification that the CM's platform is consistent with data-protection standards and the assurance framework published by the Board.

Where: Board-published interoperability standard; accredited test lab.

How: The Board is expected to publish the interoperability standard and assurance framework on its website under Part A, item 9(a). Track MeitY / DPBI notifications weekly for the framework text. Once published: engage an accredited test lab; test (i) consent payload schema conformance; (ii) withdrawal propagation cross-CM; (iii) data-principal record portability across CMs; (iv) blind-routing (CM cannot read personal data) under Part B, item 2. Certify and submit with the Rule 4 application.

Templates: Test cases will need to align to the Board's published framework — a placeholder test matrix is included in the vendor-diligence questionnaire.

Common mistakes: Certifying against the draft DPDP Rules, 2025 (G.S.R. 02(E) of 3 January 2025) text — which was superseded; certifying against GDPR or GDPR-like standards alone.

Step 12: Continuous compliance — annual audit, Board reporting, renewals

What: Ongoing obligations to sustain registration (registration track) or to sustain a compliant integration (integration track).

Where: Audit committee; DPO / Grievance Officer desk; MeitY / DPBI notifications watch.

How: Registration-track continuing obligations — First Schedule Part B, item 12 (audit mechanisms with periodic reports to the Board); item 13 (no change of control without Board approval); Part A, item 6 (fit-and-proper of KMP and senior management — refreshed on change); item 7 (no MoA / AoA change without Board approval). Integration-track continuing obligations — monitor CM registration status on the Board's published list; re-diligence annually; terminate and migrate if the CM is deregistered under Rule 4(5). Both tracks — breach-SOP tabletop once per quarter; annual DPIA refresh.

Templates: Continuous-compliance calendar.

Common mistakes: Treating the initial registration as a completed project; missing the Board's website updates to its interoperability framework; letting fit-and-proper declarations lapse when a new director joins.

Timeline

Template clauses

Template A — Consent notice (Rule 3-compliant, ~260 words)

[COMPANY NAME] — NOTICE UNDER SECTION 5 AND SECTION 6 OF THE DIGITAL PERSONAL
DATA PROTECTION ACT, 2023 AND RULE 3 OF THE DIGITAL PERSONAL DATA PROTECTION
RULES, 2025

We, [Company Name, CIN] ("we"), process the following itemised personal data about you:
 — [Category 1 — e.g., full name, mobile number, email address]
 — [Category 2 — e.g., residential address, PAN]
 — [Category 3 — e.g., transaction history, usage telemetry]

We process this personal data for the following specified purposes:
 1. [Purpose 1] — to enable [specific good / service — e.g., account creation on our
    platform].
 2. [Purpose 2] — to enable [specific use — e.g., monthly billing and statement
    generation].
 3. [Purpose 3] — to enable [specific use — e.g., fraud detection and prevention].

You have the right to withdraw your consent at any time, with ease comparable to that
with which you are giving consent now, by clicking the link or using the mechanism
described at [withdrawal URL]. You have the right to access your personal data, seek
correction, completion, updation or erasure, nominate a representative, and access a
grievance redressal channel — please visit [rights-exercise URL] for each of these.

If you wish to make a complaint to the Data Protection Board of India, please visit
[Board complaint channel URL — to be populated once DPBI publishes it]. For any
question about this notice, contact our Grievance Officer at [email] / [phone].

By clicking "I agree", you give your free, specific, informed, unconditional and
unambiguous consent to the processing described above, limited to the specified
purposes.

Notice version: [hash / version number]        Dated: [YYYY-MM-DD, HH:MM IST]

Template B — Data Fiduciary ↔ Consent Manager Agreement (skeleton, ~170 words)

DATA FIDUCIARY-CONSENT MANAGER AGREEMENT

1. The Consent Manager is registered with the Data Protection Board of India under
   Rule 4 of the Digital Personal Data Protection Rules, 2025. Registration
   particulars: [published on Board website — reference].

2. The Consent Manager shall enable Data Principals using its platform to give,
   manage, review and withdraw consent in respect of personal data processed by the
   Data Fiduciary, in accordance with First Schedule Part B of the DPDP Rules, 2025.

3. The Consent Manager shall not read the personal data routed through its platform
   (First Schedule Part B, item 2) and shall act in a fiduciary capacity in relation
   to the Data Principal (item 8).

4. The Consent Manager shall maintain consent records for at least seven years
   (item 4(c)) and shall not sub-contract any of its obligations (item 6).

5. The Consent Manager shall notify the Data Fiduciary of any breach on its
   platform within twenty-four (24) hours.

6. This Agreement is governed by the laws of India.

Internal audit checklist

Run quarterly (integration track) / monthly (registration track):

• RoPA complete — every processing activity has Section 6 / Section 7 basis, purpose, data categories, CM-routing flag
• Consent ledger — last 90 days fully versioned with notice hashes
• Purpose limitation — no processing outside consented purposes in the last quarter
• Withdrawal propagation — every withdrawal in the last quarter traced to all downstream processors / onward fiduciaries
• Retention enforcement — records older than the Rule 8 Third Schedule trigger erased on schedule
• DPO / Grievance Officer sign-off on the monthly consent dashboard
• CM interoperability — cross-CM portability tested in last quarter (registration track)
• CM blind-routing — penetration-test evidence that plaintext personal data is not readable by the CM (registration track)
• Breach SOP — tabletop in last 90 days with CERT-In + DPDP + sectoral clocks
• Annual external audit (registration track) — engagement letter signed; scope covers Part B items 1-13
• Fit-and-proper certificates (registration track) — current for all directors, KMP, senior management
• MoA / AoA — provisions under First Schedule Part A, item 7 intact; no amendment without Board approval (registration track)
• CM registration list on Board website — candidate CM still registered (integration track)
• Grievance redressal — response times under the Rule 3 notice measured and met
• Children's data — Section 9 flows separately flagged; Rule 10 verification pathway operated

What if things go wrong

Failure 1 — Rule 4(5) non-adherence proceeding against the Consent Manager

• Symptom: Board issues a show-cause under Rule 4(4) alleging non-adherence to conditions and obligations.
• Likely cause: Lapsed fit-and-proper; conflict-of-interest breach (Part B, items 9-11); retention-record gap; sub-contracting of an obligation (item 6).
• Action: File a written response within the Board's specified window; curative plan (remove conflicted personnel, recertify fit-and-proper, restore records, insource the outsourced function); engage with the Board; consider a Section 32 voluntary undertaking if the Board signals escalation.

Failure 2 — Board suspension or cancellation of registration

• Symptom: Order under Rule 4(5) suspending or cancelling registration and issuing directions to protect data principals.
• Likely cause: Unremedied non-adherence; material breach; loss of net-worth (below Rs. 2 crore); change of control without Board approval (Part B, item 13).
• Action: For the CM — file a Section 29 appeal to TDSAT within 60 days; in parallel, effect Board directions on transferring data-principal records to other registered CMs (item 4(c) preserves record continuity). For onboarded Data Fiduciaries — migrate to an alternate registered CM or resume direct consent collection; notify affected data principals under Rule 3 of the changed processing chain.

Failure 3 — Consent log gap discovered during audit

• Symptom: Subset of consent events lacks the rendered notice version; cannot reconstruct what the data principal saw at consent time.
• Likely cause: Notice-version table truncated; consent ledger stored only numeric version without the rendered artefact.
• Action: Immediately preserve all available artefacts; re-consent the affected cohort on a fresh Rule 3-compliant notice; log the gap and remediation in the DPO diary; consider disclosure to DPBI if the gap is systemic — the burden is on the Data Fiduciary under Sections 6(10) and 28(6) to prove consent.

Failure 4 — Withdrawal propagation failure to a downstream processor

• Symptom: Data principal withdraws consent; processor continues to process for N days.
• Likely cause: Webhook failure; processor contract without propagation SLA; manual-only withdrawal handling.
• Action: Stop processor access; file Section 8(6) DPDP breach notification within 72 hours (unauthorised post-withdrawal processing qualifies as personal data breach under Section 2(u)); intimate affected data principals; invoke indemnity in the Data Processing Agreement; remediate the integration.

Failure 5 — Children's-data processing through Consent Manager without Rule 10 verification

• Symptom: Behavioural or profiling signals on under-18 users flow through the CM path without verifiable parental consent.
• Likely cause: Age gate not enforced at the CM layer; Rule 10 pathway not operated.
• Action: Shut off the flow; file Section 8(6) breach notice; assess Entry 3 Schedule exposure (up to Rs. 200 crore for Section 9 breach); re-architect consent so the Rule 10 verification pathway is enforced on the CM side before any child-processing is permitted; voluntary undertaking (Section 32) where appropriate.

Founder checklist

• Decide track (use vs become) in the next 14 days, anchored on consent volume, federation strategy and Rs. 2 crore net-worth appetite.
• Build the RoPA by 30 June 2026 — a single table of every processing activity, purpose, legal basis, hosting region, CM-routing flag.
• Re-paper notices to Rule 3 format and ship granular opt-in / opt-out UX by 30 September 2026 — no bundled consent, no pre-checked boxes, parity of withdrawal with capture.
• Engage auditors by 31 October 2026 — ISO 27001 / SOC 2 for security; independent privacy-audit scope aligned to Rule 13(1)(b) even if not an SDF; for CM applicants, the Board's interoperability certifier.
• Tabletop the breach SOP once a quarter across CERT-In (6 h) + DPDP (72 h) + sectoral + foreign regulators. A single failure in the consent chain is the fastest route to an Entry-1 proceeding.

FAQ

Do I need to engage a Consent Manager if I already handle consent in-house?

No. Section 6(7) of the Digital Personal Data Protection Act, 2023 uses enabling language — a data principal "may" give, manage, review or withdraw consent through a registered Consent Manager. The statute does not compel a Data Fiduciary to route consent through a Consent Manager. If you collect consent directly through your own notice and consent flow that meets Section 6 and Rule 3 DPDP Rules 2025, you remain compliant. Engaging a Consent Manager is a commercial and architectural choice, typically preferred where the fiduciary participates in a federated ecosystem (for example, account aggregators or health-record exchanges).

How does the Consent Manager framework interact with the RBI Account Aggregator regime?

The Account Aggregator ('AA') framework operates under the RBI Master Direction on Non-Banking Financial Company — Account Aggregator (Reserve Bank) Directions, 2016 as amended, and is regulated by the Reserve Bank of India for financial-sector data flows. The DPDP Consent Manager framework under Rule 4 of the DPDP Rules, 2025 is sectoral-neutral and regulated by the Data Protection Board of India. An NBFC-AA may need to additionally register as a Consent Manager under Rule 4 for DPDP purposes — the two are legally distinct registrations with different regulators. Section 16(2) DPDP Act preserves the continued operation of sectoral frameworks including the AA regime.

What happens if a Consent Manager is deregistered by the Board?

Rule 4(5) of the DPDP Rules, 2025 empowers the Data Protection Board of India, after giving the Consent Manager an opportunity of being heard, to suspend or cancel registration and issue consequential directions to protect the interests of data principals. Data Fiduciaries onboarded onto the deregistered platform must have pre-agreed fallback — either migrate consent records to another registered Consent Manager or resume direct consent collection under Section 6 DPDP Act. Consent records maintained by the deregistered Consent Manager remain subject to the seven-year retention obligation under First Schedule Part B, item 4(c).

Can I switch from one Consent Manager to another?

Yes. The DPDP Rules, 2025 do not contain a lock-in. First Schedule Part B, item 1 of the DPDP Rules requires Consent Managers to enable data principals to give, manage, review and withdraw consent on an interoperable basis; Part A, item 9(a) requires the applicant's platform to be consistent with such interoperability and data-protection standards as the Board publishes on its website. Practical switching requires commercial exit terms in the Data Fiduciary-Consent Manager agreement (exit data migration, record continuity, notice to data principals under Rule 3 of any material processing-chain change).

How does children's consent work when routed through a Consent Manager?

Section 9(1) of the Digital Personal Data Protection Act, 2023 requires verifiable parental consent before processing the personal data of a child (person under 18). Rule 10 of the DPDP Rules, 2025 specifies three verification pathways: (a) personal information reliably held by the Data Fiduciary; (b) identity and age details voluntarily provided; or (c) a government-issued or authorised virtual token. A Consent Manager acting for a child must operate the same verification standard — the Rule 10 pathway must be satisfied on the Consent Manager's platform. Section 9(3) prohibitions on tracking, behavioural monitoring and targeted advertising apply whether consent was routed through a Consent Manager or given directly.

Must a Consent Manager maintain records, and for how long?

Yes. First Schedule Part B, item 3 of the DPDP Rules, 2025 requires the Consent Manager to maintain on its platform a record of consents given, denied or withdrawn; notices preceding or accompanying requests for consent; and sharing of personal data with any transferee Data Fiduciary. Item 4(c) requires that such record be maintained for at least seven years, or for such longer period as the Data Principal and Consent Manager may agree upon, or as may be required by law. The record must be accessible to the data principal in machine-readable form on request.

Sources

1. Digital Personal Data Protection Act, 2023 (Act No. 22 of 2023) — Section 6 and Sections 6(7)-(9). MeitY PDF: https://www.meity.gov.in/static/uploads/2024/06/2bf1f0e9f04e6fb4f8fef35e82c42aa5.pdf ; India Code: https://www.indiacode.nic.in/handle/123456789/2002

2. Digital Personal Data Protection Rules, 2025 (G.S.R. 846(E) dated 13 November 2025) — Rule 3 (notice), Rule 4 (Consent Manager registration and obligations), Rule 1 (commencement), Rules 17-22 (Board procedure), First Schedule Parts A and B. MeitY PDF: https://www.meity.gov.in/static/uploads/2025/11/53450e6e5dc0bfa85ebd78686cadad39.pdf ; PIB: https://static.pib.gov.in/WriteReadData/specificdocs/documents/2025/nov/doc20251117695301.pdf

3. RBI Master Direction — Non-Banking Financial Company — Account Aggregator (Reserve Bank) Directions, 2016 (as amended) — https://www.rbi.org.in/Scripts/BS_ViewMasDirections.aspx?id=10598

4. Companies Act, 2013 — India Code: https://www.indiacode.nic.in/handle/123456789/2114

5. CERT-In Directions dated 28 April 2022 — https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf

6. eGazette of India — https://egazette.gov.in/

This playbook is prepared by Veritect Legal Intelligence for general informational purposes and does not constitute legal advice. Rule 4 and First Schedule text verified against the MeitY-hosted DPDP Rules, 2025 gazette PDF. Statutory citations are current as of 21 April 2026. The Data Protection Board of India's interoperability standard and assurance framework under First Schedule Part A, item 9(a) is awaited — prospective applicants should monitor meity.gov.in and the DPBI page for its publication.