NIS 2: Cyber security requirements

June 17th, 2024 Posted in Compliance, Information Security, NIS 2 Directive

Organisations in scope of NIS 2 should be preparing for compliance. EU countries have until 17th October 2024 to transpose the directive into their domestic laws and until 17th April 2025 to have identified Essential and Important entities.

The key obligations applicable to entities in scope are cybersecurity obligations, covering governance, risks management measures and incident notification. NIS 2 goes much further than the first NIS directive in mandating a minimum level of security to be met.

In this blog we are going to explain these requirements and share our view on what they mean for your security management practices if you are in scope.

This is the third in a series of six blogs in NIS 2. Together they provide an in-depth overview of NIS 2 together with our comments and recommendations for being ready. You can read the other blogs in this series by following the links below:

Key changes to NIS 2 cyber security requirements

The NIS 2 cyber security requirements are more specific than NIS 1. In the first directive, the requirement was for organisations to “take appropriate and proportionate technical and organisational measures to manage the risks posed to the security of network and information systems which they use in their operations”.

NIS 1 also required that organisations take appropriate measures to prevent and minimise the impact of incidents affecting the security of the network and information systems. 

NIS 2 sets a very similar outcome based obligations but goes further. It includes a list of governance and risk management requirements which must be met as a minimum. Because these are described as the minimum measures, we can expect some member states to build upon these as they transpose the directive into their domestic law. The inclusion of these specific security obligations is the key security change between NIS 1 and NIS 2. They establish the baseline security risk management framework which must be met.

Based on the requirements set out in NIS 2, which we’ll cover below, it is clear that you should be implementing a risk led security management system and embedding it into the culture of your organisation across your c-suite, IT and OT/ICS functions as a minimum.  

NIS 2 security obligations

The NIS 2 security obligations are set out in Articles 20, 21 and 23 of the directive, which cover governance, risk management measures and incident reporting, respectively. We’ll address each of these in turn and include some excerpts from NIS 2 to help support understanding. To learn how Evalian can help support you, visit our NIS 2 compliance service page. 

Governance (Article 20)

Article 20 of NIS 2 mandates that senior management (such as board members and executives) are to be responsible for approving and overseeing the implementation of risk management measures. It also states they can be held liable for failing to do so. Their liability is also covered later in the directive in the enforcement sections – which we’ll cover in a future blog. 

This is a substantial change from NIS 1 and a clear statement of intent that compliance is a top-down process, not just a bottom up one.  

This approach is entirely consistent with the drive for cybersecurity strategy and risk-based decision making to be owned at board and senior executive level. The UK NCSC has been driving this for several years and at least one UK NIS regulator in a sector in which we support clients has recently asked CEOs to personally sign off on their levels of compliance. 

This might sound straightforward, but in our experience it is more challenging to evidence than you might think. All boards and executives are aware that security is a risk and are increasingly demonstrating support by signing off financial support and additional headcount to manage risks, but very few get into the detail. We have seen evidence of papers going up to boards but little evidence of decisions being taken, or strategy being flowed down from that level, through meetings minutes or similar.  

In truth, executives and non-executives are busy managing a multitude of business and regulatory risks (financial, environmental, health and safety, license obligations and more) all of which are competing for their time – so they delegate a lot of decision making. A more structured approach to cyber risk management is going to be required though, including systematic reviews, by executives, of risks and the progress of implementing risk mitigation measures and controls.  

The right approach to address this challenge will depend on the size of your organisation and its current security governance maturity. A good knowledge of cyber risks and security will be required by your executives. This is recognised in NIS 2 at Article 20 which mandates cyber security training for senior management. We’re not just talking basic compliance training either. Training is required so that senior management can “identify risks and assess cybersecurity risk-management practices and their impact on the services provided by the entity“, which is a step up from what we see any most of the organisations we work with. 

Risk management measures (Article 21) 

The risk management requirements set out at Article 21 of NIS cover the full lifecycle of risk identification, analysis, evaluation against risk appetite, and risk treatment. Specific organisational and technical controls are listed as the minimum measures to be implemented.  

Appropriate Measures

The original wording from NIS 2 (referred to above) is expanded, with the core security expectations on covered entities being to: “take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems”.  

We have emphasised the word ‘operational’ in that paragraph because it was not in NIS 1. We think it’s important in the context of the Article 21 requirement, that an “all hazards” approach be used to “protect network and information systems and the physical environment of those systems”. 

We interpret these as a clear statement that Operational Technology (OT) systems are to be included in scope and that OT system risk assessments address potential health, safety and environmental impacts that could arise as a result of a security incident affecting control systems.  

Minimum Measures

Unlike the original directive, NIS 2 goes on to set out the minimum security requirements to be met. The level of detail is not as granular as the measures outlined in DORA, but it still sets out a framework that aligns to industry best practice standards like ISO 27001, IEC 62443 and NIST CSF. The measures listed are: 

  • Policies on risk analysis and information system security .
  • Incident handling. 
  • Business continuity, such as backup management and disaster recovery, and crisis management. 
  • Supply chain security. 
  • Security in systems acquisition, development and maintenance, including vulnerability handling and disclosure. 
  • Policies and procedures to assess the effectiveness of cybersecurity risk-management measures. 
  • Policies and procedures regarding the use of cryptography and, where appropriate, encryption. 
  • Human resources security, access control policies and asset management. 
  • The use of multi-factor authentication or continuous authentication solutions, secured voice, video and text communications and secured emergency communication systems within the entity, where appropriate. 

