DPDP Consent Manager Integration — Architecture for Indian SaaS

What a Consent Manager is and is not

A Consent Manager is a third-party service registered with the Data Protection Board that facilitates consent on behalf of data principals. It is not a CRM, not a tracking platform, not a marketing tool. The Manager has fiduciary duty to the data principal — it cannot use the consent data for its own commercial purpose. India's Consent Manager ecosystem builds on the Account Aggregator framework (RBI) and the Data Empowerment and Protection Architecture (DEPA).

When you must use a Consent Manager vs direct collection

DPDP allows both direct consent collection and Consent Manager mediation. Use a registered Consent Manager when: (1) consent flows cross multiple parties (AA framework, multi-party data sharing), (2) you process volumes large enough that managing the audit trail in-house is expensive, (3) your sector has Manager mandates emerging (financial services via RBI, healthtech via Ayushman Bharat Digital Mission). Use direct collection when: simple direct B2C SaaS with clear single-purpose data flows.

5-step integration architecture

Production-grade Consent Manager integration follows five steps:

• Step 1: Register your data fiduciary identity with the Consent Manager (one-time onboarding, typically API key + signing certificate)
• Step 2: Define consent artifacts — purpose statement, data categories, retention period, sharing parties — per your data flows
• Step 3: Implement the consent request flow — redirect to Manager UI or embed Manager iframe for consent capture
• Step 4: Implement consent verification webhook — every data access checks the Manager for current consent status (cache TTL ≤ 60 seconds for safety)
• Step 5: Implement the withdrawal handler — subscribe to revocation events, purge dependent data within the prescribed deletion window

Audit trail requirements (Schedule I obligation 7)

Every consent-related event must produce a tamper-evident log entry: consent grant, renewal, withdrawal, and every data access that relied on a specific consent. Log fields: timestamp (ms-precision), data principal identity hash (not the raw identifier), consent artifact reference (the consent ID), the data accessed, the system/user that accessed it, and the authorisation chain. Logs must be retained for the regulator-specified period (currently 1 year per draft rules) and made available on Data Protection Board request within 72 hours.

Common Consent Manager integration vulnerabilities

From our DPDP reviews — the most common defects:

• Stale consent caching (cache TTL too long → revoked consent still allowing access)
• Webhook signature verification missing (anyone can forge withdrawal/grant events)
• Withdrawal handler not idempotent (replays cause duplicate purge attempts)
• Audit log missing the consent artifact reference (cannot map a data access back to the consent it relied on)
• Dependent data not purged on withdrawal (only primary record deleted; analytics aggregates retained)
• Manager API credentials in code (should be in secret store + rotated periodically)

Get a Consent Manager integration review

Bachao.AI's DPDP gap analysis includes a Consent Manager integration review covering all 6 common defect classes above, mapped to Schedule I obligation 7 + Data Protection Board draft rules. Free first review covers a baseline scan; full review extends to load testing and replay-attack simulation.