SOC 2 (AICPA): what it is, Type I vs Type II and compliance

The short answer: SOC 2 is an attestation, not a certification. It is issued by an independent auditor (a CPA, the US equivalent of a statutory auditor) who examines your controls against the Trust Services Criteria defined by the AICPA. The result is a report, not a stamp. It matters most to SaaS companies selling in the United States, where customers ask for it before they sign.

What SOC 2 is, in plain terms

SOC stands for System and Organization Controls. SOC 2 comes from the AICPA (the American Institute of Certified Public Accountants) and belongs to the world of assurance: an independent third-party professional checks your statements about your controls and puts them in writing in a report. This is the cultural difference with Europe: you don't get a certificate to hang on the wall, you get a document signed by an auditor stating whether your controls hold up.

The report is designed to be shared with your customers and their auditors. In practice it answers a question every US company asks its software vendors: "if I give you my data, how do you handle it and who vouches for that?".

That is why, when a customer asks whether you are SOC 2 compliant, they are really asking to see a recent SOC 2 report: compliance isn't proven with a certificate, it is proven with the report. SOC 2 also has two sibling reports that the AICPA keeps separate. SOC 1 covers a vendor's controls that affect its customers' internal control over financial reporting. SOC 3 uses the same Trust Services Criteria as SOC 2, but in a general-use report designed to be distributed freely. For a software vendor, what customers ask for is almost always SOC 2.

What it is based on: the Trust Services Criteria

SOC 2 measures controls against five categories, the Trust Services Criteria. One is mandatory; you include the other four only if they are relevant to the service you provide. The criteria are set by the AICPA's Assurance Services Executive Committee (ASEC), and the reference version is the 2017 one, with the points of focus revised in 2022:

• Security: the foundation, always included. It covers access control to systems and data and the prevention of unauthorised access.
• Availability: the service is accessible and operational as promised, useful if you have uptime commitments.
• Processing integrity: data is processed completely, accurately and on time.
• Confidentiality: information classified as confidential is treated as such.
• Privacy: personal data is collected, used and retained according to stated criteria.

Choosing which criteria to include is not a formality: it defines the breadth of the examination and therefore the effort. Most SaaS companies start with Security, adding Availability and Confidentiality when a contract requires them.

SOC 2 Type I and Type II: what each one attests and which you need

This is the distinction that causes the most confusion. The two reports look at the same Trust Services Criteria and the same system description: what changes is the time horizon, and with it what the auditor can state.

• SOC 2 Type I attests, as of a specific date, that the system description is accurate and that the controls are suitably designed to meet the criteria. It is a snapshot: it says the controls exist and are well designed, not that they have worked.
• SOC 2 Type II attests the same things over a period and adds operating effectiveness: the auditor tests the controls across the period and reports the tests performed and the results, exceptions included. It says the controls worked over time, not just on the day of the examination.

The observation period. In Type II, this is the window over which the auditor collects evidence. There is no single number: the length is agreed with the auditor based on what customers ask for, and in market practice it usually runs from 3 to 12 months. The report only arrives after the period ends, which is why a Type II has to be planned ahead and can't be squeezed in at the last minute.

Which one you need. Type I makes sense when a customer wants an early signal quickly, when controls have only just been put in place or when the system has changed recently. Type II is what structured procurement teams normally ask for, because it is the only one of the two that proves continuity. The typical path has two steps: Type I first so deals don't stall, then Type II at the end of the observation period. Companies with mature controls can also go straight to Type II. Before choosing, the question to ask your customer is simple: which one do they accept.

Who really needs SOC 2

If we had to describe a typical profile: a SaaS company or cloud service provider selling to US customers. In the US, SOC 2 is effectively the implicit standard for vendor assessments: when a company evaluates a new software vendor, the SOC 2 report is almost always among the documents requested.

The sign that the time has come is almost always commercial, not technical: a major deal stalls because the customer's procurement team asks for the report and you don't have it. From that moment SOC 2 stops being a "sooner or later" topic and becomes a requirement for closing contracts.

How you get it: the path in practice

Simplifying, the path has a few recurring steps:

1. Define the scope. Which systems and services you cover and which Trust Services Criteria you include. Getting this wrong inflates the work for no reason.
2. Run a gap analysis. You compare the controls you have with the ones expected and see what is missing. It is the map of the work ahead.
3. Close the gaps and implement the controls. Policies, access management, logging, vendor management, incident response and so on.
4. Collect the evidence. The auditor won't take your word for it: they want evidence that the controls operate. This is the most tedious and longest part, especially for Type II.
5. The auditor's examination. An independent CPA conducts the examination and produces the report. For Type II, they observe an entire period.

On timing: Type I wraps up in weeks or a few months, while Type II additionally requires the observation period set by the auditor. The variable that moves the calendar the most is evidence collection, and that is exactly where automation comes in.

The role of compliance automation

The bottleneck in SOC 2 is rarely "figuring out what to do". It is keeping dozens of controls together and continuously producing the evidence that they work: screenshots, logs, configurations, access lists, training records. Doing it by hand, in a spreadsheet, is where projects get bogged down.

Compliance automation tools such as Vanta connect to the systems you already use (cloud, identity management, HR, ticketing) and collect evidence continuously, flagging when a control drifts out of bounds. The result isn't "SOC 2 for free", but a shorter, repeatable path, with less manual work and fewer surprises during the examination.

What's inside the report (and what customers look at)

It is worth knowing what the end product looks like, because it is what will land on your customer's procurement desk. A SOC 2 report isn't a one-page document with a stamp: it is a detailed document that typically contains:

• The auditor's opinion: the CPA's conclusion, the part customers read first.
• Management's assertion: the company's statements about its own systems and controls.
• The system description: what the service does, where its boundaries are and which controls are in place.
• Tests and results: in Type II, the list of controls tested, how they were tested and the outcome, including any exceptions.

Exceptions deserve a note: a report can contain findings without being "failed". What matters to the customer is understanding how significant they are and how they were handled. Knowing this helps you treat the examination not as an all-or-nothing test, but as an honest snapshot of your controls.

SOC 2 and ISO 27001: how they relate

One last recurring question: if I have ISO 27001, do I also need SOC 2, or vice versa? They are two different things with a strong overlap. ISO 27001 is an international certification of an information security management system, widely requested in Europe. SOC 2 is a US attestation on specific controls, widely requested in the United States. Many of the underlying controls are the same, so anyone tackling both reuses much of the work.

The choice depends on your customers: if you sell in Europe you often start with ISO 27001, if you sell in the United States with SOC 2, and if you do both it makes sense to plan them in parallel. When you decide to start on SOC 2, our SOC 2 services take you from scope to report.

In short: SOC 2 is an attestation that shows customers, especially American ones, that your controls hold up. Type I captures the design, Type II proves it works over time. The fastest way to get it is to define the scope well and automate evidence collection, so the examination becomes a confirmation rather than a race.