In respect of supply chain security risk measures, the NIS 2 requires that covered entities take account of vulnerabilities specific to each supplier, the overall quality of their products and cybersecurity practices including their secure development procedures.  

This additional emphasis on supplier security and secure development, specifically, is unsurprising given the extent to which supplier security weaknesses, especially in digital and software supply chains, have been exploited by threat actors in recent years, the SolarWinds supply chain attack being one example.  

It is clear from these expectations that organisations will need to implement a risk-based security management system, which necessitates governance, risk assessments, risk treatment, risk monitoring, assurance activities and continual improvement.  

Many covered entities may have a security management system in place, but in our experience, these are often paper based and not truly operational. NIS 2 will require that the security management system becomes fully embedded within the culture of the entity.  

Incident reporting (Article 23) 

The incident reporting requirements from NIS 1 are expanded significantly in Article 23 of the new directive.  

NIS 2 still requires covered entities to notify their relevant regulator about any incident that has a “significant impact” on their services. Whilst NIS 1 provided criteria to be used when determining whether an incident is significant, NIS 2 goes further and provides something closer to a useable definition (albeit it still requires interpretation).  

Article 23 states that an incident will be significant: “If it [the incident] has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned” or “it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage“. 

In terms of timelines, the requirement to report to the relevant competent authority (regulator) “without undue delay” remains, but with an associated timeline for an initial and subsequent report as follows: 

  • Early warning notification within 24 hours of becoming aware of the significant incident, to include a view on whether the cause was malicious and whether it could have a cross-border impact. 
  • A more detailed incident notification within 72 hours to include an assessment covering incident severity and impact, and the indicators of compromise (which should be interpreted as root cause where the incident cause is not malicious). 
  • Intermediate update reports if requested by the relevant competent authority (regulator). 
  • A final report no later than one month after the date of submission of the 72-hour report. This final report needs to set out a detailed description of the incident, severity, impact, root cause, mitigating measures applied and cross border impact (if any).  

NIS 2 also includes an obligation on covered entities to “notify the recipients of their services of significant incidents that are likely to adversely affect the provision of those services” where appropriate. There is also an obligation, where applicable, to notify service recipients potentially affected by a “significant cyber threat” about “measures or remedies” that those recipients could take in response to those threats.  

We anticipate that member states laws and guidance will provide greater clarity on these obligations, including the mechanics and the the contacts to be used.

In the meantime, covered entities should be updating their incident response plans to ensure that incidents are suitably assessed against defined service / business impact criteria. You should also establish or update your communications plan(s) to list internal authorities and responsibilities for escalating details of incidents and making the decision to notify a regulator if an incident is deemed to have a significant impact. 

Steps to take now

Assuming you’re in scope, we recommend a gap analysis against the security requirements set out in Articles 20, 21 and 23. Whilst these might seem specific, they can be developed by reference to industry best practice such as ISO 27001, NIS CSF and even the UK NCSC’s Cyber Assessment Framework. 

Bear in mind that security management systems typically focus on information and emphasise ‘Confidentiality’. NIS 2 is a cyber resilience standard for critical systems and supporting information. Your emphasis should therefore be on ‘Availability’ to a greater extent than it might be if you are already certified to ISO 27001.

This notwithstanding, the management system requirements for ISO 27001 set out in clauses 4-10 will absolutely be relevant. Many of the control objectives in Annex A will also be relevant but their application to any OT systems in scope may not always be possible and compensating controls may be necessary.  

It is important to bear in mind, however, that certification to ISO 27001 will not make you NIS 2 compliant. It may provide a strong basis for demonstrating compliance, but the standard expected by your certification auditor may fall below that required during a regulatory inspection. This is especially true for organisations deemed to be a ‘Essential entity’ under NIS 2 (something we’ll cover in a future blog).  

Need help with NIS 2? 

If you need help with NIS 2, please get in touch. We can support with all aspects of your compliance readiness programme. Our experienced consultants can lead a gap analysis, develop your improvement plan, prepare policies, lead risk assessments, help establish governance processes, improve your incident response plans, business continuity plans and manage supplier security risk assessments. 

We can also support compliance assurance through compliance auditing, internal auditing, business continuity exercising, cyber incident response exercising, penetration testing and controls assessments. 

Evalian is committed to protecting and respecting your privacy. By proceeding with your inquiry, you agree to the terms of our Privacy Policy.

  • This field is for validation purposes and should be left unchanged.

Sean Huggett Evalian

Written by Sean Huggett

Sean specialises in data protection, information risk and cyber security. He is a qualified barrister, having been called to the Bar in 1998, and started his career as an in-house lawyer working in intellectual property, data protection and commercial contracts. He later progressed into commercial leadership roles, working in a number of sectors before specialising in privacy and security strategy, management and compliance. Sean is also Managing Director at Evalian®. His qualifications include CISM, CISA, CRISC, ISO 27001 Lead Implementer, ISO 27001 Lead Auditor, CISMP, CIPP-E, CIPT & GDPR Practitioner Certificate.