A preparedness guide, not a claim that all duties apply today
As of 3 November 2026, the substantive consent, notice and Section 7 provisions are scheduled to commence on 13 May 2027. Section 6(9), concerning Consent Manager registration, commences on 13 November 2026. The final Rules were notified in November 2025 and also have phased commencement: Rule 4 one year after Gazette publication; Rules 3, 5–16, 22 and 23 eighteen months after publication. Existing obligations under other applicable laws are not suspended by this timetable.
Read the official Act commencement notification and final DPDP Rules, Rule 1. The architecture below is recommended engineering practice, not a legally mandated product or design.
How can an organisation manage and synchronise user consent across multiple systems?
Maintain an authoritative record for each person and specified purpose, distribute changes to every relevant application, and require those applications to enforce the current state before processing. Treat withdrawal as an operational workflow with acknowledgements and reconciliation, not merely a preference updated in one database.
Under Sections 4 and 7, consent is not the only possible ground for processing. Record the applicable ground separately for each purpose. A lawful service or record-retention activity must not silently become permission for a marketing campaign. For the underlying legal requirements, start with the DPDP consent management guide.
A practical consent architecture
01 · Collect
Notice + purpose choice
Website, app or assisted channel captures the person’s choice and evidence.
02 · Record
Authoritative consent ledger
Verified identity, purpose, current state, notice version and change history.
03 · Enforce
Connected applications
CRM, ERP, campaigns and processors consume updates and confirm the resulting state.
Changes flow out; delivery acknowledgements and reconciliation flow back. A logical source of truth can be implemented within an existing application or a dedicated internal service. It does not require buying a particular platform.
An internal consent service is not automatically a statutory Consent Manager. Section 2(g) defines that role by registration with the Board and acting for Data Principals; Section 6(9) and Rule 4 address registration and conditions.
Seven implementation areas
01 · Privacy lead + system owners
Map data, systems and processing purposes
Inventory collection forms, CRM and ERP records, cloud applications, spreadsheets, data warehouses, campaign tools and processors. For each flow, record the personal data, specified purpose, responsible owner, recipients and retention rule. Include scheduled exports and offline copies, not just applications with an API.
Evidence to keep: A purpose-to-system map showing every destination and the documented processing ground.
02 · Product + privacy
Collect purpose-specific consent at the source
Where consent is the processing ground, show the required notice and capture a clear affirmative choice for the specified purpose. Keep optional marketing separate from responding to an enquiry. A product registration, imported CRM record or email address alone is not proof of marketing consent. Document any applicable Section 7 certain legitimate use rather than treating every activity as consent-based.
Evidence to keep: A tested collection flow with notice version, purpose identifier and affirmative action.
03 · Engineering + privacy
Keep versioned consent evidence
Maintain a logical source of truth for each person and purpose. Record the current state alongside the history: grant or withdrawal time, collection channel, notice version, purpose version and evidence reference. Keep a documented retention policy for evidence; versioning is not a reason to keep personal data forever. Restrict access and avoid putting full personal data into diagnostic logs.
Evidence to keep: A retrievable record connecting the choice to the notice shown at that time.
04 · Identity + CRM teams
Link identities without guessing
Use a stable internal subject identifier and maintain verified mappings to system-specific record IDs. Do not use an unverified email address as the sole identity key: people change addresses, and shared addresses exist. Handle duplicate records, account merges and changes explicitly. Do not infer consent when two identities are merged; resolve conflicting evidence before processing for that purpose.
Evidence to keep: An identity mapping and tests for duplicates, changed addresses and incorrect matches.
05 · Integration + application teams
Distribute changes and enforce them locally
Publish purpose-specific updates through authenticated APIs, webhooks or events. Include a unique event ID, subject ID, purpose, state and monotonically increasing version. Consumers should ignore duplicates and stale events. Each application must check the relevant permission before a job runs or a message is sent; a central record has no effect if downstream tools do not enforce it. For consent-based optional processing, pause rather than assume permission when state is unavailable or ambiguous.
Evidence to keep: Grant, withdrawal, duplicate and out-of-order event tests across every connected system.
06 · Operations + vendor management
Propagate withdrawal to processors and queued work
Make withdrawal as easy as giving consent. Update the source of truth, suppress the affected purpose, cancel or recheck queued work, and instruct processors to cease processing within a reasonable time. Capture acknowledgements and investigate missing ones. Section 6(6) preserves processing without consent where required or authorised by the Act or another law; document that exception rather than using it to continue optional marketing. Separately assess erasure and lawful retention under Section 8(7).
Evidence to keep: An end-to-end withdrawal trace including processor instructions, acknowledgements and queue checks.
07 · Operations + assurance
Monitor failures and reconcile actual behaviour
Track delivery failures, stale copies, missing acknowledgements and processing that contradicts the current purpose state. Use retries with bounded backoff, a failed-event queue and an escalation owner. Reconcile application states against the authoritative record on a defined schedule. Test restoration from backup so an old consent state cannot silently re-enable withdrawn processing. Audit evidence should show the resulting system behaviour, not only successful API calls.
Evidence to keep: A reconciliation report, failure runbook and tested recovery procedure.
Legal anchors: Act Sections 4–7, 8(1), 8(2) and 8(7); Rules 3 and 4. Event IDs, version counters, queues and reconciliation are implementation recommendations, not prescribed statutory formats.
Example: one withdrawal, four connected systems
Illustrative scenario, not a client case study or a claim about native vendor integrations: a person submits a sales enquiry and separately opts into marketing. The organisation uses HubSpot, Salesforce, Microsoft 365 and an email marketing platform. Its integration team must verify the available APIs, account permissions and contract terms for each tool.
When the person withdraws marketing consent, the ledger writes a new withdrawal version. HubSpot and Salesforce stop the affected campaign workflows; Microsoft 365 owners apply the instruction to relevant marketing copies and automations; the campaign platform suppresses the recipient and checks queued sends. Each destination acknowledges the new state. A failed update triggers an alert and pauses the affected optional processing until resolved.
The sales enquiry is assessed independently for its specified purpose and applicable ground. Withdrawal does not automatically require deleting every business record: under Section 8(7), assess erasure and necessary lawful retention, and prevent retained data from being reused for the withdrawn purpose.
Multi-system consent implementation checklist
- Every processing purpose has a documented ground and mapped system owner.
- Consent-based choices are linked to the notice and purpose version shown.
- Identities are verified across systems; duplicate records do not create permission.
- Applications enforce purpose-specific state immediately before processing.
- Duplicate, delayed and out-of-order updates cannot restore withdrawn consent.
- Withdrawal reaches queues, exports and processors; failures have an owner.
- Lawful retention and erasure decisions are separate from marketing suppression.
- A recovery drill and reconciliation report demonstrate downstream behaviour.
Use this as an implementation review, not a compliance certification. For a wider action plan, use the free DPDP readiness checklist.
Multi-system DPDP consent implementation
Discuss your system map, consent records, integration failures and processor withdrawal workflow with Digital Privacy India. Please do not send personal data or live consent records in your enquiry.
Contact Us for Multi-System DPDP Consent Implementation