The Era of Accountability: Why NIS2 Is the New GDPR for Cybersecurity

If you are a business leader operating in or with the European Union, the “grace period” mentalities of the past decade are officially over. By now, the Network and Information Security 2 (NIS2) Directive is no longer just a piece of paper in Brussels; it is active national law across member states.

Much like the GDPR revolutionized data privacy in 2018, NIS2 has fundamentally reshaped the corporate responsibility landscape for cybersecurity. But unlike previous regulations that focused heavily on IT departments, NIS2 has walked straight into the boardroom.

If you are still asking “Does this apply to me?” or “Can we delay this?”, you are likely already exposed. And you definitely don’t want to be exposed, otherwise you could face a fine of up to CZK 250,000,000 or 2% of the company’s worldwide turnover.

In the Czech Republic, we are talking about Act No. 264/2025 Coll., on Cybersecurity (AoC), which entered into effect in November (on 1 November 2025). In this article, we will briefly introduce the Act and compare some of its selected aspects by contrasting them with the long-established PCI DSS standard, which deals with the protection of cardholder data.

Key aspects of the regulation

The AoC defines the cybersecurity framework for a selected group of companies that have a fundamental influence on the operation of society and where an outage or disruption of the provided services could threaten the operation of society and the safety of the population.

Where the predecessor of the AoC, Act No. 181/2014 Coll., on Cybersecurity, targeted a few selected sectors, the AoC goes much further and significantly expands the list of sectors:

1. public administration,
2. energy,
3. manufacturing industry,
4. food industry,
5. chemical industry,
6. water management,
7. waste management,
8. transport,
9. digital infrastructure and services,
10. financial market,
11. healthcare,
12. science, research, and education,
13. postal and courier services,
14. defense industry,
15. space industry

In addition to the above classification of the field of business, the size of the company according to the number of employees and the company’s turnover (or balance sheet) also co

mes into play.

If you are still wondering whether you are a mandatory company, check out the official “calculator” which will calculate which category you fall into, and whether you fall under the AoC at all. The calculator was created by the National Cyber and Information Security Agency (NÚKIB), which was entrusted with the entire agenda related to the AoC, and acts as a registrar, controller, and collector of security incidents, as described below.

According to the size of the company, the AoC divides mandatory companies into companies with

• higher obligation and
• lower obligation.

This division determines the strictness of the applied measures; the overall framework remains practically the same.

The timeline for implementing the AoC starts with the registration of mandatory companies and subsequently allows a one-year period for the (re)implementation of all required measures.

The implementation of the AoC into corporate practice should look something like this:

1. Formal notification of the provided service to the NÚKIB, self-assessment, and registration in the NÚKIB registry. Submission of contact details for the company’s responsible bodies.
2. Start of AoC implementation in the company – development and approval of the security policy, risk management policy, implementation of an asset register, creation of a training and security awareness plan, preparation of a budget for the implementation of measures, proposal of a compliance verification method, review of supplier contractual relationships, and incorporation of AoC requirements into supplier contracts.
3. Creation of an implementation plan for technical measures to protect individual assets (the annexes to the implementing decree will help with this).
4. Introduction of technical measures and continuous control of compliance – encryption, training, implementation of technical measures for identity management, access, authentication mechanisms, and other security tools, performing penetration tests, etc.
5. Reporting security incidents according to AoC requirements.
6. Monitoring and evaluating the so-called Countermeasures issued by NÚKIB for individual threats.

Remember the sanctions for non-compliance with legislative requirements are huge!

• CZK 250,000,000 or 2% of net worldwide turnover for higher obligations, and
• CZK 175,000,000 or 1.4% of net worldwide turnover for lower obligations. 
• disciplinary fines that can be imposed continuously up to CZK 100,000 (even repeatedly)
• in case of non-compliance or non-cooperation, NÚKIB may impose a fine of up to CZK 10,000,000, or temporarily suspend the performance of the company’s statutory representative or suspend the company’s registration and certification.

A comparison with the PCI-DSS regulation

Let’s now look at some selected aspects of the AoC. For the analysis, we will use a parallel with the PCI DSS standard (Payment Card Industry Data Security Standard). PCI DSS is a mandatory security standard, which we wrote about in the last article and which deals with the protection of cardholder data. The goal of the PCI DSS standard is to ensure a minimum secure level for companies that transmit, store, or process cardholder data.

