A gap analysis before your audit isn't optional — it's the difference between a clean Type II report and six months of remediation that delays your enterprise deals. This guide covers what each Trust Services Criteria domain actually requires, what evidence auditors look for, and the gaps that cause first-time assessments to fail.

Run it twice

At least 6 months before your target audit date, then again 30–60 days before. The gap between those two runs tells you whether your remediation is on track.

What a SOC 2 Gap Analysis Is (and Isn't)

A gap analysis compares what your controls require — the SOC 2 Trust Services Criteria — against what you currently have implemented. The output is a prioritized list of what needs to be fixed before an auditor looks at your environment.

  • It is: a map of where you stand today vs. where you need to be, a prioritized remediation roadmap, and a realistic timeline for submitting to audit
  • It is not: a penetration test, a security assessment, or a guarantee that you'll pass

SOC 2 Trust Services Criteria — What Each Area Requires

Every SOC 2 audit covers Security (the Common Criteria). Availability, Confidentiality, Processing Integrity, and Privacy are added only if your product specifically commits to them in customer contracts.

Security — Common Criteria (CC)

CC1

Control Environment

Does your organization have a formal security program? Documented policies, defined security roles, a risk assessment process, a vendor management program. Auditors want to see that security is managed, not improvised.

  • Information security policy in place and reviewed in the past 12 months
  • Security roles defined (CISO, security team, or designated security owner)
  • Background screening for employees with access to sensitive systems
  • Code of conduct or acceptable use policy signed by all employees
CC2

Communication & Information

Do you communicate security requirements to employees and customers? This includes security awareness training, policy communication to new employees, and customer-facing commitments that match what's actually implemented.

  • Security awareness training completed by all employees, with completion records
  • New employee onboarding covers security policies
  • Customer-facing security commitments match what's actually implemented (your trust page isn't aspirational)
CC3

Risk Assessment

Do you formally identify, analyze, and respond to risk? Auditors won't expect enterprise-grade risk management from an early-stage company — but they do expect a documented process.

  • Risk assessment conducted in the past 12 months with documented output
  • Risks categorized by likelihood and impact
  • Mitigation decisions documented (accepted, transferred, mitigated, avoided)
CC4

Monitoring

Do you monitor controls to verify they're working? This includes internal audits, control reviews, and acting on findings.

  • Periodic review of access rights (quarterly or annual access certification)
  • Monitoring process for vendor risk
  • Documented response to identified control deficiencies
CC5

Control Activities

Are you actually doing what your policies say? The gap between documented policy and actual practice is where most audits find findings. If your policy says access is reviewed quarterly and you haven't done a review in 18 months, that's a finding regardless of how good the policy looks.

  • Access review completed within the audit period
  • Change management process followed for all production changes (with evidence — tickets, approvals)
  • Vendor security reviews completed for third-party processors
CC6

Logical and Physical Access Controls

This is where most technical findings live. CC6 covers who can access what, how access is granted and revoked, and how data is protected. It's the most checklist-intensive criteria and the one most audits scrutinize hardest.

  • Multi-factor authentication enforced for all production systems
  • MFA enforced for email and collaboration tools (Google Workspace, Microsoft 365)
  • Access provisioning requires documented approval
  • Access revoked within 24 hours of termination (with evidence — offboarding tickets with timestamps)
  • Privileged access (admin, root) is separate from day-to-day access and logged
  • Encryption at rest: production databases, backups, object storage
  • Encryption in transit: TLS 1.2+ enforced, no HTTP fallback
  • Network segmentation: production environment isolated from development and corporate networks
  • Remote access secured via VPN or zero-trust
CC7

System Operations

Do you monitor for threats and respond to them?

  • Vulnerability scanning on a regular cadence (quarterly minimum)
  • Critical vulnerabilities remediated within defined SLA (30 days for critical is standard)
  • Security monitoring and alerting in place (SIEM or equivalent)
  • Incident response plan documented
  • Incident response tested (tabletop exercise) within the past 12 months
