How to Run a SOC 2 Self-Assessment Checklist

Don't Let the Auditor Find Your Gaps First

There's a painful version of SOC 2 and a smart version.

The painful version: you hire an auditor, start the observation period, and discover during the audit that you're missing a dozen controls you didn't know were required. You scramble to fix them mid-audit, the auditor notes exceptions, and your report has findings.

The smart version: you run a readiness assessment before the auditor gets involved, find your own gaps, fix them on your schedule, and only start the formal observation period when you're confident your controls are operating properly.

Orion chose the smart version.

What a Readiness Assessment Actually Produces

A good readiness assessment gives you three outputs:

1. A gap register — every control that's missing, weak, or undocumented
2. A risk-prioritized remediation roadmap — what to fix first, and roughly how long it will take
3. A Self-Assessment Score — a calibrated view of where you stand against each TSC

This document becomes your project plan for the next 3-6 months of preparation.

The Framework: Assessing Each Trust Services Criteria Area

CC1 — Control Environment

This is about governance. Does your leadership team formally own security? Do you have documented accountability for controls?

What to check:

• Is there a named individual responsible for security? (Even in a 15-person company, someone needs to own it)
• Has the board (or equivalent decision-making body) formally acknowledged the risk management approach?
• Do you have a code of conduct that covers security and privacy?
• Are there documented roles and responsibilities for security-related activities?

Orion's gap: No formal RACI for security. Fixed by creating an ownership matrix in Notion.

CC3 — Risk Assessment

What to check:

• Do you have a documented risk register?
• Has a formal risk assessment been completed in the last 12 months?
• Are risks rated by likelihood and impact?
• Is there a documented process for how risks are reviewed and treated?

Orion's gap: No formal risk register. They had risks in their heads but nothing documented. This became a high-priority remediation item.

CC6 — Logical Access (The Big One)

Access controls are the most heavily tested area in any SOC 2 audit. Expect this to be where most of your gaps live.

What to check:

• ●CC6.2 — How is access to production systems provisioned? Is there an approval workflow?
• ●CC6.3 — When someone leaves, how quickly is their access removed? Is there evidence?
• ●CC6.7 — Do admins have MFA? Is privileged access reviewed quarterly?
• Is there a formal access review process (user access recertification) at least quarterly?
• Are there separate accounts for development vs production environments?

Orion's gaps:

• No formal offboarding checklist that covered system access
• No quarterly access review for production systems
• One developer had production database access "temporarily" for 9 months

CC7 — System Operations

What to check:

• ●CC7.1 — Do you run regular vulnerability scans? What's your SLA for remediation?
• ●CC7.2 — Do you have log monitoring or a SIEM? Are alerts reviewed?
• ●CC7.3 — Do you have a documented incident response plan? Has it been tested?
• When was your last penetration test? (Most auditors expect at least annual)

Orion's gaps:

• Vulnerability scans ran monthly but findings older than 60 days had no remediation tracking
• No documented IR plan — incidents were handled ad hoc
• Last pen test: 18 months ago

CC8 — Change Management

What to check:

• ●CC8.1 — Are production changes reviewed and approved before deployment?
• Is there a separated development environment? (Code tested before going to production?)
• Are deployments tracked? Can you trace every production change back to an approved pull request?

Orion's gap: No formal approval requirement for hotfixes. Engineers could deploy to production without peer review in "urgent" situations.

CC9 — Risk Mitigation / Vendor Management

What to check:

• ●CC9.2 — Do you have a vendor risk register? Have you reviewed your critical vendors' security posture?
• Do critical vendors have their own SOC 2 reports?
• Do vendor contracts include security and data processing requirements?

The Readiness Scoring Model

After walking through each area, score yourself on a simple three-point scale:

| Score | Meaning | |---|---| | Green | Control is documented, operating, and evidence exists | | Amber | Control exists but is informal, undocumented, or inconsistently applied | | Red | Control does not exist or is critically deficient |

Count your reds and ambers. Reds are critical — fix these before the audit clock starts. Ambers are opportunities — improving these will improve your evidence quality during the audit.

Orion's Self-Assessment Score

After completing their assessment, Orion's scores looked like this:

| Area | Status | Key Gaps | |---|---|---| | CC1 — Control Environment | 🟡 Amber | No formal security RACI | | CC2 — Communication | 🟢 Green | Policies exist and distributed | | CC3 — Risk Assessment | 🔴 Red | No risk register | | CC4 — Monitoring | 🟡 Amber | Monitoring exists, reviews informal | | CC5 — Control Activities | 🟢 Green | Policies solid | | CC6 — Logical Access | 🔴 Red | Offboarding gaps, no access reviews | | CC7 — System Operations | 🟡 Amber | IR plan missing | | CC8 — Change Management | 🟡 Amber | Hotfix process gap | | CC9 — Risk Mitigation | 🔴 Red | No vendor register | | A1 — Availability | 🟡 Amber | DR plan exists, not tested |

3 reds, 5 ambers, 2 greens. That's a realistic picture for a company starting from scratch.

Their estimated remediation timeline: 14 weeks before they'd be comfortable starting the observation period.

What Comes Next

With their gap list in hand, Orion needed to choose their auditor — because the right auditor would also help them prioritise their remediation. In the next post, we'll cover how to pick a SOC 2 auditor and what nobody tells you about the process.