Now, the EU's updated NIS2 Directive is coming into force (2024), making the issue more relevant than ever. NIS2 imposes significantly stricter cybersecurity requirements, not least for public sector organisations. The directive now covers public administration and many digital service providers, emphasising, among other things, supply chain security, incident reporting and accountability among management. This means that the decision to use an external cloud service such as Cloudflare is no longer a purely technical choice – it has become a strategic risk decision that may have regulatory consequences. The same features of Cloudflare that have previously been criticised (such as lack of transparency in traffic and potential protection of malicious activity) may now put public sector organisations on a collision course with NIS2 requirements.

In this follow-up article, we analyse the most serious risks associated with Cloudflare from a NIS2 perspective. Several Swedish authorities already use Cloudflare for DNSSEC, web application firewalls (WAF) and DDoS protection, among other things, so this is not an abstract issue. How do Cloudflare's foreign jurisdiction, data management and technical setup affect an organisation's ability to comply with NIS2?

Below, we go through five key areas:

  • Jurisdiction
  • Data residency
  • Lack of transparency
  • Dependencies
  • Incident reporting

Through concrete examples (the Schrems II ruling, the CLOUD Act, the infamous Cloudbleed bug, and more) and links to current EU initiatives, we show why the public sector must weigh these risks very carefully. We conclude with recommendations for decision-makers on how to approach Cloudflare in sensitive systems, with a focus on achieving NIS2 compliance.

Jurisdiction: US law versus EU regulations

One of the most talked-about risks is Cloudflare's jurisdiction – i.e. the fact that the company is based in the US and is therefore subject to US law. This means that laws such as the US CLOUD Act and FISA 702 can apply to data handled by Cloudflare. In concrete terms, this means that US authorities can demand the disclosure of data from Cloudflare, even if the data is physically located within the EU. This extraterritorial reach directly conflicts with EU data protection rules: GDPR Article 48 prohibits the transfer of personal data to foreign authorities without a legal basis in the EU, and the EU Court of Justice's Schrems II ruling (2020) established that US surveillance legislation does not meet the EU's requirements of necessity and proportionality. Furthermore, the court found that EU citizens have no possibility of judicial review in the US if their data is collected. In other words, there is an inherent legal conflict: Cloudflare may be forced to comply with US law in a way that jeopardises European privacy and integrity principles.

For the public sector, which often handles sensitive personal data and confidential information, this is a red flag. In Sweden, great caution has been expressed regarding the use of cloud services under foreign law. The eSam collaboration, for example, has stated that if a supplier is subject to the CLOUD Act, it must be assumed that confidential information may be disclosed to foreign countries. Several authorities have ended up in a ‘deadlock’ where they have been unable to move data to American cloud solutions precisely because of the risk of unauthorised access and violations of public access and confidentiality legislation. The ongoing conflict between EU and US legislation in this area is well known and still unresolved, despite new frameworks such as the Data Privacy Framework. In short, Cloudflare's US domicile means there is an inherent high risk that European rules will be disregarded.

The NIS2 Directive clearly addresses this issue. The preamble to the Directive emphasises that risk management should include an analysis of suppliers' legal residence and the risks this entails. This is a matter of digital sovereignty – the EU wants to ensure that critical services are not subject to the laws of foreign powers. We also see concrete initiatives that support this view: According to ENISA's proposal for an EU Cloud Certification Scheme (EUCS), the highest level of security should only be awarded to cloud services that have their headquarters in the EU, store data within the EU and guarantee freedom from foreign government access. If adopted, this would exclude providers such as Cloudflare from the most sensitive areas of use within the EU. France has already introduced its own SecNumCloud certification with similar criteria – French authorities do not consider American clouds to be ‘sovereign’ as long as the CLOUD Act remains in force. Germany has been more pragmatic, but even there, there is a tug-of-war between the need for American technology and the demands for legal control.

