FAQ · Frequently asked questions

QUESTIONS AND ANSWERS

Answers to common questions about the new Czech Cybersecurity Act (264/2025 Coll.). Filter the questions by category or search them by keyword.

Orientation only — not a legal opinion The answers below are our practical reading of Act No. 264/2025 Coll. and of Decrees 409/2025 (higher tier) and 410/2025 (lower tier). The Act is the Czech transposition of the NIS2 Directive, Directive (EU) 2022/2555, so anyone who knows NIS2 will recognise the structure of the obligations. There is no official English wording of the Act or its decrees — only the Czech text in the Collection of Laws is binding and everything here is an orientation translation, not an official one. See the Czech text of the Act in the e-Sbírka and the English text of NIS2 on EUR-Lex. These answers are not a binding legal opinion. For a definitive assessment of your situation we recommend the official NÚKIB sources or a lawyer registered with the Czech Bar Association. CypherOn provides cybersecurity consulting; it is not a law firm.

No question matches your search.

Basics of the new Act

Who does the new Act apply to?

Act No. 264/2025 Coll. reaches providers of regulated services in 15 sectors (Section 4) — public administration, energy, manufacturing, food, chemicals, water management, waste management, transport, digital infrastructure and services, financial markets, healthcare, science, research and education, postal and courier services, defence and space. The specific list of services, and the conditions under which they become regulated, is set out in Decree No. 408/2025 Coll. on regulated services.

Whether the Act reaches you depends on a combination of three factors: (1) the sector and type of service, (2) the size of the organisation (micro / small / medium / large under the EU SME definition), (3) in some cases a specific criterion — a licence from the Energy Regulatory Office, the Czech National Bank or the Czech Telecommunication Office, or the accreditation of a medical laboratory.

The quickest way to find out where you stand is our calculator. For a definitive answer use the official NÚKIB calculator.

What do the lower and higher tiers of obligations mean?

The Act splits regulated entities into two categories according to how serious the impact of their service would be:

  • Higher obligations (essential entities) — the most important entities (banks, electricity distributors, hospitals, DNS providers, TLD registries, central government bodies). The full set of obligations: an ISMS, the role of a cybersecurity manager (MKB in Czech), a mandatory audit, registration, full incident reporting, fines up to CZK 250 million / 2 % of turnover.
  • Lower obligations (important entities) — important but not critical (mid-sized manufacturers, SMEs, distributors, regional authorities). A narrower set: simplified risk management, baseline security controls, incident reporting. Fines up to CZK 175 million / 1.4 % of worldwide turnover (Section 59).

The key difference: entities in the higher tier have to go through a mandatory external audit and run a fully developed ISMS, entities in the lower tier do not. The incident reporting deadlines are the same in both tiers — early warning within 24 h of detection, notification within 72 h, final report within 30 days of the notification (Section 16). What differs is the recipient: the higher tier reports to the Authority, the lower tier to the National CERT, in both cases through the NÚKIB portal.

How is the size of a company calculated?

Size is calculated under Commission Recommendation 2003/361/EC from three figures:

  • Headcount in annual work units (AWU)
  • Annual turnover
  • Balance sheet total

The thresholds:

  • Micro: < 10 employees and (≤ EUR 2 million turnover OR ≤ EUR 2 million balance sheet total)
  • Small: < 50 employees and (≤ EUR 10 million turnover OR ≤ EUR 10 million balance sheet total)
  • Medium: < 250 employees and (≤ EUR 50 million turnover OR ≤ EUR 43 million balance sheet total)
  • Large: anything above that

Between turnover and balance sheet total you take the more favourable (lower) category. Between headcount and the financial figures you take the higher one — with 300 employees you are a large company even on a turnover of EUR 5 million.

Watch out: in groups of companies, partner and linked enterprises count towards the totals, per the SME user guide. Our calculator does not account for that.

When do we need to start dealing with the Act?

Short answer: now, if the Act reaches you.

