A single team or individual should own the process so requests are not lost across overlapping responsibilities. The article notes that this role often falls on IT Ops or SecOps, which already juggle primary operational duties. Central ownership matters because it creates one intake path, improves accountability, and reduces the chance that privacy requests are treated as secondary work.
Why a single owner matters for data subject requests
data subject request need one accountable owner even when the work lands in Security Operations. The issue is not just routing, it is preventing fragmented handling across IT Ops, SecOps, privacy, and application teams. A single owner creates one intake path, tracks deadlines, and ensures the request is completed instead of being absorbed into someone else’s queue.
This is especially important when security teams already manage incident response, monitoring, and access controls. Without a named owner, a request can stall at handoff points, be duplicated, or be closed without a full answer. Ownership should therefore be explicit, documented, and visible to the teams that may need to support fulfilment.
When the process touches identity data, the privacy-handling expectations in Identity Data Privacy and Consent Guide are a useful reminder that consent, retention, and data subject rights need a clear operational path, not just a policy statement.
Who usually owns the process in practice
In many organisations, IT Ops or SecOps becomes the operational owner because those teams already have access to systems, logs, and control points needed to execute the request. That does not mean the request is a security task by nature. It means security often has the best path to fulfillment, while privacy or legal remain the decision authorities for interpretation and scope.
The cleanest model is one named owner with supporting contributors. The owner receives the request, confirms its type, assigns work, follows up on blockers, and records completion. Support teams can gather evidence or make system changes, but they should not become separate owners of the same request.
For the regulatory baseline, GDPR makes the operating model materially relevant because data subject rights must be handled in a timely and accountable way. EU General Data Protection Regulation (GDPR) is the clearest reference point for why accountability, data minimisation, and response discipline matter.
What good handoff looks like when security operations is involved
Security Operations can own the workflow without owning the privacy decision itself. The right pattern is a single queue, a clear decision tree, and a defined handoff from intake to verification to fulfilment. If the request needs identity proofing, log review, access confirmation, or data extraction from protected systems, SecOps can coordinate that work while preserving one accountable case owner.
Good handoff design also means the request is never dependent on informal messaging. The owner should know which team supplies evidence, which team approves release, and which team closes the case. If the workflow spans tools or ticketing systems, the case must still appear as one request to the requester and one tracked item to the organisation.
Operationally, this is consistent with the broader need for strong incident and service handling discipline described in SANS Security Resources, where security teams are expected to work through repeatable processes rather than ad hoc escalations.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 sets the technical controls, while GDPR, ISO/IEC 27001:2022 and SOC 2 (AICPA) define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| GDPR | Art.5 — Principles relating to processing of personal data | DSR handling depends on accountable, timely personal-data processing. |
| Art.25 — Data protection by design and by default | One-owner workflows are a by-design control for reliable rights handling. | |
| Art.12 — Transparent information, communication and modalities for exercising rights | Data subject requests need a clear, usable response path and ownership. | |
| Recommendation — Align request handling to lawful processing, minimisation, and accountability principles. Build one intake path and default routing into the request process. Define a single contact and response process for rights requests. | ||
| NIST SP 800-53 Rev 5 | AU-2 — Event Logging | Owned request handling needs auditable records of intake, action, and closure. |
| AC-6 — Least Privilege | Security teams may need limited access to execute DSR tasks without broad ownership drift. | |
| Recommendation — Log receipt, action, approval, and closure for each request. Limit request handlers to the minimum access needed to fulfill the request. | ||
| ISO/IEC 27001:2022 | A.5.1 — Policies for information security | Ownership and accountability for request handling should be defined in policy. |
| Recommendation — Document who owns DSR intake, execution, and closure. | ||
| SOC 2 (AICPA) | CC2.1 — Commitment to competence | A named owner and clear responsibilities support reliable control operation. |
| Recommendation — Assign a competent owner with clear responsibility for DSR handling. | ||
Practitioner Guidance
What to prioritise: Assign one named owner for the entire request lifecycle, even if several teams contribute execution steps. If SecOps is the intake point, make it the coordinator of record so the request does not disappear between queue owners.
What to verify: Confirm that the owner can show three things for every request, who received it, who performed each action, and who approved closure. If any of those are unclear, the process is too distributed to trust.
Common mistake: Treating “security is involved” as a reason to split responsibility. That usually creates delay, inconsistent answers, and weak auditability, especially when privacy requests compete with operational work.
Practitioner takeaway: Security Operations can run the workflow, but one accountable owner must own the outcome. The organisation should optimise for traceable fulfilment, not for shared ownership that diffuses responsibility.
Related resources from NHI Mgmt Group
- How should privacy teams automate data subject request handling without losing control?
- How should security teams use app banners to reduce risky credential and data handling in everyday work?
- Who should own IAM transformation when the goal is to combine security, operations, and data science?
- Who should own automated remediation when security, compliance, and operations teams all depend on the same data controls?
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 29, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
