Who is accountable when DPDP controls fail in a multi-cloud environment?

Why This Matters for Security Teams

DPDP accountability fails most often in the gap between legal obligation and technical ownership. In a multi-cloud estate, privacy duties do not disappear because workloads span regions, accounts, or platforms. Someone still has to prove that collection, retention, access, deletion, and breach handling are controlled end to end. That is why control ownership must be explicit, not implied by tooling. NIST’s NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it separates policy intent from operational control execution.

The real risk is that cloud teams assume vendor responsibility covers compliance, while business teams assume the platform team has already solved it. That leaves gaps in evidence, exception handling, and incident response. Under DPDP-style obligations, accountability is not a shared abstraction. It must be traceable to a named owner who can answer who approved the control, who monitors it, and who signs off on exceptions. In practice, many security teams encounter failure only after a privacy review, regulator query, or incident has already exposed the missing ownership chain.

How It Works in Practice

Operationally, accountability should be assigned by control domain rather than by cloud platform. The business owner owns the lawful purpose and retention requirement. The security function owns control design, assurance, and detection. The platform or cloud engineering team owns implementation, change management, and rollback discipline. Where personal data spans multiple clouds, those roles need one control register that maps each DPDP obligation to a named owner, evidence source, and review cadence.

A workable model usually includes:

• A data classification standard that identifies which workloads contain regulated personal data.
• A control inventory that maps each obligation to technical and procedural safeguards.
• A RACI or equivalent decision matrix that defines who approves, who executes, and who attests.
• Continuous logging and access review so ownership is supported by evidence, not spreadsheets alone.
• Exception handling with expiry dates, compensating controls, and documented risk acceptance.

For control design, teams can anchor on CISA Cross-Sector Cybersecurity Performance Goals and map operational safeguards to a privacy governance model. Where privileged access or automation touches personal data, the accountability chain should also cover service accounts, API keys, and administrative entitlements, because those are often the fastest path to uncontrolled disclosure. If the organisation uses multi-cloud policy engines, the policy author is not automatically the control owner. Current guidance suggests the owner must also validate that the policy is deployed, monitored, and recoverable.

This guidance breaks down when responsibility is split across separate legal entities or unmanaged subsidiaries, because no single team can evidence control performance across all processing environments.

Common Variations and Edge Cases

Tighter accountability often increases coordination overhead, requiring organisations to balance clearer ownership against slower change velocity. That tradeoff is unavoidable in regulated environments, especially where multiple cloud tenants, shared services, and outsourced operations overlap.

There is no universal standard for this yet, but best practice is evolving toward a single accountable owner per compliance obligation, with delegated execution across teams. That distinction matters in shared responsibility models: the cloud provider may own infrastructure security, but the organisation still owns lawful processing, access governance, retention, and evidence production. If a third party processes personal data, contract terms and assurance reviews should confirm who maintains the control and who reports failures.

Edge cases appear when automation or AI agents trigger data processing in real time. In that case, the ownership model should extend to the workflow that initiated the action, not just the cloud service hosting it. Where the environment includes sovereign cloud, regional residency rules, or incident-driven data transfer exceptions, the accountable owner should also decide whether the exception is acceptable under policy and whether notification duties are triggered. For controls that rely on vendor-native features, the organisation should verify that settings remain effective after upgrades, drift, and failover events, because control inheritance can be weaker than teams assume.

For identity-heavy control points, NIST SP 800-63 Digital Identity Guidelines can help frame assurance for authentication and session handling. In practice, the hardest failures emerge when ownership is documented in policy but not embedded in cloud change control, so the last approved design no longer matches the live estate.

Related resources from NHI Mgmt Group

• Who is accountable when privileged access controls fail in cloud environments?
• Who is accountable when cloud AppSec controls fail in the SDLC?
• How do I manage NHI security in a multi-cloud environment?
• Who is accountable when administrative access controls fail in CMMC assessments?