Audit
Intermediate

SOC 2 Quick-Start

A beginner-friendly walk of SOC 2 — the five Trust Service Criteria, the audit lifecycle (readiness → Type 1 → Type 2), the difference between a Type I and Type II report, and two real analyst briefs that show the report firing in a vendor intake and a customer questionnaire.

Last updated:

Pair this primer with the full course: Full /courses/soc-2 walk →

The five Trust Service Criteria

  • Security (the "Common Criteria") — the only criterion mandatory in every SOC 2; covers logical access (CC6.1), system operations (CC7.1), change management (CC8.1), and the baseline of controls every other criterion inherits from.
  • Availability — the system stays up to its stated commitment. Look here for capacity planning, incident response, disaster recovery, and the uptime SLA your customers actually read.
  • Processing Integrity — the system does what it claims, end to end: input is captured, processing is complete, output is accurate, and errors are surfaced. The criterion a fintech or an order-fulfillment platform gets asked about.
  • Confidentiality — information marked confidential is protected through its lifecycle. The criterion that protects data the company has agreed (by contract, by classification) to keep confidential beyond the Security baseline.
  • Privacy — personal information is collected, used, retained, disclosed, and disposed of in line with the entity's privacy notice and the AICPA's Generally Accepted Privacy Principles. The criterion closest to GDPR in spirit, scoped to what the company actually does with PII.
  • Note: every SOC 2 includes Security; the other four are optional and selected by the entity based on what their customers and their auditors actually need to see attested.

The audit lifecycle

  • Readiness assessment — a gap analysis and remediation stretch that runs before any auditor looks. You walk the selected Trust Service Criteria, score each Common Criteria row against your actual control, remediate the gaps, and produce the controls-evidence binder the auditor will sample from. No opinion is issued yet.
  • Type 1 report — a point-in-time attestation that your controls are designed appropriately as of a stated date. The auditor describes the system, the criteria selected, and the controls in place; the report covers design only, not whether the controls actually worked over a window.
  • Type 2 report — a window-of-operation attestation that your controls operated effectively over a stated period, typically six to twelve months. The auditor tests a sample of controls, traces evidence, and reports an opinion on operating effectiveness in addition to design. This is the report enterprise procurement actually asks for.

Type I vs Type II

A SOC 2 Type I asks a single question: "Are your controls designed appropriately at a point in time?" The auditor reads the system description, walks the selected Trust Service Criteria against the Common Criteria, and writes an opinion on design only. A Type I can usually be produced inside about six weeks of controls being stable, costs roughly one third to one half of a Type II, and is the right artifact for early-customer trust pages and for sales cycles that ask "are you SOC 2?" but do not yet demand the operating-effectiveness evidence.

A SOC 2 Type II asks the harder question: "Did your controls actually operate effectively over a window?" The auditor describes the system, then tests a sample of controls over the audit period — typically six months minimum, twelve months for the cleanest opinion — and reports on operating effectiveness in addition to design. A Type II is slower, more expensive, and the artifact enterprise procurement teams demand for any vendor that holds regulated data, integrates with the production stack, or processes more than a defined threshold of customer records.

Both reports use the same five Trust Service Criteria selection; the difference is the period the auditor covers and the depth of evidence required. A common path is a Type I in year one to clear the trust-page objection and qualify for enterprise pipeline, then a Type II covering the next twelve months once the controls have actually been run long enough to produce a defensible opinion.

Two beginner briefs — vendor due-diligence intake and customer questionnaire response

  • WovenCart (D2C apparel on Shopify Plus, PCI scope in the marketing tooling that touches cardholder data) handling a customer questionnaire response: a global enterprise prospect sends a 200-row security questionnaire ahead of a multi-year contract. The analyst's job is to map each questionnaire row to the relevant Trust Service Criterion (CC6.1 logical access ↔ the row that asks "do you enforce MFA on all production access?", A1.2 availability ↔ the row that asks for incident-response runbooks), attach the SOC 2 report excerpt that covers each criterion, and route only the genuinely unscoped questions back to engineering. The concrete artifact is the populated questionnaire plus a one-page cover letter mapping each customer row ID to the TSC number that answers it.
  • Atlas Health Partners (regional integrated delivery network, post-merger HITRUST foundation that is evaluating a new clinical-decision-support SaaS for the cardiology group) handling a vendor due-diligence intake: procurement sends the vendor's security review packet ahead of a pilot. The analyst's job is to intake the vendor's SOC 2 Type II report, map the relevant Trust Service Criteria to the HITRUST inheritance map already in use across the delivery network, flag any unmapped or partial criterion in Availability and Confidentiality (because clinical-workflow uptime and PHI handling inherit directly here), and produce a vendor-risk memo that names the gaps the pilot cannot run around. The concrete artifact is the memo plus a gap list cross-referenced to the HITRUST inheritance rows.

Next steps

Once you can name which Trust Service Criterion a brief opens first — and whether the evidence you need is a Type I design opinion or a Type II operating-effectiveness opinion — you are no longer reading SOC 2 as a five-letter acronym; you are reading it the way the auditor and the procurement team read it. The next concrete move is to score a real environment against the SOC 2 criteria on a 0–3 maturity scale and read the gap scoring for the criterion the brief actually targets.

When you are ready to read the matching course, the full /courses/soc-2 walk covers the Common Criteria row-by-row and the criterion selection logic for both Type I and Type II engagements. The Gap Analysis lab below accepts SOC 2 directly on its free sub-form, so a free visitor can run the lab against the SOC 2 criteria and read the gap scoring with no payment required. Until then, the laminate for SOC 2 is: name the criterion, name the report type, name the next concrete artifact.

Next
Next: try the Gap Analysis lab

Score a real environment against the SOC 2 Trust Service Criteria on a 0–3 maturity scale and print a Gap Report (per-criterion current vs target, average maturity, and a remediation list sorted lowest first). SOC 2 is selectable directly from the lab's free sub-form — no payment required to walk the criteria and read the gap scoring.

Open the Gap Analysis lab →