A practical, control-by-control checklist of what an auditor expects to see before SOC 2 Type II fieldwork begins. Broken down by domain with realistic timelines.
Readiness is the work you do before the auditor starts testing. For a Type II, the auditor is going to ask for evidence that your controls operated effectively over a period — typically 3 to 12 months. That means controls have to be designed, implemented, and producing observable evidence well before fieldwork begins, not the week of.
Governance and policy
Information security policy reviewed and approved by leadership in the last 12 months.
Acceptable use policy distributed to all personnel with acknowledgment evidence (signed handbook, HRIS attestation, training completion).
Code of conduct in the employee handbook covering integrity, ethical values, and confidentiality.
Risk assessment performed in the last 12 months with documented results and remediation tracking.
Information security officer or equivalent role designated with documented responsibilities.
Board or governance body that meets at least annually with security on the agenda.
People and HR
Background checks documented for all employees handling sensitive data (where legally permissible).
Onboarding checklist that includes security training and access provisioning approvals.
Offboarding checklist that includes timely access revocation and asset return.
Annual security awareness training with completion tracking. Phishing test results retained.
Confidentiality / NDA agreements signed by all employees and contractors.
Access controls (CC6 — the heaviest section)
MFA enforced on production systems and on company SSO. Document any exceptions.
SSO covering as many in-scope applications as possible. List of apps that bypass SSO is short and explained.
Quarterly user access reviews with evidence: who reviewed, what they reviewed, what they changed, when.
Privileged access (admin, root, production) inventoried separately and reviewed at least quarterly.
Joiner / mover / leaver process tied to HR — access provisioned within SLA, revoked within 24 hours of termination.
Encryption at rest for production data stores. Encryption in transit for all customer-facing endpoints.
Network segmentation between production, staging, and corporate environments.
Operations and monitoring (CC4, CC7)
Centralized logging for production systems (auth, admin actions, data access).
Alerts defined for security-relevant events with documented response procedures.
Vulnerability scanning at least monthly with tracked remediation SLAs by severity.
Annual penetration test by an independent third party with remediation evidence.
Endpoint protection (EDR or equivalent) deployed on company-issued laptops.
Patch management procedures with evidence of operating system and application patches applied per policy.
Incident response
Documented incident response plan with severity classifications and escalation paths.
Runbooks for common incident types (account compromise, data exposure, prolonged outage).
At least one tabletop exercise per year with documented findings and follow-ups.
Customer notification procedures aligned with contractual commitments and applicable regulations.
Post-incident retrospective template used for any significant incident during the period.
Change management (CC8)
All production code changes go through pull request review with at least one approver who is not the author.
CI/CD pipeline runs automated tests before deployment.
Production deployment requires authentication and is logged. Tag, build ID, or commit SHA traceable to a PR.
Emergency change procedure documented for incidents that require bypassing standard review.
Database schema changes follow a documented review and approval flow.
Vendor management (CC9)
Vendor inventory with classification by data sensitivity and criticality.
Security review for new vendors that handle customer data — SOC 2 review, security questionnaire, or contractual security addendum.
Annual review of critical vendors with evidence (renewed SOC 2, updated questionnaire, refreshed DPA).
Subservice organization decisions documented (carve-out vs. inclusive) for the system description.
Business continuity and disaster recovery (CC9, A1.2–A1.3)
Backup procedures with retention periods that meet customer commitments and regulatory requirements.
At least one documented backup restoration test per year.
Disaster recovery plan with recovery time and point objectives stated.
At least one DR test per year covering a meaningful failure scenario.
Data and privacy (Confidentiality, Privacy when in scope)
Data classification scheme with definitions and handling rules.
Customer data retention and deletion procedures. Evidence of deletion when contract terms or DSARs require it.
Privacy notice published and current.
Data subject access request (DSAR) process if Privacy is in scope.
Realistic timelines
From zero to a Type I report typically takes 8 to 16 weeks for a startup using a compliance platform. Type II observation periods then add 3 to 12 months on top, depending on what your customers will accept. Mid-market companies without prior compliance work usually need 4 to 6 months of readiness before Type I fieldwork.