Skip to content
Stribog

§00/Data Sovereignty

Data sovereignty, engineered.

Where your data lives, who holds jurisdiction over it, and whether you can prove control are engineering decisions — not clauses in a policy PDF. The regulations differ by country; the answer is the same everywhere: own the perimeter, run inside it, and keep the evidence.

§01/What Sovereignty Means

Three words the market blurs — and why the difference is architectural.

“Data residency,” “data sovereignty,” and “digital sovereignty” get used interchangeably in vendor decks. They are not the same, and the gap between them is exactly where compliance risk hides. Each is a different engineering property.

  1. §01

    Data residency

    Where the bytes physically sit. A jurisdiction requirement: this data must be stored on hardware inside this country's borders. The weakest guarantee — a managed service can satisfy residency on paper while replicating, caching, or routing your data through regions you never see.

  2. §02

    Data sovereignty

    Whose law governs the data, and who can compel access to it. Data stored in-country but operated by a foreign-headquartered provider can still be reachable under that provider's home-country legal process. Sovereignty is about jurisdiction over control, not just location of storage.

  3. §03

    Digital sovereignty

    Independence of the entire stack that processes the data — the compute, the models, the operational tooling, the ability to keep running if a vendor withdraws. The strongest property, and the one owned infrastructure is uniquely positioned to deliver.

Residency is table stakes. Sovereignty is the real bar most regulations are reaching for. Digital sovereignty is the durable version — and it is only reachable when you own the perimeter the data runs inside.

§02/The Method

One engineering answer for every jurisdiction.

Chasing a separate architecture per regulation is how teams end up with five half-compliant estates and no evidence. There is a simpler discipline: build one owned environment that satisfies the strictest demand you face, and the rest resolve as special cases of it.

§01

Keep data inside a perimeter you own

Personal data, payment records, PHI, and model inputs stay on infrastructure your team operates — private cloud, colocated bare metal, or in-country region — not on managed services whose internals you cannot inspect. Residency and jurisdiction stop being promises on a vendor's compliance page and become facts about where your hardware is.

§02

Run inference where the data already lives

The largest new data-liability surface is AI. Open-weight models on dedicated GPU nodes inside your cluster mean regulated data is never posted to a third-party inference endpoint you cannot audit. No cross-border transfer, no opaque logging, no data-processing agreement standing between you and a regulator's question.

§03

Produce evidence as a side effect of operation

Admission controllers log every policy decision. Access is reviewed on every pull request. Audit logs carry cryptographic integrity so tampering is detectable, and retention lives in a jurisdiction you control. When an auditor or a data-protection board asks for proof, it already exists — you are not reconstructing it under a deadline.

§04

Design the exit before you need it

Data in open, portable formats (PostgreSQL, S3-compatible object storage, OTLP). Workloads on any Kubernetes distribution, not a single vendor's API. If a jurisdiction, a provider, or a regulation changes under you, migration is a planned operation — not a two-year rebuild that itself becomes the compliance risk.

§03/Regulation by Region

The same discipline, read against the law that applies to you.

Every jurisdiction is converging on the same demand — control over data, evidence of that control, and resilience you can prove. What differs is the statute doing the asking. Here is how owned infrastructure answers each, starting where we are: India.

§01PRIMARY-MARKET

India

India's data regime moved from principle to statute — and much of it mandates on-shore control that self-hosting satisfies literally, not by attestation.

DPDP Act, 2023

The demand

The Digital Personal Data Protection Act makes a Data Fiduciary accountable for lawful, consent-based processing of digital personal data, breach notification to the Data Protection Board, and Data Principal rights — access, correction, and erasure. Significant Data Fiduciaries carry added duties: data-protection impact assessments and independent audits.

Owned infrastructure

When you own the storage layer, erasure and correction are operations you can actually perform and evidence, consent state is a record you hold, and processing history is auditable end to end. You cannot honor a data-principal right you have delegated to a black box.

RBI payment-data localization

The demand

The Reserve Bank of India requires the entire payment data lifecycle to be stored only within India. Storage is on-shore, full stop — a hard localization mandate, not a preference.

Owned infrastructure

In-country self-hosted storage meets this by construction. The failure mode is a managed data or inference service that transparently replicates or routes payment data to a region outside India — a localization breach you cannot see because you do not control the data path.

