Subject Access Request: How to Handle SARs Properly

A subject access request is a formal right that allows any individual to obtain a copy of the personal data an organisation holds about them. Under Article 15 of the UK GDPR and the Data Protection Act 2018, anyone can submit a data subject access request to your business, and you are legally required to respond.

This article explains what a subject access request involves, the rules and deadlines you must follow, and how to build a reliable process for handling them. This is educational content, not legal advice. Consult a qualified solicitor for decisions specific to your organisation.

What Is a Subject Access Request?

A subject access request (SAR) is an exercise of the right of access under data protection law. When an individual submits a SAR, they are asking you to confirm whether you process their personal data and, if so, to provide them with:

• A copy of their personal data
• The purposes of the processing
• The categories of personal data concerned
• The recipients or categories of recipients who have received or will receive the data
• The retention period, or the criteria used to determine it
• Information about their other rights (rectification, erasure, restriction, objection)
• The source of the data if it was not collected directly from the individual
• Whether automated decision-making, including profiling, is applied, and the logic involved

This right is established in Article 15 of the UK GDPR and applies to all organisations that process personal data of individuals in the United Kingdom. The Data Protection Act 2018 adds exemptions in Schedules 2 through 4, but the core obligation is broad.

A data subject access request does not need to use any specific language. An email that says "I want to know what data you have on me" is a valid SAR, even if the person never uses the term "subject access request." Your staff need to recognise these requests in whatever form they arrive.

Who Can Make a Subject Access Request?

Any living individual whose personal data you process can submit a subject access request. This includes:

• Customers and users of your website, app, or service
• Employees and former employees requesting their HR records, performance reviews, and internal correspondence about them
• Job applicants who want to see interview notes or assessment data
• Website visitors whose data you collect through cookies, analytics, or contact forms
• Third-party representatives acting on behalf of a data subject with proper authorisation, such as solicitors, parents of children under 13, or persons with power of attorney

There is no requirement for the individual to be a UK resident or citizen. If you hold their personal data and they make a request, you must respond.

Requests From Children

The DPA 2018 sets the age of digital consent at 13 in the UK. For children younger than 13, a parent or guardian typically makes the request. For children aged 13 and above, the ICO advises that the child can generally make their own request, but you should consider whether the child understands what they are asking for.

How to Receive and Verify a Subject Access Request

A SAR can arrive through any channel: email, letter, phone call, social media message, or in person. You cannot require individuals to use a specific form or portal, although offering one is considered good practice as it helps you collect the information you need.

Identity Verification

Before disclosing personal data, you must be reasonably confident the request comes from the data subject (or their authorised representative). Common verification methods include:

• Asking the individual to confirm information you already hold, such as account details, an order number, or a date of birth
• Requesting a copy of photo ID if you do not have an existing relationship with the individual
• Using your existing authentication system if the person is a registered user

The key principle is proportionality. Do not demand more identification than necessary. If a logged-in user submits a SAR through their account, their identity is already verified.

Starting the Clock

The one-month response deadline starts on the day you receive the request, not the day you verify identity. However, if you need additional information to identify the requestor or locate their data, the ICO allows the clock to pause until you receive that information. Document every step of this process.

Subject Access Request Response: Deadlines and Format

Article 12(3) of the UK GDPR requires you to respond to a subject access request without undue delay and within one calendar month. Calendar month means the same date in the following month. If the request arrives on 15 March, the deadline is 15 April.

Extensions

If the request is complex or if you have received multiple requests from the same individual, you may extend the deadline by up to two additional months (for a total of three months). You must notify the individual within the first month, explain why the extension is necessary, and inform them of their right to complain to the ICO.

Format of the Response

You must provide the information in a concise, transparent, intelligible, and easily accessible form. Practical guidelines:

• Electronic requests should receive electronic responses, typically a structured document or secure download
• Use clear, plain language. Avoid legal jargon where possible.
• Provide a copy of the data itself, not just a summary. Redact third-party personal data if disclosing it would breach another person's rights.
• Include the supplementary information listed in Article 15(1), such as processing purposes, recipients, and retention periods.
• Organise the data logically. Group by category (account data, transaction history, communications, analytics) rather than dumping raw database exports.

If the individual made the request electronically, you should provide the data in a commonly used electronic format (PDF, CSV, or similar) unless they request otherwise.

Exemptions: When You Can Withhold Data

The DPA 2018 includes exemptions that may allow you to withhold some or all of the requested data. These are set out primarily in Schedule 2 and include:

• Crime prevention and detection. You can withhold data if disclosure would prejudice the prevention or detection of crime.
• Legal proceedings. Data covered by legal professional privilege is exempt.
• Regulatory functions. If disclosure would prejudice a regulatory body's ability to carry out its functions.
• Journalism, academia, art, and literature. Schedule 2, Part 5 provides exemptions where processing is for these purposes and disclosure would be incompatible with the special purpose.
• Management planning. You can withhold data about management forecasting or planning if disclosure would prejudice the conduct of the business.
• Third-party data. If the response would reveal personal data about another individual, and it is not reasonable to disclose it, you may redact that information.

Exemptions are narrow and must be applied on a case-by-case basis. You cannot use a blanket exemption to refuse an entire request. Where only some data is exempt, you must still provide the rest.

