TL;DR: Data subject requests are shifting from simple access lookups to deletion-heavy, cross-platform workflows that must reach cloud, SaaS, collaboration tools, and AI systems, according to BigID. The governing issue is no longer response intent but discovery, scope, and defensible execution across fragmented personal data estates.
At a glance
What this is: Data subject requests have moved beyond simple database lookups into complex, deletion-heavy privacy workflows that span cloud, SaaS, unstructured content, and AI systems.
Why it matters: This matters because IAM-adjacent identity and data discovery controls increasingly determine whether privacy teams can find, verify, and act on personal data within statutory deadlines.
By the numbers:
- 36% of consumers had exercised their data subject access rights, up from 28% the year before.
- 46% of consumers aged 25 to 34 had exercised these rights, compared with just 16% of those 65 and older.
- 60% of organizations reported an increase in DSARs year over year, according to EY Law survey data cited by BigID.
👉 Read BigID's analysis of how data subject requests have become harder to fulfill
Context
Data subject requests now expose a governance gap that old privacy workflows were never designed to handle. The primary issue is no longer whether an organisation can answer a basic access request from a structured database, but whether it can find, verify, and act on personal data spread across cloud platforms, SaaS, collaboration tools, and AI systems.
That shift creates an identity and access adjacency that privacy teams cannot ignore. When personal data is embedded in shared drives, workspaces, logs, and AI-assisted workflows, discovery depends on knowing where accounts, permissions, and data paths intersect. Employee requests add further risk because they often arrive in dispute contexts, which makes scope, evidence, and defensible search behaviour harder to sustain.
Key questions
Q: How should organisations handle deletion requests across cloud, SaaS, and AI systems?
A: Treat deletion as a distributed workflow, not a manual case. Map all systems that may store or derive the data, automate propagation where possible, and preserve an audit trail for each action. The key requirement is consistent discovery and execution across structured and unstructured repositories so the response is complete and defensible.
Q: Why do employee data subject requests create higher legal risk?
A: Employee requests often arrive alongside disputes, termination issues, or counsel involvement, which raises the need for precise search boundaries and stronger evidence. They also tend to reach deeper history and more fragmented records than consumer requests, so weak inventory and retention practices surface quickly under legal scrutiny.
Q: What breaks when privacy teams rely on manual DSR workflows?
A: Manual workflows break when request volume rises, data is scattered across systems, and search quality depends on individual knowledge. The result is missed records, inconsistent deletions, late responses, and poor audit evidence. In practice, the programme starts failing before the legal deadline arrives because the discovery step cannot keep pace.
Q: Which controls help prove that a data subject request was handled properly?
A: Strong proof comes from end-to-end logging, clear ownership, repeatable search criteria, and policy-based workflow execution. Organisations should be able to show what was searched, what was removed, what was exempted, and why. Without that evidence chain, even a completed request can remain vulnerable to complaint or challenge.
Technical breakdown
Why deletion requests are harder than access requests
Access requests are primarily read operations. Deletion requests are write operations that must reach every system containing the person’s data, trigger downstream propagation where required, and preserve evidence that the action occurred. That difference is why deletion creates more operational drag than access. It also explains why manual handling fails first in fragmented estates, where the same individual may appear in CRM, HR, collaboration, backup, and AI-generated content. The core technical challenge is not request intake. It is reliable discovery, coordinated execution, and proving the result across heterogeneous systems.
Practical implication: treat deletion as a distributed workflow problem, not a form-handling task.
How unstructured and AI data expands DSR scope
Modern DSR scope extends well beyond databases. Emails, chat messages, shared files, screen recordings, audio, video, prompts, outputs, and model-adjacent artefacts can all contain personal data or derivations of it. That means search logic must work across structured, semi-structured, and unstructured stores, while privacy review must also consider whether an AI system has transformed or reproduced the data in a way that remains responsive. The technical issue is identity correlation at scale: locating a person consistently across many systems whose metadata and access controls do not align.
Practical implication: build cross-system discovery and identity correlation before you promise complete response coverage.
Why employee requests create a different evidence burden
Employee DSARs often overlap with HR disputes, legal holds, and internal investigations. That introduces a tighter need for defensible search boundaries, audit trails, and escalation rules because the request may become part of a wider legal process. The organisation does not just need to find data. It needs to show what was searched, why certain exclusions were made, and how consistency was maintained across managers, systems, and retention domains. In practice, employee requests expose gaps in record ownership and data mapping faster than customer requests do.
Practical implication: align privacy operations with legal, HR, and records retention controls before employee disputes escalate.
NHI Mgmt Group analysis
Discovery is now the control plane for privacy execution. The article shows that DSR failure is less about intent and more about incomplete discovery across modern data estates. Once personal data sits in collaboration suites, AI systems, and distributed SaaS, the programme depends on identity-aware classification and inventory discipline, not manual case handling. That aligns closely with the same visibility problem seen in NHI governance. If you cannot locate what exists, you cannot govern what it can do. Practitioner conclusion: build discovery as a control, not as a support function.
Deletion-heavy privacy operations create a lifecycle governance problem. A deletion request is not a one-off event. It is a lifecycle action that must reach source systems, downstream processors, backups where applicable, and audit records. That is structurally similar to access revocation and offboarding in IAM, where the real risk is persistence after the business justification ends. The governance lesson is that privacy teams need the same lifecycle rigor IAM teams apply to accounts and secrets. Practitioner conclusion: map DSR fulfilment to lifecycle controls, not ticket queues.
Employee DSARs are increasingly a governance and evidence test. The article correctly highlights how employee requests intersect with disputes, counsel review, and record retention. That means the question is no longer whether the request is burdensome, but whether the organisation can produce a defensible search narrative under pressure. From a broader security governance view, this is where data access, records management, and identity context converge. Practitioner conclusion: prepare employee request handling like a regulated evidence workflow.
Scope expansion into AI makes privacy governance more like system governance. When prompts, outputs, and AI-adjacent artefacts can become responsive material, privacy teams are dealing with a system that generates and transforms personal data, not just stores it. That raises the same boundary questions seen in agentic AI governance: where data lives, how it moves, and what survives in derived form. Practitioner conclusion: include AI systems in privacy inventory and response design before request volume catches up.
Automated fulfillment is becoming the minimum viable operating model. Manual handling cannot absorb the increase in request volume, the complexity of deletion, or the legal need for evidence. That does not mean automation replaces judgment. It means the programme needs workflow enforcement, traceable actions, and consistent policy application at scale. Practitioner conclusion: use automation to remove repetitive discovery and execution steps while preserving human review for exceptions.
What this signals
Identity-aware discovery is becoming a prerequisite for privacy operations. The programme lesson is that personal data search cannot stay separate from access governance once records span collaboration platforms, SaaS, and AI systems. Teams that already use identity inventory practices for accounts and service access are better positioned to extend those controls into privacy response and evidence handling.
The next maturity step is to connect request fulfilment to lifecycle control points, especially where employees, contractors, and downstream processors create overlapping obligations. That means privacy, IAM, and records management need shared ownership of discovery, retention boundaries, and auditable execution before request volume pushes the process into exception mode.
For practitioners
- Map personal data to identity and system ownership Build an inventory that ties data stores to accountable owners, system types, and search paths across cloud, SaaS, collaboration tools, and AI systems.
- Automate deletion and opt-out workflows Use workflow controls that execute across source systems, downstream recipients, and audit logging so the same request is handled consistently at scale.
- Include unstructured and AI content in discovery scope Expand search logic to email, chat, shared drives, recordings, prompts, and outputs so personal data is not missed outside databases.
- Separate employee request handling from routine consumer cases Route employee DSARs through a stricter legal and HR review path because disputes, retention, and evidentiary obligations change the response model.
Key takeaways
- Data subject requests have shifted from simple access lookups to distributed lifecycle actions that must span many systems.
- The hardest part is now discovery and proof, especially when requests touch unstructured content, AI artefacts, and employee disputes.
- Automated workflows, identity-aware discovery, and defensible audit trails are the controls that keep privacy programmes operational at scale.
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 and NIST SP 800-53 Rev 5 set the technical controls, while GDPR and ISO/IEC 27001:2022 define the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | PR.DS-1 | DSR handling depends on discovering where personal data resides across systems. |
| NIST SP 800-53 Rev 5 | AU-2 | DSR fulfilment needs traceable logging and defensible evidence of search and action. |
| GDPR | Art.12 | The article is about exercising data subject rights under privacy law. |
| ISO/IEC 27001:2022 | A.5.33 | Privacy request handling depends on documented operational procedures and records. |
Use discovery and inventory controls to locate personal data before response deadlines begin.
Key terms
- Data Subject Request: 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.
- Deletion Request: A deletion request is a privacy request asking an organisation to remove personal data where the law requires or permits erasure. It is operationally harder than access because it must reach multiple systems, downstream recipients, backups where applicable, and an audit trail that proves the action occurred.
- Identity Discovery: Identity discovery is the process of finding and cataloguing every identity, entitlement, and access path across the environment. In NHI programmes it is foundational because hidden service accounts, tokens, and machine identities create governance gaps that certification and offboarding cannot close.
- Defensible Search: Defensible search is a documented, repeatable search process that can stand up to regulator or legal review. It requires clear scope, consistent criteria, and evidence showing what was searched, what was found, and why any exclusions were made.
What's in the full article
BigID's full article covers the operational detail this post intentionally leaves for the source:
- Cisco consumer survey breakdowns that show how request behaviour differs by age group and why demand is rising.
- California Delete Act DROP operational requirements, including cascading deletion, suppression, and downstream service-provider handling.
- Employee DSAR handling considerations tied to disputes, retention, and legal review under tighter evidence expectations.
- Practical examples of how discovery, classification, and fulfilment workflows are structured across complex environments.
Deepen your knowledge
The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, identity lifecycle, and secrets management. It helps practitioners connect access, ownership, and lifecycle control to the programmes they already run.
Published by the NHIMG editorial team on August 18, 2026.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org