Introduction

This guide is for organisations providing digital services such as online marketplaces, online search engines and cloud services.

It outlines the requirements of the NIS Regulations 2018 (NIS) and subsequent post-implementation review. It summarises the obligations for relevant digital service providers (RDSPs) and explains the ICO’s role as the UK’s competent authority for these organisations.

Other organisations covered by NIS, such as operators of essential services, should look to their own competent authorities for specific guidance. However, they may find some parts of this guide useful, such as where the interaction between NIS and the UK GPDR is outlined.

This is a living document and we are working to expand it in key areas. It includes links to relevant sections of the NIS Regulations, the EU NIS Directive, other relevant ICO guidance, guidance produced by the National Cyber Security Centre (NCSC) and guidance produced by the European Union Agency for Cybersecurity (ENISA).

At a glance

• NIS is intended to establish a common level of security for network and information systems. These systems play a vital role in the economy and wider society, and NIS aims to address the threats posed to them from a range of areas, most notably cyber-attacks.
• Although NIS primarily concerns cybersecurity measures, it also covers physical and environmental factors.
• NIS applies to two groups of organisations: ‘operators of essential services’ (OES) and ‘relevant digital service providers’ (RDSPs). This guide provides details about the requirements NIS places on RDSPs. Although aimed at RDSPs, it may also be useful for OES.
• There is a general exemption for digital services that are small and micro-businesses, unless they are part of a larger group or are controlled by larger organisations.
• The ICO is the ‘competent authority’ for RDSPs. We have a range of powers that we can use to enforce NIS, including issuing fines of up to £17 million in the most serious cases.

In brief

• What does NIS mean?
• What are the NIS Regulations?
• Is NIS a cybersecurity law?
• What organisations does NIS cover?
• Are there any exemptions?
• What action can the ICO take to enforce NIS?

What does NIS mean?

'NIS’ is shorthand for ‘network and information systems’. It refers to:

• electronic communications networks;
• devices or groups of interconnected devices that automatically process digital data; or
• digital data stored, received or transmitted by either of the above, for the purposes of their operation, use, protection and maintenance.

Read the key definitions section of this guide for more specific detail.

What are the NIS Regulations?

The NIS Regulations are the ‘Network and Information Systems Regulations 2018’ which came into force on 10 May 2018.

The Regulations intend to address the threats posed to network and information systems and therefore aim to improve the functioning of the digital economy.

Network and information systems play a vital role in society, and their reliability and security are essential for economic and societal activities. However, the magnitude, frequency and impact of security incidents is increasing, and network and information systems may become a target for harmful actions.

In addition to the NIS Regulations, the overall UK NIS regime includes an implementing act for digital service providers. This is known as the ‘DSP regulation’, and specifies security requirements and incident reporting thresholds for certain organisations.

This guide uses the single term ‘NIS’ to refer to the overall legal framework, including the NIS Regulations and the DSP Regulation.

Is NIS a cybersecurity law?

NIS is primarily aimed at improving cybersecurity, but is not in itself a cybersecurity law. It relates to any ‘incident’ that has an impact on a service, where that impact produces a significant disruptive effect. It also includes impacts that have ‘non-cyber’ causes, for example interruptions to power supplies or natural disasters such as flooding.

What organisations does NIS cover?

NIS applies to two groups of organisations:

• operators of essential services (OES); and
• relevant digital service providers (RDSPs).

You are a ‘relevant digital service provider’ if you:

• provide one or more of the following digital services: an online search engine, an online marketplace, and a cloud computing service;
• have your head office in the UK, or have nominated a UK representative; and
• don’t meet the definition of a micro or small enterprise – this definition applies where you have fewer than 50 staff and an annual turnover or balance sheet of below €10 million.

The ICO regulates RDSPs, not OES. However, we also have a regulatory function over both types of service wherever those organisations are processing personal data. This is because in many cases OES and RDSPs will be data controllers and therefore data protection law also applies to them.

Are there any exemptions?

Yes. NIS has a general exemption for small and micro businesses. If you provide a digital service but have fewer than 50 staff and an annual turnover or balance sheet below €10 million, you are not an RDSP and therefore NIS does not apply to you.

If your digital service is part of a larger organisation, you need to count the whole organisation’s staff and turnover when assessing if NIS applies. For example, on its own the digital service could meet the small business exemption, but if it is part of a larger group (or is controlled by larger organisations) and that group has more than 50 staff and an annual turnover or balance sheet above €10 million, then the digital service is in scope of NIS.

However, irrespective of your size, if you are processing personal data in connection with your service, you are still covered by the UK GDPR. This guide provides more information about the relationship between NIS and the UK GDPR later.

What action can the ICO take to enforce NIS?

The ICO can take several different actions to enforce NIS. These include enforcement notices, powers of inspection and penalties. We can issue a monetary penalty of up to £17 million in the most serious cases.

These powers are not mutually exclusive. We will use them in combination where justified by the circumstances.

More information about these enforcement powers is provided in the enforcement section of this guide.

These enforcement powers are separate from those we have available under data protection law. In cases where a NIS incident impacts on personal data, we are able to take action under both NIS and data protection law if it is appropriate and proportionate to do so. 

This is also the case where a NIS incident affects an OES. If that incident is also a personal data breach, or leads to a personal data breach, then the ICO has a regulatory function.

At a glance

• NIS concerns ‘network and information systems’ and their security. These are any systems that process ‘digital data’ for operation, use, protection and maintenance purposes.
• NIS requires these systems to have sufficient security to prevent any action that compromises either the data they store, or any related services they provide.
• NIS applies to two groups of organisations: operators of essential services (OES) and relevant digital service providers (RDSPs).
• OES are organisations that operate services deemed critical to the economy and wider society. They include critical infrastructure (water, transport, energy) and other important services, such as healthcare and digital infrastructure.
• RDSPs are organisations that provide specific types of digital services: online search engines, online marketplaces and cloud computing services. To be an RDSP, you must provide one or more of these services, have your head office in the UK (or have nominated a UK representative) and be a medium-sized enterprise.
• There is a general small business exemption for digital services; if you have fewer than 50 staff and a turnover or balance sheet below €10 million then you are not an RDSP, and NIS does not apply. However, if you are part of a larger group, then you need to assess the group’s staffing and turnover numbers to see if the exemption applies.
• NIS is regulated by sector-specific ‘competent authorities’. The ICO is the competent authority for RDSPs.
• The National Cyber Security Centre (NCSC) also has two functions: it is the UK’s ‘single point of contact’ (SPOC), as well as the ‘computer security incident response team’ (CSIRT).

In brief

