What Is a Subject Access Request? Everything You Need to Know

What Is a Subject Access Request?

A subject access request (SAR) is a request from an individual asking an organization to provide them with a copy of the personal data it holds about them. It is a legal right, not a favor. Under the UK GDPR and the Data Protection Act 2018, every person has the right to find out what personal information an organization is processing about them, why they are processing it, and who they are sharing it with.

If you are running a business in the UK — or dealing with UK-based customers, employees, or contacts — this is something you need to understand and have a process for.

The term "subject access request" comes from UK and EU data protection law. The "subject" is the data subject — the person the data is about. The "access" is their right to see that data. You will also see this called a DSAR (Data Subject Access Request), particularly in international contexts. They are the same thing. If you have landed here looking for DSAR information, everything in this guide applies to you too. For our broader overview that covers multiple jurisdictions, see What Is a DSAR?.

Who Can Make a Subject Access Request?

Anyone whose personal data you hold. The law calls them data subjects, but in plain terms, that includes:

• Customers — current and former
• Employees — including former employees and job applicants
• Website visitors — if you collect any identifying information through your site
• Contractors, freelancers, and suppliers — if you hold their personal details
• Members of the public — if you have their data for any reason

A person does not need to have a current relationship with you. If you processed their data at any point and still hold it, they can make a SAR.

Third-Party Requests

Someone can make a subject access request on behalf of another person. Common examples:

• A solicitor acting on behalf of their client
• A parent or guardian acting on behalf of a child (though children with sufficient understanding can make their own request)
• An authorized representative with written consent from the data subject

When you receive a third-party request, you need to verify that the person making the request is authorized to act on behalf of the data subject. Do not just hand over data because someone claims to be acting for someone else.

What Must You Provide in Response?

When you receive a valid subject access request, you are required to provide:

The Personal Data Itself

This is the core of the request — a copy of the personal data you hold about the individual. Not a summary, not a paraphrase. The actual data, in an intelligible form.

"Intelligible" is important. If the data is in a database or coded format, you need to present it in a way the person can understand. Raw database dumps with column headers like usr_prf_mkt_opt_fl are not helpful. Either translate the data into readable format or provide a key.

Supplementary Information

Under Article 15 of the UK GDPR (UK GDPR Article 15), you must also tell the person:

• The purposes of the processing — why you have their data and what you are doing with it
• The categories of personal data — what types of data you hold (identity data, financial data, marketing preferences, etc.)
• The recipients — who you have shared or will share the data with, either specific organizations or categories of recipients
• Retention periods — how long you plan to keep the data, or the criteria you use to decide
• Their rights — specifically, their right to request rectification, erasure, restriction of processing, or to object to processing
• Right to complain — that they have the right to lodge a complaint with the Information Commissioner's Office (ICO)
• Source of the data — if you did not collect the data directly from the person, where it came from
• Automated decision-making — if you use automated decision-making or profiling, meaningful information about the logic involved, its significance, and its envisaged consequences

That is a lot of information. The good news is that much of it is standard — your privacy policy probably already covers the purposes, categories, and rights. You do not have to write a custom essay for each request. A well-structured template handles most of it. See our guide on DSAR response templates for exactly how to structure this.

How Long Do You Have to Respond?

Under the UK GDPR, you must respond to a subject access request within one calendar month of receiving it (UK GDPR Article 12(3)).

A few important details on timing:

When Does the Clock Start?

The clock starts when you receive the request. Not when you acknowledge it, not when you verify the requester's identity (though you should do that promptly), and not when you get around to reading it. The moment the request arrives in your inbox, the deadline is running.

If you need to ask for clarification or identity verification, this does not pause the clock under UK GDPR. However, the ICO has indicated that if you promptly request identity verification, the period can effectively be treated as starting from when you receive the verification. Do not abuse this — request verification immediately, not two weeks later as a stalling tactic.

Can You Extend the Deadline?

Yes, but only for complex or numerous requests. You can extend by up to two additional months (three months total), but you must:

1. Tell the individual within the first month that you are extending
2. Explain why the extension is necessary

"We are busy" is not a valid reason. "Your request covers 15 systems, three years of email correspondence, and involves redacting data about 47 other people" is closer to what justifies an extension.

For a full breakdown of deadlines across different regulations, including CCPA and PIPEDA, see our guide on DSAR response deadlines.

Does a SAR Have to Be in a Specific Format?

No. This is a point that trips up many businesses. A subject access request can arrive in any form:

• An email (formal or informal)
• A letter
• A phone call
• A message on social media
• A note scribbled on a napkin handed to your receptionist (yes, technically)
• Through a form on your website

The person does not need to:

• Use the phrase "subject access request" or "SAR"
• Cite the Data Protection Act or GDPR
• Use a specific form you have created
• Put the request in writing (though you can ask them to, for practical purposes)

If someone contacts you and the substance of their message is "I want to know what data you hold about me" or "Please send me my personal information," that is a subject access request regardless of how it is worded.

Should You Provide a Subject Access Request Form?

You can, and it is good practice. A form helps you collect the information you need to locate the person's data efficiently — their full name, email addresses they may have used, account numbers, date range, and so on.

But — and this is critical — you cannot require people to use your form. If someone emails you a free-text request, that is valid and you must process it. Your form is a convenience, not a gateway.

A good SAR form asks for:

• Full name (including any previous names used)
• Contact details for sending the response
• Any identifiers that help you locate their data (account number, customer ID, etc.)
• The date range they are interested in (optional — they can ask for everything)
• Any specific data or systems they are particularly interested in (optional — this can help you prioritize, but they are entitled to everything regardless)

Can You Charge a Fee?

Under the current UK GDPR rules, the first copy of the data must be provided free of charge (UK GDPR Article 15(3)).

You can charge a "reasonable fee" based on administrative costs in two situations:

1. Further copies — if the person asks for additional copies of the same data
2. Manifestly unfounded or excessive requests — if you can demonstrate the request is clearly unreasonable (more on this below)

In practice, the vast majority of SARs should be handled for free. Charging a fee is the exception, not the rule, and attempting to charge as a deterrent will not go well for you with the ICO.

When Can You Refuse a Subject Access Request?

The right of access is broad, but it is not absolute. You can refuse a request that is manifestly unfounded or excessive (UK GDPR Article 12(5)).

Manifestly Unfounded

This means the person has no genuine intention of exercising their right of access. Examples might include:

• A request made explicitly to cause disruption to your business
• A request where the person has openly stated they do not actually want the data
• Repeated requests with no reasonable interval that appear designed to harass

The bar is high. "This is inconvenient for us" does not make a request manifestly unfounded.

Manifestly Excessive

This considers:

• Whether the request is proportionate
• Whether the person has made repeated requests and the data has not changed
• Whether the request overlaps significantly with a recent request you have already fulfilled

Even when you refuse, you must tell the person why and inform them of their right to complain to the ICO. You cannot just ignore the request.

For a detailed look at all the circumstances where you might be able to refuse or limit your response, see our guide on DSAR exemptions.

What About Other People's Data?

This is one of the trickiest parts of handling subject access requests. The data you hold about one person will often contain information about other people. An email between a customer and your support team mentions the customer's spouse. An employee's performance review contains the manager's opinions. A complaint record names a third party.

The rule: you must not disclose personal data about another individual unless that person has consented or it is reasonable to disclose without their consent.

In practice, this means:

• Redact third-party information where necessary — black out names, identifying details, or other personal data belonging to other people
• Consider whether disclosure is reasonable — the name of a member of your staff who dealt with the customer is often reasonable to disclose; sensitive personal details of a third party mentioned in passing usually are not
• Balance the rights — the data subject's right of access versus the third party's right to privacy

This redaction process takes time, which is one reason complex SARs can legitimately justify an extension to the response deadline.

Practical Steps for Small Businesses

