Optimising NIS2 risk management and reporting compliance

Executive summary

The revised Directive on measures for a high common level of cybersecurity across the Union (NIS2) will expand the scope of the entities and sectors required to adopt comprehensive cybersecurity measures.1 Effective implementation of NIS2 is necessary to achieve its intended goal of increasing the level of cybersecurity across the EU.

To this end, the European Commission is preparing an implementing act that outlines the technical and methodological requirements for cybersecurity risk-management measures and further specifies the criteria for determining when an incident is significant for relevant entities.²

In this paper, we put forward key concrete recommendations on the proposed implementing act:

• The implementing act should avoid overly detailed technical requirements. Some requirements, such as identifying the root cause of an incident or recovery objectives in business continuity plans, may not always be possible and should be revised. The final act and annex should allow for differences in resources, capacities and risk profiles between entities, including between large and smaller entities.
• The implementing act should reference existing cybersecurity standards. ENISA should promptly develop guidance on how these standards align with NIS2 requirements. A multistakeholder forum should be established without delay to identify the best available standards and deployment techniques.
• The one-stop-shop principle should be reinforced for efficient compliance and reporting, with entities communicating with a single dedicated authority in their main establishment. This principle should be optionally extended to other entities under NIS2.
• There are limits to what service providers can control, and they should be responsible only for environments they control, not those solely under customers’ control.
• The annex appears to mandate a ‘three lines of defence’ model, appropriate for financial services but disproportionate for other entities. Organisations should have the flexibility to select a risk management approach that suits their needs.
• The requirement to log all incoming and outgoing traffic should either be removed or include information ‘where appropriate.’ Counterproductive requirements, such as centralised log storage, should be avoided, and physical and IT security events should be separated for clarity.
• Risk management within the supply chain should focus on critical direct suppliers or service providers to ensure a proportionate approach. Open-source software (OSS) should be excluded from the supply chain requirements.
• Significant incidents should be defined by meeting two or more criteria to avoid unnecessary burden and overreporting. Thresholds for significant incidents should focus on actual impact, such as a percentage of annual turnover for financial loss. Recurring incidents should focus on significant impacts affecting many customers.
• Timelines around availability and service level agreement (SLA) incidents should reflect commercial realities and service criticality. Reporting should focus on confirmed malicious actions following NIS2’s risk-based thresholds.
• The clock for determining when an entity became ‘aware’ of an incident should start when the entity knows with a ‘reasonable degree of certainty’ that a significant incident threshold has been met.
• The implementing act will apply from October 2024, a very short timeframe for demonstrating compliance. We urge for a one-year grace period, allowing entities to fully understand the requirements and develop implementation strategies.