NIS Compliance Guidelines For OES
NIS Compliance Guidelines For OES
NIS Compliance Guidelines For OES
Contents
A. Identify ....................................................................................................................... 9
B. Protect ...................................................................................................................... 10
C. Detect ....................................................................................................................... 11
D. Respond ................................................................................................................... 12
E. Recover .................................................................................................................... 12
5. Incident Notification by Operators of Essential Services ............................................... 14
The measures required include the application of a set of binding network and information
system security and incident reporting obligations to a wide range of critical infrastructure
operators, termed ‘Operators of Essential Services’ (or OES) including energy, transport,
health, drinking water supply and distribution and digital infrastructure. Note that in giving
effect to the NIS Directive at national level, the NIS Regulations provide that for OES in
the banking and financial market infrastructure sectors only the incident reporting
obligations in the NIS Regulations apply.3 The security obligations applicable to entities in
the banking and financial market infrastructure sectors are set out in sector specific EU
Regulations. The NIS Directive also requires the application of a new regulatory regime of
binding security and incident reporting obligations on so called Digital Service Providers
(DSPs). These include online marketplaces, cloud computing providers and search
engines providers.
Regulation 25(1) of the NIS Regulations permits the Minister for Communications, Climate
Action and Environment to make Guidelines for the purpose of providing practical
guidance as regards compliance by Operators of Essential Services and relevant Digital
Service Providers with their obligations under the Regulations. This document
establishes a set of draft Guidelines designed to assist OES in meeting their network and
information system security and incident reporting requirements under Regulations 17
and 18 of the NIS Regulations. These draft guidelines are both technology neutral and
non-sector specific to allow OES in different sectors adapt these to meet their needs, and
1
Directive 2016/1148 concerning measures for a high common level of security of network and information systems
2
Statutory Instrument 360 of 2018
3
Regulation 3(2) provides that Regulation 17 (security requirements in respect of operators of essential services) does
not apply to entities designated as OES in the banking and financial market infrastructures sectors.
Regulation 25(2) requires that a draft of the proposed Guidelines be published on the
internet and that written representations may be made in relation to the draft within 30
working days. These representations will be considered before the final version of the
Guidelines is published and comes into operation. These draft Guidelines are being
published for the purposes of further consultation in accordance with Regulation 25(2).
Dublin
D02 X285
Please note, submissions received as part of this consultation will not be published.
While these draft guidelines were developed to improve cyber security risk management
and incident response in Operators of Essential Services in accordance with their
obligations under the NIS Regulations, they can be used by organisations in any sector or
community. The guidelines enable organisations – regardless of size, degree of cyber
security risk, or cyber security sophistication – to apply the principles and best practices to
improve security and resilience.
The guidelines are not a universal approach to managing cyber security risk for critical
infrastructure. Many sectors will have unique risks, threats and vulnerabilities which
require a sector specific approach. The fundamental aim of the guidelines is to establish
cross- sectoral measures to create a high common level of security of network and
information systems across the Union.
Revised and updated guidelines may be adopted at a later date (again following the
consultation process prescribed in Regulation 25) following feedback on implementation
of these guidelines and lessons learned from security incidents.
II. The Central Bank of Ireland is the National Competent Authority for the
Banking and Financial Market Infrastructures sectors.
Regulation 12 permits the National Competent Authority for the relevant sector in respect
of which it is the National Competent Authority to designate a person as an OES in
respect of an essential service where it is satisfied that:
c) the person is a person of a type set out in Column (3) of Schedule 1 of the NIS
Regulations,
d) the sector and, where appropriate, subsector in which the essential service is
provided are each a sector and subsector set out in Schedule 1 of the NIS
Regulations;
e) the provision by the person of the essential service depends on network and
information systems, and
f) an incident affecting the provision by the person of the essential service would
have significant disruptive effects on the provision of that service in the State
Schedule 1 of the NIS Regulations sets out the types of entities in the various sectors and
subsectors covered by the Regulations from which Operators of Essential Services will be
designated, where they meet the criteria specified in Regulation 12. As set out in
The following statutory powers are afforded the designated National Competent
Authorities under the Regulations in respect of the sectors referred to above 4:
Both the Minister and the Central Bank of Ireland may seek information via a
binding information notice (Regulation 31)
The Minister (as National Competent Authority in respect of the sectors referred to
above) may carry out security assessments of the compliance by an OES with its
obligations under Regulation 17 and 18 (by means of a security audit or otherwise)
and may appoint an independent person or auditor to carry out the assessment on
his behalf (Regulation 27)
The Minister (as National Competent Authority in respect of the sectors referred to
above) may appoint authorised officers to examine a place owned or operated by
an OES for the purpose of assessing compliance with the Regulations (Regulation
28)
The Minister (as National Competent Authority in respect of the sectors referred to
above) may issue a compliance notice where of the opinion that a provision of the
Regulations is not being complied with, which may include directions as to the
action to be taken to remedy the non-compliance and to bring the notice to the
attention of the public or any person who may be affected by the non-compliance
(Regulation 30)
4
Part 8, Implementation and Enforcement, S.I 360 of 2018
Regulation 17(2) goes on to provide that the measures taken shall ensure a level of
security of network and information systems appropriate to the risks posed.
It will be the responsibility of the OES to demonstrate that they are complying with the
security and incident notification obligations under the Regulations. These guidelines offer
a sample approach for OES with regard to compliance with their obligations, identifying a
best practice framework which if adopted would be likely to achieve the outcomes set out
in Regulation 17 (1) and (2); taking appropriate technical and organisational measures to
manage risks posed the security of the network and information systems used in its
operations and minimising the impact of incidents on those systems, with a view to
ensuring the continuity of the essential services.
5
Regulation 3(2) provides that Regulation 17 (security requirements in respect of operators of essential services) does
not apply to entities designated as OES in the banking and financial market infrastructures sectors.
It is recognised that it is not possible to fully protect information system from all potential
security incidents. As such, the security requirements in the NIS Regulations are aimed at
reducing risk throughout the incident response lifecycle, and should not be considered to
render systems or entities invulnerable. Furthermore, the enforcement provisions in the
NIS Regulations will apply where an OES has failed to introduce or properly apply
appropriate network and information system security measures, either in the normal
course of events or in the aftermath of an incident. However, the fact that an OES may
have experienced an incident does not automatically mean that further enforcement
action will follow. Rather, the role of the Minister in these circumstances would be to
assess whether an affected OES had properly assessed the risks to their service, was
managing the assessed risks appropriately and that the appropriate security measures
were in place.
Lastly, when OES are formally designated as such, it will be with reference to the
essential service or services that they provide. The security measures that the OES
chooses to apply should specifically identify those network and information systems used
for the provision or support of those services.
Tailored to ensure effort is applied to measures which will have the most impact in
relation to enhancing the security of an OES.
Verifiable to ensure the OES can provide the Minister with evidence of the
effective implementation of security measures.
Inclusive, to ensure measures are applied to cover all five themes (Identify,
Protect, Detect, Respond, Recover).
be compatible with and complement existing Risk Management, Standards and Cyber
Security Programs in use by OES;
assist the Minister in carrying out effective security assessments (by means of security
audit or otherwise) of the compliance by an OES with its obligations under Regulation
17 the NIS Regulations.
The security guidelines consist of five themes which provide a high level view of an
organisation’s management of cyber security risk. These five themes are Identify,
Protect, Detect, Respond and Recover. The security guidelines in Appendix B describes
the categories and subcategories under each theme which define a wide-ranging set of
cyber security objectives, desired outcomes, and applicable references that are common
across the critical infrastructure sector.
Non applicability
As the guidelines are designed for use across multiple sectors and subsectors, the
outcomes described may not be relevant in all situations. As a result, it will be the
Standardisation
The use of internationally accepted standards and specification relevant to the security of
network and information systems is encouraged in order to promote convergent
implementations of the requirements in Regulation 17.
A. Identify
OES should develop the organisational understanding, structures, polices and processes
to manage cyber security risk to the network and information systems of the organisations
essential services, assets, data, and capabilities.
The activities in the Identify area are critical to the understanding of the business context
and resources that support critical functions and the related cyber security risks that
enable an organisation to focus its efforts and resources.
i. Asset Management
All systems and/or services that are required to deliver or support essential
services should be identified, understood and documented. This includes data,
personnel, devices, systems and facilities.
iii. Governance
The policies, procedures, and processes to manage and monitor the
organisation’s regulatory, legal, risk, environmental, and operational requirements
are identified, understood and documented, and inform the management of cyber
security risk.
B. Protect
The protect function is based on an OES being able to protect the elements deemed as
critical (data, personnel, devices, systems, facilities) to their organisation based on the
people, processes and technologies in place. Critical to protecting an OES is the premise
of developing and implementing the appropriate and proportionate security measures that
allow the delivery and protection of the organisations essential services and systems.
The activities in the protect area should be performed consistent with the organisations
risk strategy defined in the Identify function.
v. Maintenance
Maintenance and repairs of critical system components are performed consistent
with policies and procedures.
C. Detect
Develop and implement the appropriate capabilities to identify, detect and defend against
the occurrence of a cyber security event that may have the potential to affect essential
services.
The Detect function enables a timely response and the potential to limit or contain the
impact of potential cyber incidents.
i. Response Planning
Response processes and procedures are executed, maintained and documented,
to ensure timely response to cybersecurity events with an actual or potential
adverse impact.
ii. Communications
Response activities are coordinated with internal and external stakeholders (e.g.
external support from law enforcement agencies).
iii. Analysis
Analysis is conducted and documented to ensure effective response and support
recovery activities.
iv. Mitigation
Activities are performed and documented to prevent expansion of an event,
mitigate its effects, and eradicate the incident.
v. Improvements
Organisational response activities are improved and documented by incorporating
lessons learned from current and previous detection/response activities.
E. Recover
Develop and implement the appropriate capabilities, prioritised through the organisations
risk management process, to restore the capabilities of essential services that were
affected through a cyber security incident.
The activities performed in the Recover area are performed consistent with the business
context and risk strategy defined in the Protect area. The activities in the Recover area
support timely recovery to normal operations to reduce the impact from a cyber security
incident.
ii. Improvements
Recovery planning and processes are improved and documented by incorporating
lessons learned into future activities.
iii. Communications
Restoration activities are coordinated with internal and external parties, such as
coordinating centres, Internet Service Providers, owners of impacted systems,
victims, other CSIRTs, vendors and other stakeholders. The processes used for
communication will be documented.
5.1 Introduction
18. (1) (a) An operator of essential services shall notify the CSIRT in accordance
with paragraph (2) of any incident concerning it that has a significant impact on the
continuity of an essential service provided by it in respect of which it is designated
as an operator of essential services.
18. (1) (b) An operator of essential services who relies on a third-party digital
service provider for the provision of an essential service in respect of which it is
designated as an operator of essential services shall notify the CSIRT in
accordance with paragraph (2) of an incident affecting the digital service provider
which has a significant impact on the continuity of the essential service provided
by the operator.
18. (2) A notification in respect of an incident shall be made under paragraph (1)
without delay after the incident occurs and, in any event, not later than 72 hours
after the operatory of essential services becomes aware of the occurrence of that
incident.
The CSIRT is the computer security incident response team in the Department of
Communications, Climate Action and Environment designated as the computer security
incident response team in the State for the purposes of the Regulations.
Taken together, the above provisions have the effect that an OES is required to report
any incident affecting the security of their network and information systems that results in
a significant impact on the continuity of the service for which they are designated an OES.
This would include incidents affecting DSP’s or any 3rd party suppliers on which the OES
relies on for their essential services. The Regulations use the term ‘event’ – as such,
there is no requirement for a third party actor to be involved or an ‘attack’ to have taken
place for an incident to be notifiable. Rather, ‘any event’ includes accidents, equipment
failures, software errors, or external events (such as fires or floods) – all of these may
lead to notifiable incidents.
OES shall notify the CSIRT of any incident which has a significant impact on the
continuity of an essential service provided by them. The notification of an incident refers
to only the essential service under which the OES is designated. The timeline as stated in
para 18 (2), requires OES to notify the CSIRT in respect of an incident without delay after
Once an incident that has been notified to the CSIRT under Regulation 18 (1) has been
resolved, the OES is required to further notify the CSIRT that the incident has been
resolved, as per Regulation 18 (9).
The timeframe within which the OES must notify the CSIRT of resolution is no later than
72 hours after resolution of the incident, as per Regulation 18 (10).
Regulation 18(4) sets out the following three parameters that must be taken into account
in particular in determining whether an incident affecting an essential service provided by
an OES has a significant impact on the continuity of the essential service provided:
By way of practical guidance to OES in the various sectors and subsectors covered by the
NIS Regulations as to when an incident should be notified to the CSIRT, indicative, sector
specific Incident Reporting levels are set out in Appendix C, at which an incident
occurring in the relevant sector or subsector will likely reach the level of “significant
impact” within the meaning of the Regulations, taking into account the parameters
identified in Regulation 18(4).
As per Regulation 18 (3) of the NIS Regulations, incident notifications made to the CSIRT
are required to contain certain information, to the extent to which an OES may reasonably
be expected to have such information, as follows:
The Incident Reporting template below should be used by an OES to notify the CSIRT of
an incident. The template has been developed pursuant to Regulation 18(13) and will be
circulated to entities designated as OES in accordance with Regulation 12.
1. Report Type
a. First Report
Date for submission of first report.
b. Interim Report
Date for submission of interim report. The interim report is optional but
beneficial to the CSIRT with respect to supporting an OES during an incident.
c. Final Report
Date for submission of final report.
3. Incident Details
a. Description
Time/date incident first identified by the OES
May include internal reference number for incident
High level description of incident, meaning an overview of the incident and
situation.
b. Service(s) Affected
Specification of the essential service which has been affected by the incident
c. Nature and Impact
The nature and impact of incident;
Duration of the incident
Number of Users affected by the incident
Nature of the Compromise – is the incident a compromise of authenticity,
integrity, availability, confidentiality of data or service. Should be specified.
Geographic Spread of the incident.
Cross Border Impact of the incident.
Data Loss/Breach if they have occurred.
Material Damage
Financial Loss to the Operator
Reputational Damage to the Operator
Risk to Health, Safety or Possible Loss of Life as a result of the incident.
d. Root Cause
The root cause of the incident, if known should be specified. A number of
check boxes are presented as to the category of the root cause. A narrative of
the root cause should also be specified.
e. Severity
4. Current Situation
a. Investigation Status
The status of the incident should be outlined here based on the drop down list
presented. An indication should be specified.
b. Actions Taken To Mitigate/Contain
A narrative or indication of the actions taken to mitigate or contain the incident
should be presented.
c. Expected Time To Resolve
An indication on the time that is required to resolve the incident should be
indicated.
d. Support Required From CSIRT
An indication as to whether support is required from the CSIRT is required.
e. Notifications Issued
5. Information Sharing
a. Full Incident Information
The full incident information should be outlined here in full, with all details
presented. This should include for example, ICT assets affected, IOC’s and any
other relevant technical information that will allow the CSIRT to investigate the
incident.
b. Lessons Learned
The lessons learned should be presented here with examples such as
vulnerabilities/weaknesses exposed, new threats identified, inadequate
processes/controls, staff awareness training needs, success of business continuity
and disaster recovery plans, but not limited to just these. All relevant information
should be presented.
NIS Compliance
Guidelines for OES
prioritised RS.CO-1: Personnel know their roles · COBIT 5 EDM03.02, APO01.02, APO12.03
through the and order of operations when a · ISA 62443-2-1:2009 4.3.4.5.2, 4.3.4.5.3, 4.3.4.5.4
Not Applicable
(b) Oil - Operators of oil transmission pipelines
Not Applicable
(c) Gas - Supply undertakings as defined in point (8) of Article 2
of Directive 2009/73/EC of the European Parliament
and of the Council of 13 July 20096
Not Applicable
- Storage system operators as defined in point (10) of
Article 2 of Directive 2009/73/EC of the European
Parliament and of the Council of 13 July 20096
Not Applicable
- LNG system operators as defined in point (12) of Article
2 of Directive 2009/73/EC of the European Parliament
and of the Council of 13 July 20096
6
O.J. No. L 211, 14.08.2009, p.94
Not Applicable
- Operators of natural gas refining and treatment facilities
7
O.J. No. L 97, 9.4.2008, p.72
8
O.J. No. L 70,14.3.2009, p.11
9
O.J. No. L 348, 20.12.2013, p. 1
10
O.J. No. L 96, 31.3.2004, p.1
11
O.J. No. L 129, 29.4.2004, p.6
Not Applicable
(d) Road - Road authorities as defined in point (12) of Article 2 of
transport Commission Delegated Regulation (EU) 2015/962 of 18
December 201413
12
O.J. No. L 208, 5.8.2002, p. 10
13
O.J. No. L 157, 23.6.2015, p.21
> 50 000
or
14
O.J. No. L 207,6.8.2010, p.1
15
Regular level is the daily annual average of transactions, taking the previous year as the reference period for calculations.
Based on customers
> 50 000
or
16
Regular level is the daily annual average of transactions, taking the previous year as the reference period for calculations.
> 50 000
or
17
Regular level is the daily annual average of transactions, taking the previous year as the reference period for calculations.