NIS2 Directive: Step-by-Step Guide to Compliance

Looking for an in-depth guide to NIS2 compliance? We’ve gone through the legislation and created an action plan to better anticipate the new EU directive.

The transposition of the NIS2 Directive into national laws by the Member States is expected by September 2024. Nevertheless, there are already many guidelines on what to do in anticipation of NIS2, and their implementation should preempt much, if not all, of the work.

As such, we have put together a list of best practices to ensure compliance with the NIS2 directive.

This is primarily addressed at Chief Information Security Officers (CISOs), but can also be useful to Data Protection Officers (DPOs) and legal departments.

This list is the result of personal work and is based on the final NIS2 text and the briefing of June 16, 2022 – which will be regularly cited as a source. However, it is not intended to be exhaustive and may change as the legislation becomes clearer. Therefore, it is up to each one to check its compliance, in particular with regard to future national laws. The transposition of the directive at the national level should bring its share of nuances in its application.

What is the NIS2 Directive?

The NIS2 Directive is a European Union legislative text on cybersecurity. It supersedes the first NIS (Network and Information Security) Directive, adopted in July 2016.

The NIS2 Directive strengthens security requirements in the EU by :

• expanding its scope to more sectors and entities
• taking into account the security of supply chains
• streamlining reporting obligations
• introducing monitoring measures
• introducing more stringent enforcement requirements
• adding the concept of “management bodies” accountability within companies
• harmonizing and tightening sanctions in all Member States

When will the NIS2 Directive come into force?

October 2024 at the latest. The NIS2 Directive was published at the Official Journal of the EU on 27, December 2022. From that date, Member States have 21 months to transpose the directive into national law – i.e. in October 2024.

However, it should be noted that this is the deadline for transposition into national law for Member States, not the compliance date for entities subject to NIS2. They will most probably have an additional period of time to comply with the directive as soon as it is applied in their respective countries.

NIS2: strengthening the role of the CISO

NIS2 is a major opportunity for all CISOs to strengthen their position within the company. The directive brings a notion of management accountability for cybersecurity risk management, as well as heavy penalties for offenders. The CISO is not a mere advisor here, but a guide and leader on the decisions to be taken, both on technical and business issues. With NIS2, the CISO also becomes an educator for senior executives, an evangelist of cybersecurity policies and best practices.

By playing their cards right, every CISO should accompany this responsibility with an increase in their budget and scope of action. With always the same objective: a better global security. 

Now, let’s take a look at what actions can be taken. As a CISO, your compliance action plan for NIS2 will focus on 3 main areas:

• Governance
• Incident detection and response
• Securing and testing perimeters and assets

1. Determine if you are affected by NIS2

NIS2 expands the scope of the NIS Directive to include more sectors and types of public and private entities. Before anything else, it is therefore essential to know if you are targeted by the text.

Determine if you are an Essential Entity (EE) or an Important Entity (IE)

The first NIS directive applies to DSPs (Digital Services Providers) and OESs (Operators of Essential Services). These terminologies disappear with NIS2 – even though in practice, the entities covered by NIS are also covered by NIS2.

For its scope, the NIS2 directive distinguishes two types of entities:

• Essential Entities (EE), detailed in Annex I of the NIS2 text
• Important Entities (IE), detailed in Annex II of the NIS2 text

The Essential Entities (EE) cover the following sectors:

• Energy
• Transport
• Banking
• Financial market infrastructure
• Health
• Drinking water
• Waste water
• Digital infrastructure – cloud providers, data centers, DNS, etc.
• ICT service management (B2B): Managed service providers and Managed Security Service Providers
• Public administration
• Space

The Important Entities (IE) cover the following sectors:

• Postal and courrier services;
• Waste management;
• Manufacture, production and distribution of chemicals;
• Food production, processing and distribution;
• Manufacturing of:
  • medical devices and in vitro diagnostic medical devices
  • computer, electronic and optical products
  • electrical equipment
  • machinery and equipment n.e.c.
  • motor vehicles, trailers and semi-trailers
  • other transport equipment
• Digital providers of:
  • online marketplaces
  • online search engines
  • social networking services platform
• Research, aka research organizations in the sense of “an entity which has as its primary goal to conduct applied research or experimental development with a view to exploiting the results of that research for commercial purposes, but which does not include educational institutions.” (Article 6(41))

Determine if your entity size makes you regulated under NIS2

