UK NIS Regulations: enforcement, & future

For both OESs and DSPs the UK NIS Regulations have barely been enforced, but change is coming,  including to bring MSPs within scope. (OESs are operators of essential services, basically critical infrastructure service providers, while DSPs are "digital service providers": cloud computing service providers, online marketplaces or online search engines only, not other providers of digital services in the broad sense). 

The Second Post-Implementation Review of the Network and Information Systems Regulations 2018 (PDF), 4 July 2022, revealed this and other interesting information:

1. NIS incident reporting hasn't actually been happening: “…the system does not appear to be working. As of this review, competent authorities have received little-to-no reports, despite other sources of information, such as the Breaches Survey, indicating a prevalence of incidents within the wider economy and society.”
   
   
2. NIS enforcement has been minimal; no NIS fines (penalty notices) have been imposed so far: 
1. Only 2 competent authorities have enforced to date, "which raises the question of "is the enforcement regime appropriate?" But, “NCSC has also been informed of one very successful instance of a competent authority carrying out enforcement, which had very positive outcomes, suggesting that the enforcement regime may be appropriate." 
1. Note: it's unclear if the UK ICO, which regulates DSPs under the NIS Regulations, was one of thise two authorities.
2. “…there is evidence from competent authorities to suggest that there are cases where enforcement activities were merited but no action was taken. The use of enforcement tools overall, is much lower than the reported need and so far competent authorities appear to have been less inclined to make use of their regulatory powers." Why, and why not? The reasons are not stated.
3. "There is also a reported concern from regulators that the grounds for enforcement (either via enforcement notices or penalty notices) is not clear enough”…
4. “NIS competent authorities... have additionally reported being very restrictive with their regulatory powers, relying more on regular engagements, inspections, and information notices rather than any binding provisions of the regulations, such as enforcement notices, civil proceedings, or penalty notices.”
5. "Of those who felt the enforcement regime wasn't proportionate, 44% gave other reasons including there is no clear link between the fine levied and the actions that operator of essential services took prior to the incident and the fact that fines result in double jeopardy as there is already a cost relating to a cyber breach."
1. Note: it's interesting that the double jeopardy cited was not the possibility of fines under both GDPR and NIS, which is the key double jeopardy risk in my view (to be addressed in the EU's NIS 2 Directive). The breach costs point is, of course, also relevant to GDPR fines too, but cited only sometimes (in conjunction with remediation costs) in GDPR supervisory authority decisions.
6. The only relevant DSPs who indicated the enforcement regime was not proportionate to the risk of disruption reported feeling that the Regulations were incorrectly applied to DSP organisations in general. (This I agree with, see later below.)
   
7. DCMS will aim to collect annual data from the competent authorities e.g. the number of incidents per year, the number of independent audits of the Cyber Assessment Framework, the number of improvement plans as a result of the Cyber Assessment Framework, the number of information notices issued by the competent authorities, the number and nature of enforcement notices issued by competent authorities, and the number of organisations regulated by sector and also the number of SMEs regulated by sector.