CERT-In Directions, 2022

The demand

Report cyber incidents within six hours of noticing them, enable and retain logs for 180 days within Indian jurisdiction, and synchronize system clocks to an Indian time source.

Owned infrastructure

Self-hosted, integrity-verified logging with in-country retention and your own observability stack answers this directly. Six-hour reporting and 180-day log custody are hard to satisfy when the logs live in an opaque service you cannot query or hold.

Sectoral residency (SEBI, IRDAI)

The demand

Securities-market and insurance regulators layer their own systems-audit, data-localization, and resilience obligations on top of the general regime for regulated financial entities.

Owned infrastructure

One owned, well-documented environment produces the systems-audit evidence and data-locality guarantees these regulators expect — without standing up a separate compliance estate per authority.

Sovereign AI — inference inside your perimeterCloud repatriation capabilityTalk through an India-jurisdiction estate
§02SECONDARY-CAPTURE

European Union

The EU writes the world's most demanding data and AI law. Every requirement resolves to the same root: control you can evidence, inside a boundary you own.

EU AI Act

The demand

High-risk AI systems must meet obligations for data governance, logging and traceability, transparency, human oversight, and robustness — with records a supervisory authority can inspect.

Owned infrastructure

On-premises inference keeps the data, the model, and the decision logs inside your audit boundary, making the Act's record-keeping a property of the system rather than a bolt-on.

GDPR after Schrems II

The demand

Schrems II raised the bar on transferring EU personal data to third countries — standard contractual clauses now require supplementary measures, and US-bound transfers carry real legal exposure.

Owned infrastructure

Keep EU personal data on EU-region infrastructure you operate and the transfer problem disappears: there is no cross-border flow to justify, document, or defend.

NIS2 & DORA

The demand

NIS2 raises cyber-resilience duties for essential and important entities; DORA imposes operational-resilience and ICT-risk requirements on the financial sector — both demanding tested recovery and demonstrable control over your systems.

Owned infrastructure

Owned, GitOps-driven infrastructure with practiced recovery procedures produces the resilience evidence these regimes ask for — not vendor SLAs, but audit trails and runbooks your team can produce on demand.

EU AI Act & high-risk systems: on-prem inferenceNIS2, DORA & the EU AI Act for self-hosted KubernetesSee the capabilities
§03GEO-NEUTRAL + VERTICAL

United States

US pressure is sectoral and framework-driven rather than a single sovereignty statute — but the same owned-infrastructure discipline answers each demand.

HIPAA (healthcare)

The demand

Protected health information carries safeguard obligations and business-associate agreements governing every party that touches it.

Owned infrastructure

Self-hosted storage and inference keep PHI inside a perimeter your BAAs actually cover — rather than routing it through a managed endpoint whose subprocessor chain you cannot fully enumerate.

SOC 2 & ISO 27001

The demand

The trust frameworks buyers and partners require worldwide turn on one thing an auditor can act on: evidence, produced consistently, not attested annually.

Owned infrastructure

Evidence-by-default infrastructure — policy-as-code, automated access review, integrity-checked logs — makes these frameworks a byproduct of how the system runs.

FedRAMP & data residency

The demand

Government and regulated buyers require authorized, isolated environments with hard guarantees about where data lives and who can reach it.

Owned infrastructure

Sovereign, owned environments give hard residency and isolation guarantees by construction — the strongest possible answer to a residency question is hardware you control.

HIPAA-compliant self-hosted LLM: PHI on-premModel the trade-off

§04/What This Is Not

Sovereignty is intentional, not isolationist.

Owned infrastructure is a discipline, not a doctrine. The honest version names its costs.

§01

It is not air-gapped purism

Sovereignty does not mean refusing every external dependency. It means every external dependency is a documented, deliberate risk acceptance — not an invisible assumption you discover during an incident. Some managed services earn their place; we will say which.

§02

It is not free

You trade metered convenience for operational responsibility. The gain is predictable economics, jurisdictional certainty, and audit evidence you own; the cost is a team that can run the system. We build for handoff so that team is yours, not ours.

§03

It is not legal advice

We are engineers, not your counsel. We build the technical controls a regulation demands and the evidence that proves them — your legal and compliance functions own the interpretation. The two disciplines work best in the same room.