CC8

Change Management

Are changes to the system controlled? The most common version of this finding: engineers merging their own PRs to production with no second reviewer.

  • All production changes go through a formal process (PR review, CAB approval, or equivalent)
  • Emergency changes are documented and retroactively approved
  • Software deployed to production is tested in a non-production environment first
  • Separation of duties: the person who writes code isn't the only one who approves it going to production
CC9

Risk Mitigation — Vendor Management

Do you manage third-party and vendor risk? Every SaaS tool that touches production or customer data is a vendor that needs to be tracked.

  • Vendor list maintained with security tier designation
  • SOC 2 reports or security questionnaires obtained from critical vendors
  • Data processing agreements (DPAs) in place for vendors that process customer data
  • Vendor access to production systems requires MFA and is logged

Availability Criteria (A)

Add if your product has uptime commitments in customer contracts or SLAs.

  • Uptime monitoring with alerting
  • Incident communication process documented and tested
  • RTO and RPO defined and tested
  • Business continuity and disaster recovery plan documented and tested within 12 months
  • Critical components have no single point of failure

Confidentiality Criteria (C)

Add if you handle information customers designate as confidential.

  • Confidential information identified and classified
  • Confidential information encrypted at rest and in transit
  • Confidential information disposed of securely on contract termination
  • NDA/confidentiality agreements with employees and relevant vendors

The 10 Most Common SOC 2 Gaps

Based on what shows up in first-time assessments, in order of frequency:

  1. 1
    No access review in the past 12 months The most common finding, period. CC5 requires periodic access certification. Schedule quarterly reviews and make sure they happen — the calendar invite isn't evidence, the completed review with a ticket and names is.
  2. 2
    MFA not enforced everywhere One system without MFA — a legacy admin interface, an internal tool, a developer's direct database access — creates a finding for CC6. Auditors check all systems in scope, not just the ones you highlight.
  3. 3
    Offboarding is manual and slow If you can't show that departed employees had access revoked within 24 hours — with a ticket, timestamp, and confirmation — you have a CC6 finding. Automate offboarding or build a checklist with evidence capture.
  4. 4
    Policies exist but aren't followed If your change management policy requires two approvals but engineers are merging their own PRs, the policy actually creates the finding. The gap between what's documented and what's practiced is where auditors look hardest.
  5. 5
    Vulnerability scans aren't happening or aren't authenticated Unauthenticated scans miss most findings. Results need to be tracked to remediation. If scans are running quarterly but you can't show the findings were closed, auditors treat it the same as no scanning.
  6. 6
    No documented incident response test Having an IR plan isn't enough. You need evidence that you tested it — a tabletop exercise writeup with date and participant names. "We reviewed it" is not a test.
  7. 7
    Vendor list is incomplete or unreviewed Auditors will ask for the complete list of third-party services that touch production or customer data, and evidence that critical vendors have been security-reviewed. Most companies undercount their vendor list by 40–60%.
  8. 8
    Log retention is too short SOC 2 Type II covers a 12-month audit period. If logs are retained for 90 days, you can't support the full period. Most auditors want at minimum 12 months of retention for security-relevant logs.
  9. 9
    Production and development environments aren't separated Developers with direct production database access, shared credentials between environments, or code deploying directly from developer machines without CI/CD — all CC6 findings.
  10. 10
    Security training has no records Completing training doesn't count if you can't prove who completed it and when. Completion certificates, LMS records, or even a signed acknowledgment with a date — something with names and timestamps.

Related reading: The hidden complexity of AI agent orchestration

Run your SOC 2 gap analysis in one conversation.

The GRC Assessment Pack includes a gap analyst agent that runs a structured domain-by-domain assessment, scores each control (Implemented / Partial / Gap), generates a prioritized remediation roadmap, and cross-maps to ISO 27001 and NIST CSF simultaneously.

framework-mapper gap-analyst evidence-collector policy-drafter risk-register-manager audit-report-generator
Get GRC Assessment Pack — $149/mo → Read more posts