SOC 2 Gap Analysis: What It Covers and How to Prepare
Babar Khan Akhunzada
February 23, 2026
If you've just been told a customer needs you to complete a SOC 2 audit, or you're preparing for one for the first time, a gap analysis is where you should start before you hire an auditor, before you buy compliance software, and before you spend money fixing things that may not need fixing.
A SOC 2 gap analysis tells you exactly where you stand: what controls you already have in place, what's missing, and what has to be built before an auditor can evaluate it. Done well, it's the difference between a focused 90-day sprint to audit-ready and a sprawling 12-month effort that still ends with findings you didn't see coming.
This article explains what a gap analysis actually covers, how to run one, what the output should look like, and the mistakes that most organizations make the first time through.
- What Is a SOC 2 Gap Analysis?
- What a SOC 2 Gap Analysis Actually Covers
- How to Prepare Before Your Gap Analysis
- What Good Gap Analysis Output Looks Like
- The Most Common SOC 2 Gaps — and What They Mean
- From Gap Analysis to Audit-Ready: What Comes Next
- Start Your SOC 2 Gap Analysis
What Is a SOC 2 Gap Analysis?
A SOC 2 gap analysis is a structured assessment of your organization's current security controls against the AICPA's Trust Services Criteria the framework that defines what SOC 2 auditors evaluate. The goal is simple: find the distance between where you are now and where you need to be to pass an audit.
It's not an audit. It doesn't produce a SOC 2 report or any kind of certification. What it produces is a roadmap a clear list of what exists, what doesn't, and what needs to be built, documented, or improved before you're ready for a formal assessment.
Most organizations need a gap analysis because they have more security controls in place than they realize (informal processes that just aren't documented) and more gaps than they expect (particularly around access reviews, change management, and logging). The analysis surfaces both.
Who should run a SOC 2 gap analysis:
The gap analysis is typically conducted either by your internal security or compliance team, or by an external consultant. Each has tradeoffs. An internal assessment is faster and cheaper but tends to be more optimistic teams underreport gaps in areas they own. An external assessment is more objective and produces output that carries more weight with auditors and customers, but costs more and takes longer to schedule.
For most organizations pursuing SOC 2 for the first time, a lightweight external gap analysis even a focused half-day session with a consultant who knows the Trust Services Criteria well is worth the cost. It surfaces the structural gaps your team will miss because they're too close to the systems.
What a SOC 2 Gap Analysis Actually Covers
The scope of a gap analysis maps directly to the Trust Services Criteria your audit will cover. For most companies, that's the Security (CC) criteria required for every SOC 2 report. Additional criteria like Availability, Confidentiality, Processing Integrity, and Privacy are optional and included only if your customers require them.
Here's what gets evaluated across each major control area:
Access Control (CC6.1–CC6.3)
Who has access to what, and how is that access managed? The gap analysis looks at whether you have formal access provisioning and deprovisioning processes, whether you conduct periodic access reviews (typically quarterly or annually), how privileged access is controlled, and whether multi-factor authentication is enforced for critical systems.
This is the area where most organizations have the most informal controls. Engineers were given access when they joined and it was never reviewed. A contractor left six months ago and their account is still active. These aren't malicious failures they're process failures. The gap analysis finds them.
Change Management (CC8.1)
Do code changes go through a documented review process before reaching production? The evaluator looks for evidence of pull request reviews, separation of duties between developers and production deployments, and rollback procedures. Startups with small engineering teams frequently have gaps here one engineer reviewing their own code, or direct pushes to production with no review trail.
Risk Assessment (CC3.1–CC3.4)
Have you formally identified and documented the risks to your systems and data? SOC 2 requires an ongoing risk management program, not just a one-time assessment. The gap analysis checks whether you have a documented risk register, a defined process for identifying new risks, and evidence that risks are reviewed and updated regularly.
Monitoring and Logging (CC7.1–CC7.2)
Are you collecting logs from the systems that matter — cloud infrastructure, application layer, authentication events — and are those logs being monitored? The gap analysis evaluates log coverage, alert rules, SIEM or log aggregation tooling, and whether there's any evidence of human review or automated response.
This is also where your penetration testing posture gets evaluated. If you don't have evidence of regular technical security testing, that gap shows up here under CC4.1 (ongoing monitoring of controls). We cover what auditors specifically expect from pentesting in our SOC 2 penetration testing requirements guide.
Vendor and Third-Party Management (CC9.2)
Do you know which third-party vendors have access to your systems or customer data? Do you have a process for evaluating their security posture before onboarding? The gap analysis checks for a vendor inventory, security questionnaire or review process, and evidence that high-risk vendors are monitored over time.
Incident Response (CC7.3–CC7.5)
Do you have a documented incident response plan? Has it been tested? The gap analysis looks for a written IRP with defined roles, escalation paths, and communication procedures and some evidence that the team knows it exists and how to execute it. A plan that lives in a Google Doc nobody has read doesn't satisfy this control.
Business Continuity and Backup (A1.2–A1.3)
If Availability is in scope, the gap analysis evaluates whether you have tested backup procedures, documented recovery time objectives (RTOs) and recovery point objectives (RPOs), and evidence that backups are tested rather than just assumed to work.
Policies and Procedures
Across all control areas, the gap analysis checks whether you have written policies that reflect how your organization actually operates. This is where many organizations discover their biggest gap: policies written two years ago by an external consultant that bear no resemblance to current systems or processes.
How to Prepare Before Your Gap Analysis
A gap analysis moves faster and produces more useful output when you've done some groundwork before it starts. Here's what to have ready:
A system inventory. Know what systems are in scope: your primary product, the infrastructure it runs on, the databases that store customer data, and the third-party services with access to that data. The gap analysis can't evaluate what it doesn't know about.
An asset list for access reviews. A rough inventory of who has access to which systems even a spreadsheet gives the analyst something to work from when evaluating your access control posture. Without it, the access control assessment becomes speculative.
Existing policies and procedures. Pull together whatever written security policies you have, even if they're incomplete or outdated. They give the analyst a baseline to compare against actual practice.
Your most recent pentest report, if you have one. If you've run a penetration test in the last 12 months, the findings are directly relevant to the gap analysis — specifically to the CC4.1 monitoring and CC7.1 threat detection controls. If you don't have one, that's a gap that will show up anyway.
A contact who knows the engineering environment. The most useful gap analysis interviews involve someone who can answer questions about how code is deployed, how access is provisioned, and how incidents are handled. If that's you, great. If not, schedule time with whoever it is.
What Good Gap Analysis Output Looks Like
A gap analysis that produces a 50-page compliance report isn't necessarily more useful than one that produces a clear two-page prioritized list. What matters is the output being actionable not impressive.
Good gap analysis output includes:
A control-by-control status. For each Trust Services Criteria control in scope, a clear status: implemented and evidenced, partially implemented, not implemented, or not applicable. No ambiguity.
Gap descriptions that explain the risk, not just the finding. "No formal access review process" is a finding. "No formal access review process means terminated employees or inactive contractors may retain access to production systems containing customer data" is a gap description that helps your team understand why it matters and prioritize accordingly.
A prioritized remediation list. Not all gaps are equal. Some will block your audit entirely if not addressed. Others are important but can be managed as ongoing improvements. Good output separates the audit-blockers from the continuous improvement items.
Effort estimates. A rough sense of how long each remediation will take days, weeks, or months helps you build a realistic timeline to audit-ready. Gaps that require policy documentation are fast. Gaps that require tooling procurement, configuration, and evidence accumulation take longer.
An honest timeline to Type I or Type II readiness. Given the gaps identified, how long does it realistically take to be ready for a Type I audit (point-in-time)? For a Type II audit (12-month operating period), the clock starts when your controls are operating so an early gap analysis has a direct impact on when you can achieve Type II.
The Most Common SOC 2 Gaps — and What They Mean
After running SOC 2 gap analyses across dozens of SaaS companies, certain gaps show up almost universally. These aren't failures they're the natural consequence of building a product fast without a compliance function. But they are the gaps that consistently surprise teams when they first see them documented.
No formal access review process. By far the most common. Most companies provision access correctly but never review it. The fix is straightforward a quarterly or annual review process with a documented sign-off but it takes time to implement and more time to generate evidence of operating over a period.
Outdated or non-existent security policies. Policies that reference systems or processes that no longer exist, or that were written as templates and never customized to reflect how the company actually operates. Auditors test whether policies match practice — gaps between them are findings.
No penetration test or testing older than 12 months. Under CC4.1, SOC 2 auditors expect evidence of ongoing technical security evaluation. A pentest that's 18 months old doesn't satisfy the "ongoing" requirement. If you're in this position, scheduling a pentest early in your remediation process rather than right before the audit — gives you time to remediate findings and generate retest evidence. See our SOC 2 pentest cost guide for what to budget.
Logging coverage gaps. Logs exist for some systems but not all. Authentication events from your identity provider are captured, but application-layer events aren't. Cloud infrastructure changes aren't logged at all. Auditors test log coverage not just whether you have a SIEM, but whether the right events are flowing into it.
No vendor security review process. New SaaS tools get added to the stack without any documented security evaluation. By the time the gap analysis runs, there are 40 third-party integrations with access to production data and no record of any of them being assessed.
Incident response plan exists but isn't tested. The document is there. Nobody has read it in two years. There are no tabletop exercises, no defined escalation contacts, and the communication plan references a Slack channel that was archived. The fix requires both updating the document and generating evidence of a test which takes time to schedule.
From Gap Analysis to Audit-Ready: What Comes Next
A gap analysis is only useful if it drives action. Once you have the output, here's the typical sequence to audit-ready:
Remediate audit-blockers first. Address the controls that an auditor cannot accept findings on typically access control documentation, logging coverage, change management evidence, and the penetration test. These have the longest implementation timelines and need to start immediately.
Build your evidence library in parallel. SOC 2 audits are evidence-driven. For every control you implement, start collecting evidence as soon as the control is operating: screenshots of access reviews, pull request logs, vendor questionnaire records, pentest reports with retest documentation. The evidence clock starts when the control starts.
Schedule your Type I audit when the major gaps are closed. A Type I audit evaluates whether controls are designed correctly at a point in time. It doesn't require an operating history so once the audit-blockers are remediated, you can pursue Type I. Most organizations take 60–120 days from gap analysis to Type I readiness, depending on the volume of gaps.
Start the Type II clock. Your Type II audit covers a defined period typically 6 or 12 months during which your controls must be operating consistently. The earlier you close the major gaps and start that period, the sooner you can achieve Type II. Organizations that run the gap analysis late lose months on the Type II clock.
Pentest timing matters here specifically. If your gap analysis reveals you don't have a current pentest, schedule it early in the remediation process. Critical findings need remediation time, and retest evidence needs to be generated before the audit window closes. For organizations going through SOC 2 for the first time, see our full SOC 2 compliance services page for how we support the end-to-end process.
SOC 2 Gap Analysis Isn't Glamorous
A SOC 2 gap analysis isn't glamorous but it's the most cost-effective thing you can do before starting a compliance program. It tells you what you actually need to build versus what you already have. It prevents you from spending time and money remediating gaps that don't exist while missing the ones that will block your audit. And it gives you a realistic timeline rather than an optimistic guess.
The organizations that get to SOC 2 fastest aren't the ones with the fewest gaps. They're the ones who found out about their gaps earliest and had time to address them without a deadline breathing down their neck.
Start Your SOC 2 Gap Analysis
Related reading:
- SOC 2 Compliance Services
- SOC 2 Penetration Testing Requirements 2026
- SOC 2 Pentest Cost: What to Budget
- PTaaS: The Complete Buyer's Guide
SOC 2, Gap Analysis, SOC 2 Readiness, Trust Services Criteria, Compliance, SaaS Security, Audit Preparation
Tags
About Babar Khan Akhunzada
Babar Khan Akhunzada is Founder of SecurityWall. He leads security strategy, offensive operations. Babar has been featured in 25-Under-25 and has been to BlackHat, OWASP, BSides premiere conferences as a speaker.