DPA, BAA, and SCCs: Which Vendor Agreements Matter for CSV Processing

Quick Answer

Three legal agreements govern most sensitive data processing with external vendors: DPA (GDPR), BAA (HIPAA), and SCCs (GDPR international transfers). Which ones you need depends on two variables: what type of data you are processing, and where the vendor's servers are located. The decision matrix below maps every combination. A client-side tool that never receives file uploads does not trigger the DPA or BAA requirement for the processing step — the agreements are only needed when personal data actually crosses the boundary to a vendor's system.

---

TL;DR: GDPR personal data + server-side tool = DPA required. PHI + server-side tool = BAA required. EU personal data + non-EEA server = SCCs (or other Chapter V mechanism) required. All three may apply simultaneously. Client-side processing avoids triggering them for the processing step itself.

---

Three months ago your team started using a CSV cleaning tool for customer data exports. Last week your DPO asked: "Do we have a DPA with that vendor?" You checked. The vendor's website mentions GDPR compliance but has no DPA template. Their terms of service do not define retention. Their privacy policy says they may use uploaded data to improve their services.

This is not an unusual situation. It is the default situation for most SaaS tools. The agreements exist to protect you — the controller. The vendor's default terms protect the vendor. Getting the right agreements in place before uploading personal data is the controller's responsibility, not the vendor's.

This guide was prepared by reviewing GDPR Article 28, HIPAA 45 CFR §§164.502(e)/164.504(e), and GDPR Chapter V transfer provisions. All regulatory references are to current text as of March 2026. This is not legal advice — consult qualified legal counsel for your specific circumstances.

---

Table of Contents

• Agreement Decision Matrix
• The DPA: GDPR Article 28
• The BAA: HIPAA §§164.502(e)/164.504(e)
• SCCs: GDPR Chapter V
• When Client-Side Processing Changes the Picture
• What to Do When a Vendor Won't Sign
• Additional Resources
• FAQ

---

This guide is for: DPOs, compliance officers, and data leads who need to determine which vendor agreements are legally required before using a CSV processing tool with sensitive data.

---

Agreement Decision Matrix

Quick-reference summary — scan this first:

🔵 DPA = GDPR Article 28 Data Processing Agreement required
🔴 BAA = HIPAA Business Associate Agreement required (45 CFR §§164.502(e)/164.504(e))
🟠 SCCs = Standard Contractual Clauses required for non-EEA transfer (GDPR Chapter V)
None = no agreement triggered for the file processing step itself

How to read this table: Find your data type in the rows. Find your vendor's server location in the columns. Every symbol shown is a required agreement that must be signed before uploading. Client-side processing avoids triggering these requirements for the file processing step — the vendor never receives the file contents.

Use this matrix in the full detail below for the underlying legal basis for each requirement.

The DPA: GDPR Article 28

What it is: A Data Processing Agreement is a contract between a data controller (you) and a data processor (a vendor that handles personal data on your behalf). GDPR Article 28 makes this agreement mandatory for every controller-processor relationship involving personal data subject to GDPR.

When it is required: Whenever you upload personal data from EEA residents to any server-side tool. "Personal data" under GDPR Article 4(1) includes names, email addresses, IP addresses, location data, identifiers — essentially any information that can identify a living individual. The threshold is low.

What it must contain (Article 28(3) minimum):

• Subject matter and duration of processing
• Nature and purpose of the processing
• Type of personal data and categories of data subjects
• Obligations and rights of the controller
• Sub-processor restrictions (the vendor cannot engage sub-processors without your authorization)
• Data subject request cooperation obligations
• Security measures and audit rights

What a DPA does not do: It does not make processing lawful — you still need a valid Article 6 legal basis. It does not replace the need for SCCs if the vendor processes data outside the EEA. It does not satisfy HIPAA — the DPA and BAA are parallel, separate requirements.

