SOC 2 readiness assessment

Do you have written security policies that management approved in the last 12 months?

Policies are the first section of every SOC 2 document request, and undated policies read as unapproved.

Is one named person accountable for the security program?

Auditors look for clear ownership and reporting lines before they test anything else.

Have you completed a documented risk assessment, with a scored risk register, in the last 12 months?

The whole CC3 series is about identifying and responding to risk; the register is the evidence.

Do you check at least yearly that your controls are still working, and track the fixes?

Monitoring activities (CC4) ask for evidence that someone looks at whether controls operate, not just that they exist.

Does everyone acknowledge the security policies and complete security training at hire and every year?

Signed acknowledgments and training records are the standard evidence that people know what is expected of them.

Do you follow a written onboarding and offboarding checklist, including background checks where lawful?

Auditors sample new hires and leavers and ask for the checklist and the screening record for each.

Is multi-factor authentication enforced for everyone on your identity provider, cloud console and source control?

MFA is one of the first things tested under logical access, and an exception list is itself a finding.

Is access granted through single sign-on groups or roles, following least privilege?

Role-based access makes the population auditors sample small and explainable.

Do you review who has access to production, source code and admin roles at least quarterly, and keep the record?

Periodic access reviews are among the most commonly sampled controls, and a missed quarter is a visible exception.

When someone leaves, is their access removed within a defined time you can prove?

A terminated user who stayed active is one of the classic SOC 2 exceptions.

Does every production change go through a pull request with an independent review and passing checks?

Change management (CC8.1) is tested by sampling production changes and looking for approval before deployment.

Are production deployments done only through your CI/CD pipeline, not by hand?

A pipeline gives a complete, dated record of what was deployed, by whom, from which commit.

Do you scan code, dependencies and infrastructure for vulnerabilities and fix findings within set timelines?

CC7.1 asks for detection of vulnerabilities; auditors compare fix dates against the timelines your policy sets.

Are security-relevant logs collected centrally, retained, and alerted on?

Monitoring for anomalies (CC7.2) needs logs you keep and alerts someone actually reviews.

Do you have a written incident response plan that you tested (for example a tabletop) in the last 12 months?

CC7.3 to CC7.5 cover evaluating, responding to and recovering from incidents; a tested plan is the evidence.

Do you keep a vendor inventory and review the SOC 2 reports of vendors that hold customer data?

CC9.2 asks how you assess and monitor vendor risk; the inventory and the dated reviews are what gets sampled.

Are backups automated, and have you restored from one as a test in the last 12 months?

An untested backup is not evidence of recoverability; auditors ask for the restore test record.

Do you have a business continuity and disaster recovery plan with recovery time and recovery point objectives?

Availability commitments and CC9.1 expect a plan for disruption, with objectives you can test against.

Are laptops encrypted, screen-locked and kept up to date, and can you prove it (device management or attestation)?

Endpoints hold credentials and data; auditors ask for evidence across the whole fleet, not a policy statement.

Is customer data classified, encrypted in transit and at rest, and deleted on a defined schedule?

Confidentiality criteria and CC6.7 cover how data is protected while you hold it and disposed of when you do not need it.