Compliance Guide
What Compliance Frameworks Require From a Penetration Test
Only one of the major frameworks names penetration testing with a defined frequency. The rest require testing in language general enough that what your auditor accepts is set by convention rather than text.
- Separates mandated from conventionally expected
- States the specific clause each expectation rests on
- Written for the evidence pack, not the marketing claim
Most vendors tell you that every framework requires penetration testing. That is not accurate, and the inaccuracy causes real problems: teams buy the wrong depth of testing, receive a report their auditor questions, and discover the gap weeks before a deadline.
The honest position is that the frameworks vary considerably. Understanding which one you are actually subject to changes what you should buy.
The one framework that specifies it explicitly
PCI-DSS is the outlier. Requirement 11.4 names penetration testing, sets a minimum frequency of at least annually and after any significant change, requires internal and external testing, requires an industry-accepted methodology, and separately requires segmentation testing to confirm the cardholder data environment is properly isolated. If you are in scope for PCI-DSS, the requirement is concrete and the evidence expectations are well defined.
The frameworks that require testing without naming it
ISO 27001, SOC 2 and GDPR all require that security measures be tested for effectiveness, without prescribing penetration testing specifically.
- ISO 27001 — Annex A controls on technical vulnerability management and on security testing in development and acceptance. Penetration testing is the usual way organisations evidence them, but the standard does not mandate it by name
- SOC 2 — the Trust Services Criteria require monitoring and vulnerability identification. Penetration testing is what most auditors expect to see, and many will issue an exception without it, but the criteria do not name it
- GDPR — Article 32 requires a process for regularly testing, assessing and evaluating the effectiveness of your technical measures. That is a testing obligation in substance, with no method or frequency specified
In each of these the practical requirement is set by your auditor's expectations rather than the text. That is why the useful question during scoping is not "what does the standard say" but "what will your specific auditor accept as evidence".
The framework that requires analysis rather than testing
HIPAA is the most widely misrepresented. The Security Rule requires a risk analysis and a periodic technical evaluation. It does not require penetration testing anywhere in its text. Penetration testing is a strong and common way to satisfy the evaluation standard, and we recommend it, but any vendor telling you HIPAA mandates a penetration test is quoting marketing rather than the regulation.
What this means for what you buy
- If PCI-DSS applies, buy against Requirement 11.4 specifically, including segmentation testing — a generic web application test will not close it
- If you are pursuing SOC 2 or ISO 27001, ask your auditor what evidence they expect before scoping, because their convention is the real requirement
- If GDPR is your only driver, you have latitude on method and frequency, which means you can direct the budget by risk rather than by checkbox
- If HIPAA is your driver, ensure the engagement feeds your risk analysis rather than sitting beside it as an unrelated document
- In every case, confirm the report will state scope, methodology, competence and severity rationale, because those are the elements auditors challenge
The common failure across all of them
Testing too late. A report delivered a week before the audit window closes leaves no time to remediate, and open critical findings are harder to explain than findings that were found and fixed. Six to eight weeks ahead of the audit date leaves room for a remediation cycle and a retest, which turns an open list into a closed loop.
Common questions
Which compliance frameworks actually require a penetration test?
PCI-DSS is the only major framework that names penetration testing explicitly, with a defined minimum frequency and scope in Requirement 11.4. ISO 27001, SOC 2 and GDPR require that security measures be tested for effectiveness without naming the method, and in practice auditors expect penetration testing to evidence it. HIPAA requires a risk analysis and periodic technical evaluation, not a penetration test.
Can the same penetration test satisfy several frameworks at once?
Usually yes, provided scope covers the systems each framework cares about and the report maps findings to each framework's control references. The efficiency comes from the mapping, not from repeating the testing. Where PCI-DSS is involved, the specific requirements for internal, external and segmentation testing must be met explicitly rather than assumed to be covered.
How often do we need to test?
PCI-DSS sets at least annually and after significant change, with more frequent segmentation testing. Elsewhere, annually plus after significant change is the working convention auditors accept. If you deploy frequently, an annual test describes an application that no longer exists, so periodic testing between formal assessments is usually a better match for the actual risk.
When should we schedule testing relative to our audit?
Six to eight weeks before your audit window closes. That leaves room to remediate what we find and retest it, so your auditor sees findings that were identified and closed rather than an open list. Testing a week beforehand converts every serious finding into an item you have to explain instead of one you have fixed.
Can we share your report with our auditor and our customers?
With your auditor, yes — that is what it is written for. For customers and prospects, sharing the full technical report is rarely wise, because it is a map of your architecture and of any findings still open. The usual approach is a summary document confirming scope, methodology, dates and remediation status without the exploitation detail, and we agree that in the scope.
Do you provide a letter of attestation?
Yes. A short signed statement of what was tested, when, by whom, against which methodology, and the remediation status at the time of writing is what most procurement and vendor security reviews actually want. It is far more useful for that purpose than the full report and can be shared without exposing your architecture.
What if our auditor rejects the report?
That is worth understanding before it happens, which is why we ask during scoping what your auditor expects and what evidence they have requested. Rejections are almost always about scope or evidence format rather than testing quality — a missing internal component, or severity ratings without a stated basis. Both are avoidable if the requirement is known up front.
Let's scope your infrastructure.
Tell us what you have built and what you are testing against. You will speak to a Lead Security Architect, not a sales desk, and you will get a written scope with a fixed price before any work begins.