What is the first step in SOC 2?

Confirm exactly what your customer needs: Type 1 or Type 2, which Trust Services categories and by what date. That answer sets your scope, timeline and budget. Starting with policies or tools before you know the target is the most common way founders waste the first month of a SOC 2 project.

Do we need a penetration test for SOC 2?

The Trust Services Criteria do not name a mandatory penetration test, but they expect you to evaluate whether controls work and to find vulnerabilities. In practice, most auditors and enterprise buyers expect an annual external penetration test on the in-scope product. Plan for one and track the findings to closure.

How many controls does a SOC 2 audit test?

It depends on your scope and design. The criteria are fixed, but each company chooses its own controls to meet them, so a small Security-only scope might have far fewer controls than a larger company adding Availability and Confidentiality. Your control matrix, agreed with your auditor, defines the final list.

Can we do a SOC 2 readiness assessment ourselves?

Yes. A self-assessment against the criteria is a sound first step and costs only time. Score each criterion, record evidence you already have and assign owners to gaps. Some CPA firms also offer formal readiness assessments; if you use the same firm for the audit, check how they manage independence.

What evidence do SOC 2 auditors ask for?

Expect requests for approved policies, the risk assessment, vendor reviews, user access lists and review records, onboarding and offboarding tickets, training completions, change and pull request history, vulnerability scans, incident records and backup restore tests. For Type 2, they sample these across the whole period.

SOC 2 Checklist: 12 Steps From Zero to Audit-Ready

September 29, 2026 ISO Cloud Consulting editorial team

A SOC 2 checklist turns a vague requirement into 12 ordered steps: confirm the need, set scope, assign an owner, find gaps, assess risk, review vendors, adopt policies, fix technical and people controls, build a control matrix, draft the system description and engage a CPA firm. Work them in order and you avoid expensive rework.

Key facts

SOC 2 is an attestation report by a licensed CPA firm, measured against 61 Trust Services Criteria.
Security (33 common criteria, CC1 to CC9) is always in scope.
Type 1 tests design on one date; Type 2 tests operation over a period, commonly 3 to 12 months.
Readiness for a small cloud-based team often takes around three months with a committed owner.

What are the 12 steps to get SOC 2 audit-ready?

The 12 steps run from scoping to auditor engagement. Each produces a concrete output the auditor will later ask to see.

Step	Output	Main criteria
1. Confirm the need	Report type, categories and deadline in writing	n/a
2. Set scope	Scope statement: product, systems, people, locations	All
3. Assign ownership	Named owner and working group	CC1.3
4. Assess gaps	Scored gap list with fix owners	All
5. Assess risk	Risk register with treatments	CC3.1 to CC3.4
6. Review vendors	Vendor inventory and review records	CC9.2
7. Adopt policies	Approved, acknowledged policy set	CC1, CC2, CC5
8. Technical controls	Configurations and tool evidence	CC6, CC7, CC8
9. People controls	Training, checks, onboarding and offboarding records	CC1.4, CC6.2
10. Control matrix and calendar	Controls, owners, frequencies, evidence locations	CC4, CC5
11. System description and dry run	Draft description, mock audit findings	Description criteria
12. Engage the auditor	Signed engagement, audit date or period	n/a

1. Confirm who needs SOC 2 and which report

Ask the customer who raised it what they accept: Type 1 or Type 2, which categories and by when. Some will accept a Type 1 now with a commitment to Type 2. Good looks like a written answer you can plan against, not a guess.

2. Define your scope

Scope is the product, infrastructure, software, people, data and locations the report covers. Keep it tight: one production environment and the teams that touch it. Write the scope down in a paragraph; it becomes the opening of your system description. Add optional categories only when customers need them. Scope creep is the most expensive mistake in SOC 2, because every addition adds controls to run and evidence to keep.

3. Name an owner and a small working group

One person owns the program and has time to chase evidence. Typically that is a CTO, head of engineering or operations lead, supported by someone from HR and one engineer. Auditors look for clear responsibility (CC1.3), and projects without an owner stall.

4. Run a gap assessment

Compare what you do today against every criterion in scope and score each as met, partly met or not met. Record who will fix each gap and by when. Our SOC 2 Readiness Assessment & Control Matrix ($59) is built for this, or start with the free readiness checklist.

5. Assess your risks

List what could realistically go wrong: stolen credentials, a bad deploy, a vendor breach, a key person leaving, fraud. Score likelihood and impact, pick a treatment and link each risk to the controls that address it. The criteria expect a documented assessment that you repeat at least annually and when significant changes occur (CC3.1 to CC3.4).

