Introduction

Compliance with SOC 2 and India DPDP now demands more than annual audits. As DPDP rules prepare for May 2027 enforcement, organizations face a fundamental question: how to consistently prove who accessed personal data, when, and under what entitlement across both frameworks. The gap between a SOC 2 audit snapshot and DPDP's ongoing requirements reveals a growing risk exposure.

What Happened

The article exposes how SOC 2 access reviews and DPDP access lists often emerge from separate identity exports, producing divergent answers. Security teams pull user lists from identity providers while privacy teams build their own lists from different system exports. Factors like nested group memberships, vendor accounts filtered out of one export but kept in another, and service accounts create mismatches. When a regulator, auditor, or customer asks who could reach a specific record on a specific day, two lists can give two answers—one of which may trigger a penalty of up to ₹250 crore under the DPDP Act's Schedule of penalties.

Why This Matters

The real risk emerges after the audit period closes. New API tokens, vendor integrations, changing admin groups, and drifting cloud configurations mean that a SOC 2 report from six months ago may no longer reflect the current state. Verizon's 2026 DBIR found a third party involved in 48% of breaches, up from 30% the prior year, highlighting persistent third-party risk. Both frameworks demand controls that survive beyond a single examination window. The engineering question becomes urgent: for any timestamp in the recent past, can your systems definitively show who held access to customer data, which entitlement granted it, and what that access touched? When two teams answer separately and their answers differ, the compliance gap widens.

Key Takeaways

The solution lies in building one control and letting both frameworks read the same evidence. A single quarterly access review—removing unnecessary access to systems holding customer data—can serve SOC 2's logical access criteria (CC6) and DPDP Rule 6 simultaneously. Map this control in a plain table under version control, tagging each record with the supporting control and source system. Critical evidence includes one record per event with actor, action, resource, and outcome—for example, example: svc-payment WRITE customer_profile_db DENIED. Tag each entry with its controlling framework and originating system.

Identity events must capture who the actor is, drawn from the identity layer across cloud IAM, PAM, application roles, databases, and SaaS. API access at gateways should log caller, endpoint, resource, data class, outcome, and a correlation ID. Direct database sessions, batch jobs, and admin access that bypass the gateway need separate logging. Consent withdrawals require an event with ID, old and new state, and source system, with downstream acknowledgment and a reconciliation job that compares consent state across platforms.

Logs only help if they survive. Store logs in append-only, tamper-resistant storage with encryption and hash integrity checks. Synchronize clocks across gateways and databases; time drift obscures event ordering. For DPDP Rule 6, retain logs for at least one year, mask personal data at the source, and ensure a green dashboard is backed by run records—scheduled checks like MFA enforcement or dormant account scans should log pass/fail status, failed runs must trigger tickets with root causes, and passing runs need records too.

The layer still breaks where legacy systems lack APIs, duplicate identities inflate person counts, and stale mappings persist after architecture changes. Address legacy gaps with adapters and named owners. Resolve duplicate identities by configuring the compliance platform to consolidate them on schedule. Review control mappings whenever systems shift, assigning one owner per control to keep evidence current.

The simplest test: collect 30 days of evidence on three shared controls—access reviews, vendor access, and security logging—then pick a date and attempt to rebuild it. Who had access? What did they touch? Which checks ran, and who fixed failures? If the answer takes a week to assemble, that's the first build priority. If an hour suffices, you're positioned for May 2027.

Conclusion

May 2027 is the DPDP enforcement deadline, but the evidence gap starts now. The test is simple: can your systems reconstruct a single day's access and logging state without digging through tickets and outdated exports? If not, the first build should focus on identity entitlements, API-level audit logs, and consent event tracking. Whatever date you pick, your systems should already have written it down.