Consequences for NIS2 compliance:

  • High risk level: According to a recent risk assessment, Cloudflare's US jurisdiction is ranked as ‘High’ risk (high probability, high impact) for a public sector organisation. This is considered well-founded in light of the Schrems II ruling and the EU's stance on third-country transfers.

  • Required measures: NIS2 requires organisations to take ‘appropriate and proportionate technical and organisational measures’ to manage risks. If, despite everything, a US-based service such as Cloudflare is used in sensitive systems, strong safeguards (e.g. encryption, data processing agreements) must be put in place to mitigate the jurisdictional risk. We will return to recommendations on this issue.

  • Future regulations: Public decision-makers should take into account that the trend in the EU is towards greater restrictiveness with foreign-dependent suppliers. Ignoring these signals could mean that in a few years' time, you will be forced to change solutions under time pressure as regulations are further tightened. The jurisdiction issue is therefore not just a theoretical discussion – it could determine whether a service such as Cloudflare is even permitted for certain applications in the future.

Data residency: where does the data and traffic end up?

Closely linked to jurisdiction is the issue of data residency, i.e. where data flows and is stored. Cloudflare operates a global network of servers in over 100 countries to optimise performance. This means that even if your web server and database are in the EU, traffic data, metadata and cache content may be temporarily stored on nodes outside the EU depending on the network routing. The risk assessment explicitly notes that traffic “may be routed outside the EU”, which constitutes a potential violation of local data storage requirements. This risk was assessed as medium–high in the analysis.

Formally, NIS2 does not stipulate that all data must remain within the EU. However, the directive emphasises that supply chain security and jurisdiction must be addressed (once again, the jurisdiction aspect comes up here). In practice, the issue of data residency falls under several regulations: GDPR requires protection for third-country transfers of personal data, and national laws may prohibit confidential information from being handled outside Swedish control. As mentioned above, many believe that if a cloud service is subject to the CLOUD Act, it is of little help that the data centres happen to be in the EU – the data is still not ‘secure’ in the European sense.

The Schrems II ruling (2020) invalidated the previous Privacy Shield agreement between the EU and the US and introduced requirements for case-by-case assessments before personal data is transferred to third countries. Authorities and companies must therefore carry out so-called transfer assessments and possibly introduce additional protection (encryption, etc.) if data may end up outside the EU. In Sweden, eSam and the Swedish Data Protection Authority have signalled that transfers to the US should be considered high risk and handled with the utmost caution.

In 2023, several municipalities and authorities have been criticised for using cloud services without proper risk assessment of third-country processing.

Cloudflare is aware of these concerns and has launched initiatives to meet customer requirements for data residency. Among other things, it offers a ‘Data Localisation Suite’, where Cloudflare promises to process customer traffic data only in data centres within the EU, for example. It is also possible to configure a Customer Metadata Boundary to restrict where certain metadata is stored. These solutions, together with standard contractual clauses (SCC) for GDPR, are steps in the right direction. However, they do not eliminate the risk entirely. The problem is that the underlying legal dilemma remains: a US-based operator can never guarantee full immunity from US government demands – regardless of where the servers are located. Cloudflare can technically try to keep data within the EU, but if a court order from the US requires information that has passed through their network, Cloudflare is caught between violating EU law or US law.

Consequences for NIS2 compliance:

  • Transfer assessments: Public sector organisations must, in accordance with the GDPR and good practice, carry out a transfer assessment for Cloudflare if the service is used and personal data is included in the traffic. Given the CLOUD Act, etc., such an assessment would likely identify significant risks that require strong encryption or refraining from using the service for that specific data. NIS2 tightens the requirements for such analyses to be carried out and documented.
  • Data classification: It will be important to classify the data and traffic that passes through Cloudflare. Open, public websites (without login or sensitive information) can be considered less sensitive – where the benefits of Cloudflare may outweigh the risks. Sensitive personal data or security-classified information is another matter; there are strong arguments that the data residency and jurisdiction risk is unacceptable. Deliberately sending confidential personal data through Cloudflare's global network would likely be seen as a breach of the principle of caution in public activities.

  • Mitigating agreements: As compensation, there should be clear agreements: Cloudflare must undertake to keep data within the EU where possible, to provide information about where data may end up, and to contest unreasonable requests from authorities. Although this does not remove the jurisdiction conflict itself, it can at least show that the organisation has done what it can – something that may be crucial in a NIS2 supervisory review.

