Home/ Blog/ New Regulations Are Making Penetration...
Article

New Regulations Are Making Penetration Testing Mandatory

PublishedSep 22, 2026 AuthorRarefied Read time4 minutes
complianceregulationsdoranis2penetration testingcybersecurity

For most of the last decade, penetration testing sat in the "good practice" column. Mature organizations did it because it worked; everyone else did it when a customer's security questionnaire forced the issue. That distinction is closing. A cluster of regulations now converging across public markets, financial services, critical sectors, and payments has moved independent security testing from something you should do to something you are expected to be able to prove you did. The shift matters less for the testing itself and more for who is accountable for it, how often it happens, and what evidence survives scrutiny afterward.

Disclosure Rules Made Cyber a Board Problem

The SEC's cyber disclosure framework requires public companies to report material cybersecurity incidents promptly and to describe, in their annual filings, how they manage cyber risk — including the board's oversight role and management's processes for identifying and assessing threats.

Read that carefully, because the second half is the part that changes behavior. Incident reporting is reactive. The governance disclosure is continuous, and it puts a company on record about its own risk management practices. A company that describes a robust program in its filings and cannot demonstrate independent testing behind that description has created a problem that is no longer purely technical. The practical effect is that directors now ask questions they previously delegated: when were we last tested, by whom, what did they find, and did we fix it. Those questions require an answer with a date on it.

DORA Formalizes Threat-Led Testing in Financial Services

The EU's Digital Operational Resilience Act takes a different angle. Rather than focusing on disclosure, DORA sets expectations for how financial entities withstand and recover from ICT disruption — covering risk management, incident reporting, third-party oversight, and testing.

Its testing provisions are the most instructive part of the whole regulatory wave, because they distinguish between two things organizations often conflate:

  • Baseline resilience testing: the regular, broad-based assessment of ICT systems that every in-scope entity is expected to perform, covering vulnerabilities and controls across the estate.
  • Threat-led penetration testing: advanced, intelligence-driven testing against live production systems, expected of entities deemed significant enough to warrant it, and designed to emulate real adversary behavior rather than run a checklist.

That second category is a meaningful signal. Regulators are no longer satisfied with tests that confirm known controls exist. They want evidence that an organization can withstand an adversary who behaves like an actual attacker — using current threat intelligence, against real systems, without the defenders being told the answers in advance. DORA also extends attention to critical third-party providers, which means the testing question travels down the supply chain.

NIS2 Widens the Population

NIS2 broadens the EU's earlier network and information security regime to a much larger set of essential and important entities — energy, transport, health, digital infrastructure, public administration, manufacturing, and more — and raises the baseline for risk management measures and incident reporting across all of them.

The important shift is scope. Organizations that never considered themselves regulated for cybersecurity now are, and many of them have security programs built for a compliance regime that no longer describes their obligations. NIS2 also pushes accountability toward management bodies, which mirrors the direction the SEC rules take: the people who sign off are the people who answer for it.

PCI DSS Was Always the Preview

None of this is unprecedented. PCI DSS has required penetration testing for years — internal and external, at defined intervals and after significant change, with segmentation testing for environments that rely on network isolation to reduce scope. It also requires that testing be performed by qualified, organizationally independent testers.

PCI's contribution to this conversation is that we already know how the mandate plays out in practice. Organizations that treat it as an annual box-check produce thin reports, remediate the findings that are easy, and are breached anyway. Organizations that treat the requirement as a floor get real value. The regulations arriving now are broader, but the failure mode is identical — and the sector standards that already apply to you are worth mapping deliberately, which is why we maintain a compliance standards overview covering how testing satisfies specific frameworks.

What This Means for Your Program

Three practical implications follow from the convergence.

  • Independence is now a feature, not an expense: internal teams testing their own systems produce findings, but not the kind of evidence a regulator, auditor, or board committee treats as credible. Third-party testing exists to remove the conflict of interest.
  • Cadence beats point-in-time: an annual test describes an environment that stopped existing the week after it finished. Regulations increasingly reference testing after significant change, which in a continuous-deployment organization means continuous assessment.
  • Evidence quality determines usefulness: a report needs to demonstrate what was tested, what was found, what the realistic impact was, and what happened next. Scope and remediation tracking are what turn a test into a defensible record.

The organizations handling this well are not the ones with the largest compliance functions. They are the ones that were already testing seriously and now simply document it properly.

Get in Touch

Regulatory pressure is a reason to start, but it's a poor reason to stop. If you want to understand how independent testing maps to your obligations, read our methodology or contact us to talk through your requirements.

This post represents the view of the individual author and not necessarily that of Rarefied Inc.
Get in touch

Interested in professional security testing?

Tell us what you’d like tested and we’ll get back to you shortly.

Contact Rarefied