How should organisations build data governance processes to handle access, portability, and deletion requests under privacy regulations?

Designing the request process around the person, not just the ticket

Access, portability, and deletion requests only work when the organisation can reliably connect a request to a real person, a defined legal basis, and a complete internal data footprint. That means designing intake, identity verification, and case ownership as one process, so the legal outcome is not separated from the technical search, export, redaction, and erasure steps.

The practical problem is not just approval, it is discovery. A strong process has to identify where personal data lives across production systems, analytics stores, file shares, logs, backups, and downstream copies, then route the case through the right action for each system. For organisations building this capability, the DSAR Guide: Handling Data Subject Requests is a direct fit because it covers intake, identity verification, search, redaction, exemptions, and automation at scale.

Good process design also separates request type from response type. Access requests need completeness and intelligibility, portability requests need a usable export, and deletion requests need disciplined erasure with documented exceptions where retention is required. The control point is not the form itself, but whether the organisation can consistently translate one request into the correct technical and records-management action.

How data inventory and access control make privacy requests workable

Privacy requests fail when the organisation lacks a trustworthy inventory of data locations and access paths. A usable governance process needs system ownership, field-level or dataset-level classification where possible, and a repeatable way to ask which stores contain data about a particular person. Without that, teams end up manually searching, missing copies, or over-scoping deletion and export work.

This is why request handling should be built on data governance, not on ad hoc spreadsheet tracking. The Data Governance and Data Catalogue Security Guide is useful here because it treats ownership, catalogue controls, and access governance as the foundation for finding and managing governed data. A catalogue only helps if its ownership, classification, and access metadata are accurate enough to drive a request workflow.

Access governance also matters because privacy requests often touch the same systems that support day-to-day internal access. If data owners, stewards, and platform teams do not know who can read, copy, or export personal data, the organisation cannot credibly prove that a DSAR response is complete or that an erasure request has actually reached all relevant stores. The governance process should therefore include clear review points for who can query, extract, or retain personal data in the first place.

Building deletion and portability workflows that survive real systems

Portability and deletion become difficult when data is distributed across warehouses, SaaS tools, archives, and file systems with different search and retention behaviour. The workflow has to account for transformed data, duplicated records, and operational copies such as exports, reports, and staging datasets. A request process that ignores those layers may satisfy the letter of the request in one system while leaving the same data live elsewhere.

For that reason, organisations should define standard operating rules for export format, retention exceptions, masking, redaction, and deletion verification. The point is to make the response repeatable and auditable, not to improvise per case. The Data Access Governance Guide is relevant because it links sensitive data access, reviews, and monitoring to the practical question of who can retrieve and move data, which is central when a privacy request requires controlled export or removal.

Deletion workflows also need to address residual copies. Backups, immutable archives, retention locks, and downstream recipients can all affect whether deletion is immediate, delayed, or partial. A mature process records those exceptions explicitly, so the organisation can explain what was deleted, what was suppressed, and what remains only because a lawful retention duty overrides the request.

Risk and Threat Considerations

Privacy request handling creates exposure if hidden copies, weak identity verification, or poor workflow controls let the wrong person receive data, or let personal data persist after it should have been removed. The main security problem is not only non-compliance, but the possibility that access, export, or erasure actions are applied inconsistently across systems and copies.

Failure mechanism: Incomplete discovery, weak request verification, or untracked downstream copies can cause over-disclosure on access or portability requests, and false completion on deletion requests.

Impact: The organisation can expose personal data, fail to meet regulatory obligations, and lose confidence in its ability to prove accountability to the individual and to auditors.

Practitioner Guidance

What to prioritise: Build the request process around data inventory quality before you optimise case handling speed. If you cannot quickly identify where a person’s data exists, automation will only make incomplete responses faster.

What to verify: For every request type, verify that the workflow has a defined owner, a search scope, a fulfilment action, and a closure check. The closure check should confirm whether exports were complete and whether deletions were applied wherever technically and legally possible.

Common mistake: Treating portability and deletion as one-off privacy tasks handled by legal or support alone. The operational owner needs authority over search, export, redaction, retention exceptions, and evidence capture, otherwise the process will drift into manual exception handling.

Practitioner takeaway: The strongest privacy-request programme is the one that can prove, case by case, where data was found, what was done to it, and why any residual copy still exists.

Related resources from NHI Mgmt Group

• What should organisations do when a consumer requests deletion, correction, or access to their data under a new privacy law?
• How should organisations handle identity verification before fulfilling data subject access requests under state privacy laws?
• How should organisations handle EU Data Act data access and sharing requests without weakening privacy controls?
• How can security and privacy teams handle deletion, correction, and access requests at scale?