Security audit frequency: trigger-based, not calendar-driven, with one statutory exception

Q: Security audit frequency: trigger-based, not calendar-driven, with one statutory exception

For most organisations, Czech law does not set a single calendar deadline for a security audit; the interval is something the organisation determines and justifies itself, and the real trigger for re-auditing is a significant change, not the calendar. There is one documented statutory exception: an entity in the higher-obligations regime under the Czech cybersecurity law must have its cybersecurity audit performed at significant changes and, separately, at regular intervals of at least once every two years, with a narrow allowance to complete a full-scope audit incrementally over up to five years in justified cases. If you do not know whether that regime applies to you, that is the first question to answer, before picking an interval.

Two different answers, depending on who you are

“How often should we run a security audit” has two different correct answers in Czech law, and giving the wrong one to the wrong organisation is a real risk in either direction. Most organisations set their own interval. A specific, named category does not.

The general rule: risk-based, trigger-driven, self-determined

For an organisation outside the regime described below, no single Czech statute prescribes a fixed audit interval. The obligation that does exist, whether under the cybersecurity law’s general provisions, NIS2-adjacent expectations, or GDPR’s security-of-processing requirement, is to manage risk on an ongoing basis and be able to justify your review cadence, not to hit a specific number written into a table. In practice this means:

The interval is something you set and document, based on the risk you have actually assessed, not a number you picked because it is customary.
The real trigger for re-auditing is a significant change: a new integration, a migration to a different environment, a supplier change, an incident, or a material shift in what the system does or who it affects.
A calendar default (commonly once a year) is common because it is administratively convenient, not because a general statute compels it.

The exception: the higher-obligations regime has a real number

Entities identified under the Czech cybersecurity law (Act No. 264/2025 Coll., which implements the EU’s NIS2 directive) as falling into the higher-obligations regime are a documented exception to the “no fixed deadline” rule. Section 16(4) of Decree No. 409/2025 Coll., which sets out the detailed security-measure requirements for that regime, states that the cybersecurity audit required under section 16(2) is performed:

(a) at significant changes, within the scope of that change,
(b) at regular intervals of at least once every two years, and
(c) in accordance with the entity’s cybersecurity audit plan.

The change-trigger and the two-year interval are cumulative requirements, not alternatives. A significant change does not push back the two-year clock, and reaching the two-year mark does not excuse skipping an audit after a significant change in between.

Section 16(5) adds a narrower allowance: in justified cases, a full-scope audit may be carried out incrementally, in systematic parts, provided the entire audit scope is completed at least once every five years. This is a phasing mechanism for large or complex environments, not a general extension of the two-year rule; it does not apply automatically and needs to be justified as part of the audit plan.

Figuring out which answer applies to you

Whether an organisation falls into the higher-obligations regime is determined through a formal identification process under Act No. 264/2025 Coll., not by self-assessment based on how important the organisation feels its systems are. If you do not already know your regime status with confidence, resolving that question comes first; it determines whether “at least once every two years” is a legal floor for you or a reasonable practice you have chosen for other reasons.

For the difference between the audit itself and an active penetration test that may feed into it, see penetration test or security audit: what is the difference. For what an AI system audit specifically covers, see what an AI system audit actually tests. More answers are in the answer hub; to work out your regime status and audit plan, use the inquiry form.

Sources and limitations

Section 16(4) and (5) of Decree No. 409/2025 Coll. were read directly from the official Sbírka zákonů publication text, verified 6 August 2026. Whether the higher-obligations regime applies to a specific organisation is a legal classification question this page does not answer; it depends on facts about that organisation under Act No. 264/2025 Coll. that need individual review, ideally with a lawyer or with CIAD as part of a scoping engagement.

Frequently asked questions

Does Czech law set a general deadline for security audits?

No single deadline applies to every organisation. Outside the specific statutory regime described below, an organisation determines its own audit interval based on the risk it assesses, and needs to be able to justify that interval if asked. A calendar default of once a year is common in practice because it fits budget cycles, not because a statute requires it for most organisations.

What is the higher-obligations regime, and does it apply to us?

It is a specific category under the Czech cybersecurity law (Act No. 264/2025 Coll., implementing the EU's NIS2 directive) for entities identified as carrying a higher level of cybersecurity risk or importance, typically larger or more critical regulated services. Whether it applies to a specific organisation depends on a formal identification process under that law, not on self-assessment; if you are unsure, that determination should come before you set an audit interval, not after.

What does the statutory interval actually require?

Section 16(4) of Decree No. 409/2025 Coll. requires the cybersecurity audit for a higher-obligations-regime entity to be performed (a) at significant changes, within the scope of that change, (b) at regular intervals of at least once every two years, and (c) in accordance with the entity's cybersecurity audit plan. Section 16(5) allows a full-scope audit to be carried out incrementally, in justified cases, as long as the entire scope is completed at least once every five years. The two-year interval and the change trigger are both requirements, not alternatives; a significant change does not reset or postpone the two-year clock.

If we are not in the higher-obligations regime, does 'trigger-based' mean we can skip audits?

No. It means the interval is not fixed by a specific number in the statute for your category, not that no audit obligation or good-practice expectation exists. NIS2-adjacent obligations and the GDPR both expect risk-based, ongoing security review; they simply do not name a fixed number of months or years the way the higher-obligations decree does for the specific regime it covers. A written, risk-based schedule that you can justify to a regulator or auditor is still expected.

What events should trigger a re-audit regardless of the calendar?

A new integration or system handling sensitive data, migration to a new environment or provider, a significant supplier change, a security incident, or a material change to the scope of a regulated service. These are the events Decree 409/2025 itself names as triggers for the higher-obligations regime, and they are a reasonable basis for any organisation's own trigger list even outside that regime.