What Must Be Included in a Subject Access Request Response?

What You Must Provide in a SAR Response

Receiving a subject access request is one thing. Knowing exactly what to put in your response is another. Getting it wrong — by including too little, omitting required supplementary information, or formatting the response in a way the requester cannot understand — leads to ICO complaints, enforcement action, and the entire process starting over.

This guide covers everything that must go into a SAR response under GDPR Article 15, with practical examples and common mistakes to avoid.

The Two Parts of Every SAR Response

A complete SAR response has two parts:

1. A copy of the personal data you hold about the individual
2. Supplementary information about how and why you process that data

Most businesses get the first part roughly right but fall short on the second. Both are legally required under Article 15 of the UK GDPR and EU GDPR.

Part 1: The Personal Data Itself

You must provide the requester with a copy of all personal data you hold about them. "Personal data" means any information relating to an identified or identifiable individual. In practice, this covers far more than most businesses initially expect.

What Counts as Personal Data

Here are the categories most organizations hold, with practical examples:

Identity and contact information: Names, addresses, email addresses, phone numbers, dates of birth, national insurance numbers, passport numbers, employee IDs, customer account numbers.

Communications: Emails to and from the individual, chat messages, letters, call recordings, notes from phone conversations, text messages, social media messages.

Employment records (for employee SARs): Contracts, offer letters, performance reviews, disciplinary records, grievance files, attendance records, pay slips, benefits information, training records, interview notes, references received about them.

Customer records: Purchase history, account activity, support tickets, complaint records, membership details, subscription information, payment records.

CCTV and images: CCTV footage featuring the individual, photographs, ID document copies.

System and technical data: Login records, IP addresses, device identifiers, access logs, audit trails that identify the individual.

Marketing data: Consent records, marketing preferences, profiling data, segments or categories the individual has been placed in, scores assigned by automated systems.

Notes and opinions: Internal notes about the individual, opinions recorded by staff members, assessments, evaluations. Opinions about a person constitute their personal data, even if the person recording the opinion considers it informal or internal.

How to Present the Data

The data must be provided in an intelligible form. This means the requester must be able to understand it. A raw database export with field names like cust_seg_flg_01 is not intelligible. You need to either:

• Present the data in a readable, structured format (a well-organized document or spreadsheet with clear headers), or
• Provide a key or glossary that explains any codes, abbreviations, or technical terms

If the request was made electronically, you should provide the data in a commonly used electronic format (PDF, CSV, or a structured document) unless the requester asks for something different.

Part 2: Supplementary Information

Under Article 15(1) and 15(2) of the GDPR, you must also provide the following supplementary information alongside the personal data. This is not optional — it is part of the legal requirement.

1. The Purposes of Processing

Tell the requester why you hold and process their data. Be specific to their actual data, not just a generic privacy policy statement.

Example: "We process your personal data for the following purposes: (a) to manage your customer account and provide the services you have subscribed to; (b) to communicate with you about your account and respond to your queries; (c) to comply with our legal obligations under tax and accounting law."

2. The Categories of Personal Data

List the types of personal data you hold. This gives the requester an overview of the scope of data you process about them.

Example: "We hold the following categories of your personal data: identity data, contact data, transaction data, communications data, and marketing preferences."

3. Recipients or Categories of Recipients

Disclose who you have shared or will share the requester's data with. You can name specific organizations or describe categories of recipients.

Example: "Your personal data has been shared with: (a) our payment processor for transaction processing; (b) our email service provider for account communications; (c) HMRC as required by law."

The ICO has indicated that you should be as specific as possible. Naming individual recipients is preferred over vague categories like "third-party service providers" wherever practical.

4. Retention Periods

Tell the requester how long you intend to keep their data, or the criteria you use to determine retention periods.

Example: "We retain your account data for the duration of your active subscription and for six years after account closure to comply with our legal obligations. Marketing preference data is retained until you withdraw consent."

5. The Right to Rectification, Erasure, Restriction, and Objection

Inform the requester that they have the right to request correction of inaccurate data, deletion of their data, restriction of processing, or to object to processing. A brief statement is sufficient — you do not need to explain the full scope of each right.

6. The Right to Complain

Tell the requester that they have the right to lodge a complaint with the supervisory authority. In the UK, this is the Information Commissioner's Office (ICO). In the EU, it is the relevant national data protection authority.

7. Source of the Data

If you did not collect the data directly from the requester, disclose where it came from. This applies to data obtained from third parties, publicly available sources, or other organizations.

Example: "Your contact details were originally provided to us by [Company Name] as part of a business referral in March 2024."

8. Automated Decision-Making and Profiling

