Cloud and Other Digital Services Providers – Security & Incident Notification Obligations under the UK NIS Regulations, and GDPR comparison

The UK NIS Regulations,[1]
implementing the NIS Directive,[2]
could involve GDPR-level fines. This article summarises a longer paper with fuller
references.[3]

Background

Passed in mid-2016, the NIS Directive was supplemented in
Jan 2018 by a Commission Implementing Regulation (IR).[4]
The deadline for national implementation was 10 May 2018. At 6 June 2018, only
five Member States including the UK had transposed it fully, and three
partially.[5]

This Directive aims to enhance EU cybersecurity in two main
ways:

·       
Improve EU Member States’ cybersecurity
preparedness and capabilities, by requiring national frameworks for security of
network and information systems (NIS):
national CSIRTs (computer security incident response teams), national single
points of contact (SPOCs) and other national authorities; and better cross-EU
cooperation via an EU-wide cooperation group and CSIRT network; and

·       
Impose security obligations and incident
reporting requirements:

·       
on those the Member State considers to provide,
effectively, critical infrastructure
(operators of ‘essential services’, ‘essential operators’ or ‘OESs’) e.g. utilities, transport, healthcare (banks and comms providers are excluded
in the UK, given existing sectoral regulation), and

·       
with lighter touch, on ‘digital service
providers’ (DSPs): cloud service providers, online marketplaces and online search engines, applying ‘ex
post supervisory measures’ following
evidence of infringement (Art.17). Member States cannot impose ‘further’
security or incident notification requirements on DSPs, without prejudice to
safeguarding national security and law and order (Arts.16(10), 1(6)). No DSP
can be subject to increased liability through notifying incidents (Art.16(3)).

This article does not discuss national cybersecurity, only security
and incident reporting obligations under the NIS Regulations, focusing mainly on
DSPs. It also compares the requirements under the NIS Regulations with those
under the GDPR.

Overview

The Regulations’ definitions mirror the NIS Directive’s
regarding ‘digital service’, ‘digital service provider’ and (somewhat circularly)
‘cloud computing service’: a digital service that enables access to a scalable
and elastic pool of shareable computing resources (Reg.1(2)).

All cloud service providers are DSPs: IaaS, PaaS, or SaaS;
public or private. Under reg 14, the
ICO is their ‘competent authority’. ‘Relevant’ DSPs must register with it by 1 Nov 2018 or within three months of becoming
‘relevant’ (see below). The government expects annual fees will be levied. The
Regulations do not cover this, so additional legislation appears likely.

The government considers SaaS ‘would likely exclude most
online gaming, entertainment or VOIP services, as the resources available to
the user are not scalable, but may include services such as email or online
storage providers, where the resources are scaleable’.[6]
This seems wrong, given cloud computing’s definition and Rec.17: ‘resources
such as networks, servers or other infrastructure, storage, applications and
services’. The services mentioned epitomise applications and services that need
to be, and generally are, scalable. Generally,
the EU’s policy decision seems odd – why apply the Directive to scalable
services (with better availability), yet exclude traditional online applications/services
that are non-scalable and therefore more
vulnerable to availability problems, given the Directive’s service/business
continuity objective?

Territorial scope

The Regulations catch only non-SME[7]
DSPs who:

·       
provide digital services in the UK, and

·       
have a UK
head office (or nominated a UK-’established’
representative) (Reg.1(3)(e)).

These are ‘relevant digital service providers’ (‘RDSPs’).

The NIS Directive’s ‘offering’ concept (Rec.65, ‘provide’ in
the Regulations) corresponds to GDPR’s Rec.23. Both envisage ‘targeting’ EU
persons.

If a DSP not ‘established’ in the EU offers digital services
in the EU, it ‘shall’ designate an EU representative in a Member State where it
offers services (Art.18(2)); thereafter, it is under the jurisdiction of only
that Member State for those services, within the EU – i.e., a ‘one-stop-shop’. Non-EU
DSPs should therefore consider where to appoint their EU representative. The
role and impact of appointing a representative under this Directive (Art.4(10),
18(3), Rec.65) is as under the GDPR: communicating with national competent
authorities or CSIRTs, and acting for the DSP e.g. reporting incidents.

