SOC 2 readiness assessment checklist: are you ready to start your audit?

A readiness assessment is what separates companies that sail through their SOC 2 audit from companies that get a report full of exceptions. The audit observation period is not the time to discover that you have no MFA on your AWS root account, no evidence of access reviews, and no documented incident response procedure.

This checklist covers the controls that are most commonly missing when companies start their first SOC 2 readiness assessment. Work through it honestly. Gaps you find here are gaps you can fix before the clock starts.

Policies and documentation

• Information Security Policy: Does a written policy exist? Is it version-controlled and has management formally approved it?
• Acceptable Use Policy: Covers appropriate use of company systems, devices, and data
• Access Control Policy: Documents how access is granted, modified, and revoked
• Change Management Policy: Documents how software and infrastructure changes are reviewed and approved
• Incident Response Plan: Formal documented procedure for security incidents, including roles, escalation, and notification
• Business Continuity Plan: Documented plan for maintaining operations during disruptions
• Disaster Recovery Plan: RTO and RPO definitions, recovery procedures for production systems
• Vendor Management Policy: How third-party vendors are evaluated, approved, and monitored
• Password Policy: Minimum complexity, rotation requirements, and credential management
• Data Classification Policy: Defines categories of data and handling requirements for each
• Policy acknowledgment: Evidence that employees have read and acknowledged the relevant policies

Access management

• MFA enforced on all production systems: AWS Console, GCP Console, Azure Portal, GitHub, Okta, and any other system with access to production environment or customer data
• MFA enforced on email: Google Workspace or Microsoft 365 with MFA required for all accounts
• No shared accounts: Every individual who accesses production has a unique, named account
• Privileged access review: Evidence that admin and privileged access has been reviewed and is appropriate
• Access provisioning process: Formal process (ticket, approval, documentation) for granting new access
• Access deprovisioning process: Formal process for revoking access when employees leave or change roles; evidence that it is followed
• Terminated employee access log: Evidence that access was revoked for a sample of departed employees within an acceptable timeframe (typically same day or within 24 hours)
• Least privilege review: Engineers have only the access they need; no one with broad admin rights who does not require them
• AWS/GCP/Azure root account: Root/owner account has MFA, no access keys, and is not used for day-to-day operations
• Service account management: Service accounts have minimal permissions, keys are rotated, no service accounts with human-equivalent admin rights

Change management

• Code review required: All code changes to production must be reviewed by at least one other engineer before merging
• Protected main/production branch: Direct pushes to main or production branch are blocked; changes require PRs
• Automated testing in CI pipeline: CI runs tests before deployment; failed tests block deployment
• Deployment approval process: Production deployments are authorized (may be automated if controls are in place) and logged
• Emergency change procedure: Documented exception process for urgent fixes, with post-hoc review
• Separation of duties: Engineers do not both write and approve their own changes (for material changes)

Risk and vulnerability management

• Risk assessment performed: A formal risk assessment has been conducted and is documented; risks are rated by likelihood and impact
• Risk register: A living document tracking identified risks, owners, and treatment plans
• Vulnerability scanning: Automated scanning of infrastructure and/or code (e.g., AWS Inspector, Snyk, Qualys) running on a defined schedule
• Patch management process: Critical vulnerabilities are patched within a defined SLA (e.g., critical = 7 days, high = 30 days)
• Penetration testing: Annual penetration test by a qualified third party; findings tracked to remediation
• Dependency scanning: Dependencies (npm packages, Python libraries, etc.) are scanned for known vulnerabilities

Monitoring and incident response

• Infrastructure monitoring: Production systems have health monitoring with alerting (uptime, error rates, resource utilization)
• Security alerting: Security events (failed logins, privilege escalation, unusual API activity) generate alerts to an on-call channel
• Log retention: Application and infrastructure logs retained for a defined period (90 days minimum, 1 year common)
• Incident response procedure: The IR plan is actionable, not theoretical: who is paged, how severity is classified, who is notified, how incidents are closed and documented
• Incident log: Evidence of security incidents (even minor ones) and how they were handled; if none, document that none occurred with rationale
• On-call rotation: Named individuals responsible for responding to production alerts

Vendor management

• Vendor inventory: A list of all third-party services that process customer data or have access to your systems
• Risk tiering: Vendors are classified by risk level (high, medium, low) based on what data they access
• Vendor SOC 2 reports on file: For high-risk vendors, you have obtained and reviewed their SOC 2 reports or equivalent assurance
• DPAs executed: For vendors processing personal data, a Data Processing Agreement is in place
• Annual vendor review: Evidence that vendor risk is reviewed on a defined schedule

Infrastructure and encryption

• Encryption at rest: Customer data encrypted at rest in databases and object storage (AES-256)
• Encryption in transit: All customer-facing endpoints use TLS 1.2 or higher; no plain HTTP
• Key management: Encryption keys managed via KMS or equivalent; no hardcoded keys in code
• Secrets management: API keys, database credentials, and secrets not hardcoded in repositories or environment files; managed via secrets manager
• Network segmentation: Production is in its own VPC/account, isolated from development and staging
• Firewall rules documented: Security group rules are documented and reviewed; no open 0.0.0.0/0 inbound rules except 80/443

Employee controls

• Background checks: Process for background checks on employees with production access; evidence checks were performed
• Security training: Annual security awareness training for all employees; completion records maintained
• Onboarding checklist: Includes security training, policy acknowledgment, and account setup in scope
• Offboarding checklist: Includes access revocation across all systems; evidence of completion

After the assessment

Once you have worked through this checklist, you have a gap list. Prioritize gaps in this order:

1. Critical gaps that block the audit: No MFA on production, no written policies, no evidence trail for access provisioning/deprovisioning
2. High-risk gaps likely to appear as exceptions: Missing penetration test, no vendor inventory, incomplete access reviews
3. Documentation gaps: Existing processes not documented, policies not formally approved

Remediate critical and high-risk gaps before starting your observation period. Document everything, the audit evidence is the documentation, not the control itself.

A fractional CISO runs a SOC 2 readiness assessment against your live environment, not a spreadsheet, and then owns closing the gaps it surfaces. Book a call to get your readiness picture.

Related reading

• SOC 2 Type 1 vs Type 2
• How to prepare for a SOC 2 audit
• SOC 2 Trust Service Criteria explained
• SOC 2 evidence collection: what auditors actually want
• What does SOC 2 cost in 2026?

Want a security leader to run this?

Xorabyte is a fractional CISO for startups who can review your cloud for the gaps found first, so a blocked deal or an audit stops being your problem to carry alone. Book a call and you will leave with a clear path, not a sales pitch.