If you use automated decision-making (including profiling) that produces legal effects or similarly significant effects on the individual, you must provide:

• Meaningful information about the logic involved
• The significance of the processing
• The envisaged consequences for the individual

This requirement applies to things like automated credit scoring, algorithmic hiring decisions, or insurance risk assessments. If you do not use automated decision-making, a brief statement confirming that is sufficient.

What You Can Legitimately Exclude

Not everything in your files needs to go into the response. There are specific situations where you can withhold data.

Third-Party Personal Data

If the data you hold about the requester also contains personal data about other identifiable individuals, you must not disclose that third-party data unless the other person has consented or it is reasonable to do so without consent. The correct approach is to redact the third-party information and provide the rest of the document — not to withhold the entire document.

Legally Privileged Material

Communications between you and your legal advisors that are subject to legal professional privilege are exempt from disclosure. This covers legal advice privilege and litigation privilege. The exemption applies to the privileged material itself, not to all data connected to a legal matter.

Other Exemptions

The UK Data Protection Act 2018 provides additional exemptions in specific circumstances, including data processed for crime prevention, management planning, and negotiations. For a full breakdown, see our guide on DSAR exemptions.

Important Rule

When you withhold any data, you must tell the requester that you have done so and explain which exemption you are relying on (to the extent possible without defeating the purpose of the exemption). You must also inform them of their right to complain to the ICO.

How to Structure a SAR Response Package

A well-organized response reduces the risk of complaints and makes the process more efficient for both sides. Here is a practical structure:

1. Covering letter or email. This should include:

• Confirmation of who you are and that this is your response to their SAR
• A summary of the supplementary information (purposes, categories, recipients, retention, rights, complaint route, source, automated decisions)
• A note about any data that has been withheld and the exemption relied upon
• Contact details for follow-up questions

2. Data schedule or index. A table or list that summarizes the data enclosed, organized by category or system. This gives the requester a roadmap to navigate the response.

3. The data itself. The actual personal data, organized in a logical way. Group it by category (communications, account data, HR records, etc.) rather than by system. The requester does not care which database the data came from — they want to understand what you hold about them.

4. Glossary (if needed). An explanation of any codes, abbreviations, or technical terms used in the data.

For template language and a more detailed walkthrough, see our DSAR response templates guide.

Common Mistakes That Lead to ICO Complaints

Based on ICO enforcement actions and published decisions, these are the most frequent errors organizations make when responding to SARs.

Providing an Incomplete Search

Organizations search their main customer database and call it done. But personal data often lives in email inboxes, shared drives, archived systems, handwritten notes, CCTV recordings, and backup systems. If the requester's data exists in a system and is reasonably accessible, it needs to be included.

Omitting the Supplementary Information

Sending a data dump without the Article 15 supplementary information is not a compliant response. The covering letter or response document must include the purposes, recipients, retention periods, and rights information. Many businesses skip this entirely.

Excessive Redaction

Some organizations redact so heavily that the response is meaningless. Redaction should be targeted — remove specific third-party identifying information, not entire pages. If a document is so heavily redacted that nothing intelligible remains, reconsider whether the redaction is proportionate.

Providing Data in an Unusable Format

Sending hundreds of pages of unorganized printouts, password-protected files without the password, or data in obscure file formats that the requester cannot open defeats the purpose of the right of access. The data must be in a format the requester can actually use.

Missing the Deadline

You have one calendar month from receipt of the request. Extensions of up to two additional months are available for complex requests, but you must notify the requester within the first month. Silence followed by a late response is one of the most common triggers for ICO complaints.

Confusing a SAR With a Complaint

A SAR is not a complaint, and it should not be handled by your complaints team using complaint procedures. The legal requirements, timelines, and outcomes are different. Train your team to recognize SARs and route them to the right person immediately.

A Note on Format Requests

If the requester asks for their data in a specific format (for example, electronic copies rather than paper), you should accommodate that request where reasonably practicable. Under Article 15(3), if the request is made by electronic means, the information should be provided in a commonly used electronic format unless the requester asks otherwise.

If providing the data in the requested format would involve disproportionate effort, explain why and offer an alternative. But the bar for "disproportionate effort" is high — converting a paper file to PDF, for instance, is not disproportionate.

References

• UK GDPR / EU GDPR Article 15: Right of access by the data subject. GDPR Article 15
• ICO Guidance: Right of access — what should we consider when responding. ICO right of access guidance
• UK Data Protection Act 2018: Schedule 2 — exemptions. UK DPA 2018

Related Guides

• How to Respond to a DSAR — full step-by-step response process
• DSAR Response Templates Guide — template language and structure
• DSAR Exemptions — when you can legitimately withhold data