• What are ‘network and information systems'?
• What is meant by ‘security of network and information systems’?
• What organisations are covered?
• What is an ‘operator of essential services’ (OES)?
• What is a ‘relevant digital service provider’ (RDSP)?
• What is a ‘competent authority’?
• What is the ‘single point of contact’ (SPOC)?
• What is the ‘computer security incident response team’ (CSIRT)?

What are ‘network and information systems’?

Regulation 1 of NIS defines a ‘network and information system’ as:

(a) an electronic communications network within the meaning of section 32(1) of the Communications Act 2003;

(b) any device or group of interconnected or related devices, one or more of which, pursuant to a program, perform automatic processing of digital data; or

(c) digital data stored, processed, retrieved or transmitted by elements covered under point (a) or (b) for the purposes of their operation, use, protection and maintenance;

This is basically any computer system used to process ‘digital data’. Digital data is any information stored in digital form on a network and information system. This information can include personal data even where the data is only processed for the operation, use, protection and/or maintenance of network and information systems. This is one reason for the inter-relationship between NIS and the UK GDPR.

What is meant by ‘security of network and information systems’?

Regulation 1 of NIS defines this as:

the ability of network and information systems to resist, at a given level of confidence, any action that compromises the availability, authenticity, integrity or confidentiality of stored or transmitted or processed data or the related services offered by, or accessible via, those network and information systems.

In essence, this refers to the concept of ‘information security’. You must have appropriate security measures to ensure that your systems, and the data within them, are not compromised.

This aligns closely with established standards such as ISO/IEC 27000:2018 and well-known guidelines including the US National Institute of Standards and Technology (NIST) Special Publication 800-53:

The terms ‘confidentiality, integrity and availability’ are collectively known as the ‘CIA triad’, and they are well-established information security concepts. They are present in the UK GDPR and are therefore relevant in terms of the technical and organisational measures that you are required to have in place under that legislation. NIS adds ‘authenticity’ to these three.

This means that most of the NIS requirements in practice relate to cybersecurity measures. However, information security also encompasses physical and environmental factors as well, eg where such factors may pose a risk of compromising your systems.

What organisations are covered?

NIS applies to two different groups of organisations. These are ‘operators of essential services’ (OES) and ‘relevant digital service providers’ (RDSPs).

Although the ICO is not regulating operators of essential services it is nevertheless useful to outline what these are. NIS envisages a different set of requirements for the two groups, with the security obligations and enforcement regimes for OES being stricter than RDSPs.

What is an ‘operator of essential services’ (OES)?

Essential services are services that are critical to the national infrastructure (eg water, energy, transport) or significantly important to the economy and wider society like health services and digital infrastructure.

Regulation 1 of NIS defines an essential service as:

‘a service which is essential for the maintenance of critical societal or economic activities’

An ‘operator of essential services’ (OES) is an organisation that provides an essential service, where:

• the service provision depends on network and information systems; and
• any incident would have ‘significant disruptive effects’ on that service.

Part 3 of the NIS Regulations 2018 deals with the identification of OES and the security requirements they are obliged to follow. These are outside the scope of this Guide. If you are an OES and want to know more about these obligations, we recommend that you consult guidance produced by your competent authority, as well as the NCSC’s guidance.

What is a ‘relevant digital service provider’ (RDSP)?

If you provide certain types of digital services, you are a ‘digital service provider’ or DSP. However, NIS does not apply to all digital services. To be covered, your digital service must be one or more of:

• an online marketplace;
• an online search engine; or
• a cloud computing service.

If you provide any of these, alone or in combination, then you are a providing a type of digital service covered by NIS. There is more detail on the precise definition for each of these under the section titled ‘Digital service providers’.

However, for NIS to apply to you directly, you must:

• have a head office in the UK, or have nominated a representative in the UK; and
• not meet the definition of a micro or small enterprise – this definition applies where you have fewer than 50 staff and an annual turnover or balance sheet of below €10 million.

If you meet these conditions then you are an RDSP, and must comply with the NIS requirements.

Part 4 of the NIS Regulations 2018 details these requirements. These include an additional implementing act, Regulation 2018/151, which is specifically aimed at RDSPs and is referred to in this Guide as ‘the DSP Regulation’.

The following sections of this Guide provide further detail on Part 4 of NIS. 

However, even if your service is not an RDSP, it is likely that you are a data controller and potentially a data processor under the UK GDPR, and therefore you need to ensure that any personal data you process complies with data protection law.

What is a ‘competent authority’?

‘Competent authority’ is the term used in NIS for a regulatory body. There are multiple competent authorities responsible for different sectors covered by NIS.

The ICO is the competent authority for RDSPs. In that capacity, we are required to:

• review the application of NIS on RDSPs;
• prepare and publish guidance for RDSPs;
• consult and co-operate with other relevant agencies, such as law enforcement, other competent authorities, and the NCSC; and
• undertake enforcement action, where appropriate.

A list of other competent authorities is published in Schedule 1 of NIS.

What is the ‘single point of contact’ (SPOC)?

NIS establishes a ‘single point of contact’ (SPOC). The SPOC’s role is concerned with cross-border co-operation, for example in any incident that has an impact in another Member State. Competent authorities provide the SPOC with an annual summary of incident notifications, and the SPOC in turn reports to a European-level ‘Cooperation Group’ as well as the EU Commission.

GCHQ is the UK SPOC, with functions under NIS carried out by the National Cyber Security Centre (NCSC) will be the UK SPOC. We have provided more information on the role of the SPOC later in this Guide.

What is the ‘computer security incident response team’ (CSIRT)?

NIS establishes a CSIRT to monitor and respond to incidents it is notified about. The CSIRT also has other functions to provide warnings, alerts, announcements and disseminate information about risks and incidents. Competent authorities are required to share incident notifications with the CSIRT as soon as reasonably practicable.

GCHQ is the UK CSIRT, with functions under NIS carried out by the NCSC. We have provided more information on the role of the CSIRT later in this Guide.

At a glance

• If you provide an online search engine, online marketplace or cloud computing service (either alone or in combination) then you are a digital service provider (DSP).
• Your digital service must be provided to external customers – ie, to individuals or organisations. If you only maintain these services internally, you are not a DSP.
• If you provide one or more of these digital services, are not a small or micro business, and you either have a head office in the UK or have nominated a UK representative, then you are a ‘relevant digital service provider’ (RDSP) for the purposes of NIS.
• Online search engines are digital services that enable individuals to perform searches of all websites based on a particular query or search term. If you run a website that uses an embedded search from a search engine provider, your site is not covered by NIS and you are not deemed to be a DSP – it is the underlying search engine that is covered.
• Online marketplaces are digital services that allow individuals or traders to conclude sales or service contracts with traders, either on their own website or by means of providing services to traders’ websites. Online retailers that sell directly to individuals on their own behalf are not covered.
• Cloud services are digital services that ‘enable access’ to a scalable and elastic pool of shareable computing resources. This can include common cloud models like ‘Platform as a Service’ (PaaS) and ‘Infrastructure as a Service’ (IaaS). If you provide ‘Software as a Service’ (SaaS) you are also covered to the extent that your service is scalable and elastic.
• There is a general exemption for small and micro businesses. If you have fewer than 50 staff and an annual turnover and/or balance sheet below €10 million does not apply to you and you are not an RDSP. However, if your service is part of a larger group, you need to include the staff and turnover size of the group when assessing whether the small business exemption applies.
• RDSPs are required to register with the ICO.

