Cyber Security and Resilience (Network and Information Systems) Bill — Written evidence submitted by Cloudflare (CSRB38)

Cyber Security and Resilience (Network and Information Systems) Bill (24th February 2026)

Primary navigation

Home

Parliamentary business

MPs, Lords & offices

About Parliament

Get involved

Visiting

Education

House of Commons

House of Lords

What's on

Bills & legislation

Committees

Publications & records

Parliament TV

News

Topics

You are hereParliament home page
>
Parliamentary business
>
Publications and Records
>
Hansard
>
Commons Debates
>
Public Bill Committee Debates
>
Public Bill Committee

Session 2021-22

Cyber Security and Resilience (Network and Information Systems) Bill

Written evidence submitted by Cloudflare to the Cyber Security and Resilience (Network and Information Systems) Public Bill Committee (CSRB38)

1. Introduction

Cloudflare welcomes the opportunity to provide evidence to the House of Commons regarding the Cyber Security and Resilience (Network and Information Systems) Bill (CSRB). As a global leader in cybersecurity, providing security, performance, and reliability services to millions of Internet properties, as well as a regulated Operator of Essential Services (OES) and Relevant Digital Services Provider (RDSP) under the current NIS framework, we have a unique vantage point on the evolving threat landscape and the regulatory frameworks designed to address it.

Cloudflare is committed to enhancing the security of the UK's digital economy. While we believe that the Cyber Resilience Bill represents a critical step in modernizing the UK’s cybersecurity posture, its success depends on addressing systemic inefficiencies in the current regulatory environment-specifically regarding multi-regulator supervision, incident reporting and supervisory fees.

2. Designation of Critical Suppliers - adopt a Lead Authority Model (proposed Regulation 14

H(

5) and 14L)

The Cyber Resilience Bill permits an entity to be designated as a critical supplier by more than one competent authority simultaneously.
[1]
. While Cloudflare supports the principle of a broad and resilient digital ecosystem and welcomes the proposed coordination between multiple competent authorities,
[2]
we have concerns around the duplicative oversight that would lead to increased compliance costs for critical suppliers without a corresponding improvement in security outcomes. Suppliers subject to regulation by multiple authorities may choose to cease supplying OES and RDSP entities rather than bear the cost, concentrating supply chains and reducing overall resilience.

Cloudflare has firsthand experience with the challenges of being supervised by multiple regulators and this has meant duplication of efforts, requiring the submission of substantially similar information to both the Information Commission’s Office (ICO) and Ofcom. We encourage lawmakers to consider a more centralized approach to regulating critical suppliers, such as a "lead authority" model, to ensure that suppliers are not overburdened by compliance costs.

Proposed changeAmend Regulation 14H to require designation of a single lead authority for each critical supplier. Where a supplier has connections to multiple sectors, the lead authority should be determined through the coordination mechanism in Regulation 14L(3), which should be made mandatory rather than subject to the disproportionality exception in 14L(6).

3. Alleviating Burdensome Thresholds and Reporting Requirements

A.

Clarification of the "Capable Of" Reporting Threshold (Clause 15(2))

In order for organizations like Cloudflare to devise actionable, consistent policies and procedures for incident reporting, it is crucial that we have clear regulatory thresholds for when such reporting is required. The CSRB would broaden the definition of incident to include events that are "capable of having an adverse effect on the security of network and information systems."
[3]
In the context of incident reporting by regulated entities, it is not clear what "capable of" means or what criteria organizations should use when assessing that term. Moreover, the lack of clarity will lead to businesses making the wrong interpretation. Without further guidance on what "capable of" means, regulated entities may over-report, diluting the quality of intelligence available to regulators and the NCSC while diverting engineering resources from incident response to operationally burdensome additional compliance paperwork.

Proposed changeRequire the Secretary of State, through the code of practice under Clause 36, to issue binding guidance specifying the criteria for assessing whether an incident is "capable of" having a significant impact, including how existing mitigating controls should be factored into the assessment.

B.

Extend the Initial Notification Window Beyond 24 Hours (Clauses 11(6)(a), 12A(5)(a), 14E(5)(a))

The bill would shorten the timeframe for regulated entities to provide an initial incident report from 72 hours to 24 hours.
[4]
A significant concern for a 24 hour time period is the time and resources it takes to gather the metrics needed to assess an incident against the NIS reporting thresholds (e.g., currently 750,000 user hours in the UK). The preparation of a NIS incident report relies on many different teams including legal and other technical support , depending on the nature of the incident. In most cases, these metrics are not readily available and so it takes time to compile the required information Moreover, in the first 24 hours of an incident, the staff and engineers who would be best positioned to compile these metrics should primarily focus on mitigating the incident and supporting any affected customers. Accordingly, the shorter timeline would likely result in significant overreporting of incidents with metrics that are less reliable and would require several additional follow-up reports, while potentially distracting key engineers from their primary incident response obligations.

