SOC 2 (System and Organisation Controls 2) is an auditing framework developed by the American Institute of Certified Public Accountants (AICPA) that defines how service organisations should manage customer data. Unlike prescriptive standards that dictate specific technologies or configurations, SOC 2 is criteria-based: it establishes what your controls must achieve, not how you implement them. This flexibility makes SOC 2 applicable to organisations of nearly any size, technology stack, or operational model.
In practice, SOC 2 has become the baseline trust credential for technology companies operating in the B2B space. If your organisation stores, processes, or transmits customer data — and particularly if you deliver software as a service — SOC 2 compliance is almost certainly a prerequisite for closing enterprise deals.
What does SOC 2 stand for?
SOC stands for System and Organisation Controls. The “2” distinguishes it from two related but distinct report types:
- SOC 1 focuses on controls relevant to financial reporting (governed by SSAE 18 / ISAE 3402). It is designed for service organisations whose services affect their clients’ financial statements — payroll processors, payment platforms, and similar entities.
- SOC 2 focuses on controls relevant to security, availability, processing integrity, confidentiality, and privacy. It is governed by the AICPA’s Trust Service Criteria (TSC) and is the standard for technology and cloud service providers.
- SOC 3 uses the same criteria as SOC 2 but produces a general-use report suitable for public distribution. It contains less detail and is rarely requested by enterprise buyers.
The SOC 2 framework traces its origins to SAS 70, an earlier auditing standard that the AICPA retired in 2011. The AICPA replaced it with the SSAE 16 standard (later updated to SSAE 18), which gave rise to the SOC reporting suite. The Trust Service Criteria themselves were most recently updated in 2017, aligning them more closely with the COSO 2013 internal control framework.
Why SOC 2 matters — business impact and customer trust
SOC 2 compliance is not a regulatory requirement in the way that HIPAA or PCI DSS can be. No government body mandates it. Yet it has become one of the most consequential compliance standards for technology companies, for three reasons.
Deal velocity
Enterprise procurement teams routinely require SOC 2 reports before signing contracts. Without one, your sales cycle stalls — prospects must either accept additional risk or escalate internally, both of which extend timelines by weeks or months. Organisations with a current SOC 2 Type 2 report can respond to security questionnaires faster and close deals with less friction.
Customer trust
A SOC 2 report is an independent, third-party attestation that your organisation has implemented controls to protect customer data. It is not a self-assessment or a checkbox exercise. A licensed CPA firm must examine your controls and issue a formal opinion. This level of external scrutiny carries weight that marketing claims and internal security pages cannot match.
Competitive positioning
In crowded markets, SOC 2 compliance is a differentiator — not because it proves you are more secure than competitors, but because it proves you have invested in demonstrating that security to an independent auditor. For early-stage SaaS companies especially, a SOC 2 report signals operational maturity that can tip evaluation decisions.
Reduced risk exposure
The process of preparing for SOC 2 forces organisations to formalise policies, identify gaps, and implement controls that reduce genuine security risk. The framework’s value is not purely commercial — many organisations discover and remediate vulnerabilities during the readiness phase that would otherwise have gone unaddressed.
Who needs SOC 2 compliance?
SOC 2 is relevant to any service organisation that handles customer data, but certain categories of companies face the strongest pressure to achieve compliance.
SaaS providers are the most common SOC 2 candidates. If your product stores or processes customer data in the cloud, enterprise buyers will ask for your SOC 2 report during procurement. This applies regardless of whether you host infrastructure yourself or use a cloud provider like AWS, Azure, or GCP.
Cloud infrastructure and hosting companies need SOC 2 to demonstrate that the environments they manage meet security and availability standards. Their customers’ own compliance obligations often cascade down to infrastructure providers.
Data analytics and AI/ML companies that ingest, process, or store client data face increasing scrutiny around data handling practices. SOC 2 provides a structured way to evidence those controls.
Managed service providers (MSPs) and managed security service providers (MSSPs) typically require SOC 2 because they have privileged access to client environments. Their clients need assurance that this access is controlled and monitored.
Financial technology companies often need both SOC 1 (for controls affecting financial reporting) and SOC 2 (for data security controls). The two reports serve different audiences and purposes.
Healthcare technology companies may pursue SOC 2 alongside HIPAA compliance. While SOC 2 does not replace HIPAA, the Privacy and Confidentiality criteria overlap meaningfully with HIPAA’s Security Rule requirements.
As a general rule: if your sales team is fielding security questionnaires, if your prospects’ legal teams are asking for compliance documentation, or if you are targeting mid-market and enterprise customers, SOC 2 should be on your roadmap.
SOC 2 Trust Service Criteria
The AICPA defines five Trust Service Criteria (TSC) that form the foundation of every SOC 2 audit. Organisations select which criteria to include in their report based on the nature of their services and the expectations of their customers.
| Criterion | Focus | Required? | Typical applicability |
|---|---|---|---|
| Security | Protection against unauthorised access (physical and logical) | Yes — always included | All service organisations |
| Availability | System uptime and operational reliability | No | SaaS, cloud hosting, infrastructure providers |
| Processing Integrity | Accuracy, completeness, and timeliness of data processing | No | Payment processors, data pipelines, analytics platforms |
| Confidentiality | Protection of data designated as confidential | No | Any organisation handling proprietary or sensitive business data |
| Privacy | Collection, use, retention, and disposal of personal information | No | Organisations processing personal data (especially where GDPR or CCPA apply) |
Security is the only mandatory criterion and is sometimes referred to as the Common Criteria. It includes nine categories of controls (CC1 through CC9) covering areas such as risk assessment, logical and physical access, system operations, and change management.
Most first-time SOC 2 audits include Security and Availability. Organisations processing sensitive data or personal information typically add Confidentiality and/or Privacy. Processing Integrity is less commonly selected but is critical for organisations whose core service involves data transformation or financial calculations.
For a detailed breakdown of each criterion and its sub-requirements, see our Trust Service Criteria guide.
SOC 2 Type 1 vs Type 2
SOC 2 reports come in two types, each serving a different purpose.
| Aspect | Type 1 | Type 2 |
|---|---|---|
| What it evaluates | Design of controls at a single point in time | Design and operating effectiveness of controls over a period |
| Observation period | None (point-in-time snapshot) | Typically 3 to 12 months |
| Time to achieve | 4 to 12 weeks (after readiness) | 3 to 12 months (including observation window) |
| Auditor effort | Lower — examines control descriptions and design | Higher — tests that controls actually operated as described |
| Market perception | Acceptable as a first step; not sufficient long-term | The standard enterprise buyers expect |
| Cost | Lower | Higher |
Type 1 is often used as a stepping stone. It demonstrates that you have designed appropriate controls, even if you have not yet operated them over time. Some organisations use Type 1 to unblock sales deals while their Type 2 observation period runs.
Type 2 is the report that matters. It provides evidence that your controls not only exist on paper but actually functioned as intended over a sustained period. Most enterprise procurement teams will specifically ask for a Type 2 report and may scrutinise the observation period length.
For a more detailed comparison, including guidance on which type to pursue first, see our Type 1 vs Type 2 guide.
What is a SOC 2 audit?
A SOC 2 audit is a formal examination conducted by a licensed CPA firm. The auditor evaluates whether your organisation’s controls satisfy the Trust Service Criteria you have selected. The audit results in a SOC 2 report — a detailed document containing the auditor’s opinion, a description of your system, the controls tested, and (for Type 2) the results of testing.
How the audit process works
The audit process typically follows these stages:
1. Scoping and planning. You define which systems, services, and Trust Service Criteria are in scope. The auditor reviews your system description and agrees on the scope, timeline, and logistics. Scoping decisions have a significant impact on cost and complexity — including unnecessary systems increases both.
2. Readiness assessment (optional but recommended). Before the formal audit, many organisations conduct a readiness assessment — either internally or with the help of a consultant. This identifies gaps between your current controls and what the audit will examine. Fixing these gaps before the audit begins avoids findings in the final report.
3. Control documentation. You document your policies, procedures, and technical controls. The auditor needs evidence that controls are formally defined, not just informally practised. This includes information security policies, access management procedures, change management processes, incident response plans, and vendor management practices.
4. Evidence collection. The auditor requests evidence that controls are in place and functioning. For a Type 1, this means demonstrating that controls are designed correctly. For a Type 2, this means providing evidence of control operation over the observation period — access reviews, change records, monitoring logs, incident reports, and similar artefacts. Evidence collection is often the most time-consuming phase.
5. Testing and evaluation. The auditor examines the evidence, tests controls through inquiry, observation, and inspection, and evaluates whether they satisfy the applicable Trust Service Criteria. For Type 2 audits, the auditor selects samples from the observation period and tests whether controls operated consistently.
6. Report issuance. The auditor issues a formal SOC 2 report containing their opinion (unqualified, qualified, or adverse), a description of the system examined, the criteria tested, and details of any exceptions or deviations found. The report is restricted-use — it can only be shared under NDA with parties who have a legitimate need.
What auditors actually look at
Auditors are not running penetration tests or scanning your code. They are evaluating whether your organisation has implemented controls that satisfy the Trust Service Criteria. In practice, this means they examine:
- Policies and procedures — Are they documented, approved, and communicated?
- Access controls — Who has access to systems and data, and how is that access provisioned, reviewed, and revoked?
- Change management — How are changes to production systems authorised, tested, and deployed?
- Monitoring and alerting — How do you detect anomalies, unauthorised access, or system failures?
- Incident response — Do you have a defined process for responding to security incidents, and have you used it?
- Vendor management — How do you evaluate and monitor third-party providers?
- Risk assessment — Do you have a formal process for identifying and evaluating risks?
How long does SOC 2 take?
The timeline from decision to report varies widely based on your organisation’s starting point.
| Starting position | Estimated timeline to Type 2 report |
|---|---|
| Minimal formal controls, no documented policies | 9 to 15 months |
| Some controls in place, informal documentation | 6 to 10 months |
| Strong security posture, partial documentation | 4 to 8 months |
| Mature controls with automation | 3 to 6 months |
Several factors influence timeline:
- Current security posture. Organisations that already follow security best practices (MFA enforcement, centralised logging, access reviews) will spend less time remediating gaps.
- Scope. More Trust Service Criteria and more systems in scope means more controls to implement, document, and evidence.
- Team capacity. SOC 2 preparation requires sustained effort from engineering, IT, and security teams. Organisations that cannot dedicate bandwidth will see timelines stretch.
- Auditor availability. CPA firms have capacity constraints, especially in Q4 and Q1. Book your audit window early.
- Automation. Compliance automation platforms can reduce the preparation and evidence collection phases from months to weeks by continuously monitoring controls and gathering evidence automatically.
SOC 2 vs other frameworks
SOC 2 is one of several frameworks that address information security and data protection. Understanding where it fits helps you plan a coherent compliance strategy.
| Framework | Governing body | Focus | Output | Geographic relevance |
|---|---|---|---|---|
| SOC 2 | AICPA | Data security for service organisations | Audit report (restricted use) | Primarily North America, increasingly global |
| ISO 27001 | ISO/IEC | Information security management system (ISMS) | Certification (public) | Global, especially Europe and APAC |
| SOC 1 | AICPA | Controls relevant to financial reporting | Audit report (restricted use) | North America |
| SOC 3 | AICPA | Same criteria as SOC 2, general-use format | General-use report (public) | North America |
| PCI DSS | PCI SSC | Cardholder data protection | Certification / attestation | Global (wherever card payments are processed) |
SOC 2 vs ISO 27001 is the most common comparison. Key differences: SOC 2 produces an audit report with a CPA’s opinion, while ISO 27001 produces a certification issued by an accredited certification body. ISO 27001 is prescriptive about requiring a formal ISMS, while SOC 2 is criteria-based and more flexible in how you achieve compliance. Many organisations pursue both — the control overlap is substantial (often 40 to 60 percent), so the incremental effort for the second framework is significantly lower than starting from scratch.
SOC 2 vs SOC 1: SOC 1 is for controls that affect your clients’ financial reporting. SOC 2 is for controls that protect data security and operations. If your service does not affect financial statements, SOC 1 is not relevant. Some organisations (particularly fintech companies) need both.
Common mistakes organisations make
Having worked with organisations at every stage of SOC 2 readiness, certain patterns of mistakes recur.
Over-scoping the audit. Including every system, service, and Trust Service Criterion in your first audit increases cost, complexity, and timeline. Start with the systems and criteria that matter most to your customers and expand scope in subsequent years.
Treating compliance as a project, not a programme. SOC 2 is not a one-time effort. Controls must be maintained and evidenced continuously. Organisations that treat compliance as an annual sprint — scrambling to produce evidence before the audit window — create unnecessary risk and cost.
Neglecting the observation period for Type 2. Your controls must be operational for the entire observation period. Controls implemented the day before the audit window opens will not satisfy the auditor. Plan your implementation timeline so that controls are in place before your observation period begins.
Relying on manual evidence collection. Screenshots, spreadsheets, and email threads are error-prone, time-consuming to gather, and difficult to maintain. Manual processes also create a significant burden on engineering teams, whose time is better spent building product.
Writing policies that do not reflect reality. Auditors test whether your organisation follows its own policies. If your access review policy says quarterly reviews and you have not done one in six months, that is an exception in the report. Write policies that describe what you actually do, then improve practices over time.
Ignoring subservice organisations. If you use cloud providers, third-party processors, or other vendors as part of your service delivery, they are subservice organisations. The auditor will ask how you monitor and evaluate their controls. Your SOC 2 report will typically disclaim responsibility for subservice organisation controls using the “carve-out” method, but you still need to demonstrate that you manage vendor risk.
How automation accelerates compliance
The traditional approach to SOC 2 compliance — manual policy writing, spreadsheet-based control tracking, screenshot evidence collection, and email-driven audit coordination — is labour-intensive and does not scale. For organisations managing multiple frameworks or undergoing annual re-audits, the cumulative burden compounds each year.
Compliance automation platforms address this by continuously monitoring your environment, automatically collecting evidence from integrated systems, and mapping controls across multiple frameworks. The practical benefits are measurable:
- Continuous control monitoring replaces periodic manual checks. Instead of quarterly access reviews conducted in a spreadsheet, automated platforms pull access data from identity providers and flag anomalies in real time.
- Automated evidence collection eliminates the weeks of work typically spent gathering screenshots and logs before an audit. Evidence is collected programmatically from cloud providers, version control systems, HR platforms, and other integrated tools.
- Cross-framework mapping means that controls implemented for SOC 2 are automatically mapped to corresponding requirements in ISO 27001, HIPAA, GDPR, and other standards. This reduces duplicate effort when pursuing multiple certifications.
- Audit-ready dashboards give auditors direct access to evidence and control status, reducing the back-and-forth communication that extends audit timelines.
The result is a shift from compliance as a periodic, disruptive project to compliance as a continuous, embedded operational function. Organisations that adopt automation typically reduce their time to audit readiness by 50 to 70 percent and significantly decrease the internal resource burden on engineering and security teams.
Next steps
If your organisation is evaluating SOC 2 compliance, the most productive first step is a gap assessment: compare your current controls against the Trust Service Criteria you plan to include in your audit, identify what is missing or undocumented, and build a remediation plan with clear ownership and timelines.
From there, the path typically follows this sequence:
- Select your Trust Service Criteria based on customer requirements and your service model.
- Conduct a gap assessment to identify missing controls and documentation.
- Remediate gaps — implement controls, write policies, configure monitoring.
- Engage an auditor and agree on scope, timeline, and logistics.
- Begin your observation period (for Type 2) with controls fully operational.
- Complete the audit and receive your SOC 2 report.
For detailed guidance on each of these steps, see our SOC 2 compliance checklist and preparing for your SOC 2 audit.