Where PCI DSS clearly defines the scope of compliance (the “scope”), with the AoC, it is up to each registered organization how it works with the concept of an asset. Companies that have not yet worked with this concept may initially have some difficulties in grasping it, and the devil may be in the detail:

Paragraph § 12 Determination of the scope of cybersecurity management states that:

Assets related to the provision of a regulated service are part of the scope of cybersecurity management (hereinafter referred to as “determined scope”). For the purpose of defining the determined scope, the provider of the regulated service

1. a) determines all its primary assets, 
2. b) assesses whether the primary assets are related to the provision of a regulated service, and 
3. c) determines supporting assets for the primary assets according to letter b).

The concept of supporting assets can be very tricky. For example, in the PCI DSS standard, this is a key requirement that causes headaches for all architects and IT managers in companies where the PCI DSS standard had to be implemented, because it de facto involves creating a dedicated “IT within IT.”

The rules for managing IT that is in scope of the PCI DSS standard are so strict that it is usually necessary to build a completely separated and dedicated environment that is used only and exclusively to provide services related to payment cards. This is also the moment when the costs for implementing the PCI DSS standard skyrocket.

If a similar spirit is maintained within the AoC, the implementation of the AoC may be significantly costly, because the entire IT infrastructure of the mandatory company will have to meet the AoC requirements through such defined supporting assets.

NÚKIB’s approach relies on a ‘top-down’ methodology, meaning the organization itself determines its primary and supporting assets. This method allows for drawing an administrative boundary that can be very creative and, from the perspective of security assurance, potentially inadequate

This primarily concerns various supporting systems such as Active Directory, remote access tools, disk arrays, backup systems, databases, cloud, etc., which can affect the security of the so-called primary assets and which must be secured according to the AoC. 

The second interesting aspect of the AoC is security management based on risk analysis. This is a clearly important step in the entire AoC implementation. Unfortunately, NÚKIB does not provide any methodological framework or recommended models for this. Implemented measures must correspond to the level of risk of a security incident’s impact. Risk is usually calculated as impact (damage) x probability. 

Another significant obligation of regulated organizations is the reporting of security incidents. The AoC methodology distinguishes between a security incident and a security event. An incident has an impact on the security, integrity, and availability of an asset. An event does not. According to the example given in the methodological material, an event seems to be a state where the risk “did not materialize.” 

The timeline for security incident management then looks like this:

The organization is obliged to record the security incident in the NÚKIB portal. NÚKIB will assess the incident, register it, and can provide methodological assistance in processing the incident.

Critical View on the AoC

The entire proposed architecture of the AoC is only half-set up. It lacks the completion of the entire ecosystem and the definition of rules for publishing registrations, records of mandatory companies, their AoC status, the number and impact of security incidents, etc.

The AoC sets the required level of security through technical measures. However, it leaves their implementation purely up to the organization and cannot systematically verify that the measures are implemented correctly to meet the objectives of the measures. And this may not always be related to negligence or intent; there may be cases where the organization does not have sufficiently qualified human capital. There is no set process to assess and verify the correctness of AoC implementation in the given organization.

The AoC is thus on the best path to becoming another legislative requirement that needs to be fulfilled “on paper” without deeper understanding, which can easily lead to the creation of generic documentation, the installation of a product that claims to be “AoC ready,” and that’s where the entire cybersecurity effort ends.

Given the number of mandatory companies (up to several thousand is mentioned), this is a fairly predictable scenario. For this conclusion, we can borrow a parallel with the obligation for companies to publish their financial statements. According to research by the Czech Credit Bureau (link), approximately 50% do not comply with this obligation because there is no systemic framework for checking the publication of financial statements. Although there is an institution for control, with all possible fines, it is currently not used in practice.

The PCI DSS standard is where the AoC can find inspiration. It responded to this situation by having the parent organization PCI SSC (Standards Security Council) create a system of accredited auditors who are authorized to carry out compliance checks with the requirements of the PCI DSS standard.

Every auditor must undergo initial training and subsequently retrain and update their education in the field annually. Such a trained auditor is authorized to carry out so-called onsite checks at risky (=largest) entities that process, transmit, or store cardholder data.

If the organization successfully passes the audit, it is included in the list of trusted service providers along with information on when the audit took place and the current validity of the certification. It is thus easy to monitor the status of considered service providers, for example, for tenders.

