Penetration Testing for Compliance: Regulatory Standards Guide

For many years, cybersecurity compliance was treated primarily as a matter of documentation. Organizations were expected to formalize processes, define responsibilities, and maintain approved policies. If these elements were present and properly recorded, compliance was generally assumed.

That assumption no longer holds.

Across modern regulatory frameworks, compliance has shifted from intent to evidence. Regulators and auditors now expect proof that security controls function under realistic conditions. Documented processes alone are insufficient; implemented measures must withstand credible attack paths and satisfy regulatory scrutiny.

This shift affects how compliance programs are structured. While required controls are usually clear, validation is often less defined, particularly when testing scope must align with specific frameworks or when independence becomes a determining factor. Penetration testing and adversarial validation have therefore moved from supporting activities to formal components of compliance programs. In this context, penetration testing for compliance is no longer optional validation but a structured regulatory requirement.

This article examines how security assessment maps to key regulatory and assurance frameworks across operational resilience, product security, and data protection regimes,including NIS 2, DORA, GLBA, the Cyber Resilience Act (CRA), FDA Medical Devices guidance, PCI DSS, SOC 2, and ISO 27001. It clarifies when technical testing is expected, how validation differs across regulatory families, and how responsibilities should be separated to preserve independence and audit defensibility. Understanding how penetration testing compliance expectations differ across these frameworks is essential for defensible audit outcomes.

At Iterasec, we operate solely at the validation stage. We do not design controls, write policies, or implement compliance programs. Our role is to provide independent, adversarial assessment aligned with the applicable regulatory framework and structured to support both technical remediation and regulatory review.

The Separation of Duties: Implementation vs. Assessment

In compliance-driven security testing, who performs the assessment is often as important as what is tested. The principle that matters here is independence: the party that validates a control should not be the same party that designed, built, or operates it. That separation is what gives the results their evidentiary value.

When the same internal team, or the same consultancy, that designs and implements security controls is also responsible for testing them, independence is compromised. Even with the best intentions, conflicts of interest arise: assumptions go unchallenged, blind spots remain, and findings may be unconsciously softened to avoid internal friction.

In practice, every framework covered in this article separates three parties:

The implementer (internal team and/or GRC consultant) builds and operates the controls — governance, policy writing, system configuration, remediation. They design the ISMS, write the risk registers, and deploy the defenses.

The independent assessor (Iterasec) tests those controls adversarially and produces the evidence. We do not fix the holes; we find them, prove they can be exploited, and document the results in a form that withstands scrutiny.

The auditor or authority judges that evidence and issues the compliance outcome. Depending on the framework, this is the QSA (PCI DSS), the CPA firm (SOC 2), the certification body (ISO 27001), the notified body (CRA), the FDA reviewer, or the TLPT authority (DORA). This party does not perform the testing — it evaluates whether the testing, and the controls it examined, satisfy the requirement.

Keeping the first two parties separate is what auditors and authorities in the third seat are looking for. The exact bar varies by framework. Some, such as PCI DSS and ISO/IEC 27001, require organizational independence rather than a strictly external provider, meaning a sufficiently separated in-house team can qualify; DORA likewise permits internal red-teamers between its mandatory external testing cycles (though significant credit institutions must use external testers exclusively). 

Others make third-party involvement mandatory outright, including DORA’s external-tester requirement for TLPT and the notified-body routes for higher-risk product classes under the CRA. But across all of them, externally validated assessments are consistently treated as higher-quality evidence than internally conducted testing, because independence is easiest to demonstrate, and hardest to dispute, when the assessor sits outside the organization entirely. That holds even where a framework does not explicitly mandate third-party involvement.

Regulatory Standards That Require Penetration Testing for Compliance

Before examining specific testing requirements, it is useful to group these standards not by topic but by the kind of obligation they create, because that is what ultimately determines how rigorous and how independent the testing must be.

Although terminology differs across frameworks, the obligations fall into two broad types.