Practical step: Ask the vendor for their standard DPA template before uploading any personal data. Many smaller tools and consumer-oriented SaaS products do not provide DPA templates — compliance-ready enterprise vendors will have one available without a sales conversation.

The BAA: HIPAA §§164.502(e)/164.504(e)

What it is: A Business Associate Agreement is required under HIPAA when a covered entity (hospital, health insurer, healthcare provider, health plan) uses a vendor that will create, receive, maintain, or transmit Protected Health Information on the covered entity's behalf. The obligation is in 45 CFR §§164.502(e) and 164.504(e).

When it is required: When PHI passes through a vendor's system. PHI includes patient names, dates of service, diagnosis codes, treatment information, health plan beneficiary numbers, and 16 other categories defined by the HIPAA Privacy Rule. It does not matter whether the tool is marketed as a healthcare tool — if PHI flows through it, a BAA is required.

What it must contain (minimum): Permitted uses of PHI, safeguarding obligations, reporting obligations for breaches, PHI return or destruction upon termination, access rights for HIPAA compliance audits.

Key distinction: The BAA is with the vendor — not your DPO or compliance officer. It must be signed before PHI is transmitted. Operating without one when PHI is involved is a direct HIPAA violation. OCR enforcement actions have been brought against covered entities that failed to obtain BAAs with vendors who subsequently experienced breaches affecting PHI.

Common mistake: Assuming that because a vendor is ISO 27001 certified or SOC 2 compliant, a BAA is not needed. Those certifications address security controls, not HIPAA-specific contractual obligations.

SCCs: GDPR Chapter V

What they are: Standard Contractual Clauses are pre-approved contractual safeguards for transferring personal data from the EEA to third countries. They are authorized under GDPR Article 46(2)(c). The EU Commission published updated SCCs in June 2021. These are the current operative version.

When they are required: When personal data from EEA residents is transferred to a country without an EU adequacy decision AND the vendor is not certified under an adequacy framework like the EU-US Data Privacy Framework.

Countries with current adequacy decisions (as of March 2026): UK (adequacy), Switzerland, Japan, Canada (commercial entities), South Korea, Israel, New Zealand, Uruguay, Argentina, and several others — check the European Commission's current adequacy list as this changes. EEA member states and European Economic Area members (Iceland, Liechtenstein, Norway) do not require transfer mechanisms.

The EU-US Data Privacy Framework: Following the invalidation of Privacy Shield (Schrems II, 2020), the EU-US Data Privacy Framework was adopted in July 2023 as an adequacy mechanism for US organizations that self-certify. A US vendor certified under DPF can receive EU personal data without SCCs. Check certification status at https://www.dataprivacyframework.gov.

What happens without a mechanism: The Meta €1.2 billion GDPR fine in May 2023 was for exactly this failure — transferring EU personal data to US servers without a valid Chapter V mechanism during the period when Privacy Shield was invalidated and SCCs had not been properly implemented.

How SCCs work in practice: SCCs are typically incorporated into the DPA as an annex or addendum. The vendor's standard DPA should address this. If the vendor has a US-only operation and no DPA at all, they are almost certainly also missing the required transfer mechanism.

When Client-Side Processing Changes the Picture

A client-side CSV tool — one where the file is processed entirely in the user's browser using the File API and Web Workers — does not receive file data on any server. No upload occurs. From a data flow perspective, no personal data crosses the boundary to the vendor's infrastructure during file processing.

This has direct legal implications:

DPA: The DPA obligation under GDPR Article 28 applies when a processor "processes personal data on behalf of a controller." If no personal data is processed on the vendor's servers (because processing is entirely client-side), the Article 28 processor relationship is not triggered for the file processing operation itself. You may still have a relationship with the vendor (account data, usage analytics) that requires separate consideration, but the file processing step does not trigger it.

BAA: The HIPAA BAA obligation applies when a business associate "creates, receives, maintains, or transmits" PHI. If PHI never reaches the vendor's servers, the vendor does not receive or maintain it. The BAA obligation for the processing step is not triggered.

