The layer you sign first and read last

A company that should have been sovereign

Some time ago I worked with an organisation that, on paper, owned its data outright.

The hardware was theirs. The server sat in a room they held the key to. They maintained the software on it themselves. They could log in to the database, query it, change its schema, update rows, and delete them.

Then they wanted to integrate that data with a new platform, and the contract said no. Or rather: yes, but only through the original supplier, and at a steep starting price. They held the data; moving it anywhere else ran through the vendor that had built the system years earlier.

On every layer they could see, they were sovereign. On the one they could not, they were not.

The fourth layer

Part 1 described data sovereignty as three rights, to possess, use and dispose, held across three technical layers: the hardware data runs on, the software that processes it, and the data itself. By that test, Part 1’s municipality failed at the bottom of the stack: it held its residents’ data while the hardware and software underneath belonged to someone else. The organisation above is the mirror image. It owned all three layers outright and still could not act. Put the two cases side by side and the pattern shows itself: sovereignty fails at whichever layer is weakest, and not every layer is made of technology.

There is a fourth layer underneath the other three, and it decides whether the rights can be exercised at all. Call it the organisational layer: the contracts, licences, service terms and governance arrangements that sit between you and your data. It is where the right to act is actually allocated. The academic model from Part 1 gives the agreement the same weight: in von Scherenberg, Hellmeier and Otto’s seven-aspect model, the contractual agreement “is located in the middle, as it consists of the main conditions for maintaining control over data assets” (von Scherenberg et al., 2024). The data asset is the thing the model protects; the agreement is where the protecting is decided.

Part 1 ended on enforcement: a contract alone is only a promise until infrastructure applies it. That cuts both ways. Infrastructure can only enforce rights the agreement actually grants, and neither safeguard closes the risk on its own (Irion, 2012). The law adds a further limit: the access and portability rights that EU data law grants are, as one analysis of the Data Act’s draft put it, “rights in personam”, claims you hold against a specific party rather than control of a thing (Geiregat, 2022). Your sovereignty is only ever as strong as your agreement with whoever holds the keys.

The first three layers are visible. You can point at the server, open the database, read the code. The fourth is invisible until the moment you try to act, and by then it has already decided the answer.

Why it is the layer that bites

Two things make the organisational layer dangerous.

The first is timing. The contract is signed at the start, before anyone knows everything the data will be used for. The organisation above had agreed its terms when the system was first built; the integration those terms blocked was not even on the table yet. This is the ordinary shape of “lock-in”, and its economics have been understood for decades: switching costs are low to enter and high to leave, so an incumbent can win the work cheaply and charge for every change afterwards (Klemperer, 1987, 1995). The lock is not only commercial. Habit and inertia do the same work from the inside (Murray & Häubl, 2007; Polites & Karahanna, 2012), and my own research finds the same pattern in regulated organisations (Everaars, 2024).

The second is attention. The public debate is about the layers you can see: “sovereign cloud”, “sovereign software”, open data standards. In the projects we see, the contract draws real scrutiny only once something is already blocked: this organisation signed its terms on day one and read them closely years later, on the day it wanted to move. A signature is also easily mistaken for protection in itself, when terms offered on a take-it-or-leave-it basis bind you without protecting you (Rhoen, 2016).

The same trap is visible in public bodies, because they have to publish. In October 2023 the municipality of Kampen, which buys the Centric applications it has long relied on through a shared service centre (SSC ONS) with Zwolle and the province of Overijssel, set out in a formal decision why it wanted to renegotiate the supplier’s standard terms: those terms were “éénzijdig, geschreven vanuit opdrachtnemers kant” (one-sided, written from the supplier’s side), with the risks and liabilities resting mainly on the customer. Its answer was to push the new framework onto the municipal sector’s standard IT-procurement terms (GIBIT) instead (Gemeente Kampen, 2023). Nothing here is dramatic: it is the ordinary cost of signing the supplier’s paper, and it is cheapest to question before the architecture and the budget are fixed.

What the contract is really deciding

It helps to read the organisational layer through the same three rights from Part 1, because that is what it grants or withholds.

Possess. Do you have your own copy of the data, in a usable form, with the right to keep it? Or is the only authoritative copy inside the supplier’s system, available to you only while the relationship lasts?

Use. Can you integrate, query and build on the data with tools of your choosing? Or does every new use, like the integration that organisation wanted, have to run back through the vendor?