The Act expects the entity itself to assess whether it is regulated and to notify the service to the Authority within 60 days of the day the conditions were met (Section 6). NÚKIB then decides on registration; only once that decision is delivered does the 30-day deadline for supplementary details start to run (Section 11). You have one year from delivery of the registration decision to implement the security measures (Section 13) — the clock runs from your own registration, not from a fixed date tied to the Act taking effect.

A realistic schedule for a mid-sized company in the lower tier:

  • 0–3 months: gap analysis, appoint the MKB or an accountable person, notify the regulated service to the Authority, get the core policies approved by management.
  • 3–6 months: asset register, risk assessment, MFA on key access paths, incident response plan.
  • 6–12 months: 3-2-1 backups, EDR, security awareness training, assessment of key suppliers, documentation ready for an inspection.

For the higher tier, plan on 12–18 months and an external audit.

How does the Act relate to the old act (181/2014)? And to NIS2?

The new Act No. 264/2025 Coll. replaces the original cybersecurity act (181/2014 Coll.) and transposes the NIS2 Directive (Directive (EU) 2022/2555) into Czech law.

The main changes against the old act:

  • A far wider scope — the old concepts of “critical information infrastructure” and “significant information system” give way to regulated services across 15 sectors.
  • Mid-sized companies now carry a substantial body of obligations; previously they were typically outside the regime.
  • Reporting deadlines of 24 h / 72 h / 30 days, harmonised across the EU.
  • Personal liability of members of statutory bodies — explicitly new.
  • Higher fines, and fines that can run in parallel with GDPR.

If you were regulated under the old act, your regime changes and typically widens. A fresh assessment is worth doing.

Where do I find further official information?

Our own materials: guide to the Act, the Act interactive, higher-tier decree, lower-tier decree, higher-tier cheatsheet, lower-tier cheatsheet.

The lower tier of obligations

What exactly do I have to do in the lower tier?

In the lower tier (important entity) the expectation is a set of measures proportionate to the size and the risk profile of the organisation:

  • Governance: a designated accountable person, approved core policies (information security, access control, IRP, backup), an annual review.
  • Risk management: an asset inventory, a simple risk register with named owners, updated once a year.
  • Security controls: MFA on administrative and remote access, patch management, 3-2-1 backups with a restore test, central logging of key systems (≥ 90 days), EDR on endpoints.
  • Incident response: a documented plan with contacts, reporting through the NÚKIB portal within 24 h / 72 h / 30 days (in the lower tier the recipient is the National CERT, Section 15).
  • People: annual security awareness training, phishing simulations, a sane off-boarding process.
  • Suppliers: assessment of key ICT suppliers, contractual DPAs, incident reporting from suppliers.

In detail: the lower-tier decree, interactive or the two-page cheatsheet PDF.

Which incidents do I have to report, and by when?

What gets reported is a cybersecurity incident with an impact on the regulated service — a breach of availability, integrity or confidentiality, or a financial or societal impact. A breach with no demonstrated impact (a security event) is not reported, but document it internally.

The deadlines are the same in both tiers:

  • Early warning within 24 hours of detection.
  • Notification within 72 hours.
  • Final report within 30 days of submitting the notification.

“Detection” means the moment the accountable person, typically the MKB, has reasonable grounds for suspicion — not the moment the attack took place.

Practical advice: when in doubt, report. Under this Act a late report carries more risk than a report that turns out to have been unnecessary.

Do I need an MKB in the lower tier as well?

The lower tier does not require a formal “cybersecurity manager” (MKB) in the full sense the higher tier does, but you do have to designate a person accountable for cybersecurity. That person needs a mandate from management, sufficient authority, and a documented role.

For a mid-sized company there are three realistic options:

  • An existing IT manager with an extended role — roughly 20–40 % of their working time on security. Watch the conflict of interest: an IT manager cannot audit their own work.
  • An external consultant as a “virtual MKB” — typically 2–4 days a month. Suits companies with no internal capacity.
  • CISO-as-a-Service on a retainer — a higher level of involvement, workable for the lower as well as the higher tier.

