Most compliance frameworks expect or require a real penetration test. A scan exported to PDF does not satisfy an auditor who knows the standard. Here is what each framework actually asks for, and the evidence that passes review.
File · Answer first
The faster question than whether you need a pentest is which of two camps your framework sits in. PCI DSS and CMMC name testing in the requirement text, so the test is non-negotiable. SOC 2, ISO 27001, and HIPAA do not say the word, but the examiners who assess them read the control language as an expectation of independent, manual testing with attack-path evidence, which means a scan export quietly fails the same bar. Either way you need a real test, and an auditor who knows the standard separates a scan export from a tested finding in about thirty seconds. The rest of this page maps each framework to the evidence its examiner actually accepts.
File · What each
The frameworks differ in whether they say the word "penetration test" out loud. They converge on the same thing in practice: evidence that a competent human tried to break the in-scope systems and documented what an adversary could do.
File · The gap
A scanner reports what its signature database already knows. It cannot chain a low-severity finding into a high-severity attack path, it cannot prove segmentation actually holds, and it cannot tell an auditor what an adversary would have done with a finding inside your boundary. Those are exactly the questions a competent examiner asks. Hand an experienced auditor a Nessus or Burp export with the in-scope systems renamed and your logo on the cover, and they will grade it as the scan it is.
The full breakdown of why a scan and a test are not interchangeable is here: penetration test vs vulnerability scan. For audit purposes the line is simple. Scans cover volume between tests; the audit wants the depth only manual testing produces.
Operator Note
Scope the test to the audit boundary, not the network diagram. The system description, the cardholder data environment, the ePHI flow, or the CUI boundary is what the auditor is examining, so that is what the test should cover. A test that ranges outside the boundary wastes budget; a test that misses part of the boundary leaves a gap fieldwork will find.
“An auditor is not reading your report for the CVSS scores. They are reading it to see whether a human tested the thing they are about to attest to. A scan export answers a different question than the one being asked.”
File · The evidence
File · Timing the
Work backward from fieldwork. A typical engagement runs two to four weeks of active testing plus a one-week report cycle, and you want remediation and a retest to land before the auditor arrives. That means starting roughly six to eight weeks ahead of fieldwork for a clean cycle. If your date is tighter than that, say so on the scoping call. We scope around the audit window and tell you the realistic timeline, not the optimistic one. The full mechanics of a manual engagement are on the penetration testing page.
File · FAQ
Q1 Does SOC 2 require a penetration test?
SOC 2 does not name a penetration test in the criteria. The Trust Services Criteria (CC4.1 and CC7.1) require evidence of independent security testing, and examiners operationalize that as an annual third-party penetration test with manual validation and attack-path narrative. A vulnerability scan alone does not demonstrate the control to an examiner who knows the standard.
Q2 Will a vulnerability scan pass my audit?
Rarely, and not for the frameworks that matter here. PCI DSS 4.0.1 explicitly requires penetration testing and segmentation testing in requirement 11.4. For SOC 2, ISO 27001, HIPAA, and CMMC, a scan export shows the auditor a list of potential issues, not that anyone tested the boundary. Auditors who know the difference treat a scan-and-PDF as a scan.
Q3 How fast can you test before my audit date?
Start about six to eight weeks ahead of fieldwork for a clean test, remediate, and retest cycle. If your date is tighter, we say so on the scoping call and test the boundary the auditor examines first.
Q4 Does the report meet my framework's evidence requirements?
Yes. We produce a scope statement tied to the audit boundary, an attack-path narrative per finding, segmentation results where the framework requires them, an executive summary, and a retest delta document mapping each fix to its original finding. Those are the artifacts examiners ask for across SOC 2, PCI DSS, HIPAA, CMMC, and ISO 27001.
Talk to an Operator
Real operators. Real attack paths. Real business impact. Talk to us about your security goals.
Related
Each framework page covers the controls, scope, and evidence that auditor expects.
CC4 and CC7 evidence with attack-path narrative.
Requirement 11.4 testing, including segmentation.
Risk-analysis evidence across the ePHI environment.
NIST 800-171 assessment for CUI boundaries.
Annex A technical review mapped to your SoA.
Retest evidence packaged for your audit window.