The NIS2 directive concerns only medium and large companies. Indeed, NIS2 introduces in its Article 2 a notion of entity size that did not exist with the first iteration. It should be noted that micro and small enterprises in the sense of the Commission Recommendation 2003/361/EC are not affected by the legislation.

Exceptions list, no matter the entity’s size

However, there are exceptions. Some entities are subject to NIS2 regardless of their size, if one of the following conditions is met:

• the services are provided by:
  • public electronic communications networks or publicly available electronic communications services
  • trust service providers
  • TLD name registries and DNS service providers;

• the entity is a public administration entity;
  • of central government as defined by a Member State;
  • or at regional level as defined by a Member State in accordance with national law that, following a risk-based assessment, provides services the disruption of which could have a significant impact on critical societal or economic activities.

• the entity is the sole provider of a service in a Member State;
• a potential disruption of the service provided by the entity could have an impact on public safety, public security or public health;
• a potential disruption of the service provided by the entity could induce systemic risks, in particular for the sectors where such disruption could have a cross-border impact;
• the entity is critical because of its specific importance at regional or national level for the particular sector or type of service, or for other interdependent sectors in the Member State;
• the entity is identified as a critical one under Directive (EU) 2022/2557 – aka the Critical Entities Resilience Directive (CER). The critical entities with regard to this directive are detailed in its Article 6 and its Annex. Spoiler alert: they are about the same as the critical ones in the sense of NIS2.

The NIS2 states that each Member State shall establish a list of the national entities covered by the above points.

Check if you are falling under another legislation specific to your sector

Some sectors, especially the most critical ones, are subject to other legislation regarding cybersecurity. They sometimes complement the NIS2 directive, or even supersede it, according to the “lex specialis” principle – a specific law prevails over a general law. It is therefore important to know if you are affected by any other legislation.

Some guidance can be found in the Impact Assessment Report that accompanies the NIS2 proposal (Document 3/3, page 46). It outlines that:

• For the financial sector, the DORA (Digital Operational Resilience Act) regulation is “lex specialis” in relation to the NIS2 directive, by “setting out consolidated, simplified and upgraded ICT risk requirements throughout the financial sector”. If necessary, here is a link to our guide to DORA compliance for the financial sector;
• For the energy sector, it is the Risk Preparedness Regulation that is mentioned as a complement to NIS2. The same applies to the Regulation (EU) 2017/1938 aimed at ensuring gas safety;
• For the transport sector, several European initiatives are mentioned, such as for aviation and maritime transport;
• For electronic communication networks and services, it is the European Electronic Communications Code (EECC) that is widely discussed.

2. Raise awareness among top management about NIS2 sanctions and fines

The NIS2 directive is intended to be much more dissuasive than its predecessor. To ensure compliance, it sets out two types of sanctions:

• hefty and quantified administrative fines ;
• a liability of top managers and C-Level executives within the organizations.

It is the CISO’s responsibility – but not only – to make clear to senior executives the penalties of the NIS2 directive. To put it bluntly, this sword of Damocles should help CISOs push through their decisions and the inherent budget increases.

For reference, all of the penalties and fines described further on are outlined in Chapter VII of NIS2, Supervision and Enforcement (Articles 32, 33 and 34).

Fines of “at least” €10 million or 2% of annual worldwide turnover

NIS2 specifies and reinforces the fines foreseen by the law in case of non-compliance with:

• reporting obligations, as set forth in Article 23
• cybersecurity risk management measures, as set forth in Article 21

Article 34(4) of the NIS2 Directive provides for administrative fines in case of non-compliance with these obligations (editor’s note: we will come back to this later in this article). These fines are different depending on whether the entity is Important or Essential :

• For Important Entities (IE), the NIS2 directive allows for administrative fines of “at least” 7 million euros or “at least” 1,4% of the total annual worldwide turnover of the company to which the entity belongs during the previous financial year, whichever is higher.
• For Essential Entities (EE), administrative fines of “at least” 10 million euros or “at least” 2% of the total annual worldwide turnover of the company to which the entity belongs during the previous financial year. Whichever is higher.

Yes, you read that right, “at least”. The draft text of NIS2 called for fines “up to” €7M for IEs and €10M for EEs, but the final text of NIS2 provides for fines of “at least” 7 and 10 million respectively.

Member States are also allowed to sprinkle these fines with their own national laws and sanctions.

