SOC 2 Type II Readiness Checklist

What SOC 2 Type II actually requires

SOC 2 is an attestation, not a certification. A licensed CPA firm issues a report describing the system your organization operates and opining on whether the controls you have asserted were both suitably designed and operating effectively over a defined observation period. Type I captures design at a point in time. Type II captures operating effectiveness over a window, typically six or twelve months. Buyers want Type II because only Type II tells them your controls did work, not merely that they existed on paper.

The work breaks into two parts. First, you document the system description: what the product does, who it serves, where data flows, which subservice organizations you rely on, and which criteria apply to your service commitments. Second, you assert a set of controls, test them yourself, and then hand auditors the evidence they need to re-test a sample. The auditor does not invent controls for you. They evaluate the ones you have selected against the applicable 2017 Trust Services Criteria published by the AICPA (SOC suite of services).

The Security criterion (also called the Common Criteria) is mandatory. The other four (Availability, Processing Integrity, Confidentiality, Privacy) are elective and should be selected based on the service commitments you make to customers. Most early SaaS Type II reports cover Security and Availability. If you handle regulated data or make privacy promises in a marketing page, add Confidentiality or Privacy as needed. If you process transactions or produce reporting that customers rely on, add Processing Integrity.

Type II timelines are real constraints. The observation period cannot start until your controls are operating. If you promise a prospect a Type II report in March and you do not have controls operating until January, the earliest plausible report covers a short window and most sophisticated buyers will ask for a longer one on the next cycle.

The 2017 Trust Services Criteria at a glance

The 2017 TSC replaced the earlier criteria structure and introduced the common criteria model. Nine common-criteria categories (CC1 through CC9) cover governance, communication, risk, monitoring, control activities, access, operations, change, and risk mitigation. Those nine are what Security actually is. Add one or more of the elective categories (Availability, Processing Integrity, Confidentiality, Privacy) if your service commitments require it.

Most teams new to SOC 2 underestimate how integrated the nine common-criteria sections are. CC1 (control environment) and CC2 (communication) set the governance and training baseline without which CC6 (access) and CC8 (change) cannot be demonstrated. CC3 (risk assessment) and CC4 (monitoring) are the glue that tells auditors you have a functioning program rather than a one-time scramble. Skipping the governance layers produces a report with exceptions that buyers notice.

See the AICPA SOC 2 examinations page for authoritative guidance. The list that follows is the operational interpretation we use on engagements. It is not a substitute for the AICPA TSC document, but it is what the document looks like when it meets a real environment.

Security (Common Criteria): CC1 through CC9

The nine common-criteria groups below are mandatory for every SOC 2 Type II examination. Treat them as the floor. For each group the summary describes the intent and the list describes the controls a Type II auditor will expect to test.

Availability, Processing Integrity, Confidentiality, Privacy

The four elective categories apply based on the commitments you make in contracts and marketing. Availability is the most commonly added because SaaS providers publish uptime targets. Confidentiality follows when regulated or sensitive data is handled. Privacy comes in when the service collects personal data in ways that go beyond internal employee records. Processing Integrity applies when customers rely on the accuracy of computed outputs.

Adding a category is not symbolic. It extends the set of controls in scope, the evidence required, and the observation period testing. Scope creep is a real cost, so align the elective categories with the service commitments already in your contracts rather than asserting everything at once.

Evidence expectations: what auditors actually look for

Auditors test controls by sampling. They do not read every change ticket. They pick a handful and verify the evidence matches the asserted control. That means evidence has to be findable, date-stamped, tied to the system of record, and tied to a person. Screenshots are acceptable for discrete items but are the wrong default for anything that happens often. Automated extracts from the source system are the right default.

The most common evidence categories we see tested are user access reviews (CC6.2), change management tickets and PR approvals (CC8), backup restore tests (CC7.6), and incident response tabletop results (CC7.5). Each needs a population list (how many were in scope during the observation window) and a sample (what the auditor picked and what you handed over). Missing a population list is the single most common reason an engagement slips.

Tie evidence to the zero trust architecture decisions you have already made. A ZTNA rollout produces authentication logs that answer CC6 questions without additional instrumentation. A consolidated identity provider collapses dozens of per-application user access reviews into one. Use the audit as a forcing function for architecture improvements rather than treating it as a checkbox exercise.

The 6-month readiness timeline

A six-month path is reasonable if the organization already runs with sound engineering hygiene: code review, branch protection, MFA on SaaS, centralized logging, an identity provider, and a documented on-call rotation. Months one and two are gap assessment and policy drafting. Month three closes high-priority gaps (access review cadence, vendor inventory, incident response plan). Months four through six are the operating window during which controls run and evidence accumulates. The Type II fieldwork happens at the end of month six or early in month seven.

The single most important decision in the six-month path is the observation window. A six-month window is the shortest duration most audit firms will issue a Type II opinion on. Do not start the window before all required controls are demonstrably in operation, because exceptions in the first month of the window are visible in the report.

See our SOC 2 Type II compliance guide for the operational detail on each step. For regulated industries where the audit is consumed by a bank or insurer, see financial services for the additional supervisory expectations layered on top.

The 12-month readiness timeline for less mature organizations

A twelve-month path is the realistic plan when starting points include a flat production environment, no identity provider, manual deploys, no vulnerability management, or no formal policies. In that scenario the first three months are architecture work, not compliance work. Stand up SSO, enforce MFA, consolidate logging, adopt branch protection, and write the policies that describe what the team is now doing. Months four through six close remaining gaps and finish the vendor inventory. Months seven through twelve are the operating window.

The trap in a twelve-month timeline is treating the first three months as documentation rather than engineering. Writing a policy that says the team uses SSO does nothing if SSO is not actually enforced. Write policies that describe the system as implemented, and implement the system before you write the policy. Everything else is a paper exercise.

The second trap is ignoring the incident response maturity required at CC7.5. A Type II auditor will ask for a tabletop exercise that happened inside the observation window. If you schedule the first tabletop in month eleven of a twelve-month window, you have no population to sample and the control is untested.

Common gaps that delay the audit

The same gaps appear on almost every first engagement. User access reviews that are not reliably completed each quarter (and for which the reviewer attestation is not retained). Change management where the tooling supports code review but branch protection is not enforced on production branches. Backups that run but have never been restored under realistic conditions. Vendor inventories that list names but not data sensitivity, not contract owners, and not assessment dates. Incident response plans that were written once and never exercised.

The other recurring gap is service-organization descriptions that do not match reality. The system description in the report is what customers read. If it says you run on AWS in a specific region and you have just migrated to multi-region, the description is stale and the audit has to be reopened. Keep the description aligned with the architecture as it is, not as it was six months ago.

None of these gaps are exotic. All of them are fixable with a few quarters of disciplined execution. The checklist above is the instrument we use to make the execution visible to the team, the auditor, and the buyer who will read the report.