Proposed changeExtend the initial notification period from 24 hours to 72 hours, with the full notification deadline at 7 days. Alternatively, reduce the information required in the 24-hour initial notification to the entity's name and the bare fact that a potential incident has been detected, with the substantive report to follow at 72 hours.

C.

Remove the Direct Customer Notification Requirement (Clause 16, proposed Regulations 11C, 12C, and 14G)

The Bill requires regulated entities to take "reasonable steps" to identify which UK customers are likely to be adversely affected by an incident and then notify them individually... Requiring infrastructure providers like Cloudflare, which process billions of requests daily, to granularly identify each customer affected by an incident would significantly increase the amount of data Cloudflare would be required to collect. In turn, this would significantly increase operating costs and potentially impinge upon the confidentiality of our customers’ activities, creating additional privacy risk for customers who use these services specifically for privacy protection.

Proposed changeAmend the customer notification provisions to permit compliance through general public-facing notifications (such as a published status page) where the regulated entity cannot reasonably attribute the impact of an incident to specific customers without disproportionate data collection.

4. Establish a

Centralised

Incident Reporting Portal (Clause 15, proposed Regulations 11(8), 12

A(

7), 14

E(

7))

The concern around having to report into several competent authorities is that regulated entities must submit multiple incident notifications simultaneously, in the form and manner each authority determines. For companies like Cloudflare that are subject to regulation by multiple competent authorities, a single cyber event could trigger multiple, slightly different reporting obligations simultaneously, all the while diverting critical resources away from incident mitigation and toward administrative compliance.

Under the current proposal, regulated entities would be required to submit incident reports to their competent authority or authorities,
as well

as
to the National Cyber Security Centre (NCSC).
[5]

Cloudflare strongly advocates for the establishment of a common incident reporting portal for all UK NIS-related notifications. This approach aligns with international best practices, most notably the EU’s Digital Omnibus Regulation Proposal, which seeks to centralize reporting.
[6]

In setting up this portal, it is key that incident report templates be straightforward and flexible. Mandatory fields, in particular, should not be used. The government must balance its desire for detailed information about an incident with the reality that regulated entities may not yet have all the facts when submitting a report, especially when the deadline to do so is within 24 hours, as is currently proposed in this legislation.

Proposed changeAdd a new provision requiring the Secretary of State to establish a single incident reporting portal through which a regulated entity can submit one standardised report that is automatically routed to the relevant competent authority (or authorities) and the CSIRT. Report templates should avoid mandatory fields during the initial notification window, given the limited information available in the early hours of an incident.

5. Predictable Regulatory Fees

Because Cloudflare is regulated as both an OES by Ofcom and as a RDSP by the ICO, we pay fees to Ofcom to cover the costs of supervision, and this bill proposes to allow the ICO to levy similar fees.
[7]
However, the bill does not require a minimum notice period before revised fees take effect. Regulation 20A(3)(e) provides only a 14-day minimum between publication and effect. Company budgets are set many months in advance, making it difficult to absorb significant fee increases imposed without adequate notice.

We urge lawmakers to mandate proper notice before fees are adjusted, to ensure that regulated entities can set their budgets appropriately. Ideally, regulated entities would be informed of the predicted fees during the previous financial cycle to allow for proper budgeting.

Proposed changeAmend Regulation 20A(3)(e) to require a minimum of 6 months between publication of a revised charging scheme and its effective date, and require NIS enforcement authorities to provide regulated entities with an indicative fee estimate for the following financial year.

6. Conclusion

Cloudflare believes the CSRB is an essential vehicle for securing the UK’s digital future. However, to ensure it does not unnecessarily divert resources away from development and

growth towards compliance, it must not only address the friction within the current NIS

framework, but

establish a streamlined regulatory environment that is both future proof and aligned with global standards.

February 2026

[1]
Part 4B, 14H(5)

[2]
Part 4B, 14L

[3]
Section 15, page 29 https://publications.parliament.uk/pa/bills/cbill/59-01/0329/240329.pdf

[4]
Section 11(6), page 30 https://publications.parliament.uk/pa/bills/cbill/59-01/0329/240329.pdf

[5]
11(8) page 30

https://publications.parliament.uk/pa/bills/cbill/59-01/0329/240329.pdf

[6]
Article 6

https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=CELEX:52025PC0837

[7]
Chapter 3, Cost Recovery (p. 42)

https://publications.parliament.uk/pa/bills/cbill/59-01/0329/240329.pdf

Prepared 24th February 2026

Footer links

A-Z index

Glossary

Contact us

Freedom of Information

Jobs

Using this website

Copyright

Privacy notice
Cookie policy
Cookie Manager