SOC 2 Compliance Checklist 2026: The 90-Day Path to Audit-Ready

SOC 2 has no prescribed control list — it has criteria and you design controls that meet them. In practice, auditors expect a consistent set of ~60-120 controls depending on scope. This checklist captures what we see pass audits in 2026, organized for a 90-day implementation path toward Type 2 observation.

If you want the full background first, start with What is SOC 2 Compliance?.

Pre-checklist: 4 scoping decisions

Before you start ticking boxes, make these scoping decisions — they change what's on your list:

1. Which Trust Services Criteria? Security is mandatory. Most B2B SaaS add Availability + Confidentiality. Skip Privacy if you already have GDPR.
2. Type 1 or Type 2? Type 2 requires a 3-12 month observation window — can you wait?
3. Which systems are "in scope"? Customer production + any system that stores/processes customer data. Be precise.
4. Which auditor? Pick before implementation so you design controls to their expectations.

Phase 1 — Governance and policies (Days 1-20)

Foundation: 25-40 policies that define how your company runs.

• Information Security Policy (master policy)
• Acceptable Use Policy (what employees may/may not do with IT)
• Access Control Policy (least privilege, reviews, termination)
• Change Management Policy (code reviews, production changes)
• Risk Assessment Policy (annual, documented, quantified)
• Incident Response Policy + playbook
• Vendor Management Policy
• Data Classification Policy (public, internal, confidential, restricted)
• Data Retention and Disposal Policy
• Business Continuity / Disaster Recovery Policy
• Backup Policy
• Encryption Policy
• Password Policy (complexity, rotation, MFA)
• Remote Work Policy (endpoint security, VPN)
• Physical Security Policy (even for remote-first — covers data center access via vendor)
• Personnel Security Policy (background checks, training, offboarding)
• Secure Software Development Policy (SDLC)
• Vulnerability Management Policy
• Logging and Monitoring Policy
• Code of Conduct (ethics, conflicts of interest)

All policies: signed by CEO, reviewed annually, accessible to all employees.

Phase 2 — Access management (Days 15-30)

Security TSC evidence starts here.

• MFA enforced on all production systems, email, SSO provider, cloud consoles
• SSO for all business-critical apps (Okta, Entra ID, Google Workspace)
• Least privilege access model documented, per-role
• Privileged Access Management for admin accounts (Just-in-Time ideally)
• Quarterly access reviews — every user, every system, sign-off by manager
• Termination checklist — revoke access within 24h (4h for privileged)
• Service accounts inventoried, rotated, non-human-owned
• Guest access time-boxed and reviewed
• No shared accounts in production (or documented exception)
• SSH / production access via bastion or session manager, recorded
• Secrets management — no hardcoded credentials, use AWS Secrets Manager / Vault / 1Password

Evidence to collect: access matrix, quarterly review screenshots, termination tickets with timestamps.

Phase 3 — Change management (Days 20-40)

• Code review required on every production PR (enforce via branch protection)
• CI/CD pipeline with automated tests
• Production deployments logged with deployer identity
• Rollback procedure documented and tested
• Emergency change process for hotfixes with retro documentation
• Separation of duties — developer cannot merge own code to production without review
• Infrastructure as Code for reproducibility (Terraform, CloudFormation)
• Configuration baseline documented for servers/containers

Evidence: GitHub/GitLab branch protection settings, sample PRs with reviews, deployment logs.

Phase 4 — Monitoring and logging (Days 25-50)

• Centralized logging (Datadog, Splunk, ELK, CloudWatch)
• Security event logging — authentication, authorization, admin actions, data access
• Log retention at least 1 year (check your sector — some require 3+ years)
• Log tamper-proofing — append-only, access-controlled
• Alerting on suspicious patterns (failed logins, privilege escalations, data exfil)
• SIEM or equivalent for correlation
• Uptime monitoring with incident response hookup
• Performance monitoring for availability SLA tracking
• Daily review of high-severity alerts (documented)

Evidence: dashboard screenshots, alert history with response notes, retention proof.

Phase 5 — Vulnerability management (Days 30-55)

• Automated vulnerability scanner (Tenable, Qualys, Rapid7) — see Vulnerability Management Guide
• Cloud security posture management (CSPM) if you're cloud-hosted — see Cloud Pentest Guide
• Container image scanning in CI/CD
• SAST (Semgrep, Snyk, SonarQube) on every PR
• DAST / API scanning before production releases
• Defined patch SLAs (Critical 7d, High 30d, Medium 90d)
• Annual penetration test — full scope
• Exception process for accepted risks with documented sign-off
• Quarterly vuln review with engineering leadership

