CHAPTER 3: COMPLYING WITH THE DIRECTIVE

As described earlier, the NIS Directive is not a piece of legislation that applies directly to organisations, so speaking of the ‘Directive’s requirements’ is slightly misleading. It is not that the Directive tells organisations how to operate within the market; rather, it tells Member States to legislate within a set of parameters. Having said that, understanding what the Directive actually demands of Member States – and finding out what relevant competent authorities have said on the matter – can be illuminating, especially for DSPs that operate across several Member States.

Because, as previously noted, DSPs face a lower level of risk than OES, their security requirements are lighter. Article 16 of the Directive provides some detail on the two main requirements facing DSPs:

Minimum security measures

Article 16(1) states the following:

Article 2 of the Implementing Regulation goes into more detail for each of these elements, stipulating what sub-elements DSPs need to consider. That article also notes that DSPs need to keep “adequate documentation” so they can demonstrate compliance to relevant authorities and stakeholders.

In addition, ENISA has published its “Technical Guidelines for the implementation of minimum security measures for Digital Service Providers”, designed to help Member States and DSPs provide “a common approach” when it comes to the required security measures.²¹ The Guidelines list 27 security objectives, including security measures that take the five elements listed above into account. This means that meeting these 27 objectives can also support compliance with the NIS Directive’s security requirements. The Guidelines also recognise that different organisations need different levels of maturity depending on their specific circumstances: each objective can be achieved at three different ‘sophistication levels’, in accordance with the results of a risk assessment that identifies the organisation’s particular needs.

Regardless of how much note your organisation takes of ENISA’s guidance, it should remember that there are two keys to applying security measures:

Appropriate to the risk

Ultimately, DSPs are free to judge their own adequate measures, as long as they are appropriate to the risk. Taking a risk-based approach lies at the heart of cyber security best practice, as it is, after all, critical to fully understand a threat in order to treat it both adequately and proportionately. Without useful intelligence about the threats facing you, it is difficult to make sure that you are spending the right money on the right measures.

Taking a risk-based approach means having to establish the risks that your organisation faces or is likely to face at an early stage in your compliance project. You should also determine your organisation’s risk appetite (or risk tolerance) if you have not done so already.

For the purposes of compliance, you do not have to seek out every single risk your organisation may face. As the Directive focuses on risks that could affect IT continuity, it would be sensible to look for relevant sources of guidance on information security risk management, such as international standards (as suggested by the Directive itself). However, whether or not you choose to follow best-practice guidance, there are several methodologies an organisation can apply in assessing and managing its risks, which generally fall into two schools:

Each method has benefits and drawbacks, and the organisation should consider which is most appropriate to its needs. After establishing all risks – regardless of the approach – you should decide what measures to take. There are generally four types of response:

Naturally, retaining is only an appropriate choice for very specific risks. There are typically four reasons:

You should also bear in mind that ‘actual’ measures, whether they consist of modifying or sharing the risk, do not have to eliminate the risk altogether – they can simply be enough to lower the risk to within acceptable boundaries (determined by your risk appetite). Ultimately, it is a matter of balancing the cost of treating a risk (taking potential legal costs into account) against the impact of that risk.

Technical and organisational measures

The measures you apply to mitigate risks need to consider both technical and organisational approaches. After all, people have to implement and/or operate technology, and follow defined processes. For instance, the first security objective outlined in ENISA’s Technical Guidelines – establishing and maintaining an information security policy – is clearly an organisational measure. The ninth objective – establishing and maintaining appropriate security measures to ensure the security of supporting utilities (e.g. electricity or fuel) – has both technical and organisational aspects. Ensuring the security of such utilities may entail putting a policy – an organisational measure – in place, but also putting physical and/or technical controls in place, such as standby power generators.

All 27 security objectives are explained and mapped to ISO/IEC 27001:2013’s reference controls in Appendix 1.

Mandatory incident notification

Article 16(3) of the Directive says the following on incident notification:

Article 1 of the Implementing Regulation makes clear that the DSP itself is responsible for assessing the scale of an incident, its geographical spread and the significance of damages to service users in the EU – not any of the supervisory bodies. Article 4(1) defines the thresholds for what constitutes a “substantial impact”.

The metrics that determine whether an incident is of “substantial impact” are:

If any of these are the case, the DSP is required to notify its competent authority or CSIRT “without undue delay” (Article 16(3) of the Directive) when they become aware of the incident – exact timeframes are defined on a state-by-state basis. More generally speaking, competent authorities should also “be informed about potential new risks”, and should therefore encourage DSPs to “voluntarily report any incident whose characteristics have been previously unknown to them such as new exploits, attack-vectors or threat actor, vulnerabilities and hazards” (Recital 11 of the Implementing Regulation).

After notifying the competent authority or CSIRT, they may further notify other authorities or CSIRTS of the incident, should it indeed have a significant impact across borders. By the nature of DSPs, they are, after all, likely to be used remotely – its users are not bound to the Member State where the DSP is based. ENISA has provided a figure that explains the overall incident notification process for DSPs at EU level, which is reproduced in Figure 1.²²

Figure 1: Incident notification process for DSPs at EU level

In essence, the DSP is responsible for reporting incidents to either the CSIRT or the relevant competent authority, which will then inform the other body. The CSIRT and competent authority then share information with the single point of contact – referred to as ‘national reporting’ – assuming that the competent authority does not also act as the single point of contact.

If there is indeed a cross-border impact, the CSIRT and competent authority will report it to their respective bodies in the affected Member State(s). The CSIRT and competent authority in that/those Member State(s) will then communicate with one another, and report the incident to their single point of contact. Regardless of the cross-border impact, the single point(s) of contact will inform the Cooperation Group of the incident, which will cooperate with the CSIRTs network. This ensures that CSIRTs across the EU have the best possible information about incidents and can respond appropriately.

Earlier on, we explained that, due to the lighter security requirements for DSPs compared to OES, competent authorities have no need to supervise DSPs, unless provided with evidence that the DSP in question is not complying with the Directive’s requirements. Naturally, the most obvious evidence would be when an incident of “substantial impact” occurs – competent authorities would then need to investigate whether the organisation was compliant at the time. The lack of immediate supervision could result in DSPs forgetting to keep or even generate evidence that they do comply. This stresses the importance of not only achieving and maintaining compliance, but also ensuring you can prove it. The lighter requirements do not imply lighter penalties.

International standards

The NIS Directive and Implementing Regulation both note that the required security measures can be managed under the guidance of existing international standards (Article 16(1e) of the NIS Directive; Article 2(5) of the Implementing Regulation). However, neither provide any specifics on how to go about implementing them.

If your organisation opts for a standards-based approach, it has to consider a lot of variables, including which standards to select, which parts of your organisation will be in scope, and whether to seek certification against any or all of the chosen standards.

Some of our recommended choices to help DSPs manage information security risks effectively include:

There are also standards that provide guidance specifically for Cloud services, which we discuss in more detail in Chapter 4: Implementing Cyber Resilience.

As mentioned earlier, Article 2(6) of the Implementing Regulation is explicit about the fact that DSPs must have “adequate documentation available” so the relevant competent authority can “verify compliance with the security elements”. In order to meet that requirement, you should make sure that process flows produce evidence of compliance as a natural byproduct. For instance, if you have a process for confirming that critical software is up to date and fully patched, it should produce a record that demonstrates this. The cumulative records of this process will, over time, demonstrate good practice. Having an ISO 27001-aligned ISMS in place would also produce evidence of good practice and ensure that security is maintained. Such an approach would be favourably looked upon by regulators.

²¹ ENISA, “Technical Guidelines for the implementation of minimum security measures for Digital Service Providers”, February 2017, www.enisa.europa.eu/publications/minimum-security-measures-for-digital-service-providers.

²² ENISA, “NIS Directive and national CSIRTs”, February 2016, www.enisa.europa.eu/publications/nis-directive-and-national-csirts.