Whichever you pick, three things matter: a written mandate from management, access to company leadership at least on an ad hoc basis, and documentation of the key decisions.

The higher tier of obligations

What exactly do I have to do in the higher tier?

The higher tier (essential entity) means the full set of obligations — typically 12–18 months of structured implementation. The main pillars:

  • An information security management system (ISMS) with a defined scope, a PDCA cycle and an annual management review.
  • The MKB — appointed by management, separated from IT operations, reporting directly to the statutory body.
  • Risk management with a methodology (NÚKIB or ISO 27005), a fully structured risk register, formal acceptance of residual risk.
  • The full breadth of security controls — IAM with phishing-resistant MFA plus PAM, EDR/XDR and ITDR, vulnerability management with SLAs, segmentation, a cryptographic policy including post-quantum.
  • A SOC or an MSSP with 24/7 coverage, automated device isolation through EDR, detections mapped to MITRE ATT&CK.
  • An incident response plan (IRP) with playbooks, an annual tabletop exercise, BCP/DR.
  • Supply chain security including SBOM, signed artefacts and continuous monitoring of suppliers.
  • A mandatory external cybersecurity audit by an independent auditor.

In detail: the higher-tier decree, interactive or the two-page cheatsheet PDF.

We hold ISO 27001 — does that cover the higher obligations automatically?

ISO 27001 is a strong foundation for the higher tier, but it is not an automatic substitute. The Act imposes specific duties that ISO 27001 does not cover explicitly:

  • Incident reporting through the NÚKIB portal within 24 h / 72 h / 30 days — ISO 27001 requires incident management, but reporting duties towards a national regulator are local.
  • Notifying the service to the Authority and communicating with it — purely a matter of the Czech Act.
  • A specific cybersecurity audit under Section 16 of Decree 409/2025 — a different scope and different qualification requirements from an ISO 27001 audit.
  • Specific technical measures from the decree (3-2-1 backups, the reach of MFA, log retention) are more prescriptive than the Annex A controls of ISO 27001.

In practice: if your ISO 27001 scope covers the regulated service, you are roughly 70–80 % of the way there. Add a gap analysis against the Act and Decree 409/2025, close the missing points, notify the service to the Authority, and document it.

Penalties and liability

What penalties apply if we do not comply?

Maximum fines (the higher of the fixed amount and the percentage of turnover):

  • Higher obligations: up to CZK 250,000,000 or 2 % of net worldwide annual turnover.
  • Lower obligations: up to CZK 175,000,000 or 1.4 % of net worldwide annual turnover.

In setting the amount, NÚKIB weighs the nature, seriousness and duration of the breach, whether it is repeated, any financial gain from it, cooperation with the Authority and the security posture actually achieved. Maximum fines are rare in NIS2 practice elsewhere in the EU, and decisions in the first Czech cases are not public yet.

The main risk point: a late or missing incident report — it is the obligation that can be tested most easily, and in NIS2 practice it is the most common reason for a penalty.

Combined with GDPR (4 % of turnover), a single incident can produce two parallel fines: one from NÚKIB and one from the Czech data protection authority (ÚOOÚ).

Are members of the statutory body personally liable?

Yes. The new Act explicitly establishes personal liability of members of statutory bodies for putting security measures in place and keeping them working. In cases of serious breach they can be sanctioned personally.

In practice the statutory body needs a demonstrable record that it:

  • Approved the security strategy and the key policies.
  • Received periodic reports on the state of security, typically quarterly.
  • Kept a record of the key decisions — board minutes, approved documents, a responsibility matrix.

A note on D&O insurance: standard directors and officers policies generally do not cover breaches of regulatory duties, nor intent or gross negligence. If you are relying on a policy, check the scope with the insurer in advance — a penalty for failing to report an incident or failing to implement measures can land on the individual.