In summary, data residency and jurisdiction are two sides of the same coin. The EU is increasingly emphasising ‘cloud sovereignty’, so the public sector needs to ask itself: How big a problem would it be if certain data via Cloudflare ended up outside EU control? If the answer is ‘unacceptable’, Cloudflare should be rejected for that application – or alternatively, the data should be encrypted/encapsulated so that even Cloudflare itself cannot access anything useful.

Lack of transparency: when the cloud shield obscures the view

One technical risk that has been highlighted is the lack of transparency when Cloudflare acts as an intermediary (‘reverse proxy’). Cloudflare's service acts as a shield in front of your server: all traffic from users first passes through Cloudflare's network, where filtering and caching take place, before being forwarded to your application. This offers many advantages (protection against DDoS, filtering of malicious traffic, performance improvement via cache), but also a disadvantage: you as a customer may lose some visibility into what is actually happening in the traffic.

Two concrete examples of transparency issues:

  • Hidden IP addresses: When Cloudflare proxies your web traffic, the visitor's real IP address is not visible in your logs – instead, you see a Cloudflare IP. The original IP can be obtained via special headers (CF-Connecting-IP), but this requires your systems to support and log them. For many older systems or standard logs, using Cloudflare means losing information about where the traffic is coming from. This makes it difficult to perform geo-based analyses, block individual threat actors, and more.

  • Logs in the cloud: Much of the log information about what Cloudflare blocks or allows through is stored at Cloudflare, not locally on your premises. To see detailed logs of HTTP requests, cache hits, WAF events, etc., you must use Cloudflare's interface or API. This poses a problem for smaller customers in particular: Cloudflare only offers complete HTTP logs to Enterprise customers. If you don't pay for the highest level, your access to raw data may be limited – you do not only get aggregates or shorter retention times. The risk assessment points out that forensics and monitoring may suffer without the right contract level.

For a public sector organisation that needs to maintain high security, a lack of transparency means that attacks or anomalies may potentially be missed. It can be difficult to detect an advanced intrusion campaign if important details are filtered out in the cloud. And if an incident is investigated retrospectively, critical evidence may be out of reach on Cloudflare's servers. You become dependent on Cloudflare's goodwill to obtain all the necessary information.

NIS2 requires organisations to have the ability to detect and respond to incidents on an ongoing basis.

Among other things, the directive stipulates that continuous monitoring and regular security tests must be carried out. If Cloudflare is responsible for a large part of the security functionality (e.g. blocking attacks), you must ensure that these events are shared back with your own organisation. Otherwise, you risk living in a false sense of security. As a NIS2-covered entity, you are expected to be able to present a snapshot of your cybersecurity situation, which requires that logs and traffic data are actually accessible for analysis.

Possible measures for transparency:

There are ways to mitigate the lack of transparency, which are also recommended in the risk analysis:

  • Advanced log management: Utilise Cloudflare features such as Logpush to send log data (HTTP requests, DNS queries, WAF events, etc.) in real time to your own environment for storage and analysis. Integrate Cloudflare logs into your SIEM monitoring system. The goal should be that almost all relevant traffic data that Cloudflare sees, you also see – at least retrospectively.

  • ‘Double logging’: Continue to log as much as possible in your own systems. Even if Cloudflare is in front, make sure that your origin server logs visits (with forwarded IP), and log any encrypted traffic before it enters Cloudflare. For example, some organisations run a parallel network sniffer or an IDS on traffic entering/leaving Cloudflare to have their own copy.

  • Contractual requirements: Include in agreements/SLAs that you will have immediate access to relevant logs at Cloudflare in the event of a security incident. For critical systems, you may want to agree on extended log access even without an Enterprise package. Also require audit rights – that you or a third party can review Cloudflare's controls and gain insight (under NDA if necessary) into security processes.

  • Testing: Conduct regular tests where you simulate an incident and evaluate how much data you can retrieve with your current log levels. If the tests reveal gaps, adjust the configuration accordingly.

