India's DPDP security rulescome into force in May 2027, and they ask a question an annual audit was never built to answer. Rule 6 expects logs and monitoring that help detect unauthorised access to personal data, and specified logs must be kept for at least one year. A SOC 2 report proves that controls worked during one examination period. The trouble starts the day that period closes. New API tokens get issued, vendors connect new integrations, admin groups change and cloud settings drift. That is where the real risk sits.
Verizon's 2026 DBIR found a third party involved in 48% of breaches. A year earlier, the figure was 30%. The report also points to missing MFA and credentials that are never rotated. Both can appear months after an audit has closed. So the audit question turns into an engineering one: for any timestamp last month, can your systems show who held access to customer data, under which entitlement, and what they touched? Two teams often answer it separately, and the answers can differ.
SOC 2 Access Reviews and DPDP Access Lists Often Come From Different Exports
For SOC 2, the security team reviews access every quarter. An engineer pulls the user list from the identity provider, managers sign it off in a ticket, and the file goes to the GRC tool. The privacy team builds its own list for DPDP from a separate export, pulled by someone else.
The two lists often differ, for simple reasons. One counts members of nested groups and the other counts only direct access. Vendor and contractor accounts often live in other systems, so one list can miss them. Service accounts get filtered out of one export and kept in the other. An export is also a snapshot, so anyone whose access changed after it was pulled is already out of date.
This becomes a problem when a customer, auditor or regulator asks who could reach a specific record on a specific day. Two lists give two answers. Under the Act's Schedule, failing to take reasonable security safeguards can attract a penalty of up to ₹250 crore. A record built after the fact is only a reconstruction, which is why the fix has to start where the evidence is created.
Build the Control Once and Let SOC 2 and DPDP Read the Same Evidence
A framework reads a control. It does not own one. Take a single control: access to systems holding customer data is reviewed every quarter, and access nobody needs is removed. SOC 2 can use it as evidence for the logical access criteria in CC6. DPDP reads the same control under Rule 6, which asks for measures to control access to the systems that process personal data. Keep that mapping in a plain table under version control, so any change to it is reviewed like a code change.
What matters is what the control leaves behind: one record per event, with the actor, action, resource and outcome. "svc-payment WRITE customer_profile_db DENIED" is a good example. It shows who tried, what they tried, where, and that the control stopped it. Tag each record with the control it supports and the system it came from, and both frameworks can read the same entry.
This is also where GRC tools reach their limit, since they can only collect what systems already record. The evidence store is an output of the control plane. A GRC platform can read from it, but it cannot create it. That only works if the systems producing the records are set up for it, and the first one to set up is identity.
Each Access Change, API Call and Consent Withdrawal Should Record Itself
Identity. Who the actor is comes from the identity layer. What they can reach comes from entitlements, which are spread across cloud IAM, PAM, application roles, databases and SaaS. Build the quarterly review from current entitlements, and attach the ticket to every removal. Service accounts, vendor logins and API keys go in the same review. They have no manager to chase and can stay active far longer than a staff account. Scope them, set an expiry and log what they access.
API access. At the gateway or service boundary, log the caller, endpoint, resource, data class, outcome and a correlation ID. Direct database sessions, batch jobs and admin access skip the gateway, so they need their own logs.
Consent events. A withdrawal becomes an event with an ID, the old and new state, and the system that sent it. Every downstream system must acknowledge it. A missing acknowledgement triggers a retry, then an alert. A reconciliation job compares consent state across systems and logs the result, so a mismatch surfaces before a customer complains.
All of these events end up in logs, and logs only help if they survive.
A Green Dashboard Needs Logs and Run Records to Count as Proof
A green dashboard shows the state of the dashboard. It says nothing about what happened six months ago. That answer sits in two places: the log store and the history of every check that ran.
Store logs somewhere the source systems cannot reach. Restrict who can delete, encrypt the data, and use hashes so any change shows up. Watch the clocks as well. When the gateway and the database disagree on the time, nobody can say which event came first. Append-only storage cannot prove that nothing was removed either. For logs covered by Rule 6, one year is the minimum, and the real period should also reflect the SOC 2 examination window and investigation needs. Mask personal data in logs at the source.
Each scheduled check, such as MFA enforcement, public storage or dormant accounts, should write a run record whether it passes or fails. Every failed check should open a ticket with a root cause, the fix and a link to the run that found it. A sample can land on any date, so passing runs need a record too.
Where an Evidence Layer Still Breaks: Legacy Systems, Duplicate Identities, Stale Mappings
Legacy systems are the first gap. An ERP with no API needs an adapter that writes the same tagged records, and a named owner who keeps it working. Duplicate identities are the second. A compliance platform placed over duplicate identities will collect the duplicates on schedule, so one person with three accounts shows up as three people.
Stale mappings are the third. Earlier, one table tied the access review to CC6 and Rule 6. Six months on, the application has moved to a new identity platform, a new SaaS processor holds a copy of customer data, and a reporting database now stores personal data. The table still says the old evidence is enough. Review the mapping every time the architecture changes, and give each control one owner who answers for its evidence.
The Test Is Simple: Rebuild a Past Day From the Evidence
Collect evidence for 30 days on three controls both frameworks read: access reviews, vendor access, and security logging. Then pick a date from that period and rebuild it. Who had access, what did they touch, which checks ran, and who fixed the ones that failed? Wherever the answer is missing, you have found a gap no audit sample has hit yet. If an hour is enough, you are in good shape for May 2027. If it takes a week, you know what to build first.
Whatever date gets picked, your systems should already have written it down.
