Imagine a single dashboard where a person can see every consent they've ever granted, across every app, and pull any of them back in one tap. That's the promise of the DPDP consent manager, a new kind of intermediary the Digital Personal Data Protection Act puts between you and the people whose data you process. If you're a data fiduciary building for India in 2026, you'll want to understand what a consent manager is, what a consent artifact holds, and where your integration responsibilities begin and end.

We'll cover the framework, its roots in DEPA and Account Aggregators, the mechanics of consent artifacts, the give-review-withdraw flows, and how registration with the Data Protection Board works. Then what all of it means for how you actually build.

This is general information for engineers and product teams, not legal advice. Confirm specifics with your counsel.

A DPDP consent manager is a registered intermediary that lets a person manage their consent through a single, interoperable interface. The Digital Personal Data Protection Act, 2023 defines it in Section 2(g) as a person registered with the Data Protection Board who acts as the single point of contact to enable a Data Principal to give, manage, review, and withdraw consent through an accessible, transparent, and interoperable platform.

Two words in that definition do a lot of work. Single point of contact means the user does not have to chase down twenty different privacy dashboards across twenty different apps. Interoperable means the consent record has to follow a common format so any participating fiduciary can read and honor it.

It helps to be precise about who is who in this picture. The person whose data is processed is the Data Principal. The organization deciding why and how that data gets processed is the Data Fiduciary, which is probably you. If you are not clear on those roles, our explainer on data fiduciary vs data processor breaks them down. The consent manager is a separate actor that sits alongside both and is accountable to the Data Principal.

A consent manager is not a replacement for your own consent capture. You still ask for consent at the point you collect data. What the framework adds is a standardized, user-controlled layer on top, so the person can see every consent they have granted in one view and pull any of them back without negotiating with each company one at a time.

The DEPA and Account Aggregator lineage

The consent manager idea did not appear out of nowhere with the DPDP Act. It comes from DEPA, the Data Empowerment and Protection Architecture, a framework NITI Aayog published in 2020. You can read the original DEPA draft from NITI Aayog. DEPA proposed a consent artifact as a machine-readable, revocable, granular, auditable record of consent, and a new class of intermediary called a Consent Manager to operate it.

The first place DEPA shipped at scale was financial data. The Reserve Bank of India created the Account Aggregator ecosystem, where a licensed Account Aggregator is a non-banking financial company that moves financial data between institutions only on the basis of an explicit consent artifact. The Account Aggregator is, in DEPA terms, a consent manager for the financial sector. The Sahamati Account Aggregator resources document how that consent artifact is structured in practice.

So the lineage runs like this:

Layer	What it is	Scope
DEPA	The architecture and the consent-artifact concept	Cross-sector blueprint
Account Aggregator	First production implementation, RBI-regulated	Financial data
DPDP consent manager	The statutory version under the DPDP Act	All personal data

The point of the lineage is that the DPDP consent manager isn't a theoretical construct. The financial-sector version already runs in production with millions of consents, so the technical patterns for the consent artifact are field-tested. The DPDP framework just generalizes the same pattern across every kind of personal data.

The core data object is the consent artifact, the same one India's Account Aggregator ecosystem already uses. A consent artifact is a structured, machine-readable record that captures exactly what a person agreed to. It's not a checkbox. It's a signed document with fields.

A consent artifact, following the DEPA and Account Aggregator pattern, typically holds:

Who the data is about, the Data Principal, and who is requesting it
What data is in scope, the specific categories, not a blanket grant
Why, the purpose, stated in plain terms
How long the consent is valid, an expiry
How often the data may be accessed, frequency and a fetch type, one-time or recurring
A unique consent ID so the artifact can be referenced, reviewed, and revoked
A signature so the artifact is tamper-evident

Here is a simplified shape of what a consent artifact looks like as JSON. This follows the public Account Aggregator pattern, it is illustrative, not a NamoID schema:

{
  "consentId": "a4f1c2e0-9b3d-4f5a-8c21-0e7b9d6f1a2c",
  "dataPrincipal": "user-ref-123",
  "purpose": { "code": "01", "text": "Loan eligibility check" },
  "dataScope": ["account.balance", "account.transactions"],
  "frequency": { "unit": "MONTH", "value": 1 },
  "fetchType": "PERIODIC",
  "validFrom": "2026-06-20T00:00:00Z",
  "validUntil": "2026-12-20T00:00:00Z",
  "status": "ACTIVE",
  "signature": "..."
}

Two properties matter most for builders. First, the artifact is granular. The user consents to specific data categories for a specific purpose, not to everything forever. Second, it is auditable. Every artifact has an ID and a status, so you can prove later exactly what was granted, when, and on what terms. That auditability is also what makes a clean DPDP audit trail possible. We cover that in detail in our guide to DPDP audit trail requirements for engineers.

Give, review, and withdraw flows

The DPDP framework gives the Data Principal three rights the consent manager has to support: give consent, review what they have given, and withdraw it. The withdrawal right is the one teams most often under-build, so it deserves attention.

Give

The give flow is a consent request. A fiduciary, or its app, asks for specific data for a specific purpose. The consent manager presents this to the user in plain language, the user approves, and a signed consent artifact is created with a unique ID. The artifact, not a verbal yes, is now the source of truth.

