Accountability usually sits with the privacy function, but legal, IT, security, and data owners all share responsibility for execution. The organisation must be able to show who verified identity, who approved the search scope, who fulfilled the request, and what evidence was retained. Clear ownership matters because regulators judge the outcome, not the internal handoffs.
Who owns the clock on a data subject request?
A late or incomplete data subject request is usually treated as a governance failure, not just an operational miss. The privacy function is typically accountable for the process, but that accountability only works if legal, IT, security, records, and the relevant data owners each perform their part. Under the GDPR, organisations must manage requests in a way that can be evidenced, time-bound, and auditable, which makes handoffs and proof of action part of the control itself. EU General Data Protection Regulation (GDPR)
In practice, teams often discover ownership gaps only after the deadline has already passed, rather than through a well-rehearsed request workflow.
How accountability is assigned across the request lifecycle
Accountability for a data subject request is split across the lifecycle, even if one function is answerable for the overall result. Privacy or data protection leads normally own the case and the deadline, but they rarely control identity verification, system access, retention systems, or source data inventory on their own. That means the real control question is whether each participant can prove what they did, when they did it, and under what instruction. Where requests are late or incomplete, the failure is often not a single missed task but a breakdown in sequencing, escalation, or evidence retention.
The most reliable operating model separates decision rights from execution duties:
- Privacy or legal sets the response scope and decides whether any exemption applies.
- Identity or service teams confirm the requester is who they claim to be before disclosure starts.
- IT and application owners locate the records and identify which systems are in scope.
- Security supports controlled extraction, transfer, and logging when data is sensitive or spread across multiple systems.
- Data owners validate completeness before release so the response is not technically timely but practically deficient.
This matters because regulators and complainants do not care how work was split internally if the final response is late, missing records, or inconsistent with what the organisation said it would provide. For that reason, accountability should be traceable through assigned case ownership, timestamps, approvals, and retained evidence rather than informal email chains alone. Guidance from control frameworks such as NIST SP 800-53 Rev 5 Security and Privacy Controls is useful here because it reinforces the need for defined responsibility, access control, and auditable process steps. Where the request spans many systems or jurisdictions, the workflow breaks down fastest when no one owns the final reconciliation step.
When the simple answer stops being enough
Tighter request governance often increases coordination overhead, requiring organisations to balance speed against verification and completeness. That tradeoff becomes visible when a request touches archived data, shared platforms, or third-party processors, because each extra source adds delay and increases the chance of an incomplete search or inconsistent redaction decision.
There is also a genuine distinction between operational responsibility and legal accountability. In some organisations, the privacy team is the default case owner, but the legal team becomes the decision maker for exemptions, while IT or data engineering owns extraction from complex systems. The consensus view is that one accountable owner should remain visible to the requester and to regulators, but internal sub-ownership must still be explicit enough to prove who handled each step. A vague “shared responsibility” model is weak because it often hides failure until the response is challenged.
Practitioners also underestimate how often identity proofing and scope definition determine whether a response is complete. If the requester is not properly verified, the organisation may disclose too little, delay the case, or both. If the search scope is too narrow, the response can be on time but still incomplete. The standard fails most often where request tracking, records discovery, and sign-off are separated without a final review checkpoint.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0, CIS Controls v8 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.RR-01 — Roles, Responsibilities, and Authorities | Late DSARs expose unclear ownership across privacy, IT, legal, and data teams. |
| RS.MA-1 — Response Planning and Management | DSARs need tracked case handling, escalation, and deadline management to stay complete. | |
| GV.OV-01 — Oversight and Accountability | Regulators judge whether the organisation can evidence accountable oversight of the process. | |
| Recommendation — Assign a single accountable owner and document supporting responsibilities for each DSAR step. Use a managed case workflow to track deadlines, escalations, and completion evidence. Maintain auditable oversight records that show who approved scope, search, and release. | ||
| CIS Controls v8 | 6 — Access Control Management | DSAR handling depends on verified access and controlled disclosure of personal data. |
| Recommendation — Restrict DSAR data access to approved staff and review disclosure permissions before release. | ||
| NIST SP 800-63 | IAL2 — Identity Assurance Level 2 | Incomplete or late responses often start with weak requester identity verification. |
| Recommendation — Apply a defined identity-proofing standard before searching or releasing personal data. | ||
Practitioner Guidance
What to verify: Verify that every request has one named case owner, one deadline, and one final completeness check before release. If those three fields are not visible in the workflow, accountability will usually be disputed after the fact rather than managed during the case.
Escalation / exception: Escalate immediately when a request depends on multiple business units, legacy archives, or a third-party processor. Those are the conditions where missed handoffs and partial search results most often turn a manageable request into a regulatory problem.
Practitioner takeaway: The accountable party is the one who can demonstrate control of the full process, not merely the team that answered the email at the end.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 7, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