A liability of the “management bodies” regarding cybersecurity risk management

The NIS2 directive introduces the notion of top management accountability for security – and more precisely of “management bodies” according to the final text. The objective here is clear: to induce risk ownership by senior managers and the board of directors to ensure better governance. The prospect of sanctions is most effective when individuals are clearly identified as accountable.

The European Parliament’s rapporteur, Mr. Bart Groothuis, explained to us:

“The most important difference between NIS2 and NIS1 but also the legislations of other countries is, as they say in Germany, the Chefsache. It’s the CEO matter, it’s a Board issue. Cybersecurity can no longer be something like saying to an IT guy:  “okay, whatever, you do something”.

The CEO and Board of Directors must be aware of the latest news on what to do, how to get into control, where they are as an organization. Therefore, there is a personal fine for the CEO. This fine has been defined as 1.4 up to 2% for Essential Entities. Why? Because ransomware gangs, whenever they hack into a network, they ask for 1.4 to 2%.

So it’s a way to influence the calculus, saying, do you want to pay some ransomware gangs, do you want to pay a fine, or do you just want to invest a short little amount of money in cybersecurity? My expectation is that if the CEO becomes perfectly liable, he will ensure that it’s the latter.”

– Mr. Deputy Bart Groothuis

NIS2: sanctions for the top management

NIS2 allows Member State authorities to order offending entities:

• to make public the aspects of non-compliance with the directive;
• to make a public statement identifying the natural and legal person(s) responsible for the violation, and the nature of the violation;

In the context of a Essential Entity (EE), these sanctions may include:

• suspension of certifications and authorizations for services or activities provided by the organization ;
• a temporary ban from management positions within the entity for any person discharging managerial responsibilities at chief executive officer or legal representative level.

It should be noted that these latter enforcement measures are not applicable to public administration entities subject to the present Directive.

3. Educate and train top managers about cybersecurity risk management

Fortunately, the directive doesn’t simply bring sanctions against top management. NIS2 calls for regular training and risk ownership for executives. As a CISO, you are one of the best suited to take on this role within the organization – or at least to guide the selection of the training provider.

Regular training obligations for top managers

Regarding governance, Article 20 of the text provides that the management bodies of essential and important entities must :

• approve cybersecurity risk management measures taken by these entities;
• supervise their implementation (and be accountable for any non-compliance);
• follow “training, on a regular basis”, to gain sufficient knowledge and skills in order to apprehend and assess cybersecurity risks and management practices and their impact on the operations of the entity. The directive also encourages similar training for employees on a regular basis.

NIS2: which training to choose?

Well, after reading the final text from cover to cover, we unfortunately do not have the answer. NIS2 doesn’t specify the content of these trainings, nor the conditions to prove that they have been taken.

That being said, there are many topics to consider if one wants to “gain sufficient knowledge and skills in order to apprehend and assess cybersecurity risks and management practices“. Zero-trust principles, cyber threats, phishing and social engineering techniques, compliance requirements, you name it!

Furthermore, there are already several ways to educate employees at all levels about cybersecurity risk management, as well as the most fundamental hygiene best practices. In France for example, the ANSSI’s MOOC covers the basics of digital security. This program is free and leads to a proof of completion (however, the training does not lead to certification).

We also advise you to get in touch with the consulting firms present in your country, which will certainly offer seminars and training courses that meet the requirements of NIS2, DORA and the EU Cyber Resilience Act.

Live Hacking Events, a field training for operational teams

At Yogosha, we like hands-on approaches. That’s why we organize Live Hacking Events; events that bring together for a few days the client’s internal teams and hackers from the Yogosha Strike Force.

Let’s face it, Live Hacking Events are probably not the best approach to educate top executives on risk management. However, it is an excellent training opportunity for operational teams, be it developers or security teams.

Organizing a Live Hacking Event allows you to challenge your teams in a real-life setting, with a true Red Team vs Blue Team philosophy. Our hunters discover vulnerabilities, and your teams work on remediation in real time.

4. Plan and cost the budget increase

The NIS2 directive will inevitably result in increased expenses for covered organizations. As a CISO, you may want to plan for these increases today. This will give you visibility into your options, and allow you to have your decisions validated by the board of directors as soon as possible.

There is obviously no universal magic formula for calculating this budget increase, as it will depend on the level of maturity and governance already existing in each organization. Nevertheless, the NIS2 briefing gives some indications of the increases to be expected.

