SOC 2 Type II Readiness Checklist: What Auditors Actually Look For

If you want to pass a SOC 2 Type II audit, the shortest version of the SOC 2 Type II checklist is this: define your control environment against the Trust Services Criteria, operate those controls consistently for your observation window (typically 3 to 12 months), and keep evidence that proves the controls ran as designed the entire time. Type II is not a point-in-time snapshot. Auditors are testing whether your controls actually worked, day after day, across the review period. The gap between "we have a policy" and "we can show the policy was enforced on a specific Tuesday eight months ago" is where most first-time efforts stall.

Below is what I look for when preparing teams for a Type II examination, organized the way auditors actually test it.

Type I vs. Type II: Why the Distinction Changes Your Work

A SOC 2 Type I report attests that your controls are suitably designed at a single moment. A Type II report attests that those controls were designed and operating effectively over a period of time. That single word, "operating," is the entire difference, and it dictates most of your preparation.

For Type II, the auditor samples events from across your observation window. If you claim access reviews happen quarterly, they will ask for all four quarters. If one quarter is missing, that is a control exception, and exceptions show up in your final report. The practical implication: you cannot cram for Type II. You need the controls running, and the evidence accumulating, before the window opens.

The SOC 2 Type II Checklist, by Control Area

The Trust Services Criteria (TSC), published by the AICPA, cover five categories: Security (the mandatory Common Criteria), Availability, Processing Integrity, Confidentiality, and Privacy. Most organizations scope to Security plus one or two others based on customer commitments. Here is the readiness checklist, grouped by what auditors examine.

1. Governance and Risk (Common Criteria CC1–CC5)

This is the foundation, and it is where loose documentation gets exposed.

• Organizational structure and accountability. Current org chart, defined security roles, and evidence that someone owns the information security program.
• Policies, reviewed annually. Information security, acceptable use, access control, change management, incident response, vendor management, and business continuity. Each should show a review date and an approver.
• Risk assessment. A documented, dated risk assessment that identifies threats, rates them, and maps mitigations. Auditors want to see this is a living process, not a one-time PDF.
• Vendor risk management. An inventory of subservice organizations, their SOC reports or security reviews, and evidence you assess them on a cadence.

2. Access Control (CC6)

Access is the most heavily tested area because it produces clean, timestamped evidence.

• Provisioning and deprovisioning tied to HR events. When someone is hired, access is granted through an approved request. When someone leaves, access is revoked promptly. Auditors will pull a sample of terminations and check revocation timestamps against separation dates.
• Least privilege and role-based access. Permissions map to job function, not to "whoever asked."
• Periodic access reviews. Usually quarterly. You need the review artifact, who performed it, and remediation of anything flagged.
• MFA enforced on all critical systems and admin consoles.
• Strong authentication policy with documented password or passkey standards.

A practical way to make access reviews auditable is to export entitlements on a schedule and store them immutably:

# Snapshot IAM users and attached policies for the quarterly access review
aws iam list-users --output json > "iam-users-$(date +%Y-%m-%d).json"

for user in $(aws iam list-users --query 'Users[].UserName' --output text); do
  aws iam list-attached-user-policies --user-name "$user" \
    --output json > "entitlements-${user}-$(date +%Y-%m-%d).json"
done

The dated files become your evidence. Reviewers annotate them, and you retain them for the full window.

3. Change Management (CC8)

Auditors test that code and infrastructure changes are controlled.

• Pull requests require review. No direct pushes to protected branches.
• CI/CD pipeline enforces gates: tests, security scans, and approvals before production deploys.
• Separation of duties so the person who writes a change is not the sole approver of its release, where feasible.
• Traceability from a change request or ticket to the merged code to the deploy.

Enforcing branch protection as code gives you consistent, provable control behavior:

# Example: GitHub branch protection expressed via Terraform
resource "github_branch_protection" "main" {
  repository_id = github_repository.app.node_id
  pattern       = "main"

  required_pull_request_reviews {
    required_approving_review_count = 1
    dismiss_stale_reviews           = true
  }

  required_status_checks {
    strict   = true
    contexts = ["build", "unit-tests", "sast-scan"]
  }

  enforce_admins = true
}

