SOC 2 Explained: Trust Services Criteria, Type 1 vs Type 2, and How to Pass Your First Audit

If you sell software to US companies, SOC 2 is the report their security team asks for before signing. Unlike a certificate you can wave around, a SOC 2 is a detailed attestation report — often 40 to 100+ pages — written by an independent CPA firm, describing your controls and the auditor's opinion on them. Your customers read it (or make their auditors read it) to decide whether trusting you with their data is defensible. This guide covers what SOC 2 actually is, the five Trust Services Criteria, the all-important Type 1 versus Type 2 distinction, how an audit runs, what it costs, and how it maps to ISO 27001 and NIST CSF 2.0 so you build once and report many times.

The short version

SOC 2 is defined by the AICPA (the US accounting body) and can only be issued by a licensed CPA firm. It reports against the Trust Services Criteria (TSC): five categories of which only Security is mandatory. There are two report types — Type 1 assesses whether controls are suitably designed at a point in time, and Type 2 assesses whether they operated effectively across a period (typically 3–12 months). Type 2 is what customers actually want. There is no "pass/fail" and no certificate; the deliverable is a report with the auditor's opinion, which you share under NDA. Because the underlying controls are ordinary security practices, a SOC 2 programme reuses most of the work behind ISO 27001 and NIST CSF.

SOC 1 vs SOC 2 vs SOC 3 — get the family right first

The "SOC" name covers three different reports, and conflating them wastes time on sales calls:

• SOC 1 — controls relevant to a customer's financial reporting (e.g. a payroll processor). Not a security report.
• SOC 2 — controls relevant to security, availability, processing integrity, confidentiality and privacy. This is the one security teams request. It is a restricted-use report, shared under NDA.
• SOC 3 — a short, general-use summary of a SOC 2 that you can publish on your website as a trust marker, without the sensitive detail.

When someone says "send us your SOC report," they almost always mean a SOC 2 Type 2.

The five Trust Services Criteria

SOC 2 is built on five TSC categories. You choose which apply to your service — but Security is always in scope.

Most first SOC 2 reports scope Security only, or Security + Availability + Confidentiality. Adding criteria adds controls and audit effort, so include a category only when a customer commitment or a real risk justifies it. You can always expand scope in a later report.

The Common Criteria and its COSO backbone

The Security category is called the Common Criteria (CC) because the other four build on it. The CC is organised into nine series (CC1–CC9) that mirror the COSO internal-control framework:

• CC1 — Control Environment (governance, integrity, org structure, accountability)
• CC2 — Communication and Information (internal and external communication of security)
• CC3 — Risk Assessment (identifying and analysing risks to objectives)
• CC4 — Monitoring Activities (evaluating whether controls work)
• CC5 — Control Activities (the policies and procedures that mitigate risk)
• CC6 — Logical and Physical Access Controls (the largest series — authentication, authorisation, provisioning, encryption)
• CC7 — System Operations (detecting and responding to incidents and anomalies)
• CC8 — Change Management (controlling changes to infrastructure and code)
• CC9 — Risk Mitigation (vendor risk and business disruption)

The current criteria are the 2017 TSC, revised in 2022 (updated points of focus). Unlike ISO 27001's fixed Annex A list, SOC 2 does not prescribe specific controls — you design controls that meet each criterion, and the auditor judges whether they do. That flexibility is a double-edged sword: it fits any architecture, but it means there is no checklist to copy. CC9's vendor-risk requirements are where a structured third-party risk management process and a vendor risk assessment tool earn their keep.

Type 1 vs Type 2: the distinction that matters most

This is the single most important choice in SOC 2, and customers know the difference.

• Type 1 answers: are the controls suitably designed as of a specific date? It is a point-in-time snapshot — a photograph. It is faster and cheaper, and useful as a first milestone or to unblock a deal quickly, but it proves nothing about whether controls actually run day to day.
• Type 2 answers: did the controls operate effectively throughout a period? — usually three to twelve months. It is a video, not a photo, and it is what enterprise customers require, because it demonstrates the controls work continuously, not just on audit day.

The common path is to lead with a Type 1 to establish design, then run a Type 2 over the following observation window. Many mature companies skip straight to Type 2. Whichever you choose, the controls must be operating before the window starts — you cannot retroactively create evidence for a period that has already passed, and auditors sample throughout the window.

How a SOC 2 audit runs

The engagement follows a predictable arc:

• Readiness assessment (optional but wise). A gap analysis — often with your future auditor or a separate advisor — that maps your current controls to the TSC and lists what to fix before the real audit. It is the SOC 2 equivalent of ISO's Stage 1.
• Remediation. Close the gaps: turn on MFA everywhere, formalise change management, implement logging and alerting, write the missing policies, stand up access reviews.
• Observation window (Type 2). The controls run for the chosen period while you accumulate evidence — tickets, logs, review records, onboarding/offboarding trails.
• Fieldwork. The CPA firm requests evidence, samples it, interviews control owners, and tests operating effectiveness across the window.
• The report. The auditor issues the SOC 2 with an opinion: unqualified (clean), qualified (some controls fell short), adverse (pervasive failures), or a disclaimer. Any exceptions — instances where a control did not operate as described — are listed with management's response. A report with a few well-explained exceptions is normal and still useful; customers read the detail.

What it costs and how long it takes

A first SOC 2 typically takes three to nine months from kickoff: a few weeks to a couple of months of readiness and remediation, then the Type 2 observation window (a first report often uses a shorter 3-month window to get to market, later reports a 6- or 12-month one). Costs fall into three buckets: the CPA firm's fee (commonly mid five figures for an SMB Type 2, scaling with scope and criteria), compliance-automation tooling if you use a platform to collect evidence, and internal time plus remediation spend. Because SOC 2 renews annually — customers expect a current report each year — treat it as an ongoing programme, not a one-off.