We missed the deadline for notifying the service — what now?

The duty to notify a regulated service to the Authority within 60 days follows directly from the Act (Section 6), not from any letter from the regulator — so “nobody told us” is not an argument. NÚKIB then decides on registration by a formal decision; you cannot register yourself.

Practical advice: notify the service yourself and as soon as possible, even late. Mitigating circumstances — cooperation with the Authority, the security posture actually achieved — are weighed when a penalty is considered, and alongside a fine the Authority can order a remedial measure under Section 56, that is, fix the shortcomings within a set deadline.

If you are only now finding out that the Act reaches you, take it in this order:

  1. Confirm that you really are in scope (our calculator, the official NÚKIB calculator, legal advice where needed).
  2. If you are, notify the service to the Authority and state where you currently stand.
  3. Put together a 6–12 month plan for implementing the obligations.

Incident reporting

What is a “cybersecurity incident” and what is only an “event”?

An incident = a security breach with a demonstrated impact on the regulated service (availability, integrity, confidentiality, financial loss, physical or societal impact). Incidents have to be reported within 24 h / 72 h / 30 days through the NÚKIB portal — in the higher tier the recipient is the Authority, in the lower tier the National CERT (Section 15).

An event = a security breach with no demonstrated impact on the regulated service. Events are not reported, but document them internally.

The line is not always clear. Our recommendation: when in doubt, report. A false alarm will not count against you with NÚKIB; a late or missing report of a real incident can lead to a penalty.

Examples of incidents: ransomware encrypting even part of your data, theft of a customer database, an outage of the service longer than 4 hours, unauthorised access to an administrator account, a supply chain compromise that reaches your service.

How is an incident reported in practice?

Primarily through the NÚKIB portal, alternatively by e-mail or data box. NÚKIB runs a 24/7 hotline for the first notification.

What the sequence looks like during an incident:

  1. Containment — immediate steps to stop the spread (isolate the system, disable the account).
  2. First notification by phone to the NÚKIB hotline, within 24 h.
  3. Full report through the portal within the same 24 h, on the prescribed form.
  4. Notification within 72 h — what happened, what was hit, which indicators you already have.
  5. Interim updates when the Authority asks for them.
  6. Final report within 30 days of the notification — full analysis, root cause, measures to prevent a repeat.

Prepare in advance: a template with the static details pre-filled (company ID, contacts, sector), a contact matrix (who calls NÚKIB, who calls the lawyer, who handles external communication), playbooks for the typical scenarios.

What if the incident also involves personal data — how does GDPR overlap?

An incident involving personal data typically triggers parallel duties under this Act and under GDPR. The deadlines differ slightly:

  • The Act: early warning ≤ 24 h, notification ≤ 72 h, final report ≤ 30 days from the notification — through the NÚKIB portal (recipient: the Authority in the higher tier, the National CERT in the lower one).
  • GDPR: 72 hours to the supervisory authority plus “without undue delay” to the data subjects — the recipient is ÚOOÚ and, where required, the individuals affected.

In practice, run one reporting process that covers both sides. Penalties can stack — one incident can mean a fine from NÚKIB and a fine from ÚOOÚ.

For a specific GDPR case we recommend a data protection specialist — the interaction of the Czech Act, GDPR and NIS2 is not always intuitive.

Implementing security measures

Where do we start when the list of obligations is long and nothing is obviously first?

Recommended priorities for the first 90 days:

  1. Appoint the MKB or an accountable person and notify the regulated service to the Authority. Without this there is nobody to drive the rest.
  2. Gap analysis against Decree 409/2025 (higher tier) or 410/2025 (lower tier) — where you stand against where you need to be. The output is a list of priorities.
  3. MFA on all privileged and remote access — the largest security gain for the lowest cost. The reason: around 80 % of attacks start with a compromised password.
  4. EDR on all endpoints plus automated alerting into an on-call rotation. Without detection you have no chance of responding to ransomware.
  5. 3-2-1 backups with an offline or immutable copy and a monthly restore test. This is the difference between surviving ransomware and losing the company.
  6. An incident response plan with contacts and NÚKIB reporting templates — prepared before an incident, not during one.

