The practical approach
- Train staff to recognise requests regardless of how they are worded or received.
- Define the scope before searching across email, HR, CRM, messaging and document systems.
- Record why the searches performed were reasonable and proportionate.
- Apply exemptions and third-party redactions individually rather than withholding complete documents by default.
- Keep an auditable record of decisions, deadlines, searches and disclosures.
Subject access requests have long been one of the most operationally demanding parts of UK data-protection compliance. A request may require an organisation to search years of email, HR files, customer-service records, internal messages, recordings, CCTV footage and archived documents. It may also arrive during an employment dispute, complaint, litigation threat or breakdown in a customer relationship.
The Data (Use and Access) Act 2025 clarified an important limit: a person is entitled to the information a controller can provide after conducting a reasonable and proportionate search. The Act codified a principle already recognised in domestic case law rather than creating a right for organisations to perform only superficial searches.
The challenge is therefore no longer whether every theoretically possible location must be searched. It is whether the organisation can show that its search decisions were sensible, properly scoped and proportionate to the circumstances.
1. What is a subject access request?
A subject access request, commonly called a SAR, is a request made by or on behalf of an individual for information they are entitled to receive under Article 15 of the UK GDPR. The right generally includes: confirmation of whether the organisation processes their personal information, a copy of that personal information, and supplementary information about matters such as purposes, categories, recipients, retention and individual rights.
There are no formal words that a person must use. A request may simply say:
- “Please send me my HR file.”
- “What information do you hold about me?”
- “Can I see the notes from my complaint?”
- “Please provide the emails discussing my dismissal.”
- “Send me all the information linked to my account.”
A person can make a request verbally or in writing, including through a social-media account operated by the organisation. It can be made to any part of the organisation and does not have to be sent to the DPO or a dedicated privacy address. This makes staff awareness one of the first controls an organisation needs: a receptionist, line manager, salesperson or social-media administrator may receive a valid request without realising it. The compliance deadline does not wait for the message to reach the privacy team.
2. What changed under the Data (Use and Access) Act?
Section 78 of the Data (Use and Access) Act 2025 amended the UK’s data-protection framework to state expressly that a controller is only required to provide information it is able to supply on the basis of a reasonable and proportionate search. The explanatory notes state that the provision codifies the principle already established in domestic case law. The legislation also treats the clarification as having effect from 1 January 2024.
This does not mean:
- Organisations may search only the easiest systems.
- Archived information may always be ignored.
- Emails need not be reviewed.
- A broad request can be rejected automatically.
- Cost or inconvenience alone ends the obligation.
- The controller may decide what it would prefer the requester to receive.
It means the search should be judged in context. Relevant considerations may include the wording and scope of the request, the length of the relationship with the individual, the volume and location of likely personal information, the accessibility of archived or legacy systems, the time, cost and technical effort involved, the likelihood that a particular system contains relevant information, the sensitivity and importance of the requested data, the potential effect on the individual if information is missed, and whether the requester has helped identify dates, people, topics or accounts.
The strongest position is not “we searched everywhere.” It is:
“We identified the systems and custodians reasonably likely to contain responsive personal data, conducted documented searches using appropriate terms and date ranges, reviewed the results, and recorded why further searches would have been disproportionate.”
3. A large request is not automatically excessive
Organisations sometimes treat a request for “all my data” as abusive merely because it may be time-consuming. That is unsafe. The ICO says a request is not excessive simply because it covers a large amount of information. An organisation may invite the requester to narrow the scope, but if they decline, the organisation must still carry out reasonable searches for the requested personal data.
Manifestly excessive requests require more than size. Relevant circumstances may include whether the request repeats or substantially overlaps recent requests, has already been answered with no meaningful change since, requires work clearly disproportionate to the benefit of a further response, or forms part of a pattern that places an unreasonable burden on the organisation. The assessment must remain case-specific: a request from an employee for 15 years of data may be broad, but it may also be legitimate. Consider first whether clarification, sensible date ranges or identified custodians can make the response manageable.
4. When can you ask the requester to clarify?
Clarification can be useful when an organisation holds a large amount of information about the person and cannot reasonably identify what information or processing activities the person is seeking. For example, a long-serving employee may ask for “all information about me”; the organisation could explain the types of information held and ask whether the employee is primarily seeking records connected with a recent grievance, appraisal or disciplinary process.
The ICO says the response time may be paused while clarification is awaited, but clarification should only be requested where it is genuinely required to respond and the organisation processes a large amount of information about the person. Clarification should not become a delaying tactic. Ask promptly, explain why it is needed, give useful examples of possible scope, avoid pressuring the person to abandon part of the request, preserve the original request, and record when the clock was paused and restarted. Where the requester confirms they want all their information and refuses to narrow the scope, proceed with reasonable and proportionate searches.
5. What is the deadline for responding?
The normal deadline is one calendar month from receipt. The ICO’s practical guidance highlights three points: the clock can start on a weekend or public holiday; where the due date falls on a weekend or public holiday, the deadline moves to the next working day; and organisations cannot add days merely because the following month is shorter.
Where a request is complex, or the individual has made several requests, the organisation may extend the response period by up to two additional months. The requester must be told about the extension within the original one-month period, together with the reason for the delay. Complexity should not be assumed merely because the organisation has poor records or fragmented systems. Factors supporting an extension might include large volumes requiring individual review, extensive third-party information, complex confidentiality or exemption questions, information held in several formats and locations, specialist work to extract or redact recordings and CCTV, or several simultaneous rights requests from the same person. A simple request should not be extended merely because the responsible team is busy.
6. Identity checks must be proportionate
An organisation should not disclose personal information until it is reasonably satisfied about the requester’s identity and, where relevant, the authority of somebody acting on their behalf. However, requesting identification creates additional personal data and can introduce its own security risks. The ICO advises organisations not to demand formal identity documents unless this is necessary and proportionate: existing account verification, reference numbers or questions based on information already held may sometimes be more appropriate.
The required level of assurance should reflect the sensitivity of the information, the method by which the request was received, whether an authenticated relationship already exists, the risk of sending information to the wrong recipient, and whether there are genuine doubts about identity. A bank responding through an authenticated customer portal may require less additional evidence than an organisation receiving a request from a newly created email address for sensitive health records. Avoid automatically requesting passports or driving licences for every SAR.
7. Requests made by representatives
A solicitor, relative, friend, union representative or specialist SAR service may submit a request on behalf of an individual. The organisation should confirm that the representative is authorised both to make the request and, where applicable, to receive the information. Evidence might include a recent signed letter of authority, a valid electronic authorisation, an applicable power of attorney, or another reliable record of the individual’s instructions.
The ICO cautions that merely accepting an online portal’s terms and conditions is unlikely, by itself, to prove that the portal has authority to act for the individual. Organisations do not have to pay a fee or register with a third-party service merely to access or answer a request. Where authority is unclear, contact the individual where possible rather than simply ignoring the request.
8. How to design a reasonable and proportionate search
A defensible search usually begins with a search plan.
Define the request. Record the exact wording, date received, relevant period, named employees, departments, products or incidents, accounts, aliases, email addresses and identifiers, and any clarification received.
Map likely data locations. Depending on the request these may include CRM and customer-support systems, HR and payroll platforms, email accounts, Teams, Slack or other business messaging, shared drives and document systems, call recordings, complaint-management tools, CCTV, paper files, archived or legacy systems, and data held by processors. Not every location must be searched automatically — identify which systems are reasonably likely to contain relevant personal data.
Identify custodians. Where the request concerns a workplace dispute, searches may need to cover the requester’s manager, HR adviser, investigating officer and decision-maker. Searching only the requester’s own mailbox may miss the most important records.
Choose search terms. Possible terms include full and previous names, initials, employee or customer number, email addresses, telephone number, case or complaint reference, project name, and relevant incident terms. Test them: a name may produce too many irrelevant results, while a narrow term may miss records.
Record exclusions. Where a system is not searched, record why: it did not exist during the relevant period, it has been confirmed not to contain personal data of that type, information was permanently deleted under the retention schedule before the request arrived, restoring it would require disproportionate technical work with little likelihood of responsive data, or equivalent information was already retrieved from an authoritative source. The reasoning should be specific rather than formulaic.
9. Personal data is not the same as every document mentioning the person
The right of access applies to the requester’s personal data, not automatically to complete documents. An email may contain personal data about the requester, personal data about colleagues or customers, confidential business information, legally privileged advice, and information unrelated to the requester. The organisation may provide an extract, transcript or redacted copy rather than the entire original document where that is sufficient to communicate the requester’s personal data.
However, context may form part of the personal data. Extracting one sentence so narrowly that it becomes misleading or unintelligible may not provide meaningful access. The review should ask: what information relates to the requester? Is surrounding context needed to understand it? Does the document contain information about other people? Does an exemption apply? Can the relevant data be disclosed through redaction or extraction?
10. How should third-party information be handled?
SAR responses frequently contain information about other identifiable people. The correct response is not automatically to withhold the whole document. Consider whether the third party has consented to disclosure, whether it is reasonable to disclose without consent, whether the third party can be anonymised or redacted, whether the requester already knows the person’s identity, whether the information concerns the third party in a professional capacity, and whether disclosure could cause harm or unfairness.
For CCTV, other people may need to be blurred or masked before footage is released. Where redaction is not possible, the organisation must balance the requester’s right of access against the privacy rights of the other people shown. Every decision should be recorded.
11. Exemptions must be applied individually
The Data Protection Act 2018 contains exemptions that may allow information to be withheld in particular circumstances. Potentially relevant areas include legal professional privilege, crime and taxation, management forecasting or planning, negotiations with the requester, confidential references, regulatory and judicial functions, certain health, social-work and education information, and information involving the rights of other people.
Exemptions are not blanket exclusions for document categories. Marking an email “privileged” does not necessarily make every part of it legally privileged; information connected with an employment investigation is not automatically exempt merely because litigation is possible. The ICO says organisations must justify and document their reasons for applying an exemption. A good exemption record identifies the information withheld, the exemption relied upon, why its legal conditions are satisfied, whether only part of the material could be withheld, who approved the decision, and what explanation was given to the requester.
12. Redaction must actually remove the information
Poor redaction can cause a personal-data breach. Placing a black rectangle over text in an editable document may leave the underlying content recoverable. Metadata, comments, tracked changes, hidden worksheets and document properties may also reveal information. The ICO recommends checking that redacted information cannot be read after scanning or copying paper documents; electronic redaction should use suitable tools, and redacted files should be saved separately from the originals.
Before disclosure, check the visible document, hidden text and layers, comments and tracked changes, file properties and metadata, spreadsheet tabs, formulas and hidden columns, email attachments and conversation history, and whether search or copy-and-paste reveals removed content. A second-person quality check is advisable for sensitive or high-volume responses.
13. The information must be sent securely
The delivery method should reflect the sensitivity and volume of the information. Possible safeguards include an authenticated customer portal, an encrypted download link, a password-protected file with the password sent separately, tracked or signed-for post, and in-person collection after identity verification.
The ICO notes that where a request was made by email, there is generally an expectation that the response will also be electronic unless the requester says otherwise. Nevertheless, assess the security risk and verify addresses carefully before sending — sending the correct response to the wrong email address can create a reportable personal-data breach.
14. What should the final response contain?
A complete response normally includes:
- Confirmation of whether personal information is being processed.
- A copy of the relevant personal information.
- The purposes of processing.
- Categories of personal information.
- Recipients or recipient categories.
- Retention periods or the criteria used to determine them.
- Information about the source where data was not collected directly.
- Relevant information about automated decision-making.
- Information about applicable individual rights.
- The right to complain to the ICO.
The response should also explain any material limitations on the search, any information withheld, any exemptions applied (where disclosure of the explanation would not undermine the exemption), and the right to complain or seek further review. The information should be concise, transparent, intelligible and easily accessible: a document dump containing thousands of unstructured pages may technically contain the data but still fail to provide meaningful access if the requester cannot reasonably understand it.
15. What good SAR evidence looks like
A strong SAR file should contain more than the final email: the original request, date and method of receipt, identity and authority checks, clarification correspondence, deadline calculations, any extension decision, the search plan, systems and custodians searched, search terms and date ranges, search results, the duplicate-removal process, third-party assessments, exemption decisions, redaction checks, approval records, disclosure method, the final response, and any complaint or follow-up. This record allows the organisation to explain what it did if the requester challenges the response or complains to the ICO.
A 30-day SAR workflow
Days 1–3: Recognise and control. Log the request immediately, confirm the deadline, acknowledge receipt, verify identity only where necessary, confirm authority for representatives, assign an owner.
Days 3–7: Define the search. Read the wording carefully, seek clarification only where genuinely needed, identify systems, custodians and processors, establish search terms and relevant dates, preserve potentially relevant data.
Days 7–18: Retrieve and review. Run documented searches, remove duplicates, identify responsive personal data, review third-party information, escalate potential exemptions.
Days 18–25: Prepare disclosure. Apply redactions, create extracts where appropriate, compile supplementary information, explain search limitations and withheld information, conduct quality assurance.
Days 25–30: Approve and send. Verify the recipient and delivery address, send securely, retain the response record, log any follow-up or complaint.
Common pitfalls
- “They did not call it a SAR.” No particular terminology is required.
- “It went to the wrong department.” A request can be valid when sent to any part of the organisation.
- “They asked for too much.” Volume alone does not make a request excessive.
- “We asked them to narrow it, so the clock stopped.” The clock only pauses for clarification in the relevant circumstances; clarification cannot be used routinely to delay work.
- “We searched the main system.” A reasonable search may also require relevant email accounts, messaging platforms, archives or processors.
- “The email mentions another employee, so we withheld it.” Third-party information requires a balancing and redaction assessment.
- “The document is confidential.” Confidentiality alone is not necessarily a valid exemption from access.
- “We blacked out the text.” Visual covering is not secure redaction if the underlying content remains recoverable.
- “We can send everything as one large file.” A response must remain intelligible and securely delivered.
What organisations should do now
Organisations should update their SAR procedures to reflect the express reasonable-and-proportionate-search standard. The priority is not to reduce the quality of searches — it is to make search decisions deliberate, repeatable and defensible. A well-run process should show how the organisation recognised the request, how it interpreted the scope, which locations and people were searched, why the search was reasonable and proportionate, and how third-party rights and exemptions were assessed.