A sovereign cloud is a staffing roster before it is a data centre

My position is that an EU-hosted cloud service has earned the word sovereign only when its provider can show, for any hour of any day, which people could reach a client's data, which legal entity employed them, which country they worked from and under which laws a demand for that data could be made. Where the data centre stands matters, but it is the least informative of those facts. Boards buying or selling such services should ask for the access roster first and the map of data centres second.

I hold this view because I spent much of 2021 and 2022 discovering how far our own service fell short of it. Lumivara runs six data centres, three in Finland and three in Sweden, and we had sold our higher-assurance cloud tier to municipalities, government agencies and banks largely on that basis. The servers were where we said they were. The people were not always. Our round-the-clock operations followed the sun, and overnight administration of some platforms was carried out by a partner's engineers working outside the European Economic Area.

Location answers the easiest question

After the Court of Justice of the European Union invalidated the Privacy Shield in July 2020, European data protection authorities made clear that remote access to personal data from a third country counts as a transfer, needing the same lawful basis and safeguards as copying a database abroad. I am confident of that principle. The detailed guidance on supplementary measures is long, and I would not summarise it from memory. The consequence for a hosting provider is easy to state: a database in Espoo administered at three in the morning from outside the EEA has been transferred, whatever the sales material says.

Three further layers sit beneath location. The first is jurisdiction over the provider itself. A group headquartered outside the EU may receive a lawful demand from its home authorities for data held by its European subsidiary, and incorporating a European entity does not by itself settle that question. The second is subprocessors. The monitoring tool, the ticketing system and the backup software may each send data, or revealing metadata, somewhere else. The third is vendor support. When a database engine or storage system fails in an unusual way, its maker's engineers may need access to diagnose it, and they work wherever the vendor employs them. A provider that answers only the location question has answered the one question that was never in doubt.

None of this means every workload deserves sovereign treatment. Most of our clients' systems hold nothing that would trouble anyone if a vendor's engineer abroad read a log file. My argument is about honest labelling: a client paying for sovereignty should receive it, and a client that does not need it should not pay for it.

Read the access roster, not the brochure

Each client on our sovereign tier now receives a monthly access statement. It lists every role that held administrative access to that client's environment during the month, the employing entity, the country of work, the number of privileged sessions and the tickets that justified them. Access is granted just in time, for a named ticket and a fixed period, and expires on its own. Between 2022 and 2023 we moved night operations for this tier to our own teams in Tallinn and Vilnius. Estonia and Lithuania are EU member states, and the engineers are employed by EU companies within our group. The change costs us about €11 million a year more than the partner arrangement it replaced, and it ended a long relationship with a partner that had done nothing wrong.

The statement changed client conversations more than any certification we hold. A municipal data protection officer can read it in ten minutes and challenge a single line. Twice in the first year a client asked why a particular role had touched its environment. Once our answer had to be that it should not have: an engineer had used a broader access group because it was quicker. We removed the group. Without the statement, nobody outside our team would have known it existed, and I am not certain we would have found it ourselves.

Directors rarely see this layer of a cloud business. When I report to our audit and risk committee, the sovereignty section shows privileged sessions by country of work, the exceptions granted and the subprocessors added or changed in the quarter. A director does not need to understand key management to ask why the exception count has risen, and that question is worth more than a briefing on architecture.

What sovereignty costs and who should pay

The economics are unflattering. Our sovereign tier costs between 18 and 25 per cent more to run than our standard tier for comparable workloads, mostly because of staffing, duplicated tooling and a narrower choice of subprocessors. A provider can absorb that cost to win public tenders and then quietly widen access later to restore its margin. I think that is the most likely way sovereignty claims will fail over the next few years. They will fail through gradual operational convenience, approved one exception at a time, rather than through a dramatic demand from a foreign court.

We chose to price the tier openly, with a published difference from the standard tier, and to let clients use the standard tier wherever their own risk assessment allows. Once the difference was visible, about 40 per cent of our public-sector clients moved some workloads to the standard tier. I count that as a success. Paying for assurance you do not need is waste, and a provider that sells it without saying so is building a business on its clients' inattention.

Some things no provider can promise. We cannot promise that no court anywhere will seek data we hold. We can describe our group structure, the laws that apply to each entity and what we would do on receiving a demand. We cannot certify our software vendors' internal practices. We can contract for EU-based support where it exists and disclose where it does not. Two components of our sovereign stack still depend, in rare fault scenarios, on vendor support from outside the EU. We say so in the access statement, and clients who need to can plan around it.

My advice to a board on either side of such a contract is to ask four questions. Who can reach the data tonight, by role and by employer? From which countries? Which laws could compel any of those people or their employers? And what evidence would show that any answer had changed? A provider that replies with a map of its data centres has not yet understood the question. One that hands over a roster, exceptions included, has begun to answer it.