A European position on operational preparedness

1Summary

Europe is funding preparedness as things. Stockpiles, equipment, shelters and kits can be counted, stored and audited, and they answer a real part of the problem. What is not being funded is the layer that coordinates their use: the software that puts people who have never worked together onto one picture of one incident. It goes unbudgeted because no single organisation owns it, and it is the part that fails first.

This paper has a deadline, and that is why it is written now rather than later. The European Union's 2028 to 2034 budget is under negotiation. The Union Civil Protection Mechanism is proposed at over 10.6 billion euro, with health emergency preparedness integrated into it, and internal security at 6.8 billion. What counts as preparedness capability is being defined this year and then holds for the seven years that follow. We argue, while the definitions are still open, that the coordination layer is preparedness infrastructure and should be funded, specified and governed as such.

We also make a second, narrower argument: that this particular class of software, the software holding the live location of responders and the addresses of citizens who cannot evacuate themselves, should sit under European ownership and European law. Section 5 makes that case and is the section we would most like read. Sections 3 and 4 state our own position first, including where our platform runs, because a paper asking for scrutiny should accept it before requesting it.

2The premise: preparedness is being funded as things

The Preparedness Union Strategy, published in March 2025 and past its first-year review in March 2026, is a serious document and its direction is right. Our concern is with what happens further down, when a strategy becomes an instrument and an instrument becomes a call for proposals. At that point capability has to be described in terms a budget can carry, and the terms a budget carries most easily are objects.

An object has an owner, an address, an inventory number and a depreciation schedule. The coordination layer has none of those. It sits between organisations rather than inside one. No ministry owns the interface between a fire service in one country and a water authority in another, and no agency's asset register carries a line for the shared picture that three of them need on the same morning. So it is nobody's line item. It is procured, when it is procured at all, as a project after the event that proved it was missing.

This is a specification problem before it is a money problem. Stockpiles, vehicles and shelters can be evidenced at rest: counted in a warehouse, photographed, audited against a register on a quiet afternoon. Coordination capability cannot be evidenced at rest, because it does not exist at rest. It exists only in the hour in which several organisations need it at once, which means the only honest evidence of it is an exercise, and an exercise is a harder thing to place in a funding instrument than a number of pumps. What cannot be counted is not thereby unimportant. It is merely unfunded.

The failure that follows is not that nobody comes. Help comes. It is that what arrives cannot be directed, because the people who came do not have what the plan assumed they would have. The Netherlands Institute for Public Safety evaluated how the National Rescue Fleet, the volunteer rescue organisation called on during the July 2021 floods, was alerted and deployed. Its report records what that was like from the inside, in the words of the people it spoke to: units had to act headlong, because the request for assistance had been so long in coming, without information about the area they would encounter or the facilities that would be there for them.

Netherlands Institute for Public Safety (NIPV), evaluation of the National Rescue Fleet deployment, 24 March 2022, section 3.1, page 18. Translated from the Dutch. nipv.nl (PDF)

What follows from that for an instrument, rather than for an operation, is narrow and testable. If the coordination layer is preparedness capability, it needs three things a strategy cannot supply on its own. A line that names it, so that it stops being every plan's assumption and no budget's responsibility. Acceptance criteria that are demonstrated in a multi-agency exercise rather than audited against a register, because the exercise is the only place the capability is visible at all. And an owner at the level where the boundary actually sits, which is between organisations and between states rather than inside either, since the reason this goes unfunded is not that anyone objects to it. It is that the question of whose line it is has never had an answer, and a question with no answer does not become a line item.

Capability that only exists after the event is not preparedness. A pump that arrives without a task is not a capability, and neither is a crew that arrives without a picture.

3What sovereignty means for operational software

The word is used loosely enough in procurement documents that it has nearly stopped meaning anything. For operational software we take it to mean four separate things, set out here in order of how hard each is to change after signature. The first cannot be changed at all.

1. A European company, European engineering, no foreign parent

   LIVEOP B.V. is incorporated in the Netherlands. The platform is designed, built and maintained by its own engineers. There is no non-European ownership and no non-European investor control in the company. We state it plainly because this is the pillar that cannot be retrofitted: a hosting region can be changed in a deployment, and a jurisdiction of incorporation cannot be changed by a contract clause. The ownership and control statements above are the part of this paper a buyer can check without taking our word for any of it: they are a matter of public record in the Dutch company register.

