An IT director receives next year’s budget with a single line item: “penetration testing — 1 unit”. Last year it looked the same, and the year before that as well. Nobody questions the number, because the answer seems obvious: “that is what the regulations require”. The problem is that in most organisations no regulation requires it at all — and where one does, the figure reads quite differently.
This text will not recommend “once a year unless something changes”. What matters here is separating two things that blur together in every conversation about pentests: the cadence imposed by law and the cadence that follows from the pace of change in the system. The first is verifiable in the text of a legal act, the second in a change register. Neither is a matter of opinion.
How often do penetration tests actually need to be performed?
Outside the financial sector no Polish or EU provision states a figure — which means the organisation sets the cadence itself and must be able to justify it. Where a figure does exist it is precise: the DORA Regulation requires yearly testing of systems supporting critical functions and threat-led penetration testing at least every three years.
In practice this produces three different answers for three different companies. A bank and a brokerage house have their cadence written into a regulation. An essential entity under the Polish National Cybersecurity System Act has a written cadence for the audit, not for the test. A mid-sized manufacturer outside both categories has nothing written down at all — and it is precisely that company which buys “one pentest a year”, because intuition suggests it.
Does Polish law require penetration testing at all?
Not explicitly — and this takes five minutes to verify. The phrase “penetration test” does not appear even once in the consolidated text of the National Cybersecurity System Act, announced by the Marshal of the Sejm on 29 December 2025 (Journal of Laws 2026 item 20), nor in the amending act of 23 January 2026 (Journal of Laws 2026 item 252), in force since 3 April 2026. Download both files from the Journal of Laws and use the search box in any PDF reader.
The Act does speak about testing, only in broader terms. Article 8(1)(2)(b) requires “security in the process of acquiring, developing, maintaining and operating the information system, including testing of the information system”, and point (h) requires “policies and procedures for assessing the effectiveness of technical and organisational measures” (own translation). Both provisions describe what must exist. Neither says how often.
There is also a mode in which the state performs the testing. Article 36a(2) defines a security assessment as the performance of security tests of an information system in order to identify its vulnerabilities, and it is carried out by CSIRT MON, CSIRT NASK, CSIRT GOV or a sectoral CSIRT. This is not an obligation of the entity — it is a power of the authority, requiring either the entity’s consent or an instruction from the competent authority (Article 36b(1)).
Key takeaway: the Polish NSC Act does not mandate penetration testing and states no frequency for it. It mandates testing of the information system as an element of the information security management system, and an assessment of the effectiveness of the measures deployed. The choice of method and cadence belongs to the entity — together with the burden of justifying it before the authority.
What does the Polish NSC Act actually say about frequency?
The only figure in the Act concerns the audit, not the penetration test. Article 15(1), as amended: an essential entity carries out, at its own cost, at least once every 3 years, a security audit of the information system used in the process of providing the service — “counted from the date on which the auditors performing the audit drew up and signed the report from the previous audit”.
Three details of this provision change how a budget is planned. First, the clock runs from the signature on the report, not from the start of the engagement — a delayed report shifts the whole cycle. Second, the obligation applies to essential entities; an important entity has no cyclical audit cadence. Third, Article 16(2) allows 24 months for the first audit from the date the entity met the classification criteria, while the remaining obligations of that chapter must be met within 12 months.
An extraordinary mode sits on top of that. Under Article 15(1b), the competent cybersecurity authority may at any time order an essential entity to undergo an external audit, and may order the same of an important entity where a significant incident or another breach of the Act has occurred. The decision is immediately enforceable (paragraph 1c), and a copy of the report reaches the authority within 3 working days (paragraph 1a). The three-year cadence is therefore a floor that an incident can invalidate overnight. We develop the distinction between an audit and a test separately, in the article on how a security audit differs from a penetration test.
Does the NIS2 Directive impose a testing frequency?
It does not — and this is the most frequently repeated error in compliance conversations. Article 21(2)(f) of Directive (EU) 2022/2555 requires “policies and procedures to assess the effectiveness of cybersecurity risk-management measures”. Not a word about method, not a word about cadence.
The check is as simple as it was for the Act. Across the entire Directive the phrase “penetration testing” appears twice, and both occurrences sit in the recitals: once in the description of managed security service providers, once in the list of services competent authorities may use in the course of supervision. In the enacting terms — Articles 1 to 46 — it does not appear at all.
The practical consequence is friendlier than it sounds. Since the Directive states no figure, nobody will accuse a company of testing “too rarely for NIS2”. What will be challenged is the absence of a policy that sets the frequency, and the absence of evidence that the chosen cadence follows from assessed risk. A justified cadence of every 18 months is stronger in that setting than an unjustified annual one. We collected the broader legal context in the article on the law and regulations governing penetration testing.
Where does regulation state a specific figure?
In the DORA Regulation — and only there are the figures unambiguous. Article 24(6) of Regulation (EU) 2022/2554: financial entities other than microenterprises “shall ensure, at least yearly, that appropriate tests are conducted on all ICT systems and applications supporting critical or important functions”.
The second figure comes from Article 26(1): advanced testing by means of TLPT must be carried out “at least every 3 years”, and the competent authority may — based on the risk profile of the entity and its operational circumstances — request that the frequency be decreased or increased. The Regulation defines TLPT itself as a red team exercise mimicking the tactics, techniques and procedures of real-life attackers, run against the live production systems of the financial entity.
The third figure is not a figure at all but an event — and it illustrates this article’s thesis best. Article 25(2) requires central securities depositories and central counterparties to “perform vulnerability assessments before any deployment or redeployment of new or existing applications and infrastructure components, and ICT services supporting critical or important functions”. The EU legislator therefore abandons the calendar precisely where the stakes are highest. We described the TLPT model at greater length in the article on penetration testing in the financial sector under DORA.
Why is the calendar a poor trigger for a test?
Because a test captures the state of a single day, while the system changes with every sprint. NIST puts this plainly in SP 800-115, Technical Guide to Information Security Testing and Assessment (September 2008), in section 6.2 on assessment frequency: “Important technical considerations can also help determine testing frequency.” The same section notes that regulatory compliance is only one of the drivers, alongside system criticality and available resources.
The same idea underpins the OWASP methodology. The Web Security Testing Guide opens its chapter on the development lifecycle by observing that most organisations do not test software until it has reached the deployment phase, and calls that habit “generally a very ineffective and cost-prohibitive practice”. The recommendation runs the other way: weave security testing into every phase of the cycle.
Arithmetic closes the argument. A team shipping changes to an internet-facing application every two weeks accumulates roughly 26 deployments between one annual pentest and the next, none of which anyone has examined from an attacker’s perspective. An annual cadence then describes one day out of 365, not the security posture of the application.
When should a change in the system trigger a test?
When the attack surface changes, not when the volume of code does. A new API exposed publicly, a service migrated to the cloud, a change to the authentication mechanism, an external integrator wired into the internal network, a portal opened for business partners — each of these events creates an access path that was not in scope during the previous test.
Changes that leave that surface untouched should not incur the cost of a test. A performance fix in the presentation layer, a content update, a refactor that does not alter the API contract — that is material for scanning and code review, not for a full pentest. The distinction is worth writing into the policy as a list of triggering events, because otherwise it is settled by the budget rather than by risk.
Practical checklist: before scheduling the next test, list every deployment recorded in the change register since the date of the last report and mark those that touched authentication, authorisation, external integrations or internet exposure. The number of marked entries is a better basis for timing than a date in the calendar.
When should a new vulnerability trigger a test out of sequence?
When it is actively exploited and affects technology you actually run. The Known Exploited Vulnerabilities catalogue maintained by the US agency CISA is the most convenient source here, because it lists only vulnerabilities with confirmed exploitation in real-world attacks.
The scale of that stream tends to surprise. The catalogue release labelled 2026.08.24 contains 1,675 entries, of which 274 were added over the preceding twelve months — on average one newly exploited vulnerability every day and a half. You can reproduce this measurement yourself: the catalogue JSON file is publicly available and every entry carries a dateAdded field.
Not every one of those entries concerns your technology stack, and that is exactly the point. The trigger is not the catalogue entry itself but the intersection of the catalogue with your asset register. Without a current inventory of hardware and software that intersection cannot be computed — and the organisation falls back on the calendar, because it has nothing to replace it with.
How does scanning cadence differ from pentest cadence?
Scanning is meant to be continuous, penetration testing event-driven. These are two different methods with different unit costs and different result profiles: a scanner compares system state against a database of known vulnerabilities and can run daily, while a pentester hunts for business logic flaws, privilege chains and process abuse that no database describes.
NIST combines the two into a single recommendation, describing in SP 800-115 a model in which regular vulnerability scanning is interspersed with periodic penetration testing. The operational conclusion: the question “how often should we pentest” only makes sense once scanning already runs continuously. Without that, a penetration test becomes a prosthesis for monitoring — the most expensive possible way to discover an outdated library version. We develop this in the article on continuous security testing.
How do you set your own penetration testing cadence?
By crossing the class of the system with the pace at which it changes, rather than by picking one number for the whole organisation. The table below is a decision tool: find the row matching your system, check the floor imposed by regulation, and add the triggers that in your case call a test out of sequence.
| System class | Regulatory floor | Event triggering an out-of-sequence test | What the calendar cannot replace |
|---|---|---|---|
| ICT system supporting critical functions in a financial entity | Testing at least yearly (DORA Article 24(6)); TLPT at least every 3 years (Article 26(1)) | Authority request to increase TLPT frequency | The tester independence requirement (Article 24(4)) |
| System used to provide a service in an essential entity under the Polish NSC Act | Audit at least once every 3 years (Article 15(1)); first one within 24 months (Article 16(2)) | External audit ordered by the authority (Article 15(1b)) | The 3 working day deadline for submitting the report (Article 15(1a)) |
| Internet-facing web application deployed more than once a month | No statutory floor | Change to authentication, authorisation or the API contract | Verification of changes shipped after the report date |
| Internal infrastructure with a low rate of change | No statutory floor | A new supplier wired into the internal network | A check of actual network segmentation |
| Any system built on a component listed in the KEV catalogue | No statutory floor | An entry covering your version of the component in the CISA catalogue | A retest after the fix is deployed |
The table deliberately omits a “recommended number of tests per year” column. Such a column would be the calendar returning under a different name.
Where should you start if you have no cadence yet?
With three documents that in most organisations already exist in fragments: a register of systems with assigned criticality, a change register with deployment dates, and the last test report together with the date it was signed. Putting the three side by side shows how many changes reached production outside the scope of the last verification — and that is the real measure of the backlog.
The second step is to write the cadence into a policy, together with its justification. A supervisory authority will not challenge a number that the entity can derive from assessed risk; it will challenge the absence of one. At nFlo we start from exactly that comparison before defining any scope — penetration testing planned without a change register tends to measure what was easy to measure rather than what has actually changed.
The third step applies to essential entities only: check the signature date on the report from your last security audit and count three years from it. That is the one deadline in Polish law which runs regardless of whether anybody remembers it.
Sources
- Act of 23 January 2026 amending the National Cybersecurity System Act and certain other acts (Journal of Laws 2026 item 252), Articles 8, 15, 16, 36a–36b, 49
- Announcement of the Marshal of the Sejm of the Republic of Poland of 29 December 2025 on the publication of the consolidated text of the National Cybersecurity System Act (Journal of Laws 2026 item 20)
- Regulation (EU) 2022/2554 of the European Parliament and of the Council of 14 December 2022 (DORA), Article 3(18), Articles 24–26
- Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 (NIS2), Article 21(2)(f)
- NIST, Technical Guide to Information Security Testing and Assessment, SP 800-115, September 2008, section 6.2
- OWASP, Web Security Testing Guide, chapter 2 — Principles of Testing, The SDLC is King
- CISA, Known Exploited Vulnerabilities Catalog, release 2026.08.24 (1,675 entries, as at 24 August 2026)
