← All guides
GDPR9 min read21 May 2026

GDPR Subject Access Request (SAR): How to Respond Correctly in SaaS

A practical guide to handling GDPR Subject Access Requests (SARs) in SaaS — what to include, how to verify identity, when to extend, and how to respond when you can't provide everything.

What is a Subject Access Request (SAR)?

A Subject Access Request (SAR) — formally a request under GDPR Article 15 — is a written or verbal request from an individual asking for a copy of their personal data that you hold and supplementary information about how you process it. Any individual whose personal data you process as a controller can make one.

SARs are the most common type of Data Subject Request (DSR). In the UK alone, the ICO received over 17,000 data protection complaints in 2023/24, with SAR-related complaints representing a significant proportion. Most are triggered by customers who feel mistreated, employees in disputes, or individuals who are simply curious about what you hold.

This guide focuses specifically on Article 15 SARs — what you must provide, how to handle them operationally, and what to do when the request is complex or contentious.

What must you include in a SAR response?

Article 15(1) and (3) require you to confirm whether you process the individual's personal data and, if so, provide:

  • A copy of the personal data — all of it, from all systems
  • Processing purposes — why you hold each category of data
  • Data categories — types of personal data held
  • Recipients or categories of recipients — who you share the data with
  • Retention periods — how long each data category is kept
  • The right to request rectification, erasure, or restriction
  • The right to lodge a complaint with a supervisory authority
  • Where data was not collected from the individual — its source
  • Information about automated decision-making (if applicable) — logic, significance, and consequences

Providing a copy of the data alone is not sufficient. The supplementary information (Art. 15(1)(a)-(h)) is mandatory and forms a significant part of the response. Many SaaS companies fail precisely because they only provide the data export without the required context.

One month — and what resets the clock

The response deadline is one calendar month from the day you receive the request — not from when you verify identity, not from when you acknowledge it.

If you cannot verify identity: Article 12(6) allows you to request additional information to confirm identity. Once the requestor provides it, the one-month clock continues from the original receipt date — it does not restart. Document when the request was received and when identity was confirmed.

Extension to three months: For complex or numerous requests, you can extend by a further two months — but you must notify the requestor within the initial one-month period, explain why an extension is needed, and document the reason. Complexity here means the request is genuinely difficult to fulfil, not just that your systems are poorly organised.

Clock reset situations: If you ask for clarification about the scope of a request (not identity), the clock may be paused — but this is a grey area. The EDPB guidance suggests using clarification requests sparingly and only when genuinely necessary to find the data.

Data scattered across systems: the SaaS challenge

For SaaS companies, the hardest part of SAR compliance is not the response letter — it is finding all the data. A typical early-stage SaaS company holds personal data in:

  • Main application database (user accounts, usage data)
  • Analytics platform (Mixpanel, PostHog, Amplitude — usage events tied to user ID)
  • Error tracking (Sentry — may contain user IDs or emails in error context)
  • Support ticketing (Intercom, Zendesk, Freshdesk — conversation history)
  • Billing system (Stripe — name, email, address, payment history)
  • Email marketing (Mailchimp, Customer.io — subscription status, email history)
  • CRM (HubSpot, Salesforce — sales and marketing touchpoints)
  • Application logs (may contain IP addresses, user IDs, actions)
  • Backups

Your Data Retention Policy and internal RoPA (Records of Processing Activities) are the map for conducting a SAR search. Without this map, you risk missing data, which is itself a compliance failure — providing an incomplete SAR response is a violation of Article 15.

Identity verification: the balance

You cannot provide personal data to the wrong person — that would itself be a data breach under Article 5(1)(f) (integrity and confidentiality). But GDPR also prohibits requesting more information than is necessary to confirm identity.

Proportionate verification approaches:

  • For authenticated users: an email match to the account email is usually sufficient
  • For unauthenticated requests: you may ask for the email used to register, or other account-specific details (last 4 of card, username)
  • For requests involving special category data: a higher verification standard is proportionate
  • Demanding government ID for routine SARs from registered users is disproportionate and potentially discriminatory

If you cannot verify identity after reasonable attempts: respond in writing explaining that you are unable to proceed without identity confirmation, what additional information is needed, and their right to complain to the supervisory authority.

What can you withhold?

You do not have to provide everything in all circumstances. Key grounds for withholding or redacting:

  • Third-party personal data: If the data also contains personal information about another individual, you may need to redact it unless that person has consented or it would be reasonable to provide it without their consent (Art. 15(4), recital 63). Do not redact your own data — only data about third parties.
  • Legal professional privilege: Communications with legal advisers that are privileged may be withheld
  • Manifestly unfounded or excessive requests: A narrow exemption — you must document your reasoning thoroughly

When you withhold something, inform the requestor of this fact and the grounds, without necessarily revealing the content. Always tell them about their right to complain.

Format and delivery of the SAR response

The copy of data must be provided in electronic format by default when the request was made electronically (Art. 15(3)). For authenticated users making in-app requests, consider:

  • Data export feature: A self-service data export (JSON, CSV, HTML) in account settings is best practice — it handles the data copy element automatically, freeing your team for the supplementary information response
  • Encrypted attachment: For email delivery of sensitive data, encrypt the file or use a secure link
  • Secure portal: For complex responses with large data sets

Never send personal data over unencrypted email. The response itself (supplementary information) can be sent by email; the data copy should be provided via a secure method.

SAR response letter structure

A complete SAR response should include:

  1. Confirmation that you hold personal data (or confirmation that you do not)
  2. Acknowledgement of the Article 15 right and the request date
  3. Confirmation of identity verification method
  4. Data copy (attached or via secure link)
  5. Supplementary information: purposes, categories, recipients, retention, rights, source
  6. Information about automated decision-making (if applicable)
  7. Right to lodge complaint with supervisory authority (with contact details)
  8. Right to request rectification, erasure, or restriction
  9. Any data withheld and the grounds

Use our DSR Response Template Generator to generate a compliant SAR response letter. The generator covers all Article 15 requirements, handles the extension and refusal scenarios, and includes the mandatory supervisory authority contact details for your jurisdiction.

Employee SARs: a higher-stakes scenario

Employee SARs (from current or former employees) are the most complex and contentious. Employees frequently make SARs during or after employment disputes, grievances, or disciplinary proceedings. Key considerations:

  • The employee is entitled to all their personal data — including HR records, performance reviews, emails about them, disciplinary records, and management communications that reference them by name
  • Communications about the employee that also reference third parties (other employees) require careful redaction
  • Legal professional privilege may cover some communications — seek legal advice in contentious situations
  • The SAR response can and often does become evidence in employment tribunal proceedings

For HR data, also consider generating an Employee Privacy Notice to be proactive about data subject rights before disputes arise.

Key documents to have in place