SOC 2 by industry
SOC 2 for data analytics: pipelines, warehouses and who can query what.
An analytics company takes in other people's raw data, transforms it, and hands back numbers that customers make decisions on. Buyers want to know three things: who can read their data on your side, whether another customer could ever query it, and whether the figures coming out are complete and correct. This guide covers how to put each of those into a SOC 2.
Back to SOC 2 services01 · Who asks
Who asks data analytics companies for a SOC 2 report
The buyer decides the scope and the weight of the report, so start with who is asking.
| Asked by | What they want to see |
|---|---|
| Customer data or platform team | How connector credentials are stored, what is copied, and how long raw data is kept. |
| Customer security team | Isolation between customers in shared warehouses and compute, and who on your staff can run queries against their data. |
| Customer finance or reporting team | Whether pipeline failures are detected so dashboards don't show silently stale or partial numbers. |
| Customer privacy office | Your role as a processor, sub-processors, and how deletion requests flow through derived tables. |
02 · What is in scope
What sits inside the system boundary
The report covers one system. In this sector the boundary usually takes in:
- Ingestion connectors
- Jobs that pull from customer databases, apps and files, plus the credentials they hold.
- Transformation pipelines
- The jobs and code that clean, join and aggregate data, with their scheduling and failure handling.
- Storage and warehouse
- Raw, staged and modelled layers, and how each customer's data is separated in them.
- Query and dashboard layer
- Where customers, and your staff, read results, including any shared query engine.
- Data science workspaces
- Notebooks and sandboxes where staff explore data; often the least controlled corner.
- Exports and reverse sync
- Pushes of results back into customer tools, which are outputs you are accountable for.
03 · Categories
Which Trust Services Categories matter here
Security is always in. The rest depend on what you promise customers.
| Category | Weight in this sector | Why |
|---|---|---|
| Security | Always | Required; the hard part is query-level access in a shared engine. |
| Confidentiality | Strong | Customer datasets are confidential by contract, with retention and disposal terms. |
| Processing Integrity | Often | Chosen when customers rely on your outputs as complete, accurate and timely inputs to their own reporting. |
| Availability | Sometimes | Matters when dashboards or feeds sit in a customer's operational loop. |
| Privacy | Sometimes | Considered when you collect personal information directly, for example through tracking scripts. |
04 · Vendors in the report
The vendors that appear in your report
Each one is a subservice organization or a carve-out, and the report has to say which.
- Cloud data warehouse
- Commonly carved out; your configuration (roles, network rules, sharing features) is still yours to evidence.
- Orchestration or managed pipeline service
- Carved out where it runs jobs on your behalf; monitor its report and its incident notices.
- Connector marketplace or third-party extractors
- Name any that hold customer credentials. They are often overlooked.
- Enrichment data suppliers
- If you blend in third-party data, describe the source and how its quality is checked.
05 · Sector controls
Controls that this sector makes necessary
Examples only. Your own wording is what the auditor tests.
- S.1Per-customer storage isolationEach customer's data lives in a separate schema, database or account, and shared engines enforce row- or tenant-level policies.
- S.2Staff query approvalEngineers query production customer data only through a logged, approved path with a stated reason.
- S.3Pipeline completeness checksRow counts and freshness are compared with source at each run; mismatches raise an alert.
- S.4Transformation change reviewChanges to models that produce customer-facing figures are reviewed and tested against known outputs before release.
- S.5Connector credential vaultingCustomer source credentials are stored in a secrets manager, scoped to read access and rotated on request.
- S.6Retention enforcementRaw ingested data is deleted on the contractual schedule, and the deletion job's runs are logged.
- S.7Sandbox data controlsNotebooks run on masked or sampled data unless an approval allows otherwise.
06 · Traps
Where companies in this sector slip
Predictable, and cheaper to fix before fieldwork.
- Ignoring derived data in deletion promises. Deleting the raw table but keeping aggregates and caches built from it may break a contract's promise.
- Treating data scientists as out of scope. If they can read customer data, their workspaces are part of the system.
- No population for staff queries. Without a log of who queried what, the auditor has nothing to sample.
- Claiming accuracy without a definition. Processing Integrity needs stated processing specifications. "Accurate dashboards" is not one.
- Shared service accounts in pipelines. One credential used by every job hides who changed what.
07 · Query isolation
Proving one customer can't query another's data
Isolation is a claim until something tests it on a schedule.
- Write down the isolation model: separate accounts, separate schemas, or shared tables with tenant filters.
- Name the component that enforces it, for example warehouse roles or a policy in the query service.
- Add an automated test that runs a query as one tenant and expects zero rows from another.
- Run the test on every release that touches the query path, and on a schedule in between.
- Keep the results. They are the population the auditor samples.
| Isolation model (illustrative) | Strength | What the auditor tends to probe |
|---|---|---|
| Separate account per customer | Strongest | Provisioning and the admin roles that span accounts |
| Separate schema per customer | Strong | Role grants and anyone with cross-schema rights |
| Shared tables with a tenant column | Weakest | Every code path that builds a query, and the tests for missing filters |
08 · Evidence
Evidence to have ready
What an auditor will ask for, in the order they usually ask.
- Data flow diagram from connector to dashboard, per layer
- Warehouse role grants and the periodic review of them
- Staff query logs with approvals for a sample of entries
- Pipeline run history showing completeness and freshness alerts and their resolution
- Change tickets for customer-facing models with test results
- Retention job logs and deletion confirmations
- Tenant isolation test results across the period
Processor duties come from the contract and the law
Where you process personal data for EU or UK customers, GDPR Article 28 expects a written contract setting out what a processor may do with it, and US state privacy laws use similar service-provider terms. A SOC 2 can evidence the controls behind those terms. It is not a statement that you comply with GDPR or any other law.
Sources: AICPA Trust Services Criteria (TSP section 100, 2017, revised points of focus 2022), including PI1.1 to PI1.5 and C1.1 to C1.2; AICPA description criteria (DC section 200); AICPA SOC 2 guide; EU General Data Protection Regulation, Article 28.
More about SOC 2 for data analytics
Our customers write their own SQL. Is their query logic in scope?
No; your platform is.
You are responsible for the engine, the isolation and the data you deliver to it. A customer's own query mistakes are theirs. The description should state that line, and list related CUECs such as reviewing their own users' access.
Is Processing Integrity worth adding for an analytics product?
When customers rely on your figures.
If customers feed your outputs into finance, billing or regulatory reporting, they often ask for it. You'll need written processing specifications and evidence that completeness and accuracy checks run. Without those, Confidentiality alone is the safer first step.
Do anonymised or aggregated datasets fall outside scope?
Only if the commitments say so.
If your contract promises to delete or protect customer data, data derived from it is usually expected to follow. Be explicit in the description about which layers your commitments cover.
How do we show a stale dashboard was handled properly?
Through the alert and its ticket.
An auditor looks for the freshness alert, the incident or ticket it created, and the fix. A failure that was detected and resolved through your process is evidence the control operated.
Scope your data analytics SOC 2 around what buyers ask.
A readiness assessment turns this into your boundary, your categories and your gaps.