SOC 2 Readiness Checklist

SOC 2 readiness means having your scope defined, your policies written, your controls operating and your evidence collectable before an auditor starts fieldwork. Done in that order, the audit is a confirmation. Done in the other order, the audit becomes a remediation project with a CPA firm watching. This SOC 2 checklist covers the decisions (which report, which criteria, which systems), the controls auditors test most, how evidence collection works in practice, and what a realistic timeline looks like.

One correction up front: there is no such thing as “SOC 2 certification”. SOC 2 is an attestation report issued by a licensed CPA firm; nobody certifies you, and a report is what customers will ask to see. This is general information, not legal advice.

SOC 2 Type 1 versus Type 2

SOC 2 is defined by the AICPA. The auditor evaluates your controls against the Trust Services Criteria: Security (the common criteria, required in every report) plus any of Availability, Processing Integrity, Confidentiality and Privacy that you choose to include. The report comes in two forms.

	Type 1	Type 2
What it tests	Whether controls are suitably designed and in place at a point in time	Whether controls were designed and operated effectively over a period
Observation window	None; a single date	Typically three to twelve months
Evidence	Policies, configurations and a walkthrough on the as-of date	Samples from across the period: tickets, reviews, logs, approvals
What customers think of it	A credible first step; proves intent and design	The standard most procurement teams require; proves operation
Typical use	A young company’s first report, or a bridge while a Type 2 window runs	The annual report for an established service

Most companies go straight to Type 2 and accept a shorter first observation window, or issue a Type 1 while the window runs so that sales has something to show. The readiness work is the same either way; a Type 2 just requires you to keep doing it.

SOC 2 readiness checklist

Scope and decisions

• Define the system: the product or service, the infrastructure, software, people, procedures and data that deliver it. This becomes the system description in the report.
• Choose the criteria. Security is mandatory; add Availability if customers depend on uptime commitments, Confidentiality if you hold their sensitive data, Processing Integrity if you process transactions, Privacy if you handle personal information under privacy commitments.
• Decide the report type and the observation window.
• List subservice organizations (your cloud provider, key SaaS vendors) and decide whether they are carved out of the report or included.
• Draft complementary user entity controls: what your customers must do for your controls to work (for example, manage their own users).
• Name an executive sponsor and a day-to-day owner.

Governance and people (common criteria CC1 to CC5)

• Written policy set approved by leadership: information security, acceptable use, access control, change management, incident response, vendor management, business continuity, data classification. Our guide to IT policies and procedures covers the set.
• Organization chart, role descriptions and a code of conduct; background checks where law allows; confidentiality agreements.
• Security awareness training at hire and annually, with records.
• A documented risk assessment, reviewed at least annually, with a risk register and treatment decisions.
• Management oversight: a periodic security review meeting with minutes, and reporting to leadership or the board.
• Internal communication of policies and of how to report incidents and concerns.

Technical controls (CC6 to CC9)

• Logical access (CC6): single sign-on and MFA; role-based access; documented provisioning and same-day deprovisioning; quarterly access reviews with evidence; encryption of data at rest and in transit; key management; physical access controls or reliance on the cloud provider’s report.
• System operations (CC7): vulnerability scanning on a cadence; patching with defined windows; endpoint protection; centralized logging and alerting; an incident response plan that has been exercised; an incident log.
• Change management (CC8): every production change tracked, reviewed, tested and approved by someone other than the author; separation of environments; emergency change procedure.
• Risk mitigation (CC9): business continuity and disaster recovery plans, tested; vendor risk management with due diligence and contracts; cyber insurance consideration.
• If Availability is in scope: capacity monitoring, backups with tested restores, defined recovery objectives, status communication to customers.
• If Confidentiality is in scope: data classification applied, retention and secure disposal, confidentiality terms in contracts.

Documentation

• System description drafted in the AICPA structure: services, infrastructure, software, people, data, processes, and the controls that address each criterion.
• A control matrix mapping each criterion to your controls, the owner, the frequency and the evidence that proves it.
• Network and architecture diagrams, data-flow diagrams and an asset inventory.
• Vendor list with risk ratings and the SOC 2 reports or equivalents you collected from them.

Readiness assessment and remediation

• A gap assessment against the criteria, performed internally, by a consultant or by the audit firm as a separate engagement.
• Remediation plan with owners and dates; controls must be operating before the observation window opens, not during it.
• Penetration test completed and findings addressed (not required by the criteria, but expected by auditors and customers).

Tooling

• Compliance automation platforms connect to your cloud, identity provider, code repository and HR system, test controls continuously and collect evidence automatically. They reduce the evidence burden substantially for cloud-native companies, and they do not replace the policies, the risk assessment or the people who review alerts.
• Whether or not you use one, you need: a ticketing system for changes and access requests, a central log store, an identity provider, and a document system with version history.

Auditor selection

