Statutory Consent Managers

DPDP — not yet effective

Section 6(9), section 27(1)(d), Rule 4 and the First Schedule are scheduled for 13 November 2026.

A statutory Consent Manager is a person registered with the Board who enables a Data Principal to give, manage, review and withdraw consent through an accessible, transparent and interoperable platform. It is not a synonym for a customer’s consent banner, preference centre or consent API.

Registration conditions

The First Schedule requires, among other things:

• a company incorporated in India;
• sufficient technical, operational and financial capacity;
• sound financial condition and management;
• net worth of at least ₹2 crore under the Schedule’s definition;
• fit and proper directors, key managerial personnel and senior management;
• constitutional documents embedding conflict-related obligations and Board approval for change;
• operations in Data Principal interests;
• independent certification of platform consistency with Board-published data-protection standards and assurance framework, plus appropriate controls.

As of the cut-off, Board standards/certification mechanics and a production application interface were not verified. OpenDPDP defines extension points and does not invent them.

Operating obligations

The platform must:

• route consent directly or through another onboarded Fiduciary;
• ensure shared personal-data content is not readable by the Consent Manager;
• retain consent grant/deny/withdrawal, preceding/accompanying notices and sharing records;
• give the Principal access and machine-readable export;
• retain records at least seven years, longer if agreed or required by law;
• provide a website/app as the primary service;
• not subcontract or assign statutory obligations;
• apply reasonable security safeguards and act in a fiduciary capacity;
• avoid institutional and personal conflicts with Data Fiduciaries;
• publish promoters, leadership, >2% shareholders and specified related interests;
• operate effective audits and report outcomes to the Board;
• obtain prior Board approval for transfer of control.

Hard architecture separation

flowchart LR
  subgraph Enterprise["Enterprise privacy product"]
    E1[Customer notices and purposes]
    E2[Consent receipts]
  end
  subgraph Statutory["Registered operating entity boundary"]
    C1[Principal platform]
    C2[Consent routing]
    C3[Seven-year record and export]
    C4[Governance and audit]
  end
  F1[Onboarded Fiduciary A] <--> C2
  F2[Onboarded Fiduciary B] <--> C2
  C1 --> C2
  C2 --> C3
  C4 -. oversight .-> C2
  E1 -. versioned public adapter only .-> C2

Separate legal entity, tenancy, credentials, keys, staff access, audit, release approvals, financial records, conflicts and branding. A shared codebase may be possible, but an enterprise customer administrator must never gain statutory platform access.

Interoperability contract

Until an official standard is verified, expose only a vendor-neutral adapter:

requestConsent(requestVersion, fiduciaryRef, principalRef, noticeDigest, purposeDigest)
routeInstruction(routeVersion, sourceFiduciaryRef, destinationFiduciaryRef, encryptedPayloadRef)
recordDecision(decision, proof, occurredAt)
withdrawConsent(consentRef, idempotencyKey)
exportPrincipalRecord(formatVersion)

Fields specific to an unidentified government or Board API remain unverified.

No-readability proof

Use end-to-end encryption between sharing Fiduciaries where the Consent Manager holds routing metadata but no payload decryption key. Test that logs, traces, dead letters, support tooling and backups do not expose content. Metadata still requires minimisation and safeguards.

Acceptance tests

• Given no Board registration, when public copy is rendered, then no registered-status claim or registration number appears.
• Given a sharing payload, when inspected by Consent Manager staff and observability systems, then only encrypted content and minimal routing metadata are accessible.
• Given an audit export, then records remain available for seven years and include notice and sharing linkage.
• Given a request to subcontract the statutory routing duty, then policy rejects it.