NÚKIB registration is done. What you must finish before the deadline

Registration was the easy part. The year for implementing measures runs from delivery of your decision — and 24-hour incident reporting applies right now. Timeline, month-by-month plan and what inspectors ask.

The Czech Cybersecurity Act landed on several thousand companies, which had to notify their regulated service to the National Cyber and Information Security Agency (NÚKIB) by the end of 2025. Most of them managed it — form, contact person, submitted.

And then silence. The sentence we have heard most often since: "we are registered, that's behind us."

It isn't. Registration is an application, not compliance. Only after it does the clock start on the main task — implementing the security measures. And two obligations apply immediately, regardless of how much time you have left for the rest.

Three deadlines that get mixed up most often

The year for implementation runs from delivery of the decision, not from New Year's Day

The Act gives you one year to implement the security measures, counted from the day the decision registering your regulated service was delivered to you. That is the crucial detail: every company has a different date. There is no shared "end of 2026" deadline, even though people talk about it that way — it is simply that for the main wave, which registered around the turn of 2025 and 2026, most deadlines fall in the second half of 2026 and the beginning of 2027.

The practical consequence: your exact date is in your own decision. Before planning anything, find that document and write the delivery date at the top of your plan. Everything else follows from it.

Incident reporting: 24 hours, 72 hours, 30 days — and it applies right now

This is the distinction that costs companies most. Reporting a significant incident does not wait for the end of the one-year period. Once you are registered:

• within 24 hours of discovery — the initial report, even if you don't yet know exactly what happened,
• within 72 hours — supplementary information on how the situation is developing,
• within 30 days — the final report.

Twenty-four hours is not much. Especially when an incident starts on Friday evening and the person with access to the authority's portal is in the mountains. So your plan needs one boring item nobody enjoys: who reports, from which account, and who stands in for them. Testing that sign-in in advance takes ten minutes. During an incident it is the most valuable ten minutes you have.

And what actually counts as a "significant" incident?

What gets reported is an incident with a serious impact on the delivery of your regulated service — typically an outage, a data breach, or a disruption that materially limits the service. Every company has to set that threshold itself, and in advance, because when it is happening there is no time for debate.

A recommendation from practice: write down three to five concrete situations from your own operation where "we report this" applies (for example, the server running your production system gets encrypted, the whole company loses access to Microsoft 365, a confirmed leak of customer data). If you are unsure whether a situation qualifies, report it — a late report is worse than an unnecessary one.

Changes get reported as they happen

The third deadline cannot be planned, because it depends on you. If the contact person, the scope of the service or the details you submitted change, you have to notify the authority. The most common source of trouble is mundane: the contact person no longer works for the company, and official messages arrive in a mailbox nobody reads.

What exactly has to be finished

The scope differs depending on whether you are in the lower or the higher obligations regime. Simply put: the lower regime has a narrower scope and lighter formal requirements, the higher regime means more documentation, more defined roles and stricter proof. The areas, however, are the same in both cases. Specifically these — and for each, try answering right away whether you have it or not:

• Access and password management — who can reach what, how it is approved, and what happens when someone leaves.
• Multi-factor authentication — on all accounts, including admin and service accounts.
• Monitoring and logging — that records are collected, kept long enough, and that somebody looks at them.
• Incident handling — who assesses incidents, who reports them, who is the deputy.
• Backup and recovery — including a tested restore, not just a backup job that runs.
• Supplier management — who has access into your environment from outside, and under what terms.
• Updates and configuration management — that patches get deployed and settings don't drift.
• Training and awareness — demonstrable, not "we told them once".

We explain the difference between the regimes in plain language on the NIS2 hub.

One practical rule holds for both regimes: every measure needs the trio decision — configuration — evidence. The decision that this is how it's done (and who approved it). The configuration in the system. And evidence that the configuration really applies — an export, a screenshot, a test record. Companies usually have the middle item and are missing the two on either side.

A plan for the rest of your deadline

The schedule below assumes you are roughly halfway through the one-year period. If you have more time, shift it; if less, start with the first two rows and run the rest in parallel.

Where companies lose the most time