In brief

• What types of digital services are covered?
• What is an online search engine?
• What is an online marketplace?
• What is a cloud computing service?
• We are a small business – does NIS apply?
• Do we have to be based in the UK?
• Do we have to register?

What types of digital services are covered?

You are covered by NIS if you provide one or more of:

• an online search engine;
• an online marketplace; or
• a cloud computing service

If your head office is in the UK, and you are neither a micro nor small enterprise, then you are a ‘relevant digital service provider’ and NIS applies to you.

Importantly, you need to provide your digital service to external customers. You may, for example, operate a search engine within your own corporate network for your employees to use. However, whilst this may be a ‘digital service’ as defined by NIS, it does not make you a ‘digital service provider’ because the search engine is internal to your systems.

What is an online search engine?

Regulation 1 of NIS defines an online search engine as:

a digital service that allows users to perform searches of, in principle, all websites or websites in a particular language on the basis of a query on any subject in the form of a keyword, phrase or other input, and returns links in which information related to the requested content can be found.

This describes a web search operator such as Google or Bing. Websites that offer users a search function that is powered by another search engine (eg websites that embed a search engine provider) are not included in this definition, although the underlying search engine may be covered provided it meets the definition of being an RDSP.

The definition of an online search engine does not include internal search engines that organisations may operate. You have to be providing the search engine to the public in order for this definition to apply.

What is an online marketplace?

Regulation 1 of NIS defines an online marketplace as:

‘a digital service that allows consumers and/or traders […] to conclude online sales or service contracts with traders either on the online marketplace’s website or on a trader’s website that uses computing services provided by the online marketplace’

For the purposes of NIS, online marketplaces are platforms that enable buyers (both consumers and traders) and sellers to conclude sales of goods and services. Not all platforms that allow individuals to buy goods and services online are covered; for example, the following are not ‘online marketplaces’ under NIS:

• sites that redirect users to other services to make a final contract, such as price comparison websites;
• classified ads; and
• online retailers that only sell directly to consumers on behalf of themselves.

Where an online marketplace uses a third-party payment provider to complete a purchase, the marketplace is still covered by NIS. This is because those concluding the sale do their business with the marketplace, not the payment provider.

What is a cloud computing service?

Regulation 1 of NIS defines a cloud computing service as:

‘A digital service that enables access to a scalable and elastic pool of shareable computing resources.’

The definition has close alignment with that of NIST Special Publication 800-145:

‘Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.’

The term primarily, but not exclusively, includes the following types of cloud computing services:

• Software-as-a-Service (SaaS) providers: only to the extent that they provide a scalable and elastic pool of resources to the customer;
• Platform-as-a-Service (PaaS) providers; and
• Infrastructure-as-a-Service (IaaS) providers.

These are the three main categories of cloud computing services. However, there are also hybrid models, as well as other examples of ‘[something] as a Service’. If these models or concepts meet the definition of ‘cloud computing service’ then NIS will also apply to them.

The key is whether your service ‘enables access’ to a scalable and elastic pool of shareable computing resources.

As detailed in NIST SP 500-292 on Cloud Computing Reference Architecture, the following entities may, depending on the circumstances, ‘enable access’ to these resources:

• ‘cloud provider’ – the entity responsible for making a service available to cloud customers, ie they build and manage cloud infrastructure; and
• ‘cloud broker’ – an entity that manages the use, performance and delivery of cloud services, negotiating relationships between cloud providers and cloud customers.

Cloud brokers may provide a multiplicity of offerings and can essentially act as a single ‘service point’ where cloud customers can manage multiple cloud services. They can provide business and relationship support services, as well as technical support.

According to the NIST reference architecture, cloud brokers can be placed into three different categories:

• ‘service intermediation’ – where a cloud broker provides value-added services or additional functionality on top of the underlying cloud provision that it makes available to customers, such as identity management or security measures;
• ‘service aggregation’ – where a cloud broker essentially creates a new cloud service by combining and aggregating multiple other services into a single offering. In this context, the broker may provide service integration and can also be responsible for ensuring that data moves between the customer and the multiple providers in a secure manner; and
• ‘service arbitrage’ – similar to aggregation, except the services the cloud broker offers are not fixed and can be selected from multiple providers.

If you are a cloud broker, you may be covered by the NIS Regulations depending on your circumstances and the type of service(s) you offer. NIS states that for a service to fit the definition of ‘cloud computing service’, it must ‘enable access’ to a scalable and elastic pool of shareable computing resources. The pool does not necessarily have to be owned and operated by the organisation that enables access to it.

For example, if a cloud broker enables access to underlying cloud services by means of an identity management platform, if that platform suffers an incident that disrupts or reduces its functionality, the broker’s customers may be unable to access the cloud computing resources the broker offers to them.

What are “computing resources”?

Recital 17 of the Directive provides a non-exhaustive list of what is meant by ‘computing resources’ in the context of cloud computing services:

‘Those computing resources include resources such as networks, servers or other infrastructure, storage, applications and services’

This essentially the same as the NIST definition of cloud computing, which refers to ‘networks, servers, storage, applications and services’.

What does ‘scalable and elastic’ mean?

Recital 17 of the Directive describes these terms. It says:

‘The term “scalable” refers to computing resources that are flexibly allocated by the cloud service provider, irrespective of the geographical location of the resources, in order to handle fluctuations in demand.’

‘The term “elastic pool” is used to describe computing resources that are provisioned and released according to demand in order to rapidly increase and decrease resources available depending on workload’

This means that if your cloud computing service exhibits these properties, then it would be regarded as ‘scalable and elastic’. This may not necessarily include all aspects of your service – it will in practice depend on your specific circumstances, the nature of the services you offer, and the details of any contractual arrangements between you and your customers. The key is whether the service is able to respond to increases in demand or changes in workload.

What does ‘shareable’ mean?

Recital 17 defines ‘shareable’ as:

‘computing resources that are provided to multiple users who share a common access to the service, but where the processing is carried out separately for each user, although the service is provided from the same electronic equipment.’

In addition to the computing pool being scalable and elastic, to be covered by NIS it also needs to be shareable. This essentially aligns the NIS definition with that of the standard description of cloud computing.  

