SOC 2 and CSV Tools — Quick Reference:
- SOC 2 CC9 requires vendor risk assessment for every tool that receives customer data
- CC6 requires logical access controls on all systems touching customer data
- Confidentiality TSC (C1) applies to customer data in CSV exports
- Local browser-based tools often remove the tool from vendor data-processing scope — with documented evidence
- DevTools network tab verification is auditor-acceptable evidence of no transmission
Quick Answer
SOC 2 CSV data processing is examined at the tool level — auditors review every third-party application your team uses to handle customer data, including CSV processing tools.
Why it matters: SOC 2 Trust Services Criteria (TSC) CC6 and CC9 specifically require that vendors with access to customer data be assessed and that logical access to systems and data be controlled. An unapproved cloud CSV tool that receives customer data can become an audit finding.
The fix: Use tools that process data locally — eliminating vendor risk from the SOC 2 scope — and document your tool evaluation process as evidence for the audit.
Root cause: SOC 2 is an operational audit. Auditors follow the data. If customer data flows through an unassessed tool, that tool is in scope — regardless of how small the task was.
Fast Fix (Before Your Next SOC 2 Audit)
If your audit window is approaching:
- Inventory every tool your team uses to handle customer data — including CSV processors, data cleaning tools, and export utilities.
- Identify which tools transmit customer data to third-party servers — these are in SOC 2 vendor scope.
- Pull SOC 2 Type II reports for any in-scope vendor — if the vendor does not have one, flag for remediation.
- Switch ad-hoc CSV processing to a local tool — eliminating transmission to unassessed vendors removes those tools from scope.
- Document your evidence — auditors need to see tool evaluation records, not just assertions that processes exist.
For the full Trust Services Criteria mapping, continue below.
TL;DR: SOC 2 auditors assess every vendor that receives customer data, including CSV processing tools used for routine data tasks. Cloud-based CSV tools without SOC 2 Type II reports create audit findings under CC6 and CC9. Use SplitForge Data Masking to process and mask customer CSV data locally — removing the tool from SOC 2 vendor scope entirely.
Legal disclaimer: The content in this post is for informational purposes only and does not constitute legal or audit advice. SOC 2 audit scope and findings depend on your specific systems, data flows, and auditor. Consult qualified auditors and legal counsel for organization-specific guidance.
Your engineering team's security review found it. The customer success team has been exporting CRM data to a CSV, uploading it to a cloud deduplication tool to clean the list, then re-importing. 80,000 customer records. Monthly. For two years.
Nobody thought to add that tool to the vendor risk list. The deduplication tool had no SOC 2 report. The SOC 2 auditor found it during evidence collection for CC9 (risk mitigation with business partners) and flagged it as a gap.
The finding delayed the SOC 2 Type II report by six weeks. Three enterprise deals stalled while customers waited for the report. That is the cost of one unassessed CSV tool.
This post maps which SOC 2 Trust Services Criteria apply to CSV processing workflows and what auditors specifically look for. Criteria descriptions and Common Criteria references reviewed against AICPA Trust Services Criteria documentation, March 2026.
Table of Contents
- Which Trust Services Criteria Apply to CSV Processing
- What Auditors Actually Examine in Data Workflows
- The Vendor Risk Gap: Why CSV Tools Become Audit Findings
- SOC 2 Criteria vs CSV Workflow Mapping
- Remediation: Three Paths to Compliance
- Evidence Requirements for SOC 2 Auditors
- Additional Resources
- FAQ
Which Trust Services Criteria Apply to CSV Processing
SOC 2 is structured around five Trust Services Criteria (TSC): Security (required for every SOC 2 engagement), Availability, Processing Integrity, Confidentiality, and Privacy. For most SaaS and technology companies, Security, Confidentiality, and Privacy are the three criteria relevant to CSV data processing workflows.
The Security criteria are organized into Common Criteria (CC) numbered groups. Two CC groups are most directly relevant to CSV processing tool selection:
CC6 — Logical and Physical Access Controls: Requires that logical access to systems, data, and resources is managed to restrict access to authorized users and to prevent unauthorized access. If customer data passes through a tool that the security team has not assessed and approved, CC6 is implicated — the data flowed to a system not under logical access control review.
CC9 — Risk Mitigation: Requires identifying and assessing the risks associated with the use of vendors and business partners. Any vendor that receives customer data — including a CSV processing tool — should be assessed before use, with documentation of the assessment available for the auditor.
Confidentiality TSC (C1): Requires that information designated as confidential is protected from access by unauthorized parties. Customer data in CSV exports is generally confidential. If that data flows through an unapproved tool, the confidentiality criteria are implicated.
Privacy TSC (P6 — Disclosure to Third Parties): Requires that personal information is disclosed to third parties only for the purposes identified in the privacy notice, with appropriate protections in place. Uploading customer personal data to an unapproved CSV tool may constitute an unauthorized disclosure under P6.
What Auditors Actually Examine in Data Workflows
SOC 2 auditors for CC9 do not just review your vendor list. They sample data flows. They ask how data moves through the organization, then follow it. If the data path leads to a tool that is not in the vendor risk register, it becomes a question — and potentially a finding.
Here is the type of evidence request that surfaces CSV tool gaps:
❌ AUDIT EVIDENCE GAP (common finding):
Auditor request (CC9.2):
"Please provide evidence of your vendor risk assessment process for vendors
that process or have access to customer personal data."
Response submitted:
- Vendor risk register (37 vendors listed)
- SOC 2 reports for Salesforce, AWS, Stripe, Zendesk, Twilio
Auditor follow-up:
"During our data flow walkthrough with your customer success team, we identified
that customer contact data is regularly exported to CSV and processed using
[Tool Name], which is not listed in your vendor risk register and does not
appear in your SOC 2 evidence package. Please provide risk assessment
documentation for this tool or remediation evidence."
Status: OPEN FINDING — CC9.2 vendor risk assessment gap
Resolution required before SOC 2 Type II opinion is issued.
REMEDIATED EVIDENCE (what the auditor needs to close the finding):
Option A: SOC 2 Type II report for the CSV tool + signed DPA
Option B: Evidence that the CSV tool processes data locally (no server transmission)
+ tool evaluation documentation dated before first use
The finding is not catastrophic — it can be remediated. But it delays the audit, requires additional evidence collection, and creates a timeline problem if an enterprise customer is waiting for the report.
The Vendor Risk Gap: Why CSV Tools Become Audit Findings
The gap appears because CSV processing is perceived as a utility function — a tool used to clean data before it goes somewhere else. Teams that carefully assess their CRM, their data warehouse, and their email platform often do not apply the same rigor to the tools used in between.
But from a SOC 2 perspective, the data is what matters — not the perceived importance of the tool. If customer personal data enters a tool, that tool is processing customer data. The fact that the processing is temporary or low-risk in the team's view does not change the auditor's assessment framework.
The three most common CSV-related audit findings are:
- Unapproved tool in data flow — customer data passed through a tool not in the vendor risk register
- No SOC 2 report for vendor — tool is in the vendor risk register but the vendor does not have a SOC 2 Type II report
- No DPA in place — vendor processes EU personal data but no Data Processing Agreement exists
All three have the same root cause: the team did not formally assess the CSV tool before using it for customer data.
Many SaaS tools retain uploaded files temporarily for debugging, caching, or processing purposes — retention policies vary by vendor and use case. For SOC 2 purposes, any such tool becomes a vendor in scope for CC9 assessment. SplitForge processes files in Web Worker threads in the browser. For raw file contents, nothing is transmitted to any server during processing. A tool that never receives customer data materially reduces or eliminates the vendor risk assessment burden for that processing activity — auditors typically focus CC9 scrutiny on vendors that receive data, not tools that demonstrably do not.
SOC 2 Criteria vs CSV Workflow Mapping
Use this mapping to identify which criteria are implicated at each stage of a typical CSV processing workflow.
| Workflow Step | SOC 2 Criteria Implicated | What Auditors Look For | Evidence Required |
|---|---|---|---|
| Export customer data from CRM | CC6.1 — Logical access controls | Who can export? Access control documentation. | Export permissions log, role-based access policy |
| Open/preview CSV file | CC6 — minimal if local only | Is data accessed only by authorized personnel? | Device encryption policy, screen lock policy |
| Upload CSV to cloud tool | CC9.2 — Vendor risk assessment | Is this vendor assessed? SOC 2 report available? | Vendor risk register entry + vendor's SOC 2 Type II |
| Process CSV in cloud tool | C1 — Confidentiality, P6 — Disclosure | Is data protected? Disclosure authorized? | Vendor DPA + data flow documentation |
| Download processed file | CC6.1 | Download controls, authorized recipients only | Access log |
| Store/archive processed file | C1 — Confidentiality | Retention period, encryption at rest | Retention policy + encryption documentation |
| Delete after use | CC6 — Data disposal | Secure deletion confirmed | Deletion log or policy evidence |
For steps involving a cloud tool (row 3-4), the audit evidence burden is highest. Eliminating those steps — by using a local tool — removes the CC9 vendor assessment requirement and the C1 disclosure documentation requirement for that processing activity.
Remediation: Three Paths to Compliance
If you have identified a CSV tool gap in your SOC 2 scope, three remediation paths are available.
Path 1: Obtain the vendor's SOC 2 Type II report and sign a DPA. Request the vendor's current SOC 2 Type II report. Verify it covers the Security trust services criteria. Sign a DPA if EU personal data is involved. Add the vendor to your risk register with the assessment date and report period. This path is viable if the vendor has a current SOC 2 report — many smaller CSV tools do not.
Path 2: Restrict the tool to non-customer data only. If the CSV tool is used for internal analytics data or anonymized exports with no customer personal data, document that restriction as a control. Implement a policy and technical control preventing customer personal data from being uploaded. Train the team. This path is viable if the tool's use case can be genuinely scoped to non-personal data.
Path 3: Switch to a local processing tool for customer data tasks. Use a browser-based tool that processes data locally without transmitting it to any server. Document the evaluation confirming no transmission occurs (Chrome DevTools verification is sufficient evidence — see how to verify a CSV tool is client-side). Remove the prior tool from the data flow for customer data tasks. This path eliminates the vendor risk finding for future audit periods.
For a complete vendor evaluation framework, see CSV tool security checklist and questions to ask vendors before uploading CSV data.
Evidence Requirements for SOC 2 Auditors
Auditors need evidence, not assertions. For CSV processing workflows, the specific evidence types that satisfy common criteria requests are:
For CC9 — Vendor risk assessment:
- Completed vendor risk assessment form with date, assessor name, and risk determination
- Copy of vendor's current SOC 2 Type II report (or equivalent, e.g., ISO 27001)
- Signed DPA or data processing addendum if personal data is involved
- Evidence of annual re-assessment (for continuous monitoring)
For CC6 — Logical access:
- Screenshot or export from CRM or data warehouse showing who has export permissions
- Role-based access control policy
- Audit log showing export events (who exported, what, when)
For C1 — Confidentiality:
- Data classification policy showing customer data is classified as confidential
- Evidence that tools receiving confidential data are listed in vendor register
- Data flow diagram showing all systems that touch customer data
For P6 — Disclosure to third parties:
- Privacy notice stating what third parties may receive personal data
- Vendor list showing third parties actually receiving data
- Confirmation that vendor list matches privacy notice disclosures
For a complete overview of privacy controls in data processing workflows, see our privacy-first data processing guide.
What Auditors Actually Flag: Real CSV Finding Patterns
The three CSV-related findings below appear repeatedly across SOC 2 Type II audits. Each includes the typical auditor language, the time required to remediate, and the evidence needed to close the finding.
Finding 1: Unapproved CSV tool in customer data flow Typical auditor comment: "During data flow walkthrough with the customer success team, we identified that customer contact data is regularly exported to CSV and processed using [Tool Name], which is not listed in the vendor risk register. No risk assessment documentation was provided." Time to fix: 15–30 minutes if switching to local tool (document DevTools verification); 1–2 days if obtaining vendor's SOC 2 report and DPA. Evidence to close: Either DevTools screenshot showing no file transmission, or vendor's current SOC 2 Type II report + signed DPA + risk register entry.
Finding 2: No documented data flow for CSV exports Typical auditor comment: "The organization was unable to provide a complete data flow diagram for customer data. Specifically, CSV exports from the CRM were not included in the documented data flows, making it impossible to confirm all processing locations were assessed." Time to fix: 2–4 hours to document CSV export flow; add to existing data flow diagram. Evidence to close: Updated data flow diagram showing CSV export path, processing tool, and destination.
Finding 3: Logical access not documented for export function Typical auditor comment: "We were unable to confirm that access to the CRM export function is restricted to authorized personnel. No access control matrix or export permission log was provided for the audit period." Time to fix: 30–60 minutes to document current role assignments; ongoing access log requires CRM configuration change. Evidence to close: Screenshot of CRM role settings showing export permissions; user list with export access; access log for the audit period.
These three findings are preventable. The first requires a tool decision made once. The second requires documentation that should exist anyway. The third requires a CRM configuration review that takes under an hour.
SOC 2 CSV Tool Evaluation Checklist
Use this checklist when assessing any CSV processing tool for CC9 compliance. Complete it before first use for customer data, and repeat annually.
| Evaluation Criterion | Question | If Yes | If No |
|---|---|---|---|
| Data transmission | Does the tool upload file contents to a remote server? | Requires vendor risk assessment | Local tool — assessment focused on device security only |
| SOC 2 Type II report | Has the vendor published a current SOC 2 Type II report (Security criteria)? | Obtain and review | Flag as gap; escalate before use for customer data |
| Report currency | Is the report period within the last 12 months? | Acceptable | Request updated report or use with documented exception |
| DPA availability | Will the vendor sign a GDPR-compliant Data Processing Agreement? | Obtain before use with EU data | Cannot use for EU personal data without alternative |
| Retention policy | What is the vendor's file retention period per ToS? | Document period in vendor register | Request clarification; note in risk register |
| Breach notification | Does the vendor's contract include breach notification obligations? | Note procedure and timeline | Flag as gap; request addendum |
| Encryption | Does vendor confirm encryption in transit and at rest? | Document confirmation | Flag as gap |
| Risk register entry | Is the vendor added to your risk register with assessment date? | Compliance maintained | Add before first use |
Here is what the vendor risk register looks like with and without a CSV tool entry — the exact evidence gap auditors find during CC9 sampling:
❌ BROKEN — CSV tool missing from vendor register (common audit finding):
| Vendor | Service | Data Shared | SOC 2 | DPA | Last Review |
| Salesforce | CRM | Customer PII | ✓ 2025 | ✓ | 2025-09-01 |
| AWS | Infrastructure | All | ✓ 2025 | ✓ | 2025-09-01 |
| Stripe | Payments | Financial PII | ✓ 2025 | ✓ | 2025-09-01 |
[CloudCSVTool.com not listed — receives customer data monthly — CC9 gap]
Auditor finding: "Customer data flows to CloudCSVTool.com, which is not included
in the vendor risk register and has not been assessed. CC9.2 gap identified."
FIXED — CSV tool assessed and registered:
| Vendor | Service | Data Shared | SOC 2 | DPA | Last Review |
| Salesforce | CRM | Customer PII | ✓ 2025 | ✓ | 2026-01-15 |
| AWS | Infrastructure | All | ✓ 2025 | ✓ | 2026-01-15 |
| Stripe | Payments | Financial PII | ✓ 2025 | ✓ | 2026-01-15 |
| SplitForge | CSV Processing | None — local | N/A* | N/A* | 2026-01-15 |
*Local processing confirmed via DevTools — no file transmission. Evidence: Network
tab screenshot on file. Assessment: No vendor data flow — local tool only.
Auditor close: "SplitForge confirmed as local processing tool with no data transmission.
DevTools verification on file. CC9 assessment complete."
Additional Resources
Reviewed: AICPA Trust Services Criteria descriptions cross-referenced against official AICPA documentation. SOC 2 criteria references (CC6, CC9, C1, P6) verified against current TSC framework. March 2026.
Official SOC 2 Sources:
- AICPA SOC 2 — Trust Services Criteria — Official TSC documentation including CC6 and CC9
- AICPA Trust Services Criteria (2017 with 2022 updates) — Complete criteria text
Privacy and GDPR Integration:
- GDPR Article 28 — Processor DPA requirements — For EU data in SOC 2 scope
- NIST SP 800-53 — Security and Privacy Controls — Control catalog relevant to audit evidence
Vendor Assessment References:
- ISO/IEC 27001 — Alternative to SOC 2 for international vendors
- SplitForge: Verify Client-Side Processing with DevTools — Evidence collection for local tool assessments