NIS2 is Coming – How Should You Handle the New Incident Reporting Obligations?

October is rapidly approaching, and that means new cybersecurity regulations known as NIS2 are set to be enacted by European Union (EU) member states. States are required to publish their local version of the NIS2 Directive into law by the 17th of October. Whilst many countries are well on track, however, some have already acknowledged they will not meet the deadline. This delay leaves organisations somewhat in the dark as to what they will need to comply with and by when. 

Notwithstanding delays in the implementation of local legislation, the NIS2 directive provides an indication of the compliance obligations affecting those organisations which fall within the scope of the new rules.  

It is important to recognise that any organisation doing business in the EU will need to comply with the new regulations, even if they are headquartered outside the bloc. 

How should you start getting ready? 

I’ve held several webinars exploring the ways in which in-scope organisations can prepare for publication of the new measures, by using the coming weeks and months to review their incident response maturity. During these webinars, several recurring themes keep popping up from attendees within the Q&A, so I’ve decided to zoom into these areas over a succession of blogs. 

Incident Reporting Requirements 

To start, I’m going to look at the incident handling and reporting obligations set out within the directive. If we compare the requirements of NIS2 with other legislation such as GDPR, we see some clear similarities, as well as some important — and potentially tricky — differences. For example, what does the directive define as an ’incident’? To whom does an incident need to be reported and what are the time limits on each stage of the reporting process? These issues become even more complex for organisations which operate under a range of regulatory regimes or in multiple jurisdictions.  

NIS2 Article 21 sets out a series of minimum cyber-risk management measures that in-scope organisations will be expected to implement and, therefore, that EU member states will need to enshrine in local legislation. These measures include incident handling, which is further defined within Article 6 as “actions and procedures aiming to prevent, detect, analyse, and contain or to respond to and recover from an incident”.   

Incident handling is nothing new, and most of the measures within NIS2 aren’t either. Many organisations – even small ones – will have some sort of incident response policy in place, however rudimentary (if your organisation doesn’t have a plan, now is the time to make one!). 

Even those organisations with a solid incident response might find that it doesn’t factor in  the strict reporting obligations set out in NIS2. Under the directive, organisations will have a formal duty to notify their competent authority of a significant incident within 24 hours, provide further details around extent and impact within 72 hours, and issue a full report within a month. 

The definition of an incident also warrants careful consideration. NIS2 states that an incident shall be considered significant if… 

‘(a) the incident has caused or has the potential to cause substantial operational disruption or financial losses for the entity concerned, (b) the incident has affected or has the potential to affect other natural or legal persons by causing considerable material or non-material losses” 

For most organisations, adjusting incident response planning to accommodate this definition and support the more stringent reporting obligations is likely to require some careful planning. 

Of course, incident response plans should comply with recognised best-practice, but the need to customise specific actions and strategies to fit with an organisation’s structure, wider compliance obligations, data landscape and operational requirements will be more important than ever. 

For organisations operating across multiple EU countries, there is an added layer of complexity in ensuring the local incident response planning is consistent with the specific requirements of each jurisdiction. 

If we look at past experiences with GDPR, an EU data privacy regulation, for example, there is a clear obligation to report a data breach in all affected jurisdictions. If a breach affects a data subject in more than one country in which an organisation operates, therefore, there is a duty to following the reporting requirements laid down by each national data protection regulator. This situation becomes even more complicated where data is shared or synchronised across national boundaries to facilitate, for example, backup regimes, operational resilience and cloud processing, but we’ll leave that for another day. 

Suffice to say that similar considerations are likely to come into play when organisations consider their local strategies for implementing NIS2 — compliant incident response measures. 

National authorities will be looking to organisations not just to have compliant incident response policies and procedures in place, but to compliment these with effective playbooks. Furthermore, there will be a duty on organisations to ensure a good standard of testing and rehearsal of their incident response provisions through tabletop exercises and other simulation activities. 

Testing the efficacy and operational viability of incident response plans ahead of a real emergency is likely to extend beyond technical considerations and will include an organisation’s ability to effectively bring together relevant stakeholders to mount effective response action.  

Effective incident preparedness also requires an organisation to understand its infrastructure, digital assets and data landscape. Recent experience suggests that organisations with effective endpoint tooling and up-to-date digital asset and data registers are much better placed to identify, collect, preserve and analyse data in the immediate aftermath of an incident, and are generally far more capable of containing, eradicating and recovering from an incident, as well as mitigating future risk through effective root cause analysis, all of which will likely be pivotal in complying with the both the spirit and letter of forthcoming NIS2 legislation. 

In the next blog we are going to look at supply chain management. In particular, we are going to be looking at incidents and data breaches, and then dive into the detection and analysis components of incident handling. 

Are you a Microsoft Security user and looking for more information on NIS2? Find out your NIS2 readiness and how BlueVoyant can help you maximize your Microsoft Security investment to comply.