GDPR DSAR Policy: How to Handle Data Subject Access Requests in SaaS

Data subject access requests (DSARs) are one of the most operationally demanding parts of GDPR compliance for SaaS companies. They're low-volume until they're not — and when a request comes from an unhappy customer, a former employee, or a privacy activist, you need a documented, repeatable process to avoid fines and complaints.

This guide covers what a GDPR-compliant DSAR policy needs to include, how to build a procedure that works at scale, and the common mistakes that lead to regulatory action.

What is a DSAR policy?

A DSAR policy (also called a data subject rights policy or privacy rights procedure) is an internal document that tells your team how to handle requests from individuals exercising their GDPR rights. It's not the same as your Privacy Notice (which tells users about their rights) — it's the internal playbook for responding to those requests.

A complete DSAR policy covers:

Which rights are in scope and what they require
How requests can be submitted (intake channels)
How to verify requestor identity without being invasive
Step-by-step response procedures per right
Timelines and when extensions are permitted
Grounds for refusing or limiting requests
DSR register and audit trail requirements
Escalation paths for complex or contested requests

Use the ComplyKit DSAR Policy Generator to generate a complete internal policy tailored to your company's setup — intake channels, data stores, rights in scope, and identity verification methods.

The 8 GDPR data subject rights your policy must cover

Right	GDPR Article	What it requires	SLA
Right of access (SAR)	Art. 15	Copy of personal data + 8 supplementary items (purposes, categories, recipients, transfers, retention, rights, sources, automated decisions)	1 month
Right to rectification	Art. 16	Correct inaccurate data; complete incomplete data	1 month
Right to erasure	Art. 17	Delete personal data where 6 grounds apply; notify recipients of erasure	1 month
Right to restriction	Art. 18	Pause processing while dispute resolved; must still store the data	1 month
Right to portability	Art. 20	Structured, machine-readable export of data provided under contract/consent only	1 month
Right to object	Art. 21	Object to processing based on legitimate interests; must cease unless compelling grounds	1 month
Right to object to direct marketing	Art. 21(2)	Unconditional — no balancing test, no compelling grounds defence. Must cease immediately.	Immediate
Rights re: automated decisions	Art. 22	Right not to be subject to solely automated decisions with legal/significant effects; right to human review, contest, explanation	1 month

Critical note on Art. 21(2): The right to object to direct marketing is unconditional. Unlike other rights, you cannot refuse it, delay it, or apply a balancing test. If someone objects to receiving marketing emails, you must stop — regardless of any contractual arrangements or consent you think you have. Failing to comply here is one of the most common DPA complaint triggers.

Intake channels: where requests can come from

One of the most common DSAR handling mistakes is failing to recognise requests that don't arrive via your designated channel. GDPR Art. 12(1) requires you to provide information and facilitate exercise of rights — it doesn't say "only via your privacy inbox." A support ticket saying "I want to see all my data" is a SAR. A live chat saying "please delete my account and all my data" is an erasure request.

Your DSAR policy should specify your intake channels and what happens when requests arrive informally:

Primary channel: privacy email inbox (e.g. privacy@company.com) — easy to set up, easy to search
In-product DSR form: self-service portal where users can submit and track requests — best practice for scale
Support ticket escalation: tag protocol for when support agents identify a rights request
Verbal/phone requests: Art. 12(2) — where requested in person, can be provided verbally if identity established

Key rule: all informal requests must trigger the formal process. Train support agents to escalate immediately. Never handle a rights request ad hoc in a support ticket thread.

Identity verification: the proportionality trap

Art. 12(6) allows you to request additional information to confirm identity when you have reasonable doubts. But "reasonable doubts" is a high bar, and verification must be proportionate to the risk. Over-demanding verification is itself a GDPR violation — it effectively denies the right.

Scenario	Appropriate verification	Over-demanding verification
SAR from registered user, email from their account address	Email match against account record	Demanding passport copy or video call
SAR from unknown email claiming to be a user	One-time verification link to account email	Demanding government ID upfront
SAR requesting special category data or highly sensitive info	Knowledge-based auth or ID verification proportionate to sensitivity	Demanding multiple IDs + notarised copies
Former employee SAR	HR records match, former work email confirmation	Demanding they return office equipment first

