What Actually Happens During A Manual DSAR
Last month I watched a privacy lead at a 200-person UK financial services firm spend an entire weekend inside a SharePoint export. She was looking for every file that mentioned one person. The subject access request had been received on a Thursday afternoon, eight working days remained against the one-month deadline, and her team had three other DSARs in progress. By Sunday evening she had found 47 documents. On Monday she discovered she had missed a folder.
That scenario is not unusual. It is the ordinary texture of DSAR fulfilment at UK SMBs in 2026. Yet when privacy professionals describe this work to people outside the function (to finance teams building next year's budget, to executives scoping an audit, to engineers who have been asked to help), the response is usually surprise. The request is just one person's data. How much work can it really be?
This post walks through the hours, realistically. Numbers vary by organisation and by request, but the shape is consistent enough that I think it is worth putting on the record. If you are operating privacy at a UK organisation that relies on unstructured exports, shared drives and ad-hoc archives, the hours below will look familiar. If you are not, they may clarify why the privacy leads you work with sound tired.
The hours, phase by phase
A typical DSAR at a 100-500 person UK organisation takes between 18 and 25 hours of privacy-team time end to end. That number is not an estimate from a vendor pitch deck; it is the pattern I see across the conversations Sylure has been having. The breakdown below assumes a moderately complex subject (an employee, a long-standing customer, or a supplier contact) rather than an extreme case involving litigation, special category data, or subject-to-subject data contamination that requires legal review.
Phase 1: Intake and scope clarification (1-2 hours)
A request arrives. Before anything else, the privacy team has to confirm the requester's identity, record the request in whatever tracking system they use, and clarify what data the subject is actually asking for. Subjects rarely submit a clean request on the first attempt. They ask for "all my data" when they mean "my HR records from the last two years," or they ask for "anything you have about me" without naming the systems they expect it to live in.
This phase is quick if the requester is cooperative and the identity verification is straightforward. It balloons if the requester is an employee who has left on bad terms, or if the organisation has multiple legal entities and the request touches more than one. A badly scoped intake is the single most common reason DSARs become expensive later.
Phase 2: Data location (3-5 hours)
The team now has to identify where data about the subject might exist. At a UK SMB this is rarely a structured exercise with a data map. It is a mental inventory: HR systems, email, Slack, shared drives, finance tools, the CRM, the support system, whatever tools individual teams have adopted without IT's formal approval. Every one of these has to be considered.
Some are easy. The HR system almost certainly has a profile page for a current or former employee, and pulling that is a matter of exporting from a UI. Others are hard. Email searches cover inboxes across the company, not just the subject's own mailbox, and finding all the threads that reference a person (as opposed to the threads they were on) requires full-text search across a large volume of data.
Phase 3: File retrieval and export (3-5 hours)
Once the team has a list of sources, they have to extract data from each one. HR systems export as PDFs or CSVs. Email platforms export to PST or EML archives. Shared drives are downloaded as ZIP bundles, sometimes individually, sometimes through native export tools that produce an opaque structure the team has to navigate later.
This phase is mechanical but slow. Every export has a different user interface, a different file format, a different convention for how the data is bundled. The team ends up with a folder on someone's laptop containing ten or twelve archives, totalling anywhere from 500 megabytes to several gigabytes, that they now have to work through.
Phase 4: Content review (6-10 hours)
This is where the work actually lives. Reviewing the extracted content means opening files, reading them, and deciding whether they contain personal data about the subject. For structured exports from an HR system, the decision is mostly automatic: the data is clearly labelled as belonging to a named person. For unstructured data (emails, Slack threads, documents on shared drives, call notes, meeting minutes) the review has to happen line by line.
A 200-megabyte SharePoint export might contain 8,000 files. Most of them are irrelevant to the DSAR. Some of them mention the subject. A handful contain substantive personal data about them. The reviewer has to open each file that plausibly matches, read enough of it to make the determination, and record the outcome.
Even with keyword search, this phase is slow. Keyword search finds documents that contain the subject's name, but it does not tell the reviewer whether the mention is substantive (a performance review, a complaint, an employment contract) or incidental (a name on a distribution list, a sign-off on an unrelated document, a mention in meeting minutes where the subject did not personally attend).
Keyword search is a triage tool, not a review tool. Determining whether a document is substantively about the subject is a human judgement call that no search layer has yet replaced.
Phase 5: Redaction and third-party data removal (3-5 hours)
Documents that contain personal data about the subject often contain personal data about other people too. An email thread about the subject's performance usually includes the manager, HR contacts and possibly colleagues. A complaint about the subject necessarily includes the complainant. The privacy team has to redact everyone else before the document can be disclosed.
Redaction is where the work becomes delicate. Over-redact and the subject receives a document with so many blacked-out sections that they cannot understand what was said about them. Under-redact and you disclose personal data about someone who did not consent to the disclosure. Getting this balance right requires attention and judgement, and it has to happen on every document that makes it through the review phase.
For organisations redacting in Word, Google Docs or Acrobat, this phase often takes longer than expected because of the technical details: flattening redactions so they cannot be undone, removing metadata from files, converting documents to image-based PDFs to prevent text recovery.
Phase 6: Packaging and response letter (2-3 hours)
The redacted documents have to be packaged into a disclosure bundle, indexed so the subject can find what they asked for, and sent with a response letter. The response letter itself has to describe what data was found, where it was found, and on what legal basis each category is being processed. It also has to explain any exemptions applied, any data withheld, and the subject's right to complain to the ICO.
This phase is the most visible to the subject and often the most scrutinised if the response later becomes contested. A weak response letter invites follow-up correspondence that can run for weeks.
Why these numbers surprise people
Eighteen to twenty-five hours per DSAR, at typical UK professional hourly rates, is approximately £900-£1,500 of internal labour per request. For an organisation receiving 20-40 DSARs a year, that is between £18,000 and £60,000 of annual privacy work going into DSAR fulfilment alone, not counting management oversight, legal review of complex cases, or the opportunity cost of the privacy team not doing other work.
These numbers surprise people outside the privacy function because they expect DSAR fulfilment to be a technical problem. Surely, the reasoning goes, there is a system that answers "give me everything about this person." There is not, at most UK SMBs. What exists is a privacy lead, a laptop, access to a dozen systems, and a deadline. The hours happen because the work is largely manual and the subject's data is scattered across tools that were never designed to answer this question.
What the numbers do not tell you
The hours are the visible cost. They are not the full cost. Three things the time estimate misses:
Privacy professionals burn out. A privacy lead responsible for DSAR fulfilment at a UK SMB is probably handling two to five active requests at any given time, while also managing subject rights more broadly, handling breaches, writing policies, supporting the business with privacy reviews, and preparing for audits. DSARs do not happen in isolation. They happen on top of everything else. The cumulative effect is that good privacy professionals leave privacy roles for adjacent roles with fewer deadlines.
Deadline pressure introduces errors. UK GDPR gives organisations one month to respond to a DSAR, extendable by two months for complex cases. When an organisation is consistently pushing up against deadlines, the review phase gets compressed. Documents get missed. Redactions get less thorough. The risk of a complaint to the ICO goes up, and the cost of that complaint can dwarf the cost of the original request several times over.
The work is not sampleable. Unlike most compliance activities, DSAR fulfilment has to be right the first time. There is no way to review a sample of the output and extrapolate. Either the bundle is complete and correctly redacted, or it is not. The only way to know whether a DSAR response is good is to do the work thoroughly.
What to do about it
There is no five-step playbook that makes this work cheap. The underlying cost is a function of how data is stored at most UK organisations (widely distributed, unstructured, badly mapped) and that is not going to change soon at the organisations where it matters most.
What can change is how much of the mechanical work has to be done by a human. Phases 2 through 5 (data location, file retrieval, content review, and initial redaction) are where tooling can reduce labour meaningfully, if the tools are honest about what they can and cannot do. A tool that finds 90% of the relevant documents, suggests categorisations, and surfaces redaction candidates for human review can turn a 20-hour DSAR into a 6-hour DSAR. A tool that claims to do the work entirely without human review is either overselling or being used by someone who does not understand the risk profile.
The more useful reframing, for privacy teams budgeting for next year: assume DSAR fulfilment is a significant recurring cost, measure it, and make the trade-off between tooling cost and labour cost explicitly. The worst outcome is the one where the cost is real but invisible, and the privacy team is quietly doing fifteen hours of discovery work on their weekends because no one budgeted for the hours it actually takes.