Operational guidance, not legal advice. This page distills named public sources (regulator guidance and industry practice). It is not a legal determination, not a notification decision, and not a substitute for your counsel, insurer, or a retained DFIR firm. Verify applicability and current deadlines for your facts and jurisdiction.
What belongs on a SOC 2 readiness checklist?
Last verifiedGroup readiness work by the common criteria series: governance, communication, risk assessment, monitoring, control activities, access, operations, change management, and vendor risk. For each, know the control, the owner, and the dated evidence it produces. Readiness is your own assessment, never an attestation opinion.
SOC 2 readiness checklist, last verified 10 September 2026 against the AICPA Trust Services Criteria (TSP section 100 — 2017 criteria with the 2022 revised points of focus) and the AICPA attestation standards SSAE 18, AT-C sections 105 and 205. SOC 2 is an attestation examination performed by a licensed CPA firm and delivered as an opinion — a report, not a certification. This page is not legal advice, does not determine that YOU need SOC 2, and does not issue a SOC 2 report.
This is a readiness checklist, not YOUR audit programme
Audience: a compliance owner, CTO, CISO, or engineering lead closing gaps before fieldwork. This checklist is organised by criteria series reference so it maps onto how the examination is structured. It is not the criteria, not an audit programme, and not a determination. Ticking every row here is not readiness, is not an opinion, and is not a SOC 2 report.
The Trust Services Criteria are proprietary AICPA material. This page cites criteria series references — CC1 through CC9 and the optional categories — and paraphrases their subject areas in our own words. It never reproduces the licensed criterion text. Read the criteria from the AICPA source; that text, not this table, is what the CPA firm tests against.
SOC 2 is market and contractual, not statutory: no statute requires a SOC 2 report, and nothing on this list is a legal requirement. Type I addresses the design of controls at a point in time; Type II addresses operating effectiveness over a review period, which is why the evidence column matters more than the control column. "SOC 2 certified" is a misnomer — there is no SOC 2 certificate. Only a licensed CPA firm can perform a SOC 2 examination and issue the report; compliance-automation tooling, including this product, is not the attestor. Last verified 10 September 2026. Not legal advice.
Checklist by criteria series (CC1–CC9)
Each row: the subject area in paraphrase, what to have in place, the evidence a Type II period needs, and the kind of text the row is. Print it, assign owners, and treat the evidence column as the deliverable.
| Series | Have in place | Evidence across a Type II period | Kind of text |
|---|---|---|---|
| CC1 — control environment | Defined security governance: who owns security, board or leadership oversight, background checks where lawful, a code of conduct, role descriptions, and annual security awareness training. | Org chart with dates, signed policy acknowledgements, training completion records per person per period, minutes or a written record of oversight discussions. | Trust Services Criteria reference CC1 — the criteria set the objective; the specific controls are yours to choose. |
| CC2 — communication and information | Published internal security policies people can find, an external commitment (terms, security page, or DPA language), and a channel for reporting security concerns. | Policy version history, acknowledgement records, screenshots or exports of the reporting channel, examples of concerns raised and handled. | Trust Services Criteria reference CC2. |
| CC3 — risk assessment | A documented risk assessment performed at a stated cadence, including fraud consideration and the effect of significant change, with risks rated and owned. | The dated assessment for the period, the risk register with changes over time, evidence that identified risks were treated or accepted by a named person. | Trust Services Criteria reference CC3. |
| CC4 — monitoring | Periodic evaluation that controls are actually operating: internal reviews, control self-assessment, and a route for deficiencies to reach leadership. | Dated review records across the period, deficiency log with remediation dates, evidence of escalation. | Trust Services Criteria reference CC4. |
| CC5 — control activities | Controls selected and documented against the risks identified, including controls over technology, with segregation of duties where feasible. | The control register mapped to risks, evidence each control ran, approval records showing separation between requester and approver. | Trust Services Criteria reference CC5. |
| CC6 — logical and physical access | Single sign-on and strong authentication for in-scope systems, least-privilege roles, documented joiner/mover/leaver process, periodic access reviews, encryption in transit and at rest, and physical or cloud-provider facility controls. | Provisioning and deprovisioning tickets with timestamps, completed access-review records with reviewer names, authentication configuration exports, key and certificate inventory, the cloud provider's own report where facilities are carved out. | Trust Services Criteria reference CC6 — the highest-volume evidence area in most examinations. |
| CC7 — system operations | Logging and monitoring with alerting, vulnerability identification and remediation with target timeframes, an incident-response plan that has been exercised, and defined roles during an incident. | Alert samples and their disposition, scan or dependency findings with remediation dates, incident tickets with timeline and post-incident review, evidence the plan was tested during the period. | Trust Services Criteria reference CC7. |
| CC8 — change management | Changes authorised, reviewed, tested, and approved before release; separation between the person who writes a change and the person who approves it; documented emergency-change path. | Pull requests with independent approval, pipeline records for tests and deployments, change tickets for infrastructure, the complete population of production changes for the period. | Trust Services Criteria reference CC8 — populations here are commonly sampled, so completeness matters. |
| CC9 — risk mitigation | Vendor and business-partner risk assessment before onboarding and at a cadence afterwards, contractual security commitments, and business-disruption planning. | Vendor inventory with tiering, review records per period, subservice organisation reports obtained and read, continuity or recovery test records. | Trust Services Criteria reference CC9. |
| Optional categories | Only if a customer requires them: Availability (capacity, backup, recovery), Confidentiality (lifecycle handling and disposal), Processing Integrity (completeness and accuracy of processing), Privacy (handling personal information against your own notice). | Recovery test results, retention and disposal records, reconciliation or exception-handling records, consent and notice records — whichever category is in scope. | Trust Services Criteria reference — optional categories. Adding one because it sounds thorough is a cost decision, not a requirement. |
Cross-cutting rows that are not criteria
These matter to whether the examination goes smoothly, and none of them is required by an attestation standard. Labelled honestly so nobody presents them to an auditor as obligations.
- A one-page system description draft covering services, infrastructure, software, people, procedures, and data. Attestation-standard requirement that a description exist and be fair; drafting it early is best practice.
- A single evidence location with dates attached to artefacts, rather than screenshots in chat threads. Best practice.
- One named accountable human for the examination, with time allocated. SRM recommendation.
- A dry run of the likely request list before fieldwork, to find missing populations while they can still be produced. Best practice.
- Policies that describe what you actually do. A policy that promises quarterly reviews you do not perform manufactures its own exception. Best practice with real consequences.
- A decision on subservice organisations — carve-in or carve-out — and the provider reports you will rely on. Attestation-standard requirement that the description address them.
- Vendor and tooling choices, including this product. SRM recommendation, never a requirement, and not the attestor.
Kinds of text on this page
Different sentences here carry different weight. The table labels which is which, so no checklist row gets presented to an auditor as an obligation it is not.
| Kind of text | What it means | What it is not |
|---|---|---|
| Attestation-standard requirement | SSAE 18 — AT-C sections 105 and 205 — governs how the CPA firm plans, performs, and reports the examination. | Not a statute, and it binds the practitioner rather than you. |
| Trust Services Criteria reference | A pointer to a criteria series (CC1–CC9 or an optional category) in TSP section 100. | Not the criterion text. The Trust Services Criteria are proprietary AICPA material; every description here is paraphrase. |
| Best practice | What experienced practitioners commonly do to reach fieldwork without a scramble. | Not required by any attestation standard. Skipping it is not an exception. |
| Market observation | What buyers, contracts, and firms are commonly observed to do. | Not a rule, not a quote, and not a promise about YOUR deal, timeline, or price. |
| SRM recommendation | Something this product suggests doing. | Not a legal requirement, not an attestation requirement, and not an audit opinion. |
What to do now
Work the list in this order. Evidence beats controls: a control nobody can evidence is, to an examination, a control that did not run.
- Print the CC1–CC9 table and put a named owner and a date against every row. Rows without owners are the rows that fail.
- For each row, answer the evidence question first: what dated artefact proves this ran, and where does it live?
- Fix CC6 and CC8 before anything else. Access and change management generate the largest populations and the most exceptions.
- Read your existing policies against what you actually do, and change whichever is wrong. Do not leave a promise you do not keep.
- Confirm which subservice organisations you rely on and obtain their reports. Reading them is best practice; relying on them without reading is how a complementary control gets missed.
- Do a dry run of the request list, then close the gaps it exposes, then book fieldwork.
- Do not treat this page — or a green readiness view in any tool — as an opinion. Only a licensed CPA firm can issue one.
Checklist
The compressed version, for a status meeting. Labels carried through from the tables above.
- Every CC1–CC9 row has an owner, a control, and a named evidence source. Trust Services Criteria reference.
- Access provisioning, deprovisioning, and periodic reviews produce dated records. Trust Services Criteria reference CC6.
- Every production change has independent approval and the population is complete. Trust Services Criteria reference CC8.
- Vulnerability findings have remediation dates and someone reviews the backlog. Trust Services Criteria reference CC7.
- Vendor reviews happened during the period, not before it. Trust Services Criteria reference CC9.
- System description drafted and boundary agreed. Attestation-standard requirement.
- Evidence lives in one dated place, not in screenshots in chat. Best practice.
- Named accountable owner with time allocated. SRM recommendation.
- Nobody is calling readiness an opinion, or the future report a certification. Best practice — the misnomer costs credibility.
Where this shows up in ShipReady Metrics
The bundled framework key soc2 is customer-visible, labelled against the 2017 Trust Services Criteria with the 2022 revised points of focus. Its control-set is a starter subset — an illustrative readiness mapping to be tailored by a compliance owner, not the criteria and not an audit programme. This page is not a product checklist UI: ticking a row here does not tick a control in the app.
If you already have a session: evidence collection gathers the artefacts named in the evidence column, and evidence review with the met-verdict overlay records a named human's judgement that an item supports a control — which is a judgement, not an opinion. The 24-framework crosswalk maps SOC 2 to this product's canonical controls by criteria series reference only and never reproduces Trust Services Criteria text; mapped coverage is not a count of criteria met. The policies library holds the documents this list usually reveals are missing. Connector-sourced evidence — dependency, code-scanning, and secret-scanning ingest — feeds the CC7 and CC8 rows. The cyber risk register under the security area supports the CC3 and CC4 rows. ShipReady Passport and the auditor share token hand a reviewer a scoped view.
Readiness in this product is not an attestation opinion. This product does not issue a SOC 2 report and does not replace a licensed CPA examination. There is no public SOC 2 demo URL. The SOC 2 readiness checklist template on this site is the printable companion to this page.
Primary sources (last verified 10 September 2026)
Criteria series references come from the AICPA source below. Everything describing them here is paraphrase, because the criterion text is licensed.
AICPA Trust Services Criteria, TSP section 100 — 2017 Trust Services Criteria with the 2022 revised points of focus, organised into the common criteria series CC1 through CC9 plus the Availability, Confidentiality, Processing Integrity, and Privacy categories. Proprietary AICPA material: cited by reference and paraphrased, never reproduced. AICPA attestation standards SSAE 18, AT-C sections 105 and 205. AICPA SOC 2 guidance for service organisations. These are not a complete list, and none of them is legal advice.
The SOC 2 framework guide on this site is the education page under frameworks; this cluster does not reuse that slug. The SOC 2 readiness checklist template on this site is live. The SOC 2 versus ISO 27001 comparison on this site is live. A dedicated ISO 27001 docs cluster is not on this site yet — naming ISO 27001 in prose is not a link to it.