Quick Answer
Seven questions reveal whether any CSV processing tool is safe for sensitive data. The most important is whether files are processed on the vendor's servers or entirely in your browser — this single answer determines which regulatory obligations apply. The others cover retention, agreements, cross-border transfers, logging practices, and breach procedures. Get written answers before uploading any personal data.
TL;DR: Vendor websites rarely volunteer the information needed to assess privacy risk. You need to ask directly — in writing — and treat non-answers as a fail. This guide gives you the seven questions, where to find the answers, and a scorecard to document results.
Your procurement team is reviewing three CSV tools for your data operations workflow. All three have attractive pricing and similar feature sets. One has a privacy policy that explicitly states it does not retain uploaded files. One has a privacy policy that is silent on retention. One explicitly says it may use uploaded data to improve its services.
Most teams using CSV tools never evaluate them against these questions before uploading customer records. They evaluate them against the feature comparison table. The compliance risk surfaces months later — during a GDPR audit, a vendor security questionnaire from a client, or an incident.
This framework was developed by reviewing GDPR Article 28 obligations, HIPAA §§164.502(e) and 164.504(e), GDPR Chapter V transfer requirements, and common vendor documentation patterns, March 2026. It applies to any tool where sensitive data files might be uploaded.
Table of Contents
- Vendor Scorecard Template
- Question 1: Client-Side or Server-Side?
- Question 2: What Is the File Retention Period?
- Question 3: Is a DPA Available?
- Question 4: Is a BAA Available?
- Question 5: What Transfer Safeguards Apply for Non-EEA?
- Question 6: What Does Telemetry and Logging Collect?
- Question 7: What Is the Breach Notification Procedure?
- How to Get Answers
- Additional Resources
- FAQ
This guide is for: Anyone responsible for evaluating whether a CSV or data processing tool is appropriate for use with personal data — analysts, compliance teams, procurement, or DPOs.
Vendor Scorecard Template
Use this template to document vendor responses. Get answers in writing — email or vendor documentation is sufficient. Do not rely on verbal assurances.
| Question | Your Tool | Written Evidence? | Pass / Fail / Unknown |
|---|---|---|---|
| 1. Client-side or server-side? | |||
| 2. File retention period? | |||
| 3. DPA available? | |||
| 4. BAA available? | |||
| 5. Transfer safeguards for non-EEA? | |||
| 6. Logging and telemetry documented? | |||
| 7. Breach notification procedure? | |||
| Overall |
Scoring guide: 7/7 documented pass = vendor meets the basic due-diligence baseline for personal data use — confirm appropriate agreements are signed before proceeding. 5–6/7 = address gaps before use. 4 or fewer = do not use with personal data without remediation.
Question 1: Client-Side or Server-Side?
Ask: "Does your tool process uploaded files on your servers, or entirely in the user's browser?"
Why this matters: Server-side processing means your file is uploaded to the vendor's infrastructure. This triggers GDPR Article 28 (processor relationship requiring a DPA), HIPAA BAA requirements if PHI is involved, and international transfer obligations under GDPR Chapter V if the vendor's servers are outside the EEA.
Client-side processing means the file is read by the browser using the File API and processed locally. No upload occurs. None of those obligations are triggered for the processing operation itself.
Where to find the answer: The tool's technical documentation, architecture overview, or security page. If not documented, check in Chrome DevTools — open the Network tab, upload a small test file, and look for POST requests containing file data. Presence of such requests confirms server-side processing.
Red flag: "We use secure servers" is not an answer to this question. It describes server security, not processing location.
Question 2: What Is the File Retention Period?
Ask: "How long do you retain uploaded files after processing is complete? Where is this documented?"
Why this matters: A file retained on a vendor's servers for 30 days is within the vendor's control — and subject to their security posture, their employees' access, their backup infrastructure, and any future security incident — for 30 days. During that window, you have limited visibility and no direct control.
Many SaaS tools retain uploaded files temporarily — retention policies vary by vendor. For files containing personal data under GDPR, each day of retention is a day of processor exposure.
Where to find the answer: Privacy policy (search "retain," "deletion," "storage"), terms of service, or security FAQ. If the privacy policy is silent on file retention, that silence is itself a red flag.
Acceptable answers: Zero retention (client-side tool), same-session deletion, or documented deletion within 24 hours of processing.
Red flag: Retention of 7+ days with no security justification. "Files may be retained for service improvement" — this is training data consent language.
Question 3: Is a DPA Available?
Ask: "Do you offer a GDPR Data Processing Agreement? Is there a standard template I can review?"
Why this matters: Under GDPR Article 28, if a processor handles personal data on behalf of a controller, a signed DPA is legally required. It is not a nice-to-have. Operating a processor relationship without a DPA is a direct violation.
Where to find the answer: Vendor legal page, trust center, or "GDPR compliance" page. A vendor serious about GDPR compliance will have a downloadable DPA template — not a "contact sales" wall.
What the DPA must include (Article 28(3) minimum): Subject matter and duration of processing, nature and purpose, type of personal data, categories of data subjects, obligations and rights of the controller, sub-processor list.
Red flag: "We are working on it." No DPA template available without a sales conversation.
See our GDPR Article 28 guide for what the DPA must contain.
Question 4: Is a BAA Available?
Ask: "For healthcare organizations processing PHI, do you offer a signed Business Associate Agreement?"
Why this matters: HIPAA requires a BAA under 45 CFR §§164.502(e) and 164.504(e) whenever a covered entity uses a vendor that handles Protected Health Information. This applies to any CSV file containing patient names, dates of service, diagnosis codes, treatment information, or any other PHI. The BAA requirement exists regardless of how the tool is marketed — even if it is not marketed as a healthcare tool.
Where to find the answer: Vendor's healthcare or compliance page. A vendor offering BAAs will typically say so explicitly.
Red flag: No mention of HIPAA anywhere on the vendor's website. This indicates the vendor has not assessed PHI compliance and almost certainly cannot offer a BAA.
Practical note: A DPA and a BAA are separate documents for separate regulatory frameworks. A vendor can offer one without the other. If files may contain PHI from EEA residents, you may need both.
Question 5: What Transfer Safeguards Apply for Non-EEA Processing?
Ask: "If your servers are outside the EEA, what GDPR Chapter V transfer mechanism do you use for EU personal data?"
Why this matters: GDPR Chapter V prohibits transferring personal data from the EEA to third countries without a valid legal mechanism. For US-based vendors, the options are: EU-US Data Privacy Framework certification (Article 45 adequacy), Standard Contractual Clauses incorporated into the DPA (Article 46(2)(c)), or Binding Corporate Rules (Article 47). In May 2023, Meta was fined €1.2 billion by the Irish Data Protection Commission for transferring EU personal data to US servers without a valid mechanism.
Where to find the answer: DPA (SCCs are typically incorporated or attached), vendor's GDPR FAQ, or EU Data Privacy Framework registry at https://www.dataprivacyframework.gov.
Red flag: A US-based vendor with no mention of SCCs, BCRs, or DPF certification. "We comply with applicable law" without specifying which mechanism is not a compliant answer.
See our international data transfers guide for the full Chapter V framework.
Question 6: What Does Telemetry and Logging Collect?
Ask: "What data does your tool log during or after file processing? Specifically, does your logging capture any content from uploaded files?"
Why this matters: Even a tool with short file retention may log file-related data for debugging, analytics, or crash reporting. Depending on what is logged, this creates a secondary retention issue. Under GDPR Article 5(1)(a), processing must be transparent — a vendor whose logging practices are undocumented is not transparent about what happens to personal data.
Common logging categories:
- Metadata only (acceptable): File size, processing time, error codes, session ID
- Partial content (risk): Column names, row counts, error rows with field values
- Full content (serious risk): File contents captured in debug logs or error reports
Where to find the answer: Privacy policy (search "log," "collect," "telemetry," "analytics," "crash report"). Technical documentation.
Red flag: "We may collect information you provide to us" language that could encompass file contents. No documentation of logging scope at all.
Question 7: What Is the Breach Notification Procedure?
Ask: "If you experience a security breach affecting data from our files, what is your notification procedure and timeline?"
Why this matters: Under GDPR Article 33, a data processor must notify the controller without undue delay — and within 72 hours of becoming aware of a breach. Under HIPAA, notification is required within 60 days of discovery. Without a documented procedure, you cannot rely on timely notification.
What to look for: A specific timeline. A named contact or method (account portal, email, security@ address). Documentation of what information the vendor will provide in the notification.
Red flag: "We will notify you as required by applicable law" with no specific timeline or contact. A vendor that has not thought through breach notification procedure has not thought through security incident response.
How to Get Answers
Step 1: Check the vendor's legal page, trust center, and privacy policy before contacting anyone. Most of these questions should be answerable from public documentation for any compliance-ready vendor.
Step 2: If answers are not in public documentation, email the vendor's privacy or legal contact (usually privacy@[vendor].com or legal@[vendor].com). Use the exact questions above. Ask for responses in writing.
Step 3: If the vendor responds with vague or evasive answers, treat those as fails. A vendor that has done the compliance work will have clear, documented answers. Vagueness indicates the work has not been done.
Step 4: Document your findings in the scorecard template above. Keep the documentation — if your organization is audited, evidence of pre-use vendor assessment demonstrates due diligence.
Red Flags Quick Reference
When evaluating vendor responses, these specific phrases and patterns signal compliance gaps more reliably than general marketing claims.
Phrases that indicate a compliance gap:
- "We take security seriously" — describes intent, not controls. Ask for specifics.
- "We comply with applicable law" — does not identify which laws or mechanisms apply.
- "We use industry-standard encryption" — describes a security control, not processing location or retention.
- "Our servers are ISO 27001 certified" — describes a security framework, not GDPR or HIPAA compliance.
- "Contact our sales team for compliance inquiries" — in a compliance-first vendor, documentation is self-service.
- "We may use data to improve our services" — this is training data consent language and should trigger immediate review.
For a full phrase-by-phrase reference table including what each signals and what action to take, see the Privacy Policy Red-Flag Phrases table in our CSV Tool Security Checklist — it covers ten specific phrases to search for in any vendor privacy policy.
Privacy page structures that typically indicate server-side processing:
- Explicit mention of "data centers," "servers," or "cloud infrastructure" as where data is processed.
- SOC 2 certification mentioned without clarifying whether it applies to file data or account data only.
- Retention policies for uploaded content (even "we delete within 24 hours" confirms server-side receipt).
Privacy page structures consistent with client-side processing:
- Explicit statement that file contents are never transmitted or received by vendor servers.
- Technical explanation referencing File API, Web Workers, or browser-based processing.
- DevTools verification instructions or architecture diagrams showing local processing.
- Absence of any retention policy for processed files — because there is nothing to retain.
Keep this reference when reviewing vendor privacy policies. The presence of absence is often the most informative signal.
Additional Resources
GDPR Official Sources:
- GDPR Article 28 — Processor obligations — Full text of DPA requirements
- GDPR Chapter V — International transfers — Transfer mechanism requirements
- EU Data Privacy Framework Registry — Verify US vendor DPF certification
HIPAA:
- HHS Business Associate FAQ — BAA requirements
Transfer Mechanisms:
- EDPB Standard Contractual Clauses Guidance — How to implement SCCs
Related Checklists:
- SplitForge CSV Tool Security Checklist — 8-criterion evaluation matrix
- DPA, BAA, and SCCs Guide — Which agreements are required when