Maurice Müller
Senior Content Manager
Maurice Müller is a journalist and content strategist with experience across print and digital media. At Formalize, he translates complex compliance and regulatory topics into clear, practical content for compliance, risk, and security professionals across Europe.
Key takeaways:
SOC 2 is neither a law nor a certification. An independent certified public accountant (CPA) firm examines your controls and issues a report, which customers typically request during procurement.
Five Trust Services Criteria form the basis. Security is required in every SOC 2 report; availability, processing integrity, confidentiality, and privacy are optional.
A Type 1 report assesses whether controls are suitably designed at a specific date. A Type 2 report also tests whether they operated effectively over a review period, commonly three to twelve months.
SOC 2 and ISO 27001 overlap substantially, but they're different instruments: ISO 27001 is a certification more common in Europe, while SOC 2 reports are most common in North America.
Most of the work happens before the audit: defining scope, assigning control owners, and collecting evidence that controls run as described.
A European software company is close to signing its first large US customer. Then the security questionnaire arrives, and one line holds everything up: "Please provide your most recent SOC 2 Type 2 report." The company is ISO 27001 certified. The customer's procurement team still wants the report.
That's how many organizations first meet SOC 2: through a customer rather than a regulator. Understanding what the report is, what it covers, and how long it takes to get one decides whether the deal moves forward this quarter or next year.
What is SOC 2?
In practice, SOC 2 is an examination. An independent CPA firm looks at the controls you have in place to meet one or more of the AICPA's Trust Services Criteria, and issues a report that customers and other stakeholders use to judge how well you protect your systems and the information entrusted to you.
SOC 2 isn't a fixed checklist. The criteria describe what needs to be achieved, and each organization designs its own controls to meet them. The AICPA adds "points of focus" to each criterion, but these are considerations, not mandatory controls. The current criteria date from 2017, with points of focus revised in 2022.
SOC 2 is one of three related report types. SOC 1 covers controls relevant to financial reporting, and SOC 3 is a shorter, general-use version of a SOC 2 report that can be shared publicly. Outside the US, comparable assurance reports are issued under the international standard ISAE 3000, which is why some European providers present an ISAE 3000 report instead. See how Formalize approaches SOC 2.
What does SOC 2 stand for?
SOC 2 stands for System and Organization Controls 2. The term was previously expanded as "Service Organization Control," and the number distinguishes it from SOC 1 and SOC 3.
Who needs SOC 2 compliance?
SOC 2 isn't a statutory requirement. It becomes relevant when customers ask for it, which typically happens for:
SaaS and cloud providers that host or process customer data.
Technology and data-processing companies whose services are embedded in other companies' operations.
Managed service providers with access to customer systems.
Other service organizations that handle sensitive customer or business data.
The request usually comes up during procurement, vendor risk assessments, or security reviews, and it's particularly common when selling to US enterprises. Some contracts also require a current SOC 2 report. If nobody you sell to asks for one, an ISO 27001 certification or an ISAE 3000 report may serve you better, especially in Europe.
What are the five SOC 2 Trust Services Criteria?
Security, also called the common criteria, is part of every SOC 2 report. The other four are added when they're relevant to the services you provide and the commitments you make to customers:
Criterion | What it covers | Example controls |
|---|---|---|
Security | Protection against unauthorized access, use, or changes to systems and information | Multi-factor authentication, access reviews, logging and monitoring, change management, incident response |
Availability | Whether systems are available for operation and use as committed | Backups, disaster recovery testing, capacity monitoring |
Processing integrity | Whether system processing is complete, valid, accurate, timely, and authorized | Input validation, reconciliations, quality checks on processing |
Confidentiality | Protection of information designated as confidential | Encryption, data classification, secure disposal |
Privacy | Collection, use, retention, disclosure, and disposal of personal information in line with the organization's commitments | Privacy notices, consent records, retention schedules |
One point matters for European organizations in particular: the privacy criterion assesses whether you meet your own privacy commitments. It doesn't make an organization GDPR compliant.
SOC 2 compliance requirements: what do organizations need?
Because SOC 2 sets criteria rather than prescribing controls, the SOC 2 requirements look different for every organization. Most programs, however, need to cover the same ground:
A defined scope, covering which services, systems, locations, and Trust Services Criteria the report includes.
Policies and controls that meet the selected criteria, backed by a structured approach to policy management.
Core operational areas, including access, change management, incident response, a risk management system, and third-party and vendor risk management.
Evidence that controls are implemented and, for Type 2, operating throughout the review period.
Clear ownership and documentation, so every control has someone accountable for it.
A system description. Management prepares a description of the system in scope and signs an assertion about it. Both are part of the final report, and they're often underestimated in preparation.
Examples of common SOC 2 controls
The common criteria fall into nine groups, CC1 to CC9. Your controls depend on your scope, but these are typical examples for each group:
Area | Example controls |
|---|---|
CC1 Control environment | Code of conduct, background checks, defined security roles, management oversight |
CC2 Communication and information | Policies shared with employees, a system description for customers, a channel to report incidents |
CC3 Risk assessment | A risk assessment at least once a year, including fraud risk and changes to the business |
CC4 Monitoring activities | Regular control reviews, internal audits, tracking and fixing control deficiencies |
CC5 Control activities | Documented procedures, segregation of duties, controls linked to identified risks |
CC6 Logical and physical access | Multi-factor authentication, access reviews, onboarding and offboarding, encryption |
CC7 System operations | Logging and monitoring, vulnerability scanning, incident response |
CC8 Change management | Approval, testing, and code review before changes reach production |
CC9 Risk mitigation | Vendor risk management, business continuity planning |
SOC 2 Type 1 vs Type 2: what is the difference?
The two report types answer different questions:
SOC 2 Type 1 | SOC 2 Type 2 | |
|---|---|---|
What it assesses | Whether controls are suitably designed | Whether controls are suitably designed and operated effectively |
Time frame | A specific date | A review period, typically three to twelve months |
Evidence the auditor needs | Proof that controls exist and are designed to meet the criteria | Proof that controls ran consistently across the whole period |
Typical use | A first report, or a quick answer to an early customer request | The report most enterprise buyers expect |
Enterprise buyers often place more weight on a Type 2 report, because it shows how controls worked over time, in addition to how they were designed. There's no fixed minimum review period: the CPA firm and the customers relying on the report decide what's acceptable. Which type to pursue first depends on your stage, your timeline, and what you're being asked for:
Type 1 often makes sense when you need to show your control design at a specific point in time, for example to answer an urgent customer request. Many organizations then move on to Type 2.
Type 2 is generally the better fit once customers want proof that your controls work in practice, not only on paper.
What to expect for SOC 2 in 2027
The criteria themselves aren't changing. As of October 2026, the 2017 Trust Services Criteria described above are still in force, and the AICPA's pending proposals don't revise them. Two developments are worth knowing about as you plan your next audit:
New attestation standards are in the works, but not for 2027 audits. In February 2026, the AICPA's Auditing Standards Board proposed revisions to the attestation standards that SOC 2 examinations are performed under. They aren't final yet, and as proposed, they would apply to engagements beginning on or after 15 June 2029. Examinations in 2027 and 2028 will still follow the current standards.
AI is getting more attention in audits. There are no AI-specific criteria, but auditors increasingly look at AI systems and AI vendors under the existing criteria, such as risk assessment, access control, and vendor management. If AI is part of your product or your operations, expect questions about it in your next examination.
Why is SOC 2 important for businesses?
The value of SOC 2 depends on who you sell to and what they require. Where it's relevant, a SOC 2 report can:
Build customer trust with an independent opinion rather than self-assessment.
Shorten procurement and vendor assessments, since reviewers can often rely on the report instead of long questionnaires.
Give sales one consistent answer to security questions, instead of a new reply for every customer.
Demonstrate control maturity to customers, partners, and investors.
Reveal gaps in security and governance processes, often during the readiness phase, before the auditor finds them.
See how your SOC 2 preparation would run in Formalize
Bring your current control list and evidence, however scattered they are today. We'll show you how owners, policies, and evidence come together in one place before the auditor arrives.
How to prepare for SOC 2 compliance
Most of the effort in SOC 2 happens before the examination starts. A practical sequence looks like this:
Define your scope. Decide which services, systems, and locations the report covers.
Select the Trust Services Criteria. Security is required. Add others based on your services and customer commitments.
Map existing controls against the criteria. If you already work with ISO 27001, much of this mapping is a starting point rather than new work.
Identify and remediate gaps. Close missing or weak controls before the review period begins.
Assign control owners. Every control needs someone responsible for running it and keeping its evidence.
Establish evidence collection and monitoring. For Type 2, evidence has to cover the entire review period, so it needs to be captured as controls run, not reconstructed afterward.
Run a readiness assessment and choose your auditor. A readiness review, internal or with an advisor, shows whether your controls and evidence would hold up in front of an auditor. Only a licensed CPA firm can perform the examination itself.
Maintain controls after the report. A SOC 2 report doesn't formally expire, but buyers generally treat it as current for 12 months after the review period ends. Most organizations therefore renew it every year, so controls and evidence need to keep running between audits.
How long does it take to get SOC 2 compliant?
Two things set the timeline: how mature your controls already are and which report you need. For a first report, these are typical ranges:
Phase | Typical duration | What happens |
|---|---|---|
Readiness and remediation | One to three months, longer if you start from scratch | Scoping, gap assessment, closing gaps, setting up evidence collection |
Type 1 examination | A few weeks to two months | The auditor assesses control design at a specific date and issues the report |
Type 2 review period | Three to twelve months | Controls run and evidence is collected across the whole period |
Type 2 fieldwork and report | About one to three months after the period ends | The auditor tests how controls operated and issues the report |
Put together, a first Type 1 report often takes two to five months, and a first Type 2 report six months to a year, or longer if the review period runs a full year. Some CPA firms start testing during the review period, which shortens the wait at the end. From the second report on, the review period usually covers a full 12 months.
How Formalize supports SOC 2 preparation
Formalize doesn't replace your auditor. It organizes the work that leads up to the examination:
Controls with named owners and evidence attached, so you can show how each control ran throughout the review period.
Policies with approvals, versions, and acceptance tracking, supporting the policy-related controls in the security criteria.
Risk, incident, and supplier management in the same system as your controls.
A Trust Center to share your security documentation with customers.
If you also manage ISO 27001, NIS2, or the GDPR, that work can sit alongside your SOC 2 preparation.
Formalize itself is ISO 27001 certified and holds an ISAE 3000 Type 2 report, so we go through the same kind of independent assurance as the teams we support.