What are GDPR data subject rights?
The GDPR grants individuals eight distinct rights over their personal data. As a SaaS company that processes personal data from EU/EEA residents, you are a data controller (or processor, or both) — and you must be able to honour these rights in a structured, documented, timely way.
Getting DSR handling wrong is expensive. The ICO fined Clearview AI £7.5 million in part for failing to facilitate data subject rights. Even smaller companies face investigations triggered by single complaints to supervisory authorities.
This guide covers all 8 rights, your obligations for each, how to structure your internal process, and when you can legally refuse a request.
The 8 GDPR data subject rights
1. Right of Access (Article 15)
Any individual can request confirmation of whether you process their personal data, and if so, a copy of that data plus supplementary information: processing purposes, data categories, recipients, retention periods, data origin, and information about any automated decision-making.
Your obligation: Provide the data free of charge within one calendar month. For complex or numerous requests, you can extend by a further two months — but you must notify the requestor of the extension and the reason within the initial one-month period.
Format: Electronic by default when the request was made electronically. The copy must be provided in a commonly used, machine-readable format where practicable.
Common SaaS challenge: Data is scattered across multiple systems — your main app database, analytics tools, support ticketing, billing system, email logs. A Subject Access Request (SAR) requires you to search all of them. Build your process before you get the first request.
2. Right to Rectification (Article 16)
Individuals can request correction of inaccurate personal data or completion of incomplete data. You must act without undue delay.
Your obligation: Correct inaccurate data promptly. If you have shared the data with third parties, notify them of the rectification — unless it is impossible or involves disproportionate effort (Art. 19).
Practical note: Most SaaS products allow users to update their own profile data. Ensure your account settings cover the main data fields. For data users cannot self-correct (billing records, analytics, support ticket content), you need a clear process to handle rectification requests.
3. Right to Erasure (Article 17) — "Right to be Forgotten"
Individuals can request deletion of their personal data when one of six grounds applies: the data is no longer necessary for its original purpose; they withdraw consent (and no other lawful basis exists); they object and no overriding legitimate interests exist; the data was unlawfully processed; erasure is required by EU or member state law; or the data was collected in relation to a child (online services).
Your obligation: Delete the data without undue delay. Notify third parties (processors, sub-processors) of the erasure request (Art. 19).
Exemptions that matter for SaaS:
- Legal obligation: Tax and accounting records must be retained for 5–7 years depending on jurisdiction — you can refuse erasure for these
- Legal claims: You can retain data needed to establish, exercise, or defend legal claims
- Freedom of expression / public interest: Less relevant for typical SaaS
The backup problem: Complete erasure from backups is practically complex. Most DPAs accept a documented approach: flag the data as deleted (so it is not restored from backup), and confirm it will be overwritten in the normal backup rotation cycle. Document this in your privacy policy.
4. Right to Restriction of Processing (Article 18)
In four situations, individuals can request that you restrict (but not delete) processing of their data: they contest the accuracy (during verification); processing is unlawful but they prefer restriction to erasure; you no longer need the data but they need it for legal claims; or they have objected pending verification of legitimate grounds.
Your obligation: Mark the data as restricted and only process it for storage, legal claims, protection of rights, or with the individual's consent. Notify them before lifting any restriction.
Technical implementation: This often means flagging records in your database so they are excluded from normal processing workflows. For multi-tenant SaaS, this needs to be implemented at the account or user level.
5. Right to Data Portability (Article 20)
Individuals can request their personal data in a structured, commonly used, machine-readable format — and have it transmitted directly to another controller where technically feasible.
Important limitation: Portability only applies to data processed by automated means AND based on consent (Art. 6(1)(a)) or contract (Art. 6(1)(b)). It does not apply to legitimate interests processing.
Your obligation: Provide data in JSON, CSV, or XML format within one month. If the requestor asks for direct transmission to another controller, you must do this where technically feasible — but you are not required to build new infrastructure to make this possible.
For SaaS founders: Think about what user-generated data is truly "theirs" — documents, records, settings, activity — versus data you generate as the controller (analytics, logs, derived inferences). Portability applies to the former.
6. Right to Object (Article 21(1))
Individuals can object to processing based on legitimate interests (Art. 6(1)(f)) or public interest (Art. 6(1)(e)), including profiling. You must stop processing unless you can demonstrate compelling legitimate grounds that override the individual's interests, rights, and freedoms, or the processing is for legal claims.
Critical point: The burden is on you to demonstrate compelling legitimate grounds — not on the individual to prove harm. This is a high bar.
7. Right to Object — Direct Marketing (Article 21(2))
This is an unconditional right. Individuals can object to their data being used for direct marketing at any time and you must stop immediately — no balancing test required, no grounds needed. This includes profiling for direct marketing purposes.
Your obligation: Stop all direct marketing processing immediately. Maintain a suppression list so the individual is not inadvertently re-added to marketing lists. Audit your email marketing lists and segmentation for compliance.
8. Rights Related to Automated Decision-Making (Article 22)
Individuals have the right not to be subject to decisions based solely on automated processing (including profiling) that produce legal or similarly significant effects on them.
Exceptions: Solely automated decisions are permitted if necessary for a contract, authorised by EU/member state law, or based on explicit consent — but even then, the individual has the right to obtain human review, express their point of view, and contest the decision.
For most SaaS founders: Standard analytics, product personalisation, and recommendation engines generally do not qualify as "solely automated decisions with legal or similarly significant effects." Credit scoring, insurance pricing, hiring algorithms, and fraud detection with hard blocks are the main risk areas.
Response timelines and obligations
| Obligation | Timeline | GDPR Reference |
|---|---|---|
| Respond to request | 1 calendar month from receipt | Art. 12(3) |
| Extension (complex/numerous) | +2 months — notify within 1 month | Art. 12(3) |
| Refuse with grounds | 1 calendar month | Art. 12(4) |
| Acknowledge receipt | As soon as possible — no hard deadline but best practice within 72h | Art. 12(3) |
| Fee for manifestly unfounded/excessive requests | Notify before charging | Art. 12(5) |
When can you refuse a DSR?
GDPR Article 12(5) allows you to refuse requests that are manifestly unfounded or excessive — particularly repetitive. But this is a narrow exception and you must document your reasoning carefully. The burden is on you to prove the request is manifestly unfounded.
Other valid grounds for refusing or limiting responses:
- Third-party rights: If providing the data would reveal personal data of another individual who has not consented, you may need to redact or refuse
- Legal obligation: You cannot delete data you are legally required to retain
- Legal claims: You can retain and process data needed for legal proceedings
- Identity not verified: Art. 12(6) allows you to request additional verification before responding — the clock stops until identity is confirmed
When refusing: You must inform the requestor of the refusal and its grounds within one month, notify them of their right to lodge a complaint with a supervisory authority, and their right to seek a judicial remedy (Art. 12(4)).
Building a scalable DSR process for SaaS
A repeatable internal process is essential — especially as you scale. Here is a practical framework:
- Single intake channel: Route all DSRs through one email (e.g., privacy@yourdomain.com) or a dedicated form. Avoid relying on support tickets or general inbox where requests get lost.
- Identity verification: For authenticated users, account email match is usually sufficient. For unauthenticated requests, ask for additional verification but do not demand disproportionate information (Art. 12(6)).
- Data mapping: Know where personal data lives across all systems — your app DB, analytics, billing, support, email marketing, logs. A RoPA (Article 30 records) is the foundation for this.
- Assign ownership: Designate a DPO or privacy owner who is responsible for acknowledging, coordinating, and responding to DSRs.
- Track the clock: Log receipt date and calculated deadline for every request. A simple spreadsheet works at early stage; dedicated tools (OneTrust, Withersworldwide, Osano) scale better.
- Maintain a register: Log all DSRs received, type, date, outcome, and whether deadline was met. This is evidence of compliance in case of supervisory authority audit.
- Sub-processor coordination: For erasure and portability requests, you may need to trigger actions with your sub-processors. Have a process for this.
Common mistakes to avoid
- No dedicated inbox: DSRs sent to general support email go unrecognised as formal legal requests
- Missing the deadline: A missed one-month deadline is the most common DSR compliance failure and triggers supervisory authority complaints
- Providing too much data to the wrong person: Incomplete identity verification leads to data breaches — always verify before responding to access requests
- Ignoring third-party data in responses: Including personal data of other users in an access request response creates a secondary breach
- Treating "manifestly unfounded" too broadly: This exemption is narrow; document your reasoning carefully before invoking it
- No backup deletion process: Erasure requests require a documented process for handling data in backups
Tools to handle DSRs
- DSR Response Template Generator — generate GDPR-compliant response letters for all 8 rights: access, erasure, portability, rectification, restriction, objection, direct marketing opt-out, and automated decision-making
- Privacy Policy Generator — disclose your DSR process and individual rights in your public privacy policy (mandatory under Art. 13/14)
- GDPR DPA Generator — coordinate DSR obligations with your sub-processors
- Data Retention Policy Generator — establishes the retention periods referenced in access request responses