In short, it is important to regain control over your data as far as possible. Cloudflare must not become a ‘black box’ in your infrastructure. In the worst case, an intermediary that extends your eyes and ears can also act as a blindfold if you do not have the right access. Also be aware that if Cloudflare itself were to be attacked (for example, a supply chain attack on their platform), it may be difficult for you to detect in time. Such scenarios should be included in your risk analysis: ‘What do we do if Cloudflare is compromised or filters out something we should see?’

Dependence on an external actor: risk of lock-in and single point of failure

Cloudflare is now a critical part of the internet: the company says it handles traffic for over 30 million websites and protects a significant proportion of all web traffic. If a public organisation chooses to put its website or e-service behind Cloudflare, this means that an external supplier suddenly becomes responsible for a large part of its availability and security. This creates a dependency that must be managed.

The risk analysis highlights several dimensions of this dependency:

  • Difficult to switch quickly: If you have built your infrastructure around Cloudflare's services (DNS, certificates, WAF rules, etc.), it can be operationally difficult to switch providers at short notice. Imagine that Cloudflare suffers a serious vulnerability or that a new law forces you to stop using the service – how quickly can you switch to another solution? This lock-in effect is real, especially if you have used many of Cloudflare's value-added services.

  • Single point of failure: Although Cloudflare's operational reliability is normally very high, it is fallible. There are incidents that show that Cloudflare errors can have global consequences – for example, in 2019, an incorrect network rule accidentally took Cloudflare's services down for ~30 minutes for large parts of the internet, affecting many customers' sites. And in 2020, Cloudflare experienced an outage that affected parts of Europe. If your business does not have redundancy or a backup route outside Cloudflare, this constitutes a single point of failure. As the risk analysis notes: Cloudflare's strength and size do not eliminate the risk of total outages – it remains if all traffic goes through one actor.

  • Supply chain risk: NIS2 emphasises the importance of managing risks in the supply chain. If Cloudflare were to become hostile (for example, in a contract dispute) or suffer a cyberattack, this would effectively be a vulnerability in your chain. In fact, NIS2 Article 21 requires organisations to evaluate the security of their suppliers and take their vulnerabilities into account. Cloudflare should be considered a ‘critical third party’ in your IT supply chain if you depend on them for operations.

From a NIS2 perspective, continuity and resilience are key words. The directive requires planning to maintain essential services even during disruptions. This makes ‘What happens if Cloudflare goes down?’ a key question. In the risk analysis, the dependence on Cloudflare was assessed as high risk (medium probability, high impact), precisely because a sudden loss of Cloudflare could paralyse an organisation without preparedness.

Strategies for managing dependence:

  • Redundancy: Ensure that there is a fallback plan if Cloudflare fails. This could be alternative DNS servers (which can be used if Cloudflare DNS is down) or a parallel, simpler CDN/proxy service that can take over basic functions. Some organisations have a ‘bypass’ mechanism – for example, the ability to quickly redirect the domain directly to the origin server if Cloudflare is unavailable. Such a plan should be tested in practice in advance.

  • Exit strategy: When procuring services, you should already consider your exit strategy – how do we terminate Cloudflare if necessary? How long does it take to migrate DNS zones, certificates, WAF rules, etc. to a new platform? Plan for an orderly transition so that you do not get ‘stuck’ if the world around you change. Under NIS2, organisations are expected to be prepared for scenarios where a supplier must be replaced.

  • Supplier diversification: Consider not putting all your eggs in one basket. Perhaps you can use Cloudflare for certain services but keep other critical services on a different solution. This limits the impact if one supplier goes down. However, this should be weighed against complexity – sometimes multiple suppliers can mean more to manage in terms of security. The main point is to consciously choose where you can tolerate a Cloudflare outage and where you cannot.

  • Contractual protections: Try to include commitments from Cloudflare regarding incident support and advance notice of changes. For example, if Cloudflare is planning a change that may affect you, you want to know about it. If you need to terminate the agreement due to legal requirements, there should be a smooth way out without a long commitment period.

