Article contents
Run a penetration test at least once a year and every time something significant changes: a new product launch, a major release, a new integration, a move to the cloud, an acquisition, and after an incident. Between pentests you scan for vulnerabilities on a regular schedule, and after fixes you order a retest.
Below you will find a table of events that call for a new test, what to test and how deep, what PCI DSS, DORA and NIST actually say, and how to build a one-year testing plan.
In short
- The baseline is one pentest a year for each important system. PCI DSS describes it that way for the payment environment, and NIST for an organisation's network. [1] [4]
- A yearly schedule does not cancel tests after changes. A new payment module, a new API or a cloud migration is tested before launch or right after.
- Vulnerability scanning runs between pentests, for example every quarter and after changes. It finds known issues but does not see logic flaws.
- After fixes you need a retest. PCI DSS explicitly requires repeating the test to verify the corrections. [1]
- Financial companies in the EU test the systems behind critical functions every year under DORA, and entities identified by the regulator run TLPT every three years. [3]
Why a calendar is not enough: a pentest shows one point in time
Any security assessment is a snapshot of the system at the moment of testing. NIST says so directly and adds that this is why organisations may require more frequent assessments. [4] A month after the report the team ships new features, opens an API to a partner, changes access rights. The report stays the same, the system does not.
So frequency is set by two things: the calendar and the changes. A company with rare releases and stable infrastructure often does fine with a yearly pentest. A SaaS product that changes every week and keeps adding integrations tests major changes separately, without waiting for the yearly test.
When you need a new pentest: a trigger table
| Event | What to test | How deep |
|---|---|---|
| 12 months since the last test | Everything in scope: external perimeter, key applications, internal network | Full pentest |
| New product or application launch | The new application, its API, login and user roles | Full pentest before launch or right after |
| Major release: new roles, payments, file uploads, login changes | The changed features and everything connected to them | Targeted pentest of the changes |
| New integration or partner API | Keys, partner permissions, what data the partner sees and can change | Targeted API pentest |
| Cloud migration or new cloud infrastructure | Cloud configuration, access, what is exposed to the internet | Cloud configuration review plus application pentest |
| Acquisition or merger | The acquired company's network and accounts, links between networks | Security assessment, then a pentest of the connection points |
| Network segmentation change | Whether segments are isolated from each other | Segmentation test |
| Incident | How the attacker got in, whether that path is closed, whether similar ones exist | Targeted pentest after the investigation |
| Findings from the last pentest fixed | The same findings | Retest |
What counts as a significant change is up to the company. The PCI Security Standards Council explains in its penetration testing guidance that it depends on the risk assessment and the configuration of the environment, and that a change which could affect network security or access to card data may be considered significant. [5] A simple rule for any industry: if a change touches login, access rights, money or personal data, it is significant.
For the cloud I explain what gets tested in the article cloud security pentest for AWS, Azure and GCP. For an acquired company it helps to start with a security assessment: it gives the overall picture before deep testing.
What standards and regulators actually say
PCI DSS (the payment card data security standard). Penetration testing is covered by requirement 11.4. Internal (11.4.2) and external (11.4.3) penetration tests are performed at least once every 12 months and after any significant infrastructure or application upgrade or change. Exploitable findings are corrected and the test is repeated to verify the corrections (11.4.4). [1] If segmentation is used to isolate the cardholder data environment, it is tested every 12 months and after changes (11.4.5), and by service providers every six months (11.4.6). [1] [2] Vulnerability scans are required at least once every three months (11.3.1 and 11.3.2). [1] The current version, 4.0.1, was published in June 2024 and added no new requirements compared with 4.0. [6]
DORA (EU Regulation 2022/2554 on digital operational resilience for the financial sector, applicable since 17 January 2025). Financial entities other than microenterprises test all ICT systems and applications supporting critical or important functions at least yearly (Article 24(6)). Penetration testing is listed explicitly among those tests (Article 25(1)). Entities identified by the competent authority carry out TLPT, threat-led penetration testing on live production systems, at least every three years (Article 26). The authority can reduce or increase that frequency. [3] How such a test differs from a regular pentest is explained in red team vs pentest.
NIST SP 800-115 (NIST's technical guide to security testing). Because of its cost and potential impact on live systems, penetration testing of a network once a year may be sufficient. Between pentests NIST recommends regularly scheduled network and vulnerability scanning. Frequency is often driven by the requirements an organisation must meet, and resources go to high-priority systems first. [4]
ISO 27001 and SOC 2. If you are preparing for ISO 27001 certification or a SOC 2 report, write the pentest frequency and the list of significant changes into your own security policy and agree it with your auditor. How these frameworks relate to pentesting is covered in pentest for a SaaS startup.
A one-year plan for a company with its own product
A pentest and a scan do different jobs, so the plan has both:
- Continuously or every quarter: automated scanning of the external perimeter and applications, plus after major infrastructure changes. This part is covered by a vulnerability assessment.
- Once a year: a full pentest of key systems. It is convenient to tie it to the budget cycle or to contract renewals with large customers.
- Before a major launch: a targeted pentest of the new features while there is still time to fix findings.
- After fixes: a retest of critical and high findings.
- Once a year and after network changes: a segmentation test, if your protection relies on separating the network.
How a scan differs from a manual test, and why one does not replace the other, is explained in pentest vs vulnerability scan. How to close findings and pass the second check is covered in what to do after a pentest.
Common mistakes
- One pentest a year and none after changes. A major release a month after the report stays untested until next year.
- The same scope every year. Last year you tested the website, this year you also have a mobile app and an API. Review the scope before every test.
- A scan instead of a pentest. A scanner will not notice that a customer can see other people's orders by changing a number in the request.
- No retest. Without a second check you do not know whether the fix worked.
- Waiting for the yearly test after an incident. The path the attacker used is tested right after the investigation.
- Testing in the middle of a big migration. NIST notes that testing is sometimes delayed until a major upgrade is complete. [4] Otherwise the report describes a system that will be gone in a week.
Checklist: a yearly pentest plan
Download the preparation checklist (PDF)PDF · A4
FAQ
Is a pentest once a year enough?
For a stable system that rarely changes, yes. If you often ship new features or integrations, or change infrastructure, test major changes separately instead of waiting for the yearly test.
Can vulnerability scanning replace a pentest?
No. A scanner finds known vulnerabilities, while a pentest checks what an attacker can do with the system, including through logic flaws. PCI DSS requires both: scans every quarter, a pentest every year and after changes. [1]
How often does PCI DSS require a penetration test?
Internal and external pentests at least once every 12 months and after significant changes. Segmentation tests every 12 months, or every six months for service providers. [1] [2]
What does DORA require for penetration testing?
Financial entities test the systems supporting critical or important functions every year, and penetration testing is on the list of tests. Entities identified by the regulator run TLPT every three years. [3]
Do you need a pentest after every release?
No. Routine releases are covered by automated checks. A separate pentest is needed when a release changes login, access rights, payments, handling of personal data, or opens new APIs.
References
- Microsoft Learn: PCI DSS Requirement 11 (requirement text for 11.3 and 11.4) learn.microsoft.com
- PCI SSC FAQ 1447: How often must service providers test segmentation controls? pcisecuritystandards.org
- EUR-Lex: Regulation (EU) 2022/2554 (DORA) eur-lex.europa.eu
- NIST SP 800-115: Technical Guide to Information Security Testing and Assessment nvlpubs.nist.gov
- PCI SSC: Penetration Testing Guidance v1.1 listings.pcisecuritystandards.org
- PCI SSC: Just Published: PCI DSS v4.0.1 blog.pcisecuritystandards.org
