SOC 2 Gap Analysis: How to Find and Fix Every Gap

What Is a SOC 2 Gap Analysis?

A SOC 2 gap analysis is a structured assessment of your current security controls against the SOC 2 Trust Services Criteria. For each criterion, you evaluate: does a control exist? Is it implemented? Is there evidence of operation? Does the control design match the criterion requirement?

The output is a gap list: criteria where your current state does not meet the SOC 2 requirement. Each gap should include: the specific criterion, the nature of the gap (design gap vs. operating gap), the remediation required, an owner, and a target completion date.

Gap analysis precedes your audit engagement — it is internal work that shapes your preparation timeline and helps you engage an auditor at the right moment (when major gaps are closed).

Gap Analysis Methodology

Step 1: Map criteria. Create a spreadsheet or use a compliance tool (AuditPath includes a gap analysis dashboard) with every SOC 2 criterion in your selected scope as a row.

Step 2: For each criterion, describe your current control (if any). Be honest — describe what actually exists, not what should exist.

Step 3: Evaluate against the criterion requirement. Is the current control sufficient in design? Is it actually operating? Is there evidence of operation?

Step 4: Classify each row: No Gap (control exists, operating, evidenced), Design Gap (control does not exist or is insufficiently designed), Operating Gap (control exists but not operating consistently), Evidence Gap (control operating but not documented).

Step 5: For each gap, document the remediation required, assign an owner, and estimate time to close.

CC1 and CC2: Governance and Communication

CC1 (Control Environment): does management demonstrate commitment to security? Common gaps: no formal information security policy, no security training programme, no documented security responsibilities in job descriptions.

CC2 (Communication and Information): are security policies communicated to personnel? Common gaps: policies exist but are not formally distributed to employees, no evidence of employee acknowledgement, no formal communication to third parties of relevant policies.

Remediation for CC1–CC2 gaps is primarily documentation and process: draft and approve the ISP, distribute to all employees, collect acknowledgements, and build a security awareness training programme.

CC6: Logical and Physical Access

CC6 is the most commonly tested and most commonly found with gaps in first-time SOC 2 engagements. Key gaps: no formal access review process (CC6.2/CC6.3), no documented procedures for terminating access (CC6.2), no MFA enforcement for all users with production access (CC6.1), no documented process for requesting and approving access (CC6.1).

Physical access (CC6.4–CC6.5): most SaaS companies use cloud-only infrastructure, so physical access controls are largely delegated to AWS/GCP/Azure. Document this delegation clearly — your cloud provider's SOC 2 report covers physical controls, and you should reference it explicitly.

Remediation priorities: implement MFA (often same-day if you use Okta or Google Workspace), document your access review process and conduct a first review, build a termination checklist and offboarding process.

CC7, CC8, CC9: Operations and Risk

CC7 (System Operations and Monitoring): common gaps include no vulnerability management programme (no scheduled scans, no remediation SLAs), no formal incident response plan, no security event monitoring (GuardDuty or equivalent not enabled), and no penetration test history.

CC8 (Change Management): common gaps include no formal change approval process (production deployments happen without required reviews), no documented emergency change procedure, and no record of change approvals in ticketing system.

CC9 (Risk Mitigation): most common gap is no vendor risk register and no formal vendor security review process. Secondary gap: no documented business continuity plan or backup restore testing.

Prioritising the Remediation Backlog

Not all gaps are equal. Prioritise by: audit risk (high — gaps that are certain to generate Type II exceptions), implementation effort (low-effort quick wins vs. long-lead items), and business risk (which gaps create the most exposure to actual security incidents).

High priority, quick wins: enable GuardDuty and Security Hub (same day), enforce MFA in Okta/Google Workspace (same day to 1 week), create vendor register with top 10 vendors (2 days), configure CloudTrail multi-region (1 day).

High priority, longer effort: write and approve 12+ policies (3–6 weeks), establish and conduct first access review (2 weeks), document and implement change management process (2 weeks), schedule and complete penetration test (6–10 weeks for scheduling + execution).

From Gap Analysis to Audit Readiness

Typical gap analysis to Type I readiness: 60–90 days for companies with moderate existing security maturity, 90–120 days for companies starting from minimal baseline.

Key milestone: all CC6 (access) and CC7 (monitoring) gaps closed before you engage your auditor for fieldwork. These are the most commonly tested criteria and the most frequently found with exceptions.

Engage your auditor during or immediately after gap analysis, not at the end. Their input on your remediation plan can prevent you from building controls that do not meet their testing criteria.