The AoC does not account for any of this, and yet it would be significantly simpler and more transparent to have the capability to address the security of supply chains in this way, whether for tenders or managing a part of the supply chain security.

Further room for improvement can also be found in the reporting of security events and incidents. Although NÚKIB requires security incidents to be reported, the effort ends there, and there is no further exploitation of the reported data.

For example, from the November incident report (https://nukib.gov.cz/download/publikace/vyzkum/Kyberneticke-incidenty-pohledem-NUKIB-listopad-2025.pdf), we can learn that there were 3 significant incidents in state administration entities in November, and unfortunately, all information ends there:

Monthly Summary 

In November, the number of registered cybersecurity incidents decreased to below-average values. However, the severity slightly increased – out of a total of 15 incidents, NÚKIB classified 3 as significant. 

These were formed by successful intrusions within the state sector. As for the classification of incidents, three categories dominated: Availability, Intrusion, and Information Security. In the Availability category, outages mostly prevailed, with NÚKIB not registering any DDoS attacks. Hacktivist group activities, from the perspective of registered incidents, remained minimal for the second month in a row. 

Conversely, 4 successful ransomware attacks represent a slight increase compared to previous months. Ransomware such as Warlock or INC Ransom were recorded, for example. Within intrusions, compromises of VPNs, administrator accounts, or email boxes were registered. Beyond those already mentioned above, NÚKIB registered one case of malicious code in a healthcare entity. 

During November, NÚKIB also registered a below-average number of cyber events consisting of suspicious communication, attempted compromise, or unsuccessful DDoS attacks.

The availability of security incident information is crucial for developing security awareness, not as a critique of state administration, but primarily to enable the quantification of incident impacts, which is a critical input into the risk analysis that security should primarily be governed by.

While one approach is to conduct a theoretical risk analysis, it is far more valuable to document the real impacts and costs of incident management, perhaps in an organization of similar size. A risk analysis based on real data constructed in this way might shed a different light on the business case for implementing security measures.

Many risk analysis methods employ impractically broad damage ranges or vague verbal assessments such as high, medium, and low risk impact. The more precisely you determine the size of the impact, the better the business case for implementing measures or accepting risk will be calculated.

Unfortunately, data on impacts and damages are not published, so inputs for refining risk analysis are missing. For example, from publicly available information, it can be read that the ransomware attack on the Benešov hospital at the end of 2019 was quantified by the hospital at CZK 59 million for limiting medical procedures, canceling planned examinations, surgeries, production, and restoration costs over a period of about 3 weeks. This information is missing for other successful attacks, even though NÚKIB participated in managing the incidents.

The introduction of security measures and the building of a secure organization is financially very demanding. The cost and investment side is represented by security tools, human resources, processes, licenses, reduced user-friendliness, etc. The benefit side then includes items such as the company’s reputation and goodwill, the elimination of fines for security incidents or non-compliance with regulations and legislation, etc.

In times of strained budgets, it would be interesting to support increased security by supplementing the benefit side with possible benefits such as the “trusted company title,” which is recorded in the NÚKIB registry, regularly fulfills all measures, has not reported a security incident in the last year, and checks its status, and as such can apply for public tenders.

At the same time, it would also be interesting to find out which of the required security measures was not complied with or correctly implemented, or was bypassed by the attacker, and whether the entire architecture of security measures is current and complete.

The last area to address is the concurrency of AoC requirements with other standards in the field of security management and their coordination so that they do not bring redundant costs and bureaucracy to mandatory companies. This refers, for example, to the concurrency of compliance with PCI DSS standards for companies providing services in the areas of finance and payment services, banks being subject to regulation by the Czech National Bank (ČNB), etc. Moreover, many companies have already implemented some type of security standard, such as ISO 27001, or military certifications, etc. Similarly, the reporting of incidents associated with, for example, GDPR regulation, etc., may be duplicated. Increasing the bureaucratic burden in such complex situations will only complicate the successful management of a security incident.

How can NEXT Studio help?

The company NEXT Studio and its consultants have worked on a number of projects where it was necessary to meet regulatory and legislative requirements in a wide range of areas. We are ready to provide our know-how and our cooperation and guidance in managing these requirements in your company as well.

We will oversee the quality of outputs, the financial side of the project, communication with the regulator, or manage the project. We can prepare materials for management decisions on further action or test the implementation of technical measures. We are helping companies  develop security policies, incident handling procedures and communication and negotiation with suppliers.