SOC 2 compliance requirements: the practical checklist

Founders ask us for "the SOC 2 requirements checklist" at least once a week, and the honest answer surprises them: there isn't one. The AICPA does not publish a numbered list of controls you must implement. Your auditor does not have a secret rubric. What exists is a framework, and your job is to design controls that meet it.

This post is the working checklist we hand clients when they want the concrete version of that answer. For the conceptual primer, start with what SOC 2 is.

The short answer

SOC 2 has no fixed control list. The "requirements" are meeting the AICPA Trust Services Criteria you put in scope, with controls you design and evidence you can produce on demand. The criteria themselves are published by the AICPA's Assurance Services Executive Committee as the 2017 Trust Services Criteria with 2022 revised points of focus, and they are outcome-based, not prescriptive.

The Common Criteria: what every SOC 2 covers

Security is mandatory in every SOC 2, and Security is organized into nine Common Criteria (CC) series that every report has to address:

• CC1, Control environment. Governance, org structure, hiring tone.
• CC2, Communication and information. How policies and responsibilities move inside and out of the company.
• CC3, Risk assessment. Identifying risks to your service commitments, including fraud risk.
• CC4, Monitoring activities. Ongoing evaluation, internal audit, remediation.
• CC5, Control activities. General design-and-deploy criteria.
• CC6, Logical and physical access. Identity, authentication, provisioning, termination, encryption.
• CC7, System operations. Monitoring, incident response, vulnerability management, recovery.
• CC8, Change management. Authorizing and documenting changes to infrastructure, data, and software.
• CC9, Risk mitigation. Business disruption and vendor management.

If you add Availability, Confidentiality, Processing Integrity, or Privacy to scope, you layer additional criteria on top of CC1–CC9. You do not re-do the Common Criteria work. The narrative that accompanies the report is governed by the AICPA's 2018 SOC 2 Description Criteria, which sets the benchmarks for how your system description has to read.

Policies every SOC 2 expects to see

Policies are the spine of a SOC 2. The auditor wants them written, approved, dated, and actually followed. A realistic first-year set:

• Information Security Policy. The umbrella document. Scope, roles, management commitment, review cadence.
• Access Control Policy. Provisioning, deprovisioning, least privilege, MFA, privileged access, quarterly reviews.
• Change Management Policy. Peer review, testing, approvals, rollback, separation of duties between developers and production.
• Incident Response Policy. Definitions, severities, roles, comms, post-incident review cadence.
• Vendor Management Policy. Risk-rating inventory, onboarding diligence, annual review, termination.
• Risk Assessment Policy. Annual cadence, methodology, fraud risk, treatment decisions.
• Acceptable Use Policy. What employees can and cannot do on company systems.
• Data Classification Policy. Public, internal, confidential, restricted, and the handling rules for each.
• Business Continuity and Disaster Recovery Policy. RTO and RPO targets, backup strategy, rehearsal cadence.

Owners should be named on the policy, review dates should be on the cover, and the last approval should be less than twelve months old when fieldwork starts. Undated policies are the most common finding we see on first audits.

Controls the auditor actually tests

Policies describe intent. Controls are what the auditor samples. The common ones across CC6, CC7, CC8, and CC9:

• Access reviews on a quarterly cadence for production and sensitive corporate systems, with evidence of who reviewed and what changed.
• MFA on identity provider, code repo, cloud console, and every production admin path.
• Background checks for new hires, with a policy exception process for jurisdictions where they are restricted.
• Onboarding and offboarding tickets that tie account creation and termination to HR events, closed within a defined SLA.
• Logging and monitoring with alerts routed to a human, retention consistent with your policy, and evidence the alerts have been acted on.
• Vulnerability management with scans on a stated cadence, a remediation SLA tied to severity, and ticket history.
• Encryption in transit and at rest, with key management documented.
• Backups with tested restores. An untested backup is a claim, not a control.
• Vendor reviews annually for critical vendors, using their SOC 2 Type II or equivalent evidence.

A control you cannot sample a year of is a policy wearing a control's name tag. The auditor will tell the difference.

Evidence you need to produce

Fieldwork is mostly an evidence conversation. For each control, the auditor will ask for artifacts. Typical requests:

• Access review screenshots or exports, with reviewer name and date.
• Tickets for onboarding, offboarding, change management, and incident response, with timestamps the auditor can correlate.
• Logs from your SIEM or cloud platform, with a sample that proves retention and alert routing.
• Signed policies with version, approval date, and owner.
• Training records showing who took security awareness, when, and the completion status.
• Penetration test reports from an independent third party, dated within the observation window or the preceding year depending on your policy.
• Vendor SOC 2 reports for your critical subservice organizations, plus CUEC (complementary user entity controls) evidence showing you actually do your side.

A note on pentests. SOC 2 effectively requires an independent third-party penetration test as part of CC7. SecurancePro does not perform penetration testing. We evaluate the pentest report your chosen firm produces as evidence during fieldwork, and we will flag if the scope, methodology, or timing does not hold up. Picking a reputable pentest firm is on you; reading the report critically is on us.

Build this library before fieldwork, not during. Our readiness assessment post covers how to stand the library up in four to eight weeks.

The observation window for Type II

Type I is a point in time, so there is no observation window. Type II is a period, typically three to twelve months, during which your controls have to be running and producing evidence. For a fuller comparison, see Type I vs Type II. The underlying engagement is performed under the AICPA's attestation standards, codified in SSAE No. 18, which is what gives your report its legal weight.

How to pick the length:

• Three months. The absolute minimum the AICPA allows. Useful only when a buyer has specifically accepted a short initial window and you will extend next cycle. Do not make this your default.
• Six months. The right first-year choice for most companies. Long enough to prove the controls run, short enough that the report ships inside a calendar year.
• Twelve months. Standard steady state. Every cycle after the first is a twelve-month window that lines up annually, with a bridge letter from management covering the gap between your report date and the next period.

Once you pick, the window is not flexible. Controls that do not fire during the window do not get tested clean, and extending the window late adds fees and pushes your sales-enablement date.

What fieldwork week actually looks like

The last mile of a SOC 2 is a week or two of fieldwork, usually remote. Three things happen.

Walkthroughs. The auditor asks an owner to demonstrate a control end to end. "Show me how a new engineer gets production access." You click through it live, they take notes. This is where undocumented processes get exposed.

Sampling. For every control with a population, the auditor picks a sample. Twenty-five of your onboarding tickets from the past six months. Every critical change in April. A quarter of your access reviews. You pull the artifacts, they tie them back to the control.

Interviews. Short sessions with control owners, not just the compliance lead. The auditor is testing whether the policy lives in the heads of the people doing the work, or only on the policy page.

Our full walkthrough of the SOC 2 audit process covers kickoff through issuance in more depth.

Pulling it together

SOC 2 compliance requirements are less a checklist and more a design exercise. Scope the criteria, write the policies, implement the controls, run them long enough to produce evidence, and survive a week of fieldwork with artifacts ready. Do that once, cleanly, and the annual cycle becomes bookkeeping. Try to cram it in a sprint and it becomes a remediation bill.

For how the resulting report reads to a procurement team, see what a SOC 2 actually tells your buyer. For where we fit in the picture, our services page lays out the engagement types we run.

---

If you want an auditor's read on whether your policies, controls, and evidence are close enough to open an observation window, get in touch and we will walk through your current state in an hour.