Where a DSP with UK NIS has its ‘main establishment’ or
representative in another Member State, the ICO must cooperate with other
Member States’ authorities to secure effective supervision, including ‘receiving’
requests for enforcement action (Reg.13). Unfortunately, the Regulations as
drafted give the ICO power over RDSPs – but not non-’RDSP’ DSPs with UK NISs.

Security obligations
of RDSPs – NIS Directive vs. GDPR

The table compares DSP obligations regarding security
measures under the NIS Directive and GDPR.

 

Issue	NIS Directive / UK NIS Regulations	GDPR
Risks targeted	Risks to NIS security and service continuity, including associated data	Risks to personal data and individuals, particularly privacy
Application	‘network and information systems’ (NIS): electronic communications networks; interconnected devices that automatically programatically process digital data; and digital data processed via those networks or devices for their operation or maintenance (Art.4(1), Reg.1(2)). Can include personal and non-personal data. Trickier threshold issue: when is digital data processed for purposes of operation or maintenance? A broad interpretation seems likely.	‘personal data’ Art.4(1): any information relating to an identified or identifiable natural person (‘data subject’)…
Security	‘security of network and information systems’: defined in relation to ability to resist compromise of availability, authenticity, integrity or confidentiality of stored, transmitted or processed data or related services accessible by NIS (Art.4(2))	The GDPR imposes obligations regarding ‘security’ (Art.32) and ‘integrity and confidentiality’ (Art.5(1)(f)) without defining them. Its security provisions largely address personal data’s confidentiality and integrity, but also mention availability, resilience and recovery.
Level	Under both, measures must be ‘appropriate’ to the relevant risks. The NIS Directive (but not GDPR) requires measures to be ‘proportionate’.
Testing and evaluation	Mentioned by both
Accoun-tability	Not mentioned specifically. However, ‘adequate documentation’ is required, so authorities can verify compliance (IR Art.2(6)).	Ability to prove compliance through documentation and other evidence (Art.5(2)), implementing appropriate measures and policies (Art.24).
Inter-national standards	Measures must ‘take into account’ compliance with international standards (Art.16(1)(e)).	Adherence to approved codes of conduct/certifications may be ‘an element’ to show compliance with security obligations. However, codes or certifications, even to international standards, cannot evidence GDPR compliance until the standard is approved for GDPR purposes (Arts.40-43).

 

NIS-related security requirements (detailed by the IR and ENISA)
are more specific. Accordingly, DSPs could decide to follow NIS-required
measures. Adopting best practices to recognised industry standards and
implementing more rather than less secure measures can only benefit the
security of NIS and personal data, so some may choose the ‘highest common denominator’,
but noting inevitable trade-offs between security and costs/usability.

DSP notification of
incidents

DSPs must notify (Art.16(3)):

·       
the competent authority or CSIRT (ICO, in the UK),
including information to enable it to determine any cross-border impact’s
significance (Art.16(3), Regs.12(3), 12(6)(b))

·       
‘without undue delay’ – in the UK, ‘without
undue delay and in any event no
later than 72 hours after the RDSP is aware’ (Reg.12(6)(a))[8]

·       
of any ‘incident’ – any event having an actual adverse effect on NIS security
(Art.4(7), Reg.1(2))

·       
having a ‘substantial
impact’ on the provision of its digital service offered within the EU (not
just the relevant Member State), taking into account certain parameters/factors
(Art.16(4), Reg.12(7)):[9]

o   number
of users affected, particularly users relying on the service for their own
services

o   incident
duration

o   geographical
spread (area affected)

o   extent
the service’s functioning was disrupted; and

o   extent
of impact on economic and societal activities

