SOC 2 Quick-Start

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.

Evidence collection — the analyser owns the binder the CPA firm samples at audit. The audit-period binder (access-review screenshots, change-tickets, MDM reports, the quarterly access-review output, the SIEM retention report) is what the auditor pulls first; map each Trust Service Criterion row to the artifact that satisfies it: Security CC6.1 (logical access) ↔ the access-review output; Availability A1.2 ↔ the uptime SLA report and the incident-response runbook; Confidentiality C1.1 ↔ the data-classification inventory and the signed NDAs for every vendor that touches confidential data; Processing Integrity PI1.1 ↔ the input/output reconciliation report; Privacy P1.1 ↔ the privacy notice backed by the Art. 30 / RoPA-aligned record-of-processing row. A binder keyed to the Common Criteria one row at a time is the most common difference between a Type II with a clean opinion and one with a sampling exception.

Control mapping — pair each Trust Service Criterion row to the controls the organisation already runs, so the Type II attestation is also a control-inheritance story. The artifact: a mapping spreadsheet that names for each CC row the underlying control instance (the TSC ↔ ISO 27001 Annex A marriage, the TSC ↔ HIPAA §164.308–§164.312 overlap, the TSC ↔ PCI Reqs 7/8/10 mapping, the TSC ↔ GDPR Art. 32 technical safeguards), the evidence owner, and the audit-window the sample covers. The mapping is what the auditor opens in the planning call; it is the single document that turns the SOC 2 attestation from a one-off report into a continuous control-running exercise, and a clean mapping is the difference between a Type II with no findings and one with operating-effectiveness exceptions.

Audit support — the point-of-contact role during the auditor walk. The analyst schedules the weekly check-ins with the CPA firm, prepares the evidence-pull queue, routes auditor questions by Trust Service Criterion, and owns the findings log through remediation. A typical Type II run produces a findings list (operating-effectiveness exceptions, sampling exceptions, scope-clarification items, the carve-out disputes over Availability and Confidentiality scope) and the analyst owns pairing each finding with an owner, a remediation date, and a verification step before the report issues. A Type II that closes its findings inside the audit window, with a verification step the CPA firm accepts, lands clean; one that leaves findings open at issue flags the engagement in the next surveillance cycle.

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.