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.

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.

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:

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