Under Section 6 of the DPDP Act, consent must be free, specific, informed, unconditional, and unambiguous, with a clear affirmative action. A pre-ticked box does not count. Bundling unrelated purposes into one consent does not count.

Review

The review flow is the single-pane-of-glass promise. The user opens their consent manager and sees every active consent, what each one covers, who holds it, and when it expires. This is where the single point of contact language in the definition becomes a product requirement. The user should not need to log into each fiduciary separately to see what they agreed to.

Withdraw

This is the one that changes how you build. The Act is explicit here: withdrawing consent has to be as easy as giving it. A one-click grant paired with a thirty-day email-support withdrawal won't fly.

When a user withdraws, three things have to happen. The consent artifact flips to a revoked status. Any processing that leaned on that consent stops. And the change gets logged. In practice your system needs to react to a withdrawal signal in near real time, so treat revocation as a first-class event, not a quarterly cleanup job.

A consent manager is one piece of a larger consent design. If you're building the broader capture-and-honor layer yourself, the wider DPDP compliance checklist for SaaS puts withdrawal in context with the rest of your obligations.

Registration with the Board

A consent manager is not something you self-declare. Under the Digital Personal Data Protection Rules, 2025, a consent manager must register with the Data Protection Board of India, and the Rules set conditions for that registration. The official rules are published by MeitY.

The Rules attach obligations to a registered consent manager, including a minimum net worth, an obligation to act in a fiduciary capacity toward the Data Principal, technical interoperability requirements, and a duty to keep records of consents and data-sharing. The Board may suspend or cancel registration for non-compliance.

For most teams reading this, the practical takeaway is a clean separation of concerns:

If you are	Your job is
A Data Fiduciary, most product teams	Capture valid consent, honor artifacts, react to withdrawal, keep your own audit trail
A Consent Manager	Register with the Board, run the interoperable platform, meet net-worth and fiduciary-duty conditions

You probably do not want to become a registered consent manager. That is a regulated, capital-intensive role. What you do need is to be ready to integrate with consent managers and to honor the artifacts they produce.

What this means for how you build

Here is the engineering translation of everything above.

Model consent as an artifact, not a boolean. A consents table with a user_id and a marketing = true column will not survive a DPDP audit. You need per-purpose records with a scope, a purpose, an expiry, a status, and an ID. Store the artifact, not the click.

Make withdrawal a real-time event. Because withdrawal must be as easy as giving, wire revocation into an event that immediately flips artifact status and halts dependent processing. An append-only event log is the cleanest way to do this, and it doubles as your audit trail. NamoID is built around exactly this pattern: every state change, including consent and provider connections, appends an immutable event, and a DSAR export endpoint returns a user's full event history plus connected providers.

Keep purpose-scoped records you can export. When a Data Principal exercises a data-subject right, you need to produce what you hold and on what basis. If your consent records are scattered across feature flags and CRM fields, that export is painful. Centralize it.

Tie consent to verification where it matters. India verification rails like DigiLocker, Aadhaar offline e-KYC, and Truecaller each carry their own consent step. NamoID is built to put those rails behind a single OIDC issuer, so the consent moment and the verification moment are captured together. For the verification side, see our DigiLocker API integration guide.

A short code sketch of an OIDC authorization request, the moment where a verification consent often originates, looks like this. NamoID is built to enforce PKCE on every flow:

curl -G "https://issuer.example.com/v1/oauth/authorize" \
  --data-urlencode "response_type=code" \
  --data-urlencode "client_id=your-client-id" \
  --data-urlencode "redirect_uri=https://app.example.com/callback" \
  --data-urlencode "scope=openid profile" \
  --data-urlencode "code_challenge=$CODE_CHALLENGE" \
  --data-urlencode "code_challenge_method=S256"

The broader design goal is to stop treating consent, verification, and audit as three separate systems. They are one flow. The DPDP consent manager framework, the DEPA artifact, and your own audit log all point at the same thing: a record of who agreed to what, why, for how long, and how they can take it back.

FAQ

No, but they are close relatives. An Account Aggregator is a consent manager for financial data, regulated by the RBI under the DEPA framework. A DPDP consent manager is the statutory, cross-sector version under the DPDP Act, covering all personal data and registered with the Data Protection Board. Same consent-artifact pattern, broader scope.

Almost certainly not. Registration is for organizations that want to run the consent-management platform itself, and it carries net-worth and fiduciary-duty conditions under the DPDP Rules, 2025. Most product teams are data fiduciaries. Your job is to capture valid consent, honor consent artifacts, and react to withdrawal, not to operate the platform.

What does "withdrawal must be as easy as giving" actually require?

It means you cannot make granting consent a single tap and withdrawing it a support ticket. Practically, you need a user-facing way to revoke, a system that flips the consent artifact to revoked, and processing that stops when it does. Treat revocation as a real-time event, not a batch job. This is general information, not legal advice.

Each artifact carries a unique ID, a scope, a purpose, an expiry, and a status, so you can prove exactly what was granted and when. Pair that with an append-only event log and you have a defensible audit trail. See our DPDP audit trail requirements for the engineering details.

Talk to us

NamoID is built to put India's verification rails and a clean, exportable consent and audit trail behind a single OIDC issuer, so consent, verification, and audit live in one place instead of three.

If you are designing for the consent-manager era and want to talk through your integration, book a demo at https://calendly.com/polymindslabs/30min or reach us at hello@namoid.in.