- Not much time left for cloud providers/critical infrastructure operators to respond - 29 April deadline!
- UK cloud providers face mandatory registration, 72-hour incident notification period and up to £17m fines, etc - see further below.
- Critical infrastructure operators relying on cloud services may be in an impossible position, and should update their contracts before 9 May 2018.
You have till 29 April 2018 to respond to the UK's proposed implementation of the NIS Directive (Directive (EU) 2016/1148 of the European Parliament and of the Council of 6 July 2016 concerning measures for a high common level of security of network and information systems across the Union - supplemented so far by one implementing Regulation).
It has to be implemented nationally by 9 May 2018. That's right, even earlier than the GDPR (General Data Protection Regulation, which from 25 May 2018 applies directly in all EU Member States including the UK, and has nabbed most of the attention in the media and tech community).
The UK conducted a consultation in Aug 2017 (with impact assessment), and in Jan 2018 published an analysis of consultation responses and its own policy response.
But in March 2018 it then launched a separate targeted consultation just on digital service providers (DSPs), or "relevant DSPs" (RDSPs) as the UK calls them - with a closing date for responses 29 April 2018.
Cloud providers with EU HQs in the UK may want to respond - whether IaaS, PaaS or SaaS. So may other RDSPs (basically, online marketplaces and search engines). This is because under the UK proposals, among other things:
Registration
RDSPs may have to register with the UK Information Commissioner (ICO), and possibly pay an annual fee.- UK proposal: "We are considering making registration mandatory" (p.5)... "it is expected that the ICO... will levy an annual fee on DSPs, in addition to recovering direct costs involved in any regulatory investigations" (p.12)
Security
RDSPs have obligations under the NISD regarding the "security of network and information systems" and their physical environment
- This means 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
- "Network & information systems" means electronic communications networks; any device or group of interconnected or related devices, if one or more "pursuant to a program" perform automatic processing of digital data; or digital data stored, processed, retrieved or transmitted by the above for their operation, use, protection and maintenance.
- Note: this means any digital data and systems - even if not personal data (unlike under the GDPR)
- See the implementing Regulation for mandatory security elements (including security of supplies, not just access controls etc.); and ENISA's technical guidelines for DSPs' implementation of minimum security measures.
Incident notification
RDSPs must notify the ICO "as soon as possible and in any event no later than 72 hours after the service provider is aware that a security incident has occurred", in cases where the incident has a "substantial impact" on the provision of any of its "digital services" (cloud, online marketplace etc.).
- This absolute 72-hour max. deadline for security breach notification is:
- tougher than under the GDPR, which only requires "without undue delay and, where feasible, not later than 72 hours after having become aware of it" for controllers to report personal data breaches to regulators
- tougher than the deadline for operators of essential services (basically, critical infrastructure providers), where the UK government said (p.12-13) that it would follow the GDPR's deadline.
- An "incident" is any event having an actual adverse effect on the "security of network and information systems" (see above)
- This includes incidents affecting non-personal data
- "Substantial" impact (see implementing Regulation) - factors include: no. of users affected (RDSPs need to implement a way to work that out - contracts or past traffic data), duration, geographical area, extent of service disruption, extent of impact on economic and societal activities, including:
- service unavailable for more than 5m user-hours (no. of affected EU users for 60mins)
- loss of integrity, authenticity or confidentiality of stored, transmitted or processed data or the related services offered by or accessible via a network and information system of the DSP, affecting more than 100k EU users
- incident created risk to public safety, public security or of loss of life, or
- incident caused material damage of over €1m to at least one EU user
- See further ENISA guidelines on incident notification for DSPs.
Penalty for breach
Up to £17m under the UK policy response (p.16) - risk of being fined under separate laws
- "The Government does not believe that ‘double jeopardy’ can be completely removed, without undermining either the NIS Regulations or other UK legislation" - including the GDPR
- A breach includes "failure to cooperate with the competent authority, failure to report a reportable incident, failure to comply with an instruction from the competent authority, failure to implement appropriate and proportionate security measures".
Critical infrastructure services, and contracts
The UK proposes that, if an operator of essential services relies on any RDSP for providing an essential service (which is critical for economic and societal functions - utilities, healthcare, transport, IXPs, DNS service providers, TLD name registries), the operator must notify its competent authority (the authority varies with sector) of any significant impact to the provision of that service caused by a security incident [presumably, at the RDSP] "as soon as the incident occurs".
- This is on top of the requirement for RDSPs to notify the ICO.
- Much headscratching. How can an operator notify "as soon as" an incident at its RDSP occurs, when any "significant impact" may take a while to materialise? Cart and horse problem - surely an incident pre-dates its impact, not vice versa? Operators may wish to invest in time machines...
- Also, how will an operator know about incidents at an RDSP that it relies on for providing its essential service?
- There's no statutory obligation on RDSPs to notify their customers such as operators - a gap I pointed out some time ago.
- So, operators will have to, by 9 May (!):
- Work out if their essential services rely on any RDSP services
- Update their contracts with the "relied on" RDSPs to require RDSPs to notify operators of security incidents at the RDSP "as soon as the incident occurs". (Yes, many false positives are possible)
- Implement mechanisms (which many operators may already have in place) to work how how "significant" an incident's impact is. (Note: the factors for operators to determine impact are similar but not the same as those for DSPs)