Policies · eGov
With India's DPDP security rules taking effect in May 2027, organisations running SOC 2 programmes face a practical engineering challenge: building one shared evidence layer that satisfies both frameworks continuously, not just at audit time.
✦ AI SUMMARY 30-second read
- Rule 6 of the DPDP security rules requires logs that detect unauthorised access to personal data, with specified logs retained for at least one year.
- Verizon's 2026 DBIR found a third party involved in 48% of breaches, up from 30% the prior year, with missing MFA and unrotated credentials cited as recurring factors.
- Failing to take reasonable security safeguards under the Act's Schedule can attract a penalty of up to ₹250 crore.
Why it matters: Organisations that rely on point-in-time audits risk being unable to reconstruct who accessed personal data on any given past day, which is precisely what Rule 6 demands.
This summary was generated by AI. Editors may review and update it.
Document details
| Document type | Rules & Regulation |
|---|---|
| Issued by | Government of India |
| Region | India |
| Published | 2 November 2026 |
India's DPDP security rules come into force in May 2027. Rule 6 requires logs and monitoring capable of detecting unauthorised access to personal data, and specified logs must be kept for at least one year. The rules pose a question that a conventional annual audit was not designed to answer.
A SOC 2 report confirms that controls worked during a defined examination period. The difficulty begins the moment that period closes, as API tokens are issued, vendors connect new integrations, admin groups change and cloud settings drift. Both frameworks ultimately demand the same underlying evidence, yet many organisations produce it twice, from separate exports, with results that can differ.
What the document says
For SOC 2, security teams typically conduct quarterly access reviews: an engineer pulls a user list from the identity provider, managers approve it in a ticket, and the file goes to a GRC tool. Privacy teams build a separate list for DPDP from a different export. The two lists diverge because one counts members of nested groups while the other counts only direct access; vendor and contractor accounts may appear in one but not the other; service accounts get filtered in one export and retained in the other.
The proposed fix is a single control that both frameworks read from the same evidence. A plain, version-controlled mapping table can link one access review to SOC 2's CC6 logical access criteria and simultaneously to Rule 6's requirement for measures that control access to systems processing personal data. Each event in the underlying log should record the actor, action, resource and outcome in a consistent format, with tags identifying the control it supports and the system it came from.
Consent withdrawals, API calls and identity changes each need to record themselves as discrete events. A withdrawal should carry an ID, the old and new state, and confirmation from every downstream system. A reconciliation job should compare consent state across systems and surface mismatches before a customer complaint does.
Who is affected
Any organisation processing personal data under the Act that also holds a SOC 2 programme is directly in scope. The challenge extends to service accounts, vendor logins and API keys, which have no manager to prompt renewals and can remain active far longer than staff accounts.
Legacy systems with no API present an additional gap, requiring adapters that write the same tagged records and a named owner responsible for keeping them current. Duplicate identities compound the problem: a compliance platform collecting evidence across duplicate accounts treats one person with three accounts as three separate people.
Background
Verizon's 2026 DBIR found a third party involved in 48% of breaches, compared with 30% the previous year. The report also points to missing MFA and credentials that are never rotated, both of which can emerge months after an audit has closed.
GRC tools can only collect what systems already record. The evidence store is an output of the control plane itself, which means the systems producing records must be configured correctly before any compliance platform can read them.
What happens next
The document proposes a practical readiness test: collect evidence for 30 days across three controls that both frameworks share — access reviews, vendor access and security logging — then select a past date from that period and attempt to reconstruct it fully. Wherever the answer is missing, a gap exists that no audit sample has yet exposed.
Logs must be stored in a location that source systems cannot modify, with encryption, hashing to detect changes and synchronised clocks across systems. Each scheduled automated check should write a run record regardless of whether it passes or fails, and every failed check should open a ticket linking back to the run that identified it. For logs covered by Rule 6, one year is the minimum retention period, with the actual period also reflecting the SOC 2 examination window and investigation requirements.
Stale control mappings are flagged as a recurring risk. The mapping table must be reviewed whenever the architecture changes — such as when an application moves to a new identity platform or a new processor takes on a copy of customer data — and each control should have a single named owner accountable for its evidence.