How to Prepare for a SOC 2 Type II Audit: A Step-by-Step Readiness Checklist

If you're asking how to prepare for a SOC 2 Type II audit, the short answer is this: define your scope, run a gap assessment against the AICPA Trust Services Criteria, fix the gaps, then operate your controls consistently and collect evidence throughout an observation period before the auditor ever arrives. Effective SOC 2 Type II prep is less about passing a single test and more about proving that your controls work, repeatedly, over months. The checklist below walks through each step in the order we recommend, with practical examples of how to automate the evidence that auditors will ask for.

What a SOC 2 Type II Audit Actually Tests

A SOC 2 report is an attestation issued by a licensed CPA firm under AICPA standards. The difference between the two report types matters for how you prepare:

• Type I evaluates whether your controls are suitably designed at a single point in time.
• Type II evaluates whether those controls operated effectively across a defined review period.

The criteria come from the AICPA's 2017 Trust Services Criteria (With Revised Points of Focus, 2022). Security, also called the Common Criteria (CC1 through CC9), is mandatory. Availability, Processing Integrity, Confidentiality, and Privacy are optional and should be included only when they reflect commitments you make to customers.

Because Type II is about operating effectiveness, the auditor will pull a population of events (new hires, terminations, production changes, access reviews) and test samples from it. If a control was skipped even a few times during the window, that can surface as an exception in the report. That is why preparation has to start well before the audit.

The SOC 2 Type II Prep Checklist

Step 1: Define Scope and Select Trust Services Criteria

Scope drives cost, effort, and audit duration. Get explicit about:

1. The system boundary. Which products, services, and environments are in scope? Production only, or staging too?
2. Infrastructure and data flows. Cloud accounts, databases, third-party processors, and where customer data lives.
3. People and processes. Which teams operate in-scope systems?
4. Subservice organizations. For cloud providers and other vendors, decide with your auditor whether to use the carve-out method (their controls are excluded and you rely on their own SOC reports) or the inclusive method.
5. Trust Services Criteria. Start with Security. Add others only when customers or contracts require them.

A tight, well-documented boundary is one of the most effective ways to reduce audit burden without weakening your security posture.

Step 2: Run a Gap Assessment

Map your current practices against each applicable criterion. For every criterion, record:

• The control that addresses it (if one exists)
• Who owns it
• How it operates (manual, automated, or hybrid)
• What evidence it produces
• The gap, if any, and a remediation plan

Be honest here. A gap found internally is a backlog item. A gap found by the auditor during the window becomes an exception in the report.

Step 3: Write Policies You Will Actually Follow

Auditors test whether you do what your policies say. Overly ambitious policies create self-inflicted exceptions. A typical baseline set includes:

• Information security policy
• Access control policy
• Change management policy
• Incident response plan (NIST SP 800-61 is a useful reference)
• Business continuity and disaster recovery plan
• Vendor management policy
• Data classification and retention policy
• Acceptable use policy

Rule of thumb: if a policy says "quarterly," make sure a calendar reminder, a named owner, and a ticket template already exist before the window starts.

Step 4: Implement and Harden Core Controls

Most Common Criteria findings cluster around a few control families. Prioritize these:

• Access management: SSO with MFA, role-based access, documented onboarding and offboarding, and periodic user access reviews.
• Change management: peer-reviewed pull requests, protected branches, CI checks, and a traceable link between changes and tickets.
• Logging and monitoring: centralized logs, alerting on security-relevant events, and defined retention.
• Vulnerability management: scheduled scanning, remediation SLAs by severity, and periodic penetration testing.
• Vendor risk: an inventory of vendors, risk tiers, and annual review of critical vendors' SOC reports.
• HR security: background checks where lawful, security awareness training, and signed acknowledgments of policies.
• Backups and recovery: automated backups plus documented, tested restores.

Step 5: Build a Control Matrix Mapped to Evidence

A control matrix is the backbone of your audit. We recommend keeping it as structured data in version control rather than in a spreadsheet that drifts. Here is a simple example format:

controls:
  - id: AC-04
    title: Quarterly user access review
    criteria: [CC6.1, CC6.2, CC6.3]
    owner: security-lead
    frequency: quarterly
    type: manual
    evidence:
      - Signed access review export from IdP
      - Ticket documenting removals and approvals
    storage: evidence/access-reviews/{YYYY}-Q{N}/

  - id: CM-02
    title: Production changes require peer approval
    criteria: [CC8.1]
    owner: eng-manager
    frequency: continuous
    type: automated
    evidence:
      - Branch protection configuration snapshot
      - Sample of merged PRs with approvals
    storage: evidence/change-mgmt/{YYYY}-{MM}/

Version-controlling the matrix gives you a history of who changed which control and when, which is itself useful audit context.

Step 6: Automate Evidence Collection

Manual screenshot gathering does not scale across a Type II window. Compliance automation, whether through a dedicated platform or your own scripts, reduces both effort and the risk of missed evidence. A scheduled job can capture point-in-time configuration snapshots like these:

#!/usr/bin/env bash
# Monthly evidence snapshot: IAM credential report and branch protection
set -euo pipefail

STAMP=$(date +%Y-%m)
OUT="evidence/${STAMP}"
mkdir -p "$OUT"

# AWS IAM credential report (MFA status, key age, last use)
aws iam generate-credential-report > /dev/null
sleep 10
aws iam get-credential-report \
  --query Content --output text | base64 --decode \
  > "${OUT}/iam-credential-report.csv"

# GitHub branch protection on the default branch
gh api "repos/${GH_ORG}/${GH_REPO}/branches/main/protection" \
  > "${OUT}/branch-protection-main.json"

# Record a checksum manifest for integrity
sha256sum "${OUT}"/* > "${OUT}/MANIFEST.sha256"

A few practices make automated evidence stronger:

• Timestamp everything and store it somewhere with restricted write access.
• Generate checksums so you can demonstrate files were not altered.
• Alert on collection failures. A silent cron failure in month four is a gap you will not notice until the auditor asks.
• Keep humans in the loop for judgment-based controls such as access reviews and risk assessments. Automation collects the data. People still need to review and sign off.

Step 7: Select an Auditor and Set the Observation Window

Engage a CPA firm early. Ask about their experience with organizations of your size and technology stack, their evidence request process, and whether they recommend a readiness assessment first.

Review periods commonly range from three to twelve months. A shorter first window can get a report into customers' hands sooner. A longer window can carry more weight with some buyers. Your auditor and your customers' expectations should drive this decision. Do not start the window until your controls are implemented and operating.

Step 8: Conduct a Mock Audit

Before the window opens, or early in it, run a dry run:

1. Pick a sample of controls from the matrix.
2. Have someone outside the control owner's team request evidence as an auditor would.
3. Time how long it takes to produce it.
4. Log anything missing, inconsistent, or undocumented.

This exercise is the best predictor of how fieldwork will feel.

Step 9: Operate Consistently Through the Window

During the observation period, the job is consistency:

• Hold a short recurring compliance review to check that periodic controls happened on schedule.
• Document exceptions immediately, along with the remediation taken. A documented, remediated exception reads very differently from an undiscovered one.
• Avoid major control changes mid-window without telling your auditor.
• Track terminations closely. Late access removal is a common source of exceptions.

Common Pitfalls to Avoid

• Scoping too broadly and pulling non-critical systems into the audit.
• Policy-practice mismatch, such as writing "monthly" when the team actually works quarterly.
• Evidence scattered across inboxes, chat threads, and personal drives.
• Ignoring complementary user entity controls (CUECs) listed in your vendors' SOC reports, which you are expected to address.
• Treating the report as the finish line. The next window starts as soon as this one ends, and customers may request bridge letters to cover the gap between reports.

Getting Support for Audit Preparation

Many teams find that the hardest part of audit preparation is the engineering work: building identity and access controls, CI/CD guardrails, logging pipelines, and evidence automation that hold up under scrutiny. If you want an engineering partner for that work, our cloud, security, and compliance engineering capabilities cover the technical controls described above. Requirements also vary by sector, so it is worth reviewing how compliance expectations differ across the industries we support.

Sources and further reading:

• AICPA, 2017 Trust Services Criteria for Security, Availability, Processing Integrity, Confidentiality, and Privacy (With Revised Points of Focus, 2022)
• AICPA, SOC 2 Reporting on an Examination of Controls at a Service Organization Relevant to Security, Availability, Processing Integrity, Confidentiality, or Privacy (Guide)
• NIST Special Publication 800-61, Computer Security Incident Handling Guide

FAQ

How long does SOC 2 Type II prep take?

It depends on your starting maturity and scope. Teams with established access, change management, and logging controls may only need a few months of remediation before starting the observation window. Teams starting from scratch should expect longer. The review period itself then runs for the length agreed with your auditor, often between three and twelve months.

Should we get a SOC 2 Type I before a Type II?

Not necessarily. A Type I can provide an earlier customer-facing report and validate control design. Many organizations instead go straight to a Type II after a readiness assessment. Discuss the trade-offs with your auditor based on customer deadlines.

What is the difference between a readiness assessment and the audit itself?

A readiness assessment is a pre-audit review that identifies gaps in control design and evidence. It does not produce a SOC 2 report. The audit is the formal examination performed by a CPA firm that results in the attestation report your customers receive.

Do we need a compliance automation platform?

No, but you do need a reliable, repeatable way to collect and store evidence. Platforms can speed up monitoring and evidence collection. Scripts and well-structured storage can also work, especially for teams with strong engineering capacity. Either way, judgment-based controls still require human review.

What happens if the auditor finds an exception?

Exceptions are documented in the report along with management's response. A single exception does not automatically mean a qualified opinion, but it will be visible to customers. Documenting and remediating issues promptly during the window is the best way to limit their impact.