The short answer: Under Section 15 of zákon č. 264/2025 Sb., only providers of regulated services are required to report cybersecurity incidents. Reports are submitted to NÚKIB, primarily using a form on the Portál NÚKIB, in several stages: an initial report no later than 24 hours after the designated person assesses the event as an incident, an incident notification within 72 hours of detection, and a final report within 30 days of the notification. Organisations that are not regulated do not have to report. This article is an informative overview, not legal advice—the wording of the law and implementing regulations is authoritative.
Zákon č. 264/2025 Sb., o kybernetické bezpečnosti, took effect on 1 November 2025 and repealed zákon č. 181/2014 Sb. through Section 72. Registration has its own 60-day deadline (Section 6(1)), while security measures must be implemented within one year of receiving the registration decision (Section 13(4)). Incident reporting, however, cannot be scheduled in advance: it is triggered by an event, and its deadlines are measured in hours.
A cybersecurity incident, or merely an event?
The law uses two terms, and the distinction between them determines whether a reporting deadline has started to run.
Under Section 2(2)(f) of the law, a cybersecurity incident is „a breach of information security in cyberspace". Information security means ensuring the confidentiality, integrity, and availability of information and data (Section 2(2)(b)). NÚKIB explains these three properties as follows:
- Confidentiality is breached when information is accessed by someone who should not have had access to it.
- Integrity is breached when information is altered or deleted through unauthorised interference.
- Availability is breached when information is not accessible when it should be.
Under Section 2(2)(e), a cybersecurity event is „an event that may result in a cybersecurity incident"—it has the potential to develop into an incident, but no breach has yet occurred. Reporting events is voluntary and uses the same reporting channel.
The distinction is clear in an example used by NÚKIB itself. If a phishing email passes through a filter and reaches a user, but the user does not click anything and reports the message, it is an event. If the user clicks the link and enters their work credentials into the attacker’s form, it is a reportable incident because data confidentiality has been breached.
The definition also includes the element of being unplanned. A loss of availability during an approved maintenance window or a controlled change is not reported because intentional causation can be ruled out.
Who is required to report an incident?
Section 15 of the law imposes the reporting obligation only on providers of regulated services. Others do not have to report, although they may do so voluntarily. Whether you fall within the scope of regulation is covered in a separate article explaining who is affected by zákon 264/2025; here, we assume that you do.
A provider of a regulated service reports incidents that meet all three of the following conditions:
- they occurred within the defined scope of cybersecurity management (Section 12 of the law),
- they originated in cyberspace,
- intentional causation cannot be ruled out without undue delay and no later than within 24 hours.
The third point is the most important in practice. Operational incidents for which intent can be ruled out—a failed disk, an incorrect configuration, or a power outage—are not reported. If you cannot rule it out, however, you must proceed with the report.
The scope of reportable incidents also differs by regulatory regime:
- Higher-obligation regime—all incidents meeting the three conditions above must be reported.
- Lower-obligation regime—only incidents that have a significant impact on the provision of the regulated service must be reported. The provider assesses significance itself using the criteria in Section 14 of vyhláška o bezpečnostních opatřeních v režimu nižších povinností.
For selected digital services—including cloud services, data centres, DNS, online marketplaces, search engines, social networks, managed security services, and others—a significant incident is defined by Commission Implementing Regulation (EU) 2024/2690, irrespective of the applicable regime. The reporting method and deadlines remain the same.
Where and how to report
Reports are submitted to the authority, NÚKIB, and the primary channel is the form on the Portál NÚKIB (portal.nukib.gov.cz). This applies to all regulated entities, regardless of their regime.
If the Portál NÚKIB cannot be accessed—which may be caused by the incident itself—Section 16(4) of the law allows the incident to be reported by email or datová schránka. NÚKIB publishes cert@nukib.gov.cz for the higher-obligation regime, abuse@csirt.cz for the lower-obligation regime, and the datové schránky zzfnkp3 and h4axdn8. These fallback channels are temporary emergency measures, not standard alternatives.
The NÚKIB telephone lines—541 110 555 during business hours and 725 502 878 outside them—are intended for rapid communication and immediate assistance. However, the authority expressly states that reporting by telephone does not constitute an official report. You may call, but the reporting obligation will not have been fulfilled.
The practical conclusion is that more than one person must have access to the Portál NÚKIB, and that access must not depend solely on infrastructure that may be encrypted or disconnected when it is needed.
Incident reporting deadlines: 24 hours, 72 hours, 30 days
The process has several stages. For less serious incidents affecting providers in the higher-obligation regime, it may end with the initial report. For incidents with a significant impact, it continues through several steps and concludes with a final report.
| Stage | Deadline | When it starts | Required content |
|---|---|---|---|
| Initial report | without undue delay and no later than within 24 hours | when the designated person assesses the detected event as an incident | notification that an incident has occurred |
| Incident notification | 72 hours (24 hours for providers of trust services) | from detection of the incident | a more detailed assessment of the incident, its impact, and indicators of compromise |
| Interim report | at the request of NÚKIB or Národní CERT | — | material changes in the status of incident handling |
| Final report | 30 days | from the incident notification | description of the incident, its severity and impact, the type of threat, probable root cause, mitigation measures, and any cross-border impact |
The timeline and description of the stages come from the NÚKIB supporting document „Hlášení kybernetických bezpečnostních incidentů", version 1.2 dated 8 June 2026. Three points in the table are easy to overlook.
After the initial report, the authority decides—not you. For a provider in the higher-obligation regime, NÚKIB determines whether the incident has a significant impact. If it does not, the organisation’s reporting process ends at this stage and no further reports are submitted.
If the incident is still ongoing when the deadline expires, the organisation submits an interim report on the current status of its response after the deadline and files the final resolution report no later than 30 days after the incident has been resolved.
The first 24 hours are measured from the assessment, not from the attack. The deadline starts when the designated person—for example, the cybersecurity manager—assesses the detected event as an incident. NÚKIB adds two qualifications: the designated person does not decide what they personally consider an incident, but whether the legal definition has objectively been met; and the assessment must be completed as quickly as possible. Delaying it is not a way to extend the deadline.
The Czech deadlines are based on the NIS2 Directive (Directive (EU) 2022/2555), Article 23(4) of which requires an early warning within 24 hours, an incident notification within 72 hours, and a final report within one month for significant incidents. Czech law adopts this structure but uses its own terminology and method of calculating deadlines, so follow the Czech wording and NÚKIB guidance.
What to prepare in advance so you can meet the deadlines
Twenty-four hours sounds like plenty of time until you have to deal simultaneously with encrypted data, calls from customers, and the question of who actually has access to the portal. Most of the necessary groundwork can be completed in advance.
| What to prepare | Why it is often unavailable during an incident |
|---|---|
| A specifically designated person who assesses whether an event is an incident, plus a deputy | The 24-hour deadline starts with that person’s assessment. Without a deputy, annual leave or illness can bring the process to a halt. |
| Access to the Portál NÚKIB for two people, independently of the main infrastructure | A single account tied to the company’s sign-in system becomes inaccessible precisely when it is needed. |
| An offline contact list: fallback reporting channels, IT provider, connectivity provider, lawyer, insurer, and bank | Contacts stored only in email or on the intranet disappear along with those systems. |
| An asset inventory—servers, applications, data, their owners, and suppliers | Without it, you cannot determine whether the incident occurred within the defined scope and therefore whether it must be reported at all. |
| A documented scope of cybersecurity management under Section 12 | This is one of the three conditions for a reportable incident. Trying to reconstruct it under pressure means guessing. |
| Logs with sufficient retention and synchronised timestamps | Without them, you have no reliable basis for reconstructing indicators of compromise or the timeline. |
| An incident description template: what happened, when it was detected, what it affects, its impact on the service, and what has already been done | The report can then be completed by filling in the details instead of being written from scratch. |
| An ongoing record of who did what and when | The final report requires the probable cause and the measures taken. After a month, no one will remember every detail. |
| Up-to-date contact details in the Portál NÚKIB | After the initial report, the authority announces whether the incident has a significant impact. It must be able to reach you. |
Each item takes hours to prepare in advance—and days to reconstruct during an incident.
Preparedness matters more than the form
Reporting is the administrative part. The other part is the ability to restore operations, which determines how long the incident will last and what the final report will ultimately say.
In practice, this means having backups that someone regularly tests by restoring them, along with a recovery plan specifying the order in which systems will be restored, individual responsibilities, and acceptable downtime. A backup that has never been restored is merely an assumption. Where data on a server has already been compromised, the available options are described in a separate article on recovering data from a server.
The technical procedure for the first hours after an attack—what to disconnect, what not to switch off because of evidence preservation, and how to determine the scope—is covered in a separate article about the first 24 hours after ransomware hits a company. Both tracks run in parallel: while technicians handle isolation and recovery, someone else monitors the deadline and submits the initial report. Assign these responsibilities to different people.
It is also worth noting what does not constitute an offence. The mere fact that an incident has occurred at an obligated entity is not an offence. Failing to report it on time—or at all—is an offence, as is ceasing communication after submitting the initial report of a significant incident. The law defines these offences in its sanctions provisions; verify the specific amounts of fines in the current wording. NÚKIB also states that reporting an incident does not in itself immediately provide grounds for a subsequent inspection.
If you are not regulated
Most small and medium-sized companies are not providers of regulated services and therefore have no obligation to report incidents to NÚKIB. Voluntary reporting is nevertheless possible: entities without a statutory obligation may report both incidents and events to the authority through the same channels. This is particularly worthwhile when the incident involves a wider campaign or a vulnerability that also affects others.
Extortion, typically in the form of ransomware, should be reported to Policie ČR. It is a criminal offence, and reporting it to Policie ČR is not the same as submitting an incident report to NÚKIB—these are two independent steps involving different recipients. If the incident affected personal data, a reporting obligation under the GDPR to Úřad pro ochranu osobních údajů may also apply; this is a separate legal regime and must be assessed independently.
The checklist in the previous section is useful regardless of whether you are regulated. Knowing who makes decisions, keeping contacts offline, maintaining an asset inventory, and retaining logs for a reasonable period are valuable even for a company that falls entirely outside the scope of the law. The only difference is that a regulated entity may face penalties for non-compliance, while others face a longer outage.
In Brno, ITHOPE provides IT management for companies and helps them prepare for situations of this kind: backups regularly tested through restoration, a recovery plan with defined responsibilities, and the documentation needed to compile a report within the deadline—including an asset inventory, logs with usable retention, and a contact list stored outside the corporate network. Details are available on the IT management and backup page, with an overview of services under IT for businesses. The assessment of whether the law applies to you and under which regime is a matter for your lawyer.
Sources
- Zákon č. 264/2025 Sb., o kybernetické bezpečnosti — e-Sbírka (effective from 1 November 2025; Section 72 repealed zákon č. 181/2014 Sb.; Section 6(1) and Section 13(4))
- Hlášení kybernetických bezpečnostních incidentů, TLP:CLEAR, verze 1.2 z 8. 6. 2026 — NÚKIB supporting document (definitions of an incident and an event, the three conditions for a reportable incident, the 24-hour / 72-hour / 30-day timeline, and offences)
- Hlášení incidentů — kontakty a způsoby hlášení — NÚKIB (Portál NÚKIB, fallback reporting under Section 16(4), email addresses, datové schránky, and telephone lines)
- Hlášení kybernetického bezpečnostního incidentu — Portál NÚKIB, forms for the individual reporting stages
- Directive (EU) 2022/2555 (NIS2), Article 23(4) — EUR-Lex (24 hours, 72 hours, one month)
Where to find us
ITHOPE is a company based in Brno, Czechia: we do data recovery from disks, RAID and NAS, PC and laptop service and IT for business, all in our own lab at Viniční 3587/216, 615 00 Brno.
Phone +420 775 556 063 (24/7 line). You can bring the device in person, or send it by courier (Zásilkovna, PPL).