Who is accountable for DPDP compliance when multiple teams handle personal data?

Accountability should sit with clear owners across business, legal, security, and engineering, led by a responsible privacy function or privacy leader. DPDP expects decision rights, escalation paths, and enforceable controls, not informal coordination. If ownership is diffuse, organisations struggle to prove who approved data use, who monitors controls, and who responds when a breach or rights request occurs.

Who actually owns DPDP compliance when work is split across teams?

When personal data is handled by product, operations, security, legal, and engineering, accountability cannot be left as a shared assumption. The practical answer is that one function must own the compliance outcome, while each contributing team owns the controls and decisions inside its scope. That distinction matters because DPDP compliance is not just about policies on paper; it is about provable decisions, documented purpose, retention, consent or notice handling, and response readiness.

This is where many organisations drift into ambiguity. A privacy lead or equivalent accountable owner is needed to coordinate the programme, but that role only works if business owners, data stewards, and technical teams have named responsibilities and escalation paths. NHI Mgmt Group’s research shows how often control gaps persist when ownership is unclear, especially around lifecycle and access governance; for example, only 20% of organisations have formal offboarding and revocation processes for API keys and just 5.7% have full visibility into service accounts. Ultimate Guide to NHIs — Regulatory and Audit Perspectives

In practice, teams usually discover the accountability gap only after a rights request, audit, or incident forces them to reconstruct who approved what.

How DPDP accountability works in practice across shared data workflows

DPDP accountability should be organised around decision ownership, not just task completion. The accountable owner is the function that can answer for why personal data is collected, how it is used, where it is shared, how long it is kept, and what happens when an individual exercises rights or a breach occurs. Other teams may execute those duties, but they do not replace the need for a single owner who can evidence the whole chain.

A workable model usually separates three layers:

Business ownership: defines the purpose, lawful use, and retention need for each processing activity.
Privacy and legal oversight: interprets DPDP obligations, reviews notices, cross-border or disclosure issues, and approves exceptions.
Security and engineering execution: implements access controls, logging, segregation, deletion, and response workflows.

That structure is strongest when every high-risk processing activity has a named data owner, a privacy reviewer, and a technical controller. It also needs a single register of processing activities, because accountability breaks down when the data map, system inventory, and exception log live in different places. For teams managing tokens, service accounts, or automated workflows that touch personal data, the same rule applies: the owner must be able to show who can access the data, why that access exists, and how it is revoked. Ultimate Guide to NHIs — Lifecycle Processes for Managing NHIs EU General Data Protection Regulation (GDPR)

In mature setups, RACI-style mapping is useful only if it is backed by approval logs, review cadence, and enforcement in change management. If a team can deploy a new data flow without privacy review, the governance model is decorative rather than accountable. NIST Cybersecurity Framework 2.0

These arrangements tend to break down in fast-moving product environments where teams can create new processing paths faster than governance can update ownership records.

Where shared ownership becomes fragile and what good looks like

Clearer ownership often increases coordination overhead, so organisations have to balance speed against evidentiary control. The trade-off is real: the more teams touch personal data, the more likely accountability fragments unless the organisation enforces one source of truth for decisions and one escalation route for exceptions.

Edge cases often appear in outsourced operations, embedded analytics, and platform teams that support many products at once. Best practice is evolving here, but the current guidance suggests that “everyone involved” is not an acceptable accountability model. Instead, organisations should insist on one accountable owner per processing activity, even when execution is distributed. That owner should be able to prove four things: the purpose is defined, the controller is named, the access path is restricted, and the response path is tested.

Practitioners should also watch for false comfort in committee governance. Committees can coordinate, but they do not own incidents, notices, or regulatory responses. If a breach or rights request spans multiple teams, accountability should still resolve to a specific role that can make timely decisions, assign remediation, and sign off on closure. Where the same data set is reused across products, the right question is not who touched it last, but who can demonstrate ongoing control over its authorised use and deletion. Ultimate Guide to NHIs — Key Research and Survey Results

The strongest programmes treat accountability as an operating model, not a document, and they fail fastest when ownership exists on paper but not in workflow approvals, monitoring, or incident response.

Risk and Threat Considerations

Diffuse accountability creates governance and exposure risk because no single owner can reliably prove lawful processing, access restraint, or timely response. That gap matters under DPDP because failures usually surface at the points where evidence is needed most: a complaint, a breach, a deletion request, or an audit.

Failure mechanism: Shared responsibility without a named accountable owner leads to missed approvals, inconsistent retention, untracked sharing, and weak escalation. In technical environments, the same weakness often appears as unmanaged access paths, stale credentials, or orphaned service accounts that continue processing personal data after the business context has changed.

Impact: Organisations can lose the ability to show who authorised processing, who controlled access, and who was responsible for remediation. That increases regulatory exposure, slows breach response, and can leave personal data flowing through systems no team actively owns.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM — Risk Management Strategy	Maps accountability for data-processing risk ownership and escalation.
	GV.OV — Oversight	Applies to governance oversight when many teams share privacy duties.
Recommendation — Assign clear risk owners for personal-data processing and keep escalation paths enforceable. Define oversight checkpoints that prove privacy decisions were reviewed and approved.
CIS Controls v8	6 — Access Control Management	Relevant because accountable DPDP control depends on restricting who can access personal data.
	8 — Audit Log Management	Needed to evidence who approved, accessed, or changed personal-data handling.
Recommendation — Review and revoke personal-data access paths when ownership or purpose changes. Log privacy approvals and data-access changes so accountability can be proven later.
OWASP Non-Human Identity Top 10	NHI-01 — Secrets and Credential Inventory	Applies when shared workflows use service accounts or tokens to process personal data.
Recommendation — Inventory all machine credentials that can touch personal data and assign an owner.

Practitioner Guidance

What to prioritise: Assign one accountable owner per personal-data processing activity, then name the supporting business, privacy, security, and engineering roles that execute parts of the control chain. If a workflow cannot point to a single decision-maker for approval, retention, and exception handling, it is not yet governable enough for audit or incident response.

What to verify: Check whether the accountable role can produce evidence for consent or notice handling, retention decisions, access approvals, deletion actions, and breach escalation. The important test is not whether teams “know their part,” but whether the organisation can reconstruct the full decision path without guesswork after the fact.

Practitioner takeaway: DPDP accountability is real only when one owner can answer for the whole processing outcome, while every other team is tied to specific, enforceable controls inside that outcome.