The single biggest mistake teams make with SOC 2 Type II readiness is treating the audit as an event instead of a period. A Type II report attests that your controls operated effectively over a window of time, typically three to twelve months. That means the work is not "pass the audit," it is "run your controls consistently and prove it with evidence collected throughout the window." If you start prepping the week before the auditor arrives, you have already lost the game, because you cannot retroactively generate months of access reviews, change logs, or vulnerability scans that never happened.
This checklist walks through what to do before your audit window opens, during the window, and in the final stretch before fieldwork begins. It is written for engineering leaders and security owners who need a concrete plan, not a vendor pitch.
Understand What SOC 2 Type II Actually Tests
Type I asks: are your controls designed correctly at a point in time? Type II asks: did those controls operate effectively over the observation period? That distinction drives everything.
SOC 2 is built on the AICPA Trust Services Criteria (TSC): Security (the required "common criteria"), plus optional Availability, Confidentiality, Processing Integrity, and Privacy. You choose which categories are in scope based on the commitments you make to customers. Source: AICPA Trust Services Criteria.
Before anything else, confirm three scoping decisions with your auditor:
- Which TSC categories are in scope. Most SaaS companies start with Security only, then add Availability and Confidentiality.
- The length of your observation window. First-time reports often use a shorter window (three to six months) to reduce evidence burden.
- The system boundary. Which products, environments, and supporting infrastructure are covered. Be precise. A vague boundary creates evidence chaos.
The Pre-Window Readiness Checklist
Everything in this section should be done before the observation window opens. Auditors will sample evidence from within the window, so the controls need to be live and generating artifacts from day one.
1. Write and publish your policies
Auditors expect a documented, version-controlled, and approved policy set. At minimum:
- Information Security Policy
- Access Control Policy
- Change Management Policy
- Incident Response Policy
- Vendor / Third-Party Risk Policy
- Business Continuity and Disaster Recovery Policy
- Data Classification and Retention Policy
- Risk Assessment Policy
Policies need an approval date and an owner. A policy dated the week before fieldwork is a red flag. Store them where you can prove version history.
2. Run a gap assessment against the controls
Map each in-scope TSC criterion to a control and an owner. A simple matrix works:
| TSC Ref | Control | Owner | Evidence Source | Status |
|---------|----------------------------------|-------------|------------------------|---------|
| CC6.1 | Logical access via SSO + MFA | IT Lead | Okta admin export | Ready |
| CC6.2 | Access provisioning tickets | IT Lead | Jira workflow | Ready |
| CC7.2 | Vulnerability scanning weekly | Sec Eng | Scanner report | Gap |
| CC8.1 | PR review + approval before merge| Eng Manager | GitHub branch rules | Ready |
| A1.2 | Backup + restore testing | SRE | Restore test log | Gap |
Anything marked "Gap" needs remediation before the window opens, not during it.
3. Enforce technical controls that produce automatic evidence
The controls that survive audits are the ones the system enforces without human diligence. Prioritize these:
- SSO and MFA everywhere. Enforce at the identity provider, not per-app.
- Branch protection. Require pull request review and passing checks before merge. This is your change-management evidence.
# Example GitHub branch protection intent (via API/Terraform)
required_pull_request_reviews:
required_approving_review_count: 1
dismiss_stale_reviews: true
required_status_checks:
strict: true
contexts: ["ci/build", "ci/tests"]
enforce_admins: true
allow_force_pushes: false
- Centralized logging with retention covering the full window. If logs roll off after 30 days, you cannot prove controls operated over a six-month period.
- Infrastructure as code so environment changes are reviewable and traceable.
- Automated vulnerability scanning on a fixed cadence with tracked remediation.
4. Stand up your evidence collection pipeline
Evidence collection is where readiness efforts live or die. The goal is to make evidence a byproduct of doing the work, not a scavenger hunt at audit time. Two patterns work:
- Compliance automation platforms that integrate with your cloud, identity provider, and code host to pull evidence continuously.
- A disciplined manual cadence with a shared evidence repository, calendar reminders, and named owners, if you are not ready to buy tooling.
Either way, define for every control: what artifact proves it, who produces it, how often, and where it is stored. If you are building out the broader security program behind this, our cybersecurity and compliance capabilities outline how these controls fit into a production environment.
During the Audit Window: Operate and Capture
Once the window opens, the objective shifts from building controls to running them consistently and capturing proof. Auditors sample across the period, so a control that worked in month one but silently broke in month four will surface as an exception.
Recurring activities to schedule
Put these on a calendar with owners and evidence destinations:
- Quarterly user access reviews. Export access lists, have owners attest, document removals.
- Weekly or monthly vulnerability scans with tracked remediation tickets.
- Change management running continuously through your PR and deployment process.
- Onboarding and offboarding with timestamped tickets. Offboarding evidence is heavily sampled: prove access was revoked promptly.
- Backup and restore testing. A backup you never test-restored is not a control.
- Incident response. Even with zero incidents, document that the process exists and was reviewed.
- Vendor reviews. Collect subservice organizations' SOC 2 reports and track them.
Monitor for control drift
The most common failure is drift. A new admin account added outside the process. A branch protection rule disabled "temporarily." A logging pipeline that quietly stops. Build alerting for the controls that matter, and treat a broken control as an incident.
# Example: alert if an IAM user is created without going through IaC
aws cloudtrail lookup-events \
--lookup-attributes AttributeKey=EventName,AttributeValue=CreateUser \
--start-time "$(date -d '1 day ago' --iso-8601=seconds)"
Regulated sectors carry extra weight here. If you serve healthcare, financial services, or other high-scrutiny customers, your control operation gets examined closely. We describe sector-specific considerations across the industries we support.
The Final Stretch Before Fieldwork
In the last four to six weeks before the auditor requests evidence:
- Reconcile your control matrix. Every control should have evidence spanning the full window.
- Do a dry run of the evidence request list. Ask your auditor for their expected request list and pre-stage everything.
- Resolve open exceptions honestly. If a control failed at some point, document what happened and what you fixed. Auditors respond far better to a documented, remediated exception than a hidden one.
- Assign a single point of contact for the auditor. Fragmented communication slows fieldwork and increases the chance of miscommunication.
- Prepare your system description. The narrative describing your services, boundaries, and controls is part of the report and takes real time to write well.
A Realistic Timeline
For a first Type II with a six-month window, a workable plan looks like:
- Months -3 to -1: Scoping, policies, gap assessment, remediation, evidence pipeline.
- Month 0: Window opens. All controls live and generating evidence.
- Months 0 to 6: Operate controls, run recurring reviews, monitor drift.
- Weeks -6 to 0 before fieldwork: Reconcile, dry run, prepare system description.
- Fieldwork: Respond to sampling requests promptly with pre-staged evidence.
The teams that sail through are the ones for whom the audit changes almost nothing about how they already work. That is the real definition of SOC 2 Type II readiness: your normal operations already produce the proof.
FAQ
How long does the SOC 2 Type II observation window need to be?
The window can range from roughly three to twelve months. Many organizations choose a shorter window (three to six months) for their first Type II report to limit evidence burden, then extend to twelve months in subsequent cycles. Confirm the length with your auditor and your customers' contractual requirements.
What is the difference between SOC 2 Type I and Type II?
Type I evaluates whether your controls are designed appropriately at a single point in time. Type II evaluates whether those controls operated effectively over a period. Type II is more demanding because it requires evidence spanning the entire observation window, not a snapshot.
Do I need a compliance automation tool to get through a SOC 2 audit?
No, but it helps. Automation platforms continuously pull evidence from your cloud, identity provider, and code host, which reduces manual effort and drift. A disciplined manual process with a shared evidence repository and clear owners can also work, especially for a first, shorter window.
What causes the most audit exceptions?
Control drift and gaps in evidence coverage. Common examples include access reviews that were skipped a quarter, offboarding that was slow to revoke access, logging that rolled off before the window ended, and change management that was bypassed for a "quick fix." Consistency across the full window matters more than perfection at any single moment.
When should I start preparing for SOC 2 Type II readiness?
Start before the observation window opens. Policies, technical controls, and your evidence pipeline all need to be live from day one of the window, because auditors sample evidence from within that period. Plan for one to three months of pre-window work depending on your current control maturity.
