Penetration Testing Requirements in Regulated Environments
Regulated industry penetration testing is not a box-checking exercise — PCI DSS, DORA, and TIBER-EU each impose specific scoping, methodology, independence, and reporting standards that fundamentally shape how tests must be conducted.
Penetration testing in regulated environments is governed by framework-specific requirements that go beyond generic "conduct annual pen tests" mandates. PCI DSS v4.0 Requirement 11.4 is the most prescriptive: it requires annual penetration testing of all cardholder data environment (CDE) network and application components, segmentation testing to validate CDE isolation, and testing after significant infrastructure changes. PCI DSS v4.0 Requirement 11.4.7 specifically addresses multi-tenant service providers who must support on-demand penetration testing of the tenant's environment. The DORA Article 26 framework mandates Threat-Led Penetration Testing (TLPT) for significant financial entities at least every three years, following the TIBER-EU methodology: a full-scope red team exercise using Targeted Threat Intelligence to simulate advanced persistent threat actors targeting the firm's critical functions. NHS organizations in England must conduct penetration testing per the Data Security and Protection Toolkit (DSPT) requirement 7.1.4.
The engineering and organizational requirements for compliant penetration testing include: (1) Independence — PCI DSS 11.4.2 requires external penetration testers for annual assessments; DORA TLPT requires a TIBER-accredited red team provider. (2) Scope definition — the scope document must cover all system components in or connected to the CDE (PCI DSS), or all systems supporting designated critical functions (DORA TLPT). (3) Methodology — PCI DSS references PTES (Penetration Testing Execution Standard) and OWASP Testing Guide; TIBER-EU mandates a defined reconnaissance phase, a Targeted Threat Intelligence phase, and a Red Team Testing phase with specific deliverables. (4) Reporting — penetration test reports must document all findings with CVSS scores, evidence of exploitation, and remediation guidance; PCI DSS requires retesting of critical and high findings and documentation of the remediation cycle. (5) Retention — test reports must be retained for evidence of compliance, typically 1–3 years depending on the framework.
A nuanced requirement in modern penetration testing is cloud environment testing authorization. AWS, Azure, and GCP all have Penetration Testing policies that require advance notification or explicit authorization for specific test types (vulnerability scanning, DDoS simulation, credential stuffing against authentication endpoints). Testers operating in regulated cloud environments must ensure cloud provider authorization is obtained and documented before testing. Container and Kubernetes penetration testing requires specific techniques — breakout from container to host (CVE-based and escape logic), RBAC misconfiguration exploitation, and secrets exfiltration from etcd — that differ from traditional infrastructure testing. CREST (Council of Registered Ethical Security Testers) and CHECK (NCSC-approved penetration testing scheme) accreditation are required by UK public sector and financial services regulators for test providers.
We scope and manage regulated penetration testing programs aligned to PCI DSS v4.0, DORA TLPT, TIBER-EU, and NHS DSPT requirements. We coordinate CREST or CHECK-accredited test providers, define scopes that satisfy regulatory evidence requirements, manage retesting cycles for critical findings, and produce audit-ready penetration test summary documentation.
Compliance-Native Architecture Guide
Design principles and a structured checklist for building software that is compliant by default — not compliant by retrofit. Covers data architecture, access controls, audit trails, and vendor due diligence.