What Digital Sovereignty Actually Means

“Digital sovereignty” can sound considerably more impressive than the problems it usually needs to solve.

At the scale of a small community, those problems are often ordinary. Can we reach people if a particular platform changes its rules? Can we move our data if a service becomes too expensive? Can somebody correct information that is wrong? Can the organization continue operating if an account is suspended, a vendor disappears or the person who built the system leaves?

For a community of a few thousand people, sovereignty probably doesn't mean independence from outside systems. That would be difficult to achieve and, in many cases, a terrible use of limited resources. We aren't going to manufacture our own network equipment, and we don't need to operate our own payment rails merely because payments matter. A local organization can run its own servers while depending on an internet provider, operating systems, open-source projects, hardware manufacturers, certificate authorities and software maintained by people scattered around the world. The dependency graph gets large remarkably quickly.

So I find it more useful to ask what happens when one of those dependencies changes.

Suppose a newspaper reaches much of its audience through Facebook. That's useful. The audience is already there, sharing stories and talking about what happens locally, and refusing to participate because the platform belongs to somebody else wouldn't make the newspaper more sovereign. It would simply make the newspaper harder for some people to encounter. The problem appears if the Facebook page gradually becomes indistinguishable from the newspaper's relationship with those readers, because now losing the page doesn't merely remove a distribution channel. It removes access to the audience itself.

The same distinction applies to search. Google can be extraordinarily useful for helping someone find a local story, business or event without becoming the only durable place where the underlying information exists. A payment processor can handle a problem we have little reason to reproduce ourselves while the newspaper retains its own record of who subscribed, what they purchased and what access they should have.

Using another system isn't necessarily surrendering authority to it. The more useful question is which authority we've actually transferred.

That's where digital sovereignty begins to become concrete for me. It means knowing which relationships the organization can continue to recognize without asking another platform for permission, having access to the information necessary to operate, and being able to replace an outside service when replacement becomes necessary even if doing so would be inconvenient. Depending on the problem, that might mean owning infrastructure, maintaining another copy, having a usable export or choosing a boring standard instead of a proprietary interface. It can also mean accepting a dependency because reproducing the capability locally would make the system less reliable rather than more.

Ownership is one tool among several, and that matters particularly at small scale because resources are finite. A community organization can easily spend so much effort becoming independent that it loses the capacity to perform the work the infrastructure was supposed to support. Running a server creates authority over that server, but it also means updates, backups, hardware failures, security and recovery become our responsibility. That trade can make excellent sense when the workload is predictable and the organization has the ability to operate it. It makes much less sense when local ownership creates a critical system that nobody can maintain.

Proximity doesn't automatically create accountability either. Anyone who has dealt with a poorly run local institution knows that being nearby doesn't guarantee responsiveness. A company thousands of miles away may operate a service exceptionally well, while the machine in the next room may remain broken for three days because the one person who understands it is unavailable. Distance changes some failure modes, but it doesn't tell us which system is better.

Geography becomes important when geography is related to the failure we're trying to survive. Ten servers in one building may provide excellent protection against individual machine failures while providing almost no protection against losing the building, which makes a remote copy valuable precisely because it isn't local. The reverse can happen when an outside network path or provider becomes unavailable while the building, local network and machines inside it continue operating normally. Local capability now matters precisely because it fails differently from the remote dependency.

A resilient architecture can use both observations without needing either one to become a philosophy.

Privacy deserves similar treatment. I don't think a community organization becomes trustworthy merely by hosting data locally. A local database can collect far more information than it needs, it can be badly secured, and people with access can misuse it. Privacy begins earlier, with questions about why we're collecting something, what the service actually needs to know, who can access it, how long it needs to remain and whether the information serves the relationship or was merely easy to collect.

Those questions apply whether the database is downstairs or three states away. Local operation can make some answers easier to control. It doesn't answer them for us.

Cost works similarly. Predictable workloads can make owned or fixed-cost infrastructure attractive because capacity planning is relatively straightforward and additional traffic doesn't automatically create a larger bill. A small organization with suitable hardware and technical capability may discover that the economics are excellent, while another may find that maintaining hardware, connectivity, backups and staff knowledge costs considerably more than renting the capability from someone who operates it at enormous scale.

Elastic pricing isn't inherently mismatched with small communities any more than fixed capacity is inherently matched to them. The useful question is whether the cost structure resembles the workload. A regional newspaper with fairly steady traffic may have little reason to pay a premium for extreme elasticity as its primary operating model while still benefiting enormously from outside infrastructure for geographic redundancy, occasional bursts, payments, email delivery or other specialized services.

This is where I think the word “sovereignty” can become misleading if we aren't careful, because it invites us to imagine a boundary around the community with everything important safely inside. There is no such boundary. A community is already a web of relationships extending outward. Its businesses use national banks and payment networks. Its residents use cellular networks. Its newspaper depends on paper, ink, postal systems, telecommunications and software originating elsewhere.

Digital infrastructure doesn't need to pretend otherwise. What it can do is make those dependencies legible enough that we know what happens when one changes. If a provider disappears, what do we lose? If an account is suspended, what can we still do? If a machine fails, where is the information? If a vendor raises its price, can we leave, and if we decide to leave, what comes with us?

If the answer to every question is “nothing changes,” we've probably spent far too much money eliminating dependencies that weren't especially dangerous. If the answer to every question is “the organization stops existing,” we've learned something else. The useful architecture is somewhere between those extremes, and different organizations will put the boundary in different places.

For us, running substantial infrastructure locally makes sense because we have relatively predictable workloads, available hardware and the ability to operate it. It gives us direct control over things we expect to preserve for a long time while allowing outside services to extend what we can do. That doesn't make the outside services guests or the local machines sovereign territory. They're components with different jobs and different failure boundaries.

A social platform can distribute, a search engine can help people discover, a payment processor can process payments, and a remote system can preserve something if our building disappears. Our own infrastructure can maintain the relationships and records we don't want any one of those services to define for us.

That's enough.

For a community under 10,000 people, digital sovereignty doesn't need to mean building a miniature version of the global infrastructure it depends upon. It means deciding which capabilities are important enough to retain, which dependencies are reasonable to accept and what should happen when one of them stops cooperating. Some things can disappear for a while, some can be replaced later, some need another copy, and a few may be important enough that the community should retain the ability to operate them directly.

The difficult part is knowing which is which.

Sovereignty isn't the absence of dependency. It's having enough room to choose what happens when a dependency becomes a problem.