In 2025, a defensible Data Subject Access Request (DSAR) file is much more than a bundle of PDFs.

It’s the structured, auditable record that can withstand scrutiny from the ICO, the courts, internal auditors, or a determined complainant. With the Data (Use and Access) Act 2025 (DUAA) and evolving UK GDPR standards, the bar for “search diligence” and record-keeping has been raised. Missing evidence, vague explanations and undocumented decisions are now serious risks, not minor admin gaps.

This blog sets out what a defensible DSAR file should contain in 2025—and what “good” looks like in real operations.

---

1. What Makes a DSAR File Defensible?

A defensible DSAR file doesn’t just claim that you “searched thoroughly” or “applied exemptions correctly.” It shows it.

At a minimum, it should demonstrate that:

• all relevant systems were considered and the right ones were searched

• exclusions were justified and clearly documented

• proportionality was assessed and recorded

• exemptions were applied with evidence and references

• timelines, pauses and complaints were handled in line with DUAA and ICO expectations

Think of the DSAR file as the story of the request: what was asked, where you looked, what you found, what you withheld, and why.

---

2. Documenting Your Search Strategy

Search strategy is the foundation of defensibility. If you can’t show how you looked for the data, it’s hard to argue that the search was reasonable and proportionate.

A strong DSAR file records:

• Systems searched
  For example: email, Teams/Slack, SharePoint, HR systems, EMR, CRM, case management tools, document repositories, legacy archives and cloud services.

• How they were searched
  Which keywords, IDs, date ranges, filters and custodians were used. How email chains, group chats and shared folders were handled. Whether AI-assisted search was used.

• How duplicates and inaccessible accounts were treated
  For instance, if a manager’s account was locked or a Slack workspace was archived, the file should say so and explain what alternative steps were taken.

Just as important is what you didn’t search. If a decommissioned CRM, old backup tapes or archived collaboration spaces were excluded, the DSAR file should record:

• that they were considered

• why they were excluded

• how this aligns with a “reasonable and proportionate” approach under DUAA

“Not searched: archive” without context is no longer enough.

---

3. Recording Proportionality Assessments

DUAA strengthens the idea that DSAR searches must be reasonable and proportionate. That doesn’t mean “do less and hope for the best”; it means balance effort, risk and relevance—and document that balance.

Your DSAR file should show:

• when and why you decided not to perform an exhaustive search

• how you weighed the likely benefit to the requester against the cost and disruption

• any special effort made for complex formats (Teams threads, scanned PDFs, screenshots, email attachments)

• how you handled high-risk contexts (litigation, safeguarding, clinical decisions, grievances)

A simple note like:

“Backup tapes from 2014–2016 were not restored because they contain only legacy finance data and no records of X’s employment or care. Current HR and clinical systems were searched in full.”

is far more defensible than:

“Backups too difficult to search.”

Proportionality is a judgement call. A defensible DSAR file shows how that judgement was reached.

---

4. System Inclusion and Exclusion Rationale

One of the quickest ways a DSAR file falls apart is when nobody can explain why certain systems were ignored.

Each DSAR file should contain a short system log, showing:

• systems considered (with owners or teams responsible)

• whether they were included or excluded

• the reason for each decision (technical, operational, or relevance-based)

For example:

• a university may record why a particular research cluster was out of scope for a staff DSAR

• an NHS trust may explain which clinical systems were searched for a specific care episode, and why others were irrelevant

• a council may note why a planning system wasn’t searched in a request clearly about social care

The key is to anchor decisions in policies, access models and real system use, not just “it looked hard.”

---

5. AI-Assisted Search and Redaction: Logs and Oversight

As more organisations use AI to search and redact, DSAR files need to show how AI was used—and how humans stayed in control.

Strong files now include:

• logs showing how AI processed search queries and which systems it touched

• records of which documents or snippets AI flagged as containing personal or sensitive data

