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:

Which Trust Services Criteria? Security is mandatory. Most B2B SaaS add Availability + Confidentiality. Skip Privacy if you already have GDPR.
Type 1 or Type 2? Type 2 requires a 3-12 month observation window — can you wait?
Which systems are "in scope"? Customer production + any system that stores/processes customer data. Be precise.
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.

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

Table of Contents