ECIS response to the public consultation on the implementing act under Articles 21 and 23 of the NIS2 Directive
ECIS’ response to the public consultation on the implementing act under Articles 21 and 23 of the NIS2 Directive
ECIS is an international non-profit association founded in 1989 that endeavours to promote a favourable environment for interoperable ICT solutions. It has actively represented its members regarding issues related to interoperability and competition before European, international and national fora, including the EU institutions and WIPO.
ECIS’ members include large and smaller information and communications technology hardware and software providers, namely IBM, Corel, Kolab Systems, McAfee, Opera, Oracle, RealNetworks, and Red Hat. The association strives to promote market conditions in the ICT sector that ensure that there is vigorous competition on the merits and a diversity of consumer choice.
The implementing act focuses on two major areas, as foreseen by the NIS2 directive. This includes a) the technical and the methodological requirements of the cybersecurity risk management measures, as stipulated in Article 21 of the NIS2 Directive and b) specification of cases in which an incident shall be considered as significant as stipulated in Article 23 of the NIS2 Directive.
As the implementing act covers two substantial pillars of the NIS2 Directive and the draft implementing act has only been published recently, stakeholders need more time to prepare appropriate feedback. ECIS therefore recommends extending the feedback period by an additional four weeks.
Alignment with existing EU and international standards
The annex laying down rules for technical and methodological requirements of cybersecurity risk-management measures does include a very detailed list of requirements that are already included in European and international standards. ECIS recommends that the Implementing Act should reference or align with the Three-level approach for a set of cybersecurity requirements for cloud services standard CEN/TS 18026 from CEN/CENELEC[1] and other requirements and controls such as of ISO/IEC 27001, ISO/IEC 27002 and other international schemes for cybersecurity and information security requirements and controls.
We believe that as the above-mentioned standard CEN/TS 18026 already presents requirements for cybersecurity of cloud services, including requirements which are also strongly related to information security, its alignment with the Implementing Act would provide for the much needed harmonisation and clarity among the Industry. The existing certifications relating to CEN/TS 18026 and other standards can be used to show presumption of conformity with this Regulation.
Moreover it is not clear how the requirements that are included in the Annex relate to the development of a multistakeholder forum tasked to identify the best available standards and deployment techniques as referred to in recital 7 of the draft Implementing Act. It is a missed opportunity that this multistakeholder forum, that will consist of the Commission, the European Union Agency for Cybersecurity (ENISA), competent authorities, industry – including telecommunication industry – and other stakeholders, has not been established earlier to be able to identify relevant standards and/or guidelines that map the security requirements against well-known international standards. This could have provided a solid foundation to build compliance onto existing efforts and a far more practical roadmap for the relevant entities to follow for compliance versus a brand new set of requirements drafted by the European Commission, the Cooperation Group and ENISA.
This is even more relevant now that Article 25, paragraph 1 of the NIS2 Directive stresses the need to promote the convergent implementation of Article 21, paragraph 1 and 2 of the NIS2 Directive. To achieve this, Member States shall encourage the use of European and international standards and technical specifications and ENISA shall draw up, in cooperation with Member States, and, where appropriate, after consulting relevant stakeholders, advice and guidelines regarding the technical areas to be considered as well as regarding already existing standards, including national standards. The activities and output that is foreseen by Article 25 can also be relevant for the Implementing Act and should be taken into account.
For the NIS1 Directive, ENISA published guidelines mapping security requirements against international standards[1], providing a practical roadmap for companies to prepare for compliance. ECIS encourages a similar exercise for the NIS2 Directive and the measures set out in the draft implementing act that would also fulfil the requirements of Article 25 of the NIS2 Directive.
Supply Chain requirements and unintended consequences for open source
Although requirements on supply chain security are to be welcomed as they are vital in ensuring the overall security of services subject to NIS2, the current draft risks creating unintended consequences for open source software (OSS) that could significantly hinder use of OSS in the EU. Open source software’s security strength lies in the collaborative innovation of projects that include numerous contributors. These projects and contributors investing their efforts into driving European innovation should not be considered “suppliers” or “service providers” under the implementing act. Requiring relevant entities to contract with open source projects or contributors would fundamentally undermine the open participation model of such communities. Unlike in case of proprietary software where relevant entities are dependent on a supplier, in case of open source, the relevant entity gets the code and the rights they need to ensure it meets NIS2 requirements. Given the conceptual difference, we suggest that the implementing act should align with other Cybersecurity regulations (notably the CRA) in ensuring that such open source software is out of scope of the supply chain requirements. Last but not least, ECIS proposes to include in the Implementing Act an article or recital to clarify the legal status of the Implementing Act.
Detailed information about components
Section 6.1.2.(c) of the Annex implies that ICT suppliers should shareinformation describing the hardware and software components with their customers in critical sectors. This requirement does not contribute to higher security and, on the contrary, creates risks due to dissemination of sensitive information to various third parties. Under the CRA, software and hardware manufacturers should maintain SBOMS and make them available to market surveillance authority upon request – we recommend aligning with this approach and avoid contradicting requirements within NIS2.
Reporting requirements
· Reporting criteria. We recommend that Article 3 of the draft IA refers to “two or more” instead of “one or more” criteria for the selection of an incident as significant. The criteria presented in Article 3 are too numerous, broad and difficult to assess – therefore, selection based on just one would lower the threshold too much.
· Financial loss threshold. The threshold based on financial loss is too low. Within 24 hours, it is nearly impossible to assess the level of financial loss that an incident may potentially cause. Any incident may potentially meet the threshold of 100 000 of potential financial loss – which will result in overreporting. Due to the variety of companies in scope of the NIS2 Directive, in order to ensure a proportionate approach, we recommend to apply only the 5% threshold.
· Reputational damage. The criteria proposed in Art 3(1)(b) is not relevant in the security context and should be removed. Reputational damage caused by an incident may be relevant under the Digital Operational Resilience Act (DORA) due to specificities of the financial and banking sector. However, even in this context, reputational damage is not a strong threshold to be considered when assessing incident significance as it does not impact the security of the service.
· Recurring incidents. We recommend raising the threshold proposed in Article 4 to avoid overreporting of incidents, especially when they do not result from a malicious activity. First, we recommend a threshold of 10 incidents within 6 months. Second, aggregated combination of recurring incidents over a given period should also be assessed as meeting the thresholds established in Article 3. Moreover, reviewing aggregated incident data on a regular basis is operationally sound but specifying a quarterly cadence is not suitable for each incident type.
· Unavailability of service. The unavailability timeline proposed in several sectors covered by the draft IA is too short. The threshold of 10 minutes is very low and will inevitably draw entities’ resources into assessing whether disruptions meet the reporting criteria under the NIS2. It is important to keep balanced thresholds to ensure that dedicated operational and legal teams are triggered only in specific cases where there is reasonable evidence indicating a potentially significant incident. We recommend extending the reference timeline to 60 minutes. Furthermore, there are many different types of managed services and thus we would wish to see a clarification that the relevant entity is not required to implement monitoring for availability where such information is not currently tracked given the nature of the service. In particular, a relevant provision was included in the NIS Implementing Regulation 2018/15, which we ask to include in the new NIS2 implementing regulation:
“For the purpose of [Article 3-14], the digital service providers shall not be required to collect additional information to which they do not have access.”
Article 9(c) and 10(c) of the draft implementing act include unclear statements which will cause legal uncertainty. Both articles state that the availability of the content delivery network and managed (security) service is ‘impacted’ by the incident but lack a definition or quantification to define the threshold of this impact. This could result in service providers having to report any and all incidents regardless of whether the impact was minimal or actually significant. We therefore suggest deleting both paragraphs.
· Malicious action. The draft implementing act suggests a threshold based on a suspectedly malicious action. We recommend removing the word “suspectedly” as it makes the threshold too vague as any incident may be suspected to occur as a result of a malicious action. We recommend that incidents are reported once an entity establishes evidence of malicious activity. Moreover, this criterion lacks the factor of impact and should therefore apply only in combination with other criteria in Article 3 and 4.
Interplay with national transposition legislation and of the EU legal acts
It is the understanding of ECIS that the implementing act will be directly applicable to the relevant entities, even if the NIS2 Directive itself does not have a direct applicability, without a need to transpose the provisions of the Implementing Act into the national legislation. For the purpose of harmonisation and to mitigate the fragmenting effect this otherwise is expected to have, ECIS believes that any national provision conflicting with the implementing act, should be repealed.
In addition, we ask the Commission to align the reporting obligations under NIS2 with other cybersecurity acts on the EU level. In particular, CRA offers a notion of main establishment but applies a different definition than NIS2 – which means the ultimate goal of harmonisation of the reporting obligations will not be achieved. It is important to streamline the reporting on the national and EU level. Not only does this reduce the cost of compliance but also allows entities to focus their resources on risk mitigation. It would also create a more effective framework for information sharing across the EU. We recommend that entities that have the main establishment under NIS2 should also submit notifications to the same point of entry under other cybersecurity acts (e.g. NCCS, CRA).
Grace period
Entities in scope of the implementing act should be given appropriate time to analyse the final text, review their internal procedures and prepare compliance. It can be estimated that entities will have maximum one month (optimistic scenario) to prepare compliance before the act starts applying – which is clearly insufficient to implement such an ambitious framework. We therefore recommend to include a grace period of one year to allow companies review and prepare their network systems, supply chains and operational procedures before the new rules become binding.
[1] See: https://www.enisa.europa.eu/publications/minimum-security-measures-for-digital-service-providers