NIS2: forecast figures for the increase in the ICT budget

Within 3 to 4 years of NIS2 implementation, it is expected that ICT security spending will increase on average by:

• 12% for sectors already covered by NIS;
• up to 22% for sectors and types of services added to the scope of NIS2.

At the same time, NIS2 would reduce the overall cost of cyber security incidents by €11.3 billion.

For national budgets and administrations, an estimated increase of approximately 20-30% of resources would be expected in the short and medium term.

Source: These projections are detailed in the Impact Assessment Report 1/3, p.77. Projections of average sector-specific costs are given on pages 72 and 73.

Find out about the financial aid you may be eligible for

Part of the costs for organizations can be covered by various financial aids. There are EU-wide subsidies, such as the Digital Europe Program (DIGITAL), which provides 7.5 billion euros of funding for 2021 to 2027.

In France, organizations can benefit from the financial support of the France Relance plan. For the record, the security operations conducted with Yogosha are eligible for both fundings.

For instance, we conducted a mutualized bug bounty campaign for French local authorities, financed up to 70% by the cybersecurity segment of the France Relance plan, and with the support of the ANSSI. This allowed 50 of the best hackers of the Yogosha Strike Force to test the 15 most used applications by French cities, with a single expense for all municipalities.

Read also: Crowdsourced Security to protect public services and administrations

5. Review the 10 cybersecurity risk management measures mandated by the NIS2 directive

If every CISO should remember only one topic of this article, it should be this one.

The final text of NIS2 clearly states that Essential and Important Entities must:

“take appropriate and proportionate technical, operational and organisational measures to manage the risks posed to the security of network and information systems which those entities use for their operations or for the provision of their services, and to prevent or minimise the impact of incidents on recipients of their services and on other services.” – NIS2, Article 21

According to the legislation (Article 21), EEs and IEs must take at least the following 10 measures:

• policies on risk analysis and information system security;
• incident handling (prevention, detection, and response to incidents);
• crisis management and business continuity, such as backup management and disaster recovery;
• supply chain security including security-related aspects concerning the relationships between each entity and its suppliers or service providers;
• security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure;
• policies and procedures (testing and auditing) to assess the effectiveness of cybersecurity risk management measures;
• basic cyber hygiene practices and cybersecurity training;
• 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.

6. Streamline incident reporting

NIS2 tightens incident response obligations, and shortens some timeframes. As a CISO, this should be one of your primary concerns.

Write and document your Incident Response Plan

First thing to do should be writing (or reviewing) and documenting your Incident Response Plan. Defining incident response procedures and policies will help to smooth the process when you are faced with a response obligation.

If you don’t know where to start, here’s a cool guide by HyperProof on how to create a Cybersecurity Incident Response Plan. And as for NIS2-specific response obligations, you might want to read on.

NIS2: Incidents & Cyber Threats

The threshold of “number of users impacted” used in the first NIS directive has been abandoned. Regarding incident response obligations, the NIS2 directive is based on two distinct concepts:

1. incidents: meaning “any event compromising the availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or of the services offered by, or accessible via, network and information systems” according to Article 6(6);
2. cyber threats: meaning “any potential circumstance, event or action that could damage, disrupt or otherwise adversely impact network and information systems, the users of such systems and other persons”, according to Article 2(8) of the Cybersecurity Act, itself referred to in Article 6(10) of NIS2.

Article 23 provides that an incident shall be considered significant if:

1. it has caused or is capable of causing severe operational disruption of the services or financial loss for the entity concerned;
2. it has affected or is capable of affecting other natural or legal persons by causing considerable material or non-material damage.

What to do in the event of a significant incident or cyber threat?

In the event of a cyber threat or significant incident, essential and important entities shall notify, without undue delay:

• the competent authorities or the national CSIRT, while also making sure to report any information enabling to determine any cross-border impact of the incident ;
• where appropriate, the recipients of their services if the incident is likely to adversely affect the provision of that service;
• where appropriate, those recipients of the threat itself. In the context of a significant cyber threat, measures or remedies that can be taken in response should also be notified. 

Concerning response obligations to competent authorities or the CSIRT, entities should report:

1. an initial notification within 24 hours after having become aware of the incident, indicating whether it is suspected of being caused by unlawful or malicious acts or could have a cross-border impact;
2. within 72 hours of becoming aware of the significant incident, an incident notification, which, where applicable, shall update the previous information and indicate an initial assessment of the significant incident, including its severity and impact, as well as, where available, the indicators of compromise;
3. upon the request of a competent authority or a CSIRT, an intermediate report on relevant status updates;
4. a final report not later than one month after the submission of the first report, including at least the following:
   • a detailed description of the incident, its severity and impact;
   • the type of threat or root cause that likely triggered the incident;
   • applied and ongoing mitigation measures.
   • where applicable, the cross-border impact of the incident;
5. If the incident is still ongoing at the time of the submission of the final report, entities should provide a progress report at that time and a final report within one month of their handling of the incident.

NIS2: Who are the “competent authorities”?

Member States have their own CSIRTs (Computer Security Incident Response Teams) to which incidents can be reported. Some countries also have designated “competent authorities”. Regarding the current NIS Directive, those are the ANSSI in France, the CCB in Belgium and the BSI in Germany.

7. Assess Supply Chain Security

Supply chain security was a blind spot in the first NIS Directive. NIS2 fills this gap. The preamble 85 of the text explains:

“Addressing risks stemming from an entity’s supply chain and its relationship with its suppliers […] is particularly important given the prevalence of incidents where entities have been the victim of cyberattacks and where malicious perpetrators were able to compromise the security of an entity’s network and information systems by exploiting vulnerabilities affecting third-party products and services. Essential and important entities should therefore assess and take into account the overall quality and resilience of products and services, the cybersecurity risk-management measures embedded in them, and the cybersecurity practices of their suppliers and service providers, including their secure development procedures. Essential and important entities should in particular be encouraged to incorporate cybersecurity risk-management measures into contractual arrangements with their direct suppliers and service providers. Those entities could consider risks stemming from other levels of suppliers and service providers.”

– NIS2, Preamble 85

Concretely, this is a ripple effect. Organizations that provide some services to entities targeted by NIS2 will be expected to strengthen their digital security, even if they are not explicitly included in the scope of the directive. As a CISO, it is thus crucial to evaluate the security of the supply chain.

EEs and IEs must conduct a thorough risk assessment of their supply chain, starting with their direct suppliers (Tier 1). Preamble 86 places particular emphasis on MSSPs in the areas:

• incident response;
• penetration testing;
• security audits;
• and consulting.

NIS2 therefore directs organizations to be extra diligent in their selection of MSSPs. Let’s mention here that since Yogosha provide Penetration Testing as a Service, we’ll likely be subject to these due diligence requirements. We have already taken steps to demonstrate the security of our environments – e.g. with ISO 27001 certification.

Yogosha: a Vulnerability Operations Center to involve partners’ teams

Yogosha is a VOC, a Vulnerability Operations Center. A VOC is to offensive security what a SOC is to defensive security. And since security is never done alone, our platform is first and foremost a space for collaboration.

The VOC allows our customers to bring together their own development and security teams, but also those of their partners. Yogosha’s technology allows to concretely involve the suppliers’ teams in a proactive and empowering security. If a customer has a partner who has red teamers or pentesters, they can bring them onto the platform – e.g. to conduct joint penetration tests.

The Yogosha VOC can therefore help to assess supply chain security through:

• increased collaboration between field teams from different entities;
• the ability to conduct joint security operations;
• smooth and transparent vulnerability management for all actors involved;
• support in risk mapping of the different entities;
• data-driven reports to monitor the overall security of the ecosystem.

Read also: What is a Vulnerability Operations Center (VOC)?

8. Make sure there is a business continuity and crisis management plan

The NIS2 directive clearly refers to “business continuity and crisis management” in its risk management measures. Let’s be clear, the stakes here are strategic and business, and this should be the role of all C-Level executives.

Nevertheless, a CISO worthy of the name must be somewhat involved in the process. Steps you can take include training employees in security best practices, or testing your business’ resiliency capabilities. It may also be a good idea to synchronize with the communications, marketing and legal teams on what public posture to take in the event of a breach, as well as what processes and templates to implement. Implementing an ISMS can also be highly valuable. Which brings us to the next point.

9. Implement an ISMS taking into account NIS2

Having an Information Security Management System (ISMS) helps to reduce digital risks, by structuring the organization’s information security management with a systemic approach. Simply put, adopting such a framework will allow you to better control and manage the levels of security risk in your company.

