How should organisations handle DPDP and GDPR consent requirements in one identity programme?

Why one consent policy engine beats split CIAM stacks

A single policy engine gives you one place to encode consent logic while still varying the rules by jurisdiction, purpose, and user population. That matters because DPDP and GDPR do not create two separate identity problems, they create two rule sets that must be evaluated consistently against the same customer and session data. The operational goal is policy isolation without duplicating the platform.

In practice, this means the identity layer should enforce which notices were shown, which lawful basis or consent state applies, when withdrawal takes effect, and what downstream services may continue to use after a change. When these decisions are centralised, you reduce drift between apps, consent logs, and user preference stores.

For programme design, the important question is not whether consent is collected once or twice, but whether the system can prove the right rule was applied at the right time for the right resident. That is a governance and audit problem as much as a UX problem.

How DPDP and GDPR diverge inside the same journey

DPDP and GDPR can share the same onboarding flow, but they do not always share the same consent semantics, withdrawal handling, or documentation expectations. A workable programme separates the decision engine from the presentation layer so the same journey can branch on residency, purpose, and data category without fragmenting the account model.

That separation is especially important where consent is only one of several legal bases. Some processing may rely on consent in one jurisdiction and a different lawful basis in another, so the platform should not hard-code a single global assumption into forms, APIs, or notification states. The better pattern is jurisdiction-aware policy evaluation with common telemetry and common identity records.

Done well, this also supports change management. If a rule changes, teams update policy once, then re-evaluate the journeys and downstream integrations that consume that policy, instead of rebuilding product-specific consent logic repeatedly.

For identity teams, the practical design choice is to keep jurisdiction logic close to policy and keep enforcement close to the action. That avoids a common failure mode where front-end consent banners say one thing while entitlement, marketing, or profile services behave differently.

What auditors and privacy teams need to see

The control question is whether you can demonstrate consent provenance, rule versioning, and withdrawal effect across the whole identity programme. A reviewer should be able to trace which policy version governed a given user, what text or notice was presented, what choice was captured, and when that choice was propagated to dependent systems.

That is why recordkeeping and event correlation matter as much as the consent screen itself. If the policy engine is correct but preference data is not synchronised to CRM, analytics, or campaign tools, the organisation may still process data against an outdated state. In that sense, consent is only real when every consuming system respects the same authoritative event.

Useful evidence includes policy artefacts, journey screenshots, rule-change logs, withdrawal timestamps, and downstream suppression proof. Those records should show that the programme can support both localised consent obligations and a consistent identity lifecycle.

Where the programme spans vendors, an identity security programme helps define ownership, while identity privacy and consent controls clarify how preference state, notice timing, and withdrawal handling should be governed. For regulatory mapping, the regulatory map is the clearest internal reference point.

Risk and Threat Considerations

Consent drift is the main risk in a shared identity programme: one jurisdiction’s logic gets embedded in a form, API, or downstream workflow, and the organisation can no longer prove that the correct rule was applied. The danger increases when multiple systems store consent independently or when withdrawal is not enforced consistently.

Failure mechanism: A split-stack design creates inconsistent consent states, stale preferences, and weak traceability between the recorded choice and the processing that actually occurred.

Impact: The organisation can expose itself to unlawful processing, failed audit evidence, re-permissioning work, and avoidable customer trust loss, especially when suppression or revocation does not reach every consuming system.

Practitioner Guidance

What to prioritise: Make the policy engine the single source of truth for consent decisions, then verify that all consuming services subscribe to the same state changes. If a service can act on personal data without checking the current policy result, it is outside control.

What to verify: Test both onboarding and withdrawal paths for Indian residents and GDPR-scoped users, and confirm the resulting state changes are visible in logs, preference stores, and downstream suppression lists. The control is only reliable if revocation propagates, not just if collection works.

Practitioner takeaway: Use one shared identity platform with jurisdiction-aware policy, because the real control is consistent enforcement and evidence of decisioning, not parallel consent stacks that eventually diverge.

Related resources from NHI Mgmt Group

• How should security teams handle GDPR requirements in identity programmes?
• How do organisations govern identity attack surface as a programme, not a one-off project?
• How should organisations operationalise GDPR and CCPA consent requirements across systems?
• How should organisations govern multiple credential types in one identity programme?