NIS2: What is it and how should you prepare for it?

In case the scope assessment’s result is in the affirmative, that means that the measures set out by the Directive apply for the given business or organisation. There are additional factors to be taken into account, such as Member State’s ability to excuse certain businesses or agencies operating for instance in the national security field. Overall, however, the assessment will give a firm implication whether the regulated security measures need to be implemented.

Next, as mentioned, there is an emphasis on supply chain related matters in the Directive, particularly on ICT supply chains and supplier relationships. This means that businesses originally falling outside of the scope of the instrument could potentially become obliged to follow its measures due to their ICT supply chain connections. The exact measures required are not yet known, as the directive merely instructs Member States to enact policies to ensure the cybersecurity of ICT supply chains.

Another, more specific new requirement laid down by NIS2 relates to management bodies. Every organisation that falls under the scope of NIS2 is required to have their management to approve risk management measures and oversee their implementation. Under Article 20 of the Directive, the approving managing body can also be held liable for potential infringements. To prevent this, members of management bodies are required to undergo risk management and cybersecurity training. Additionally, Hunt & Hackett’s Security Program Gap Assessment (SPGA) may prove useful when navigating risk management. In our SPGA approach, which has now been tailored to the new NIS2 requirements, we use the threat landscape as the basis for defining security controls to control risks to an acceptable level.

While this aspect of the new directive has not attracted much attention or debate so far, the relative unclarity of the wording of Article 20 is important to point out. The term “management body” is usually meant as an umbrella term referring to the overall governing and decision making functions within a firm. Whether NIS2 requires all employees with potential decision making authority to follow trainings, or a specific NIS2 compliance body should be appointed, needs clarification.

The last upcoming changes putting additional obligations on companies and organisations relate to their incident reporting requirements. Article 23 of the Directive lays down these requirements, although in a rather vague manner. According to the provision, all entities falling under the scope of NIS2 and experiencing a significant incident will have to notify the national computer security incident response team (CSIRT) or other competent national authorities without undue delay, as well as the potentially affected recipients of their services. In practice, notification to the national authorities will be required to have a three step procedure. First, within 24 hours of becoming aware of a significant incident, an initial report has to be filed. This report needs to indicate whether the incident is suspected to have been caused by a malicious actor, and whether it has any potential cross-border impact. Within 72 hours of the incident, a follow-up report needs to be submitted with any updates, detailing the incident’s severity, impact, and any compromise. A final report needs to be submitted within one month of the incident, including “(i) a detailed description of the incident, including its severity and impact; (ii) the type of threat or root cause that is likely to have triggered the incident; (iii) applied and ongoing mitigation measures; (iv) where applicable, the cross-border impact of the incident.” Depending on how much detail authorities will require in practice, one month to prepare a thorough incident report of a serious security incident is extremely short.

In order to restrict the volume of reports inevitably streamlined towards national CSIRTs due to the expansion of the directive’s scope, NIS2 requires only significant incidents to be reported. An incident can be considered significant if it has or is capable of causing severe operational disruption or financial loss, or if it has or is capable of affecting other persons or entities by causing either material or non-material damage. While this definition seems detailed at first glance, it soon becomes obvious that incidents falling under its scope are not only what would colloquially be considered significant. For instance, a strict interpretation of the text would suggest that any financial loss needs to be reported, with no minimum amount of damage. “Severe disruption” is highly subjective and leaves a lot of discretion to the decision maker. Lastly, even a single phishing email would be “capable of affecting (…) persons by causing considerable (…) damage.” How these requirements will be implemented and enforced, remains to be seen.

The list of changes brought by NIS2 and detailed above is not exhaustive, and some additional developments lay down requirements directly to the Member States to implement rather than companies and organisations. The most noteworthy changes are states’ obligation to supervise cybersecurity measures in the essential and important sectors, enhanced focus on enforcement, cross-border cooperation, and information sharing between states. It is therefore predicted that, unlike its predecessor, NIS2 will, in fact, have a meaningful effect on European safety and cybersecurity.

Regardless of the risk assessment, however, some actionable steps can already be taken in preparation for the incoming legislation. For instance, it is worth setting up internal managerial groups specifically focused on compliance, and start exploring cybersecurity training options available on the market. In case a cybersecurity incident is detected in the company’s or organisation’s network, rigorous reporting obligations will need to be met, and therefore arranging an internal system for reporting is advisable. It is important to keep in mind, however, that both the sector- and business-specific risk assessment from a cybersecurity perspective, and incident reporting are complex tasks requiring a high level of expertise, which is why it is highly recommended that entities falling under the scope of NIS2 but without an advanced security department look for cooperation with external cybersecurity experts.

Multiple factor authentication has been a popular way to protect networks on the user’s side. Banks, for instance, require confirmation on our banking apps when making significant transactions, Gmail often instructs users to confirm their identity on a different device when logging in from an unknown IP address, and logging into our personal Dutch governmental accounts is only possible with SMS- or app-confirmation. Lately, more and more universities are opting for this procedure as well. The tendency is clear, but there is still a long way to go before ideal security is achieved.

On the more technical side, there is also criticism to be found regarding the content of the NIS2 Directive. For instance, the timeline for reporting obligations may be too short. The first report after the incident needs to be submitted within 24 hours of its discovery. This would require organizations to have Incident Response (IR) retainers in place in order to have an initial investigation performed in such a short time frame, unless the organisation has an in-house CSIRT team. NIS2 also requires a final report to be submitted no later than one month after the discovery of the incident. However, major incidents often require months of forensic analysis and investigation. Therefore, the report after one month would most likely be non-complete and lacking useful insight. Moreover, requiring three different reports within a one month period regarding the same incident could place an undue burden on companies trying to focus on resolving the issue itself. In other words, NIS2 brings stringent requirements to the logging of data sources (the industry norm is selective rather than exhaustive due to the associated costs), the forensic capabilities of active security monitoring (such as with Managed Detection Response (MDR) or in-house SOCs) and Incident Response labs in order to significantly reduce processing time. This, of course, is not the case for the majority of organisations outside of the security sector and would imply a significant overhaul of the security architecture.

In general, these time frames are only realistic when extensive logging and active monitoring with forensic analysis capabilities are in place. This links to Hunt & Hackett’s IR readiness assessments that looks into both the technical and organizational aspect. Without such preparation, it is close to impossible for organizations to meet the required timelines as typically there is no data to answer these questions. The requirements will also affect MDR solutions; it is desirable to have a solution that ingests significant logs and is not selective, since it is not known what data is needed for forensics and is designed from a forensic analysis perspective. This, however, goes against the current market trend which is very selective on data ingestion due to volume based pricing, and it often correlates alerts and not underlying logging data. Consequently, this will hamper follow-up forensic analysis from the SOC.