Sovereignty relocates trust

Data sovereignty sells itself. Hold your own database, answer to nobody, and the vendor with the security team and the compliance department stops being a party to your clients’ most private material. We build for this and we think it is often the right choice. It is also the argument we most want to state against ourselves, because the version of it that circulates is missing the party it most needs to name.

European law has been precise about who is responsible since 2018 and the precision matters here. Article 4 defines the controller as the party that determines the purposes and means of processing. Article 24 puts on that controller the duty to implement appropriate technical and organizational measures and to be able to demonstrate that the processing complies. Self-hosting changes none of it. An institution that moves the database under its own roof was already the controller and remains the controller, having simply become its own processor as well, and the erasure right a person exercises under Article 17 was always exercised against the controller rather than against whoever happened to be running the servers.

Which is where the honest accounting starts, and our own architecture notes make it in a section written to be uncomfortable. The threat model for a sovereign deployment treats the institution as the trusted role and has no adversary type for the data controller themselves. The mechanism, stated plainly, is that relocating the database adds no adversary to that model and removes none, but it converts the constraint on the party most able to read everything from a technical control into a legal obligation, and legal obligations bind after the query rather than during it. The comparison people reach for, a therapist opening a paper file, understates it by a wide margin. A filing cabinet imposes friction per file. A single statement over a client table returns every disclosure anyone ever made, in seconds, with nothing in the way, and the same notes concede that direct access of that kind sits outside what any application-layer audit log can see.

The cost of this does not land on whoever made the decision. The institution chose the tier; the people whose material is held under it were not asked and in most cases are not told. On a hosted tier a person who wants their data deleted asks the platform and the platform can enforce it, because the platform controls the database. On a sovereign tier that same person has to ask the institution directly, which is fine right up until the relationship is the thing they are trying to leave, and then their only remaining leverage is legal rather than technical. Sovereignty transfers a real power to the institution and transfers a real exposure to everyone downstream of it, and only one of those two parties was in the room.

None of that makes the sovereign choice wrong. It makes the sovereign claim narrower than it sounds, and our own conclusion is the narrow one: this option is not inherently more trustworthy, it is more controlled, and control is a good that some institutions genuinely need and some people genuinely want their practitioner to have. What the argument forbids is letting the word do work the architecture has not done. Say which tier holds someone’s material during onboarding rather than in the terms. Say which of their rights survive it and which now depend on a letter to a regulator. Sovereignty is worth having, and it becomes worth trusting the moment the people who did not choose it are handed the same map as the person who did.