SOC 2 Gap Analysis Playbook: Identify and Close Compliance Gaps

At Agency, the gap analysis is where we start every SOC 2 engagement. Before we talk about platforms, auditors, or timelines, we need to understand exactly where an organization stands today. In our experience, this single step prevents more audit surprises than any other activity in the compliance process.

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. A well-executed gap analysis typically takes one to three weeks and produces a prioritized remediation roadmap that becomes the foundation of your entire SOC 2 preparation effort. 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.

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.

For a complete SOC 2 preparation framework, see the SOC 2 readiness playbook. For evidence collection requirements, see the evidence collection guide.

Gap Analysis Overview

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

• Before selecting a GRC platform: Understanding your current gaps helps you evaluate which platform features matter most for your environment
• Before engaging an auditor: Arriving at the audit with unresolved gaps leads to exceptions, delays, and increased auditor fees
• After significant infrastructure changes: Major migrations, acquisitions, or product launches may introduce new gaps
• Annually before Type II renewal: Even organizations with established SOC 2 programs should reassess gaps before each audit cycle

Step 1: Define Scope and Criteria

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. This criterion alone encompasses approximately sixty to seventy percent of the total SOC 2 control requirements.
• Availability: Adds controls for uptime commitments, capacity management, disaster recovery, backup procedures, and incident response for availability events.
• Processing Integrity: Adds controls for data processing accuracy, completeness, validity, and timeliness.
• Confidentiality: Adds controls for data classification, encryption, access restrictions, and confidential information handling.
• Privacy: Adds controls aligned with privacy principles — notice, choice, collection, use, access, disclosure, security, quality, and monitoring.

Step 2: 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:

1. Process walkthrough: "Walk me through how [process] works from start to finish." This reveals what actually happens versus what the policy says.
2. Evidence probe: "If an auditor asked to see evidence of this, what would we show them?" This reveals documentation gaps.
3. Exception handling: "What happens when the normal process doesn't work? What's the workaround?" This reveals informal practices that may create control gaps.
4. 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
Medium	Control exists with minor gaps; auditor may note as an observation	Moderate — unlikely to be an exception but may be flagged	Policies not formally approved, training completion below 100%, backup testing not documented
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	Complete within two weeks	Plan and begin within one week
Medium	Complete within two weeks	Complete within four weeks	Schedule for weeks three through six
Low	Complete within four weeks	Complete within six weeks	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	2-4 hours
No formal access review process	Define quarterly access review procedure; conduct first review; document results	8-16 hours
Branch protection not enabled	Enable branch protection rules on production repositories; require code review approval	1-2 hours
No centralized logging	Deploy logging solution or configure cloud-native logging; set retention period	4-12 hours
No documented risk assessment	Conduct formal risk assessment workshop; document risks, likelihood, impact, and treatment plans	8-20 hours
No vendor risk assessments	Build vendor inventory; send assessment questionnaires to critical vendors; document results	10-30 hours
Policies not approved	Route policies to management for formal approval; document approval with dates and signatures	4-8 hours
No incident response plan	Draft incident response plan; define roles, escalation procedures, communication templates	8-16 hours
No business continuity plan	Draft BCP; define critical systems, recovery priorities, communication procedures	12-24 hours
Security training not completed	Assign training to all employees; set deadline; track completion to 100%	4-8 hours (plus waiting for completion)
No penetration testing	Engage penetration testing firm; schedule and complete test; review and remediate findings	20-40 hours (plus vendor timeline)
Backup testing not documented	Perform backup restoration test; document results including time to restore and data integrity verification	4-8 hours

Step 6: Execute and Track Remediation

Execution Best Practices

1. Assign clear ownership: Every gap must have a single named owner — not a team, not a department, but an individual person accountable for closure
2. Set weekly check-ins: Hold a weekly fifteen-to-thirty-minute remediation standup to review progress, identify blockers, and adjust timelines
3. Close quick wins first: Completing low-effort, high-severity items immediately builds momentum and reduces audit risk
4. Document as you go: Capture evidence of remediation at the time it occurs — do not plan to "go back and document later"
5. 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
Total gaps closed	100% of critical and high; 90%+ of all gaps
Average days to close	Under fourteen days for critical; under thirty days for high

When to Engage Your Auditor

We recommend engaging your auditor after all critical and high-severity gaps are closed and at least eighty percent of medium-severity gaps are resolved. 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

Key Takeaways

• We consistently see that the gap analysis is the single highest-value activity in SOC 2 preparation — it takes one to three weeks and should be completed before engaging an auditor or selecting a GRC platform
• 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
• Critical and high-severity gaps must be fully resolved before audit engagement; we advise that medium gaps should be at least eighty percent resolved
• The most common gaps we see are in access reviews, risk assessment documentation, vendor management, and business continuity planning
• GRC platforms automate technical gap assessment but manual review is still required for process quality, policy accuracy, and organizational readiness
• What we recommend for tracking: monitor remediation progress weekly with clear ownership, effort estimates, and target dates for each gap

Frequently Asked Questions

How long does a SOC 2 gap analysis take?

Based on what we see across our engagements, a thorough gap analysis typically takes one to three weeks depending on organizational complexity. For a startup with a simple cloud environment and fewer than fifty employees, one week is usually sufficient. For a growth-stage company with multiple products, complex infrastructure, and one hundred or more employees, we typically plan for two to three weeks. The timeline includes stakeholder interviews, technical assessment, documentation review, gap categorization, and remediation planning.

Can I do a gap analysis without a GRC platform?

What we tell clients is yes, but the process requires more manual effort. Without a platform, you assess cloud configurations, access management, and endpoint compliance through direct review of each system's settings and logs. A spreadsheet or project management tool can track gaps and remediation. In our experience, the manual approach takes approximately forty to sixty percent longer than a platform-assisted assessment because the platform automates the technical scanning that otherwise requires manual configuration review.

What are the most common critical gaps for first-time organizations?

Based on what we see in our first-time engagements, the most frequently identified critical gaps are: (1) MFA not enforced for all users, (2) no formal access review process, (3) no documented risk assessment, (4) no centralized logging or security monitoring, and (5) no incident response plan. These five gaps appear in the majority of first-time gap assessments we conduct and represent the highest-priority remediation items. Most can be resolved within two to four weeks with focused effort.

Should I hire a consultant for the gap analysis?

What we tell clients is that a consultant adds the most value for first-time organizations that lack SOC 2 experience. An experienced advisor identifies gaps that internal teams may overlook — particularly in areas like risk assessment methodology, evidence quality requirements, and auditor expectations. For organizations with an experienced compliance lead who has completed SOC 2 engagements before, a self-directed gap analysis using a GRC platform is typically sufficient.

How does a gap analysis differ from a readiness assessment?

What we tell clients is that the terms are often used interchangeably, but a readiness assessment is broader in scope. A gap analysis specifically identifies where controls do not meet SOC 2 requirements. A readiness assessment includes the gap analysis plus evaluation of evidence quality, policy completeness, organizational preparedness, and audit timeline feasibility. Think of the gap analysis as the diagnostic component of the readiness assessment.