Compliance Penetration Testing: What SOC 2, PCI DSS, HIPAA, ISO 27001 and DORA Actually Require

What compliance penetration testing actually means

Let us start with the honest version, because the marketing version helps nobody.

Compliance penetration testing is a penetration test you run because a framework expects one. That is the whole idea behind compliance penetration testing, and it is simpler than the acronyms make it sound. The craft does not change. You are still trying to break into a system, still chaining weaknesses, still writing down what worked. What changes is the audience. A normal pentest answers “can we be broken into?” A compliance pentest answers that question and produces the paperwork a specific auditor needs to tick a specific box.

That second job matters more than people admit. An auditor does not watch you test. They read a report. So the report has to say the right things: what was in scope, when it ran, who ran it, what was found, what was fixed, and proof of the retest. Miss those and a technically excellent test can still fail the audit.

Here is the thing most vendors skip. The five frameworks a growing company meets — SOC 2, PCI DSS, HIPAA, ISO 27001 and DORA — each ask for this evidence in their own dialect. Some name the test. Some only imply it. One sets a hard cadence. Getting compliance penetration testing right means knowing which dialect your auditor speaks.

This page is the map. Each framework gets a short summary below and a full guide of its own. Read the map first, then follow the link that matches your audit.

Why “we passed the audit” is not “we are secure”

A certificate is a photograph. It says the system looked fine on the day the shutter clicked.

The problem is what happens after. You pass in March. You ship features every week. By November the environment the report describes is gone — new subdomains, new APIs, rotated infrastructure, a dependency that picked up a fresh vulnerability. The certificate on your wall is still valid. The system it describes no longer exists.

Auditors accept the photograph because that is what the framework asks for. Attackers do not care about your audit date. This gap — between the compliance calendar and the threat calendar — is the single most important thing to understand about compliance penetration testing, and it is the reason the last section of this page exists.

You can close the gap. Not by testing harder once a year, but by testing continuously and keeping the evidence current. More on that below.

The five frameworks at a glance

Before the detail, the shape of the whole thing. Each framework, what it governs, and how firmly it asks for a test.

SOC 2 governs how a service organisation protects customer data across five trust criteria. It does not print the words “penetration test”, but auditors expect one as evidence for the monitoring and risk criteria. The SOC 2 penetration testing guide covers exactly where it fits.

PCI DSS governs anyone who stores, processes or transmits cardholder data. It is the strict one: it names penetration testing directly and sets a cadence. See the PCI DSS penetration testing guide.

HIPAA governs protected health information in the US. It requires a risk analysis and evaluation but never says “pentest” — testing is how you satisfy the intent. The HIPAA penetration testing guide untangles it.

ISO 27001 is the international information-security management standard. Testing lives inside its risk-treatment and technical-review controls. The ISO 27001 penetration testing guide maps the clauses.

DORA is the EU’s Digital Operational Resilience Act for financial entities. It is the newest and the most demanding, with threat-led penetration testing for significant firms. The DORA penetration testing guide explains the tiers.

SOC 2 penetration testing

SOC 2 is the framework most SaaS companies meet first, usually because a customer asked for the report before signing.

It is built on the Trust Services Criteria — security, availability, processing integrity, confidentiality and privacy. None of those criteria contain the phrase “penetration test”. So people assume it is optional. It is not, in practice. Auditors look for evidence that you actively identify vulnerabilities (criteria around monitoring and change management), and a pentest is the cleanest evidence there is.

A Type II report, the one customers actually want, covers a window of time. That makes SOC 2 penetration testing a recurring obligation, not a one-off. The full guide walks through which criteria a test supports and how often to run one.

PCI DSS penetration testing

If you touch card data, this is the framework that will not let you improvise.

PCI DSS names penetration testing explicitly. It expects both external and internal testing, segmentation testing where you rely on network segmentation to reduce scope, a defined methodology, and testing after significant change — on top of the regular cadence. It is prescriptive in a way the others are not, which is oddly a relief: there is less to interpret.

The catch is the “significant change” clause. Ship a major change and the annual clock is not enough — you owe a test tied to that change. The full PCI DSS penetration testing guide breaks down the requirement, the scoping around segmentation, and how continuous testing quietly solves the significant-change problem.

HIPAA penetration testing

HIPAA is where the wording gets slippery, and where a lot of healthcare vendors get caught out.