ISO27001, an international standard to create an ISMS

If you don’t know where to start, ISO27001 is a good pick. It’s the international standard when building an ISMS, and it’s widely used across companies around the world.

ISO27001 is also widely referred to in ENISA’s official guidelines on assessing DSPs’ security and OESs’ compliance with the security requirements of the first NIS Directive. Although the concepts of PSDs and OES will disappear with NIS2, it is likely that the recommended information security standards and control frameworks will not change dramatically.

Achieving ISO27001 certification may take some time, depending on the level of maturity and governance of your entity. Even though NIS2 won’t go into force until 2024, it is an important project that needs to be undertaken as soon as possible, this is an important project that should be undertaken as soon as possible.

NIS2: towards a European cybersecurity certification framework

With NIS2, the European Union is slowly but surely moving towards european cybersecurity certification schemes. The details are still to be worked out, but Article 24(3) of the text states that ENISA may be tasked with the project by the European Commission.

On this subject, the European Parliament’s rapporteur, Mr. Bart Groothuis, told us:

“This is up to the Member States to decide, but I think that what we want is a harmonized approach as much as possible. We want the same rules to be applied, so we have the same schemes in Romania as in the Netherlands, as in Spain… Why? Obviously, because the internal market is the basis for this piece of legislation. The ENISA will put forward five to eight new schemes per year, that’s what is going to happen. […]

And then the question is, at what pace will it come? It might take years before we have certifications across Europe, it’s not anywhere soon. So in the meantime, we could use other international schemes as well. There’s so many existing ones!”

– Mr. Deputy Bart Groothuis

10. Encourage secure development practices

NIS2 aligns with the EU Cybersecurity Act of June 2019, which calls for a culture of cybersecurity by design. In other words, a security built into products and services from their very conception.

Obviously, training the developers to secure development practices and frameworks is not the role of a CISO. But nothing prevents you from going the extra mile and to raise awareness about it. This can even be a joint effort with the CTO, the SOC teams or just internal security enthusiasts.

In addition to eventual courses, you can organize workshops or in-house CTFs (Capture The Flag). Holding a monthly or quarterly Bug Day with the development teams could also be a good approach.

A VOC to bring together dev & sec teams

In addition, our VOC also contributes to raising awareness of secure development practices by bringing together all communities:

• your security teams;
• your technical teams, such as the developers;
• your partners’ teams, such as red teamers or pentesters;
• hunters from the Yogosha Strike Force.

The VOC brings together these different disciplines, and helps all these people to communicate with each other. Maybe our hunters can help your devs fix an issue? Or maybe you could invite your partners’ red teams into a current bug bounty operation. Or even organize a Live Hacking Event so that everyone can meet in real life. Possibilities are numerous.

11. Set up a Vulnerability Disclosure Policy (VDP)