6. Inventory and review your vendors

List every vendor that touches customer data or your production systems. Rate them by risk, collect SOC 2 reports from the critical ones and read the controls those reports expect you to run. Your cloud provider is usually treated as a "subservice organization" and carved out of your report, which means you rely on its report and must show you reviewed it (CC9.2).

7. Write, approve and publish policies

Adopt a policy set covering security governance, access, change, incidents, vendors, risk, HR, continuity and more. Tailor frequencies you can actually meet, get formal approval and collect staff acknowledgments. See our SOC 2 policy templates for a mapped set of 20.

8. Implement technical controls

Most exceptions start here. Close the common gaps:

Single sign-on and MFA on every system in scope.
Managed, encrypted laptops with screen lock and endpoint protection.
Protected main branches: peer review and passing tests before merge (CC8.1).
Centralized logging with alerts that someone actually reviews (CC7.2).
Vulnerability scanning with fix deadlines by severity, plus an annual penetration test most buyers expect.
Encryption at rest and in transit, and backups with a tested restore.

9. Implement people controls

Background checks as your policy defines, confidentiality terms in contracts, security training at hire and annually, and onboarding and offboarding checklists. Offboarding deserves special care: access removed days after someone leaves is a classic exception.

10. Build a control matrix and an evidence calendar

List every control with its owner, frequency, criteria IDs and where evidence lives. Then turn the frequencies into a calendar: quarterly access reviews, monthly vulnerability review, annual risk assessment, restore tests. For a Type 2, this calendar is what keeps you exception-free across the period (CC4.1).

11. Draft the system description and run a dry run

Write the system description, following the AICPA SOC 2 description criteria: services, boundaries, infrastructure, data flows, people, key processes, subservice organizations and the controls you expect customers to run. Then pull a sample of evidence for each control as an auditor would. Fix what you cannot produce.

12. Engage the CPA firm and set the date

Choose a licensed CPA firm enrolled in AICPA peer review with experience of companies like yours. Agree scope, categories, the Type 1 date or Type 2 period, evidence formats and timeline. Start these conversations around step 7, because audit calendars fill.

How long does each phase of the SOC 2 checklist take?

For a small, cloud-based team with a committed owner, the 12 steps often fit into about 90 days. Steps overlap; the order matters more than the exact dates.

Weeks 1 to 2 (steps 1 to 4): confirm the requirement, fix scope, name the owner and finish the gap assessment.
Weeks 2 to 5 (steps 5 to 7): complete the risk register and vendor reviews, then tailor and approve policies.
Weeks 4 to 10 (steps 8 to 9): close technical and people gaps. This is usually the longest phase.
Weeks 9 to 12 (steps 10 to 12): build the control matrix, draft the system description, run the dry run and lock in the auditor.

If your gap assessment shows many "not met" scores in access or change management, add time to the middle phase rather than squeezing it. Rushed technical fixes tend to become Type 2 exceptions later.

Who does the work in a small company?

SOC 2 is a team effort with one owner. In a company of 10 to 50 people, the work usually splits like this:

Owner (CTO, head of engineering or operations lead): scope, control matrix, evidence calendar, auditor contact.
Engineering lead: technical controls, change management, vulnerability fixes and the architecture parts of the system description.
HR or people lead: background checks, training records, policy acknowledgments, onboarding and offboarding.
CEO or leadership team: policy approval, annual risk review and signing management's assertion.

How do you know you are audit-ready?

You are audit-ready when every in-scope control has an owner, has run at least once and has evidence you can produce within a day. If you still describe controls in the future tense, you are not ready.

Policies approved, dated and acknowledged by all staff.
Risk register and vendor reviews completed within the last 12 months.
One full cycle of access reviews, vulnerability triage and a restore test on file.
System description drafted and checked by engineering.
No open high-severity gaps from your assessment.

What are the most common SOC 2 checklist mistakes?

Writing policies first. Without a gap assessment you document an imaginary company.
Starting the Type 2 window early. Controls that were not running on day one show up as exceptions.
Screenshots without dates. Evidence should show when and where it came from.
No backup owner. When the owner goes on leave, recurring controls lapse.
Buying tools before scoping. Software bought for systems that turn out to be out of scope is money spent twice.

Templates help you prepare faster; they do not replace running controls or the CPA firm's examination. For context on each step, see the SOC 2 guide.

Last reviewed: 29 September 2026

Back to blog

Item added to your cart