When an auditor asks "how do you prevent unreviewed code reaching production," you point to the configuration and a sample of merged PRs showing the approvals.

4. System Operations and Monitoring (CC7)

• Centralized logging across applications, infrastructure, and security tooling, with retention that covers your audit window.
• Alerting on security-relevant events with evidence that alerts are triaged.
• Vulnerability management. Scanning on a cadence, with findings tracked to remediation and SLAs by severity.
• Incident response. A tested runbook, and if an incident occurred during the window, documented handling.

5. Risk Mitigation and Availability (CC9, Availability criteria)

• Backups that run on schedule and are periodically restore-tested. A backup you have never restored is a hope, not a control.
• Business continuity and disaster recovery plans, with evidence of at least one exercise.
• Monitoring of availability against any uptime commitments you made to customers.

How Evidence Collection Actually Gets Graded

The single biggest failure mode is evidence that does not cover the entire period. Auditors think in samples across time. Build for that from day one:

1. Automate evidence capture wherever possible. Scheduled exports, logging, and immutable storage beat manual screenshots.
2. Timestamp and retain everything. Store evidence in a system where you cannot quietly backdate it.
3. Map each control to an owner and a cadence. A simple matrix listing control, owner, frequency, and evidence location prevents the "who was supposed to run the Q2 review" conversation.
4. Run a readiness assessment before the window opens. Find your gaps while you can still fix the design, not during fieldwork.

If you want help operationalizing these controls across cloud infrastructure and CI/CD, that is squarely in the kind of engineering work our platform and security capabilities are built around. Requirements also vary by sector, so it helps to ground your scope in the compliance realities of the industries you serve, whether that is healthcare, fintech, or SaaS.

A Realistic Timeline

For a team starting near zero, plan on roughly:

• Weeks 1–4: Scope the report, select TSC categories, run a gap assessment.
• Weeks 4–12: Remediate design gaps, implement controls, deploy tooling, write and approve policies.
• Observation window (3–12 months): Operate controls, accumulate evidence, run periodic reviews.
• Fieldwork (2–6 weeks): Auditor requests, sampling, interviews, and reporting.

Choose your window length based on customer pressure. Many organizations start with a shorter three-month window for the first Type II, then move to a standard six or twelve-month cycle.

Common Reasons Teams Fail Fieldwork

• Access reviews with gaps in the timeline.
• Terminated users whose access lingered past their separation date.
• Change management exceptions: direct-to-production deploys that bypassed review.
• Backups that were never restore-tested.
• Policies that exist but show no evidence of enforcement.

None of these are exotic. They are all consequences of controls that were designed but not consistently operated. Fix the operating discipline and the report follows.

FAQ

What is the difference between SOC 2 Type I and Type II?

Type I evaluates whether your controls are suitably designed at a single point in time. Type II evaluates whether those controls were designed and operating effectively over an observation period, usually 3 to 12 months. Type II requires evidence that controls ran consistently across the entire window.

How long does SOC 2 Type II take?

After preparation and remediation, you need an observation window, commonly 3 to 12 months, during which controls operate and evidence accumulates. Fieldwork and reporting typically add a few more weeks. A first-time effort from scratch often spans six to nine months end to end.

Which Trust Services Criteria do I need?

Security (the Common Criteria) is mandatory. You add Availability, Processing Integrity, Confidentiality, or Privacy based on the commitments you have made to customers. Scope to what you actually need; each added category expands the control set and evidence burden.

Can we automate SOC 2 evidence collection?

Yes, and you should. Scheduled exports of access entitlements, centralized logging, infrastructure-as-code for control configuration, and compliance automation platforms all reduce manual effort and produce consistent, timestamped evidence that holds up under sampling.

What makes a SOC 2 Type II audit fail?

The most common issues are evidence gaps across the observation window, delayed access revocation for terminated users, change management exceptions, and backups that were never restore-tested. These are operating failures, not design failures, which is why consistent execution matters more than documentation alone.