Substantial impact is deemed (IR Art.4; Reg.12(7)(b)) if:

·       
the service is unavailable for over 5m ‘user-hours’
(number of affected users in the EU for a duration of 60 minutes);

·       
loss of integrity, authenticity or
confidentiality of data or related services offered by, or accessible via, the
NIS affecting over 100,000 users in the EU;

·       
risk created to public safety, public security
or of loss of life; or

·       
material damage caused exceeding €1m to at least
one EU user.

A DSP must notify only if it ‘has access to the information
needed to assess the impact of an incident against… parameters’, but need not
collect additional information where it has no access.

The Commission may promulgate notification formats and
procedures (Art.16(9)), but hasn’t yet done so.

Reg.12(5) stipulates what information RDSPs should provide, reproducing
Reg.11(3) (notifications by OESs) without
adaptation for RDSPs. May 2018 corrections did not address this drafting error.
Presumably it will be interpreted appropriately until it is corrected, e.g. the
ICO’s NIS
notification form.

This table compares notification obligations under the
Directive and GDPR.

 

	NIS Directive / Regulations	GDPR – controller	GDPR – processor
Focus	Actual adverse effect, and substantial impact on digital services	Confidentiality, integrity and risks to individuals – but also availability
Notify what?	‘Incident’—any event having an actual adverse effect on the NIS security (including systems, devices, data whether personal or not)	‘Personal data breach’—a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed (Art.4(12))
Notify who, and in what circumstances?	ICO – if ‘substantial impact’ on DSP’s digital service in EU	ICO – unless breach ‘unlikely to result in a risk to the rights and freedoms’ of individuals (Art.32(1)) Affected individuals – if ‘likely to result in a high risk’ to their rights and freedoms (Art.33(1)); with exceptions (Art.34(3)).	Controller – any personal data breach
Notify when?	Without undue delay and [Regulations only] in any event no later than 72 hours after the RDSP is aware that an incident has occurred	Without undue delay and, where feasible, not later than 72 hours after having become aware of it	Without undue delay

 

DSPs and essential
operators

An OES whose essential service’s provision relies on a DSP (cloud
seems most relevant here) must notify its competent authority of any ‘significant
impact’ on service continuity from an incident affecting the DSP (Art.16(5), Reg.12(9)). Failures
affecting NIS of e.g. billing or payment services could affect essential
services, the UK noted.

The NIS Directive provides no deadline. UK OESs must notify
such an incident ‘as soon as it occurs’ (Reg.12(9)). ‘It’ must mean significant
impact, not incident, otherwise OESs would have to notify incidents before their significance can be
assessed! Guidance on this issue is needed.

DSPs are not statutorily-obliged to notify incidents to OES
customers. So, given their own notification obligations, OESs whose essential
services rely on DSPs should update
their contracts requiring incident notification by their DSPs. They also
need post-DSP notification policies/processes.
Negotiations on scope, liability and indemnities are inevitable, and
insurance’s importance will increase. Difference sectors might take different
approaches, so the government urged OESs to consider NCSC guidance on
supply chains.

ICO powers

The ICO has wide powers (Regulations pt.5): information
notices, inspections (including by third parties), enforcement notices, and (if
an enforcement notice was not properly complied with or the ICO considered
representations made were unsatisfactory) ‘appropriate and proportionate’ penalty
notices with ceilings as follows:

 

£1,000,000	Contraventions the ICO determines could not cause a ‘NIS incident’ (defined as having significant impact on continuity of an OES’s essential service (Reg.11(1)), so again inappropriate to DSPs?)
£3,400,000	‘Material contravention’ (not complying or properly rectifying non-compliance with security/notification obligations) it determines has caused, or could cause, an incident resulting in reduction of the RDSP’s service provision for a ‘significant’ time period
£8,500,000	Material contravention it determines has caused, or could cause, an incident resulting in disruption of the RDSP’s service provision for a ‘significant’ period
£17,000,000	Material contravention it determines has caused, or could cause, an incident resulting in immediate threat to life or significant adverse impact on the UK economy.

 

