Quick Answer
GDPR Article 28 makes controllers directly liable when processors fail to protect personal data — even when the processor causes the breach, the controller pays. On July 21, 2025, Poland's UODO fined McDonald's Polska €4,022,773 for a breach caused by their scheduling software processor's misconfigured server. The processor also received a fine — but McDonald's paid four million euros for something their vendor did. On June 3, 2025, Germany's BfDI fined Vodafone €45 million — according to the BfDI enforcement summary: €15 million for inadequate monitoring of partner agencies (GDPR Article 28), and €30 million for authentication security failures (Article 32). In both cases: the controller was liable for the processor's actions.
Fast Fix (2 Minutes)
If you're using any cloud-based CSV processing tool with personal data and haven't reviewed vendor obligations:
- Identify which tools receive personal data from your CSV files — every tool that processes a CSV containing personal data is potentially a processor under GDPR Article 28.
- Check whether a signed DPA exists — not just a privacy policy. A signed Data Processing Agreement covering your specific use case.
- Verify security measures — does the vendor have SOC 2 Type II? An incident response procedure? A breach notification timeline documented?
- Check file retention — how long does the tool retain uploaded files? Is this documented in the ToS?
- Consider SplitForge Data Validator for validation workflows — processing locally can eliminate the processor relationship for the validation step if no personal data is transmitted or logged server-side.
CSV Vendor Due Diligence Checklist — run this before any personal data is processed by a third-party CSV tool:
| # | Check | Pass Condition | Fail = |
|---|---|---|---|
| 1 | Signed DPA available | Vendor provides a signed DPA covering your use case — not just a privacy policy | Hard stop — do not upload personal data |
| 2 | File retention period documented | Retention ≤30 days for temporary processing tools; zero retention preferred | Hard stop if undefined; escalate if >30 days |
| 3 | SOC 2 Type II or equivalent current | Certification issued within 12 months; covers the specific processing environment | Hard stop for sensitive data (CRM, health, financial) |
| 4 | Sub-processors disclosed | Full list of sub-processors available; EU data stays in EEA or covered by SCCs | Escalate — controller must assess sub-processor risk |
| 5 | Breach notification timeline | Vendor commits to notifying you within 72 hours of discovering a breach | Escalate — GDPR Art 28(3)(f) requires this in the DPA |
| 6 | Data location confirmed | EU customer data stored or processed within EEA, or SCCs in place for transfers | Requires SCCs + Transfer Impact Assessment if outside EEA |
| 7 | Incident response procedure documented | Vendor has a documented IR plan; escalation contacts available | Escalate — absence signals weak security posture |
| 8 | Audit rights available | DPA grants you the right to audit or receive audit reports | Escalate — required under Art 28(3)(h) |
| 9 | Purpose limitation confirmed | Vendor contractually prohibited from using your data for their own purposes | Hard stop — vendor data use is a common ToS trap |
| 10 | Deletion on request confirmed | Vendor will delete all copies of your data on request and confirm deletion | Escalate — required for Art 17 compliance |
Scoring: 8–10 passes → proceed with monitoring. Below 5 passes → do not upload personal data until gaps are resolved.
Most consumer-grade cloud CSV tools score 2–3 on this list.
TL;DR: "We outsourced it" is not a GDPR defence. GDPR Article 28 requires controllers to verify that processors provide sufficient guarantees, implement appropriate technical measures, and remain under controller oversight. A DPA alone is not enough — you must exercise the oversight rights it contains. McDonald's had a DPA. They still paid €4 million because they didn't verify the processor's security or conduct a risk assessment.
The central argument of this post: Liability doesn't transfer when you outsource data processing. It stays with you. Your vendor's security failure becomes your regulatory fine. Your vendor's misconfigured storage bucket becomes your breach notification obligation. Your vendor's missing retention policy becomes your Article 28 violation.
This is not a theoretical risk. It is the documented outcome of two of 2025's largest GDPR enforcement actions — and both failures started with the same gap: a controller assumed that signing a DPA was sufficient. It isn't.
The blunt version of GDPR Article 28: If your vendor leaks your customers' data, regulators fine you — not them.
McDonald's Poland contracted 24/7 Communication to manage employee scheduling — a standard outsourcing arrangement. 24/7 Communication stored employee data (names, PESEL numbers, passport numbers, shift schedules) in a scheduling module. A server misconfiguration made this data publicly accessible online. The breach was 24/7 Communication's fault.
McDonald's paid €4,022,773. 24/7 Communication paid €43,680.
The UODO's reasoning: McDonald's had a DPA in place but failed to conduct a risk assessment before entrusting sensitive data to the processor, failed to verify that adequate technical and organisational measures were in place, and failed to exercise any oversight or audit rights during the processing relationship. The controller is always accountable.
Vodafone Germany paid €45 million in June 2025 — €15 million specifically for failing to adequately review and monitor partner agencies handling customer data under Article 28(1) GDPR. The second €30 million related to authentication security failures in Vodafone's own systems under Article 32. Two separate failures: one in processor oversight, one in technical security.
Both cases establish the same principle: outsourcing processing doesn't outsource accountability.
How this maps to your CSV workflows:
REAL VENDOR FAILURE → CSV EQUIVALENT
Vendor failure:
Misconfigured storage bucket → file becomes publicly accessible
CSV equivalent:
→ Upload customer.csv to SaaS CSV tool
→ Tool stores file in misconfigured cloud storage
→ File indexed or accessible by unauthorized parties
Result:
→ Your customer data is publicly exposed
→ You are fined as controller — the vendor's misconfiguration is your liability
→ McDonald's paid €4M for exactly this pattern
Prevention:
→ Verify file storage configuration before first upload
→ Confirm SOC 2 or equivalent covers the specific storage path
→ Or: process locally — no upload means no misconfigurata
Each obligation in this post was assessed against GDPR Articles 24, 25, 28, and 32; EDPB guidance on controller-processor relationships; and the UODO and BfDI decisions referenced above, March 2026.
Table of Contents
- What GDPR Article 28 Actually Requires
- The McDonald's Poland Failure Pattern
- The Vodafone Germany Failure Pattern
- Due Diligence Before Any CSV Reaches a Vendor
- Ongoing Oversight: What "Monitoring" Requires
- The Sub-Processor Problem
- Reducing Vendor Exposure Through Local Processing
- Operator Rules: Vendor Risk and CSV Tools
- Additional Resources
- FAQ
What GDPR Article 28 Actually Requires
GDPR Article 28 is not satisfied by signing a DPA. It requires:
Before engagement:
- The controller must use only processors providing "sufficient guarantees" to implement appropriate technical and organisational measures — and be able to demonstrate this assessment was conducted.
In the DPA: The DPA must contain all mandatory clauses from Article 28(3): processing only on documented controller instructions; confidentiality obligations on authorised personnel; security measures under Article 32; sub-processor restrictions; data subject rights assistance; deletion or return of data after processing; provision of information for audits.
During processing:
- Exercise audit rights — not just the right to audit, but actual periodic verification
- Monitor sub-processor use
- Receive and review security incident notifications
- Verify that processing stays within the contracted scope
The McDonald's lesson: Having a DPA on file satisfies the contract requirement. Not exercising the oversight rights in that DPA — no risk assessment, no security verification, no audit — creates the Article 28 violation.
What Article 28 compliance looks like in practice:
PRE-ENGAGEMENT:
□ Security questionnaire completed by vendor
□ Evidence of security certifications reviewed (SOC 2, ISO 27001)
□ Data retention policy reviewed and confirmed acceptable
□ Sub-processor list reviewed and accepted
□ DPA signed covering the specific processing activity
DURING PROCESSING:
□ Annual security review of vendor (or upon material change)
□ Breach notification procedure confirmed and tested
□ Sub-processor changes notified by vendor
□ Audit rights exercised at least annually for high-risk processing
WHAT MCDONALD'S DID:
□ DPA signed ✓
□ Pre-engagement security assessment: NOT DONE
□ Risk analysis: NOT DONE
□ Ongoing monitoring: NOT DONE
□ Audit of processor's systems: NOT DONE
Result: €4,022,773 fine. The DPA was necessary but not sufficient.
The McDonald's Poland Failure Pattern
The UODO's July 21, 2025 decision identified five specific failures by McDonald's:
Failure 1: No risk assessment before engaging the processor GDPR Articles 24 and 25 require controllers to assess risks and implement appropriate measures at the design stage. McDonald's contracted 24/7 Communication without conducting a risk assessment of the scheduling module or the data it would hold.
Failure 2: No verification of processor's security capabilities Article 28(1) requires controllers to use only processors providing "sufficient guarantees." McDonald's relied on a prior business relationship rather than verifying that 24/7 Communication had the technical and organisational measures required to protect employee data.
Failure 3: Data minimization violation The scheduling module stored PESEL numbers and passport numbers as employee identifiers — more than was necessary for scheduling purposes. The UODO cited this as a breach of Article 5(1)(c) data minimization. After the breach, these identifiers were replaced with unique employee numbers. This fix should have been the design from the start.
Failure 4: No audit or oversight mechanism The DPA did not contain provisions for supervision, audit, or inspection of the processor's systems. Controllers must be able to exercise meaningful oversight — a DPA that contains no audit rights is deficient.
Failure 5: Inadequate breach notification to affected individuals McDonald's notified affected current employees directly but informed former employees only via press releases. GDPR requires direct notification when a breach poses high risk to individuals' rights and freedoms.
The CSV-specific lesson:
Employee data in McDonald's scheduling system:
name, PESEL, passport_number, restaurant_number,
shift_start, shift_end, hours_worked, job_role,
holiday_type, work_type
This is effectively a CSV of sensitive employee data
handed to a third party with:
- No security verification
- No risk assessment
- No audit clause
- Over-broad data (PESEL + passport = unnecessary for scheduling)
The misconfiguration exposed this data publicly.
McDonald's paid for it.
The Vodafone Germany Failure Pattern
The BfDI's June 3, 2025 decision against Vodafone established a different but related liability pattern.
Fine 1 — €15 million (Article 28(1) GDPR): Vodafone used partner agencies — third-party distributors — to sell contracts on its behalf. These agencies had access to customer data and the ability to make changes to customer accounts. The BfDI found that Vodafone had not adequately reviewed and monitored these partner agencies. Some agents created fictitious contracts and made unauthorized changes to customer agreements. Vodafone, as the entity whose data was being processed, was held liable.
Fine 2 — €30 million (Article 32(1) GDPR): Separate from the agency failures: Vodafone's own MeinVodafone online portal had authentication weaknesses that, when combined with Vodafone's customer hotline, allowed unauthorized third parties to access eSIM profiles.
The pattern for data teams using CSV tools: if a partner, agency, or tool handles your customers' data, you are responsible for ensuring that handling meets GDPR standards. Your logo on the data doesn't follow the data — but your liability does.
What this means for your CSV workflow: Third-party tools that receive your CSV files are processors. You are the controller. Their security failures are your liability if you didn't conduct adequate due diligence and maintain adequate oversight.
Due Diligence Before Any CSV Reaches a Vendor
The minimum acceptable pre-engagement review for any tool receiving personal data from CSV files:
| Criterion | What to Check | Where to Find It |
|---|---|---|
| Security certification | SOC 2 Type II report (preferred) or ISO 27001 | Request directly from vendor |
| DPA availability | Signed DPA covering your processing activity | Vendor's legal or privacy page |
| Sub-processor list | Which third parties does the vendor use? | DPA appendix or privacy policy |
| File retention period | How long are uploaded files retained? | ToS or DPA |
| Breach notification timeline | When will they notify you of an incident? | DPA (GDPR requires without undue delay, max 72 hours to supervisory authority) |
| Data location | Where are files processed? EU or non-EEA? | Privacy policy or DPA |
| BAA availability | Required if tool processes PHI | Request directly from vendor |
DO NOT USE THE TOOL for personal data if any of the following apply — these are hard stops, not guidelines:
- No DPA available or vendor refuses to sign one
- File retention period undefined or exceeds 30 days for temporary processing
- No SOC 2 Type II or equivalent security certification
- Sub-processor list not disclosed
- Breach notification procedure not documented in the DPA
- No clear answer on data location for EU customers
Most consumer-grade cloud CSV tools don't have signed DPAs by default. They may have a GDPR-compliant privacy policy — but this is not the same as a DPA. The privacy policy governs the vendor's use of your data. The DPA governs the vendor's processing of your customers' data on your behalf. Both are required. Most vendors only have one.
Vendor Risk Scoring: Quick Triage
Use this before any procurement decision. Bookmark this — it's the framework compliance officers use to tier CSV tool vendors before the first upload.
| Risk Level | Example Tool Type | Minimum Required Actions |
|---|---|---|
| Low | Local validator / browser-only tool (no upload) | None — no processor relationship arises |
| Medium | SaaS CSV cleaner, formatter, deduplication tool | Signed DPA + annual security review |
| High | CRM, data warehouse, analytics platform | Full audit + DPIA if sensitive data + SCCs for EU data |
| Critical | AI/ML training platform, data broker receiving raw PII | Full audit + DPIA + BAA if PHI + SCCs + TIA |
Processor Due Diligence Checklist (print or paste into your vendor onboarding)
| Check | Question | Pass Condition |
|---|---|---|
| 1 | Is a signed DPA available and does it cover this use case? | Yes — DPA signed and scoped to your processing activity |
| 2 | Is file retention period documented and acceptable (<30 days for temporary processing)? | Yes — retention period specified in ToS or DPA |
| 3 | Does the vendor hold a current SOC 2 Type II or ISO 27001 certification? | Yes — report available on request |
| 4 | Is the full sub-processor list disclosed? | Yes — sub-processors named, with notification process for changes |
| 5 | Does the DPA include a breach notification timeline? | Yes — without undue delay; max 72 hours to notify you |
| 6 | Is data location confirmed (EU-hosted instance or DPF-certified US)? | Yes — confirmed in writing |
| 7 | Is a BAA available if the tool will receive PHI? | Yes — or tool is confirmed to not receive PHI |
| 8 | Does the DPA include audit rights? | Yes — right to request security documentation or conduct audit |
| 9 | Has a risk assessment been conducted for this processing activity? | Yes — documented before first upload |
| 10 | Is there a sub-processor approval process requiring controller consent? | Yes — vendor must notify you before adding new sub-processors |
Score: 8–10 = Proceed with monitoring. 5–7 = Resolve gaps before upload. Below 5 = Do not upload personal data.
Ongoing Oversight: What "Monitoring" Requires
The McDonald's case makes clear that signing a DPA is not ongoing oversight. Article 28 requires the controller to verify that the processor continues to provide sufficient guarantees throughout the processing relationship.
Minimum ongoing oversight activities:
Annual security review: For any processor handling personal data, review security status annually. This means: requesting updated SOC 2 report, reviewing any security incident disclosures, checking for changes to sub-processor list, and confirming the DPA remains current.
Audit rights: Article 28(3)(h) requires DPAs to give controllers the right to conduct audits. For cloud CSV tools, this typically means: the right to review security documentation, request penetration test results, and receive information about security incidents. Larger vendors provide this through Shared Responsibility frameworks. Smaller vendors may need direct requests.
Sub-processor change notification: Article 28(2) requires processors to inform controllers of any intended changes to sub-processors and give the controller the opportunity to object. A DPA that doesn't contain this clause is deficient. A processor that changes sub-processors without notification is violating Article 28.
What this means for your CSV workflow: Set a calendar reminder for every vendor processing personal data — annual review minimum. The review takes 30 minutes. The McDonald's fine was four million euros.
The Sub-Processor Problem
In the McDonald's case, 24/7 Communication used a sub-processor — an additional third party — without notifying McDonald's or obtaining consent. This is an Article 28(4) violation. The sub-processor's involvement created additional exposure that McDonald's had no visibility into.
For CSV tools, sub-processing is extremely common. A CSV validation tool may use cloud infrastructure (AWS, Azure, GCP) as a sub-processor. A CSV analytics tool may use a third-party analytics engine. Each sub-processor is a node in the processing chain — and as controller, you are responsible for the entire chain.
What to check:
- Does the DPA list approved sub-processors?
- Does the DPA require the vendor to notify you before adding new sub-processors?
- Are any sub-processors in non-EEA countries? If yes, what transfer mechanism covers that sub-processing?
Reducing Vendor Exposure Through Local Processing
Every vendor that receives a CSV containing personal data is a potential processor liability. The fewer vendors who receive personal data, the lower the exposure.
For CSV validation, cleaning, deduplication, and analysis workflows, local browser-based processing can eliminate the vendor relationship for those specific activities — provided no personal data is transmitted to or logged by any server during processing. A CSV validated locally with no server transmission has no processor relationship for that step. There is no DPA to sign, no security review to conduct, no audit to exercise, no breach notification to wait for.
Many cloud-based CSV tools — even well-intentioned ones — create processor relationships that require DPAs, security reviews, and ongoing monitoring for every workflow. SplitForge processes CSV files in Web Worker threads in your browser. For raw file contents, if nothing is transmitted server-side, the processor relationship for that processing step does not arise — and the compliance obligations that come with it. This assumes no telemetry, logging, or indirect transmission of personal data occurs during processing — verify in your browser's network tab if certainty is required.
For the vendor evaluation checklist before selecting any CSV processing tool, see our CSV tool security checklist. For the legal agreements required when a vendor relationship does exist, see our DPA, BAA, and SCCs guide.
Operator Rules: Vendor Risk and CSV Tools
Short. Non-negotiable. Reference before any personal data reaches a vendor's systems.
- "We outsourced it" is not a GDPR defence — controllers pay for processor failures
- A DPA on file is necessary but not sufficient — you must also exercise the oversight rights it contains
- Conduct a risk assessment before engaging any processor with sensitive data — McDonald's didn't, and paid €4M
- Sub-processors need your approval — an unauthorized sub-processor is an Article 28 violation
- Annual security review for every vendor handling personal data — not just at onboarding
- Consumer-grade cloud CSV tools rarely have DPAs by default — request one before the first upload
- The fewer vendors who touch personal data, the lower the controller liability exposure
Additional Resources
GDPR Primary Sources:
- GDPR Article 28 — Processor — Full DPA requirements and controller obligations
- GDPR Article 32 — Security of Processing — Technical and organisational security measures
Enforcement Decisions:
- EDPB: UODO McDonald's Poland Decision — July 2025 — Primary source: €4,022,773 fine for processor oversight failure
- BfDI: Vodafone Germany Decision — June 2025 — Primary source: €45M fine for Art 28 + Art 32 violations
Related SplitForge Guides:
- For the vendor evaluation checklist: CSV Tool Security Checklist
- For the complete privacy checklist before any sharing: Privacy Review Before Sharing CSV
Disclaimer: This post is for informational purposes only and does not constitute legal advice. Processor liability and due diligence obligations depend on your specific processing activities and relationships. Consult qualified legal counsel before making compliance decisions.