Never: refuse to process until you receive ID documentation as a default policy. The ICO and other DPAs have taken action against organisations using excessive verification as a delay tactic.

The 1-month clock and extension rules

GDPR Art. 12(3) sets the standard response deadline at 1 calendar month from receipt of the request. Not from when you verify identity — from when you receive the request. The clock stops while you're awaiting identity verification, but only if you request verification promptly.

Extensions under Art. 12(3): You can extend by up to 2 additional months (3 months total) for complex or numerous requests. But:

You must notify the requestor within the first 1 month that you're extending
You must explain the reasons for the extension
You cannot simply not respond and claim complexity after the deadline

Permitted extension triggers: high volume of simultaneous requests; request is technically complex (multiple systems, large data set, third-party data involvement); legal review required (potential refusal grounds); request received during holiday period with reduced staffing.

Refusal grounds: a high bar

Art. 12(5) allows you to refuse or charge a reasonable fee for requests that are "manifestly unfounded or excessive, in particular because of their repetitive character." The key word is manifestly — this is a high bar. DPAs have consistently held that:

A SAR from a disgruntled customer or ex-employee is not manifestly unfounded just because it's inconvenient
A second SAR within 12 months is not automatically excessive
You must document your reasoning for any refusal in detail

If you refuse, Art. 12(4) requires you to: (a) notify the requestor within 1 month, (b) explain the grounds for refusal, (c) inform them of their right to complain to a supervisory authority and seek a judicial remedy. Never simply ignore a request.

The DSR register: your compliance proof

Every DSAR must be logged — including those you refuse, those where no data is found, and those the requestor withdraws. The DSR register is your evidence of compliance in a regulatory investigation.

Minimum fields to log per request:

Unique request ID and date received
Right type (access, erasure, etc.)
Requestor name/identifier (hashed if preferred)
Verification status and method
Deadline (with extension date if applicable)
Response date
Outcome (fulfilled, partial, refused, no data found, withdrawn)
Notes (any third-party data withheld, refusal grounds applied, escalations)

Retain the DSR register for at least 3 years (some organisations retain for 5 years to cover the statute of limitations for civil claims). Restrict access to privacy/legal team.

Data stores: where to search for every SAR

For a SAR, you must search all systems where the requestor's data might exist. For most SaaS companies, this means:

Core application database (user accounts, usage records)
CRM (HubSpot, Salesforce — sales notes, contact data)
Support ticket system (Zendesk, Intercom — every support conversation)
Marketing email platform (Mailchimp, Customer.io — campaign data, click/open history)
Analytics platform (Mixpanel, Amplitude — note: often anonymised, but check)
Error tracking (Sentry — may contain personal data in breadcrumbs/stack traces)
Billing system (Stripe — payment history, but note: Stripe is a controller for payment processing)
Access logs (authentication logs, audit trails)
Backup systems (note: Art. 17 erasure from backups is complex — document your approach)

Document your data store search procedure in your DSAR policy. Auditors will ask which systems you searched and how you verified completeness.

Common DSAR handling mistakes

Missing informal requests: Customer support agent handles erasure request in a ticket without triggering the formal process
Clock miscalculation: Starting the 1-month clock from identity verification rather than request receipt
Excessive verification: Demanding passport copies for simple SARs from verified account holders
Incomplete Art. 15 response: Providing data export but missing 4-5 of the 8 supplementary items
Erasure from live systems only: Not documenting your approach to backup erasure (and not communicating it to recipients/sub-processors)
Refusing without Art. 12(4) notice: Not notifying the requestor of their complaint/judicial remedy rights when refusing
No DSR register: No audit trail when the DPA investigates

Related guides

Generate your DSAR Policy & Procedure → /generate/dsar-policy

⚠️ This guide is for informational purposes only and does not constitute legal advice. DSAR handling requirements may vary by jurisdiction. Engage qualified privacy counsel for complex or high-risk requests.

GDPR DSAR Policy: How to Handle Data Subject Access Requests in SaaS (2026)