SCCs: International transfer rules apply when personal data is transferred to a third country. If no personal data is transferred — because processing is client-side — GDPR Chapter V is not engaged for the processing step.

What remains: Even with a client-side tool, you should confirm that the tool's analytics/telemetry does not collect file contents (see Criterion 5 in our CSV tool security checklist), and you should assess whether account registration or authentication involves any data flow that requires assessment.

Sample DPA Clause Language

Legal readers evaluate DPAs against known standards. The following represents minimum-acceptable clause language for a controller-processor DPA under GDPR Article 28(3). Use it to assess whether a vendor's DPA template is substantive or a placeholder.

Processor obligation clause (Article 28(3)(a) — minimum standard):

"The Processor shall process Personal Data only on documented instructions from the Controller, including with regard to transfers of Personal Data to a third country or an international organisation, unless required to do so by Union or Member State law to which the Processor is subject; in such a case, the Processor shall inform the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest."

Sub-processor clause (Article 28(3)(d)):

"The Processor shall not engage another processor without prior specific or general written authorisation of the Controller. In the case of general written authorisation, the Processor shall inform the Controller of any intended changes concerning the addition or replacement of other processors, thereby giving the Controller the opportunity to object to such changes."

Return or deletion clause (Article 28(3)(g)):

"At the choice of the Controller, the Processor shall delete or return all Personal Data to the Controller after the end of the provision of services relating to processing, and shall delete existing copies unless Union or Member State law requires storage of the Personal Data."

What weak DPA language looks like: Clauses that say "we will process data securely" without specifying the Article 28 obligations, or that omit the sub-processor list, or that give the processor discretion to decide what to do with data after contract termination. These gaps matter in enforcement scenarios.

EU AI Act Consideration: High-Risk Processing

If your organization processes CSV data as input to or training data for an AI system that falls under Annex III of the EU AI Act (high-risk AI), the agreement requirements expand beyond the standard DPA/BAA/SCC stack. The EU AI Act's Article 10 data governance obligations apply to the data used to train or operate the system — and the DPA governing the processor relationship should address these specifically.

When the EU AI Act adds obligations to your CSV processing:

The EU AI Act deadline for high-risk AI system compliance is August 2, 2026 for new deployments. See our EU AI Act data processing guide for the full obligation map.

What to Do When a Vendor Won't Sign

Some vendors — particularly small tools, free tools, or tools not designed for enterprise use — will not offer DPAs or BAAs. Your options:

Option 1: Use the tool only for non-personal data. Strip personal data before processing. If the file to be processed contains only aggregate statistics, truly anonymized data, or non-personal records, the agreement requirements do not apply.

Option 2: Apply data minimization before upload. Remove or mask direct identifiers before uploading to the tool. This reduces (but may not eliminate) the personal data present. Assess whether remaining fields constitute personal data under GDPR's broad definition before proceeding.

Option 3: Switch to a client-side tool. A tool that processes files locally bypasses the upload trigger. Use a client-side tool for any processing that involves personal data, and reserve server-side tools for non-sensitive files.

Option 4: Escalate to legal. If business requirements mandate using a server-side tool with personal data and the vendor will not provide required agreements, this is a decision for legal counsel and DPO, not a data operations decision.

Additional Resources

GDPR Official Text:

• GDPR Article 28 — Processor — Full text of DPA requirements
• GDPR Chapter V — International Transfers — Transfer mechanism provisions
• European Commission Standard Contractual Clauses (2021) — Current operative SCCs

HIPAA:

• HHS Business Associate Guidance — BAA requirements
• HHS PHI Definition — What constitutes PHI

Transfer Frameworks:

• EU-US Data Privacy Framework — DPF certification registry
• European Commission Adequacy Decisions — Current list of adequate countries

EDPB Guidance:

• EDPB Controller-Processor Guidelines — Guidance on the controller/processor distinction

FAQ