ThreatExploit AI
Reference

Which frameworks actually require
a penetration test?

One of these four names penetration testing outright. The other three are more often misquoted than read. This is the clause-level answer for each, what an assessor accepts as evidence, and where organisations most commonly lose the point.

your situation
Which of these apply to you?
Two questions that change the answer
what binds you

Select at least one framework above and the combined obligation appears here.

Side by side

The short answer for each.

FrameworkIs testing required?CadenceSet by
PCI DSS v4.0Explicitly required by nameAt least every 12 months and after every significant change. Segmentation controls every 12 months, or every 6 months if you are a service provider.PCI Security Standards Council
SOC 2Not named in the criteria, expected in practiceDetermined by your own stated control, not by the standard. Most organisations commit to annual testing; if your control description says quarterly, the auditor will test you against quarterly.AICPA Trust Services Criteria
HIPAA Security RuleNot required today; explicitly proposedToday: "periodic", defined by your own risk analysis, with annual being the common interpretation. Under the proposal: at least every 12 months, with scanning every 6 months.HHS Office for Civil Rights
Cyber insuranceNo standard — the underwriter decidesWhatever you stated on the application. Annual is the most common answer given, and therefore the most common commitment made.Individual carriers and their application forms

Verdicts reflect the text of each framework as at August 2026. Compliance requirements change; confirm against the current published standard before relying on any summary, including this one.

In detail

One page per framework.

Explicitly required by name

PCI DSS v4.0

Yes. PCI DSS is the one framework on this page that names penetration testing outright and tells you how often to do it. Requirement 11.4 mandates internal and external penetration testing a…

Read the requirements →
Not named in the criteria, expected in practice

SOC 2

No — and this surprises people. The Trust Services Criteria never use the words "penetration test". SOC 2 is not a checklist of controls; it is an audit of whether the controls you claim are…

Read the requirements →
Not required today; explicitly proposed

HIPAA Security Rule

Not explicitly, as the rule stands. The HIPAA Security Rule requires a periodic technical and non-technical evaluation, and penetration testing is a recognised way to perform it — but the wo…

Read the requirements →
No standard — the underwriter decides

Cyber insurance

There is no standard to comply with, which makes this the most misunderstood item on the list. Whether a penetration test is required depends entirely on the carrier, the limit you are askin…

Read the requirements →
Common to all four

Four mistakes that span every framework.

01

Testing on a calendar, not on change

Almost every framework has a second trigger alongside the annual one: material change to the environment. An estate tested in January and rebuilt in March has an annual test and no current evidence. The change trigger is where most gaps actually open.

02

Findings without retest

PCI DSS 11.4.4 requires it explicitly; every other assessor asks for it in practice. A finding is closed when the exploit no longer reproduces, not when a ticket is marked done. Remediation without retest evidence is the most common reason a control fails on review.

03

Scope narrower than the assessment

The test covers the application; the audit covers the system. Whenever the scope of the test is smaller than the scope of the framework, the difference is the part nobody has evidence for — and it is usually the infrastructure and identity layer around the application.

04

Promising more than you deliver

SOC 2 system descriptions and cyber insurance applications are both representations. Writing “quarterly penetration testing” and performing one test a year does not create a gap in your security; it creates a documented exception, which is worse.

Questions

What buyers and auditors ask.

Which compliance frameworks actually require penetration testing?
Of the four most commonly asked about, only PCI DSS names penetration testing outright and sets a cadence — Requirement 11.4 mandates internal and external testing at least annually and after significant change. SOC 2 never uses the words, but its Trust Services Criteria on control monitoring and vulnerability detection are normally satisfied by testing. HIPAA requires a periodic technical evaluation without naming the method, though a proposed Security Rule update would make annual testing explicit. Cyber insurance has no standard at all: the carrier decides, and your application answer becomes the commitment.
How often does a penetration test need to be done for compliance?
Annually is the common baseline, but the trigger that catches people out is change. PCI DSS requires testing after any significant infrastructure or application change as an independent obligation from the annual one, and HIPAA requires re-evaluation in response to environmental or operational changes. For SOC 2 the cadence is whatever your own system description commits to, which means writing "quarterly" and delivering annually creates the exception yourself.
Does a vulnerability scan count as a penetration test?
Not where the framework distinguishes them, and PCI DSS does so explicitly: scanning sits in Requirement 11.3 and penetration testing in 11.4, and scan output does not satisfy 11.4. The distinction assessors apply is whether weaknesses were merely identified or actually exploited to establish impact. A scanner reports what it matched; a penetration test establishes what an attacker could do with it.
Do we need a third-party penetration test, or can we test ourselves?
PCI DSS requires organisational independence rather than an external company — a qualified internal resource who is independent of the systems under test satisfies the letter of it. In practice many assessors find independence easier to accept when it comes from outside, and cyber insurers frequently ask specifically about third-party testing. Where you self-test, document the independence carefully.
What evidence do auditors accept from an automated penetration testing platform?
The same evidence they accept from a human engagement: a documented methodology, a defined scope matching the system under assessment, findings with proof that they were exploitable rather than theoretical, and records of remediation and retest. Auditors assess sufficiency of evidence, not the tooling used to produce it. The one reliable way to find out is to send a sample report to the person who will actually review it.

Deadlines across the year are collected in the compliance pentesting calendar, and the difference between satisfying a control and actually being secure is covered in compliance checkbox versus real testing.

Start somewhere concrete

See what an assessor would see first.

The free exposure check covers the externally visible hygiene that shows up in every framework — certificates, headers, email authentication — in about ten seconds, with no account.

Run a free exposure checkTalk about a scoped test