• notes on where reviewers accepted or overrode AI suggestions

• explanation of any filters, confidence thresholds or model limitations

Given the ICO’s emphasis on explainability, it should be clear that:

• AI outputs informed decisions

• humans made the final calls

• AI was not allowed to silently exclude relevant records or over-redact personal data

If an AI tool helped you scan thousands of emails, your DSAR file should show how it narrowed the set and what checks were performed on its output.

---

6. Human Review Notes and Exemption Decisions

Even in AI-enabled workflows, human review remains at the centre of DSAR defensibility.

Your DSAR file should show:

• questions or concerns reviewers raised

• decisions that were escalated to senior staff or the DPO

• how ambiguous cases (for example, mixed personal data in WhatsApp threads or sensitive internal opinions) were handled

When exemptions are applied—such as:

• legal privilege

• whistleblowing protections

• third-party privacy

• management forecasting

• law enforcement or regulatory exemptions

the DSAR file should record:

• which exemption was used

• why it applied in that specific context

• any redaction or partial-disclosure approach considered

• references to internal policies or ICO guidance

Screenshots, short extracts and DPO consultation notes can all support these decisions.

---

7. Timelines, Stop-the-Clock and Complaints

Timeliness is still one of the first things the ICO looks at.

A defensible DSAR file includes a clear timeline:

• date the DSAR was received

• acknowledgement date

• any stop-the-clock events (ID checks, scope clarification), with dates and content of the requests

• date the clock was restarted

• any extensions and the reasons for them

• date the final response was issued

If the requester complains—about delay, scope, or missing data—the DSAR file should include:

• the complaint itself

• how it was investigated

• any additional searches undertaken

• any change to the response

• the final outcome and how it was communicated

Gaps in this audit trail are often interpreted as sloppy or non-compliant handling, especially where DUAA timelines and ICO guidance are clear.

---

8. Common Pitfalls That Undermine DSAR Defensibility

Many weak DSAR files share the same issues:

• exclusions recorded with no meaningful rationale (“not searched: archive”)

• no evidence explaining redaction choices

• no sign-off or peer review before sending the response

• missing communication logs with the requester

• exemptions applied without clear justification or links to guidance

• proportionality decisions that exist only in people’s heads, not on paper

In isolation, any one of these might look minor. Together, they paint a picture of poor accountability—something DUAA and UK GDPR are specifically designed to challenge.

---

9. What “Good” Looks Like in Practice

A defensible DSAR file will look different in each sector, but the underlying pattern is the same.

For example:

• A university responding to a DSAR from a research staff member may record searches across Teams, departmental SharePoint, research management tools, email, and grant systems. It documents why certain lab machines weren’t searched, includes AI redaction logs with reviewer overrides, maintains a detailed timeline (including periods awaiting clarification), and stores all scope-negotiation emails in the file.

• An NHS organisation handling a DSAR about a care episode may include EMR records, audit logs, secure messaging outputs (where accessible), and a clear explanation for excluding informal work WhatsApp chats if those are prohibited by policy. It logs clinical review delays as stop-the-clock events and records how high-risk redactions were approved.

In both cases, if the ICO or a court reviews the file, they can reconstruct:

• what was requested

• what systems were considered

• what was searched

• what was withheld

• how timelines were managed

• where judgement calls were made—and why

That is what makes a DSAR file defensible.

---

10. Modern Accountability Under DUAA and UK GDPR

Regulators are no longer satisfied with generic assurances that searches were “conducted thoroughly” or that exemptions were “applied correctly.”

They expect:

• clear logic behind each decision

• documented oversight of any AI tooling

• traceable boundaries on what was in and out of scope

A good DSAR file is adversarially ready: if the ICO, a court or a complainant challenges it, it can stand on its own as a coherent record of professional, careful handling—not something assembled in a rush after the event.

In 2025, that is the difference between a DSAR that feels risky and one that is defensible beyond doubt.