RDSPs may request independent review of penalty decisions (suspended
until reviewed, or request withdrawn) (Reg.19).

‘Action’ against DSPs must be ‘ex post’, following evidence that
they infringed their NIS obligations (Art.17). However, only enforcement
notices are conditioned on ‘reasonable grounds to believe’ there was
non-compliance. Information notices may be served, and inspections conducted, seemingly
at any time for any reason, and RDSPs must pay the ICO’s ‘reasonable costs’ to
boot (unlike under the GDPR). Arguably this contravenes the Directive’s ‘light
touch’ requirement.

Inspections may extend to cloud datacentres, although
frequent physical inspections may jeopardise security and can only confirm
physical, not logical, security. Appointed inspectors need not be
suitably-qualified independent experts under non-disclosure obligations.[10]
Similarly, ‘independent’ reviewers of penalty decisions, appointed by the ICO, need
not be suitably-qualified experts.

The ICO must share incident notifications with GCHQ and
other affected Member States’ authorities report annually to GCHQ (but not the
public?) on RDSP notifications. It may share information with other UK/EU
authorities as ‘relevant and proportionate’. Relevant authorities must ‘preserve
the digital service provider’s security and commercial interests’ and ‘the
confidentiality of the information provided’ (Arts.16(6), 1(5)). But UK
authorities are simply ‘not required’ to share confidential information or
information which may prejudice OES or RDSP security or commercial interests
(Reg.16(2)). Again, does this implement the Directive properly?

The ICO or CSIRT, after consulting the RDSP and each other,
may inform (or require the RDSP to inform) the public, if it considers public
awareness is necessary to prevent or manage the incident or is in the public
interest (Art.16(7), Reg.12(12)-(13)). This includes the ICO (but seemingly not
the CSIRT) publicising incidents affecting digital services in another Member State (Reg.12(14)). Naming
notifying RDSPs has major commercial and reputational implications and could amplify
security risks, but the government rejected requests for anonymity.

Summary

Practicalities:

·       
DSPs with UK head offices providing digital
services in the UK must register with
the ICO by 1 November 2018; registration
fees are likely.

·       
Non-EU DSPs should consider where, of the Member
States where they provide digital services, to designate a representative for EU ‘one-stop-shop’ purposes.

·       
Be prepared for ICO information notices and/or
inspections, charged to the RDSP.

·       
RDSPs have a tight 72-hour deadline to notify the ICO of incidents with ‘substantial
impact’ on their services, not limited to ‘where feasible’ (cf. GDPR).
Accordingly, RDSPs need policies and
procedures to assess incidents for ‘substantiality’ and notify, all within 72 hours, including under both GDPR and
Regulations.

·       
OESs should update
contracts with DSPs to require notification of incidents at DSPs, and
implement post-DSP notification policies/processes.

The government should update the Regulations to:

·       
Give the ICO appropriate powers over DSPs with
UK NIS (that are not RDSPs).

·       
Correct Reg.12(5) on information DSPs must provide
when notifying incidents.

·       
Clarify how Reg.11(1) penalty notices regarding ‘NIS
incidents’ apply to DSPs.

·       
Clarify Reg.12(9) on when OESs must notify
incidents affecting their DSPs.

·       
(Desirable) Require ICO-appointed inspectors to
be qualified independent experts subject to confidentiality obligations, and
require reviewers of penalty decisions to be qualified experts.

RDSPs could seek to contest the UK’s implementation as defective
because:

·       
The Regulations don’t require UK authorities to
preserve confidentiality, DSPs’ security or commercial interests.

·       
Information notices can be served and/or
inspections conducted, at RDSPs’ cost, ex ante, even absent evidence of
infringement.

The author is Dr W Kuan Hon. Views expressed are
Kuan’s alone and not necessarily those of any organisation with whom she may be
associated.

Licence: Creative Commons BY UK