Being dependent on third-party services is nothing new, but NIS2 raises the bar for how this dependency should be managed. Management must be aware of the risks and actively mitigate them. A thought-provoking quote from the analysis document is: ‘Cloudflare should not be used in systems covered by NIS2 without clear technical and organisational safeguards.’ In other words, if you do not have a firm grasp of redundancy, contracts, and security measures, you should refrain from becoming so dependent on an external actor in critical systems.

Incident reporting under NIS2: challenges with Cloudflare's involvement

One of the most concrete changes in NIS2 is the strict requirements for incident reporting. ‘Essential’ operations (which will include many public authorities) must submit an initial indication report within 24 hours of a serious incident being detected, and a more detailed report within 72 hours. This means that organisations need to detect incidents quickly and have access to detailed information in order to report the cause, scope, affected systems, measures taken, etc. within just a few days.

Cloudflare can influence this process in both positive and negative ways:

  • Helping hand: When used correctly, Cloudflare can actually reduce the number of incidents that affect you. If Cloudflare blocks a large DDoS attack or filters out known malicious traffic via WAF, you may never need to report it as an incident (because it was stopped in time). Cloudflare has a security team that monitors global threats, and they can sometimes warn customers of major attacks. Example: if your website is targeted by a massive bot attack, Cloudflare may notice this and notify you that something is happening. This type of ‘proactive incident management’ can strengthen your security and keep you up and running. At its best, Cloudflare acts as a partner, providing you with threat intelligence and first-line defence.

  • Complicating factor: On the other hand, if an incident involving Cloudflare does occur, the situation becomes more complex. Imagine that you discover a data leak or breach, and it turns out that the attacker used Cloudflare's infrastructure to hide. You may see traces of malicious traffic, but only Cloudflare's IP addresses. In that case, you would be dependent on Cloudflare to provide logs showing the original source (for example, via their CF-RAY ID or other log parameters). If Cloudflare does not provide this information quickly, you would be left with incomplete information as the 72-hour deadline approaches. It is even worse if the incident lies with Cloudflare itself – for example, the Cloudbleed bug in 2017, where a software bug at Cloudflare caused customer data to leak in plain text via caches and search engines. In such a situation, you have to rely on Cloudflare's own investigation of what was leaked, and your reports to the authorities must be based on Cloudflare's information. It is obvious without saying that reporting an incident without having full insight puts you in a difficult position.

The risk assessment for Cloudflare under NIS2 specifically points to ‘potentially impeded incident reporting’ as a risk. Lack of insight (as discussed above) can mean that you discover incidents too late or are unable to compile a complete incident report in time. For NIS2 compliance, this is problematic – an incomplete or late report can lead to sanctions, in addition to the consequences of the incident itself.

Recommendations for incident management:

  • Agree on support: Make sure your agreement with Cloudflare includes rapid support in the event of security incidents. You should have a named contact or clear process for escalating issues and obtaining logs/information within hours, not days. Cloudflare, as a supplier, should commit to assisting you in meeting your legal requirements. This also includes clarifying who reports what: For example, if Cloudflare itself is affected by an incident (such as Cloudbleed), will they inform you promptly so that you can report it further?

  • Practise incidents with Cloudflare in the loop: Include Cloudflare in your incident response exercises. If you do a table-top exercise or technical drill, simulate that Cloudflare logs are needed and see how quickly you can get them. Identify contact channels for Cloudflare. All this to avoid the first time you test the process being a real-life situation.

  • Clear division of responsibilities: NIS2 also introduces some new responsibilities for suppliers. Cloudflare will probably be covered by NIS2 itself (it is likely to be classified as a digital infrastructure service provider). This means that Cloudflare may have its own reporting obligations for incidents affecting its service. You should stay informed about how Cloudflare handles this – for example, whether they issue incident advisories to customers. In the best- case scenario, Cloudflare's own NIS2 compliance could be an advantage for you if they communicate problems quickly. In the worst-case scenario, you cannot rely on this and must assume that you will have to take the initiative yourself.

  • Built-in redundancy in reporting: If Cloudflare is down or unavailable during an incident (perhaps the cause of the incident itself), how will you gather facts? See if you can have some monitoring outside Cloudflare (e.g., external synthetic transactions, other log sources) so that all your evidence does not rest on a provider that may be amid chaos.