• Only a licensed CPA firm can issue a SOC 2 report. Ask for the firm’s peer review status and its experience with companies of your size and stack.
• Agree on scope, criteria, window, fieldwork approach (remote or onsite), sample sizes and the timeline in the engagement letter.
• Ask how exceptions are handled and what a bridge letter costs, because you will need one between annual reports.
• Ask how the firm keeps readiness advice separate from the audit itself; auditor independence rules limit what the same firm can design and then attest to.

Evidence: what auditors sample and how to collect it

A Type 2 audit is a sampling exercise. For each control the auditor asks for the population (every change, every new hire, every access review in the window) and picks samples from it. For each sample you produce the artifact: the ticket with its approval, the dated access review, the training record, the restore test log. The readiness work is making sure the population exists and the artifacts are retrievable.

Control	Population	Evidence per sample
Onboarding access	All hires in the window	Access request, approval, account creation date, training completion
Offboarding	All departures in the window	Termination date, access removal date and ticket
Change management	All production changes	Ticket, peer review, test result, approval, deployment record
Access reviews	Each scheduled review	Review export, reviewer sign-off, removals actioned
Vulnerability management	Scan runs and findings	Scan reports, remediation tickets, time to fix
Backups	Scheduled restore tests	Test log, result, sign-off
Incidents	All logged incidents	Incident record, timeline, root cause, actions
Vendor reviews	In-scope vendors	Collected report, review note, contract terms

Three habits make evidence painless: do the work through systems that leave a trail (tickets, not chat messages); timestamp everything, including screenshots; and keep an evidence calendar that says which artifact is produced when and by whom. A control that operates but leaves no trail will be reported as an exception.

Timeline

Durations depend on where you start, so treat these as phases rather than promises.

1. Scoping and readiness assessment. Decide the system, criteria and report type; run the gap assessment.
2. Remediation. Write policies, implement missing controls, set up tooling and evidence collection. This is the phase whose length varies most; a cloud-native company with SSO and a ticketing system already in place moves quickly, a company with shared accounts and no change process does not.
3. Type 1 (optional). An as-of-date report once controls are in place, useful for sales while the window runs.
4. Observation window. Controls operate and evidence accumulates for the agreed period, commonly three to twelve months for a first report.
5. Fieldwork. The auditor requests populations, samples and walkthroughs, raises questions and documents exceptions.
6. Report. Management reviews the draft, the system description is finalized and the report is issued. Then the next window starts, because SOC 2 is annual.

Companies that already run a program on the NIST Cybersecurity Framework usually find the remediation phase short, because the controls exist and only the evidence discipline is new. The same is true in the other direction: a SOC 2 control set is a strong base for ISO 27001 or, for companies adopting AI, the management-system approach of ISO 42001.

Where PS3G fits

PS3G prepares organizations of every size for SOC 2, from a founder whose first large customer has asked for a report to a division that must align its product with a corporate control set. Our SOC 2 readiness service covers scoping, the gap assessment, policy writing, control implementation with your engineers, tooling setup, evidence collection and auditor coordination; we also help select the CPA firm and manage fieldwork. We do not issue the report, and we keep readiness and audit separate so independence is never in question. Where SOC 2 is one of several obligations, our IT compliance consulting builds one control set that serves them all.

Related reading

• ISO 42001 Explained: The AI Management System Standard
• NIST Cybersecurity Framework Explained for Smaller Companies
• IT Policies and Procedures: The 10 Every Company Needs
• SOC 2 readiness and compliance consulting

Frequently asked questions

Is SOC 2 a certification?

No. SOC 2 is an attestation: an independent CPA firm examines your controls and issues a report with its opinion, with no certificate, no registry and no pass or fail mark. A report can contain exceptions and still be useful; what customers read is the opinion, the system description and the list of exceptions. Vendors who advertise “SOC 2 certified” mean they hold a report.

How long does SOC 2 compliance take?

It depends almost entirely on the remediation phase. A company that already has single sign-on, a ticketing system, cloud infrastructure as code and written policies can be ready for an observation window quickly. A company starting from shared accounts and undocumented changes needs longer to put controls in place. Add the observation window for a Type 2, commonly three to twelve months, and the auditor’s fieldwork and reporting.

Which trust services criteria should a SaaS company include?

Security is always included. Availability is the most common addition because customers depend on uptime and it is usually easy to evidence from monitoring and backups. Confidentiality is worth adding if you store customer business data under contractual confidentiality terms, and Processing Integrity matters for payment or transaction systems. Privacy is less common and adds significant obligations, so include it only when customers ask for it.

Can a small company get a SOC 2 report?

Yes. The criteria are the same for every size of company, but the controls scale: a ten-person company’s change management can be a pull request review and a deployment log, and its board oversight can be a quarterly founder review with minutes. Auditors assess whether the control fits the risk, not whether it matches a large company’s process. Scope the system tightly and the effort stays proportionate.

What is the difference between SOC 1, SOC 2 and SOC 3?

SOC 1 covers controls relevant to a customer’s financial reporting, such as a payroll processor’s calculations. SOC 2 covers the trust services criteria for security and related areas and is the report technology service providers are usually asked for. SOC 3 is a short, general-use summary of a SOC 2 that can be published publicly. Most software and IT service companies need SOC 2.