Evidence: scan reports, remediation tickets with close dates, pentest report.

Phase 6 — Encryption and data protection (Days 35-55)

• Encryption at rest for all customer data (AES-256 or equivalent)
• Encryption in transit TLS 1.2+ everywhere (TLS 1.3 preferred)
• Database backups encrypted
• Key management — AWS KMS, Azure Key Vault, GCP KMS, HashiCorp Vault
• Key rotation annual minimum, documented
• Customer data segmentation documented (multi-tenant isolation model)
• Data loss prevention controls for sensitive data egress
• Removable media policy (USB sticks, external drives)
• Secure deletion procedure for customer data at contract end

Evidence: infrastructure diagrams, KMS configuration, deletion attestation log.

Phase 7 — Incident response (Days 40-65)

• Incident Response Plan written (classification, escalation, communication)
• Tabletop exercise conducted and documented (annual minimum)
• Breach notification procedure aligned with GDPR 72h / SOC 2 expectations
• Runbooks for common incidents (DDOS, credential leak, ransomware)
• On-call rotation defined
• Post-incident review template used for every P1/P2
• Customer communication template for security events

Evidence: IR plan, tabletop notes, past incident reports (real or simulated).

Phase 8 — Vendor management (Days 45-65)

• Vendor inventory with criticality tiers
• SOC 2 / ISO 27001 collection for critical vendors
• Data Processing Agreements (for GDPR, often doubles as SOC 2 vendor evidence)
• Vendor risk assessment annual for tier 1, biennial for tier 2
• Sub-processor list public on your website
• Vendor offboarding checklist (access revoked, data deletion confirmed)

Evidence: vendor tracker, collected reports, DPAs.

Phase 9 — HR and personnel security (Days 15-75)

• Background checks (where permitted by local law — limited in DE)
• Security training on hire documented, re-trained annually
• Phishing simulation quarterly — see Phishing Simulation Guide
• Acceptable use policy signed by every employee
• Offboarding checklist includes all system access revocation
• Contractor agreements include security + confidentiality clauses
• Role-based training for elevated-access roles (engineers, admins)

Evidence: training completion rates, phishing test results, signed AUPs.

Phase 10 — Business continuity (Days 50-80)

• BCP / DR plan written
• RTO and RPO defined per critical system
• Backup testing quarterly (actual restore, not just backup success)
• DR test annual minimum — documented outcome
• Redundancy at infrastructure level (multi-AZ, or multi-region for high-availability)
• Runbook for failover procedures
• Vendor continuity — what happens if your SaaS provider fails?

Evidence: BCP, test results, recovery metrics.

Phase 11 — Availability (if TSC selected) (Days 60-85)

• Uptime SLA documented in customer agreements
• Status page public or customer-facing
• Capacity planning process with forecasts
• Load testing before major releases
• Disaster recovery validated with measurable outcomes
• Public commitments on response times for incidents

Phase 12 — Confidentiality (if TSC selected) (Days 65-85)

• NDAs with employees and contractors at hire
• Customer contracts with confidentiality clauses
• Data classification labels applied (where technically feasible)
• DLP policies on endpoints and email
• Access to confidential data time-bounded and logged

Phase 13 — Final readiness (Days 80-90)

• Control mapping document — every SOC 2 criteria mapped to specific controls + evidence
• Evidence repository organized (folder per control, auto-updating where possible)
• Management review — CEO + CISO sign-off on readiness
• Pre-audit walkthrough with chosen audit firm
• Readiness report (from your compliance tool or a consultant)
• Kickoff Type 2 observation window

How Matproof automates this

Implementing 60+ controls with Google Drive + spreadsheets is possible but brittle. Matproof provides:

• Pre-built policy library (40+ templates)
• Automated evidence collection from your stack (GitHub, AWS, GCP, Okta, Jira, etc.)
• Continuous control monitoring (alerts when a control drifts)
• SOC 2 + ISO 27001 dual-mapped — same evidence covers both
• EU-hosted (Frankfurt) — no US data residency concerns
• Auditor-ready export in one click

Start your SOC 2 readiness assessment — 15 minutes, free, instant scoring.

Final reminders

• SOC 2 isn't pass/fail — you can have exceptions in the report and still pass. The goal is material integrity.
• The first Type 2 audit always surfaces 5-15 exceptions. Normal. Plan remediation into the next observation cycle.
• Type 2 is annual — build for sustained operation, not a one-time push.

Related: What is SOC 2 Compliance? | SOC 2 Type 1 vs Type 2 | SOC 2 Compliance Cost Guide | SOC 2 Audit Preparation Guide