In the public sector, damage to trust can also be significant if it emerges that there was a lack of control. The media and regulatory authorities may ask: ‘Did you know about the risks of using a foreign cloud service, and how did you ensure that no citizen data was misused?.’ Here, it is important to be able to show that you have done your homework. A documented risk assessment (such as the one we refer to here) and the countermeasures taken become a lifeline for demonstrating that management has acted with due diligence. According to NIS2, management is responsible, with possible personal sanctions in cases of gross negligence. In other words, incident management is not just an IT issue, but a management issue. The decision to use Cloudflare in sensitive systems should therefore be anchored in senior management, precisely because of the reporting and accountability obligations that come with NIS2.

Towards a balanced strategy – recommendations for decision-makers

Cloudflare undoubtedly offers significant technical advantages. Higher global performance, powerful protection against DDoS attacks, offloading of proprietary systems and an ecosystem of security services – all of this can enable digital initiatives that would otherwise be difficult to implement, especially for smaller organisations.

The public sector is under pressure to deliver fast and reliable e-services, and cloud services such as Cloudflare can theoretically help to raise the overall level of security.

However, as we have shown with the support of both risk analysis and current EU trends, Cloudflare also poses significant risks to a NIS2-covered business, especially if no additional measures are taken. Factors such as legal sovereignty, data residency, transparency and continuity have emerged as strategic issues – not just technical details – with NIS2 and the European debate on digital autonomy. Decision-makers now need to weigh the benefits against the risks in a structured way. They should not be blinded by marketing promises or succumb to unnecessary alarmism; instead, a nuanced, evidence-based assessment is required.

