NIS2 is not a task that management can hand over to an IT administrator with instructions to “secure the servers somehow”. It affects responsibility for business operations, suppliers, access rights, recovery after an outage, application development, and the way decisions are made during an incident.
In the Czech Republic, the obligations are not governed solely by the European NIS2 Directive itself. Act No. 264/2025 Coll., on Cybersecurity, together with its implementing decrees, has been in force since 1 November 2025. Companies must therefore base their preparations on Czech legislation, the regime of obligations that applies to them, and the actual scope of the regulated service they provide.
For company management, one question is particularly important: can we demonstrate that we understand our main cybersecurity risks and manage them appropriately?
Having antivirus software, backups, and several security policies is not enough. The measures must reflect actual operations and continue to work when an administrator leaves, a supplier fails, or an attack affects an important business application.
Contents
Does NIS2 Apply to Your Company?
Why Cybersecurity Is No Longer Solely the Responsibility of IT
What the Obligations Look Like in Practice
Practical Examples of Problems That Documentation Alone Cannot Solve
What a Company Must Complete After Registration
Recommended Approach During the First 90 Days
The Most Common Mistakes When Preparing for NIS2
Penalties Are Not the Only Business Risk
When a Technical Audit Makes Sense
How GoveSoft Can Help
Does NIS2 Apply to Your Company?
The first step is not purchasing a security tool or ordering a penetration test. The company must first determine whether it provides any regulated services and which regime of obligations applies to it.
The assessment is usually based on three areas:
- The service the company actually provides.
- Whether it meets the significance criteria, most commonly based on company size.
- Whether it falls under the lower-obligation or higher-obligation regime.
The regulation applies, for example, to selected organisations in energy, transport, healthcare, manufacturing, digital infrastructure, waste management, food production, research, and other sectors.
However, simply belonging to a particular industry does not necessarily provide a clear answer. The deciding factors are the specific regulated service and the conditions set out in the relevant decree. NÚKIB provides an official calculator for an initial assessment.
Example: A Manufacturing Company
An engineering company has 120 employees and manufactures specialised industrial equipment. Management originally assumes that NIS2 only applies to the energy sector, banks, and hospitals.
However, selected manufacturing activities are among the regulated services covered by the Czech legislation. The company must therefore verify its exact classification, size, and the conditions applicable to its specific service. If it meets the relevant criteria, it may fall under the lower-obligation regime.
This also means that the scope extends beyond office IT. Its manufacturing depends on ERP, production planning, shared technical data, remote access for service companies, and sometimes communication with manufacturing equipment.
The scope therefore cannot be determined solely from a list of servers.
Consider the Size of the Entire Group
A common mistake is to assess only the number of employees or turnover of one Czech company. Partner and linked enterprises may also be relevant when determining company size.
For example, a Czech company may have only 35 employees. However, if it belongs to a group with several hundred employees, it may not be considered a small enterprise for regulatory purposes.
Assessing relationships within the corporate group should therefore be one of the first steps, rather than a legal detail addressed at the end of the project.
If a company meets the relevant conditions at a later date, it must notify NÚKIB of the regulated service within 60 days. Providers that met the conditions when the Act took effect had the same 60-day notification period starting on 1 November 2025.
Why Cybersecurity Is No Longer Solely the Responsibility of IT
A technical department can manage servers, updates, backups, and monitoring. However, it cannot decide on its own:
- which services are most important to the company,
- how long an outage the business can accept,
- what budget should be allocated to reducing risks,
- which supplier relationships must be changed,
- who is authorised to make decisions during a serious incident,
- or which business risks the company is prepared to accept.
These are management decisions.
Under the lower-obligation regime, senior management must, among other things, appoint a person responsible for cybersecurity, complete the required training, provide the necessary personnel, financial, and technical resources, and monitor the implementation of security measures.
The higher-obligation regime includes a more formal system of security roles, governance, and controls.
In practical terms, a managing director or board cannot discharge its responsibility by saying: “Our external IT technician is responsible for it.”
An external supplier may implement security measures, but management must understand what it has commissioned, why the work is necessary, and how the results will be evaluated.
What the Obligations Look Like in Practice
NIS2 is not a list of specific products that a company must purchase. It requires risk management and proportionate organisational and technical measures.
The exact measures will therefore differ depending on the size of the company, the service it provides, the systems it uses, and the potential impact of an outage.
| Area | Question for Management | Practical Implementation |
|---|---|---|
| Scope and assets | Which systems are essential to the regulated service? | An inventory of applications, servers, databases, integrations, devices, data, and responsible persons |
| Access rights | Who has administrative or remote access? | Named accounts, multi-factor authentication, regular permission reviews, and removal of invalid access |
| Backups and continuity | How quickly can we restore operations? | Segregated backups, a defined recovery sequence, and regular restoration testing |
| Updates and vulnerabilities | Who monitors vulnerabilities in the systems we use? | Version records, an update process, defined deadlines, and assigned responsibility |
| Monitoring and logging | How quickly will we know that something is happening? | Centralised logs, alerts, operational monitoring, and a defined evaluation process |
| Suppliers | How quickly must a supplier report an incident to us? | Security requirements in contracts, contact persons, notification deadlines, and remote access rules |
| Incident response | Who makes decisions at night or during the weekend? | An incident response plan, on-call contacts, an escalation matrix, and prepared communication procedures |
| Employees | Can employees recognise a suspicious situation? | Regular training, a simple reporting method, and practical testing |
The number of documents created is not the most important factor. What matters is whether the documented process reflects reality.
Practical Examples of Problems That Documentation Alone Cannot Solve
1. The Company Creates Backups but Cannot Restore Operations
A manufacturing company backs up its ERP database every day. Its security documentation therefore states that backups have been implemented.
During a ransomware attack, however, the company discovers that the backup server uses the same login credentials as the production environment. The attacker encrypts the backups as well.
An older copy exists, but nobody has tested its restoration for several years, and the current application configuration is missing.
Formally, the company performed backups. Operationally, it had no functioning recovery process.
The correct question for management is therefore not: “Do we have backups?”
A better question is: “When did we last restore the entire critical system, and how long did the restoration take?”
2. A Supplier Has Access, but the Contract Does Not Address Incidents
An external company manages the ERP system and connects remotely to the corporate network. The contract specifies the support price and response time during an outage, but it does not address account security, access records, or the obligation to report a security incident.
The supplier’s login credentials are compromised on Friday evening. The customer does not learn about the problem until Monday because neither the contract nor the operating procedure specifies who must be notified or how quickly.
Responsibility for the company’s own regulated service does not transfer to the supplier.
The company must incorporate security requirements into its contracts and ensure that it is informed about incidents in time.
3. A Former Employee Still Has Active Access
A maintenance manager leaves the company. The HR department terminates the employment relationship, but the information does not reach the administrator of an external service portal.
The account remains active for another six months. It provides access to technical documentation, equipment data, and remote management functions.
The problem was not caused by a weak password. It arose because the company had not connected its employee onboarding, role-change, and offboarding processes with access-right management.
4. An Incident Begins on Saturday Morning
Monitoring detects unusual data transfers at 6:30 on Saturday morning. The automated notification is sent only to an administrator who is on holiday. Management does not learn about the problem until Monday morning.
For reportable cybersecurity incidents, the provider must submit an initial report without undue delay and no later than 24 hours after identifying the incident. If the incident has a significant impact, an updated notification must follow within 72 hours.
The initial notification does not have to contain a complete forensic analysis. However, the company must be able to recognise the incident, assess it, and escalate it to the responsible person.
Without on-call contacts and a clear decision-making process, the 24-hour deadline is extremely short.
What a Company Must Complete After Registration
Within 30 days of receiving the registration decision, the provider must report the required contact details and supplementary information to NÚKIB.
The provider must begin complying with the required security measures no later than one year after receiving the registration decision. The same one-year period applies to the commencement of mandatory incident reporting.
One year may appear to be a long time. However, in a company with multiple sites, an older ERP system, manufacturing equipment, and several external administrators, it can quickly be consumed by:
- defining the scope,
- mapping systems and data,
- amending contracts,
- appointing responsible persons,
- addressing the most serious deficiencies,
- implementing monitoring,
- testing backups,
- modifying applications,
- training employees,
- and establishing a usable incident-response process.
Some deficiencies can be addressed within a few days. However, changing the authentication process in a legacy application, separating networks, or adding audit logs may require changes to the system and several months of work.
Recommended Approach During the First 90 Days
1. Verify the Scope and Applicable Regime
Use the NÚKIB calculator and assess the specific regulated service, company size, and relationships within the corporate group.
Where the classification is unclear, involve a lawyer or regulatory specialist.
The output should be a documented decision explaining why the company is or is not subject to the regulation.
2. Assign Responsibility
Appoint a person to coordinate the preparation process.
This person must have access to management, sufficient authority, and the ability to obtain information from IT, HR, operations, procurement, and suppliers.
Simply appointing someone without providing time and a budget will not solve the problem.
3. Describe the Regulated Service and Its Dependencies
Start with the service, not the hardware.
Determine:
- what the company must provide to customers or the public,
- which processes deliver the service,
- which applications and data those processes depend on,
- who manages the systems,
- which suppliers have access to them,
- and what will happen if they become unavailable.
The output should be a clear map of the service and its technical dependencies.
4. Analyse the Actual Situation
Compare the required measures with the company’s real operations. Checking whether policies exist is not enough.
For example, verify:
- whether administrator accounts are assigned to named individuals,
- whether systems can actually be restored from backups,
- whether important applications are supported and up to date,
- whether monitoring alerts the correct people,
- whether security logs are available,
- whether suppliers follow the remote-access rules,
- and whether the company knows about all its publicly accessible services.
5. Address the Most Serious Risks
Some measures do not need to wait until the entire analysis has been completed.
Typical quick measures include:
- enabling multi-factor authentication,
- removing invalid accounts,
- separating backups from the production environment,
- updating publicly accessible systems,
- limiting shared administrator accounts,
- adding on-call contacts,
- and reviewing suppliers’ remote access.
6. Prepare a Prioritised Plan and Budget
Each finding should include:
- a description of the impact,
- a priority,
- a responsible person,
- a proposed solution,
- an estimated cost,
- and a target deadline.
A list of 50 deficiencies without any ranking will not help management.
The company needs to know which three problems could stop operations and which changes can be safely scheduled for a later period.
7. Test an Incident Scenario
Prepare a simulated situation. For example:
At 8:00 on Saturday morning, monitoring detects a suspicious administrator login and a bulk export of customer data. The system administrator is unavailable. The external supplier has not yet confirmed whether its account has also been compromised.
During the exercise, verify:
- who takes ownership of the situation,
- who is authorised to shut down the system,
- who contacts the supplier,
- who assesses the reporting obligation,
- who informs management,
- where the necessary contact details are stored,
- and whether the required logs are available.
An exercise of this kind often reveals more than another general security policy.
The Most Common Mistakes When Preparing for NIS2
Purchasing a Tool Before Defining the Problem
The company purchases a new firewall, SIEM platform, or managed security service, but still does not know which services and systems are critical.
The result may be additional licences and alerts that nobody knows how to evaluate.
Technology should address a specific risk. It should not replace analysis.
Documentation Does Not Reflect Actual Operations
A policy states that access for former employees must be removed immediately.
In practice, however, HR does not send the administrator a list of departing employees, and some external accounts do not have an identified owner.
During an inspection or incident, the actual situation will matter more than the wording of the document.
The Project Remains Confined to IT
IT can describe the infrastructure, but it may not know the company’s contractual obligations, business priorities, or acceptable outage durations.
Management, operations, procurement, HR, legal advisers, and the owners of important services must therefore also participate in the project.
The Company Reviews the Network but Overlooks Its Applications
A serious risk does not have to exist only on a poorly protected server. It may be located directly in a business application:
- users have excessively broad permissions,
- sensitive operations are not logged,
- the application uses unsupported libraries,
- passwords or access keys are stored in configuration files,
- only one developer can deploy an update,
- or a compromised account cannot be blocked quickly.
Without reviewing applications, databases, and integrations, a security assessment may overlook the systems on which the company actually depends.
Preparation Ends Once the Deadline Has Been Met
Cybersecurity is not a one-off project.
Every new integration, cloud service, application, or change of supplier also changes the company’s risks.
The company must therefore regularly review and update its asset inventory, access rights, and security measures.
Penalties Are Not the Only Business Risk
Under the higher-obligation regime, fines for specified serious offences may reach CZK 250 million or 2% of the net worldwide annual turnover of the undertaking to which the offender belongs for the preceding financial year, whichever amount is higher.
Under the lower-obligation regime, fines for specified serious offences may reach CZK 175 million or 1.4% of that net worldwide annual turnover, whichever amount is higher.
These are maximum limits. The specific amount is determined by NÚKIB through administrative proceedings.
For most companies, however, the fine itself will not be the greatest risk. More serious consequences may include:
- a production shutdown,
- services becoming unavailable to customers,
- loss or corruption of data,
- expensive recovery of operations,
- contractual penalties,
- loss of trust among business partners,
- or an inability to demonstrate what actually happened during the incident.
Proper preparation for NIS2 should therefore not serve the regulator alone.
It should reduce the likelihood that one compromised account, a non-functioning backup, or a supplier’s mistake will bring the entire company to a halt. Several of these operational weaknesses also appear among the seven signs that business software is holding back company growth.
When a Technical Audit Makes Sense
A Technical Audit of a Business Application is appropriate when a company understands the legal requirements but does not know the actual state of its applications and infrastructure.
An audit focused on technical readiness should examine in particular:
- the architecture of important applications,
- user and administrator permissions,
- authentication and access management,
- the libraries and software versions in use,
- the storage of passwords, certificates, and keys,
- databases and sensitive data,
- logging of important operations,
- monitoring and alerts,
- backup and recovery,
- the deployment process,
- connections to other systems,
- and suppliers’ remote access.
The output should not be merely a technical list of vulnerabilities.
Management needs to understand the business impact, priority, recommended solution, and estimated effort required.
A technical audit does not replace a legal assessment of whether the Act applies to a particular company or service.
However, it can show whether the company’s systems are genuinely prepared for the required security-management processes, incident response, and restoration of operations.
A more detailed process is described in the article Technical audit of the company application: when it pays off and what it must contain.
How GoveSoft Can Help
GoveSoft focuses on the technical aspects of preparation: business applications, databases, integrations, infrastructure, access rights, monitoring, backups, and the deployment process.
We examine the actual state of the system and distinguish formal deficiencies from risks that may directly affect operations.
We rank the findings by urgency and recommend what can be fixed quickly, what requires a process change, and which parts of the system need to be modernised.
We do not automatically begin by proposing the complete replacement of an application or the purchase of another security product.
The first objective is to determine:
- Which systems are genuinely important to the service being provided.
- Which technical risks the company is currently unable to control.
- Which measures will deliver the greatest reduction in risk.
- How the implementation can be divided into manageable phases.
If you need to verify the technical readiness of your business applications and infrastructure for the requirements of the new Cybersecurity Act, begin with a technical consultation.
The outcome should be a specific plan covering measures, responsibilities, and priorities—not another general presentation about NIS2.
This article provides a general technical and operational overview and does not replace a legal assessment of a specific regulated service or the applicable regime of obligations.
Verify the scope of the law in the official NÚKIB calculator.