Who is accountable when a personal data breach happens under the DPDP Rules?

Why This Matters for Security Teams

Accountability for a personal data breach under the DPDP Rules is not just a legal question. It determines who must detect, assess, notify, document, and remediate, often under compressed timelines and public scrutiny. For most organisations, that responsibility sits with the data fiduciary, even when a processor, cloud provider, or managed service partner contributes to the failure.

The practical risk is that breach response becomes fragmented when privacy, security, legal, and operations teams each assume another group owns the next step. Strong accountability is therefore a governance control, not only a compliance obligation. A useful benchmark for control design is NIST SP 800-53 Rev 5 Security and Privacy Controls, which ties incident handling, auditability, and response coordination to clearly assigned responsibilities.

For organisations with large-scale processing or sensitive datasets, the accountability burden rises because notification decisions, evidence preservation, and third-party oversight must be repeatable and defensible. In practice, many security teams encounter accountability gaps only after a breach has already forced cross-functional escalation, rather than through intentional breach governance design.

How It Works in Practice

In operational terms, the data fiduciary remains the primary accountable party because it decides why and how personal data is processed, sets the control baseline, and answers to the regulator and affected individuals. If a breach occurs, the fiduciary must coordinate containment, determine the scope of exposure, assess harm, and decide whether notification thresholds are met. Processors can be contractually obligated to support these duties, but delegation does not transfer the underlying accountability.

Effective breach governance usually depends on four things:

• Clear assignment of incident ownership across security, privacy, legal, and business continuity teams.
• Logging and evidence retention that can support root-cause analysis and notification decisions.
• Contractual obligations for processors and subprocessors to report incidents quickly and preserve records.
• Pre-approved decision paths for notification, external communications, and remediation.

Where relevant, organisations often map these duties to broader privacy and cyber obligations such as the EU General Data Protection Regulation (GDPR) and threat-informed response practices described in the ENISA Threat Landscape. That combination helps teams connect legal accountability with operational detection, escalation, and containment. The same approach becomes especially important where agentic AI systems can access personal data, because tool misuse, prompt injection, or over-permissioned workflows can create a breach pathway without a conventional malware event. These controls tend to break down when breach triage is outsourced informally to a vendor because the fiduciary still lacks complete telemetry and decision authority.

Common Variations and Edge Cases

Tighter breach governance often increases coordination overhead, requiring organisations to balance fast notification against the need for accurate scope and impact assessment. That tradeoff becomes sharper when multiple entities share the processing chain, or when a platform provider hosts data but does not control the processing purpose.

Current guidance suggests the following edge cases deserve special handling:

• Joint processing arrangements, where more than one entity may influence breach decisions and public communications.
• Cross-border processing, where local breach rules, sector expectations, and contractual notice windows may differ.
• Significant data fiduciaries, where stronger oversight expectations make governance failures more visible and less defensible.
• AI-enabled workflows, where data exposure may occur through model inputs, retrieval layers, logs, or agent actions rather than a simple database compromise.

For high-risk environments, the accountability model should also account for identity and privilege. If an attacker or compromised agent can access broad secrets, tokens, or personal data stores, the fiduciary will still be the accountable party even when the technical fault sits elsewhere. In that sense, breach accountability is less about blame after the fact and more about whether the organisation had authority, visibility, and control before the incident. Where those conditions are absent, the framework breaks down most often in decentralised SaaS estates with weak logging and unclear processor contracts.

Related resources from NHI Mgmt Group

• Who is accountable when personal data transfers or breach handling fail under the DPDPA?
• How should organisations govern privileged access to personal-data systems under DPDP rules?
• Who is accountable when a processor mishandles personal data under GDPR?
• Who is accountable for access to retained data under lawful-access rules?