When an organization starts looking more closely at how ready it really is for NIS2, the initial picture often looks quite good. There is a firewall, backups run regularly, MFA is enabled, employees receive security training, and everyone knows who to call if an incident occurs. Most of these measures were not introduced because of NIS2. They became part of normal operations over the years, and that is a good starting point.

The problem appears when the question changes from “do you have it?” to “how is it actually implemented?”. NIS2 does not reduce cybersecurity risk management to owning certain security products or having a few written procedures. It covers areas such as incident handling, business continuity and recovery, supply chain security, vulnerability management, access control, training, and assessment of the effectiveness of security measures. Two organizations may therefore tick almost every box on a basic checklist while having very different levels of readiness in practice.

Take MFA as an example. A company uses it for Microsoft 365 and VPN access, so it can quite reasonably say that multi-factor authentication is in place. But what about administrative accounts? Are there legacy systems that do not support it? Are there exceptions, and is it clear why they exist? If a compromised administrative account can still provide access to an important part of the infrastructure without an additional verification step, simply saying that the organization “has MFA” does not tell us enough about the actual risk.

Something similar happens with vulnerabilities. An organization may run a vulnerability scanner every month and keep the resulting reports. What matters much more is what happens afterwards. If the same serious finding appears for six months because nobody has assigned an owner, deadline, or remediation path, scanning exists, but the vulnerability management process clearly has a gap. Sometimes an issue cannot be fixed immediately, and that is a reality in any IT environment. In that case, the organization should understand the remaining risk, whether it can be reduced temporarily, and who made the decision to accept it.

Suppliers are another area where the real situation can easily become unclear. An organization knows who maintains its infrastructure, where its systems are hosted, and which cloud or SaaS services it uses, but that does not necessarily mean it has a good overview of supplier access and the dependencies that have developed over time. An external IT provider may have administrative accounts, an application vendor may have remote access to production, and a business-critical system may depend on a service outside the organization’s direct control. If that supplier suffers a security incident, the question is no longer only how secure the supplier is, but what their incident could mean for your own operations.

With incidents, the difference between assumed and actual readiness usually becomes visible even faster. In a smaller organization, everyone may know who to call when something goes wrong. That can work perfectly well for minor problems. During a serious incident, however, someone suddenly has to decide what to isolate, which systems need to remain available, what information must be preserved, who leads the technical response, who communicates with management, and whether the incident needs to be reported. If everything depends on one person who “knows how things work”, the plan effectively exists only while that person is available.

A backup alone does not tell you how prepared the organization is for recovery either. It may run every night for months without an error while nobody knows how long an actual recovery would take. The database may be recoverable, but the application could depend on another service that was never included in the plan. All the data may be available, but nobody has decided what needs to be restored first. Only when these questions are tested can an organization start talking about actual recovery capability rather than simply having backups.

This is why evidence in NIS2 readiness is useful for more than a future review or self-assessment. It gives the organization a much more practical answer to whether its security measures work as expected. A recovery test result tells you more than simply stating that backups exist. Records of privileged account reviews show that access is actually being reviewed. Closed vulnerability findings show that scanning leads to remediation rather than a PDF report being stored in a folder. There is no need to invent new NIS2 documentation if the appropriate evidence already exists as part of everyday operations.

The Croatian NIS2 framework also distinguishes between the documentation of security measures and their actual implementation. This matters because an organization may have a well-written procedure that nobody follows in practice, while the opposite can also be true. A security practice may have worked well for years but remain insufficiently formalized or documented. A GAP assessment should distinguish between these situations rather than treating all of them as the same “missing” requirement.

With an AresISEC NIS2 GAP Readiness Assessment, we therefore do not look only at whether a particular policy, procedure, or security technology exists. We examine how the measure is actually implemented and what can be confirmed from the available information and evidence. The objective is not to issue a certificate or provide a legal opinion that an organization is “NIS2 compliant”, but to establish a realistic picture of the current state and identify where there is a difference between what the organization considers resolved and what is actually in place.

It makes sense to perform this type of review before a formal self-assessment or another review, while there is still time to address the gaps that are found. The result does not have to be ten new policies and another security product. Sometimes an existing process needs to be improved, a technical weakness needs to be addressed, responsibility needs to be clearly assigned, or something that has been taken for granted for years finally needs to be tested.

That is why NIS2 preparation is more useful when it starts with the actual environment rather than a checklist. The question is not only whether you have a particular security measure. The question is whether you can show how it is implemented and whether it works when you actually need it.

Sources:

European Union – Directive (EU) 2022/2555 (NIS2 Directive)

Narodne novine – Croatian Cybersecurity Act, NN 14/2024

Narodne novine – Croatian Cybersecurity Regulation, NN 135/2024