Dispose. Can you delete the data and prove it is gone, and just as important, can you leave? Exit is the clause we look for first and find least often: the right to export everything in an open format, and to have the supplier’s copies destroyed when you go. EU law has started to push here. The Data Act now requires cloud providers to make switching away easier (Reg. (EU) 2023/2854), and the GDPR’s portability right was meant as an exit mechanism, not only an access one (De Hert et al., 2018). Even so, a recent analysis finds the new EU rules deliver sovereignty only in part (Ryan et al., 2024). A statute sets a floor; the contract sets the rest.

One question sits underneath all three: who else can reach the data? Sub-processors, offshore support, an analytics partner in another jurisdiction. Where another country’s law can compel a provider to hand data over, as the US CLOUD Act can (Daskal, 2015; Cross-Border Data Forum), the contract is also deciding your exposure.

Before you sign

All of this turns into one question worth asking before any signature: when we want to act, who has to agree?

If the honest answer is “the supplier”, you are buying a service, not sovereignty, however much of the hardware and software you own. A few more questions make the layer visible while you can still change it, and they are cheapest to ask before the architecture is built and the budget is signed:

• If we want to move this data to another platform in two years, can we, and at what cost?
• If we want to delete it, can we delete every copy, including the supplier’s, and show that we did?
• Who can read this data today without our explicit approval?
• If the supplier raised its price, changed its terms, or disappeared, what could we do on our own?

How we approach it

This is why we treat portability as a design constraint rather than a feature, and why we are deliberate about our own contracts. A platform built to move keeps the technical layers from trapping you. Terms that give you source-code rights, exit support and the option of escrow keep the organisational layer from doing the same, and ours put that in writing (general terms, articles 11 and 22): no supplier should be able to hold your platform “code hostage”, and that includes us. You should be able to leave HOIST IT as easily as you arrived.

What’s next in this series

Part 1 defined data sovereignty; this part looked at the contract layer that decides whether you can use it. Part 3 turns to the technical layers in practice: the architecture, tooling and data spaces that keep hardware, software and data from locking you in, until the only layer left to negotiate is the one on paper.

References

• Daskal, J. C. (2015). The un-territoriality of data. Yale Law Journal, 125(2), 326–398. https://www.yalelawjournal.org/article/the-un-territoriality-of-data
• De Hert, P., Papakonstantinou, V., Malgieri, G., Beslay, L., & Sanchez, I. (2018). The right to data portability in the GDPR: Towards user-centric interoperability of digital services. Computer Law & Security Review, 34(2), 193–203. https://doi.org/10.1016/j.clsr.2017.10.003
• Everaars, R. (2024). Cognitieve lock-in bij Microsoft 365 (research paper). Nyenrode Business University.
• Geiregat, S. (2022). Who owns “your” (business’s) digital data? Oxford Business Law Blog (blog post). https://blogs.law.ox.ac.uk/oblb/blog-post/2022/12/who-owns-your-businesss-digital-data-new-eu-law-making
• Irion, K. (2012). Government cloud computing and national data sovereignty. Policy & Internet, 4(3–4), 40–71. https://doi.org/10.1002/poi3.10
• Klemperer, P. (1987). Markets with consumer switching costs. The Quarterly Journal of Economics, 102(2), 375–394. https://doi.org/10.2307/1885068
• Klemperer, P. (1995). Competition when consumers have switching costs. The Review of Economic Studies, 62(4), 515–539. https://doi.org/10.2307/2298075
• Murray, K. B., & Häubl, G. (2007). Explaining cognitive lock-in: The role of skill-based habits of use in consumer choice. Journal of Consumer Research, 34(1), 77–88. https://doi.org/10.1086/513048
• Polites, G. L., & Karahanna, E. (2012). Shackled to the status quo: The inhibiting effects of incumbent system habit, switching costs, and inertia on new system acceptance. MIS Quarterly, 36(1), 21–42. https://doi.org/10.2307/41410404
• Rhoen, M. (2016). Beyond consent: Improving data protection through consumer protection law. Internet Policy Review, 5(1), Article 404. https://doi.org/10.14763/2016.1.404
• Ryan, M., Gürtler, P., & Bogucki, A. (2024). Will the real data sovereign please stand up? An EU policy response to sovereignty in data spaces. International Journal of Law and Information Technology, 32(1), eaae006. https://doi.org/10.1093/ijlit/eaae006
• von Scherenberg, F., Hellmeier, M., & Otto, B. (2024). Data sovereignty in information systems. Electronic Markets, 34(1), Article 15. https://doi.org/10.1007/s12525-024-00693-4

Further reading

• EU Data Act, Reg. (EU) 2023/2854 and Data Governance Act, Reg. (EU) 2022/868
• Part 1: What it really means to own your data