⚖ The 8 Data Subject Rights
GDPR grants individuals (data subjects) eight powerful rights over their personal data. As a consultant, you must ensure your client can operationally fulfill ALL of these rights. Failing to respond to a rights request properly and on time is one of the most common reasons organizations get fined.
Right to be Informed
Articles 13-14🎓 What It Means: People have the right to know what you are doing with their data BEFORE you do it. You must be transparent about what data you collect, why, how long you keep it, and who you share it with. This is typically fulfilled through privacy notices.
What You Must Do
- ✓ Provide a clear, plain-language privacy notice at every point where you collect data
- ✓ Include: your identity, contact details, DPO contact, purposes, lawful basis, recipients, transfer info, retention periods, and their rights
- ✓ If you did not collect data directly from the person, inform them within one month of obtaining it
- ✓ Use layered notices (short summary + link to full notice) for better user experience
- ✓ Review and update privacy notices whenever processing activities change
Implementation Checklist
- ☐ Audit all data collection points (web forms, apps, paper forms, phone, in-store)
- ☐ Draft or update privacy notice with all Article 13/14 required information
- ☐ Implement layered approach: short notice at collection point, link to full notice
- ☐ Ensure notice is provided BEFORE or AT the time of collection
- ☐ Set up a process to review the privacy notice quarterly
- ☐ Test readability — aim for an 8th-grade reading level
⚠ Common Mistakes
- ❌ Using impenetrable legal jargon that nobody reads or understands
- ❌ Having a single generic privacy notice that does not cover all processing activities
- ❌ Failing to update the privacy notice when new processing activities are added
- ❌ Not providing a notice when collecting data indirectly (e.g., from a third party or public source)
- ❌ Burying the privacy notice behind multiple clicks instead of making it easily accessible
📚 Real-World Example: The Irish DPC fined WhatsApp 225 million EUR in 2021 partly because its privacy notice did not adequately inform users about how their data was shared with other Meta companies. The notice existed but was not transparent enough.
Right of Access (DSAR)
Article 15🎓 What It Means: Any person can ask your client: 'What personal data do you have about me?' and your client MUST provide a complete copy of all their personal data, plus information about how it is processed. This is called a Data Subject Access Request (DSAR). You have ONE MONTH to respond.
What You Must Do
- ✓ Establish a process to receive, verify, and respond to DSARs within 30 days
- ✓ Search ALL systems where personal data may exist (databases, email, backups, paper files, CCTV)
- ✓ Provide the data in a commonly used electronic format (CSV, PDF, JSON)
- ✓ Include supplementary information: purposes, categories, recipients, retention periods, rights info
- ✓ Verify the identity of the requester before disclosing any data
- ✓ Do NOT charge a fee unless the request is manifestly unfounded or excessive
Implementation Checklist
- ☐ Create a DSAR intake process (email, web form, postal address, phone — accept all channels)
- ☐ Build an identity verification procedure (do not over-verify — proportionate to risk)
- ☐ Map all systems containing personal data so you know where to search
- ☐ Create a DSAR response template letter
- ☐ Set up a tracking system with deadline alerts (Day 1, Day 14 warning, Day 25 escalation)
- ☐ Train customer-facing staff to recognize and escalate DSARs
- ☐ Test the process with a mock DSAR before going live
⚠ Common Mistakes
- ❌ Not searching ALL systems — missing email, chat logs, CCTV footage, paper files, or backups
- ❌ Taking longer than 30 days without properly extending the deadline
- ❌ Disclosing third-party personal data that was included in the same records
- ❌ Not having a process in place and scrambling when the first DSAR arrives
- ❌ Requiring the requester to use a specific form (they can make the request in any format)
📚 Real-World Example: Organizations routinely underestimate DSAR complexity. A single DSAR for a long-term employee could require searching HR systems, email (years of messages), file shares, CCTV, building access logs, IT support tickets, and performance reviews. Some organizations report spending 20+ hours on a single complex DSAR.
Right to Rectification
Article 16🎓 What It Means: If a person's data is inaccurate or incomplete, they have the right to have it corrected. Your client must fix it without undue delay and notify any third parties who received the incorrect data.
What You Must Do
- ✓ Establish a process for individuals to request corrections to their data
- ✓ Correct inaccurate data without undue delay (no specific deadline, but promptly)
- ✓ Allow individuals to supplement incomplete data with additional information
- ✓ Notify all recipients who received the inaccurate data about the correction
- ✓ Update the data across ALL systems, not just the primary one
Implementation Checklist
- ☐ Create a data correction request process (self-service + assisted channels)
- ☐ Map data flows to know where data needs to be corrected across systems
- ☐ Build a procedure for notifying third-party recipients of corrections
- ☐ Set up data quality controls to reduce the need for corrections in the first place
- ☐ Log all rectification requests and actions taken
⚠ Common Mistakes
- ❌ Correcting data in the primary system but not in downstream systems, backups, or third parties
- ❌ Requiring excessive proof before making a correction
- ❌ Not having a mechanism for individuals to request corrections (self-service portal is ideal)
- ❌ Forgetting to notify third parties who received the incorrect data
📚 Real-World Example: A credit reference agency that does not correct inaccurate credit data when requested can face GDPR action. Individuals have used this right to correct wrong addresses, misspelled names, incorrect employment records, and erroneous financial data that affected their credit scores.
Right to Erasure (Right to be Forgotten)
Article 17🎓 What It Means: Individuals can request that your client delete all their personal data. However, this is NOT absolute — there are important exceptions. Your client can refuse if the data is needed for legal compliance, legal claims, public interest, or other specified grounds.
What You Must Do
- ✓ Establish a process to receive and assess erasure requests
- ✓ Evaluate whether an exemption applies before deleting
- ✓ If no exemption: erase all personal data without undue delay (target: within 30 days)
- ✓ Erase from ALL systems including backups (or isolate backup data with a suppression list)
- ✓ Notify all third parties who received the data to also erase it
- ✓ If the data was made public (e.g., online), take reasonable steps to inform other controllers
Implementation Checklist
- ☐ Create an erasure request intake and assessment process
- ☐ Document all exemptions (legal holds, regulatory retention, etc.) and train staff on them
- ☐ Map all locations where personal data exists (including backups and third parties)
- ☐ Implement a suppression list to prevent re-collection of erased data
- ☐ Build an automated or semi-automated deletion workflow across systems
- ☐ Create response templates for both compliance and refusal (with reasons)
⚠ Common Mistakes
- ❌ Treating the right as absolute and deleting data that is legally required to be retained
- ❌ Deleting from the primary system but not from backups, archives, or third parties
- ❌ Not maintaining a suppression list — leading to the person's data being re-collected
- ❌ Taking too long to process the request
- ❌ Not documenting the legal grounds when refusing an erasure request
📚 Real-World Example: Google has received over 1.4 million erasure requests since GDPR enforcement began, asking for URLs to be de-listed from search results. The right to be forgotten does not mean Google must delete the source content — only its index entry. This illustrates the nuance of this right.
Right to Restrict Processing
Article 18🎓 What It Means: Individuals can request that your client STOPS processing their data (but keeps it stored) in specific circumstances: when accuracy is contested, when processing is unlawful but the individual prefers restriction over erasure, when the data is needed for legal claims, or when the individual has objected to processing and you are verifying your grounds.
What You Must Do
- ✓ Implement a mechanism to 'freeze' personal data — store it but stop all processing
- ✓ Clearly mark restricted data in your systems so it is not accidentally processed
- ✓ Only process restricted data with the individual's consent, for legal claims, to protect others, or for important public interest
- ✓ Inform the individual before lifting the restriction
- ✓ Notify any third parties who received the data about the restriction
Implementation Checklist
- ☐ Design a technical mechanism to flag and restrict records (e.g., status field, separate restricted table)
- ☐ Ensure restricted records are excluded from all automated processing and queries
- ☐ Create a process for reviewing and lifting restrictions
- ☐ Train staff on the difference between restriction, erasure, and objection
- ☐ Test that restricted data does not appear in reports, exports, or automated processes
⚠ Common Mistakes
- ❌ Not having a technical mechanism to restrict processing while retaining data
- ❌ Accidentally including restricted data in routine processing (reports, analytics, marketing)
- ❌ Confusing restriction with erasure — restriction means KEEP but STOP USING
- ❌ Lifting the restriction without informing the individual first
📚 Real-World Example: An individual disputes the accuracy of their data in your system. While you investigate whether the data is correct, you must restrict processing — keep the data but stop using it for decisions, analytics, or sharing until the dispute is resolved.
Right to Data Portability
Article 20🎓 What It Means: Individuals have the right to receive their personal data in a structured, commonly used, machine-readable format AND to have it transmitted directly to another controller. This only applies to data processed by automated means based on consent or contract.
What You Must Do
- ✓ Provide personal data in a structured, commonly used, machine-readable format (JSON, CSV, XML)
- ✓ Where technically feasible, transmit the data directly to another controller upon request
- ✓ Include only data the individual provided (directly or through use of a service), not derived or inferred data
- ✓ Provide the data free of charge
- ✓ Respond within one month
Implementation Checklist
- ☐ Identify which processing activities are based on consent or contract (only these are portable)
- ☐ Build an export function that outputs data in CSV, JSON, or XML format
- ☐ Distinguish between provided data (portable) and derived/inferred data (not portable)
- ☐ Explore API options for direct controller-to-controller transfer
- ☐ Test the export to ensure completeness and machine-readability
⚠ Common Mistakes
- ❌ Providing data in a PDF (not machine-readable) instead of CSV/JSON/XML
- ❌ Including derived data (scores, profiles) that is not covered by portability
- ❌ Refusing to transmit directly to another controller when it is technically feasible
- ❌ Confusing portability with access — portability has a narrower scope (only consent/contract-based, automated processing)
📚 Real-World Example: A customer wants to switch from your CRM to a competitor. Under portability, they can request all the data they provided (contact info, purchase history, preferences) in a machine-readable format to import into the new CRM. You do not need to export your internal scoring or segmentation data.
Right to Object
Article 21🎓 What It Means: Individuals can object to processing based on legitimate interests or public task. For DIRECT MARKETING, the right to object is ABSOLUTE — you must stop immediately, no exceptions. For other processing, you can continue only if you demonstrate compelling legitimate grounds that override the individual's interests.
What You Must Do
- ✓ Immediately stop processing for direct marketing when an individual objects (no exceptions)
- ✓ For non-marketing objections, assess whether your legitimate grounds override the individual's interests
- ✓ Inform individuals of their right to object at the point of first communication
- ✓ Make it as easy to object as it is to opt in (e.g., one-click unsubscribe)
- ✓ Document your assessment when you reject an objection (non-marketing cases only)
Implementation Checklist
- ☐ Implement one-click unsubscribe for all marketing communications
- ☐ Create a process for receiving and handling non-marketing objections
- ☐ Build a Legitimate Interest Assessment (LIA) template for evaluating objections
- ☐ Ensure the right to object is clearly stated in all privacy notices
- ☐ Train marketing teams that objection to direct marketing is absolute and immediate
- ☐ Add objection handling to your DSAR/rights management workflow
⚠ Common Mistakes
- ❌ Not stopping direct marketing processing immediately upon objection
- ❌ Making it difficult to object (e.g., requiring a phone call or written letter when they opted in online)
- ❌ Not informing people about their right to object clearly and separately from other information
- ❌ Continuing to process after an objection without documenting compelling grounds
📚 Real-World Example: Every marketing email must have a working unsubscribe link. If someone clicks unsubscribe (exercising their right to object to direct marketing), you must stop ALL direct marketing to that person immediately. You cannot say 'it will take 30 days to process' or 'please confirm by email'.
Rights Related to Automated Decision-Making and Profiling
Article 22🎓 What It Means: Individuals have the right NOT to be subject to a decision based solely on automated processing (including profiling) that produces legal or similarly significant effects. In plain English: you cannot let an algorithm make important decisions about a person without human involvement, unless specific conditions are met.
What You Must Do
- ✓ Identify all automated decision-making processes that produce legal or significant effects
- ✓ Ensure meaningful human review is part of any significant automated decision
- ✓ Inform individuals when automated decision-making is used, the logic involved, and its significance
- ✓ Provide a mechanism for individuals to request human intervention, express their point of view, and contest the decision
- ✓ Do NOT use special category data in automated decisions unless explicit consent or substantial public interest applies
Implementation Checklist
- ☐ Audit all systems that make automated decisions (credit scoring, fraud detection, HR screening, insurance pricing)
- ☐ Classify which automated decisions produce legal or similarly significant effects
- ☐ Ensure meaningful human review exists for all qualifying decisions
- ☐ Create plain-language explanations of the logic behind each automated system
- ☐ Implement a contest/appeal process for individuals affected by automated decisions
- ☐ Document the lawful basis for any purely automated decisions (consent, contract necessity, or legal authorization)
⚠ Common Mistakes
- ❌ Not realizing that credit scoring, automated recruitment screening, or insurance pricing algorithms fall under this right
- ❌ Having 'human review' that is just a rubber stamp — it must be meaningful
- ❌ Not being able to explain the logic of automated decisions in plain language
- ❌ Failing to offer an appeal/contest mechanism
📚 Real-World Example: An online lender uses an AI algorithm to automatically approve or reject loan applications with no human review. This is likely a solely automated decision with legal effects (credit denial). Under GDPR, the lender must either add meaningful human review or ensure one of the Article 22(2) exceptions applies, and must always allow the individual to contest the decision.