Quick Answer
GDPR Articles 15, 17, and 20 create hard operational deadlines. Article 15 (right of access) requires you to provide a copy of all personal data held within one month of a valid request. Article 17 (right to erasure) requires deletion from every system where data is held — including archived CSV files and backups. Article 20 (right to data portability) requires you to provide personal data in a structured, machine-readable format — GDPR explicitly cites CSV as an appropriate format. Organisations that can't find one person's data across all their CSV files cannot comply.
Fast Fix (2 Minutes)
If you've received a data subject request and need to find a person's data in CSV files:
- Search every CSV export location — shared drives, email attachments, analytics platforms, backup folders. The obligation covers every system where data is held, not just the live database.
- Use SplitForge Find & Replace — search for the person's email address or customer ID across large files without uploading their data to a cloud search tool.
- Document what you find — which files contain the data, what columns, what dates. This is your response record.
- For deletion requests — remove the matching rows and save the cleaned file back to every location. One file is not sufficient if copies exist elsewhere.
- Respond within one month — the clock starts when you receive the valid request, not when you start processing it.
TL;DR: Data subject rights aren't just a database problem. Every CSV export, analytics file, shared spreadsheet, and email attachment containing personal data is in scope. Access requests require you to compile everything. Erasure requests require you to delete from everything. Portability requests require you to deliver the data in CSV or equivalent format within a month. The organisations that struggle are those without a map of where their CSV data lives.
Most GDPR data subject request procedures are built around live databases and CRM systems. They work well when data lives in one place. They fall apart when someone asks: "Can you give me every piece of data you hold about me?" — and the answer involves 14 CSV exports sitting in a shared Google Drive folder, 6 email attachments, and 3 archived analytics reports.
This is where most organisations fail data subject requests. Not because they refuse. Because they can't find everything.
GDPR does not recognise "we couldn't find it in time" as a valid response. The one-month deadline runs from the date of the valid request regardless of how distributed your data is.
Each scenario in this post was assessed against GDPR Articles 15, 17, and 20; the EDPB Guidelines 01/2022 on the right of access; and standard UK GDPR implementation practice, March 2026.
What "Every System Where Data Is Held" Actually Means
Article 15 right of access requires you to provide a copy of all personal data being processed. "Being processed" includes stored data — not just live database records.
That means:
- Active CRM records — obvious
- CSV exports sitting in shared drives — in scope
- Email attachments sent to colleagues containing customer data — in scope
- Analytics platform exports archived for reporting — in scope
- Backup CSV files — in scope
- Vendor-held copies (if you transferred data to a processor) — in scope for the processor to respond to
❌ INCOMPLETE ACCESS RESPONSE (common failure):
Organisation responds to Subject Access Request with:
→ CRM record: provided
→ Email marketing preferences: provided
→ Purchase history: provided
Missing:
→ CSV export from 3 months ago: still in shared drive
→ Analytics report emailed to 4 team members: in 4 email inboxes
→ Backup from CRM migration: in archived folder
→ Data processor's copy: never requested from processor
This response is non-compliant. The right of access covers ALL personal data held.
COMPLIANT RESPONSE requires:
→ Inventory of where data exists before responding
→ All copies accounted for
→ Processor's copy requested and included or noted
What this means for your CSV workflow: Before you can respond to a data subject request, you need to know where every copy of that person's data lives. If you don't have that map, build it before you receive a request — not in the middle of responding to one.
Table of Contents
- What "Every System Where Data Is Held" Actually Means
- Article 15: Right of Access — Finding One Person in Large CSV Files
- Article 17: Right to Erasure — Deletion Across All CSV Copies
- Article 20: Right to Data Portability — CSV as the Required Format
- The One-Month Deadline: What the Clock Covers
- Building a Data Map Before You Need It
- Common Failures in CSV-Based Data Subject Responses
- Operator Rules: Data Subject Rights and CSV Files
- Additional Resources
- FAQ
Article 15: Right of Access — Finding One Person in Large CSV Files
The right of access (Article 15) requires you to confirm whether personal data is held and, if so, provide a copy. The format must be concise, transparent, intelligible, and easily accessible.
The practical problem: A 2 million row customer CSV takes minutes to search manually. Doing it across 20 CSV files in a shared drive, looking for a customer with a common name, takes hours — hours you may not have if the request is time-sensitive.
How to find one person's data across large CSV files:
-
Use consistent identifiers. Email address is the most reliable search key in customer data — it's typically unique. Customer ID is also reliable if it's consistent across systems.
-
Search by email or ID, not name. Names have duplicates. "John Smith" may match 40 records. [email protected] matches one.
-
Search every file separately. A global search across a folder returns filenames. You need to know what columns each file contains to compile a complete response.
-
Note each match with file name, row number, and columns containing the data. This is your working record for the response.
Practical search — SplitForge Find & Replace on a 1M row customer file:
Search term: [email protected]
Target column: email
Results:
Row 88,247: [email protected], name=Jane Customer, last_purchase=2025-11-14
Row 88,248: [email protected], name=Jane Customer, last_purchase=2025-08-03
Two rows. Two purchases. Note both for the access response.
Processing time: under 4 seconds. No upload. Customer's email never leaves the machine.
What's included in an access response: Under Article 15(1), you must confirm: whether data is held; the purposes of processing; the categories of personal data; recipients; retention periods; rights available; source of the data (if not from the subject). The EDPB Guidelines 01/2022 clarify that you must provide a copy of the personal data itself, not just a description.
What this means for your CSV workflow: Build a search procedure for access requests before you need it. A documented list of where customer CSV data lives, plus a one-line search procedure, is the minimum preparation.
Article 17: Right to Erasure — Deletion Across All CSV Copies
The right to erasure (Article 17) — often called the right to be forgotten — requires deletion of personal data when one of six grounds applies: the data is no longer necessary for its original purpose; the data subject withdraws consent; there is no overriding legitimate interest; the data must be erased to comply with a legal obligation; or objection grounds apply.
The critical point: Erasure must occur across every copy of the data, not just the live system.
A CRM deletion that leaves behind CSV exports in 4 shared drives, 2 email inboxes, and 1 backup folder is not erasure. Each remaining copy is a continued processing activity without a lawful basis.
❌ INCOMPLETE ERASURE (common failure):
Customer requests deletion.
CRM record: deleted ✓
Email marketing suppression: added ✓
Analytics platform: deleted ✓
Missed:
→ Weekly export from 6 months ago still in shared Google Drive: NOT deleted
→ Agency CSV file sent 3 months ago: agency still holds it
→ Backup file from last quarter: NOT deleted
The customer's data is still being processed in 3 locations.
GDPR Article 17 is not satisfied.
The erasure workflow:
- Search for the data subject's identifier across all CSV files (same process as access request).
- Remove the matching rows from each file.
- Save the modified files back to the same locations.
- Contact any processors (agencies, vendors) who received the data and request deletion confirmation in writing.
- Document what was deleted, from where, on what date.
When erasure can be refused:
Article 17(3) provides exceptions — where processing is necessary for legal compliance, public interest, or the establishment, exercise, or defence of legal claims. If you are legally required to retain financial records for a specific period, that's a valid reason not to delete. Document the legal basis for retention and inform the data subject.
What this means for your CSV workflow: If your team sends CSV exports to external parties, you are responsible for ensuring deletion at those parties too. "We asked them to delete it" is better than silence — written confirmation is better than asking.
Article 20: Right to Data Portability — CSV as the Required Format
The right to data portability (Article 20) requires providing personal data in a "structured, commonly used and machine-readable format." GDPR guidance — including from the EDPB and regulatory implementation guidance — explicitly identifies CSV as an appropriate format for tabular personal data.
What's portable:
- Data provided by the data subject (purchase history they generated, profile data they entered, preferences they set)
- Observed data generated through their use of the service (click history, location logs, interaction records)
- NOT derived data created by the controller (credit scores, risk classifications, inferred attributes)
What portability requests look like in CSV context:
A customer switching CRM providers requests a CSV of all their account data. A patient switching healthcare providers requests their appointment history and test results in a structured format. A user closing an account requests all their submitted profile data and transaction history.
Article 20 portability export — what to include:
customer_id, email, name, phone, address,
purchase_date, purchase_category, purchase_amount, payment_method,
account_created, preferences_set, consent_timestamp
Article 20 portability export — what NOT to include:
credit_tier (derived by your system)
churn_probability (your model's output)
fraud_risk_score (your analysis)
internal_notes (added by your team)
The right covers what the data subject provided or generated.
It does not cover what you derived from that data.
The one-month deadline applies here too. Portability requests must be fulfilled within one month of a valid request. For large accounts with complex data across multiple systems, start the compilation immediately.
What this means for your CSV workflow: Having a documented portability export template for your CRM or customer data system — a standardised set of columns that satisfies Article 20 — means portability requests can be fulfilled consistently rather than ad hoc.
The One-Month Deadline: What the Clock Covers
GDPR Article 12(3) requires responses to data subject requests without undue delay and in any event within one month of receipt of the request. The deadline can be extended by a further two months for complex or high-volume requests, provided the data subject is notified within the first month.
What the one-month clock covers:
- From: date the valid request is received
- To: substantive response (not just acknowledgement)
- Includes: all systems, all copies, all processors
What pauses the clock: Nothing in standard cases. You can request clarification of identity or scope, which pauses the clock until the data subject responds — but this must be done promptly and only where genuinely needed to identify the person.
The most common timing failure:
An access request arrives on March 1. The analyst is away March 1–7. The request sits in a shared inbox until March 10. The team starts searching for data March 11. They find 14 CSV files spread across 3 systems. It takes until March 25 to compile everything. Response is provided April 1 — one day late.
GDPR doesn't adjust the deadline for holiday, staffing gaps, or technical complexity.
What this means for your CSV workflow: The bottleneck is always finding the data, not compiling the response. Build the data map before you receive a request — not during the one-month window.
Building a Data Map Before You Need It
The single most effective preparation for data subject requests is knowing where personal data lives before someone asks.
Minimum viable data map for CSV-based data:
Data Map — Customer Personal Data
Last updated: 2026-03-18
Location 1: CRM (Salesforce)
Data: all customer records
Retention: active + 3 years post-churn
Access: sales team, customer success
Location 2: Weekly export — /shared-drive/analytics/weekly-exports/
Data: email, purchase_history, campaign_source
Retention: kept indefinitely (ACTION: add deletion policy)
Access: marketing team
Location 3: Agency email thread — sent to Agency X on 2025-11-01
Data: email, first_name, purchase_recency
Retention: Agency X ToS says 90 days
Action on deletion request: email Agency X for written confirmation
Location 4: Quarterly analytics report — /shared-drive/reports/
Data: aggregated only, no individual records
Retention: indefinitely
Action on request: no individual records present
This document — updated when new workflows are created — means any data subject request can be responded to within the deadline.
What this means for your CSV workflow: Create this map now. Update it every time you create a new CSV workflow. It is your first line of compliance for every data subject right.
Common Failures in CSV-Based Data Subject Responses
Failure 1: Searching the database but not the exports The live CRM is searched. The weekly exports archived in Google Drive are not. The response covers 60% of the data held. This is a non-compliant partial response.
Failure 2: Deleting from the CRM but not from vendor files The customer is deleted from Salesforce. The CSV sent to the email agency 4 months ago is never reviewed. The agency retains it. The erasure is incomplete.
Failure 3: Responding with a description instead of a copy "We hold your email address and purchase history for the purpose of providing our services." This is not an access response. GDPR requires a copy of the actual personal data, not a summary of what categories are held.
Failure 4: Providing inferred data under portability A portability response includes churn risk score, credit tier, and internal customer segment. These are controller-derived attributes. Article 20 doesn't cover them. Including them in a portability export to another controller creates unnecessary exposure.
Failure 5: Starting the search after acknowledgement The data subject receives an acknowledgement email on day 1. The actual search for CSV data begins on day 10. The response is ready on day 32 — two days late. The deadline is not paused by acknowledgement.
Operator Rules: Data Subject Rights and CSV Files
Short. Non-negotiable. Reference before any data subject request involves CSV data.
- Every copy is in scope — not just the live database
- Email attachments containing customer data are in scope for access and erasure
- The one-month clock runs from receipt — not from when you start the search
- Portability format is CSV or equivalent — deliver the actual data, not a summary
- Erasure at processor is your responsibility — written confirmation required
- Build the data map before you receive the request — not during
- Inferred attributes (credit score, risk tier, segment) are not portable — don't include them
Additional Resources
GDPR Primary Sources:
- GDPR Article 15 — Right of Access — Full text and scope of access right
- GDPR Article 17 — Right to Erasure — Conditions and exceptions for erasure
- GDPR Article 20 — Right to Data Portability — Portability scope, format requirements
EDPB Guidance:
- EDPB Guidelines 01/2022 on the Right of Access (Version 2.1) — Authoritative guidance on Article 15 implementation
Related SplitForge Guides:
- For finding and replacing individual records in large CSV files: Find and Replace in CSV Files
- For the complete pre-sharing privacy review: Privacy Review Before Sharing CSV
- For the full privacy framework: Privacy-First Data Processing Guide
Disclaimer: This post is for informational purposes only and does not constitute legal advice. Data subject rights obligations depend on your specific processing activities, data categories, and jurisdiction. Consult qualified legal counsel before making compliance decisions.