The Security Rule requires a risk analysis and periodic technical evaluation of safeguards protecting electronic protected health information. It never says “penetration test”. But you cannot honestly claim to have evaluated technical safeguards against attack without, at some point, attacking them. A pentest is how mature organisations satisfy the evaluation standard and evidence the risk analysis.

Because the rule is intent-based rather than prescriptive, scope is yours to justify. The HIPAA penetration testing guide covers how to tie a test to the risk analysis so it holds up under scrutiny.

ISO 27001 penetration testing

ISO 27001 is the international standard, and the one auditors treat as a system rather than a checklist.

Penetration testing supports several parts of it: the risk assessment and treatment process, and the technical controls around vulnerability management and secure development in the current Annex A. A test feeds the risk process with real findings and demonstrates that technical controls work, not just that they exist on paper.

An ISO auditor cares about the loop as much as the test: finding, treatment, retest, review. The ISO 27001 penetration testing guide shows how to run a test that produces exactly that trail.

DORA penetration testing

DORA is the new arrival, and for EU financial entities it changes the conversation entirely.

The Digital Operational Resilience Act requires regular testing of ICT systems, and for significant entities it goes further: threat-led penetration testing, modelled on real adversary behaviour, on a multi-year cycle. This is a step up from “run a scan and file it”. It expects testing that resembles an actual attack.

For a European security company this is home ground. The DORA penetration testing guide explains who falls in scope, what threat-led testing involves, and how continuous testing keeps you ready for it rather than scrambling before it.

What every framework quietly has in common

Read all five and a pattern appears that none of them states outright.

Every framework wants three things: that you looked for weaknesses, that you fixed what you found, and that you can prove both. Finding, fixing, evidence. The differences are cadence and how loudly each says the word “test”.

The truth is, that shared shape is a gift. You do not need five separate testing programmes. You need one testing capability that produces evidence in the form each auditor accepts. A single well-run compliance penetration testing programme can feed a SOC 2 report, a PCI assessment and an ISO audit at once, because underneath the dialects they are asking the same question.

And all five share the same weakness, too: they measure a point in time. Which is exactly where the annual model quietly fails everyone.

The cost of getting compliance penetration testing wrong

It is worth being blunt about what failure looks like, because “we’ll sort it before the audit” is how most teams end up here.

The common failure is not a failed audit. It is a passed audit that meant nothing. A compliance penetration testing exercise scoped to the smallest possible surface, run once, filed, and forgotten. The certificate is real. The security it implies is not. Then a breach lands in the part of the estate the scope conveniently excluded, and the report becomes evidence of what you chose not to look at.

The second failure is timing. A team schedules compliance penetration testing for the week before the audit deadline, a critical finding surfaces, and now there is no time to fix and retest before the auditor arrives. Continuous testing removes that cliff edge, because there is no single deadline the whole programme is racing toward.

The third is treating the report as the deliverable. The report is not the point. The fixed vulnerability is the point, and the retest that proves it stayed fixed. An auditor who knows their job reads for that loop, and compliance penetration testing that stops at “here is a list of findings” leaves the most important evidence unwritten.

How to scope compliance penetration testing

Scope is where compliance penetration testing goes wrong, usually by being drawn to fit the budget rather than the risk.

Start from the data the framework protects. PCI cares about the cardholder data environment. HIPAA cares about anything touching health records. SOC 2 and ISO care about the systems behind your security promises. Draw the boundary around that data first, then test everything that can reach it — not just the flagship application.

Be careful with the shortcuts. Network segmentation can reduce PCI scope, but only if the segmentation actually holds, which is itself something you have to test. Excluding a system because it is “internal” assumes an attacker never gets inside, and the whole point of a pentest is that they do.

A good rule: if a system can reach the protected data, or can reach something that can, it is in scope. If you are not sure, our free security checks guide helps you enumerate what you actually have before you draw the line.

Who owns compliance penetration testing inside the company

One quiet reason compliance penetration testing slips is that nobody clearly owns it.

Security assumes the auditors will define scope. The compliance team assumes security is already testing. The engineering team assumes someone booked the vendor. The result is a test booked late, scoped narrow, and treated as a formality. Naming a single owner — usually security, with compliance defining the evidence format — fixes more audit pain than any tool.

