SOC 2 gap analysis: what the audit scope misses and attackers find anyway
Julian ThorneApril 29, 2026
Key takeaways
SOC 2 is the only major compliance framework where the audited organization defines its own scope boundary. The gap analysis measures what is inside that boundary -- not what was excluded from it.
In Vulnox gap analysis engagements, the most common finding is not a missing control inside scope. It is infrastructure that was deliberately or accidentally left out of scope and is externally accessible.
SOC 2 Type 2 requires a minimum six-month observation period after controls are implemented. Organizations that compress timelines do so by narrowing scope, not by closing gaps faster.
Staging environments, developer tooling, and third-party integrations are the three categories most frequently excluded from SOC 2 scope and most frequently found in external attack surface assessments as live and under-controlled.
A clean SOC 2 Type 2 report does not confirm the absence of exploitable exposure. It confirms that controls functioned within a defined perimeter during a defined period. Those are different claims.
TL;DR
SOC 2 gap analysis is valuable. The problem is that most organizations conduct it inside a scope boundary they drew themselves, often to minimize what the auditor sees. The gaps that matter -- the ones attackers find -- are usually just outside that boundary. A SOC 2 gap analysis that does not interrogate the scoping decisions is a compliance exercise, not a security one. Both have value. They are not the same thing.
The audit passed. The breach used the staging environment.
A 60-person SaaS company in Dublin received a clean SOC 2 Type 2 report in March 2024. The report covered their production environment: the application, the database cluster, the identity provider, the logging pipeline. Their sales team used the report in every enterprise deal. Six months later, an attacker accessed their production database through a credential stuffing attack against their staging environment, which shared an authentication backend with production. The staging environment was not in scope for the SOC 2 audit. It never had been.
The SOC 2 report was accurate. The controls it assessed did function as described. The report was silent on the staging environment not because the auditor missed it, but because the organization excluded it from the scope definition before the engagement began. The gap analysis that preceded the audit was conducted entirely inside that same boundary.
Why SOC 2 scope is the most consequential decision in the process
Every other major compliance framework defines scope for you, at least in part. PCI DSS follows the cardholder data environment. HIPAA follows protected health information. ISO 27001 gives you latitude but requires you to justify exclusions in a documented Statement of Applicability. SOC 2 gives you a blank page. The AICPA Trust Services Criteria apply to 'the service' as defined by the organization. You define the service. You draw the boundary. The auditor assesses what is inside it. This is not a loophole. It is a design choice by AICPA that recognizes the diversity of service organizations. But the practical consequence is that scope definition has become the primary mechanism by which organizations manage audit risk -- not by improving controls, but by excluding systems that would fail. A SOC 2 gap analysis conducted against a narrowly defined scope will find fewer gaps. It will not find fewer vulnerabilities.
Example
In a Vulnox SOC 2 readiness engagement for a mid-market HR SaaS platform in 2024, the initial scope definition provided by the client covered 11 production systems. External attack surface mapping identified 34 additional subdomains resolving to live services. Of those, 9 were directly related to the product: a legacy API version still in production use, a customer-facing status page running on unpatched infrastructure, and a developer documentation portal authenticated against the same identity provider as the admin console. None were in the declared scope. All three would have required remediation to include.
The SOC 2 Common Criteria under CC6 (Logical and Physical Access) require controls for in-scope systems. They do not require the organization to demonstrate that out-of-scope systems cannot be used to reach in-scope systems. Lateral movement from an excluded environment to an included one is not addressed by the framework unless the organization explicitly defines that boundary in their System Description and the auditor tests it.
What SOC 2 gap analyses find when scope is interrogated
Assessment base: Vulnox SOC 2 readiness and gap analysis engagements, 2023-2024, SaaS companies in financial services, HR technology, healthcare adjacent, and professional services verticals, Europe and North America.
Staging environments with production-equivalent access
Across SOC 2 readiness engagements where Vulnox conducted external attack surface assessment alongside gap analysis, staging environments were found sharing authentication infrastructure with production in the majority of cases. In most instances, the staging environment was intentionally excluded from SOC 2 scope on the grounds that it does not process real customer data. The authentication backend it shares with production does.
The control that protects production access is in scope. The second path to that same control is not. The gap analysis reports the control as present and effective. An attacker testing the staging endpoint reaches the same authentication system through a path the audit never evaluated.
Third-party integrations with access rights that exceed their documented function
SOC 2 vendor management requirements under CC9.2 require that third-party service providers are assessed for risk. In practice, this surfaces as a vendor questionnaire program that covers tier-one vendors. In every Vulnox engagement where we enumerated active OAuth grants and API keys, the count of third parties with live access to in-scope systems exceeded the number of vendors in the formal vendor management program. The median gap was 11 undocumented integrations. (Vulnox assessment data, 2024)
The SOC 2 audit confirms the vendor management program exists and operates. It does not confirm that all active integrations are in the program. Undocumented integrations with access to production data are a real exposure that a clean SOC 2 report does not address.
Evidence collected for auditors that does not reflect operational reality
SOC 2 Type 2 requires evidence that controls operated consistently over the observation period. The most common mechanism for demonstrating this is periodic access reviews, change management records, and log exports. In Vulnox readiness assessments, a recurring pattern is evidence that was generated for the audit rather than collected from ongoing operations. Access reviews conducted in the month before audit fieldwork. Log retention policies configured after the observation period began. These are not fabrications -- they are real controls. They just did not operate for the full period the report will claim.
The gap analysis identified missing controls. The organization implemented them. The Type 2 report will reflect six months of effective operation. Four of those months will have been the first four months the control existed. This is a meaningful difference in actual security posture that the report does not distinguish.
DNS and subdomain exposure that predates the current IT team
In gap analysis engagements that included passive DNS enumeration, Vulnox consistently found subdomains pointing to live infrastructure that no current team member could explain. The median age of the oldest undocumented subdomain was four years. Several pointed to administrative panels. One, in a recent engagement, pointed to a VPN endpoint using a deprecated authentication method that had been deprecated in production three years prior but was still running on that subdomain.
These assets were not in scope for the SOC 2 audit because no one knew they were in scope to begin with. They appear in external attack surface scans immediately. Attackers running passive reconnaissance find them before they find the in-scope systems.
More controls found during gap analysis is not a better outcome
Common belief
A thorough SOC 2 gap analysis is one that finds many gaps. Finding more means you were more rigorous. Organizations that receive long gap analysis reports feel they got more value from the engagement.
What we found
In a 2023 Vulnox engagement, a SaaS client presented a prior gap analysis report from another firm documenting 67 control gaps. All 67 were inside a scope that excluded the client's three legacy API endpoints, still used by their two largest enterprise customers. Those endpoints ran on unpatched versions of two frameworks with known critical CVEs. They were excluded from scope because they were 'scheduled for deprecation.' The schedule had slipped 18 months. The 67-control gap report said nothing about them.
A long gap analysis report that stays inside a narrow scope definition is less useful than a shorter report that interrogates the boundary. Finding 40 missing controls inside a scope that was drawn to exclude the highest-risk systems is not thorough -- it is thorough within a constraint that undermined the exercise. The right question at the start of a SOC 2 gap analysis is not 'what controls are missing' but 'where is the boundary drawn and why.' The answer to that question determines whether the rest of the engagement will tell you something meaningful about your actual security posture or only about your audit readiness.
What SOC 2 gap analysis systematically misses
The scope justification document
Every SOC 2 System Description includes a section defining what is and is not covered. Most gap analyses take that document as given and work within it. The scope justification itself is rarely assessed. Who made the scoping decisions? What was excluded and on what basis? Were exclusions driven by risk analysis or by audit cost management? A gap analysis that does not examine the answers to these questions is building on a foundation it has not inspected.
External attack paths into in-scope systems
SOC 2 Common Criteria CC6 addresses logical access. It requires controls be in place. It does not require the organization to demonstrate that there is no path from outside the declared boundary into in-scope systems. Attackers do not respect the System Description. An external attack surface assessment that maps all paths -- through in-scope and out-of-scope systems -- is not a standard component of a SOC 2 gap analysis. It should be.
Configuration drift between gap analysis and audit fieldwork
The typical gap analysis happens 6 to 12 months before audit fieldwork. Controls identified as missing are remediated. New controls are implemented. Then the environment changes, systems are added, integrations are deployed, developers make configuration changes. By the time the auditor arrives, the environment the gap analysis assessed is not the environment that exists. Most organizations do not conduct a second gap analysis before fieldwork. The first one is treated as durable. It is not.
Privacy criteria gaps that surface under regulatory scrutiny but not audit scrutiny
SOC 2 privacy criteria (P series) are optional. Most SaaS organizations that handle personal data do not include them in scope because they are not required and they add audit cost. GDPR, Thailand PDPA, and similar privacy regulations impose obligations that the P criteria would help document evidence for. Organizations that exclude privacy criteria from SOC 2 scope often discover this when facing a regulatory inquiry, not an audit. The gap analysis that did not include P criteria will not have mapped the evidence that a regulator will request.
SOC 2 scope flexibility compared to other frameworks
SOC 2
Organization defines scope entirely. Auditor assesses what is declared. No requirement to demonstrate that out-of-scope systems cannot reach in-scope systems. Privacy criteria are optional even for organizations handling significant personal data.
Maximum flexibility in what gets assessed. Maximum risk that scope is drawn to minimize audit findings rather than maximize security coverage. Gap analysis must interrogate scope definition, not just control presence within it.
ISO 27001
Organization defines scope but must document exclusions in a Statement of Applicability with justification. Auditor reviews the justification. Annex A controls must be assessed for applicability -- you cannot simply ignore control categories.
Harder to exclude systems without documented rationale. Gap analysis findings tend to be more complete because the scoping process itself is audited. More operational overhead to maintain.
PCI DSS
Scope is defined by cardholder data flow, not by the organization's preference. Segmentation controls must demonstrably isolate the cardholder data environment. QSA can expand scope based on what they find.
Much harder to exclude relevant systems. Gap analysis findings are more likely to reflect actual exposure because the framework defines what must be in scope. But PCI DSS scope is limited to payment data environments -- adjacent systems outside that environment are still out of scope.
Where SOC 2 compliance is heading
Within three years, at least one high-profile breach will prompt AICPA to issue guidance tightening System Description requirements to include documentation of what was excluded from scope and why. This will not change the framework fundamentally, but it will make scope manipulation visible in the audit record.
The SOC 2 market has grown dramatically in the past five years. The number of organizations with SOC 2 reports has increased faster than the average quality of those reports. Auditors are already flagging scope manipulation informally. A documented breach tied directly to an out-of-scope system at a company with a clean SOC 2 Type 2 report creates the regulatory and reputational pressure needed to force the change.
Confidence: mediumIf AICPA issues no guidance on scope documentation requirements by end of 2027, this prediction does not hold. If a publicly reported breach explicitly cites SOC 2 scope exclusion as a contributing factor before 2027, confidence should be upgraded to high.SOC 2 gap analysis will increasingly be conducted using continuous attack surface monitoring rather than point-in-time assessments, driven by enterprise procurement teams that no longer accept annual audits as adequate assurance.
Enterprise security and procurement teams are becoming more sophisticated about what SOC 2 reports represent. Several large enterprise procurement checklists now ask for evidence of continuous monitoring alongside the Type 2 report. This creates demand for gap analysis methodologies that produce ongoing findings rather than a pre-audit snapshot.
Confidence: highIf enterprise procurement requirements for SaaS vendors do not materially expand beyond annual SOC 2 Type 2 by end of 2026, the timeline is longer than predicted but the direction holds.
SOC 2 is good at what it does. The problem is what it says it does.
SOC 2 has genuine value. A well-scoped SOC 2 Type 2 assessment, conducted rigorously, confirms that an organization has implemented and maintained controls relevant to a defined set of systems over a defined period. That is useful assurance. The problem is that SOC 2 reports are marketed and consumed as general security validation. Enterprise procurement teams accept them as proof that a vendor is secure. Investors cite them in due diligence summaries. Sales teams use them to close deals. None of those uses are what the framework certifies. The framework certifies control operation within a declared scope. That is a narrower claim than the market has decided it represents. The gap between those two things is where the risk lives -- and where a gap analysis should be looking.
Counterargument
The counterargument is that perfect should not be the enemy of good. SOC 2 creates accountability for controls that otherwise would not exist at many organizations. A SaaS company with a SOC 2 Type 2 report has documented controls, evidence programs, and vendor management processes that a company without one typically lacks. That baseline matters even if the scope was conservatively drawn. This is true. It does not change the fact that the market is treating the report as a claim it does not make.
One thing to do this week
Pull the System Description from your most recent SOC 2 report, or from your planned audit scope if you are preparing for one. Read the section that defines what is in scope. Then do a passive DNS enumeration of your primary domain and compare the live subdomains against that System Description. The assets that appear in the DNS results but not in the System Description are your actual gap analysis starting point. They are what an attacker finds before they ever look at your audit report. If you do not have a SOC 2 report yet and are in the scoping phase, the DNS enumeration should happen before the scope document is written -- not after.
Further Reading
Gap Analysis
SOC 2 gap analysis processDigital Footprint
digital footprint analysisSOC 2 Gap Analysis Complete Guide
comprehensive SOC 2 gap analysis guideNIST Vulnerability Assessment Definition
NIST vulnerability assessment definitionWhat is SOC 2 Framework
overview of SOC 2 framework
Frequently Asked Questions
What does a SOC 2 gap analysis actually measure?
A SOC 2 gap analysis measures whether your existing controls meet the AICPA Trust Services Criteria for the systems you have defined as in-scope. The critical word is 'defined.' SOC 2 lets the organization draw its own boundary. The gap analysis measures the gap inside that boundary. It says nothing about what the boundary excludes -- and excluded systems are often the ones attackers target first.
What is the most common SOC 2 gap finding in SaaS companies?
Based on Vulnox assessment data, the most consistent finding is not a missing control -- it is a scoping decision that left significant infrastructure out of the audit boundary. Staging environments, legacy subdomains, third-party integrations, and internal admin tooling are routinely excluded from SOC 2 scope and routinely appear in external attack surface assessments as live, exposed, and under-controlled.
How long does SOC 2 Type 2 gap analysis to certification take?
The gap analysis itself takes two to six weeks depending on scope complexity. Remediation of identified gaps typically runs three to nine months. SOC 2 Type 2 requires a minimum observation period of six months after controls are implemented, so the realistic timeline from gap analysis to issued Type 2 report is 12 to 18 months for most mid-market SaaS organizations. Organizations that attempt to compress this typically do so by narrowing scope, not by accelerating remediation.
What does SOC 2 not cover that creates real security risk?
SOC 2 does not assess systems outside the defined scope boundary. It does not require external attack surface mapping. It does not evaluate what an attacker can discover about your infrastructure through passive reconnaissance. A SOC 2 Type 2 report confirms controls functioned within a defined perimeter for a defined period. It does not confirm that the perimeter was drawn in the right place.
What is the difference between a SOC 2 Type 1 and Type 2 gap analysis?
A Type 1 gap analysis checks whether controls are designed appropriately at a point in time. A Type 2 gap analysis must also assess whether controls have operated effectively over a minimum six-month period. The practical implication is that Type 2 gaps include configuration drift, access review lapses, and evidence collection failures that would not surface in a Type 1 assessment. Type 2 gaps are harder to close because they require demonstrated operational consistency, not just documented intent.
What should a SOC 2 gap analysis include that most assessments skip?
Most gap analyses stop at the declared scope boundary. A complete gap analysis should include an external attack surface assessment of systems adjacent to scope, a review of how the scope boundary was drawn and what was deliberately excluded, third-party integration mapping for any vendor with access to in-scope systems, and a DNS and subdomain enumeration to identify infrastructure that should be in scope but was not declared.
How much does a SOC 2 gap analysis cost?
For a SaaS company with a typical production environment, external gap analysis engagement costs run between $15,000 and $40,000 depending on scope complexity and provider. Internal resource costs for evidence collection and control mapping typically add 30 to 50 percent to that figure. Organizations that have not previously mapped their infrastructure spend significantly more because asset discovery becomes part of the engagement. Costs rise sharply when gap analysis reveals scoping decisions that require renegotiation with the prospective auditor.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.