Skip to content
All posts
Product

How to search your documents for a subject access request

Nexlithic AI9 min read

A subject access request rarely fails because someone did not know the law. It fails because nobody knew where the person's data was, the search started late, and no one wrote down what had been checked. This guide covers the search itself: how to scope it, how long you have, what "reasonable and proportionate" means since the Data (Use and Access) Act 2025, and how to keep a record that will stand up if the requester complains. It is a practical guide for UK organisations, not legal advice. For the wider process, see our DSAR use case and the ICO's right of access guidance.

Start by scoping the request

Before you search anything, read the request carefully and write down three things.

Who the requester is. You need enough to be confident you are searching for the right person. If you genuinely need more information to confirm their identity, ask for it promptly, because, as explained below, the clock now runs from when you receive it.

What they are asking for. Most requests are for "all my personal data", which is their right. Some are narrower, such as emails about a particular grievance or records from a specific period. A narrow request is easier to answer, so do not widen it yourself.

Every name and identifier they are likely to appear under. This becomes your search list. More on that below.

If the request is unclear and you hold a lot of information about the person, you can ask them to clarify what they want. Only do this when you genuinely need it. Asking for clarification is not a way to buy time.

If you are new to the terms, our glossary entry on what a DSAR is covers the basics.

Work out the deadline

The standard deadline is one month, and you should respond "without undue delay" within it. The ICO's guidance on responding to a request sets out how to count it:

  • the day you receive the request counts as day 1, even if it is not a working day;
  • the deadline is the same date in the following month;
  • if there is no such date (for example, a request received on 31 January), the deadline is the last day of that month;
  • if the deadline falls on a weekend or bank holiday, it moves to the next working day.

When the clock starts and stops: Article 12A

Section 76 of the Data (Use and Access) Act 2025 inserted a new Article 12A into UK GDPR, defining the "applicable time period". It came into force on 5 February 2026 under SI 2026/82. Under it, the one month runs from the latest of:

  • receipt of the request;
  • receipt of any identity information you requested;
  • payment of a fee, where a fee can be charged.

Fees are unusual. Subject access is normally free. You can charge a reasonable fee only if a request is manifestly unfounded or excessive, or for further copies, and in those cases you may instead refuse (ICO).

Article 12A also gives a statutory "stop the clock". If you reasonably need information from the requester to identify the data or processing the request concerns, the clock pauses while you wait. It restarts when they reply.

Extensions

You can extend by up to two further months if the request is complex or the person has made several requests. You must tell them within the first month and give your reasons. Decide this early. Discovering in week four that the search is bigger than you thought, and only then writing to extend, is a common mistake.

Put the dates in your own case log on the day the request arrives: received, identity confirmed, any clarification sent and answered, deadline, extension decision.

What "reasonable and proportionate" means

Section 78 of the Data (Use and Access) Act 2025 inserted Article 15(1A) into UK GDPR. It says the data subject is only entitled to the information you can provide "based on a reasonable and proportionate search". It is treated as having been in force from 1 January 2024.

This puts on a statutory footing what many organisations already did: you are expected to search properly, not exhaustively. It is not a licence to skip systems that are inconvenient. A search is far easier to defend as proportionate if you can show how you decided where to look and what to look for. In practice, that means four things.

1. List the systems you hold data in

Write down every place the person's data could be. A typical list:

  • email, including shared mailboxes;
  • shared drives, document management systems and cloud storage;
  • HR, payroll and recruitment systems for staff and applicants;
  • CRM, ticketing and billing systems for customers;
  • chat and collaboration tools;
  • paper files and the scanned copies of them;
  • backups and archives, where you need to decide and record whether searching them is proportionate.

Your record of processing activities, if you keep one, is a good starting point. See our glossary entry on RoPA.

2. Build a list of search terms