Building a Subject Access Request Process

Handling SARs reactively leads to missed deadlines and errors. A structured process reduces risk and ensures consistency.

Step 1: Create a Central Intake Point

Designate an email address (such as [email protected]) and, optionally, an online form for receiving requests. Train all customer-facing staff to recognise SARs and route them to this central point immediately.

Step 2: Log Every Request

Maintain a register of all SARs received. For each request, record:

• Date received
• Name and contact details of the requestor
• Description of the data requested
• Identity verification status and method
• Response deadline
• Status (open, in progress, completed, refused)
• Date and method of response

Step 3: Search and Compile

Search all systems where personal data may reside: databases, email inboxes, CRM systems, file shares, backups, paper records, and third-party platforms. Common places where data hides include:

• Helpdesk and support ticket systems
• Slack or Teams messages
• Google Docs and shared drives
• Analytics platforms
• Backup systems

Step 4: Review and Redact

Before sending the response, review the compiled data for third-party personal data that should be redacted, legally privileged information, and any applicable exemptions. Document your reasoning for any data withheld.

Step 5: Respond and Record

Send the response within the deadline. Include a covering letter or email that explains what data is included, the supplementary information required by Article 15, and any data that has been withheld along with the reasons. Save a copy of everything you sent.

Step 6: Review and Improve

After each SAR, review what went well and what caused delays. Common bottlenecks include fragmented data storage, slow identity verification, and unclear ownership of the response process. Fix these systematically.

Subject Access Requests and Your Website

If you operate a website that collects personal data, SARs will touch your online operations directly. The data you may need to locate and provide includes:

• Account information. Name, email, password hash metadata (not the hash itself), profile settings.
• Transaction records. Orders, payments, invoices, shipping details.
• Communication logs. Support tickets, chat transcripts, email correspondence.
• Analytics and tracking data. IP addresses, cookie identifiers, page views, session recordings. If you can link this data to the individual, it falls within scope.
• Cookie consent records. When and how the individual gave or withdrew consent.

Your privacy policy should clearly explain how individuals can submit a subject access request. Use the privacy policy generator to include a rights section with contact details and expected response times. Your terms of service generator should reference the privacy policy for all data-related matters.

TermsBox's compliance scanner can help you identify what data your website collects through cookies and third-party scripts, which simplifies the data-mapping step when compiling SAR responses.

Common Mistakes When Handling Subject Access Requests

Organisations frequently make errors that lead to ICO complaints and enforcement action. Avoid these:

• Missing the deadline. The one-month clock is strict. Calendar reminders and a tracking register are essential.
• Demanding a specific form. You cannot refuse a SAR because the individual did not use your preferred form. Any clear request counts.
• Over-verifying identity. Asking a known customer to provide photo ID when they are already authenticated is disproportionate and may count as obstruction.
• Providing a summary instead of the actual data. Article 15 requires a copy of the personal data, not a high-level description of what you hold.
• Ignoring unstructured data. Emails, chat logs, handwritten notes, and spreadsheets all count as personal data if they relate to the individual.
• Blanket exemption claims. Exemptions must be applied to specific pieces of data with documented reasoning, not to an entire request.
• Disclosing third-party data. Failing to redact another person's personal data from the response is itself a data breach.

The ICO has published detailed guidance on the right of access, including worked examples and decision trees. Review this guidance when building your process.

Penalties for Failing to Comply With a Subject Access Request

Failure to respond properly to a SAR can result in enforcement action by the ICO. The consequences include:

• Complaints. The individual can complain directly to the ICO, which will investigate and may take informal or formal action.
• Enforcement notices. The ICO can order you to comply with the request, potentially under a specific timeline.
• Fines. While fines specifically for SAR failures tend to be lower than those for major breaches, the ICO can impose penalties of up to 17.5 million GBP or 4% of annual worldwide turnover under the most serious tier. In practice, SAR failures often surface alongside other compliance failings that compound the penalty.
• Court action. Under Section 167 of the DPA 2018, individuals can apply to court for an order requiring compliance. They can also claim compensation for material and non-material damage under Article 82 of the UK GDPR.

The ICO's enforcement tracker shows that SAR complaints consistently rank among the most common complaint types received each year. Getting your process right is not just about avoiding fines. It is about maintaining trust with your customers and users.

Frequently Asked Questions

How long do I have to respond to a subject access request?

You must respond within one calendar month of receiving the request. If the request is complex or you have received multiple requests from the same person, you can extend the deadline by up to two additional months, but you must inform the requestor of the extension within the first month.

Can I charge a fee for a subject access request?

In most cases, no. Under Article 12(5) of the UK GDPR, you must provide one copy of the data free of charge. You may charge a reasonable fee only if the request is manifestly unfounded or excessive, or if the individual requests additional copies beyond the first.

What if I cannot verify the identity of the requestor?

You are entitled to request additional information to confirm the identity of the person making the request. The one-month response deadline does not start until you have enough information to verify identity. However, you must not use identity verification as a tactic to delay or discourage requests.

Can I refuse a subject access request?

You can refuse a request only if it is manifestly unfounded or manifestly excessive, for example, if the same person makes repeated identical requests with no reasonable interval. You must explain your reasons for refusal and inform the individual of their right to complain to the ICO.