A credible enterprise DSAR workflow example is not a shared inbox, a spreadsheet and a race against a statutory deadline. It is a controlled operating process that connects legal interpretation, privacy governance and technical evidence gathering. For organisations operating across borders, this distinction determines whether a data subject access request becomes a manageable case or a high-risk operational incident.
The challenge is rarely acknowledging a request. The difficult work is establishing who owns the response, verifying the requester appropriately, locating relevant information across disconnected systems, reviewing third-party data, applying justified restrictions, and preserving a defensible record of every decision. An enterprise workflow must make those actions repeatable without treating every request as identical.
Why enterprise DSAR handling needs a workflow
A DSAR can touch HR systems, customer relationship management platforms, support tools, collaboration environments, security logs, marketing databases and archived records. In a multinational organisation, it may also involve local teams, processors, representatives and different retention practices. A privacy team cannot reliably manage this through informal requests for information alone.
The workflow needs clear gates. Each gate should establish what must be known before the case moves forward, who is accountable for a decision, and what evidence must be retained. This supports timely handling, but it also creates management information: request volumes, data-source bottlenecks, repeat requester patterns, overdue tasks and recurring data-quality issues.
There is a trade-off. Over-engineering a workflow can turn routine requests into long approval chains. Under-engineering it leaves material judgement calls with operational staff who may not understand the disclosure risk. The right design uses a standard path for ordinary cases and escalation paths for complex, sensitive or cross-border requests.
Enterprise DSAR workflow example: a seven-stage process
Consider a technology and life sciences group headquartered in APAC, with staff and customers in the UK and Europe. It uses cloud-based business applications, has several subsidiaries, and relies on central privacy leadership with local operational contacts. A former employee submits an access request to a regional HR address.
1. Intake, logging and deadline calculation
The HR team forwards the request to the central DSAR function on the day it arrives. The case is created in a controlled register with the received date, relevant entity, requester category, jurisdictions involved, request type and applicable response target. The system assigns a case owner and records the acknowledgement sent to the requester.
At this point, the case owner checks whether the request is sufficiently clear and whether additional information is required to locate the relevant records. Deadline calculation should be based on the applicable framework and the facts of the case, not on a generic global setting. Where requests involve several entities or jurisdictions, the workflow should identify the lead responding entity and define how local input will be coordinated.
2. Identity verification and authority checks
The organisation should apply verification proportionately. A former employee using a known corporate email address may require a different approach from an individual using an unfamiliar personal address and asking for records connected to a sensitive role.
The workflow records the verification method, the evidence reviewed and the decision to proceed. If a third party acts for the requester, the case owner also records the authority relied upon. This avoids a common weakness: collecting more identity information than necessary while failing to document why it was required.
3. Scope assessment and case plan
The privacy lead reviews the request with HR and, where relevant, legal and information security stakeholders. They identify likely custodians, systems, date ranges, business units and any particular categories of information that need attention. The aim is to create a proportionate search plan, not to launch an undefined search across every platform the organisation has ever used.
For this former employee, the plan includes the HR information system, payroll records, recruitment files, performance-management tools, email archives, service desk records and selected collaboration spaces. It excludes systems where no reasonable connection to the requester exists, with the rationale documented in the case file.
Complexity should be identified early. Allegations of misconduct, active disputes, privileged material, security investigations, large email collections or records relating to other individuals may require specialist review. The workflow should flag these cases before collection begins, rather than discovering them days before the response is due.
4. Data discovery and controlled collection
Named data stewards receive tasks with a defined scope, due date and collection instructions. They should not decide independently what the organisation must disclose. Their role is to locate and preserve potentially relevant material, explain the system context, and return results through an approved channel.
For consistent execution, collection instructions should state the requester identifiers, agreed date range, file formats required, relevant search terms where appropriate, and the person responsible for resolving queries. The case record should show which sources were searched, by whom, when, and with what result.
A mature process distinguishes between data retrieval and review. Technical teams and system owners help obtain the records. Privacy and legal reviewers determine what can be provided, what needs redaction, and what requires further assessment. This separation protects consistency and gives technical staff a workable remit.
5. Review, redaction and escalation
The central review team consolidates the collected information and removes duplicates where appropriate. It assesses relevance, accuracy, third-party information, confidential business information, security-sensitive material and other factors that may affect disclosure. Decisions should be tied to the applicable legal basis and documented in language that can be understood by management and, where necessary, explained to the requester.
The review is not simply a document-cleaning exercise. A personnel manager's notes may contain the personal data of the requester and another employee. A support record may reveal security controls. A message chain may include unrelated information that adds no value to the response. The workflow needs clear redaction standards, quality checks and an escalation route for difficult judgement calls.
Where the group has an EU, UK or other local representative arrangement, the team should be able to identify whether that representative needs to be informed or involved under the organisation's established governance model. The representative function should connect to the operational case process, not sit separately from it.
6. Response assembly, approval and secure delivery
The case owner prepares the response package, including the required information and a clear explanation of the material supplied. The response should be intelligible and organised. Sending a large, unlabelled file dump may technically provide data but creates avoidable confusion and follow-up work.
Approval levels should reflect risk. A straightforward request may need privacy review and case-owner sign-off. A request involving litigation, sensitive HR matters, significant redactions or executive data may require additional review. The workflow should make approval status visible, with no ambiguity about who can release the final response.
Delivery must use a method appropriate to the sensitivity and volume of the records. The team records the delivery method, date sent, recipient confirmation where available, and any material withheld or restricted with the relevant rationale.
7. Closure, retention and operational learning
Closing the request is not the end of the process. The organisation should retain a complete case file in line with its records-management rules: the request, identity checks, correspondence, search plan, source logs, review decisions, approvals and final response. This provides evidence of accountable handling and enables consistent treatment of later requests.
The privacy function should also classify the operational lessons. If every HR request requires manual searches of three legacy repositories, that is a data-governance issue. If requests regularly reveal unclear retention ownership, the DSAR process has identified a control gap. If a particular business unit repeatedly misses collection deadlines, the issue may be training, capacity or system access.
Governance that makes the workflow work
The workflow depends on a clear operating model. Formiti's three-team approach is useful here: legal expertise interprets obligations and escalated issues; privacy specialists own process design, case oversight and accountability; technical operations teams make data discovery, evidence collection and platform configuration workable in practice. One role rarely provides all three capabilities at enterprise scale.
Technology can improve control, particularly where a case-management platform assigns tasks, calculates milestones, maintains audit trails and reports on ageing cases. It does not remove the need for informed review. Automation is valuable for routing, reminders, source tracking and standard communications; it is less suitable for making unreviewed disclosure decisions about sensitive or contextual information.
For global organisations, the operating model should also define who manages local variations. A central team can set standards and maintain oversight, while country contacts provide system knowledge, language support and local context. This is particularly effective for organisations expanding into Europe, the UK, Switzerland or Asia without building a large privacy team in every market.
What leaders should measure
Board and executive reporting should focus on control performance, not merely the number of requests received. Useful measures include on-time completion rates, average time spent in collection and review, cases requiring escalation, recurring systems involved, extension decisions, and overdue tasks by business function. These indicators show where DSAR risk is accumulating before a deadline is missed.
A well-run DSAR programme also tests its own assumptions. Periodic case reviews can confirm that data maps still reflect reality, delegated system owners remain current, template communications work across jurisdictions, and access controls allow reviewers to obtain information without creating unnecessary exposure.
The strongest DSAR workflow is the one that makes accountability visible before a request arrives. When ownership, search methods, review standards and escalation routes are already embedded, the organisation can respond with discipline rather than improvisation.