Where a cloud is located tells us surprisingly little about who ultimately controls it. That distinction lies at the heart of Euralarm’s new guidance on the European Sovereign Cloud. For fire safety and physical security applications, the industry association identifies five dimensions of sovereignty – while rejecting the notion that maximum technological isolation should be pursued at any cost. The decisive question is not whether a cloud carries a European label, but whether its actual dependencies are appropriate to the risk.

Cloud technology has become far more than outsourced computing capacity for the security industry. IP-based alarm transmission, remote diagnostics, software updates, maintenance and increasingly sophisticated data analysis are extending the capabilities of fire safety and physical security systems well beyond what many on-premises architectures could economically provide.

Euralarm points to some of the benefits directly: greater computational power can improve detection probability, reduce false alarms and allow large volumes of video data to be analysed. Remote access also enables diagnostics, operations, updates and maintenance without requiring engineers to be physically present at the protected site.

Yet the deeper cloud penetrates security-critical processes, the more uncomfortable another question becomes: who ultimately controls the data, the infrastructure and the ability to keep the service running?

For operators of critical infrastructure, public authorities and other highly sensitive organisations, performance and conventional cyber security may no longer be sufficient criteria. Fire and security applications can process information and images directly related to infrastructure resilience, public institutions or national security. In such environments, preventing unauthorised access by foreign governments or actors can itself become part of the security requirement.

Euralarm’s contribution is to turn the often politically charged language of “digital sovereignty” into something more useful: a framework for technical, operational and procurement decisions.

A European Data Centre Is Not Enough

The most important argument in the guidance is deceptively simple: data location and cloud sovereignty are not the same thing.

Knowing that information is stored in Frankfurt, Paris or Amsterdam answers the geographical question. It does not establish which technologies the service depends upon, who can administer them, which courts and laws ultimately apply to the provider, or whether essential functions could continue if global infrastructure became unavailable.

Euralarm therefore distinguishes five facets of sovereignty: technological sovereignty, operational sovereignty, jurisdictional sovereignty, data residency and legal compliance. Its framework also draws on the European Commission’s Cloud Sovereignty Framework and the German BSI’s C3A scheme.

That distinction matters because it turns sovereignty from an abstract European policy objective into an architectural question: what exactly does an organisation need to control, and why?

Technological Sovereignty: Could You Actually Leave?

Technological sovereignty begins with dependency. How reliant is a cloud architecture on proprietary technologies controlled by non-European companies, and what would happen if an organisation needed to migrate away from them?

Open standards, interoperability and transparency over technological dependencies therefore become resilience issues rather than merely technical preferences. An exit strategy has little value if it is devised only after an exit has become necessary.

Euralarm’s risk-based framework consequently identifies measures such as portability architectures, tested exit plans, data exportability and, where justified, multi-cloud or dual-stack approaches. The objective is not necessarily complete independence from every non-European technology. It is to understand and reduce concentration, migration and vendor lock-in risks.

The guidance goes further through the concept of European survivability. A more sovereign cloud architecture should be capable of continuing to operate within Europe even if cross-border connectivity is severely disrupted or wider global cloud structures cease to be fully available.

For security operators, that turns technological sovereignty into a highly practical test: which non-European systems must remain available for a critical European security service to continue functioning?

If the answer includes identity infrastructure, DNS, key management, control planes, logging systems or update repositories located elsewhere, then the physical location of the application data tells only part of the story.

Operational Sovereignty: Who Holds the Administrator Credentials?

Technological independence is one issue. Operational control is another.

Euralarm defines operational sovereignty in terms of the practical ability of European actors to operate, support and develop technology without critical foreign dependencies. That includes provisioning and management, but also monitoring who has physical and digital access to the infrastructure.

This distinction is particularly important for security applications. A data centre may stand firmly on European soil while privileged support or administrative access is still exercised by globally distributed teams.

The guidance therefore moves beyond broad assurances and points towards concrete controls. These include Privileged Access Management, Just-in-Time access, dual control, tamper-evident logging and customer notification or approval for particularly sensitive operations.

The pertinent question is consequently not simply where infrastructure is operated, but who can exercise authority over it when it matters most.

For a fire safety or security system, this distinction is far from academic. Administrative privileges can affect configuration, availability, data access and incident response. Control over privileged access is therefore part of the security architecture itself.

Jurisdictional Sovereignty: Which Law Ultimately Wins?

The issue becomes more difficult when technology meets law.

Jurisdictional sovereignty considers the legal environment governing a provider, its operations and its support organisation, and the extent to which the service is insulated from legal demands originating outside Europe.

Euralarm points towards European governance structures, Europe-based support and operations, and personnel subject to European law as characteristics of a more jurisdictionally sovereign model. It also highlights stronger operational separation and EU-only access paths for sensitive environments.

The reason is concrete. The guidance devotes an annex to the US CLOUD Act, under which US data and communications companies can, subject to the relevant legal procedures, be required to provide stored customer data even where those data are held outside the United States. Euralarm also stresses that extraterritorial legislation is not uniquely American: comparable legal exposure is becoming relevant in a number of other jurisdictions.

The implication is both commercially and strategically significant:

A European server location does not automatically remove the reach of non-European law.

Nor is the analysis limited to the name on the cloud contract. Parent companies, subcontractors, support providers and other elements of the supply chain may all introduce jurisdictional dependencies. Euralarm explicitly acknowledges how difficult it can be for organisations to determine the full extent of such exposure – and that extraterritorial influence cannot realistically be eliminated in every circumstance.

Sovereignty, in other words, becomes a matter of managed residual risk rather than absolute legal isolation.

That is arguably a more mature position than much of the current debate allows.

Data Residency: Where Is the Entire Data Chain?

Geography still matters. It simply does not settle the argument.

