Stop chasing data sovereignty; defend software integrity instead

Look — telling citizens their data must live inside a border is a political narrative dressed up as security policy. The TechRadar piece on data sovereignty gets one big thing right: hoarding data inside a jurisdiction doesn't magically stop malware, backdoors, or supply-chain attacks. It makes people feel safer. Feeling safe and being safe are not the same thing.

Sovereignty as theatrical security
The article is right to call data localization an illusion when it’s sold as a silver bullet. Physical location doesn't change the provenance of the code that touches that data; it doesn't vet the build process or prevent a malicious update from rolling out across servers in the same country. Saying "our servers are domestic" is a statement about control of infrastructure, not about the integrity of the software running on it. Politicians love the optics, lawyers like chokepoints, but threat actors laugh.

Still, the politics aren’t trivial. Nations that demand localization are trying to claw back power over global platforms and ensure legal access to evidence — there’s a coherent sovereignty argument there. But security? Not much. The TechRadar piece hints at this tension and could have pushed harder: policy that aims at national control often ignores the technical vector that actually enables compromise — the software supply chain.

Here’s what nobody tells you: integrity starts long before deployment. It begins with who wrote the code, how builds are produced, whether dependencies are audited, whether artifacts are signed, and whether update channels are authenticated and monitored. Fix those things and data locality becomes a secondary issue. Ignore them and stuffing data into local datacenters is like bolting the office door while leaving the windows wide open.

From an operations perspective — when I was running ops at a Fortune 500, I watched teams treat software like plumbing: you only notice it when it floods. That mindset is exactly why "sovereignty" policies turn into expensive distraction. They redirect scarce security resources into compliance theater instead of CI/CD hardening, code review discipline, and supply-chain transparency. Invest in reproducible builds, artifact signing, and rigorous CI security and you actually reduce systemic risk. Make those investments mandatory, and you’ll block more mass compromises than any localization edict.

If you want proof, look at SolarWinds. That campaign didn’t succeed because data was sitting in the wrong country; it succeeded because attackers slipped into the build process and rode trusted updates into sensitive networks. Every “sovereign” datacenter that installed those updates was just as exposed. The geography of the server rack was irrelevant once the pipeline was poisoned.

Regulation and procurement: where policy should aim
If TechRadar is right about the “real battle,” then regulators and buyers need to change where they write requirements. Stop obsessing over where data is stored. Start demanding proof of integrity: verifiable build processes, signed releases, documented dependency audits, mandatory Software Bill of Materials (SBOM) practices. Dry words, yes, but they describe the controls that stop a compromised library from cascading through thousands of deployments.

Companies that sell cloud or software should be measured on traceability and recoverability. Procurement teams should make secure update mechanisms and transparent SBOMs pass/fail criteria, not nice-to-have appendices. That flips the incentive model. Vendors love chasing features and price because that’s where contracts are won; make integrity a condition of purchase and you’ll see roadmaps bend around secure build pipelines faster than any white paper could manage.

There’s a historical parallel here that TechRadar doesn’t touch. For years, aviation safety focused on pilot error and weather while quietly treating manufacturing defects as unlucky exceptions. It took painful crashes and detailed investigations to force attention upstream, into design, parts tracking, and maintenance records. Software is stuck in the earlier phase: we still talk about “hackers” and “data residency” while the real failure mode sits upstream in opaque build systems and untracked dependencies.

Counter-argument — and where it actually lands
Give me a break if you think data sovereignty is useless across the board. Some localization does improve security in specific, high-value contexts: defense secrets, critical government systems, certain intelligence holdings. Tighter national control can simplify lawful access, align with classified handling rules, and reduce reliance on foreign infrastructure.

But it’s a narrow win. Narrow wins still count — they just don’t scale. The problem is pretending that what works for a weapons program also protects consumer healthcare portals and retail banking apps. When regulators mandate localization for broad swaths of data, they fragment visibility across providers, complicate incident response, and make coordinated patching harder. Fragmentation is gasoline for attackers: different stacks, different rules, slower joint investigations.

Wake up: operational reality demands triage. Protect genuinely sensitive systems with tailored controls, including physical isolation and strict jurisdictional boundaries where needed. For everything else, prioritize software integrity controls that apply everywhere, independent of where servers are physically sited. The location question should come after you’ve proved you can build, ship, and patch software without blindly trusting every component on the path.

TechRadar gets the headline right: the “real battle” is software integrity. The smart governments will quietly shift budget from data-center flags to build-pipeline proof and start asking vendors how they’d spot their own SolarWinds moment before it ships.