The evidence auditors sample

SOC 2 fieldwork is evidence-hungry, and Type 2 especially so because the auditor tests operation over time. Expect requests for: a current system description; policies (information security, access control, change management, incident response, vendor management, risk assessment); user access listings and periodic access-review records; onboarding and offboarding tickets proving joiners/leavers were provisioned and deprovisioned; change-management tickets linking code changes to approvals; monitoring and alerting configuration and sample alerts; incident records; backup and (ideally) restore-test evidence; vendor risk assessments; and risk-assessment output. The recurring theme is the same as ISO 27001: a control the auditor cannot see evidence for is a control that does not exist. Teams whose operations already produce timestamped, exportable records — for example via scripted admin, as in our PowerShell for Microsoft 365 guide — spend far less time scrambling for artefacts.

SOC 2 vs ISO 27001 vs NIST CSF

All three assess broadly the same security practices in different packaging:

• SOC 2 — a US CPA attestation report you share with customers under NDA. Flexible controls, judged against the TSC. No certificate; renewed annually. Dominant among US SaaS.
• ISO 27001 — an internationally recognised certification against a management-system standard, with a fixed Annex A control set. A pass/fail badge on a three-year cycle. See the ISO 27001 guide.
• NIST CSF 2.0 — a voluntary framework for organising and communicating cyber-risk, with no audit or certificate. Often the shared vocabulary underneath. See the NIST CSF 2.0 guide.

The practical consequence: the access reviews, change management, logging, and vendor assessments that satisfy SOC 2's Common Criteria are the same practices that satisfy ISO 27001's Annex A and NIST CSF's subcategories. Map one control set to all three with our Control Mapper and a risk register, and the second and third frameworks cost a fraction of the first.

The mistakes that sink a first audit

• Over-scoping the criteria. Adding Privacy or Processing Integrity "to be safe" multiplies controls and effort. Scope Security first, add categories only when a real commitment demands it.
• Starting the Type 2 window before controls run. You cannot manufacture evidence for a period after the fact. Get controls operating, then start the clock.
• Writing policies no one follows. SOC 2 tests whether described controls actually operate. A change-management policy contradicted by how engineering really ships is an exception waiting to be found.
• Ignoring offboarding. Departed-employee access that lingers is one of the most commonly sampled — and commonly failed — controls. Automate deprovisioning.
• Treating it as annual theatre. Controls that lapse between audits produce exceptions in the next window. SOC 2 assumes continuous operation.
• Confusing the auditor and the advisor. A CPA firm can advise or attest, but independence rules limit how much hand-holding your actual auditor can provide. Plan for that.

Bottom line

SOC 2 is less about the report and more about the operating discipline it forces: least-privilege access, reviewed regularly; changes that are approved and traceable; monitoring that actually alerts; vendors that are actually assessed. Build those well and the Type 2 report is a by-product. Scope tightly, get controls running before the observation window, and keep them running between audits. Then reuse the same control set for ISO 27001 and NIST CSF 2.0 — because to a customer's security team, the framework name matters far less than the evidence that you run a tight ship.

Frequently asked questions

What is SOC 2 and who issues it?

SOC 2 is an attestation report defined by the AICPA (the American Institute of CPAs) that describes an organisation's controls over security and, optionally, availability, processing integrity, confidentiality and privacy. It can only be issued by a licensed CPA firm, which examines your controls and expresses an opinion. Unlike ISO 27001 there is no certificate — the deliverable is a detailed report you share with customers, usually under NDA, so their security teams can assess whether to trust you with their data.

What are the five Trust Services Criteria?

The five TSC categories are Security, Availability, Processing Integrity, Confidentiality and Privacy. Security — known as the Common Criteria — is mandatory in every SOC 2 report; the other four are optional and included only when relevant to the service. Most first reports cover Security alone or Security plus Availability and Confidentiality. Each category is met through controls you design, since SOC 2 (unlike ISO 27001) does not prescribe a fixed control list.

What is the difference between SOC 2 Type 1 and Type 2?

Type 1 assesses whether controls are suitably designed at a single point in time — a snapshot. Type 2 assesses whether those controls operated effectively over a period, typically three to twelve months — proof they work continuously. Type 2 is what enterprise customers usually require. Many organisations start with a Type 1 to establish control design, then complete a Type 2 over the following observation window; the controls must already be operating before that window begins.

How long does SOC 2 take and what does it cost?

A first SOC 2 typically takes three to nine months: a few weeks to a couple of months of readiness assessment and remediation, followed by the Type 2 observation window (often a shorter three-month period for a first report). Costs include the CPA firm's fee (commonly mid five figures for an SMB Type 2, scaling with scope), optional compliance-automation tooling, and internal time plus any remediation spend. SOC 2 renews annually, so budget for it as an ongoing programme.

Is SOC 2 the same as ISO 27001?

No. SOC 2 is a US CPA attestation report against the AICPA Trust Services Criteria, shared with customers and renewed annually, with flexible controls you design. ISO 27001 is an internationally recognised certification against a management-system standard with a fixed 93-control Annex A, issued by an accredited certification body on a three-year cycle. The underlying security practices overlap heavily, so one control set can support both — but the deliverables, governing bodies and geographies differ.

What does an "exception" in a SOC 2 report mean?

An exception is an instance where a control did not operate as described during the audit period — for example, one terminated user whose access was not revoked within the committed timeframe. Exceptions are listed in the report with management's response. A report can still be useful and is often unqualified overall despite a few well-explained exceptions; customers read the exceptions to judge severity. A clean report with no exceptions is ideal, but a handful of minor, remediated exceptions is normal and expected.