Euralarm defines data residency as the requirement for information to be stored within a particular geographical boundary, such as an individual country or the European Union. In a European sovereign environment, customer data and relevant metadata should remain within Europe and be isolated from other cloud regions.

But the guidance draws an important distinction between data residency and data sovereignty.

Data sovereignty concerns the customer’s ability to exercise control over the collection, storage, use, processing and eventual deletion of its information. Encryption, key management, access controls, retention policies and governance therefore matter alongside geographical location.

For security systems, this distinction is particularly revealing. A video recording might reside in Europe while associated metadata, operational information or support processes continue to depend on global cloud systems. The primary dataset may therefore be European while important elements of the surrounding processing chain are not.

Euralarm’s suggested controls include region pinning, residency requirements for backups and logs, clear data-classification and placement rules, transparency over processing locations and robust encryption and key governance.

The more useful procurement question is therefore no longer simply “Where are our data stored?”

It is: “Where does the entire data-processing chain operate, and who controls each part of it?”

Compliance: From Box-Ticking to Architecture

The fifth dimension is legal compliance.

Euralarm argues that a European sovereign cloud should do more than accumulate certifications. European legal and regulatory requirements should be incorporated into the provider’s operating model and contractual framework.

The guidance refers specifically to the GDPR and the EU Data Act, and describes a sovereign model in which cloud contracts are governed by the law of a European country and disputes fall within European jurisdiction.

Its risk framework takes the principle further: regulatory compliance should be embedded within the cloud provider’s processes in a manner that can be audited.

For purchasers, this changes the sequence of decision-making. Compliance can no longer be treated merely as a legal review conducted after the technical architecture has been selected.

Compliance becomes one of the architecture requirements.

That is especially important as security systems become more closely intertwined with data protection, cyber-security obligations and sector-specific regulatory requirements.

Not Every Security Application Needs Maximum Sovereignty

Perhaps the most intellectually useful aspect of Euralarm’s paper is what it does not argue.

It does not demand the highest conceivable level of sovereignty for every cloud-connected alarm, access control or video system. Instead, it advocates an explicitly risk-based and proportionate approach.

A routine commercial application does not necessarily carry the same protection requirements as an airport, government institution or critical infrastructure operator. The impact of service interruption, foreign legal intervention, data disclosure or forced migration can vary enormously between use cases.

Organisations should therefore identify their risk first, then determine which dimensions of sovereignty are necessary and to what degree.

For procurement teams, this is where the guidance becomes particularly useful. “Sovereign cloud” ceases to be a vague requirement and can instead be broken down into testable questions.

How quickly must an organisation be able to exit a provider? Must sensitive support operations remain entirely within Europe? Where may backups and logs be processed? Who controls the cryptographic keys? Can the application continue running if cross-border services are disrupted? Which legal structure limits exposure to third-country orders?

These are far more meaningful questions than asking a provider whether its cloud is “European”.

Sovereignty Has a Price

Euralarm is equally pragmatic about economics.

The guidance explicitly acknowledges that genuine immunity from extraterritorial legal demands, or a completely vendor-agnostic architecture, can carry a very high price. Stronger sovereignty controls must therefore be balanced against the value created by the service, the organisation’s protection requirements, and both the likelihood and potential impact of a sovereignty failure.

This may be the document’s most important conclusion.

Maximum sovereignty is not automatically the best business decision. Minimum sovereignty is not necessarily an acceptable one either.

The objective is not ideological purity. It is to understand dependencies well enough to determine where additional technical, operational or legal control genuinely reduces risk – and where it merely adds cost and architectural complexity.

That distinction matters because over-engineering has consequences of its own. An architecture designed to eliminate every conceivable dependency may become expensive, difficult to operate and harder to maintain. Conversely, a system built solely for efficiency may conceal dependencies that only become visible under legal, geopolitical or operational stress.

Sovereignty is therefore a balance sheet of dependencies.

Sovereignty Becomes a Procurement Decision

Euralarm’s guidance moves the sovereign-cloud debate away from slogans and towards risk analysis.

For security applications, choosing a cloud provider should increasingly involve more than checking whether European data centres are available or whether a familiar collection of certifications appears on the supplier’s website. Portability, privileged access, ownership and governance structures, jurisdiction, data-processing paths, cryptographic key control and dependence on global control planes may be equally significant.

This is a natural development for the security industry. As more functionality in fire detection, access control, video surveillance and alarm management moves into cloud environments, the cloud itself ceases to be merely an IT hosting choice.

It becomes part of the security system.

The relevant question is therefore not whether a provider describes its product as a European Sovereign Cloud. It is which technological, operational and legal dependencies actually remain, what risks those dependencies create, and whether the resulting level of sovereignty is proportionate to the value and criticality of the application.

Seen in those terms, cloud sovereignty is neither a political label nor an end in itself.

It is a procurement, resilience and risk-management decision.

INFO | Euralarm Guidance on European Sovereign Cloud

What is it?
Euralarm’s guidance is intended to help manufacturers, service providers, system integrators and users of fire safety and security systems assess sovereignty requirements when procuring and operating cloud services.

The five key dimensions

• Technological sovereignty – Dependency on proprietary technologies, interoperability and the ability to migrate.
• Operational sovereignty – Who operates, administers and supports the infrastructure.
• Jurisdictional sovereignty – Which legal regimes govern the provider, its operations and support.
• Data residency and sovereignty – Where data are stored and processed, and who retains effective control over them.
• Legal compliance – How European regulatory requirements are embedded in contracts and operating processes.

The principle
Euralarm recommends a proportionate, risk-based approach rather than maximum sovereignty by default. Protection requirements should be weighed against business value, operational criticality, cost and architectural complexity.

Read the original guidance
Guidance document on Criteria for European Sovereign Cloud – PDF