Search for every way the person might be identified, not just their full name:

  • full name, and any previous or married names;
  • nicknames and short forms (Katherine, Kate, Katie, K. Smith);
  • email addresses, both personal and work;
  • staff numbers, customer or account IDs, case or matter references;
  • National Insurance numbers, where you hold them;
  • phone numbers and postal addresses, where they are likely to appear on their own.

Initials and common surnames will return many false positives. That is fine. Sorting relevant from irrelevant is part of the job, and noting how you handled it is part of the record.

3. Check scanned documents

Scanned letters, signed contracts and photographed forms are often just images. A keyword search of a drive will not find a name in a scan unless the text has been read by OCR. If you hold scanned material, either run it through OCR first or search it by another route, and record which you did.

4. Record what you searched and why

Keep a short search log: each system, the terms used, the date, who ran the search, how many results came back, and any system you decided not to search, with your reason. If the requester complains to the ICO, this log is how you show the search was reasonable and proportionate.

Third-party data and exemptions

Documents found in a search often mention other people too: colleagues, family members, other customers. You need to consider whether disclosing that information would identify them, and whether to redact it, seek their consent, or decide that it is reasonable to disclose without consent. There are also exemptions that may allow you to withhold some information, and each has its own conditions.

This is the part of a subject access request where judgement matters most, and it is outside the scope of this guide. The ICO's right of access hub covers third-party information and each exemption in detail. Take advice if you are unsure.

Doing the document search in DOCNUS

DOCNUS helps with one step: finding the person in the documents you have uploaded to it. Here is how to use it honestly, and where to be careful.

Entity search. DOCNUS builds a knowledge graph from your documents, including people. In the graph, type the person's name and filter by Person. Near-identical spellings of organisations and other entities can be merged automatically, but people are never merged automatically, so search for each variant on your list (Kate Smith, Katherine Smith, K. Smith) separately. Candidates for merging go to a review queue for owners and admins.

Entity profile. Each person's profile page lists up to 100 documents and 20 passages that mention them, along with aliases and, on Professional and above, connections to other people and organisations. For a large estate, the profile is a starting list, not the whole answer. If a person appears in more than 100 documents, you will need other routes as well.

Chat with cited pages. Ask questions in plain English, for example "Which documents mention Katherine Smith's disciplinary hearing?" or "Find correspondence with kate.smith@example.com". Every answer cites the file and page, and clicking a citation opens the document at that page so you can check it. Search combines meaning-based and keyword matching, which helps with names and references. It is still not a guaranteed exact-match sweep, so treat results as leads to check.

Privacy assessment. On Professional and Enterprise plans, the privacy assessment shows which documents contain personal data and of what kind, such as contact details, government identifiers, health data or disciplinary records, with masked values and page numbers. This helps you spot documents that may be relevant, and those that hold special category or third-party data needing care before disclosure. Findings are not linked to individual people in the graph, so it tells you a document contains, say, a National Insurance number, not whose it is. Chat can answer questions about stored assessments, such as counts and categories, but never returns the raw personal values.

Scanned documents. DOCNUS reads scanned PDFs with OCR, so names in scans are searchable once uploaded. OCR is not perfect on poor-quality scans, so spot-check important ones.

DOCNUS only knows about documents you have uploaded, and it reads PDF, Word and plain-text files. Email, HR systems and other sources still need to be searched in those systems. Log the DOCNUS search in your search log like any other.

What DOCNUS does not do

To be clear about the limits:

  • no DSAR case management, request tracking or per-request deadline clock;
  • no redaction;
  • no export of a person's documents as a bundle;
  • no "find this exact identifier across every document" feature;
  • privacy findings are not linked to people in the knowledge graph.

You will still need your own case log, a redaction tool, and a way to assemble and send the response. The privacy assessment is an automated risk assessment, not legal advice, and you should review its results. Our DSAR use case page explains where DOCNUS fits in the wider process.

A checklist to work from

We have put the steps above into a one-page DSAR checklist (PDF): scoping, dates, systems, search terms, scanned material, third-party data and the search log. Print it, attach it to each request, and fill it in as you go. The record you build is as important as the search itself.