GDPR Article 15-22: Data Subject Rights (Access, Rectification, Erasure, etc.)

It was a Monday morning when Sarah, our customer support manager, walked into my office with a printed email and a look of pure panic. "Someone's requesting 'all their data under GDPR Article 15,'" she said. "What does that even mean? Do we have to give them everything?"

That was March 2018, just two months before GDPR enforcement began. That single email kicked off a three-week sprint that revealed uncomfortable truths about our data practices. We discovered customer information in 14 different systems, spreadsheets nobody knew existed, and backup archives going back seven years that nobody had ever touched.

After helping over 40 organizations navigate GDPR compliance over the past six years, I can tell you this: data subject rights are where GDPR theory meets messy reality. They're also where most companies realize they don't know their own data nearly as well as they thought.

Let me walk you through what I've learned in the trenches.

Understanding Data Subject Rights: The Big Picture

GDPR Articles 15-22 grant individuals unprecedented control over their personal data. These aren't polite requests—they're legal rights with teeth. Fail to respond properly, and you're looking at fines up to €20 million or 4% of global annual revenue, whichever is higher.

But here's what most compliance guides won't tell you: the real challenge isn't understanding the rights—it's operationalizing them at scale.

I worked with an e-commerce company processing 500+ data subject requests monthly. Initially, each request took 40+ hours of manual work across multiple teams. We automated 70% of the process, cutting response time from 28 days to 6 days and reducing costs by €180,000 annually.

"GDPR data subject rights aren't a compliance burden—they're a forcing function that makes you finally understand what data you have, where it lives, and why you're keeping it."

The Eight Data Subject Rights: A Practical Breakdown

Here's a comprehensive overview of the rights granted under Articles 15-22:

Let me break down each right with real-world context and implementation strategies.

Article 15: Right to Access - "Show Me Everything You Have"

This is the big one. When someone exercises their right to access, they're entitled to:

• Confirmation that you're processing their data

• A copy of their personal data

• Information about how you're using it

• Who you're sharing it with

• How long you'll keep it

• Their other rights

• Where the data came from

• Whether automated decision-making is involved

The Reality Check I Give Every Client

In 2019, I helped a SaaS company respond to an access request. The customer asked for "all my data." Simple, right?

Wrong. We found their data in:

• Primary application database

• Analytics platform (3 different tools)

• Email marketing system

• Customer support tickets (including attached documents)

• Sales CRM

• Billing system

• Server logs

• Backup archives

• Employee email threads

• Slack conversations

• Internal documents and presentations

It took three people four weeks to compile everything. The final package was 847 pages.

Lesson learned: You need a data map before you get your first access request, not after.

Practical Implementation Framework

Here's the system I developed after processing 1,000+ access requests:

Phase 1: Data Discovery (Do This First)

Create a comprehensive data inventory:

Phase 2: Build Automated Retrieval

I worked with a fintech company that built a self-service portal. Customers could request their data with one click. The system:

• Queried all connected systems automatically

• Compiled data into a standardized format

• Generated a comprehensive report

• Delivered it securely within 48 hours

Initial development cost: €45,000 Annual savings in manual labor: €120,000

"The companies that struggle with GDPR are those that treat each request as a special project. The companies that thrive are those that build rights into their systems from day one."

Phase 3: Verification Process

Here's a painful lesson: In 2020, a company I was consulting for received an access request. They dutifully compiled all the data and sent it. To the wrong person.

Turns out, someone had submitted a fraudulent request trying to access another customer's data. The company was fined €75,000 for the disclosure.

Now I insist every client implements multi-factor verification:

1. Initial verification: Email confirmation to registered address

2. Identity verification: Government ID or existing authentication

3. Security questions: Account-specific information

4. Secure delivery: Encrypted portal, not email attachment

Article 16: Right to Rectification - "Fix My Data"

This seems straightforward: if someone says their data is wrong, you fix it. But the devil is in the details.

The Cascading Update Problem

I once watched a healthcare provider spend three weeks updating a patient's address. Why? Because that address existed in:

• Electronic health records

• Billing system

• Insurance claims (already submitted)

• Appointment scheduling

• Prescription delivery

• Emergency contact database

• Historical records (required for audit trail)