3. NIS Regs' Cyber Assessment Framework: this has allowed experts in competent authorities to review organisations' cyber security arrangements and ensure improvements are made. 67 known operators have received improvement plans (including updating legacy systems and software to reduce vulnerabilities), highlighting Regulations' role in improving cyber security. 
1. Note: the reference was only to "operators". This suggests no DSPs were asked to make any improvements to their cybersecurity under NIS.
   
   
4. NIS Regs generally: effective to drive good cyber security behaviours; "...strong indication that without NIS, cyber security improvements across essential services in the UK would proceed at a much slower pace. ...added benefit of covering a large number of sectors, which is expected to address some of the inconsistencies of managing risks to networks and information systems across sectors...". But, areas of improvement remain, thought to be most appropriately tackled through regulatory intervention, to strengthen and future-proof the regulatory framework.
1. Other regulations or standards mentioned as drivers for improvements in cyber security included: UK General Data Protection Regulations (GDPR) (13 or 86% of relevant digital service providers, 68 or 78% of operators of essential services); ISO27001 (28% of operators of essential services); Cyber Essentials and Cyber Essentials Plus (11% of operators of essential services); as well as other industry standards (33% of operators of essential services).
   
   
5. Areas needing improvement, and future plans: Then-Minister Lopez's associated statement to Parliament on 4 July noted that recommended changes to the NIS Regs were included in the Department for Digital, Culture, Media & Sport's Jan 2022 consultation, Proposal for legislation to improve the UK’s cyber resilience (summarised in my Linkedin post). The outcome of that consultation is to be published "later this year", i.e. later in 2022. Recent UK political events, including her resignation on 6 July, may of course result in delays to the initially-planned timescale. The key areas are:
   
   
1. DSP registration and guidance: 54% of responding DSPs stated it was not easy to identify that their organisations are in scope (this deters registration, and ICO won't be aware of their activities to advise them!).
1. "Further work is required to ensure that the guidance makes it easy to identify whether firms are in or out of scope of the Regulations and to ensure that organisations that need to be included in the regulations are designated."
2. "Registration of digital service providers cannot be left to digital service providers alone... The Government will continue to support the ICO in the work it is already carrying out to identify firms that should be under the Regulations and support them in notifying those organisations of their responsibilities. Both the government and the Information Commissioner, should consider ways to increase awareness of the NIS Regulations with all potential digital service providers." The government should consider options to provide the Information Commissioner with increased information-seeking powers (similar to existing ones available to competent authorities of operators of essential services) to ascertain whether an organisation qualifies as a relevant DSP under the NIS Regulations.
   
   
2. Ensuring the right sectors are caught: managed service providers (MSPs) are not caught currently, but under the Jan 22 consultation they will be. (For other subsectors discussed e.g. BPO, SIEM, analytics & AI, see my Linkedin post, but it seems "While this Post-Implementation Review has not identified any other sectors that need to be included at this time, it has underlined a need for the government to maintain the powers to make such additions in the future.")
   
   
3. Supply chain security: OESs can't monitor supply chains due to lack of supplier cooperation and lack of resources. Action is needed to increase operators’ ability to manage security risks arising from supply chains, particularly suppliers critical to provision of essential services.
1. Proposed power to designate critical dependencies to identify, impose duties, and then regulate certain supply chain organisations that present systemic risks to OESs, due to their market concentration, reliance on those services, or other factors.
1. Comment: could IaaS/PaaS, perhaps even some SaaS providers, be caught both as DSP and as critical dependency? - highest common denominator of compliance required there. Also, could IaaS/PaaS providers that are critical enough, simply be designated as OESs themselves (legislative rules permitting)?
2. DCMS will consider options such as amending guidance to tackle supply chain security concerns, including using standards and certification, such as Cyber Essentials and Cyber Essentials +, to address this issue. But cross-government consultation is needed.
3. Note: see also the Government response to the call for views on supply chain cyber security, Nov 2021.
   
   
4. Capability & capacity of OESs, DSPS, competent authorities: lack of finance/funding or of general resources, more variable among authorities particularly lack of cyber regulator specific training or centralised NIS training (as opposed to GDPR training). Competent authorities also need more resources for effective enforcement. On authorities' resources:
1. DCMS will "commit to persuading those departments to ensure that they meet their legal obligations to fund their NIS oversight. For these, plus those regulators that are not central government departments, DCMS aims to ensure that competent authorities are able to recover the costs of regulation from those being regulated, in line with government policy."
2. Additional ways to improve resource-efficiency will be considered, e.g. promoting collaboration across authorities and with non-NIS authorities such as banking and financial services regulators (for designation of critical dependencies), exploring existing frameworks like CBEST and TBEST to test assumptions and highlight areas for further development.
   
   
5. Incident reporting: thresholds (in statutory guidance) are too high, and base criteria of a reportable incident is too narrow (disruption to the service, cf. impact on NIS) to capture the most high risk incidents risks. To ensure that the right incidents are captured:
1. Authorities should review reporting thresholds and lower if necessary.
2. OESs and DSPs will be required to report all incidents that have a material impact on the confidentiality, integrity, and availability of NIS [note: the well known CIA triad], and [note: I think "or" is intended here?] that have a potential impact on service continuity.
   
   
6. Enforcement: DCMS needs to conduct work to assess why the enforcement regime is not being utilised where it is merited.
   
   
7. Consistency and more robust oversight: greater consistency in regulatory implementation across sectors is required, alongside creation of performance metrics to better measure the impact and effectiveness of the Regulations.
1. DCMS should issue revised and updated guidance to competent authorities, setting out the requirement for a common approach to assessment and performance indicators; explore ways to make such guidance more binding on authorities; and establish a process by which competent authorities report against performance indicators and are held accountable for their performance (indicators could be linked to the delivery of the National Cyber Strategy and its performance framework). 

Note also the related consultation on Data storage and processing infrastructure security and resilience - call for views (press release), including data centre infrastructure, cloud platform infrastructure and MSP infrastructure, which expires at the end of Sunday 24 July 2022.

The next UK NIS Regulations review isn't due for another 5 years.

Comments

Below are my personal views only, but they're based on my practical experience of advising clients on the UK NIS Regulations and EU NIS Directive: both their legal and technical/security teams.

• Incident reporting:
• "There is a lot of uncertainty around the incident response, and which incidents need to be reported...". In my view, this uncertainty is a contributing factor, and guidance is sorely needed, alongside the planned steps mentioned above regarding lowering reporting thresholds and requiring reporting of incidents materially affecting NIS CIA even if not affecting the service.
• However, there's a risk of a tsunami of reports that regulators may not be able to cope with, if every incident "materially" impacting C, I or A has to be notified. It's important to bear this factor in mind when setting the reporting test/thresholds. Again, guidance on "materiality" will be vital.
  
• Awareness, scope, DSPs and non-registration: I hope the government will take the opportunity, post-Brexit, to reconsider the scope of the NIS Regulations beyond just bringing MSPs into scope. In particular, please consider whether and to what extent SaaS providers should be caught by the NIS Regulations.
• The NIS Regulations were binding from 10 May 2018. Guess what else there was in May 2018? Yep, the GDPR. No surprises then that most organisations focused their resources on GDPR rather than NIS compliance, especially with the huge publicity about GDPR fines and hardly anything being said about NIS.
• It's understandable that IaaS/PaaS providers should be subject to the Regulations as DSPs, because many organisations build their own technology infrastructure or customer-facing services on top of those cloud services. I.e., many organisations create their own SaaS services based on third party IaaS/PaaS services, which do constitute technology infrastructure-type services.
• However, automatically and unthinkingly copying out the NIST definition of cloud computing is not the right approach here. Applying NIS laws to SaaS is like applying certain laws to "all websites" when they should actually apply to "website hosting platforms/services". SaaS involves the provision of specific applications or services to end users (like a word processing application online, instead of via an application installed on a local computer). Those applications/services can vary hugely in their scope and purpose. The applicability of NIS requirements ought to depend on the specific type of application/service and its importance to the economy or society (e.g. is the service critical to the provision of an OES's essential service?) - and not just because of its general nature as SaaS. Currently, all SaaS services are technically caught, whether they're used for bill payments or as a forum for pet lovers to discuss their animals. To me, that doesn't seem to make sense.
• As I've previously pointed out, SaaS providers don't always register with the ICO for various reasons.
• Registering puts their heads firmly above the parapet for possible enforcement. Especially as, since Jan 2021, the top £17m tier of fines could be imposed based on serious service outages alone, whereas previously the top tier only applied if the service was important to the economy. If I provided a SaaS service for pet lovers' discussions, which no one could think would harm the economy or society if it went down, I wouldn't want to register and make my service known to the ICO either.
• Saying that SaaS services are caught "only to the extent that they provide a scalable and elastic pool of resources to the customer" just parrots the definition without providing any useful guidance. All cloud services are, by definition, meant to be scalable and elastic. They're not infinitely scalable or elastic, of course; even IaaS/PaaS services impose practical commercial limits on customers' usage, so SaaS services' lack of infinite scalability/elasticity should be a non-point too. But some SaaS providers do argue they're not caught because their service doesn't enable access to a "scalable" and "flexible" pool of shareable computing resources. I have some sympathy here, not because the services really aren't scalable/flexible, but because (as above), given the legislative objective of NIS laws, I feel that it's simply not sensible to try to catch all SaaS services just because they're SaaS, regardless of the exact nature of their services or customers served. Business models are increasingly moving to SaaS, away from software licensing: but there's no legal requirement to have security measures or report vulnerabilities or security issues affecting all software applications regardless of their nature (although many might think that would be sensible). And I've always thought it odd that flexible/scalable services are subject to NIS, when inflexible, non-scalable "classic" hosting platforms are not, even though with the latter their customers are more at risk from availability issues (due to their inflexibility and non-scalability!). Surely it should be the other way round?
• And making all SaaS services register is akin to making all software application manufacturers/distributors register their software. The ICO receives fees from controllers who register for data protection purposes, so there's a benefit to the ICO from that registration. But is the benefit of finding out about all online software applications of whatever type or importance worth the administration and other costs?
• Would introducing a fine for non-registration help? I don't think so, because of the underlying issue I've emphasised regarding the inappropriateness and disproportionality of bringing all SaaS services within scope regardless of their importance to society or the economy (and see later below).
• In my experience, SaaS providers may register if they provide important services to operators. Otherwise, they tend to keep their heads down, and I don't blame them.
• The lack of publicly-reported enforcement of the Regulations is another reason for relative lack of awareness of NIS. 
  
• Capability and enforcement: 
• Certainly as regards DSPs, I've found that many ICO staff aren't familiar with NIS and need NIS training as well as more resources for NIS, e.g. those staffing the helpline number given on the ICO's NIS webpage. As flagged above, some DSPs consider the Regulations were incorrectly applied to DSPs in general, and I agree, possibly because of awareness  and/or knowledge issues.
• The reluctance of many SaaS providers to register, never mind report incidents, is fuelled by the factors I've outlined above, and fear of being subject to the maximum possible fine even though their service may be of minor importance to society or the economy. If they have to bear the costs of ICO investigations too, as is planned, that may drive even more SaaS providers to decide not to register. 
• The bigger risks for non-registering DSPs are monetary penalties for not reporting incidents when they should have, and/or not having the appropriate security measures in place. If they haven't registered and haven't notified incidents, that of course reduces those risks, because the ICO won't know about them! The main risk then is if they report a personal data breach under GDPR and the ICO says, "Aha! We will fine you under NIS too, because you should have reported the incident under NIS!". But, this depends on the ICO's NIS and GDPR enforcement divisions being sufficiently joined up and also trained up (again, the skills/knowledge issue flagged earlier).
  
• Summary: personally, I would recommend:
• Reconsidering the extent to which SaaS providers should be in scope under NIS, if at all.  For example, consider introducing specific thresholds or criteria for SaaS providers to be in scope (Obviously if they are critical suppliers to OESs, or OESs themselves, they should be caught under those proposed changes and be exposed to possible designation as OESs, but that's a separate matter.)
• Reconsidering the extent to which SaaS providers should be subject to the different tiers of NIS monetary penalties or other enforcement, if at all (with the same caveat). Again, consider if different types/tiers of fines or other enforcement should be applicable to SaaS providers or indeed DSPs that aren't OESs or critical suppliers.
• These would help save the ICO's resources too, so they can be directed towards IaaS/PaaS and truly important SaaS providers.
• If less radical changes are to be made, provide much clearer guidance on if/when SaaS providers will be caught by the Regulations and therefore need to register with the ICO.
• Making publicly available the annual data DCMS aims to collect from regulators, particularly enforcement information and levels of fines imposed. This would help to raise awareness and incentivise compliance.
• Requiring the ICO and other regulators to publish the full text of their NIS enforcement and monetary penalty etc notices, but redacted as necessary (including as to OES/DSP names), ideally also listing and linking to them on a centrally-maintained webpage of NIS enforcement action. That would also help raise awareness and incentivise compliance.