That is the narrow foundation that gets you to the point where you can handle most real attacks. The rest — policies, audit, supply chain monitoring — fills in over 12–18 months.

Do we secure the whole organisation, or only the regulated service?

Formally the duty attaches to the regulated service and to every asset, process and supplier involved in providing it. In practice the boundary is porous — an attacker who compromises your “unrelated” systems usually reaches the regulated service as well.

We recommend one ISMS for the whole organisation, with the formal scope covering the regulated service. The reasons:

  • Splitting systems into “regulated” and “unregulated” is expensive and usually falls apart in practice.
  • Attackers do not make the distinction — they take the weakest link.
  • If ISO 27001 or SOC 2 is a later goal, building the wider scope from the start works out better.

The exception: genuinely isolated areas, an R&D lab with no connection to production for example, can be excluded from scope as long as you document it.

Should we build the MKB / SOC function in-house, or buy it as a service?

It depends on size, budget and available capacity. A realistic decision matrix:

  • Small company, up to 50 employees: everything external — a virtual MKB (CISO-as-a-Service), MDR for detection, an external audit. Budget roughly CZK 200,000–800,000 a year depending on scope.
  • Mid-sized company, 50–250 employees, lower tier: a hybrid — an internal accountable person (an IT manager with an extended role, or a virtual MKB for the expertise), an MDR service, an external audit as needed.
  • Higher tier: typically an in-house MKB plus an MSSP/MDR for 24/7 coverage, or an in-house SOC if you have 50+ FTE in IT and a security budget in the tens of millions of CZK a year.

What matters when choosing an external service:

  • Data sovereignty — where your logs are stored and who can read them.
  • Exit strategy — how quickly and in what format you get the data back when the contract ends.
  • Response SLA — from alert to detection, from detection to containment.
  • Detection rules — who writes them, whether they are specific to your environment, and whether you can see their content.

When the Act does not reach us

We are not in scope — can we ignore all of this?

No. Even if the Act does not reach you directly, you still have to deal with cybersecurity, for three reasons:

  • Contractual demands from regulated clients. If your clients fall under the Act, they will send you security questionnaires, ask for contractual DPAs, and in some cases audit their critical suppliers.
  • Other regulation — GDPR, eIDAS, the Czech electronic communications act and sector rules in healthcare or finance carry their own security requirements.
  • The threat itself. Ransomware, BEC and data theft hit small companies as much as large ones, and for a small company the cost of an incident can be existential.

We recommend putting in place at least a sensible minimum — see our page on the recommended security baseline or the NÚKIB support materials.

What if the Act starts to apply to us as we grow?

The Act applies to you from the moment you meet the criteria, typically when you cross a size threshold. You then have 60 days from the day the conditions are met to notify the service to the Authority (Section 6). NÚKIB then decides on registration.

How this plays out:

  • If you are growing towards 50 employees or EUR 10 million in turnover, start implementing six months ahead, before you cross the threshold. The Act lands the day after you cross it; readiness does not.
  • If you cross a threshold unexpectedly (a merger or an acquisition), contact NÚKIB yourself and agree a realistic implementation schedule.
  • The same logic applies to any change of tier — from outside the regulation into the lower one, or from lower to higher. Proactive communication with NÚKIB pays.

If you drop below the criteria and stop being regulated, tell NÚKIB and keep the measures you have implemented at least as a baseline. What you are saving is administration, not real security — the attacks do not change.

Have a specific question?

We will help you
find your way.

If your question is not in the FAQ, or you need your own situation assessed, book a no-obligation consultation. We will go through the scope of your obligations and what to deal with first.