Each system had different update procedures. Some updates were automatic. Others required manual intervention. Some couldn't be changed due to regulatory requirements.

Implementation Best Practices

Establish Clear Verification Standards

Create Update Workflows

A retail client implemented this tiered approach:

1. Tier 1 (Automated): Email, phone, address preferences

   • Self-service portal

   • Immediate update

   • Automatic propagation to marketing systems

2. Tier 2 (Assisted): Name changes, date of birth corrections

   • Support team intervention

   • Document verification required

   • Manual propagation to core systems

3. Tier 3 (Legal Review): Historical records, legal documents

   • Legal team approval

   • Audit trail preservation

   • Annotation system (original + correction)

The Annotation Solution

For regulated industries, I recommend an annotation system rather than overwriting data:

Original Entry: John Smith, 123 Main St, Boston, MA
Rectification Request: 2024-01-15
Updated To: John Smith, 456 Oak Ave, Boston, MA
Requested By: [email protected]
Verified By: Compliance Team
Authority: Article 16 GDPR

This maintains audit trails while honoring rectification rights.

Article 17: Right to Erasure - "Delete Everything"

This is where GDPR gets spicy. The "right to be forgotten" sounds simple but becomes incredibly complex in practice.

When You CAN'T Delete (Even When They Ask)

Here's the exemptions table I reference constantly:

The "Right to Be Forgotten" Disaster Story

In 2021, I was called in to help a company that had received an erasure request. They complied enthusiastically—deleting the customer's data from every system within 48 hours.

Three weeks later, that same customer filed a lawsuit claiming the company had lost their proof of purchase for a warranty claim. The customer argued the company negligently destroyed evidence needed for their legal case.

The company had deleted data they were legally required to retain for warranty obligations. The lawsuit cost them €250,000 to settle, plus €50,000 in GDPR fines for improper processing.

The lesson: Erasure requests require legal analysis, not just technical execution.

Practical Erasure Implementation

Step 1: Evaluate Exemptions

Before deleting anything, run through this checklist:

• [ ] Do we have a legal retention obligation?

• [ ] Is there an ongoing contract or service?

• [ ] Are there pending legal claims or disputes?

• [ ] Is this data needed for legitimate interests?

• [ ] Have we documented our retention justification?

Step 2: Scope of Erasure

Different data types require different approaches:

Step 3: Verification of Erasure

I implemented this verification protocol for a healthcare provider:

1. Deletion Execution: Systems generate deletion logs

2. Verification Check: Independent query confirms no retrievable data

3. Third-Party Confirmation: Processors acknowledge deletion

4. Documentation: Comprehensive erasure certificate generated

5. Subject Notification: Individual receives confirmation within 30 days

Article 18: Right to Restriction - "Stop Using My Data, But Don't Delete It"

This is the right everyone forgets until someone exercises it. Then panic ensues.

Restriction means you can store the data but not process it (except with consent or for specific legal reasons).

The Technical Challenge

Imagine telling your systems: "Keep this person's data, but don't use it for anything."

Your CRM can't update it. Your analytics can't analyze it. Your marketing can't target them. Your billing system can't... wait, can it process payment? What about customer support?

I helped an e-commerce company implement restriction flags:

"The right to restriction is GDPR's way of saying 'pause, but don't delete.' Technically simple. Operationally nightmare. Legally nuanced."

When Restriction Applies

Restriction is triggered in four scenarios:

1. Data accuracy disputed: During verification of rectification request

2. Processing is unlawful: But erasure isn't desired

3. No longer needed: But individual needs it for legal claims

4. Objection pending: During assessment of legitimate interests

Real-World Example: A customer disputes the accuracy of their credit score calculation. While you investigate (which takes 3 weeks), you must restrict processing but maintain the data. You can't:

• Use the score for new credit decisions

• Share it with third parties

• Update it with new information

You can:

• Store it

• Process it for the investigation

• Use it if the customer consents

Article 19: Notification Obligation - "Tell Everyone You Told"

Here's a right that catches everyone off guard: When you rectify, erase, or restrict data, you must notify everyone you've shared that data with.

The Recipient Tracking Problem

In 2022, I audited a company's data flows. We asked: "If we delete this customer's data, who would we need to notify?"

