Quick Answer
Before sharing or uploading any CSV containing personal data, 10 privacy checks take 5 minutes and prevent regulatory exposure under GDPR, HIPAA, CCPA, and equivalent laws. The most commonly skipped checks are: removing unnecessary PII before transfer (most exports contain far more than the recipient needs), verifying whether a signed Data Processing Agreement exists with the tool or recipient, and confirming deletion at the destination after processing is complete. Most teams skip all three.
TL;DR: This checklist exists because privacy failures in CSV workflows aren't usually malicious — they're rushed. Someone exports a full CRM record when only email was needed. Someone uploads a patient file to a cloud tool without checking whether a BAA exists. This checklist is for pasting into team SOPs, pinning to Slack, and running before any significant data handoff.
Table of Contents
- The 10-Item Privacy Checklist
- Check 1: Does This File Contain Personal Data?
- Check 2: Lawful Basis for Processing
- Check 3: Does the Recipient Need a Data Processing Agreement?
- Check 4: BAA for PHI
- Check 5: Transfer Mechanism for Non-EEA Recipients
- Check 6: Remove Unnecessary PII Before Transfer
- Check 7: Special Category Data
- Check 8: Deduplicate Before Transfer
- Check 9: Confirm Deletion at Destination
- Check 10: Record of Processing Activities
- Common Mistakes That Cause Privacy Failures in CSV Workflows
- Operator Rules: CSV Privacy Handoffs
- Additional Resources
- FAQ
Every CSV shared externally, uploaded to a tool, or sent between teams is a potential regulatory event. Not because the data is inherently dangerous — because personal data is regulated, and most CSV workflows aren't built with that in mind.
McDonald's Poland was fined €3.9 million under GDPR after a processor's misconfigured server leaked employee CSV data. The controller was liable — not just the processor. Vodafone Germany was fined €45 million after vendor security failures caused data exposure. In both cases, the failure began with data moving to a third party without adequate review.
This checklist is the review most teams don't run. Each check was validated against GDPR Articles 5, 25, and 28; HIPAA 45 CFR §§164.502(e) and 164.504(e); and CCPA 11 CCR § 7150, March 2026.
The 10-Item Privacy Checklist
Print this. Paste it into your team wiki. Run it before every significant CSV handoff.
| # | Check | Framework | Pass Condition |
|---|---|---|---|
| 1 | Does this file contain personal data? | All | Confirmed — proceed. Unsure — treat as yes. |
| 2 | Is there a lawful basis for processing? | GDPR | Consent, contract, legitimate interest, legal obligation, vital interest, or public task documented. |
| 3 | Is the recipient a data processor requiring a DPA? | GDPR Art. 28 | Signed DPA on file, or recipient is not a processor. |
| 4 | If the file contains PHI — is there a signed BAA? | HIPAA | Signed BAA on file, or file contains no PHI. |
| 5 | If transferring outside EEA — is there a transfer mechanism? | GDPR Ch. V | SCCs, DPF certification, or adequacy decision confirmed. |
| 6 | Have unnecessary PII fields been removed? | All | File contains only fields required by the downstream workflow. |
| 7 | Does the file contain special category data? | GDPR Art. 9 | If yes: explicit consent or Art. 9(2) exception documented. |
| 8 | Have duplicates been removed to minimize scope? | All | No duplicate rows; each individual appears once only. |
| 9 | Is deletion from the destination confirmed after processing? | All | Retention period agreed. Deletion confirmation process defined. |
| 10 | Is this transfer documented in your Record of Processing Activities? | GDPR Art. 30 | RoPA entry exists or will be created before transfer. |
Check 1: Does This File Contain Personal Data?
Personal data is any information that identifies or could identify a living individual. This includes: names, email addresses, phone numbers, IP addresses, customer IDs (if mappable to individuals), location data, purchase history, employment records, health information, and device identifiers.
If you're unsure, treat the file as containing personal data and proceed through the checklist. The cost of unnecessary caution is low. The cost of assuming incorrectly is not.
❌ COMMON MISTAKE — assuming non-obvious fields aren't personal data:
order_id,product_sku,region,device_type,session_duration_sec,conversion_flag
ORD_88823,SKU-4471,London,Mobile,142,1
This looks like anonymous analytics data.
But: order_id maps to a customer account. Region + device + session duration
can fingerprint an individual. Combined with other data: personal data.
CORRECT APPROACH:
If any field maps to or could identify an individual via reasonable means:
treat the file as containing personal data.
What this means for your CSV workflow: When in doubt, run the remaining 9 checks. The workflow cost is 5 minutes. The regulatory cost of getting this wrong can be measured in fines, breach notifications, and audit responses.
Check 2: Lawful Basis for Processing
Under GDPR Article 6, every processing activity requires a lawful basis. For most CSV workflows, the relevant bases are:
- Contract — processing is necessary to perform a contract with the individual (customer order data for fulfillment).
- Legitimate interest — processing serves a legitimate interest and isn't overridden by individual rights (sending marketing to existing customers in some jurisdictions).
- Legal obligation — processing is required by law (payroll records for tax compliance).
- Consent — freely given, specific, informed, and unambiguous consent (explicit opt-in marketing).
If you can't identify the lawful basis for sharing this specific file with this specific recipient for this specific purpose, stop. The sharing doesn't have a legal foundation.
What this means for your CSV workflow: "We've always done it this way" is not a lawful basis. Before any new CSV workflow is established — new recipient, new purpose, new data category — confirm the basis in writing. One sentence in a Slack thread is better than nothing.
Check 3: Does the Recipient Need a Data Processing Agreement?
Under GDPR Article 28, any third party that processes personal data on your behalf is a data processor and requires a signed Data Processing Agreement (DPA) before receiving the data.
Who is a processor? A tool or service that processes personal data for you, following your instructions, without independent control over the data. Cloud CSV tools, analytics platforms, email service providers, and HR software are typically processors.
Who is not a processor? A third party who receives data and uses it for their own purposes (a data recipient, not a processor). Advertising platforms that receive data and use it for targeting are typically joint controllers or independent controllers — different obligations apply.
Check your agreement with each recipient before sharing. If no DPA exists with a processor, establish one before the transfer.
For a decision tree on when a DPA applies, see our GDPR Article 28 and CSV tools guide.
What this means for your CSV workflow: Check your tool's privacy page or DPA before the first upload. Most established tools have a DPA template — it takes 10 minutes to locate and sign. Not having one signed when a regulator asks is the more expensive problem.
Check 4: BAA for PHI
Under HIPAA (45 CFR §§164.502(e) and 164.504(e)), any vendor whose servers receive Protected Health Information (PHI) is generally considered a Business Associate — even if the vendor cannot access or read the data. A signed Business Associate Agreement (BAA) is required before the transfer.
PHI in CSV context includes: patient names linked to health conditions, diagnoses, treatment dates, insurance IDs, appointment records, test results, or any individually identifiable health information.
Most consumer cloud CSV tools do not offer BAAs. Do not upload PHI to any tool without confirming a signed BAA is in place. For healthcare CSV workflows, see our healthcare CSV HIPAA compliance guide.
What this means for your CSV workflow: If your CSV contains any health-related fields — even something that looks administrative like appointment dates or insurance IDs — treat it as PHI and confirm a BAA exists before uploading to any cloud tool. If the tool doesn't offer a BAA, process locally.
Check 5: Transfer Mechanism for Non-EEA Recipients
If the recipient is outside the European Economic Area (EEA) — including US-based cloud tools — GDPR Chapter V requires a legal transfer mechanism before any EU personal data is shared.
Valid mechanisms:
- Adequacy decision — destination country has been granted adequacy by European Commission (check: commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/adequacy-decisions_en)
- Standard Contractual Clauses (SCCs) — pre-approved contract clauses between you (exporter) and the recipient (importer). Must be accompanied by a Transfer Impact Assessment.
- EU-US Data Privacy Framework — if the US recipient is DPF-certified (verify at dataprivacyframework.gov)
TikTok's €530 million fine (30 April 2025) confirmed that SCCs alone are insufficient without a documented Transfer Impact Assessment verifying their effectiveness. If sharing EU personal data with any non-EEA recipient, verify the mechanism is in place and documented before transfer.
For the full cross-border transfer decision tree and TIA requirements, see our cross-border CSV data transfer guide.
Check 6: Remove Unnecessary PII Before Transfer
This is the check most teams skip. Most CSV exports contain significantly more personal information than the recipient needs.
Run this before every external transfer:
- List every column in the file.
- For each column: does the recipient need this field to perform the requested task?
- Remove every column that answers "no" or "I'm not sure."
❌ OVER-SHARED (typical CRM export for a deduplication task):
first_name,last_name,email,phone,dob,address,city,state,zip,
account_value,credit_score,health_status,login_history,device_id
The deduplication task only needs: email
Everything else is unnecessary exposure.
MINIMIZED (what the task actually requires):
email
Send this. Nothing else.
Data minimization is not just good practice — it's a GDPR Article 5(1)(c) requirement: "adequate, relevant and limited to what is necessary." Processing more data than necessary creates audit findings, expands breach exposure, and widens risk assessment scope under CCPA 2026.
What this means for your CSV workflow: Before any external transfer, open the file and delete every column the recipient doesn't need for the specific task. This takes 2 minutes and can move a workflow from "assessment required" to "likely not required" under both GDPR and CCPA 2026 risk assessment triggers.
Check 7: Special Category Data
GDPR Article 9 applies heightened restrictions to special categories of personal data:
- Racial or ethnic origin
- Political opinions
- Religious or philosophical beliefs
- Trade union membership
- Genetic data
- Biometric data used for unique identification
- Health data
- Sex life or sexual orientation
Processing special category data requires explicit consent under Article 9(2)(a), or one of eight narrow exceptions (employment law obligations, vital interests, legitimate activities of associations, etc.).
If your CSV contains any of these fields, confirm that an Article 9 exception applies and is documented before proceeding with any sharing or upload.
What this means for your CSV workflow: Health data and biometric data are the two most commonly missed. An HR export containing sick leave dates or disability accommodations is special category data. A customer record with a body measurement field from a fitness app is biometric data. Check before assuming it's routine personal data.
Check 8: Deduplicate Before Transfer
Duplicate records expand regulatory exposure without adding value. A file with 50,000 records including 8,000 duplicates is processing the personal information of 8,000 individuals twice — unnecessary processing without purpose.
Deduplication before transfer:
- Reduces the volume of personal data in transit
- Reduces the scope of any privacy risk assessment
- Reduces breach exposure (8,000 fewer records in an incident)
- Aligns with GDPR data minimization requirements
Use SplitForge Remove Duplicates to deduplicate on email or unique identifier before any external sharing.
What this means for your CSV workflow: Deduplicate as the last step before transfer — after minimizing fields, after cleaning, after validation. A clean, deduplicated, minimized file is the correct starting point for any data handoff.
Check 9: Confirm Deletion at Destination
Most teams define the transfer carefully and forget the deletion entirely.
Before sharing, agree explicitly:
- Retention period — how long will the recipient retain the file?
- Deletion method — how will deletion be confirmed?
- Return or destruction — is the original file returned or destroyed after processing?
Under GDPR Article 5(1)(e), personal data must not be retained longer than necessary. If a processor retains your CSV for 90 days after the task is complete, those 90 days create unnecessary exposure. Many SaaS tools retain uploaded files temporarily for debugging, caching, or processing purposes — retention policies vary by vendor. Check the tool's terms of service before uploading.
What this means for your CSV workflow: Add a deletion confirmation step to every recurring data workflow. "Please confirm deletion of the file once processing is complete" in a follow-up email creates a paper trail. Not having one is a gap regulators notice.
Check 10: Record of Processing Activities
Under GDPR Article 30, organizations must maintain a Record of Processing Activities (RoPA) documenting: the purposes of processing, categories of data subjects and personal data, recipients, and retention periods.
Every significant CSV data transfer should be reflected in your RoPA. This is the document regulators request when investigating a breach or complaint. Organizations that maintain accurate RoPAs demonstrate accountability and reduce enforcement risk.
If your organization doesn't have a RoPA, sharing a CSV is an opportunity to start one — document the transfer, the recipient, the data categories, and the retention period.
What this means for your CSV workflow: Keep a running log — even a simple spreadsheet — of every CSV sent externally: date, file description, recipient, data categories, retention period agreed, deletion confirmed. If you're ever investigated, this document is what separates "we have controls" from "we don't know what we sent where."
Common Mistakes That Cause Privacy Failures in CSV Workflows
Most privacy failures in CSV workflows aren't caused by bad intent. They're caused by these specific patterns:
Mistake 1: Exporting full records when only one field was needed The deduplication task needed email. The export included name, DOB, address, credit score, and health status. Fourteen unnecessary fields in transit. This is the most common failure pattern and the easiest to fix.
Mistake 2: Assuming the tool's privacy page covers you Reading a tool's privacy policy is not the same as having a signed DPA in place. Many tools have excellent privacy practices and no signed DPA available. The DPA is the contractual commitment that GDPR Article 28 requires — the privacy page is marketing.
Mistake 3: Not checking server region A tool marketed as "EU-compliant" may process data on US servers unless you actively configure an EU region. Default configurations often use US infrastructure. Verify the instance region, not the vendor's country of incorporation.
Mistake 4: Treating recurring workflows as one-time events A weekly CRM export that's been running for two years was set up before GDPR, CCPA 2026, or the TikTok ruling changed the landscape. Recurring workflows need periodic review — the risk profile of a 2022 workflow may be different in 2026.
Mistake 5: Skipping deletion confirmation The transfer is documented. The DPA is signed. The SCCs are in place. Then the file sits on the vendor's server for 180 days because nobody confirmed the deletion timeline. Retention is part of the transfer obligation, not an afterthought.
The Processing Privacy Risk
Many CSV processing tools upload your file to remote servers to perform validation, cleaning, deduplication, or analysis. For files containing personal data, each upload creates an additional regulatory event: a processing activity requiring a lawful basis, a potential cross-border transfer requiring a mechanism, and a retention period requiring management.
The rule that cuts through the complexity: Most CSV tools increase your compliance burden the moment you upload. The checklist above applies to every upload — including to processing tools, not just to final recipients.
Processing files locally eliminates the upload step. SplitForge validates, cleans, deduplicates, and masks CSV files in Web Worker threads in your browser. For raw file contents, if nothing is transmitted server-side, checks 3 (DPA), 5 (transfer mechanism), and 9 (destination deletion) don't apply to the processing step itself. The checklist still applies to any downstream sharing — but the tool use step doesn't add regulatory exposure.
For a complete overview of privacy regulations and how client-side processing addresses each one, see our privacy-first data processing guide. For the specific vendor evaluation checklist before selecting a CSV tool, see our CSV tool security checklist.
Operator Rules: CSV Privacy Handoffs
Short. Non-negotiable. Reference these before every data handoff.
- Send only what the recipient needs for the specific task — nothing else
- "We removed the names" is not anonymization — it's pseudonymization, and GDPR still applies
- No DPA with a processor = no legal basis for the transfer — check before sending, not after
- No BAA with a PHI recipient = HIPAA violation — even if they can't read the data
- Recurring workflows decay — a compliant 2022 setup may not be compliant in 2026, review quarterly
- If you upload before minimizing, you've already transferred more data than you needed to
- Deletion at destination is part of the transfer — confirm it in writing
Additional Resources
GDPR Primary Sources:
- GDPR Article 5 — Principles of Processing — Data minimization, purpose limitation, storage limitation
- GDPR Article 28 — Processor Requirements — DPA obligations
- GDPR Article 30 — Records of Processing Activities — RoPA requirements
HIPAA:
- HHS: Business Associate Contracts — BAA requirements and sample provisions
- 45 CFR §164.502(e) — Disclosures to business associates
Transfer Mechanisms:
- EU-US Data Privacy Framework — Verify US organization certification
- GDPR Chapter V — International Transfers — Full transfer framework
Disclaimer: This post is for informational purposes only and does not constitute legal advice. Privacy obligations depend on your specific data types, processing activities, and jurisdiction. Consult qualified legal counsel before making compliance decisions.