How often to run a penetration test: by risk, not just by law

A yearly test is enough where the environment barely changes. Once a company starts deploying often, adding integrations, or growing, a yearly test is too little, because between tests a lot of new code and new inputs appear that nobody has checked.

The difference is in the pace of change, not in the size of the company. A small online store that ships a new feature every week has more unchecked changes than a large company with one stable system. The calendar doesn’t capture that, so the cadence follows how much has changed since the last test.

Alongside the regular cycle, a test makes sense whenever what is at stake changes substantially. There are six such situations, and none of them follows the calendar.

• A new version or feature of an application that changes the business logic or adds entry points.
• A migration of a system or of data, a move to the cloud or to another platform, for example.
• A new integration or API that opens another way in from outside.
• A new perimeter: a new domain, a new public service, a newly exposed interface.
• A merger or an acquisition that brings an environment you haven’t tested into your network.
• A security incident, after which you need to check that the attacker’s path is closed and that no other one is left open.

These triggers are about change, not about time. When one of them comes two months after the yearly test, there is no reason to wait until next year. The test follows the change, not a date in the calendar.

You derive the cadence from five factors, not from a single number. The more of them that apply strongly to you, the shorter the interval between tests makes sense.

• The size of your attack surface, meaning everything through which someone can get into the company from outside or from inside. More applications, domains, and interfaces mean more places where a flaw appears.
• The pace of change: the more often you deploy, the sooner the previous test is out of date.
• The sensitivity of the data: with payments, health records, and personal data, the cost of a single flaw is higher.
• How exposed you are to the internet: whatever is publicly reachable gets probed continuously.
• The sector: regulated industries and frequent targets need a shorter cycle.

No single factor sets an exact interval on its own, but together they tell you whether you belong with the yearly baseline or with more frequent testing. If you aren’t sure where on that scale you sit, that is exactly what one call is for.

The frequency of tests is one thing, the retest is another. A retest, meaning a repeat check that the flaws found really are fixed, doesn’t belong to the cadence but to each individual test. Without it you have documented only what was broken, not what has been repaired. How the retest fits into the whole is shown in how a single penetration test runs.

In the higher obligations regime under Act No. 264/2025 Coll., on Cybersecurity (the Czech Cybersecurity Act), regulated companies have a statutory minimum for how often they test. We don’t go into it here: the time limits and what exactly the decree asks of testing are a topic of their own.

Whether the regulation touches you at all is a question of regime, and you work that out from whether your company falls under the regulation. For the cadence decision, only this much matters: the statutory minimum is a floor, not a target frequency. Anyone who goes by it alone tests too little.

Yearly as a baseline, plus after every major change to a system and according to the level of risk. A company that deploys often or holds sensitive data needs a shorter interval than a stable environment that doesn’t change. The interval follows the pace of change and the sensitivity of the data, not the calendar.

Not after every one, only after a major one. A typo fix or a small visual tweak doesn’t call for a new test. It makes sense where the business logic changes, an entry point is added, a new integration or API appears, or the system grows wider. What matters is whether the change opened a new way in, not how big it is in lines of code.

A statutory minimum applies only to regulated companies in the higher obligations regime, and it comes from a decree, not from a general rule. The exact time limit, and what the decree asks of testing, sits with the regulation rather than with the risk-based cadence this article is about. A company outside the regulation has no statutory frequency and goes by risk.