SOC 2 Type II Audit Preparation Guide: Controls, Evidence, and Timeline

Type I: A point-in-time assessment. The auditor evaluates whether your controls are suitably designed and implemented as of a specific date. No observation period -- the auditor reads your documentation and interviews staff to confirm controls exist.

Type II: A period-of-time assessment. The auditor selects samples from across the audit period (typically 6-12 months) and tests whether your controls operated effectively throughout. A Type I report says your controls existed on Day 1. A Type II report says they worked consistently for the entire period.

What enterprise buyers require: Nearly all enterprise procurement processes require Type II. Type I is acceptable as a bridge while you accumulate the Type II observation period, but most legal and vendor risk teams do not accept Type I as a long-term substitute.

The observation period trap: Many companies plan to start their SOC 2 audit when they need the report. A 12-month Type II means your audit period started 12 months ago. If you need the report in Q4 2026, your observation period should have started Q4 2025. Starting preparation in Q4 2026 when you need the report means the earliest you can have a 12-month Type II is Q4 2027.

Practical path: complete a Type I in months 1-6 to give enterprise buyers something immediate, use the same controls to generate the Type II observation period, and deliver the Type II 6-12 months after the Type I.

SOC 2 reports are organized around Trust Service Criteria (TSC) defined by the AICPA. The Security (Common Criteria) category is required for every SOC 2. Others (Availability, Confidentiality, Processing Integrity, Privacy) are additive and selected based on customer requirements.

Common Criteria (CC) categories -- the required foundation

• CC1: Control environment (organizational structure, authority, accountability, code of conduct)
• CC2: Communication and information (internal communication of security policies, external incident notification)
• CC3: Risk assessment (formal risk assessment process, risk identification and response)
• CC4: Monitoring (ongoing monitoring of controls, deficiency identification and remediation)
• CC5: Control activities (control selection and development, vendor management, change management)
• CC6: Logical and physical access controls (this is where most technical controls live: authentication, authorization, access reviews, encryption)
• CC7: System operations (infrastructure monitoring, malware protection, incident response)
• CC8: Change management (SDLC controls, code review, release approval, testing)
• CC9: Risk mitigation (vendor risk management, business continuity)

Where auditors spend most of their time

CC6 and CC7 are the most evidence-intensive categories. CC6 covers: how users are provisioned and deprovisioned, MFA enforcement, access reviews, encryption of data at rest and in transit, network security controls, and physical access to data centers. CC7 covers incident detection, response, vulnerability management, and system monitoring.

Availability criteria (if selected)

Covers uptime commitments, capacity monitoring, and business continuity. Required if you commit to SLAs in your contracts. Auditors will test whether your monitoring, alerting, and DR processes operated as documented throughout the period.

Privacy criteria (if selected)

Covers data subject rights (deletion, access, correction), consent management, and data retention. Required if you handle personal data and represent this in your trust report. Privacy criteria are the most complex to evidence and are often added after the initial Type II.

The most common reason SOC 2 audits result in qualified opinions is not missing controls -- it is controls that are poorly designed or implemented inconsistently. Auditors look for:

Precision in control statements

Weak control: "We review user access regularly."

Audit-ready control: "User access to production systems is reviewed quarterly by each system owner. Access is revoked within 5 business days of an employee termination. Reviews are documented in Jira tickets with approval evidence attached."

The auditor will pull samples of access reviews and verify each element: did the review happen? Was it quarterly? Was revocation within 5 days? Is there documentation? A vague control statement gives the auditor latitude to find anything insufficient.

Controls that auditors scrutinize most

• Access reviews: Must be periodic, documented, and show explicit approval by an owner. Screenshots of a spreadsheet signed off in email are acceptable; verbal reviews with no record are not.
• Background checks: Must occur before access is granted, not after. Document the policy, the vendor used, and maintain evidence (certificate of completion, not the full report) for each new hire.
• Vulnerability management: Must show a defined scan cadence, a defined remediation SLA (Critical: 30 days, etc.), and evidence that findings were remediated within SLA during the audit period. Auditors will sample open findings against their reported open date.
• Change management: Code changes must go through an approval process (pull request approval by a reviewer who is not the author) consistently. A finding of a single production deployment without approval during the audit period is a control failure.
• Incident response: Must show at least one documented incident (or tabletop exercise if no incidents occurred) with evidence that your IR process was followed. Undocumented verbal responses to security events are not auditable.

Control design anti-patterns

• Designing controls you cannot sustain operationally (e.g., daily access reviews when you have 50 systems)
• Using "we" statements without assigned ownership
• Controls that depend on a single person (single points of failure create audit risk)
• Policies that are not actually followed (auditors compare policy to practice)

Type II audits are evidence-intensive. For a 12-month observation period, auditors will request samples across the period -- typically 5-25 samples per control depending on the control frequency and risk rating.

Control frequency and sample sizes (AICPA guidance)

Evidence types auditors accept

