Why do vulnerability scans not satisfy SOC 2 pentest expectations?

Scans identify known issues, but they do not prove whether controls fail when attacked in sequence. SOC 2 reviewers want evidence that the organisation can detect, understand, and remediate realistic abuse paths, including logic flaws and access bypasses. A scan can support the programme, but it does not replace adversarial validation.

Why This Matters for Security Teams

Vulnerability scans and penetration tests solve different problems. Scans are designed to find known weaknesses at scale, while a pentest is expected to validate whether an attacker can combine conditions, bypass controls, and reach a meaningful outcome. That distinction matters in SOC 2 because reviewers are not only checking that issues are catalogued, but that the security programme can surface and respond to realistic abuse paths.

Security teams often overestimate scan coverage because a clean report can look reassuring. Yet a system can be fully scanned and still remain exposed to privilege escalation, insecure workflows, broken authorisation, or chained weaknesses that only appear when tested interactively. Guidance from the CISA cyber threat advisories and current threat reporting such as the ENISA Threat Landscape both show that attackers routinely exploit exposed paths rather than isolated findings. In practice, many security teams encounter this only after an audit request or incident has already exposed the gap between “scanned” and “tested.”

How It Works in Practice

SOC 2 pentest expectations generally focus on adversarial validation, not just vulnerability enumeration. A scanner can confirm that a host has missing patches, weak services, or misconfigurations, but it will not reliably demonstrate whether an attacker can use those conditions to move laterally, access sensitive data, or escalate privileges. Pentesters, by contrast, are expected to test exploitability in context, often across web applications, cloud controls, identity flows, and privilege boundaries.

For most programmes, the practical workflow looks like this:

• Use scanning to establish baseline hygiene, asset visibility, and remediation queues.
• Use manual testing to confirm whether findings are reachable, exploitable, and chainable.
• Validate business logic, authentication, authorisation, session handling, and privilege boundaries.
• Document evidence of control failure or resilience, not just a list of CVEs.
• Track remediation and retest to show closure of the tested abuse path.

This is why control frameworks often treat scanning and testing as complementary. The CIS Controls v8 emphasise continuous vulnerability management, but that alone does not satisfy the need to validate how a real attacker would behave. For audit readiness, the more persuasive evidence is a test narrative showing scope, method, exploit path, impact, and remediation. Where identity or access controls are involved, the test should also confirm whether weak authentication, excessive privilege, or broken session controls can be abused even when the underlying system is patched.

These controls tend to break down when cloud services, APIs, and delegated access are highly interconnected because scanners rarely model the full sequence of trust decisions.

Common Variations and Edge Cases

Tighter test scope often increases cost and operational disruption, requiring organisations to balance audit evidence against application stability. That tradeoff is real, especially when production testing is constrained and teams rely heavily on external scanning.

Best practice is evolving, but there is no universal standard for whether a pentest must be annual, fully external, or scoped to every major system. What matters is whether the engagement is credible for the environment. A mature SOC 2 programme may use scans for broad coverage, then layer pentests for high-risk applications, internet-facing assets, privileged admin paths, and identity-dependent workflows. In regulated or fast-moving environments, this is often the only practical way to show meaningful assurance.

Edge cases matter. A SaaS platform with strong patch hygiene can still fail pentest expectations if the tester can abuse insecure API authorisation or tenant isolation. A network that looks clean in scan output can still be weak if exposed management interfaces, default credentials, or overly permissive service accounts remain in place. The same is true for NHI and machine-to-machine access: a scan may confirm the presence of secrets or services, but not whether those credentials allow lateral movement or privilege escalation. SOC 2 reviewers typically want evidence that the organisation has tested the paths attackers are most likely to use, not just the controls easiest to measure.

Related resources from NHI Mgmt Group

• When does an access review satisfy SOC but still fall short for SOX?
• Why do runtime signals matter more than static vulnerability scans?
• Why do internal vulnerability scans matter when a perimeter already exists?
• What do teams get wrong about pentest output and vulnerability counts?