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

Type I evaluates the design of controls at a point in time. Type II evaluates both design and operating effectiveness over a period, typically three to twelve months. Type II provides stronger assurance to customers and prospects.

How long does SOC 2 Type II preparation take?

Most organizations need six to nine months for first-time readiness, including gap remediation and the observation period. Subsequent audits are faster because controls and evidence workflows are already established.

Which Trust Service Criteria are required?

Security (Common Criteria) is always required. Availability, Processing Integrity, Confidentiality, and Privacy are optional and should be selected based on customer expectations and contractual obligations.

Can we use automated tools for evidence collection?

Yes. GRC platforms and simple scheduled scripts can pull evidence from cloud providers, identity systems, and ticketing tools. Automation reduces manual effort and keeps evidence current, but the auditor still tests the underlying control, so automation does not replace the control itself.

What happens if the auditor finds exceptions?

Exceptions do not automatically result in a qualified opinion. The auditor evaluates whether compensating controls exist and whether the exception is isolated or systemic. Fix exceptions promptly and document the corrective action, because management responses are included in the report.

SOC 2 Type II Implementation Checklist

Overview

A SOC 2 Type II report shows that your controls operated effectively over an observation period, commonly somewhere between three and twelve months. This checklist covers each phase of preparation, from scoping and gap analysis to evidence collection and auditor engagement. Use it to coordinate engineering, security, and compliance work and to avoid the gaps auditors most often find.

The criteria themselves are published by the AICPA as the 2017 Trust Services Criteria (with revised points of focus, 2022). Read the points of focus for each criterion you select; they describe what an auditor expects to see far more precisely than any summary.

Readiness Phases

Define the system description and in-scope services
Map controls to the Trust Service Criteria
Conduct a gap analysis against current control state
Remediate identified gaps and document compensating controls
Collect evidence and test control operating effectiveness
Engage the auditor and manage the examination timeline

Month-by-Month Readiness Plan

Month	Work	Output
1	Choose criteria, define in-scope systems, name control owners	Scope statement and owner list
2	Gap analysis against each selected criterion	Gap register with priorities
3 to 4	Remediate gaps, write missing policies, configure logging and access reviews	Closed gaps with evidence of the fix
4	Readiness review with the auditor or an independent assessor	List of remaining issues
5 onward	Observation period begins; controls operate and evidence accumulates	Evidence folders per control
End of period	Auditor fieldwork, sampling, and management review of exceptions	Draft report, then final report

Trust Service Criteria Summary

Criteria	Focus area	Example controls
Security (CC)	Protection against unauthorized access	Firewalls, MFA, endpoint protection, access reviews
Availability (A)	System uptime and disaster recovery	SLA monitoring, failover testing, capacity planning
Processing Integrity (PI)	Accurate and complete data processing	Input validation, reconciliation, error handling
Confidentiality (C)	Protection of confidential information	Encryption at rest and in transit, DLP, classification
Privacy (P)	Personal data handling per commitments	Consent management, data retention, access requests

Copy-Ready Checklist for the Security Criteria

CC1 Control environment: board or leadership oversight documented; security roles and code of conduct acknowledged by staff
CC2 Communication: security policies published internally; customers told how to report issues
CC3 Risk assessment: written risk assessment updated at least annually, including fraud risk
CC4 Monitoring: internal control reviews scheduled, findings tracked to closure
CC5 Control activities: policies mapped to the controls that enforce them
CC6 Logical and physical access: MFA on production and cloud consoles; joiner, mover, leaver process; quarterly access reviews
CC7 System operations: logging and alerting on production; vulnerability scanning; incident response plan tested
CC8 Change management: code review and approval before production deploys; emergency change process
CC9 Risk mitigation: vendor due diligence on file; business continuity plan and insurance reviewed

Evidence Auditors Typically Request

Control area	Evidence	Sample size to expect
Access reviews	Review tickets with reviewer name, date, and changes made	Every quarterly review in the period
Onboarding and offboarding	HR records matched to account creation and removal dates	A sample of joiners and leavers
Change management	Pull requests with approvals linked to deployments	A sample across the period
Vulnerability management	Scan reports and tickets showing remediation within your stated timelines	A sample of findings by severity
Incident response	Incident tickets or tabletop exercise records	All incidents or the annual exercise
Vendor management	Due diligence records for in-scope vendors	Vendors added or reviewed in the period

Evidence Collection Best Practices

Automate evidence collection wherever possible using GRC platforms or scripts that pull screenshots, logs, and configuration exports on a schedule. Organize evidence by control ID and map each piece of evidence to the specific criteria it supports. Maintain a chain-of-custody log for sensitive evidence. Start collecting evidence at least two months before the audit window opens to ensure you have enough operating history.

Filled Example: One Control, Written Up

Illustrative example of how to document a single control so an auditor can test it without a follow-up call.

Control ID: AC-04. Description: Production access is reviewed every quarter by the engineering manager, and any access no longer needed is removed within five business days. Criteria: CC6.2, CC6.3. Owner: Head of Engineering. Frequency: Quarterly. Evidence: review ticket listing every account with production access, the reviewer's decision for each, and the change tickets for removals. How it could fail: a review is skipped, or removals take longer than five days. Test the auditor will run: select each quarter's review, confirm it happened on time, and trace removals to closed change tickets.

Common Readiness Gaps

Missing or incomplete access reviews for critical systems
No documented change management process for production deployments
Insufficient logging or log retention below the required period
Lack of formal risk assessment updated at least annually
Vendor management program without documented due-diligence assessments
Incident response plan that has never been tested through a tabletop exercise

Auditor Engagement Timeline

Engage your auditor at least three months before the planned audit window to agree on scope, walkthrough schedules, and evidence submission formats. Conduct a readiness assessment six to eight weeks before the observation period ends. Provide evidence in organized folders with clear naming conventions. Schedule management meetings at the midpoint and end of the observation period to address any exceptions early.