Legally binding regulations. DORA, NIS 2, GLBA, the Cyber Resilience Act (CRA), and the FDA’s medical device requirements are enforced by regulators or backed by statute, and non-compliance carries legal and financial consequences. These laws differ in focus — operational resilience (DORA, NIS 2), protection of customer data (GLBA), and product security (CRA, FDA) — but they share enforceability and supervisory oversight, which is why they tend to push hardest toward demonstrable, independent validation.

Industry and assurance standards. PCI DSS, SOC 2, and ISO/IEC 27001 are not government legislation. PCI DSS is a contractual standard imposed by the payment card brands; SOC 2 is a voluntary attestation performed by a CPA firm; ISO/IEC 27001 is a voluntary certification against an international standard. Compliance here is driven by contracts, customers, and market expectations rather than by statute — but auditors, assessors, and CPA firms still treat externally validated testing as the higher-quality evidence.

Despite these differences, all of them share a common expectation: implemented controls must be demonstrably effective under realistic threat conditions. The sections below break down how an offensive security assessment maps to each framework — what must be validated, how often, and under what level of independence.

Part 1 — Legally Binding Regulations

DORA (Digital Operational Resilience Act)

DORA formalizes the shift from documentation to evidence most explicitly, and is one of the clearest cases where penetration testing is embedded directly into statutory obligations. It requires financial entities to validate their ability to withstand and recover from severe cyber incidents, and has applied since 17 January 2025.

Applies to: Financial entities (banks, insurers, investment firms, and others), with critical ICT third-party providers brought in through a dedicated oversight framework.

GLBA (FTC Safeguards Rule)

The GLBA Safeguards Rule is a prescriptive US data-security law. Its core concern is protecting the confidentiality and security of customer information (non-public personal information), and the amended rule names penetration testing outright.

Applies to: Non-banking financial institutions (auto dealers, mortgage brokers, tax preparers, payday lenders, and similar).

NIS 2 Directive

NIS 2 requires organizations to assess the effectiveness of their technical risk-management measures on a regular basis. It applies across critical sectors rather than to finance specifically — and notably, financial entities are largely governed by DORA instead, as the more specific law.

Applies to: Essential and Important entities (energy, transport, health, digital infrastructure, and others).

CRA (Cyber Resilience Act)

The CRA shifts attention from operational continuity to market integrity: the concern is whether the product itself introduces risk into the market. Testing must extend beyond network exposure to firmware, proprietary protocols, backend services, and mobile interfaces. The CRA entered into force on 10 December 2024 and applies in full from 11 December 2027, with vulnerability and incident reporting obligations from 11 September 2026 and the notified-body provisions from 11 June 2026.

Applies to: Products with digital elements (hardware and software) made available on the EU market.

FDA Medical Device Cybersecurity

FDA cybersecurity expectations are now a statutory requirement, not just guidance. Section 524B of the FD&C Act (added by the Consolidated Appropriations Act, 2023, effective 29 March 2023) requires manufacturers to demonstrate that “cyber devices” meet defined cybersecurity requirements as part of their premarket submissions. The current guidance was updated in June 2025 to fold in Section 524B and revised again in February 2026 to align with the Quality Management System Regulation (QMSR / ISO 13485).

Applies to: Manufacturers of “cyber devices” — broadly, devices that include software, can connect to the internet, and have characteristics that could be vulnerable to cybersecurity threats (US; effectively global for any product entering the US market).

Part 2 — Industry and Assurance Standards

PCI DSS v4.0.1

PCI DSS ties penetration testing directly to compliance status, with penetration testing addressed under Requirement 11.4. Segmentation validation is critical, because scope reduction depends on technical isolation being demonstrable. The current version is v4.0.1, and all v4.x future-dated requirements have been mandatory since 31 March 2025.

Applies to: Entities that store, process, or transmit payment card data.

SOC 2

SOC 2 is a voluntary AICPA attestation performed by a CPA firm, typically demanded by customers. It does not prescribe a single testing format; instead it requires organizations to demonstrate that security controls operate effectively within the defined scope of the system. Technical validation supports management’s assertions about control effectiveness and vulnerability management, which is why many SaaS providers run recurring penetration testing to support Type II reporting cycles.