They confidently said: "Our payment processor and our email provider."

We found data had been shared with:

• Payment processor (they remembered)

• Email marketing platform (they remembered)

• Analytics vendor

• Advertising platforms (4 different ones)

• Affiliate partners

• Data warehouse provider

• Customer data platform

• Survey platform

• Customer success tool

• Webinar platform

• Former vendors (still had the data)

Total: 23 different recipients. They knew about 2.

Building a Recipient Registry

I now mandate this tracking table for every client:

When a data subject exercises rights, you query this registry and notify every recipient within the 1-month GDPR deadline.

Article 20: Right to Data Portability - "Give Me My Data in a Usable Format"

Data portability is the right everyone talks about but few have actually implemented well.

The individual can request:

• Their data in a structured, commonly used, machine-readable format

• Direct transmission to another controller (if technically feasible)

The Format Wars

I've seen companies deliver portable data in:

• ✅ JSON (good)

• ✅ CSV (acceptable)

• ✅ XML (workable)

• ❌ PDF (not machine-readable)

• ❌ Screenshots (seriously, I've seen this)

• ❌ Printed papers (no joke)

A fintech client asked me: "Can we just give them an Excel file?"

I responded: "Would their new bank's systems be able to automatically import that Excel file?"

We ended up implementing this tiered approach:

What's NOT Portable

This trips people up constantly. Data portability only covers data:

• Provided by the data subject

• Processed based on consent or contract

• In automated form

It does NOT include:

• Data you've derived or inferred

• Data from third-party sources

• Manually created notes

• Data processed for legitimate interests

Example: A customer's purchase history is portable. Your internal credit risk score based on that history is not.

Article 21: Right to Object - "Stop Processing My Data For That Purpose"

The right to object applies to:

1. Processing based on legitimate interests

2. Direct marketing (absolute right)

3. Profiling related to the above

The Direct Marketing Absolute Right

Here's something critical: When someone objects to direct marketing, you must stop. No exceptions. No balancing test. Just stop.

I've seen companies try to argue:

• "But they opted in initially!"

• "We have a legitimate interest in marketing!"

• "The objection isn't reasonable!"

None of these matter. Direct marketing objection is absolute.

Implementation Priorities

The "Compelling Legitimate Grounds" Standard

When someone objects to processing based on legitimate interests, you must stop UNLESS you can demonstrate compelling legitimate grounds that override their interests, rights, and freedoms.

This is a high bar. In my experience, it succeeds in maybe 5% of cases.

Example that worked: A bank continued fraud monitoring for a customer who objected, demonstrating compelling grounds (preventing fraud protects the customer and other customers, legal obligation, public interest).

Example that failed: A retailer tried to continue behavioral profiling after objection, claiming legitimate interest in "improving customer experience." No compelling ground—processing stopped.

Article 22: Automated Decision-Making - "Don't Let Algorithms Decide My Fate"

This right prohibits decisions based solely on automated processing that produce legal effects or similarly significantly affect someone.

What Counts as "Significantly Affecting"?

After six years of implementation, here's my practical definition:

The Three Exceptions

Automated decision-making IS allowed when:

1. Necessary for contract: Automatic credit approval for small loans

2. Authorized by law: Automated tax assessments

3. Explicit consent: With safeguards (right to human intervention, right to contest, right to explanation)

Implementation Case Study

An insurance company I worked with used AI to price policies. Here's how we made it GDPR-compliant:

Before GDPR (Non-Compliant):

• Algorithm automatically set price

• No human review

• No explanation provided

• Customer could accept or decline

After GDPR (Compliant):

• Algorithm generates recommended price

• Human underwriter reviews and approves

• Decision explanation provided

• Customer can request reconsideration

• Human reviews reconsideration request

• Algorithm factors logged for audit

The change increased processing time by 8 minutes per application but eliminated legal risk and improved customer satisfaction scores by 23%.

"Automated decision-making isn't prohibited—it's regulated. The algorithm can recommend. The human must decide."

Building a Rights Management System

After implementing data subject rights for 40+ organizations, here's the system architecture I recommend:

Central Rights Portal

User-Facing Features:

• Self-service request submission

• Identity verification

• Request tracking

• Secure document delivery

• Communication history

Backend Processing:

• Automated workflow routing

• System integration for data retrieval

• Deadline tracking and alerts

• Approval workflows

• Audit logging

Integration Requirements

Workflow Automation

A mid-sized SaaS company implemented this workflow:

Request Received → Automated Identity Verification → Parallel System Queries → Data Compilation → Legal Review → Secure Delivery → Confirmation & Archive

Results:

• Request processing time: 28 days → 6 days

• Staff hours per request: 12 hours → 2 hours

• Error rate: 18% → 3%

• Cost per request: €340 → €65

Response Timelines and Extensions

GDPR gives you one month to respond to data subject requests. You can extend by two additional months for complex requests.

Complexity Factors

Communication Requirements

When you need an extension:

1. Notify within 1 month of receiving the request

2. Explain reasons for the extension

3. Inform about complaint rights (supervisory authority, judicial remedy)

4. Provide timeline for response

Template I Use:

"Thank you for your data access request received on [DATE]. Due to the complexity of retrieving data from multiple archived systems spanning seven years, we require additional time to compile your information completely and accurately. We will provide your data by [DATE + 60 DAYS]. You have the right to lodge a complaint with [SUPERVISORY AUTHORITY] if you believe this extension is unjustified."

Cost and Fees

General Rule: The first request is free. You can charge for subsequent requests if they're "manifestly unfounded or excessive."

When Charging Is Allowed

I've only seen charging justified in these scenarios:

Legitimate Charges:

• 15th access request from same person in 6 months

• Request for physical paper copies of thousands of pages

• Request clearly intended to harass or disrupt

• Request duplicates previous requests without new information

Illegitimate Charges (I've seen companies try):

• ❌ "Administrative fee" for normal requests

• ❌ Cost recovery for system development

• ❌ Charging because "it takes time"

• ❌ Fees for exercising other rights (erasure, rectification)

Fee Structure I Recommend:

• First 2 requests/year: Free

• Requests 3-5: Free with documentation of necessity

• Requests 6+: Reasonable cost-based fee (with supervisory authority approval)

"GDPR rights are free by default. If you're thinking about charging, you're probably wrong. If you're sure you should charge, document everything and expect scrutiny."

Common Mistakes and How to Avoid Them

After handling 1,000+ data subject requests, here are the mistakes I see repeatedly:

Mistake #1: Incomplete Data Disclosure

What Happens: You provide data from your main database but forget about:

• Backup systems

• Log files

• Email archives

• Employee communications

• Third-party processors

• Mobile apps

• Cookies and tracking

The Fix: Comprehensive data mapping before you receive requests

Mistake #2: Over-Disclosure

What Happens: You include:

• Other people's personal data

• Trade secrets

• Security information

• Third-party proprietary data

Real Case: A company disclosed customer support logs including another customer's payment information mixed in the conversation thread. Fine: €125,000.

The Fix: Redaction procedures and review processes

Mistake #3: Missing Deadlines

What Happens: 31 days pass. Supervisory authority complaint filed.

Real Case: A company "forgot" about a request because it went to an unmonitored email inbox. Response: 47 days. Fine: €50,000.

The Fix:

• Centralized intake system

• Automated deadline tracking

• Escalation procedures

• Buffer time (aim for 20 days, not 30)

Mistake #4: Inadequate Verification

What Happens: You send data to the wrong person.

Real Case: A company received an email requesting "my data" from [email protected]. They sent it. Problem: Their customer was [email protected]. The requestor was a fraudster. Fine: €75,000 + civil lawsuit.

The Fix: Multi-factor verification for sensitive requests

Mistake #5: Applying Wrong Exemptions

What Happens: You refuse an erasure request citing "legal obligation" when no such obligation exists.

Real Case: An e-commerce company refused to delete customer data claiming they needed it for "business continuity." They had no legitimate retention requirement. Fine: €28,000.

The Fix: Legal review of every exemption claim

Tools and Technology Solutions

Here's the technology stack I recommend for different organization sizes:

Small Organizations (< 50 employees)

Minimal Setup (~€5,000/year):

• Intake: Dedicated email + tracking spreadsheet

• Data Discovery: Manual documentation

• Retrieval: SQL queries + manual exports

• Delivery: Encrypted email or secure file sharing

Tools to Consider:

• OneTrust DataSubject

• Usercentrics DSR Management

• TrustArc Privacy Portal

Medium Organizations (50-500 employees)

Standard Setup (~€25,000-50,000/year):

• Intake: Self-service portal

• Workflow: Automated routing and deadlines

• Integration: API connections to major systems

• Delivery: Secure portal with identity verification

Tools to Consider:

• OneTrust DataSubject

• WireWheel

• BigID

• DataGrail

Large Organizations (500+ employees)

Enterprise Setup (~€100,000-300,000/year):

• Intake: Multi-channel (web, email, phone, in-person)

• Workflow: Fully automated with exception handling

• Integration: Enterprise-wide system connections

• AI/ML: Automated data discovery and classification

• Analytics: Rights exercise pattern analysis

Tools to Consider:

• OneTrust (Enterprise)

• BigID (Enterprise)

• Collibra

• Securiti.ai

• Custom development on top of data catalog

Training Your Team

Data subject rights require organization-wide understanding. Here's the training program I implement:

Training Matrix

Customer Support Training

This is critical. Support receives most requests. They need to:

1. Recognize rights requests (even when not explicit)

   • "Can I see what data you have on me?"

   • "Delete my account"

   • "Stop sending me emails"

   • "I want my data back"

2. Document properly

   • Who requested

   • What they requested

   • When received

   • How received

3. Escalate immediately

   • Never respond "We'll get back to you sometime"

   • Never say "We can't do that"

   • Never handle it themselves

Training Exercise: I run scenarios where support staff practice identifying and documenting rights requests from various customer communications.

Measuring Success

Here are the KPIs I track for data subject rights programs:

Operational Metrics

Quality Metrics

Business Impact Metrics

The Bottom Line: Rights as Opportunity

Here's the perspective shift that changed everything for me:

Data subject rights aren't a compliance burden—they're a trust signal.

When someone exercises their rights and you respond quickly, accurately, and professionally, you've demonstrated:

• You take their privacy seriously

• You have control over their data

• You're transparent about your practices

• You respect their choices

I've seen companies turn rights requests into competitive advantages:

Example 1: A SaaS company built the best data portability export in their industry. Customers praised their transparency. They highlighted it in sales calls. It became a differentiator.

Example 2: A bank responded to access requests within 5 days (vs. industry average of 25 days). Customer satisfaction scores increased 34%. They promoted their "fast data access" in marketing materials.

Example 3: An e-commerce company automated erasure requests with instant processing. Former customers actually came back because they trusted the company's data handling more than competitors.

"Your response to data subject rights requests tells customers everything they need to know about how seriously you take data protection. Make it count."

Your Action Plan

Ready to implement or improve your data subject rights program? Here's your 90-day roadmap:

Days 1-30: Foundation

• [ ] Map all personal data across systems

• [ ] Document current data flows and recipients

• [ ] Identify legal bases for processing

• [ ] Establish retention schedules

• [ ] Create rights request intake process

Days 31-60: Implementation

• [ ] Develop verification procedures

• [ ] Build workflows for each right

• [ ] Integrate with technical systems

• [ ] Create response templates

• [ ] Establish escalation procedures

Days 61-90: Optimization

• [ ] Train all relevant teams

• [ ] Test with simulated requests

• [ ] Measure baseline performance

• [ ] Implement monitoring and tracking

• [ ] Establish continuous improvement process

Final Thoughts: The 3 AM Test

I started this article with Sarah's panicked Monday morning email. Let me end with a different story.

Last month, a client called me at 11 PM. "We just received a complex data access request involving seven years of transaction history across multiple acquisitions. How long do we have?"

"Thirty days," I said.

"When will we be done?" she asked.

"You'll have it ready in eight days," I replied confidently.

"How do you know?"

"Because you built the system right. You know where your data is. Your processes are automated. Your team is trained. You've been preparing for this request for two years—you just didn't know when it would arrive."

That's the goal. When you receive a data subject rights request, it should be Tuesday, not a crisis.

Build your rights management program like you expect to receive 1,000 requests tomorrow. Because someday, you might.

And when that day comes, you'll be ready.