We are a small business – does NIS apply?

There is a general small business exemption in NIS. If your digital service has fewer than 50 staff and an annual turnover or balance sheet below €10 million, then you are not classed as an RDSP. This also includes sole traders.

Regulation 1(3)(f)(ii) says that NIS does not apply to a DSP if:

‘the provider is not a micro or small enterprise as defined in Commission Recommendation 2003/361/EC.’

Commission Recommendation 2003/631/EC concerns the definitions of small and medium-sized businesses within the EU. The EU Commission has published a summary of the Recommendation which states that there are three categories of small and medium-sized businesses:

• ‘micro enterprise’: fewer than 10 employees and an annual turnover (the amount of money taken in a particular period) or balance sheet (a statement of a company's assets and liabilities) below €2 million.
• ‘small enterprise’: fewer than 50 employees and an annual turnover or balance sheet below €10 million.
• ‘medium-sized enterprise’: fewer than 250 employees and annual turnover below €50 million or balance sheet below €43 million.

The exemption covers the first two of these categories only, so NIS does apply to medium-sized businesses as well as larger companies.

Additionally, if your digital service is part of a larger organisation, or is controlled by one or more such organisations, you need to assess whether the total staffing numbers and annual turnover or balance sheet of the group exceeds the ‘micro’ and/or ‘small’ thresholds. If this is the case, then NIS applies to you.

Do we have to be based in the UK?

NIS applies to any digital service provider that has its head office outside of the UK but provides digital services within the UK. The RDSP must nominate a representative in the UK and inform the ICO of the name and contact details of that representative.

Do we have to register?

Yes. If you are an RDSP, Regulation 14 of NIS requires you to register with the ICO. Unlike registration under data protection law, there is no fee required for NIS. You should register with the ICO by emailing [email protected] with the subject line ‘RDSP registration details’, and include the following in your email:

• the name of your organisation;
• the name of your service;
• the address of your head office, or that of your nominated representative; and
• up-to-date contact details, including the name of a nominated individual who we can contact about NIS related matters if we need to, their email address and their telephone number.

You can also provide this information via our helpline on 0303 123 1113.

You also need to notify us of any change to these details as soon as possible, and no later than three months after the change taking place.

If your organisation grows to the point that you meet the definition of an RDSP – for example, if you can no longer rely on the SME exemption – then you must register at the latest by the date three months after you met the definition.

It is also important to note that although there is no fee to register under NIS, it is a separate registration process to that established under data protection law. If you are also a data controller, you need to register with us separately to pay the data protection fee.

At a glance

• If you are a relevant digital service provider, you are required to take appropriate and proportionate technical and organisational measures to manage the risks to your systems. These measures must ensure a level of security appropriate to the risk posed.
• NIS has specific obligations for these measures, which are further detailed by an additional law, the ‘DSP Regulation’. This section of the guide provides more information about these requirements.
• You must implement measures that cover the security of your systems and facilities; incident handling; business continuity management; monitoring, auditing and testing; and compliance with international standards.
• Many of these requirements align with the security provisions of the UK GDPR. It may also be the case that you are a data controller in any case, so the UK GDPR applies to you anyway.
• You must maintain documentation to evidence your measures. This also aligns with the accountability principle of the UK GDPR, and its provisions on documentation. We can request to see these records during any investigation or inspection.

In brief

• What are the security requirements?
• What considerations must RDSPs have?
• What is meant by ‘security of systems and facilities’?
• What is meant by ‘incident handling’?
• What is meant by ‘business continuity management’?
• What is meant by ‘monitoring, auditing and testing’?
• What about compliance with international standards?
• Are there any documentation requirements?
• Requirement checklist

What are the security requirements?

Part 4 of NIS, and Regulation 12 in particular, outlines the obligations for RDSPs. These include the requirements of an additional law, the ‘DSP Regulation’, which provides specifics on a number of areas.

The primary requirement is detailed in Regulation 12(1). According to this, RDSPs must:

‘identify and take appropriate and proportionate measures to manage the risks posed to the security of network and information systems’

According to Regulation 12(2), these measures must:

• ensure a level of security appropriate to the risk posed;
• prevent and minimise the impact of incidents affecting digital services; and
• take account of the requirements of the DSP Regulation.

When determining your measures, you are allowed to consider the state of the art – this refers to the state of technological development; in other words, the type of security measures that are available to you. This is similar to the UK GDPR, however with NIS you are not allowed to consider the costs of implementation.

This section of the guide provides an overview of the security requirements for RDSPs. It is based on the DSP Regulation, which has direct effect. We will provide further detailed guidance on these requirements soon. In the meantime, you may find guidance from the European Union Agency for Cybersecurity (ENISA) may assist you.

What considerations must RDSPs have?

Regulation 12(2)(c) outlines that when considering your security measures, you must:

‘take into account the following elements as specified in Article 2 of EU Regulation 2018/151:

(i) the security of systems and facilities;

(ii) incident handling;

(iii) business continuity management;

(iv) monitoring auditing and testing; and

(v) compliance with international standards.’

These refer to requirements from the DSP Regulation, which has direct effect. These requirements are detailed below.

What is meant by ‘security of systems and facilities’?

This refers to both the security of your network and information systems, and the physical environment of those systems.

As specified in Article 1(a) of the DSP Regulation, your measures in this area should cover the following:

• systematic management of your network and information systems;
• physical and environmental security measures;
• security of supplies; and
• access controls to systems.

These requirements align with the expectations of the security principle under the UK GDPR, although they differ by specifying a number of elements that RDSPs must take into account when implementing their measures. For example, under the UK GDPR (and if appropriate for your circumstances) we would already expect you to:

• have an overall information security policy, along with specific organisational policies governing risk, data security, human resources, security of operations, encryption, etc., and ensure such policies are implemented by appropriate technical measures
• take into account physical and environmental security when implementing appropriate technical and organisational measures;
• have both technical and organisational access control systems in place to ensure that such access is authorised and restricted to those who need it.

These requirements also align to a number of areas of the Cyber Essentials scheme, particularly in respect of access controls.

What do we need to consider in terms of systematic management of our systems?

You should establish appropriate policies for managing information security, including:

• risk analysis;
• human resources;
• security of operations;
• security architecture;
• secure data;
• system lifecycle management; and
• encryption, where applicable.

What do we need to consider in terms of physical and environmental security?

You should aim to implement a set of measures that protect your systems from damage. You need to address factors including system failure, human error, malicious action (external and internal) and natural phenomena.

What do we need to consider in terms of security of supplies?

You need to establish and maintain appropriate policies so that you know the accessibility and traceability of critical supplies.

What do we need to consider in terms of access controls?

You should have measures in place that ensure both physical and logical access is authorised and restricted based on business and security requirements. This is similar to the well-known ‘principle of least privilege’ – essentially, only those users who need access to a particular area of your premises, or a certain system, should have such access.

What is meant by ‘incident handling’?

Incident handling refers to your procedures for supporting the detection, analysis and containment of any incident, and your follow-up response. Article 2(2) of the DSP Regulation has a number of requirements for incident handling. These must include:

• incident detection processes and procedures;
• processes and policies on incident reporting;
• incident response; and
• incident assessment.

Again, these requirements also similar to what we expect from data controllers under the UK GDPR, although they differ by specifying a number of elements that RDSPs must take into account  For example, if you are a controller, we expect you to have (if appropriate for your circumstances):

• appropriate security monitoring processes to detect anomalous behaviour and potential data breaches in a timely manner;
• incident management policies and procedures, including incident handling and response, escalation and analysis;
• a process for regular testing of the effectiveness of security measures, such as by way of vulnerability scanning and penetration testing, and then acting upon the results of such testing; and
• documentation of previous incidents and the existence of a continuous improvement process.

What must we do in terms of incident detection?

You should aim to implement processes and procedures that allow you to have timely and adequate awareness of any anomalous events. You also need to maintain and test these processes.

What must we do in terms of incident reporting?

You should have processes and policies in place on how you will notify the ICO of any incident, and how you identify weaknesses and vulnerabilities within your systems, your environment and your security measures.

What must we do in terms of incident response?

You should ensure that you have an established procedure so that your organisation is able to respond to any incident in an appropriate manner. This should include reporting the results of such measures.

What must we do in terms of incident assessment?

If you suffer an incident, you should have processes in place to enable you to undertake a full assessment of its severity. This should cover incident analysis, collection of relevant information, and the use of this to support a continuous improvement process.

What is meant by ‘business continuity management’?

Article 2(3) of the DSP Regulation requires you to have the capability to maintain or restore the delivery of services to acceptable predefined levels following a disruptive incident. This relates to contingency planning and disaster recovery.

This provision is very similar to the UK GDPR, which obliges data controllers to have the ability to restore access to and availability of personal data following a physical or technical incident.

What must we do in terms of contingency planning?

You need to establish contingency plans to ensure the continuity of your service. You should base these on business impact analyses. You also need to test and assess your plans on a regular basis, eg through exercises.

What must we do in terms of disaster recovery?

You must have recovery capabilities, and be able to test and assess these on a regular basis.

What is meant by ‘monitoring, auditing and testing’?

Article 2(4) of the DSP Regulation requires you to establish and maintain policies and processes concerning systems assessment, inspection and verification.

What must we do in terms of systems assessment?

You must plan and conduct a sequence of observations or measurements to check whether your systems are operating as intended.

What must we do in terms of inspection and verification?

You need to check that:

• your guidelines are being followed;
• your records are accurate; and
• any efficiency and effectiveness targets are being met.

What must we do about processes?

You need to design processes to reveal flaws in the security mechanisms of your systems. This has to include both technical processes, and those personnel involved in operations.

What about compliance with international standards?

The DSP Regulation does not lay down particular requirements for RDSPs in this area. Instead, Article 2(5) clarifies that the meaning of ‘standards’ in NIS refers to:

• standards adopted by an international standardisation body as specified in Regulation 1025/2012; and/or
• any European, national, or internationally-accepted standards and specifications relevant to the security of networks and information systems.

Examples of appropriate standards may include ISO/IEC 27001 on information security management systems and ISO/IEC 22301 on business continuity management systems, and any other related standards.

Are there any documentation requirements?

Yes. The DSP Regulation requires you to ensure that you have ‘adequate’ documentation available to demonstrate compliance with the above security elements. You will also need to make this documentation available to the ICO if we need to verify your compliance, eg during the investigation of an incident or a follow-up inspection.

If you do not have the required documentation, we can undertake regulatory action against you.

Requirement checklist

Security of systems and facilities

Incident handling

Business continuity management

Monitoring, auditing and testing

Compliance with international standards

At a glance

• NIS is overseen by a number of ‘competent authorities’ that monitor different sectors. The ICO is the competent authority for RDSPs.
• In many cases both OES and RDSPs are also data controllers and/or processors under the UK GDPR, meaning that the ICO also has regulatory functions in that context. 
• The ICO has a range of enforcement powers that we can use where appropriate.
• We can issue information notices that require you to provide us with certain information.
• We can issue enforcement notices that require you to take, or refrain from taking, particular steps or actions.
• We can issue monetary penalties if you contravene NIS, up to a maximum of £17 million in the most serious cases.
• We also have powers of inspection – we can inspect you ourselves, appoint a third party, or require you to appoint a third party.

In brief

• How is NIS enforced?
• Who are the other competent authorities?
• What enforcement powers does the ICO have?
• What are the levels of penalties?

How is NIS enforced?

NIS is overseen by different ‘competent authorities’ whose general function is to monitor the application of the Regulations. The UK has sector-specific competent authorities, with the ICO being responsible for overseeing relevant digital service providers.

Who are the other Competent Authorities?

A list of the Competent Authorities is included in Schedule 1 of NIS. With essential services, depending on the sector there may be different competent authorities within each part of the UK.

If you are an OES reading this guidance we encourage you to check the website of your competent authority for advice specific to your circumstances, including thresholds for identification and any specific security or incident reporting requirements.

What enforcement powers does the ICO have?

We have a range of actions that we can take, including;

• information notices;
• enforcement notices;
• penalty notices; and
• inspection powers.

Information notices

Under Regulation 15(3), the ICO may serve an ‘information notice’ (IN) on you where we reasonably require information to enable us to assess:

• the security of your network and information systems; and
• the implementation of your security policies, including any inspections conducted.

The IN will describe the information we require, the reasons why we require it, how you should provide it to us and the time period. If you don’t comply with an IN, we can issue you with an enforcement notice.

Enforcement notices

Under Regulation 17(2), we may serve an enforcement notice (EN) on you if we have reasonable grounds to believe you have failed to:

• fulfil your security obligations under Regulation 12;
• notify us of a security incident under Regulation 12(3);
• comply with your notification obligations in Regulation 12(5);
• notify the public about any incident, if we have required you to do so under Regulation 12(12);
• comply with an Information Notice under Regulation 15; and
• complying with the inspection requirements of Regulation 16(2) and (3).

If you don’t comply with the steps in the EN, you run the risk of the ICO imposing a penalty on you.

Inspections

Under Regulation 16(2), the ICO has the power to conduct an inspection to see if you have fulfilled your security obligations. Our inspection power allows us to:

• conduct an inspection ourselves;
• appoint someone to conduct an inspection on our behalf; or
• require you to appoint someone approved by us to conduct an inspection.

You also have to take steps to assist the inspection, as listed in Regulation 16(3). These steps include:

• paying for the ‘reasonable costs’ of the inspection;
• co-operating with the inspector(s);
• providing the inspector(s) with ‘reasonable access’ to your premises;
• allowing the inspector(s) access to documents and information that may be relevant; and
• allowing the inspector(s) access to any individual that may be relevant.

If you don’t take these steps, you run the risk of the ICO imposing a penalty on you.

Penalty notices

Regulation 18(2) gives the ICO the power to serve a penalty notice on you in certain circumstances. We will first serve you with an EN directing you to take certain steps. If you fail to take such steps, or we are not satisfied with your explanation as to why you do not need to take them, we may then issue a penalty notice.

The penalty notice will specify:

• the reasons for imposing a penalty;
• the sum that we are imposing;
• the date of the notice;
• the date by which you must pay the penalty;
• how you can appeal against the notice; and
• the consequences of failing to pay within the period specified.

Under Regulation 18(5) we are required to issue a penalty that is appropriate and proportionate to the failure. For more information on how the ICO undertakes regulatory action including imposing penalties, see our Regulatory Action Policy (pdf).

What are the levels of penalties?

There are different penalties depending on the nature of any ‘material contravention’. A material contravention is where you have failed to take steps within a particular time period to remedy any issues that we have identified, such as compliance with your security obligations.

Importantly, penalties in NIS are not just imposed if an incident takes place. You receive the penalty for the contravention, and this may include failure to comply with an EN or failure to co-operate with an inspection.

Report a NIS incident 

Relevant Digital Service Providers need to notify the ICO of an incident under the NIS Regulations.

Report a NIS incident

At a glance

• You are required to notify the ICO of any incident that has a substantial impact on the provision of your services.
• When assessing whether you need to notify, you have to take into account a number of factors, including the number of users affected, the duration of the incident, the geographical spread, the extent of the disruption and the extent of the incident’s impact.
• The DSP Regulation provides further details on thresholds and parameters relating to these factors.
• You must notify the ICO without undue delay and not later than 72 hours of becoming aware of any incident, where feasible.
• We have developed a reporting tool that you can use to notify us of NIS incidents. You should also consider notifying the National Cyber Security Centre at the same time.

In brief

• What is a NIS incident?
• Is a NIS incident the same as a personal data breach under the UK GDPR?
• When must we notify the ICO of a NIS incident?
• What information must we provide?
• How do we determine if we need to notify?
• What does the ‘number of users affected’ mean?
• What does the ‘duration of the incident’ mean?
• What does the ‘geographical spread with regard to the area affected’ mean?
• What does the ‘extent of the disruption’ mean?
• What does the ‘extent of the impact’ mean?
• What thresholds apply?
• Do we need to notify anyone else?
• Do we need to notify the public?
• What are the notification requirements when an OES relies on an RDSP’s services?

What is a NIS incident?

Regulation 1(1) of NIS defines an ‘incident’ as:

‘Any event having an actual adverse effect on the security of network and information systems.’

Read in conjunction with the definition of ‘security of network and information systems’, this is broadly in line with existing standards in information security, such as the definition of ‘incident’ within NIST Special Publication 800-53:

‘An occurrence that actually or imminently jeopardizes, without lawful authority, the confidentiality, integrity or availability of information or an information system’

Is a NIS incident the same as a personal data breach under the UK GDPR?

Not necessarily. NIS concerns computer systems and the digital data stored and processed within them. The UK GDPR concerns the processing of personal data.

The digital data is that which is connected to the operation, use and maintenance of your digital service. However, this may include personal data. Also, the NIS incident may itself lead to a personal data breach, depending on the type of attack. The NIS incident may be the initial intrusion that disrupts your service, whilst the personal data breach could follow as a result of that intrusion.

In practice, it depends on the circumstances. However, if a personal data breach does occur, you have to notify the ICO under the UK GDPR, not NIS. Our NIS reporting tool allows you to specify whether personal data has also been compromised in an incident.

We have provided more information on the links between the UK GDPR and NIS in the next section of the guide.

When must we notify the ICO of a NIS incident?

You are required to notify the ICO of any incident without undue delay and not later than 72 hours of becoming aware of it. This broadly aligns with the reporting requirements for personal data breaches under the UK GDPR. 

Only RDSPs are required to notify the ICO of a NIS incident. If you are an OES, you need to notify the competent authority for your sector.

What information must we provide?

Regulation 12(5) specifies that your notification must include:

• your organisation’s name and the types of digital service(s) you provide;
• the time the incident occurred;
• the incident’s duration;
• information about the incident’s nature and impact;
• information about any cross-border impact; and
• any other information that may assist the ICO.

The information about any cross-border impact must be sufficient to enable us to determine its significance.

We understand that in the immediate aftermath of an incident, you may not have all the necessary information required and will only learn this as your investigation unfolds. However, you still have to notify us that an incident has taken place. You can follow up with additional information resulting from your investigation as it becomes available and without undue delay.

We have developed a reporting form for you to use to report a NIS incident. It includes fields to fill in with all of the above information.

How do we determine if we need to notify?

You need to assess whether the incident caused a ‘substantial impact on the provision’ of your digital service(s) in order to decide if you need to notify.

Regulation 12(7) provides further details on how you can make this determination. When determining the impact of an incident you must take into account:

• the number of users affected by the incident, in particular those relying on the service for the provision of their own services;
• the duration of the incident;
• the geographical spread with regard to the area affected;
• the extent of the disruption of the functioning of the service; and
• the extent of the impact on economic and societal activities.

You must also have regard to the incident thresholds we set out in this guidance.

Article 3 of the DSP Regulation provides further details on how you should consider factors such as number of users, duration, and extent of the disruption. Additionally, Article 3(6) says that when considering these factors, RDSPs:

‘shall not be required to collect additional information to which they do not have access’

It is important to note that these requirements only apply to RDSPs. If you are an OES, you should consult any relevant incident notification guidance from your competent authority.

What does the ‘number of users affected’ mean?

Article 3(1) of the DSP Regulation requires you to be in a position to estimate:

• the number of affected persons you have a contract with (this includes both individuals and organisations); or
• the number of affected users determined by reference to previous traffic data.

What does the ‘duration of the incident’ mean?

Article 3(2) of the DSP Regulation states that this refers to the period of time from the disruption of the service until its recovery.

You must assess the disruption on the basis of availability, authenticity, integrity and confidentiality of the digital data you process.

What does the ‘geographical spread with regard to the area affected’ mean?

Article 3(3) of the DSP Regulation clarifies that this refers to your ability to identify whether the NIS incident affects the provision of your services in other specific areas of the United Kingdom.

In practice, your service may be available UK-wide and therefore this factor may not always be relevant. However, if you provide digital services on a more local scale, you should assess the extent to which the incident affects the provision of your service in the areas you offer it.

What does the ‘extent of the disruption’ mean?

Article 3(4) of the DSP Regulation requires you to be able to measure whether the NIS incident has impaired one or more of the following:

• the availability of data or related services;
• the authenticity of data or related services;
• the integrity of data or related services; and
• the confidentiality of data or related services.

What does the ‘extent of the impact’ mean?

Article 3(5) of the DSP Regulation requires you to be able to conclude whether the incident has:

‘caused significant material or non-material losses for the users in relation to health, safety, or damage to property.’

You should reach this conclusion by indications such as the nature of your contractual relations with your customers (ie the type of customer your digital service serves) and, where appropriate, the potential number of affected users.

What thresholds apply?

When you assess the factors above, Regulation 12(7)(b) says you must also have regard to the thresholds this guidance details. These thresholds are where the ICO considers a NIS incident to have a significant impact on the provision of your digital service.

You should consider the impact of an incident to be substantial when at least one of the following thresholds is met.

You are only required to notify the ICO where the incident meets one of these thresholds. However, we encourage you to provide voluntary notification reports of other incidents.

It is also important to understand that if the NIS incident results in a personal data breach, the UK GDPR’s breach notification requirements apply whether or not the incident meets one of these thresholds. This requires you to assess whether the personal data breach could result in a risk to the rights and freedoms of individuals.

This may mean you are required to notify the ICO of the personal data breach, even if you may not have to tell us about the NIS incident.

Do we need to notify anyone else?

Although the ICO is required to share incident notifications with the National Cyber Security Centre, you should consider voluntarily reporting the incident to them as well. This is particularly the case if you determine that you require the NCSC’s support to manage the incident.

The NCSC will provide advice, guidance, and (depending on resources) support for incidents that:

• may result in significant loss of data critical to the ongoing operation of your organisation;
• disrupt essential services (if you are providing a digital service for an OES); or
• indicate unauthorised access to, or the installation of malicious software on, key systems where you are unable to resolve these issues yourselves.

If you require this level of support, you should mark your report as ‘FOR ACTION’.

Our incident reporting tool provides further information on how you can notify the NCSC, including instances where you may not require direct support but wish to inform them of an incident so they can provide wider advice on cyber threats.

Depending on the nature of the incident, you may also wish to notify other organisations such as the National Crime Agency and Action Fraud.

Do we need to notify the public?

We may take the view that public awareness about a particular incident is necessary, eg for the public interest. In these cases we will consult with you first, but we may decide either to inform the public ourselves, or direct you to do so by means of an Enforcement Notice.

We will also consult the NCSC when making these decisions.

What are the notification requirements when an OES relies on an RDSP’s services?

An OES may rely on an RDSP to provide its essential service. An incident that has a substantial impact on the services RDSPs provide may therefore also have a knock-on impact on the continuity of the OES’s own services.

Regulation 12(9) says that where an OES does rely on an RDSP, the OES must notify its designated competent authority in writing about

“any significant impact on the continuity of the service it provides caused by an incident affecting the RDSP without undue delay”

At a glance

• The GDPR and NIS address different things – the UK GDPR concerns personal data, whilst NIS concerns the security of systems.
• However, there is considerable overlap between the two due to the UK GDPR’s provisions on security and the likelihood that most organisations covered by NIS will also be data controllers (or even data processors).
• The ICO is the UK’s data protection regulator. This means that we already regulate both OES and RDSPs, but only in the context of data protection law where they are data controllers.
• NIS requires OES and RDSPs to notify their competent authorities if an incident takes place. Where an incident is, or becomes, a personal data breach, then you also need to inform the ICO separately from our function as the competent authority for RDSPs.

In brief

• Are NIS and the UK GDPR the same?
• Does the ICO regulate OES?
• Can a NIS incident also be a personal data breach?
• Who do we report to?
• Can we get fined twice?

Are NIS and the UK GDPR the same?

No. The two laws are intended to address different things. NIS concerns the security of network and information systems and the digital data within them whilst the UK GDPR concerns the processing of personal data.

Whilst security and data protection go hand in hand, they’re also not the same. In this sense, NIS is actually broader than the UK GDPR, as it covers ‘digital data’, which does not just include personal data but any data relating to the network and information system and its provision and continuity.

Additionally, ‘digital data’ by default means that any manual data is not covered by NIS, unlike the UK GDPR where manual data is covered where such data forms part of, or is intended to form part of, a  filing system.

At the same time, NIS applies to fewer organisations than the UK GDPR. Unless you are an OES or RDSP, NIS will not apply to you – your security obligations will instead come from the GDPR.

Does the ICO regulate OES?

Not in the context of NIS. However, both OES and RDSPs are likely to be controllers and in some cases processors under data protection law. Where personal data is processed, the ICO has a regulatory function – but this concerns the UK GDPR, not NIS.

In practice, there may be considerable overlap due to the UK GDPR’s security requirements and those of NIS. For example, the UK GDPR also includes the classic information security concept of the ‘CIA triad’. This means that there’s a much greater alignment between the requirements of the UK GDPR and the NIS Directive.

The UK GDPR applies to any organisation processing personal data. NIS only applies to OES and RDSPs.

Can a NIS incident also be a personal data breach?

Yes. It is likely that organisations covered by NIS are controllers or processors under the UK GDPR. As such, it is possible that a NIS incident could also be a personal data breach as defined by the UK GDPR.

The NIS Directive recognises this in Recital 60, which says:

‘Personal data are in many cases compromised as a result of incidents. In this context, competent authorities and data protection authorities should cooperate and exchange information on all relevant matters to tackle any personal data breaches resulting from incidents.’

Regulation 3(3)(f) of NIS specifies that competent authorities must:

‘consult and co-operate, as appropriate, with the Information Commissioner in addressing incidents resulting in breaches of personal data’

The reason for this is that in practice, personal data may be processed on network and information systems, particularly for both essential and digital services.

Firstly, whilst NIS concerns ‘digital data’ relating to the operation, use and maintenance of computer systems, this data could include personal data depending on the circumstances. This could mean that the NIS incident is also a personal data breach simultaneously.

Secondly, a NIS incident may lead to a personal data breach - for example, where a cyber-attacker has undertaken an initial attack on a service and subsequently compromises personal data that the service processes, such as customer information. The initial attack and its disruptive effect could comprise the NIS incident, whilst the subsequent unlawful access of personal data could comprise the personal data breach.

Not every NIS incident will cause a personal data breach. It may be useful to remember that, in information security terms, all personal data breaches are considered incidents, but that not every incident will involve a personal data breach.

Who do we report to?

Depending on your circumstances, you may have to report an incident to both your competent authority (under NIS) and the ICO (under the GDPR). If you are an RDSP, our NIS incident reporting tool allows you to indicate whether personal data has also been compromised.

The UK GDPR is an entirely separate piece of legislation from NIS. If you are covered by NIS but are a controller or processor then the UK GDPR’s obligations apply to you in addition to your requirements under NIS. 

You may have to notify two separate regulators about the same incident – your NIS competent authority, and the ICO (if the same incident is also a personal data breach). You have to make both notifications without undue delay and within 72 hours of becoming aware, where feasible. If you are a data processor, you must notify your controller without undue delay so that it can notify the ICO within 72 hours, as required by the UK GDPR.

It is however possible that you may not know if the NIS incident is a personal data breach immediately. For example, after notifying your competent authority within 72 hours, your subsequent investigation discovers that the incident has also led to a personal data breach. At this point, you have 72 hours to notify the ICO.

Can we get fined twice?

As the UK GDPR and NIS are separate laws, it is possible that you may be subject to regulatory action under both. However, any action might relate to different aspects of the incident and the potential infringements of the specific laws in question.

The ICO will work closely with other competent authorities and the NCSC so we will maintain a common approach. However, if a NIS incident is also a personal data breach, we have specific regulatory functions that we have to follow which are entirely separate to the NIS Regulations.

Any regulatory action we take, be it under NIS, the UK GDPR, or both, will be appropriate and proportionate to the failure identified.

At a glance

• The NCSC is the UK’s technical authority for cyber threats. It is part of the Government Communications Headquarters (GCHQ) and has several roles in NIS.
• It acts as the ‘computer security incident response team’ or CSIRT. This means it monitors incidents, provides early warnings, disseminates information, conducts cyber threat assessments and provides general technical support to competent authorities.
• It is also the ‘single point of contact’ (SPOC). In this role it receives information on NIS incidents from all competent authorities and co-ordinates with its counterparts in other Member States.
• The NCSC has published a ‘NIS guidance collection’, primarily for OES.

In brief

• What is the National Cyber Security Centre (NCSC)?
• What role does the NCSC have?
• How does this relate to the ICO’s functions in respect of the GDPR?
• What guidance has the NCSC released about NIS?

What is the National Cyber Security Centre (NCSC)?

The NCSC is the UK’s ‘technical authority’ for cyber incidents. It is part of GCHQ, one of the UK’s security services, and was formed in 2016 to provide a unified national response to cyber threats. It was created out of a number of pre-existing organisations which included:

• GCHQ’s ‘Communications-Electronics Security Group’ (CESG), which was the national technical authority for information assurance and advises organisations on how to protect their network and information systems from threats;
• CERT UK, the former a computer security incident response team;
• the Centre for Cyber Assessment (CCA), also part of GCHQ, responsible for providing cyber threat assessments to UK government departments; and
• the cyber functions of the Centre for the Protection of the National Infrastructure (CPNI).

The UK’s National Cyber Security Strategy 2016-2021 outlines the Government’s intent behind setting up the NCSC. The strategy will also be used as the ‘NIS national strategy’ as required under Regulation 3.

What role does the NCSC have?

NIS does not mention the NCSC by name – a number of functions are assigned to GCHQ itself. These are carried out by the NCSC. It acts as the ‘single point of contact’ (SPOC) and ‘computer security incident response team’ (CSIRT).

Single point of contact (SPOC)

The SPOC’s role largely concerns cross-border co-operation where incidents affect more than one Member State. It also produces reports on incident notifications. 

Regulation 4 of NIS designates the NCSC as the SPOC. It is required to:

• liaise with SPOCs, CSIRTs and competent authorities in other countries to ensure cross-border co-operation;
• consult and co-operate with relevant law enforcement authorities; and
• co-operate with the competent authorities when they undertake enforcement actions.

The SPOC must also submit reports to a ‘Cooperation Group’ at European level. These are based on annual reports that competent authorities provide to the SPOC about the number and nature of any NIS incidents.

Computer Security Incident Response Team (CSIRT)

NIS assigns the CSIRT a range of functions. Regulation 5 designates the NCSC as the CSIRT. In this role, it is required to:

• monitor incidents;
• provide early warning, alerts, announcements and dissemination of information about risks and incidents;
• respond to incidents notified to it by competent authorities;
• provide dynamic risk and incident analysis and situational awareness;
• participate in the ‘CSIRTs network’ at European level;
• establish relationships with the private sector;
• promote the adoption and use of common or standard practices for incident and risk handling procedures, and incident, risk and information classification schemes; and
• co-operate with the competent authorities when they undertake enforcement actions.

Competent authorities may share information with the NCSC where this is necessary for the requirements of NIS. This has to be limited to information that is ‘relevant and proportionate’ to the purpose of the sharing.

Under Regulation 12(8), the ICO is also required to share incident notifications with the NCSC as soon as reasonably practicable.

How does this relate to the ICO’s functions in respect of the UK GDPR?

For most organisations, only the UK GDPR will apply. If you are not an OES or an RDSP, then you have no NIS obligations. However, for OES and RDSPs both laws may apply at the same time.

The ICO is the UK’s supervisory authority for the UK GDPR, with powers and functions as specified in that legislation. This means that wherever organisations covered by NIS also process personal data, we have a different, yet related, set of regulatory functions.

The NCSC is the UK ‘technical authority’ for cyber issues. Although it does not have a regulatory function in respect of the UK GDPR, where cyber breaches take place there is a clear link between what we do in enforcing the GDPR and what the NCSC does in the wider ‘cyber landscape’.

The NCSC’s specific functions under NIS, coupled with the ICO’s role as the competent authority for RDSPs, simply serve to reinforce this link.

The UK Government’s ‘Cyber Security Regulation and Incentives Review’ in 2016 stated that the UK GDPR would be the main means by which ‘cyber hygiene’ in the UK economy would be improved, in concert with NIS for OES and RDSPs. The review also outlined the Government’s intent for the ICO and the NCSC to collaborate, given the overlap in the legislation.

Since then, the ICO and the NCSC have worked closely together on both NIS and the UK GDPR, and we expect continued collaboration in the future.

What guidance has the NCSC released about NIS?

The NCSC has developed the Cyber Assessment Framework or CAF, which is intended for use by organisations that operate within UK critical national infrastructure (CNI) as well as operators of essential services under NIS.

The CAF consists of 14 cybersecurity and resilience principles, along with guidance on how to apply them. The principles are aimed at helping organisations achieve and demonstrate an appropriate level of cyber resilience in the context of the essential services they provide.

The principles define top-level outcomes that describe good cybersecurity for organisations that perform essential functions.

The CAF is designed primarily for operators of essential providing CNI. However, if you are an RDSP, the principles-based approach in the CAF may still assist you when determining and evaluating your security measures.