How Often Should Penetration Testing Be Done? PCI DSS, ISO 27001 and Insurance Rules

Penetration testing should be done at least once a year and again after any significant change to your systems. That is the minimum PCI DSS sets, and a sensible baseline for everyone else. Customer-facing applications that change often justify testing every six months or with each major release, and vulnerability scanning should run monthly or more often in between.

This guide explains how often you should do a penetration test under each of these, how insurers and contracts affect the answer, and what counts as a change big enough to trigger an extra test.

Key takeaways

• Annual testing plus testing after significant change is the practical minimum.
• PCI DSS is specific about frequency; ISO 27001 and UK GDPR leave the interval to your risk assessment.
• Insurers and customer contracts can set their own frequency, which then becomes a minimum.
• Fast-changing applications and internet-facing systems justify smaller, more frequent tests.
• Define “significant change” in advance, so testing is triggered by process rather than memory.

Penetration testing requirements: which standards require it, and how often?

Only a few frameworks explicitly require penetration testing at a set interval: of those in the table at the top of this guide, PCI DSS, NYDFS and DORA. Most others accept a penetration test as evidence for a broader duty to test security regularly, at a frequency you justify:

• ISO/IEC 27001:2022: test reports are evidence for Annex A 8.8 and 8.29, at a frequency set by your risk assessment.
• UK GDPR: they show the Article 32(1)(d) process for regularly testing security measures exists and works.
• SOC 2: they are evidence for monitoring controls; the CC4.1 points of focus list penetration testing as one type of evaluation.
• DORA: besides threat-led testing, it lists penetration testing among the tests for the yearly testing of systems that support critical or important functions (Articles 24 and 25).

Cyber Essentials does not require one at all. Contracts, insurers and regulators can turn a recommendation into a requirement: if a customer contract names an annual penetration test, it is explicitly required for you. For SOC 2, our guide to SOC 2 penetration testing explains what auditors look for.

How often does PCI DSS require penetration testing?

At least every 12 months and after any significant infrastructure or application change. Requirement 11.4 calls for a documented methodology covering the whole cardholder data environment perimeter and critical systems, from inside and outside the network. The tester must be qualified and organisationally independent, and exploitable vulnerabilities must be corrected and retested.

If you use segmentation to reduce scope, testing must confirm that out-of-scope systems genuinely cannot reach the cardholder data environment: annually for merchants and every six months for service providers. Your QSA will look at the methodology, the tester’s independence and the retest evidence, not just the date on the report. Our PCI DSS penetration testing service is scoped to those rules.

PCI DSS also requires quarterly internal and external vulnerability scans, with external scans performed by an Approved Scanning Vendor. Those are separate from the annual penetration test.

How often does ISO 27001 require penetration testing?

ISO 27001 does not set a number, and it does not name penetration testing as mandatory. An auditor will expect your testing frequency to follow from your risk assessment, and will want to see findings tracked to closure. A defensible baseline is to test your main systems every 12 months and to test significant new systems before go-live. Our page on ISO 27001 penetration testing explains what auditors typically ask for.

Does UK GDPR require penetration testing?

Not by name. Article 32(1)(d) of the UK GDPR requires “a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing”. It does not mention penetration testing or set an interval. For systems that hold personal data, a risk-based programme of penetration testing and vulnerability scanning, with findings tracked to closure, is a practical way to show that the process exists and works.

Testing raises data protection questions of its own. Testers may see personal data, so agree in writing how evidence is stored and deleted, and use test accounts rather than real customer records wherever you can.

Do cyber insurers require a penetration test?

Not as a universal rule. Each insurer sets its own questions and conditions. Some ask about security testing on proposal or renewal forms, alongside questions on MFA, backups and patching. If your policy wording or schedule names a testing frequency, treat it as a condition: failing to meet it could affect a claim. Check the wording at every renewal, and keep the report and retest letter where you can find them.

Does Cyber Essentials Plus count as a penetration test?

No. Cyber Essentials Plus is an annual technical audit in which the certification body checks patching, malware protection, MFA and account settings on a sample of devices, plus an external vulnerability scan. It is a valuable baseline, but it does not look for the application flaws or attack paths a penetration test is designed to find.

Penetration testing frequency: what should decide it?

Beyond compliance minimums, five factors decide whether annual testing is enough:

• Rate of change. A web application deployed weekly changes far more in a year than a stable internal network.
• Exposure. Internet-facing systems are probed continuously and deserve more attention.
• Data sensitivity. Systems holding payment card data, health data or large volumes of personal data carry higher impact.
• Previous results. If the last test found many serious issues, a follow-up within months tells you whether remediation worked.
• Contracts. Customers, insurers and regulators may set their own expectations.

A common pattern is annual testing for internal networks and stable infrastructure, with six-monthly or release-linked web application penetration testing for customer-facing applications and APIs.

What counts as a significant change?

“Significant change” is the trigger most organisations handle badly, because nobody decides in advance what it means. PCI DSS guidance gives examples such as new hardware or software in the cardholder data environment, changes to its boundary, and changes in how account data flows. A workable internal definition covers:

• New network segments, or changes to firewall rules between segments.
• New remote access solutions, such as a VPN replacement.
• Data centre moves, cloud migrations or new cloud accounts.
• Changes to authentication systems such as Active Directory or single sign-on.
• A new customer-facing application, portal or API.
• Major releases that change authentication, authorisation or payment flows.
• New third-party integrations that handle sensitive data.

Record the definition in your change procedure and add a “security testing required?” question to the change approval form.

How does vulnerability scanning fit in?

Scanning runs far more often than testing, and it does not replace it. Scan internet-facing systems weekly or continuously and internal systems at least monthly. Use scan results to shape each penetration test, so the tester’s time goes on what a scanner cannot find. Our comparison of penetration testing vs vulnerability scanning explains the difference, and our vulnerability scanning services cover the time between tests.

How often should penetration testing be done for each system?

A sensible testing calendar combines frequent scanning with less frequent, deeper tests:

Retest after remediation. A test that finds serious issues but is never followed up gives you a report, not assurance. If you are deciding which infrastructure test to run first, our comparison of internal vs external penetration testing sets out what each one covers.

Does testing more often cost more?

Not necessarily. Several smaller, focused tests tied to real changes can be better value than one large annual test, because they find issues sooner and each one is scoped to what actually changed. Our guide to penetration testing cost explains how scope drives price.

Why Sovereign Secure

Sovereign Secure is a PCI SSC Qualified Security Assessor (QSA) company, an IASME-licensed Cyber Essentials certification body and ISO 27001 certified. We help clients set a testing cadence that meets PCI DSS, ISO 27001 and contract requirements without testing more than they need.

Next step

List your systems, rank them by exposure and data sensitivity, and note the frameworks and contracts that apply. Then use our penetration testing quote form to get a fixed price for an annual programme or a single test.