A DSR is a request from an individual to access, correct, delete, or otherwise control personal data held about them. Effective handling depends on identity verification, accurate data discovery, and auditable fulfillment steps across every relevant system.
Expanded Definition
A Data Subject Request, or DSR, is the operational process for honoring an individual’s rights over personal data, including access, correction, deletion, restriction, and portability. In practice, the request is not just a privacy ticket; it is a cross-system identity workflow that depends on verification, discovery, and evidence-backed fulfillment.
Definitions vary across vendors and privacy programs, but the core issue is consistent: an organisation must prove the requester is who they claim to be, locate data across SaaS, databases, archives, and logs, then execute the correct action without breaking retention or legal hold obligations. The NIST Cybersecurity Framework 2.0 is useful here because it reinforces governance, asset visibility, and response discipline rather than treating privacy as a one-off manual task.
DSRs are often confused with internal admin requests or simple account deletion. The most common misapplication is treating a DSR as a single-system cleanup, which occurs when teams only remove data from the primary application and ignore replicas, exports, backups, and downstream processors.
Examples and Use Cases
Implementing DSR handling rigorously often introduces response-time pressure and data-discovery overhead, requiring organisations to weigh privacy rights compliance against operational cost and system complexity.
- A customer submits an access request, and the privacy team must confirm identity before assembling records from CRM, support tooling, and analytics platforms.
- An employee requests deletion after account closure, but retention policy requires certain payroll or tax records to remain in controlled archives.
- A user invokes correction rights, and the organisation must update source-of-truth records while preventing stale copies from reappearing in exports or caches.
- A processor receives a request routed through a controller, requiring coordinated fulfillment across multiple vendors and auditable tracking of each handoff.
- Teams use the same workflow discipline discussed in the Ultimate Guide to NHIs — Key Research and Survey Results to understand why discovery, privilege mapping, and offboarding logic matter when identity-driven data paths cross many systems.
For organisations building privacy operations alongside identity controls, DSR intake often sits next to strong verification practices and lifecycle governance, similar to how identity assurance is treated in NIST Cybersecurity Framework 2.0 implementations that emphasise repeatable control execution. In the NHI context, requests can also expose where service accounts, logs, or integration layers retain personal data longer than expected, as highlighted in Ultimate Guide to NHIs — Key Research and Survey Results.
Why It Matters in NHI Security
DSRs matter in NHI security because personal data often passes through automation, and automation tends to multiply storage locations, permissions, and retention gaps. When a request arrives, the organisation must be able to prove where data lives and who can touch it. That same visibility challenge is common in NHI programs, where only 5.7% of organisations have full visibility into their service accounts, according to Ultimate Guide to NHIs — Key Research and Survey Results.
That lack of visibility is why DSR handling can fail quietly: a response may look complete in the primary system while copies remain in workflows, logs, backups, or data shared with third parties. The issue is not just privacy compliance, but also governance of secrets, access paths, and delegated processing. A mature privacy operation uses the same discipline expected in identity security programs, with clear ownership, traceability, and evidence at each step.
Organisations typically encounter the real cost of DSR weakness only after a complaint, regulator inquiry, or legal discovery event, at which point the request becomes operationally unavoidable to address.
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 SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | Identity proofing and authentication inform how requesters are verified before data is released. | |
| NIST CSF 2.0 | GV.RM-01 | DSR handling depends on governance, risk, and repeatable response processes across systems. |
| OWASP Non-Human Identity Top 10 | NHI-04 | Data access paths through NHIs can expose personal data if permissions and scopes are not controlled. |
Review NHI permissions and data scopes so automated systems do not overexpose personal data.
Related resources from NHI Mgmt Group
- How should teams operationalise data subject requests in modern privacy programmes?
- Why is it important to integrate identity and data governance?
- How should security teams unify identity across cloud and data center environments?
- What is the difference between network trust and request-level identity trust?