The NIS2 directive emphasizes the handling and disclosure of vulnerabilities, especially regarding networks and information systems. Among the cybersecurity risk management measures required by NIS2 (see #6 of this article) is the following:

• security in network and information systems acquisition, development and maintenance, including vulnerability handling and disclosure.

Preamble 58 expands on this a bit:

“Since the exploitation of vulnerabilities in network and information systems may cause significant disruption and harm, swiftly identifying and remedying such vulnerabilities is an important factor in reducing risk. Entities that develop or administer network and information systems should therefore establish appropriate procedures to handle vulnerabilities when they are discovered.

Since vulnerabilities are often discovered and disclosed by third parties, the manufacturer or provider of ICT products or ICT services should also put in place the necessary procedures to receive vulnerability information from third parties. In that regard, international standards ISO/IEC 30111 and ISO/IEC 29147 provide guidance on vulnerability handling and vulnerability disclosure. Strengthening the coordination between reporting natural and legal persons and manufacturers or providers of ICT products or ICT services is particularly important for the purpose of facilitating the voluntary framework of vulnerability disclosure.

Coordinated vulnerability disclosure specifies a structured process through which vulnerabilities are reported to the manufacturer or provider of the potentially vulnerable ICT products or ICT services in a manner allowing it to diagnose and remedy the vulnerability before detailed vulnerability information is disclosed to third parties or to the public.”

– NIS2, Preamble 58. 

The message is clear: it’s important for organizations – especially manufacturers or providers of ICT products or services – to be able to receive vulnerabilities reported by outsiders. And this process has a name: Vulnerability Disclosure Policy (VDP) – also called Responsible Disclosure Policy.

VDP: a secure channel for gathering vulnerability reports

A Vulnerability Disclosure Policy (VDP) is a structured channel provided by an organization for anyone to report a digital security issue to it. In other words, it is a secure way for third parties to know where and how to report vulnerabilities to an entity.

Create a VDP by yourself

It is entirely possible to write and implement a vulnerability disclosure policy on your own. There are many resources to guide you, such as

• Disclose.io, which offers a vulnerability disclosure policy generator;
• securitytxt.org, which helps to create security.txt files

Indeed, it is good practice to indicate the means of contact provided by your VDP in a security.txt file, available at www.website.tld/.well-known/security.txt. As an example, here is the security.txt of the Yogosha website.

Set up a VDP with Yogosha

Another solution is to call upon a professional platform to create and host your VDP. An exercise we are used to at Yogosha, as we have been offering VDPs to our customers since 2015.

Yogosha assists organizations in the implementation of their VDP:

• by accompanying the drafting of the disclosure policy – scope, disclosure requirements, guidelines, legal and Safe Harbor clauses… ;
• providing a secure platform to collect vulnerability reports sent by ethical hackers. All reports are centralized on the Yogosha platform, and you can standardize and streamline your vulnerability management by connecting your tools;
• offering triage options for vulnerability reports so you can focus on what really matters: remediation.

12. Conduct regular security tests and audits

It may seem obvious, but regular security testing is essential to ensure that perimeters are well protected. The NIS2 directive formally requires EEs and IEs to undertake:

• “policies and procedures (testing and auditing) to assess the effectiveness of cybersecurity risk management measures”;

Security tests are numerous and varied, and as a CISO you are (hopefully) already familiar with the subject.

Let’s mention that as a Vulnerability Operations Center, Yogosha offers different approaches to reduce digital risks:

• Vulnerability Disclosure Programs – VDP
• Penetration Testing as a Service
• Bug Bounty

Read also: Security Testing – The right test at the right time

Penetration Testing as a Service

Our platform enables the digitization of pentesting activities, with real-time results and faster launches than with traditional audits.

1. Our technology makes the whole practice more efficient and streamlined, whether you have in-house red teams or you provide pentests to your clients.
2. In addition to our technology, we conduct penetration testing with members of the Yogosha Strike Force ; a private and selective community of security researchers, each with their own expertise and skill sets.

Bug Bounty

When a sufficiently advanced security level is achieved, penetration tests show their limits. Bug Bounty then allows to face reality, by asking ethical hackers to test the security of a system. Bug bounty advocates a pay-for-results logic, while allowing to uncover complex and high-risk vulnerabilities that fall through the cracks of other audits.

We could talk about bug bounty for hours. But this article is long enough as it is, so let’s just say:

• We leverage an elite community of hunters, where each member has been carefully selected – unlike most bug bounty platforms that are public.
• Our Vulnerability Operations Center (VOC) can be SaaS or Self-Hosted, thus making it suitable for sensitive and critical systems.

To sum up

Member States still have until September 2024 to transpose NIS2 into national law. This buys organizations the time they need to prepare. But as the saying goes, it’s better to be safe than sorry. We can only advise all CISOs of entities within the scope of the directive to start working on compliance now, as some of the work may take some time.

The bulk of the work should be organized along three main lines: Governance, Incident Detection and Response, and Security Testing. Your actions should revolve around the 10 cybersecurity risk management measures required by the NIS2 directive (also see #5 of this article):

Next, here is a reminder of the different key steps in our recommended action plan for NIS2 compliance:

1. Determine if you are affected by NIS2
2. Raise awareness among top management about NIS2 sanctions and fines
3. Educate and train top managers about cybersecurity risk management
4. Plan and cost the budget increase
5. Review the 10 cybersecurity risk management measures mandated by the NIS2 directive
6. Streamline incident reporting
7. Assess Supply Chain Security
8. Make sure there is a business continuity and crisis management plan
9. Implement an ISMS taking into account NIS2
10. Encourage secure development practices
11. Set up a Vulnerability Disclosure Policy (VDP)
12. Conduct regular security tests and audits

Please contact us if you need assistance in complying with certain NIS2 requirements. Whether it’s for security testing, vulnerability disclosure, or a demo of our Vulnerability Operations Center to set up a common workspace with your internal teams, partners or suppliers.