§00/The Five Pillars

§01

Sovereignty

OWN-THE-PERIMETER

Engineering teams owning the full stack they depend on — no invisible landlords, no rented foundations.

§02

Open source as method

OSS-AS-DISCIPLINE

Open source is a discipline of review, contribution, and independence — not a license type to tick on an audit form.

§03

Audit-grade rigor

EVIDENCE-BY-DEFAULT

Security and compliance aren't retrofit — they are the bar that makes self-hosting safe in regulated, serious environments.

§04

Optionality

EXIT-RAMPS-DESIGNED-IN

Anti-lock-in by architecture: every layer has a documented exit ramp so no vendor can hold you hostage.

§05

The long game

BUILT-FOR-DECADES

Systems proportioned to outlast the tools, vendors, and leadership changes that will come in the decade after delivery.

§05/Put sovereignty to work

Score your sovereignty readiness across the five pillarsRead →Model a cloud-repatriation TCORead →See the capabilitiesRead →

§06/FAQ

Questions, answered plainly.

The questions we hear most from CTOs, engineering directors, and founders considering a sovereignty engagement.

What is the difference between data residency and data sovereignty?

Data residency is about where the bytes physically sit — a requirement that data be stored on hardware inside a given country. Data sovereignty is about whose law governs the data and who can compel access to it. Data can be resident in-country yet still be reachable under a foreign provider's home-country legal process, which satisfies residency but not sovereignty. Owning the infrastructure the data runs inside is how you close that gap.

How does self-hosting help with India's DPDP Act?

The Digital Personal Data Protection Act, 2023 makes a Data Fiduciary accountable for consent-based processing, breach notification, and honoring Data Principal rights such as access, correction, and erasure. When you own the storage layer, those rights are operations you can actually perform and evidence, consent state is a record you hold, and processing history is auditable end to end — none of which you can guarantee when the data lives in a service you cannot inspect.

Does RBI payment-data localization require on-premises infrastructure?

The Reserve Bank of India requires the entire payment data lifecycle to be stored only within India. It does not mandate a specific technology, but in-country self-hosted or owned infrastructure satisfies the localization requirement by construction. The common failure mode is a managed data or inference service that transparently replicates or routes payment data to a region outside India — a localization breach that is invisible precisely because you do not control the data path.

Can we run AI and LLMs without violating data-residency or transfer rules?

Yes. Open-weight models (Llama, Mistral, and similar) deployed on dedicated GPU nodes inside your own cluster mean regulated data is never sent to a third-party inference endpoint. There is no cross-border transfer to justify under GDPR after Schrems II, no data leaving Indian jurisdiction under RBI or CERT-In rules, and the model's decision logs stay inside the audit boundary the EU AI Act expects.

Is this only relevant for the EU, or does it apply to India and the US too?

The regulations differ by jurisdiction, but the engineering discipline is the same everywhere. India's DPDP Act, RBI localization, and CERT-In directives; the EU's AI Act, GDPR, NIS2, and DORA; and US frameworks like HIPAA, SOC 2, and FedRAMP all converge on one demand — control over data plus evidence of that control. One owned environment, built to the strictest bar you face, answers all of them as special cases.

What does CERT-In require, and how does owned infrastructure satisfy it?

India's CERT-In Directions (2022) require reporting cyber incidents within six hours of noticing them, enabling and retaining logs for 180 days within Indian jurisdiction, and synchronizing clocks to an Indian time source. Self-hosted, integrity-verified logging with in-country retention and your own observability stack answers this directly — six-hour reporting and 180-day log custody are difficult when the logs live in an opaque service you can neither query nor hold.

Is sovereign infrastructure the same as being air-gapped?

No. Sovereignty is intentional, not isolationist. It does not mean refusing every external dependency — it means every external dependency is a documented, deliberate risk acceptance rather than an invisible assumption. Some managed services earn their place; the discipline is knowing which, and being able to leave any of them without a multi-year rebuild.

Executive Briefing

Thirty minutes to clarify your infrastructure risk

Walk us through your vendor footprint and regulatory constraints. We will tell you honestly where sovereignty creates leverage — and where it does not. No pitch deck. No obligation.