SOC 2 Gap Analysis Playbook: Find and Close Gaps
This playbook provides a step-by-step process for conducting a thorough SOC 2 gap analysis, including assessment frameworks, stakeholder interview techniques, technical evaluation checklists, gap categorization, and the creation of a prioritized remediation plan with realistic effort estimates. The target audience is compliance leads, security engineers, and CTOs who need a repeatable methodology for identifying and closing compliance gaps.
Key Takeaways
- •What we recommend first: define scope (systems, criteria, organizational boundaries) before assessing any controls
- •Inventory existing controls through documentation review and stakeholder interviews — in our experience, most organizations have more controls in place than they realize
- •Map existing controls to Trust Service Criteria to identify where coverage is complete, partial, or missing
- •We recommend classifying gaps by severity (critical, high, medium, low) and prioritizing remediation using a severity-effort matrix
- •Prioritize remediation by risk and confirm the effect of unresolved gaps with the auditor before committing to the engagement
A SOC 2 gap analysis is a structured assessment of your organization's current security controls, policies, and processes measured against the Trust Service Criteria defined by the AICPA. The purpose is to identify every area where your existing environment does not meet SOC 2 requirements — before your auditor finds them during fieldwork. In our experience, companies that skip or rush this step consistently encounter audit delays, evidence gaps, and exceptions that could have been identified and resolved months earlier.
For a complete SOC 2 preparation framework, see the SOC 2 readiness playbook. For evidence collection requirements, see the evidence collection guide.
For the next operating decision, compare SOC 2 compliance for startups with policies needed for SOC 2. Confirm the work included, the evidence you need, and who will own implementation before committing to a provider.
What does a SOC 2 gap analysis establish?
What a Gap Analysis Produces
| Output | Description |
|---|---|
| Current state assessment | Documented inventory of existing controls, policies, processes, and tools mapped to Trust Service Criteria |
| Gap inventory | Complete list of areas where current practices do not meet SOC 2 requirements |
| Severity classification | Each gap categorized by audit risk (critical, high, medium, low) |
| Remediation roadmap | Prioritized action plan with owners, effort estimates, and target completion dates |
| Resource requirements | Estimated hours, budget, and tooling needed to close all identified gaps |
When to Conduct a Gap Analysis
Conduct a gap analysis when defining a new assurance scope, changing a material service, or planning remediation before an examination. Revisit it when systems, customer commitments, or control ownership change. Use the results to sequence work and resolve dependencies before making delivery commitments.
How should you define the gap analysis scope?
Before assessing gaps, we recommend establishing the boundaries of your assessment.
Scope Definition
| Scope Element | What to Define |
|---|---|
| Systems in scope | Which products, platforms, and internal systems are included in the SOC 2 engagement |
| Trust Service Criteria | Which criteria you are including — Security (mandatory), plus any of Availability, Processing Integrity, Confidentiality, Privacy |
| Organizational boundaries | Which teams, departments, and business units are in scope |
| Third-party dependencies | Which vendors and subservice organizations are included in the scope |
| Data types | What categories of customer data are processed, stored, or transmitted by in-scope systems |
Criteria Selection Implications
Each Trust Service Criterion you include creates additional control requirements that must be assessed during the gap analysis:
- Security (Common Criteria): Required for all SOC 2 engagements. Covers access controls, change management, risk management, monitoring, logical and physical security, and system operations.
How do you inventory existing controls?
Before identifying gaps, we recommend documenting what controls already exist. Most organizations have more security controls in place than they realize — they simply are not documented or mapped to a compliance framework.
Control Inventory Approach
| Control Domain | What to Inventory | Where to Find Evidence |
|---|---|---|
| Access management | SSO configuration, MFA enforcement, user provisioning/deprovisioning, role-based access, admin account management | Identity provider dashboard, access logs, HR onboarding/offboarding records |
| Change management | Code review requirements, branch protection, deployment processes, change approval workflows | Git repository settings, CI/CD pipeline configuration, pull request history |
| Monitoring and logging | Centralized logging, alerting configuration, log retention, security event detection | SIEM or logging platform, alert rules, dashboards |
| Endpoint security | MDM deployment, disk encryption, OS patching, antivirus/EDR, screen lock | MDM console, endpoint agent reports, device inventory |
| Data protection | Encryption at rest and in transit, key management, data classification, backup configuration | Cloud provider settings, TLS certificates, backup logs |
| Network security | Firewall rules, network segmentation, VPN configuration, security groups | Cloud provider console, network diagrams, firewall configurations |
| Incident response | Incident response plan, communication templates, escalation procedures, post-incident review process | Policy documents, incident tracking system, post-mortem reports |
| Vendor management | Vendor inventory, risk assessments, contractual security requirements, review cadence | Vendor tracking spreadsheet or GRC platform, contracts, assessment records |
| HR security | Background checks, security training, acceptable use policy, termination procedures | HR system records, training platform completions, policy acknowledgments |
| Risk management | Risk assessment documentation, risk register, risk treatment plans, risk review cadence | Risk assessment documents, governance meeting notes |
Stakeholder Interviews
We recommend interviewing key stakeholders across the organization to understand current practices that may not be documented:
| Stakeholder | Interview Focus |
|---|---|
| CTO / VP Engineering | Architecture overview, change management practices, deployment processes, infrastructure decisions |
| Engineering leads | Code review practices, testing procedures, incident response, on-call rotation |
| IT / DevOps | Cloud configuration, monitoring setup, access provisioning, endpoint management |
| HR | Onboarding process, background check procedures, termination workflow, training programs |
| Security (if exists) | Vulnerability management, penetration testing, incident response, security tool stack |
| CEO / Founder | Risk tolerance, compliance budget, business context, customer requirements |
Interview Technique
For each stakeholder, use this structure:
- Process walkthrough: "Walk me through how [process] works from start to finish." This reveals what actually happens versus what the policy says.
- Evidence probe: "If an auditor asked to see evidence of this, what would we show them?" This reveals documentation gaps.
- Exception handling: "What happens when the normal process doesn't work? What's the workaround?" This reveals informal practices that may create control gaps.
- Frequency and consistency: "How often does this happen? Is it the same every time?" This reveals whether processes are repeatable and consistent.
Step 3: Map Controls to Trust Service Criteria
With your control inventory complete, map each existing control to the specific Trust Service Criteria points it satisfies.
Common Criteria Mapping
| TSC Category | Key Control Requirements | Typical Gaps |
|---|---|---|
| CC1 (Control Environment) | Governance structure, management oversight, organizational structure, commitment to competence | Missing board or management oversight documentation, no formal organizational chart, undefined compliance roles |
| CC2 (Communication and Information) | Internal and external communication procedures, system descriptions, policy distribution | Policies not distributed to all employees, no system description document, missing external communication procedures |
| CC3 (Risk Assessment) | Formal risk assessment, risk register, risk monitoring | No documented risk assessment, no risk register, risk assessment not updated annually |
| CC4 (Monitoring Activities) | Ongoing control monitoring, exception tracking, remediation processes | No continuous monitoring, no exception tracking process, manual monitoring without documentation |
| CC5 (Control Activities) | Logical access controls, authentication mechanisms, data protection measures | Incomplete MFA enforcement, no access review process, missing encryption on some data stores |
| CC6 (Logical and Physical Access) | User provisioning, authentication, physical access controls, data transmission security | Shared accounts, no deprovisioning process, missing physical access logs |
| CC7 (System Operations) | Monitoring and detection, incident management, change management, backup and recovery | No centralized logging, undocumented incident response, missing backup testing records |
| CC8 (Change Management) | Change authorization, testing, deployment controls | No code review requirement, missing staging environment, no rollback procedures |
| CC9 (Risk Mitigation) | Vendor management, business continuity, insurance | No vendor risk assessments, no business continuity plan, no DR testing records |
If you are using a GRC platform, the platform's control framework provides this mapping automatically. If you are conducting the gap analysis manually, use the AICPA Trust Service Criteria documentation as your reference.
Step 4: Identify and Categorize Gaps
Gap Identification Process
For each Trust Service Criteria point, evaluate whether your existing controls fully satisfy the requirement:
| Assessment Status | Definition |
|---|---|
| Satisfied | An existing control fully meets the requirement with documented evidence available |
| Partially satisfied | A control exists but is incomplete — the practice occurs but is not documented, or the control does not cover the full scope |
| Not satisfied | No control exists that addresses this requirement |
| Not applicable | The requirement does not apply to your environment (must be justified and documented) |
Gap Severity Classification
| Severity | Definition | Audit Risk | Examples |
|---|---|---|---|
| Critical | No control exists for a core requirement; would result in a significant exception | High — auditor will issue an exception | No MFA enforcement, no logging enabled, no access review process |
| High | Control exists but has a significant weakness; auditor likely to flag | Moderate-high — may result in an exception or observation | MFA enabled but not enforced for all users, logs exist but no alerting, access reviews done informally |
| Low | Control exists with documentation gaps only; easily remediated | Low — addressable before audit | Missing version dates on policies, incomplete vendor inventory, missing organizational chart |
Common Gaps by Category
| Category | Most Frequent Gaps |
|---|---|
| Access management | No formal access review process, shared admin accounts, deprovisioning delays, incomplete MFA enforcement |
| Change management | No branch protection on production repositories, no staging environment, undocumented deployment process |
| Monitoring | No centralized logging, no security alerting, insufficient log retention period |
| Risk management | No formal risk assessment document, no risk register, risk assessment not reviewed annually |
| Vendor management | No vendor inventory, no risk assessments for critical vendors, no contractual security requirements |
| HR security | Incomplete background checks, security training not completed by all employees, no formal termination checklist |
| Incident response | No documented incident response plan, no post-incident review process, no incident communication templates |
| Business continuity | No business continuity plan, no disaster recovery testing, no documented RTO/RPO |
| Data protection | Unencrypted data stores, no data classification policy, missing encryption in transit for internal services |
| Policy and documentation | Policies not approved by management, policies not distributed, no policy acknowledgment tracking |
Step 5: Build the Remediation Roadmap
Prioritization Framework
We recommend prioritizing gaps using a matrix of severity and effort:
| Low Effort (under 4 hours) | Medium Effort (4-20 hours) | High Effort (20+ hours) | |
|---|---|---|---|
| Critical | Do immediately | Do this week | Start immediately; plan for phased completion |
| High | Do this week | Depends on scope and readiness | Depends on scope and readiness |
| Medium | Depends on scope and readiness | Depends on scope and readiness | Schedule for weeks three through six |
| Low | Depends on scope and readiness | Depends on scope and readiness | Schedule based on available capacity |
Remediation Plan Template
For each gap, we recommend documenting the following:
| Field | Description |
|---|---|
| Gap ID | Unique identifier for tracking |
| TSC reference | Which Trust Service Criteria point this gap relates to |
| Gap description | Clear statement of what is missing or insufficient |
| Severity | Critical, high, medium, or low |
| Current state | What exists today |
| Target state | What must be in place to satisfy the requirement |
| Remediation actions | Specific steps to close the gap |
| Owner | Person responsible for remediation |
| Effort estimate | Hours required to complete remediation |
| Dependencies | Any prerequisites or dependencies on other teams or tools |
| Target completion date | Deadline for remediation |
| Evidence required | What evidence the auditor will need to verify the gap is closed |
Common Remediations and Effort Estimates
| Gap | Remediation | Effort Estimate |
|---|---|---|
| MFA not enforced for all users | Configure MFA requirement in identity provider; verify enforcement | Depends on scope and readiness |
| No formal access review process | Define quarterly access review procedure; conduct first review; document results | Depends on scope and readiness |
| Branch protection not enabled | Enable branch protection rules on production repositories; require code review approval | Depends on scope and readiness |
| No centralized logging | Deploy logging solution or configure cloud-native logging; set retention period | Depends on scope and readiness |
| No documented risk assessment | Conduct formal risk assessment workshop; document risks, likelihood, impact, and treatment plans | Depends on scope and readiness |
| No vendor risk assessments | Build vendor inventory; send assessment questionnaires to critical vendors; document results | Depends on scope and readiness |
| Policies not approved | Route policies to management for formal approval; document approval with dates and signatures | Depends on scope and readiness |
| No incident response plan | Draft incident response plan; define roles, escalation procedures, communication templates | Depends on scope and readiness |
| No business continuity plan | Draft BCP; define critical systems, recovery priorities, communication procedures | Depends on scope and readiness |
| No penetration testing | Engage penetration testing firm; schedule and complete test; review and remediate findings | Depends on scope and readiness |
| Backup testing not documented | Perform backup restoration test; document results including time to restore and data integrity verification | Depends on scope and readiness |
Step 6: Execute and Track Remediation
Execution Best Practices
- Assign clear ownership: Every gap must have a single named owner — not a team, not a department, but an individual person accountable for closure
- Set weekly check-ins: Hold a weekly fifteen-to-thirty-minute remediation standup to review progress, identify blockers, and adjust timelines
- Close quick wins first: Completing low-effort, high-severity items immediately builds momentum and reduces audit risk
- Document as you go: Capture evidence of remediation at the time it occurs — do not plan to "go back and document later"
- Test controls after implementation: Verify that remediated controls work as intended before marking them complete
Tracking Progress
Track remediation progress using your GRC platform's task management features or a dedicated tracking system. Key metrics to monitor:
| Metric | Target |
|---|---|
| Critical gaps remaining | Zero before audit engagement |
| High gaps remaining | Zero before audit engagement |
| Medium gaps remaining | Less than five before audit engagement |
| Remediation age | Track time open against risk-based deadlines approved by the responsible owner |
When to Engage Your Auditor
Discuss unresolved gaps with the auditor, including their severity, scope, operating history, and effect on the planned engagement. A percentage of closed tasks is not a readiness threshold. Engaging too early — while significant gaps remain — risks audit delays and higher fees as the auditor encounters evidence gaps during fieldwork.
For a fixed-deadline preparation plan, see the 90-day SOC 2 Type I preparation plan.
Using GRC Platforms for Gap Analysis
GRC platforms like Vanta, Drata, Secureframe, and Sprinto automate significant portions of the gap analysis process by connecting to your infrastructure and automatically assessing control status.
What Platforms Automate
| Assessment Area | Platform Automation |
|---|---|
| Cloud configuration | Scans AWS, Azure, GCP for encryption, access policies, logging, network security |
| Identity and access | Checks MFA enforcement, user roster, inactive accounts, admin access |
| Endpoint compliance | Verifies disk encryption, OS updates, antivirus, screen lock via agent |
| Code repository security | Checks branch protection, code review requirements, secret scanning |
| Policy management | Tracks policy creation, approval, distribution, and acknowledgment |
What Still Requires Manual Assessment
| Assessment Area | Why Manual Review Is Needed |
|---|---|
| Risk assessment quality | Platforms track completion but cannot evaluate whether the risk assessment is thorough |
| Vendor risk assessments | Platforms track vendor inventory but assessment quality depends on questionnaire depth |
| Incident response capability | Platforms cannot test whether your team can actually execute the incident response plan |
| Business continuity planning | Platforms track documentation but cannot evaluate DR testing adequacy |
| Policy accuracy | Platforms distribute policies but cannot verify that policy content reflects actual practices |
| Organizational culture | No platform can assess whether security practices are consistently followed in daily operations |
AICPA & CIMA’s SOC overview describes CPA assurance services. It defines the assurance context; it does not establish vendor rankings, market prices, or a particular company’s readiness.
Frequently Asked Questions
How do you scope a SOC 2 gap analysis?
Why inventory existing controls before finding gaps?
How do you map controls to Trust Service Criteria?
Can a GRC platform run your gap analysis?
Tyler Carbone
Managing Director and Cofounder
Tyler Carbone is a Managing Director and Cofounder of Agency and one of the industry's leading voices on governance, risk, and compliance. He holds degrees from Harvard and a JD/MBA from the University of Virginia, and previously worked in cybersecurity at Deloitte. Tyler has helped hundreds of companies operate SOC 2, ISO 27001, HIPAA, and GDPR programs.
LinkedIn