If you run a small business, handling subject access requests does not need to be overwhelming. Here is what you actually need to do.

Step 1: Make Sure Your Team Can Recognize a SAR

The single biggest risk for small businesses is not recognizing a subject access request when it arrives. Train anyone who handles customer or employee communications to spot a SAR. It does not need to be a formal training program — even a 15-minute briefing covering what a SAR looks like and who to escalate it to will dramatically reduce your risk.

For more on this, see our DSAR training guide.

Step 2: Have a Point Person

Designate someone as the person responsible for handling SARs. In a small business, this is often the owner, office manager, or whoever handles compliance. The important thing is that everyone on your team knows who to pass a SAR to.

Step 3: Know Where Your Data Lives

Before a SAR arrives, map out where you store personal data. This does not need to be a formal data audit — a simple list of your systems and what data each one holds is enough:

• Email (Gmail, Outlook, etc.)
• CRM (HubSpot, Salesforce, etc.)
• Accounting software (Xero, QuickBooks, etc.)
• HR system
• Cloud storage (Google Drive, Dropbox, etc.)
• Physical files
• Any third-party tools that hold customer or employee data

When a SAR comes in, you will know exactly where to look.

Step 4: Verify Identity

Before you release any data, make sure the person is who they say they are. How much verification you need depends on context. If a customer emails you from the email address registered on their account, that may be sufficient. If someone contacts you out of the blue claiming to be a former customer, you will need more. See our guide on DSAR identity verification for a proportionate approach.

Step 5: Search, Review, and Respond

Search all your systems, compile the data, redact third-party information, add the required supplementary information, and send the response securely within the deadline. Use a template to make sure you cover everything.

For a complete step-by-step walkthrough, see how to respond to a DSAR.

Common Questions About Subject Access Requests

Do I have to respond even if the person is not a UK resident?

If you are a UK-based business processing personal data under the UK GDPR, you need to respond to SARs from anyone whose data you process — regardless of their nationality or residence. The law applies to your processing activities, not the requester's location.

What if the person asks for data I have already deleted?

You only need to provide data you currently hold. If you have legitimately deleted data in accordance with your retention policy before receiving the request, you are not required to retrieve it. But deleting data after receiving a request to avoid disclosure is a serious violation.

Can I ask the person to narrow their request?

You can ask, but you cannot require it. If someone asks for "all my data," they are entitled to all of it. You can explain that a narrower request would be faster to process, and many people will be happy to specify what they are actually looking for. But if they insist on everything, you must provide everything.

What if I cannot find any data about the person?

Respond to tell them that. Confirm that you have searched your systems and do not hold personal data about them (or that you hold less than they expected). A nil response is still a response, and it still needs to go out within the deadline.

Do verbal requests count?

Technically yes, under the UK GDPR. In practice, it is sensible to ask the person to confirm their request in writing so you have a clear record of what was asked and when. But do not use "put it in writing" as a tactic to delay or discourage requests.

The Bottom Line

Subject access requests are a fundamental right under UK and EU data protection law. They are not optional, they are not going away, and the penalties for getting them wrong are significant. But they are also not difficult to handle if you have a basic process in place.

For most small businesses, the work is straightforward: know where your data is, train your team to recognize requests, verify identity appropriately, and respond within the deadline. Do that, and SARs become a routine administrative task rather than a crisis.

References

• UK GDPR / Data Protection Act 2018: ICO guidance on the right of access. ICO right of access guidance
• UK GDPR Guidance and Resources: ICO comprehensive guidance for organisations. ICO UK GDPR guidance
• General Data Protection Regulation (GDPR): Full text, including Article 12 (Transparent communication) and Article 15 (Right of access). GDPR full text | Article 12 | Article 15

Get Your DSAR Process in Order

Our DSAR Compliance Guide gives you everything you need to handle subject access requests confidently — including process checklists, timeline calculators, and plain-English explanations of your obligations. Built for small businesses, not privacy lawyers.

Download the DSAR Compliance Guide