Most companies should conduct penetration testing at least once a year, but the right frequency depends on your regulatory obligations, risk profile, and how often your systems change. PCI DSS mandates annual testing and retesting after significant changes. DORA requires threat-led penetration testing (TLPT) every three years for qualifying financial entities. GDPR and ISO 27001 expect regular testing without prescribing a fixed schedule. This guide breaks down what each framework actually requires and when you should test more often.
Table of contents
Penetration Testing Frequency by Compliance Framework
The table below summarises what each major compliance framework requires. Note that some frameworks mandate penetration testing explicitly, while others create a strong practical expectation without naming it directly.
| Framework | Pen Test Named? | Required Frequency | Mandatory? |
|---|---|---|---|
| PCI DSS 4.0 | Yes (Req 11.4) | Annual + after significant changes | Yes |
| ISO 27001 | No | “Planned intervals” (annual expected) | No, but auditor-expected |
| GDPR | No | “Regularly” (undefined) | Implied by Article 32(1)(d) |
| DORA | Yes (TLPT, Art. 26) | Every 3 years (adjustable) | Yes, for identified entities |
| SOC 2 | No | Not specified (annual expected) | No, but CC4.1 evidence |
| NIS2 | No | “Regular” (undefined) | Implementing regulation implies it |
| HIPAA | No (proposed: Yes) | “Periodic” (proposed: annual) | Not yet; proposed NPRM would mandate |
PCI DSS 4.0: Annual Plus After Significant Changes
PCI DSS is the most prescriptive framework when it comes to penetration testing frequency. Requirement 11.4 mandates both internal and external penetration testing at least once every 12 months, and again after any significant infrastructure or application change.
“Significant change” includes system replacements, new applications, network architecture overhauls, cloud migrations, and changes to firewall rules or segmentation policies. In practice, organisations that deploy frequently may need to test several times a year to stay compliant.
PCI DSS also requires quarterly vulnerability scans by an Approved Scanning Vendor (ASV) under Requirement 11.3. These are automated scans, not penetration tests, but they complement the annual pen test by catching newly disclosed vulnerabilities between engagements.
ISO 27001: At Planned Intervals
ISO 27001:2022 does not name penetration testing in its standard text. It is a management system standard, not a technical checklist. However, Annex A Control 8.8 (management of technical vulnerabilities) and Annex A Control 8.29 (security testing in development and acceptance) create obligations that are most directly satisfied through penetration testing.
Clause 9.1 requires evaluation of ISMS effectiveness at “planned intervals” without specifying a number. In practice, every ISO 27001 auditor we have encountered expects to see at least annual penetration testing. More frequent testing is expected for organisations with complex or high-risk environments. The test results feed directly into your risk register, risk treatment plan, and Statement of Applicability.
GDPR: Regular Testing of Security Measures
The GDPR never mentions penetration testing by name. Article 32(1)(d) requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing.” The regulation is deliberately technology-neutral and does not define “regularly.”
The UK ICO’s guidance on data security explicitly names vulnerability scanning and penetration testing as appropriate techniques for meeting this requirement. The expected frequency depends on the volume and sensitivity of personal data you process, the risk environment, and your own circumstances. For most organisations processing significant amounts of personal data, annual penetration testing is the baseline expectation.
DORA: Threat-Led Penetration Testing Every Three Years
The Digital Operational Resilience Act (DORA) takes a two-tier approach to security testing. Article 25 requires general digital operational resilience testing for all financial entities. Article 26 adds a more advanced requirement: threat-led penetration testing (TLPT) at least every three years for entities identified by their competent authority.
The identification criteria in Article 26(8) include systemic relevance, ICT risk profile, and ICT maturity level. Microenterprises are explicitly excluded. TLPT must be performed on live production systems covering several or all critical functions. The competent authority can adjust the three-year frequency up or down based on the entity’s risk profile.
The Joint Regulatory Technical Standards (RTS) published by the ESAs in July 2024 provide detailed implementation guidance, including the criteria authorities use to identify qualifying entities and the methodology for conducting TLPT exercises.
SOC 2, HIPAA, NIS2, and Other Frameworks
SOC 2
SOC 2 does not mandate penetration testing. It is an attestation framework, not a regulatory requirement. However, Trust Services Criteria CC4.1 references penetration testing as an evaluation method, and auditors routinely expect it as evidence. Annual third-party penetration testing covering external networks, internal networks, web applications, and APIs is the standard practice.
HIPAA
HIPAA currently requires “periodic” technical evaluation (45 CFR 164.308(a)(8)) without defining a cadence or naming penetration testing. The HHS Office for Civil Rights has included penetration testing in its audit protocol since 2016, making it a de facto expectation. A proposed rule published in January 2025 would explicitly require penetration testing at least every 12 months and vulnerability scanning every 6 months, though the final rule remains subject to regulatory review.
NIS2
The NIS2 Directive (Article 21) requires essential and important entities to take “appropriate and proportionate” measures to manage security risks. The implementing regulation (EU 2024/2690) and ENISA’s technical guidance explicitly recommend penetration testing as part of effectiveness evaluations. Since NIS2 is transposed into national law by each EU member state, exact requirements vary by country, but the direction is clear.
Beyond Compliance: Best Practice Testing Frequency
Compliance sets the floor, not the ceiling. Many organisations that take security seriously test more frequently than their regulatory obligations demand. Here is what best practice looks like by risk level:
- High-risk environments (financial services, healthcare, critical infrastructure): Quarterly penetration testing of customer-facing applications. Annual full-scope internal and external testing. Continuous vulnerability scanning.
- Medium-risk environments (SaaS platforms, e-commerce, professional services): Annual full-scope penetration testing. Semi-annual testing of high-change applications. Quarterly vulnerability scanning.
- Lower-risk environments (internal tools, brochure websites, low-data-sensitivity operations): Annual penetration testing. Quarterly automated vulnerability scanning.
The real driver behind testing frequency should be rate of change, not just regulatory requirement. An application that ships updates weekly has a different risk profile from one that is stable for months at a time.
Triggers for Ad-Hoc Penetration Testing
Scheduled testing is not enough on its own. Certain events should prompt an unscheduled penetration test, regardless of where you are in your annual testing cycle.
Major Infrastructure or Application Changes
A new cloud migration, a platform rewrite, a shift from monolith to microservices, or a significant change to authentication or authorisation flows all introduce new attack surface. PCI DSS explicitly requires retesting after significant changes, and the principle applies across all frameworks. If the architecture changed materially, test it before declaring it production-ready.
Security Incidents or Breaches
After a security incident, a penetration test serves two purposes: it validates that the root cause was actually fixed, and it identifies whether the attacker gained access to systems or data beyond what incident response initially uncovered. Post-incident testing should be scoped to cover the affected systems and any adjacent infrastructure that may have been exposed.
Mergers, Acquisitions, and Third-Party Integrations
When you acquire a company or integrate a third-party system into your environment, you inherit their security posture. A pre-completion or pre-integration penetration test helps you understand what you are taking on. This is standard due diligence for any organisation with a mature security programme. The same applies when onboarding a new third-party SaaS provider that will have access to sensitive data or connect to internal systems.
Regulatory or Contract Obligations
Some contracts, cyber insurance policies, and regulatory bodies require penetration testing at specific intervals or before go-live. Review your contractual obligations alongside your compliance requirements to make sure your testing schedule covers both.
Building a Penetration Testing Schedule
A practical approach to scheduling penetration tests:
- Identify your compliance obligations. Map every framework that applies to your organisation and note the required frequency for each.
- Inventory your assets. List every application, network segment, API, and cloud environment that falls within scope of testing.
- Assess rate of change. Applications with frequent releases need more frequent testing. Stable infrastructure can follow annual cycles.
- Set your baseline cadence. Annual full-scope testing is the minimum for most organisations. Add quarterly testing for high-risk or high-change systems.
- Plan for ad-hoc tests. Keep budget and capacity reserved for unscheduled testing triggered by changes, incidents, or acquisitions.
- Stagger your tests. Spread testing across the year rather than concentrating it in a single annual engagement. This gives you more consistent coverage and faster feedback on new deployments.
FORTBRIDGE is a CREST-accredited penetration testing company. We test web applications, APIs, mobile apps, networks, and cloud environments for organisations across the UK and EMEA. If you need help building a testing schedule that meets your compliance obligations, get in touch.
Frequently Asked Questions
How often should a company do penetration testing?
At minimum, once a year. PCI DSS requires annual testing plus retesting after significant changes. ISO 27001 auditors expect annual testing. GDPR expects regular assessment of security measures. If your applications change frequently, quarterly testing of critical systems is best practice.
Does PCI DSS require quarterly penetration testing?
No. PCI DSS requires quarterly vulnerability scans by an Approved Scanning Vendor (ASV), not quarterly penetration tests. Penetration testing is required at least annually and after significant changes under Requirement 11.4.
What is DORA TLPT and how often is it required?
Threat-Led Penetration Testing (TLPT) under DORA Article 26 is an advanced form of security testing required for systemically important financial entities. It must be performed at least every three years on live production systems. The competent authority can adjust this frequency based on risk.
Is penetration testing required for GDPR compliance?
GDPR does not name penetration testing directly. Article 32(1)(d) requires a process for regularly testing and evaluating security measures. The UK ICO guidance names penetration testing as an appropriate method. For organisations processing significant personal data, annual testing is the practical expectation.
When should I do a penetration test outside the normal schedule?
After major infrastructure changes, security incidents, mergers or acquisitions, new third-party integrations, or before launching a new customer-facing application. Any material change to your attack surface warrants testing, regardless of when the last scheduled test was completed.
How FORTBRIDGE Can Help
We work with organisations across the North America, UK and EMEA to build and execute penetration testing programmes that match their actual risk profile, not just tick their compliance boxes.
Whether you need annual full-scope testing to satisfy PCI DSS or ISO 27001 auditors, quarterly testing of high-change applications, DORA TLPT support, or unscheduled testing after an incident or major infrastructure change, we scope and deliver accordingly. We test web applications, APIs, mobile apps, internal and external networks, and cloud environments. Findings are reported the same day testing concludes, with remediation guidance your developers can act on immediately.
We are CREST-accredited and DESC-accredited. Every engagement is led by consultants with 10–20 years of offensive security experience, no juniors, no scanner padding.
If you need help building a testing schedule that meets your compliance obligations and your risk profile, get in touch.
About Post Author