In conclusion, we would like to offer some clear recommendations to IT managers and other decision-makers in the public sector who are considering or already using Cloudflare in sensitive or critical systems:

  1. Conduct a formal risk analysis in accordance with NIS2: Document the risks associated with Cloudflare in your environment, compared to alternative solutions. Include the supplier's jurisdiction as a parameter – NIS2 now explicitly requires this to be taken into account. Assess the probability and impact of scenarios such as ‘access to data by a foreign state’, ‘Cloudflare causes service interruptions’, ‘insufficient logging during incidents,’ etc. Be honest about uncertainties and assume the worst-case scenario in critical cases (precautionary principle). This documentation is needed to justify your decisions to both internal audit and external supervision.

  2. Limit use based on the sensitivity of the system: Apply the principle of ‘right thing in the right place’. For each system or data class, determine whether the risk level with Cloudflare is acceptable. Non-critical, public systems (such as a municipal information website) may well be run via Cloudflare, where the performance and security benefits may outweigh the risks. Critical systems or those with sensitive information (such as internal e-services with personal data, health systems, judicial applications) should be strongly considered not to be placed on a foreign-owned cloud proxy. As the risk document stated: use Cloudflare only in non-critical systems that can tolerate the extra level of risk. This way, you limit the worst possible consequences if something goes wrong – you spread the risk.

  3. Set requirements and take protective measures if you use Cloudflare: If you decide to use Cloudflare for a particular system, do so with ‘seatbelts and airbags on’. Build in compensatory controls to manage the risks we have discussed. Some key measures are:

    • Legal agreements: Ensure that you have valid Standard Contractual Clauses (SCC) for GDPR with Cloudflare and that they commit to keeping data within the EU whenever possible. Try to include wording stating that the supplier must notify and contest any government requests for your data (Cloudflare has publicly stated that it does this, but it is good to have it in writing).

    • Data location: Take advantage of technical options such as the Cloudflare Data Localisation Suite – configure your traffic to only be handled in EU data centres. Follow up on where your data actually goes; request reports on which data centres are most often used for your domain. If possible, lock traffic to specific regions.

    • End-to-end encryption: Always use TLS encryption all the way from the client to your origin server (Cloudflare supports this through Full (strict) mode). Use your own certificates at the origin and ensure that Cloudflare cannot bypass the encryption. This prevents anyone (including Cloudflare itself or an actor who gains access to their system) from reading sensitive content in plain text. All data passing through their servers will then be encrypted ‘on the surface’ at a minimum.

    • Logging and monitoring: Enable Logpush/Logpull for as many log types as possible to an environment you control. Collect Cloudflare logs and analyse them together with your own system logs. Set up alerts that correlate Cloudflare attacks/blockages with your internal events. Practise tracking an event through both Cloudflare and your own logs.

    • Redundancy plan: Implement a fallback (e.g., alternative DNS, backup proxy, or bypass option) in case Cloudflare fails or needs to be disconnected urgently. Document and test this plan regularly.

    • Exit plan: Define how you would terminate your use of Cloudflare if necessary. How quickly can you phase out the service and switch to another provider or operating model? This should be documented so that you are not left fumbling if faced with this situation. NIS2 emphasises robustness, which includes not getting stuck in an unmanageable situation.

    • Audit rights and testing: Take advantage of opportunities to review Cloudflare's audits/certifications (ISO 27001, SOC 2, etc.). If possible, participate in customer audits or request to see more details under NDA – transparency builds trust. Also continue with your own penetration tests on your systems with Cloudflare enabled, so that you can verify both protection and identify any blind spots.

  4. Stay up to date on EU regulations and guidelines: The landscape of cybersecurity and data protection is constantly changing. New legal requirements and standards may be introduced that affect your supplier strategy. Follow developments such as EUCS certification – if the highest classification becomes a requirement for certain public systems, this could exclude foreign cloud services. Keep an eye on the next chapter in the Schrems case – a Schrems III could well emerge if the current arrangements are not considered sufficient. Authorities such as MSB and PTS are likely to issue guidance on NIS2 compliance; keep an eye on these. The point is to be proactive: if you anticipate that ‘in two years' time, Cloudflare may not be permitted for us’, then it is better to act now (e.g. evaluate alternatives) than to be forced to act in a panic then.

  5. Establish support and be transparent: Ensure that management and relevant stakeholders understand the reasoning. Present the risk picture and measures to your board or executive committee – NIS2 emphasises management responsibility, so they need to be on board. Also, be prepared to answer questions from the media or the public: document your decision-making process so that you can show that you have carefully considered the issues and taken the necessary protective measures. In the public sector, transparency is important; it is better to be proactive about your cloud usage than to be perceived as having secretly brought in a potentially controversial supplier.

By following these guidelines, public sector organisations can navigate the dilemma posed by Cloudflare and similar services. In some cases, the most responsible course of action may be to refrain and choose a locally based solution, despite higher costs or certain functional limitations – when critical societal values are at stake, risk appetite is low. In other cases, global cloud services can be used with a clear conscience, but with rigorous controls, carefully defined use, and constant preparedness. The key is to make informed decisions that continuously weigh the benefits against the risks and are prepared to adjust course as the world around us changes.

Conclusion

Cloudflare itself markets its vision of ‘building a better internet’. That may be so, but for the public sector in 2024+ it is important not to leave anything to chance. NIS2 puts the spotlight on providers such as Cloudflare – compliance and security must go hand in hand. By proactively addressing the risks we have highlighted here, public authorities and organisations can both protect citizens' data and leverage modern technology in a responsible manner. The balance between innovation and caution is difficult to strike, but with the right measures in place, it is achievable. The work you put in today, before an incident or regulatory action forces you to, is an investment in both robustness and trust in your organisation. NIS2 may raise the bar – but it also raises the quality – of our shared digital ecosystems, and it is up to every decision-maker to ensure that we live up to that ambition.