Applies to: SaaS providers and general enterprise security.

ISO/IEC 27001

ISO/IEC 27001 is a voluntary certification against an international standard (current version: ISO/IEC 27001:2022). Like SOC 2, it does not prescribe a single testing format; it requires organizations to demonstrate that security controls operate effectively within the defined scope of the ISMS. Technical validation supports assertions about control effectiveness and vulnerability management, and strengthens surveillance and re-certification audit readiness.

Applies to: Any organization establishing a formal Information Security Management System (ISMS).

What a Compliance Penetration Testing Report Must Include

Every security assessment concludes with a detailed technical report. In regulated environments, that report becomes part of the compliance record. A generic vulnerability list is rarely sufficient. Auditors expect documentation that clearly demonstrates scope alignment, methodological rigor, and reproducible findings.

A compliance-oriented security report must therefore be structured with regulatory defensibility in mind. This documentation framework reflects the best penetration testing methods for compliance, where traceability and reproducibility are central.

Methodology & Testing Approach

The report must clearly define how the assessment was conducted and which framework governed the testing. Whether aligned with OWASP ASVS for application security, TIBER-EU for DORA-aligned red teaming, or FDA cybersecurity guidance for medical devices, methodology must map directly to the regulatory requirement. Ambiguity at this stage weakens evidentiary value.

Executive Summary & Narrative

Beyond technical detail, the report should provide a structured overview of the engagement — explaining scope, objectives, key findings, and overall risk posture. This narrative layer allows auditors, compliance teams, and executive stakeholders to understand the assessment context without navigating raw technical output.

Structured Technical Findings

Each finding must be documented with precision. A defensible report includes a clear description of the vulnerability, technical impact, step-by-step reproduction details, affected assets, and specific remediation guidance. Reproducibility and clarity are critical for both remediation and audit review.

Standardized Scoring (CVSS)

Severity classification must follow an accepted industry standard. Adherence to the Common Vulnerability Scoring System (CVSS) ensures objectivity and comparability across assessment cycles. Standardized scoring is a foundational element of mature compliance pentesting programs, reducing interpretation disputes and strengthening audit acceptance.

At Iterasec, report structure is designed with these requirements in mind, ensuring that technical depth and regulatory clarity are maintained simultaneously.

Summary: Building a Penetration Testing Compliance Journey

Compliance programs rarely fail because controls are missing. They fail on the harder problems: unclear scope, inconsistent validation, or testing that doesn’t line up with what the regulation actually asks for.

In practice, compliance comes together in three connected layers.

The first is regulatory definition, working out what actually applies. A financial entity has to establish whether DORA covers it; if it does, the next question is whether it has been designated for threat-led penetration testing. A product manufacturer checks if the CRA or FDA rules are triggered. For everyone else, it usually comes down to PCI DSS scope or NIS 2 coverage. Without clear scoping, technical validation has no direction.

The second is implementation, turning those requirements into operational safeguards. Governance, encryption, access controls, monitoring, and documented procedures all live here, and this is where most compliance budget is spent.

The third is validation, where the claims get tested against reality. Adversarial testing probes whether PCI DSS segmentation truly isolates the CDE, pushes DORA resilience measures against realistic attack paths, hunts for exploitable weaknesses in CRA-regulated products, and confirms that SOC 2 and ISO 27001 controls behave as described. This is the point where implementation is finally measured against the regulation.

How high the bar sits depends on the obligation. Independence matters most where compliance is legally mandated, and less where it is contractual or voluntary. But in every case, a well-run assessment is what separates a checkbox exercise from evidence that holds up under scrutiny.

At Iterasec, this validation stage is the core of our work. We run independent security assessments aligned to the relevant framework, and we structure the results to support both technical remediation and audit review.

If compliance-driven testing is on your roadmap, getting scope and methodology right early is the difference between a formality and a defensible outcome. Done well, pentesting turns regulatory obligations into measurable, attack-tested resilience.