The owner’s real job is not the test itself. It is the loop: making sure findings reach the engineers who can fix them, that fixes get retested, and that the evidence lands in the format the auditor accepts. Compliance penetration testing that produces findings nobody actions is just an expensive way to document your own weaknesses for an attacker to read later.

This is also where continuous testing helps the owner most. Instead of one frantic annual push, compliance penetration testing becomes a standing process with an owner who reviews a live stream of findings, not a once-a-year fire drill. The evidence builds itself, and the audit becomes a matter of exporting what already exists.

How SelfHack AI turns testing into standing evidence

Here is where the annual-certificate problem gets solved, and where compliance penetration testing stops being a scramble.

SelfHack AI is an autonomous penetration testing platform. It runs the test — reconnaissance, exploitation, chaining — against your estate continuously, not once a year. For compliance, that changes two things.

First, the evidence is always current. Instead of a report describing March, you have testing that describes now, with a history behind it. When an auditor asks “how do you know this control works?”, the answer is a standing record, not a nine-month-old PDF.

Second, the significant-change problem disappears. PCI’s “test after major change” clause and DORA’s resilience expectations both assume testing keeps pace with the environment. Continuous testing does that by default — a new subdomain or a shipped feature gets tested because everything does, not because someone remembered to schedule it.

We are not claiming a tool replaces your auditor or your judgement. It replaces the gap between audits. Keep the human engagement for the deep, creative work; use continuous testing so the other eleven months are covered and evidenced. See how we compare in our AI pentest tools overview, then bring the specific framework you are chasing.

None of this requires a bigger budget. It requires deciding that compliance penetration testing is a continuous property of how you build, not an event you survive once a year. Teams that make that shift stop dreading audits, because the evidence is already sitting there when the auditor asks.

FAQ

Is penetration testing legally required for compliance?

It depends on the framework. PCI DSS names penetration testing as a requirement. SOC 2, HIPAA and ISO 27001 require that you identify and evaluate vulnerabilities, and a test is the standard way to satisfy that — expected in practice even if the word is not printed. DORA requires regular testing and, for significant entities, threat-led testing. Always confirm with your auditor and the current standard text.

How often do I need compliance penetration testing?

PCI DSS sets an annual cadence plus testing after significant change. The others tie frequency to your risk and change rate rather than a fixed number, though annual is the common baseline. The honest answer is that annual is a floor set by paperwork, not by the threat — which is why continuous testing is becoming the norm for teams that ship often.

Can one penetration test cover several frameworks at once?

Often yes. The underlying question — did you look for weaknesses, fix them and prove it — is shared. A well-scoped test with a clear report can supply evidence for SOC 2, ISO 27001 and, with the right scope, PCI at the same time. The scope and the report framing are what change per framework, not the testing itself.

Does automated or continuous testing satisfy auditors?

Increasingly, yes, when it produces the same evidence a manual test would: defined scope, findings, remediation and retest, all documented. Continuous testing also answers the question annual testing cannot — what happened between audits. Confirm the evidence format with your auditor first; the platform should produce reports built for that.

What is the difference between a vulnerability scan and compliance penetration testing?

A scan lists things that might be wrong. A penetration test proves what an attacker can actually do with them. Most frameworks expect both, and some (PCI notably) require them as separate activities. A finding that says “exploited, here is the impact” carries more weight in an audit than a scanner’s list of maybes.

The verdict

Compliance penetration testing is not five different obligations. It is one capability — look, fix, prove — presented in five auditors’ dialects.

Get the capability right and the frameworks become translation work rather than five separate scrambles. Get the cadence right — continuous rather than annual — and you close the gap between the certificate on the wall and the system actually running.

Compliance penetration testing done well is boring in the best way: no scramble, no surprises. Pick the framework you are chasing from the guides above. Then decide whether you want to keep testing once a year and hoping, or test continuously and knowing. If it is the second, talk to us.

Sources & methodology: testing methodology references the OWASP Web Security Testing Guide and NIST SP 800-115. Framework requirements are summarised from the publicly available standards (PCI DSS, AICPA Trust Services Criteria, HIPAA Security Rule, ISO/IEC 27001, and EU Regulation 2022/2554 — DORA); the authoritative source is always the current text and your auditor’s interpretation. This article is general guidance, not legal or audit advice. Only test systems you own or are authorised to test.