Waiting for a management decision. A technician cannot decide alone what the regulated service is and what will be protected. Until management approves it, everything is done "probably". This item is the cheapest to do and the most expensive to postpone.

Suppliers. Supply-chain security means asking the companies that run your IT, your machines or your accounting system how they get in, who on their side has access, and what happens if the incident is at their end. Answers take weeks and sometimes require a contract amendment.

Multi-factor authentication across every account. An afternoon of technical work, months of organisational work — because ten exceptions turn up and each has its defender. The sooner you start, the less it hurts.

Logging and retention. Finding out that records are kept for a shorter period than you need usually comes late. And the fix touches licences, therefore budget, therefore another approval round.

Working out what you actually have. A surprisingly common brake: the company has no current list of servers, applications, domains and accounts. Without it there is no way to say what is being protected — so the first month goes on an inventory that should have existed long ago. If this is you, start there; it goes faster than expected and clarifies everything else.

What happens if you miss it

The authority can order corrective measures and impose a fine. The ceilings are high: in the higher obligations regime up to CZK 250 million or 2 % of net worldwide annual turnover, in the lower regime up to CZK 175 million or 1.4 % of turnover — whichever is higher.

To be fair, these are ceilings for the most serious cases, and mitigating circumstances are taken into account. We don't want to build a sales argument on it — a fine is a fact, not an incentive. Something else matters more: responsibility sits with company management. It cannot be transferred to the IT administrator or to a supplier. Details on inspections and penalties are on our NIS2 hub.

What the authority will want to see

An inspection does not start with a tour of the server room. It starts with documents and with questions answered on paper or by an export from a system. Expect four kinds of question:

"What is your regulated service and what belongs to it?" Expected: a list of systems, data and people the protection covers — and the management decision that set that scope.

"How is it configured?" A description is not enough here. What is wanted is proof from the system: a settings export, a list of policies, a list of highly privileged accounts. The easiest approach is to assemble such a pack once and refresh it quarterly.

"When did you last verify it?" The most common weak spot. Backups run, but a test restore has never been done. An emergency account exists, but nobody has ever signed in with it. The date of the last test is exactly what separates a fulfilled obligation from an unfulfilled one.

"Who decided this?" For every measure it should be traceable who approved it and when. Signed minutes are enough — it doesn't have to be elaborate, but it has to exist.

Prepare these four answers as you go and an inspection is administration. Don't, and it is a week of digging through old e-mails.

If you haven't started yet

You are not alone, and panic won't help. Three steps, in this order:

1. Find out where you stand from the outside. The free on-line security audit checks what is publicly visible about your domain — SPF and DMARC, certificates, leaked passwords. Five minutes, no meeting. It is the fastest way to get a first concrete list.

2. Find out where you stand from the inside. In an ordinary company most measures are configured in Microsoft 365. The ten places where it most often falls short are covered in NIS2 and Microsoft 365: the 10 gaps we find most often. If you want all fifty or so settings checked at once, the NIS2 Microsoft 365 audit costs CZK 14,900.

3. Give it an owner and deadlines. A list with no date and no name is just a list. This is the one step nobody can do for you.

Frequently asked questions

We missed the registration. What now?

The obligation has not gone away — it continues, and being late doesn't cancel it. The sensible course is to notify as soon as possible; the authority routinely deals with companies that discovered the obligation late. There is no point delaying: the sooner you register, the sooner the implementation period starts, and you will need all of it anyway.

Do we need a certification, such as ISO 27001?

No. The Act does not require certification. An existing security management system makes compliance easier, because part of the documentation and processes already exists, but the certificate itself is neither a condition nor proof that you have met the Act.

Are policies enough, or is the configuration checked too?

Both are checked. A policy states how it should be; an inspection asks whether it is. That is exactly why we recommend keeping the decision — configuration — evidence trio for every measure. A document with no matching configuration is arguably worse at an inspection: it proves you knew about the obligation.

Who is responsible inside the company?

Management. That is probably the single most important sentence of the Act for an owner. The IT administrator or an external supplier implements the measures, but responsibility for having them in place stays with company management. In practice that means having a name that answers for it, and a written record of what was approved and when.

This article is an orientation overview, not legal advice. Your specific classification, regime and exact deadline are in your own registration decision.