• Screenshots with timestamps and system URL visible in the browser (no cropped images)
• Exported reports from systems (CSV, PDF) with run date and parameters visible
• Jira/ServiceNow tickets with creation date, assignee, resolution date, and approval comments visible
• Email threads showing approval (with full header/timestamp)
• System-generated logs exported with timestamps in UTC
• Policy documents with version date, approval signature, and distribution evidence

Evidence auditors reject

• Screenshots cropped to hide the URL or system name
• Word documents describing what happened (narrative, not evidence)
• Undated screenshots or screenshots with modified file timestamps
• Evidence that cannot be traced to a specific individual ("the team reviewed this")

Building a continuous evidence collection process

Do not collect evidence only at audit time. Build ongoing collection:

• Configure your GRC tool (Drata, Vanta, Secureframe, Tugboat Logic) to automatically pull evidence from your tech stack (AWS Config, Okta access logs, GitHub pull request data, vulnerability scanner reports)
• For manual controls (quarterly access reviews), create recurring calendar events with a templated documentation process
• Keep a centralized evidence repository organized by control, with date ranges labeled
• Assign control ownership so each control has a named person responsible for evidence availability

SOC 2 audits can only be performed by licensed CPA firms. The firm must be registered with the AICPA. Quality and cost vary significantly.

Auditor tiers

• Big 4 / Top 10 (Deloitte, PwC, EY, KPMG, RSM, Grant Thornton): Brand credibility is highest; some enterprise customers specifically require Big 4 audit. Cost range: $40,000-$150,000+ for a standard SOC 2 Type II. Timelines are longer due to resource constraints.
• Specialized security audit firms (A-LIGN, Schellman, Coalfire, KirkpatrickPrice, Prescient): Specialize in technology company audits; often faster, more pragmatic, and SaaS-tool-familiar. Cost range: $15,000-$60,000. Often the right choice for first-time auditors.
• Boutique regional CPA firms: Lowest cost ($8,000-$25,000) but variable quality; some have limited technology company experience. Due diligence required.

What to ask auditors before selecting

• How many SOC 2 audits have you completed in the last 12 months?
• What is your experience with companies at our stage and technology stack?
• Who will be the lead auditor assigned to our engagement (seniority matters)?
• What is your evidence request process? Do you use a portal or email?
• What does your remediation observation period look like if we have exceptions?
• Do you offer a readiness assessment before the formal audit?

The readiness assessment

Most firms offer a paid readiness assessment before the formal audit: a pre-audit review of your controls and documentation. This is strongly recommended for first-time audits -- it surfaces gaps before they become audit findings, not after. Cost: $3,000-$15,000 depending on firm. Pay it. The return on investment vs. a qualified opinion is significant.

Audit timeline expectations

• Kickoff and evidence request: 2-4 weeks
• Evidence collection and submission: 4-8 weeks (the longest phase for most companies)
• Auditor fieldwork (testing): 4-6 weeks
• Draft report review: 2-3 weeks
• Management response to exceptions: 1-2 weeks
• Final report issuance: 1-2 weeks

Total: 14-25 weeks from engagement start to final report. Budget 6 months minimum. First-time audits routinely run longer due to evidence collection gaps.

Months 1-2: Foundation

• Conduct a gap assessment against the Common Criteria (use the AICPA trust services criteria document as the baseline)
• Assign control owners for each control area
• Select a GRC tool for evidence collection automation (Drata, Vanta, Secureframe, or Tugboat Logic)
• Begin writing or updating security policies (acceptable use, access control, incident response, change management, vendor management)

Months 3-4: Control Implementation

• Implement or formalize controls identified as gaps: MFA enforcement, access provisioning/deprovisioning process, quarterly access review cadence, vulnerability scanning with defined SLAs, change management approval process
• Connect your GRC tool to your tech stack for automated evidence collection
• Run your first access review under the new process and document it
• Conduct a tabletop incident response exercise and document it

Months 5-6: Type I Audit (optional but recommended)

• Engage an auditor for a Type I assessment (point-in-time)
• Use this to give enterprise customers an interim trust report while the Type II period accumulates
• Address any Type I findings before they become Type II exceptions

Months 7-10: Observation Period + Ongoing Operations

• Operate controls consistently -- this is the period the Type II will cover
• Run quarterly access reviews on schedule
• Remediate vulnerabilities within defined SLAs and document remediation
• Log all production changes through the change management process
• Conduct and document any security incidents (even minor ones) following the IR process

Months 11-12: Type II Audit

• Engage the auditor and submit to evidence requests
• Respond to exceptions with documented remediation where applicable
• Review the draft report and submit the management response
• Receive and distribute the final report

Ongoing post-audit

• SOC 2 Type II reports are typically valid for 12 months. Plan for annual re-audit
• Use the audit period as a forcing function for continuous control improvement
• Distribute the report under NDA to prospects; consider a summary version for broader sharing