2. Your region, your tenant, your administration

   The platform is deployed in the region the customer requires, with per-organisation data separation, encryption at rest and in transit, and geo-redundancy. Administration belongs to the customer: users, roles, vehicles, security profiles and single sign-on are managed by the organisation itself rather than by us on a ticket. The practical test of this pillar is not what a contract says about ownership of data. It is whether the customer can change who sees what, on a Tuesday afternoon, without asking the supplier.

3. The data that cannot leave does not leave

   Some classes of data cannot cross a boundary, whether for legal reasons, for national security reasons, or because the organisation has decided so and does not need to justify it further. LIVEOP supports hybrid deployment, with those classes held on the customer's own premises while the rest of the platform runs as a managed service. This carries further than a residency clause, because residency answers where data is stored and hybrid answers what never leaves the building at all.

4. An exit you can cost

   What a service buys from us is the platform, and the test of that is whether it can leave with what it put in. LIVEOP is built as cloud-native services and is deployed either as a managed service in the region the customer requires, or hybrid, with the classes of data that cannot leave held on the customer's own premises. Data and configuration come out in standard, documented formats, with geographic data through open standards rather than a proprietary bridge. The measure of this pillar is exit: whether an organisation that decided to leave could take its data and its configuration with it, at a cost it could estimate in advance. We think that should be scored in procurement, and section 7 asks for it, of us as much as of anyone else.

4The question everyone asks: where does it run

Every serious conversation reaches the same question, usually about twenty minutes in. If you are arguing for European control, where does your own platform run? It is the right question, and a paper that stepped around it would deserve the scepticism it got.

LIVEOP runs on Microsoft Azure. We deploy into the region the customer requires, and we support hybrid deployment, so the data a customer cannot let leave its own premises does not leave them. That is the whole of the answer, and a reader should have it from us rather than find it later and start wondering what else was phrased carefully.

We do not think that settles the question, so here is our position on it. Sovereignty for operational software is decided by four things: who owns the company, which law reaches it, who holds the data, and whether the customer can leave. Hosting bears on the third. Ownership and jurisdiction are the first two, and they are the two a contract cannot repair afterwards, which is why we would ask a buyer to weigh them in that order. A European platform hosted on non-European infrastructure and a European data centre running software owned elsewhere are not the same exposure, and it is the second that is more often presented as sovereign.

We would rather state the residual risk than argue it away. A dependency on a non-European infrastructure supplier is a real dependency, and the answer to it is not a clause. What we can say is what is true today: the classes of data that cannot tolerate the dependency are held on the customer's own premises, the platform and the company are European, and the decisions about both are taken here. What we will not do is tell a reader that we could move off that infrastructure tomorrow at a price we have already worked out. A buyer who needs that answer should ask us for it in writing and score what comes back, which is precisely what the second ask in section 7 would oblige every supplier to face, ourselves included.

The same question arrives a second time about devices, so it gets the same treatment. Our field and vehicle applications are built natively for iPhone, iPad and Apple CarPlay. That is a deliberate specialisation rather than an abstraction: supporting every device means testing none of them properly, and emergency services already buy certified radios and certified appliances instead of compatibility lists. The hardware is a commodity, procured from any reseller on an open market and swappable, and the operational data a device shows comes from the customer's own tenant. The office, action centre and control-room applications run in a browser on any platform. We have no partnership with Apple and claim none. The association is a consequence of building natively on the devices our users already carry.

5Why the coordination layer in particular

Not every system in a public body carries the same consequence if control over it is lost. A payroll system holds salaries. A document store holds documents, most of which are already circulating. The coordination layer of an emergency service holds something else, and it holds it continuously.

At any moment it holds:

• the live position of every responder and every vehicle on duty, and which of them are committed and which are free;
• the location, nature and severity of every incident in progress;
• which areas have been evacuated, which have not, and the routes in and out of both;
• and, through the data a service connects to it, the addresses of the people who cannot evacuate themselves: the ventilator dependent, the bedbound, the care homes, the schools, and the buildings holding substances that decide how close anyone can get.

Each of those is held for a good operational reason, and each is the right thing for such a system to hold. Together they are a description of a region's capacity to protect itself, current to the minute.

The argument that matters is about timing. This picture is at its most complete and most useful at exactly the moment it would be most damaging to lose.

On a quiet Tuesday, knowing where every ambulance in a region is has modest value. During the week a country is absorbing a flood, a large fire, a cyber incident or a deliberate act, the same picture tells anyone holding it which services are already committed, which parts of the region are uncovered, which streets hold people who cannot leave, and how long help would take to reach anywhere. The Preparedness Union Strategy is built on an all-hazards approach, one frame holding natural disasters alongside deliberate and hybrid threats. Planning that takes that approach seriously has to allow for the two arriving together, or for one being used to mask the other. The risk carried by the coordination layer follows the same curve as everything else in that assumption: it peaks precisely when the rest of the system is least able to absorb it.

That is why we think this class of software should be considered separately from public-sector software in general. Not because European suppliers deserve preference, which is an argument we would not make, but because the question of which government can compel disclosure from the company holding this particular picture is an operational question and not only a legal one.

Three properties follow, and each can be tested in a procurement rather than asserted in a brochure.

1. Jurisdiction

   Which country's law reaches the company holding the data, which courts can compel it, and whether a change of ownership could change the answer without the customer's consent. That is a question about the supplier, not about the data centre, and it is answerable in writing before signature.

2. Degraded operation

   Whether the picture survives the outside world failing. A coordination layer that stops when connectivity, a supplier or a region stops is not a preparedness capability. It is a fair-weather one, and it will be measured on the only day it matters.

3. Governed sharing, held by the customer

   Who sees what has to be something the organisation configures itself and can change without the supplier. In LIVEOP an incident can cross an agency boundary while the patient information inside it stays hidden or is shown anonymised, with personal identifiers in message content masked, and access filtered by discipline, priority, classification, station, municipality, linked units, assigned unit, incident source and status. A profile can be scoped to crisis incidents only. Widening access remains an act the organisation performs: a profile it configures and assigns, on its own authority, at the moment it chooses.

This is where the sovereignty argument stops being about principle. It is a specific list of people, at their specific addresses, who would not be able to leave.

6Cross-border by design

In July 2021 one weather system crossed three countries. Each had its own command structure, its own control-room systems and its own way of describing the same rivers. The event was one event. The coordination of it was three.

Mutual aid across borders is already policy. The Union Civil Protection Mechanism exists so that a member state can ask and others can answer, and it works. What is not yet policy is the picture. A shared operational picture across a border is not a scored requirement in any procurement we are aware of. Interoperability is declared in a tender response and, so far as we have seen, rarely demonstrated under test, so each country independently buys a system that is excellent inside its own boundary and silent at the edge of it.

Crossing a border operationally does not require one European system, and we are not proposing one. It requires three ordinary things: that a picture can cross, that a neighbour's geographic and incident data can be read through open standards rather than through a bespoke project each time, and that two services on either side of a line have already done it in an exercise before an event asks them to.

The public record of the July 2021 response in the Netherlands, and what those days asked of the services that came to assist, is set out on a separate page. The wider argument about what arrives with reinforcement, and what it needs in order to be useful on arrival, is on the preparedness page.

7What we ask of policymakers

Four asks, addressed to the people writing the 2028 to 2034 instruments and the national programmes that will draw on them. Each is meant to be implementable as a line in a work programme or a row in an evaluation grid, rather than as a sentiment.

1. Fund the coordination layer, not only the equipment.

   An instrument that can buy a pump, a shelter and a stockpile but cannot buy the system that tells them where to go is funding part of a capability and recording it as the whole. Make multi-agency coordination and shared situational awareness an eligible category in its own right, with its own budget line, instead of an administrative cost attached to something physical.

2. Make interoperability and exit scored requirements rather than checkboxes.

   Every supplier can tick a box marked open standards. Far fewer can show an operational picture crossing into a neighbour's system under observation, or produce a costed and time-bounded exit plan. Score what can be demonstrated in a test, and weight it enough to change an outcome. A requirement that cannot be failed is not a requirement.

3. Treat cross-border shared situational awareness as preparedness infrastructure.

   Agreements between neighbouring regions are written, signed and then exercised on paper. Fund the exercising of the picture itself, with the test being that two services across a border run one incident together, observed, before an event requires it of them. Against any physical capability this is inexpensive, and it is the part that will not improvise itself on the day.

4. Keep the software that holds responder and citizen location under European control and law.

   This is the narrow ask, and the narrowness is the point. We are not arguing for European preference across public-sector software. We are arguing that for one class of system, the class holding live responder positions and the addresses of citizens who cannot evacuate themselves, ownership, jurisdiction and exposure to foreign compulsion should be scored, and the ability to keep running degraded, or on the customer's own premises, should be required rather than preferred.

Note on the figures. The budget amounts in section 1 are those proposed for the 2028 to 2034 multiannual financial framework and under negotiation at the date of this paper. They should be re-verified against the adopted instruments before being cited.