§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.
What is workload sovereignty, and how is it different from data sovereignty?+
The property is usually called operational sovereignty — Gartner, Red Hat, IBM, Microsoft and the EU Cloud Sovereignty Framework all use data, operational, and technological sovereignty as the three pillars — but “workload sovereignty” is a common way to ask about it, and it names the same thing: control of the execution plane rather than the storage layer. Data sovereignty asks whose law governs the data and who can compel access to it. Operational sovereignty asks the same question about the compute: where does the processing actually execute, and who can reach it while it is running? The two come apart more often than vendor material suggests. Data can sit at rest in a compliant in-country region while the workload that reads it is scheduled by a control plane you do not operate, on a host image you did not build, administered by staff you cannot name — and whoever holds that control plane can attach a debugger, read process memory, or schedule a neighbouring workload on the same hardware. Closing that gap means owning the scheduler and the hosts, not only the disk: your own Kubernetes control plane on hardware you control, images you build and sign, and remote attestation proving what is running is what you shipped. It matters most for AI inference, where the data of greatest value sits in memory rather than on disk for the whole time the model is answering. Note it is a different question from SPIFFE-style workload identity, which is how services prove themselves to one another — that is authentication between workloads, not control over the machine beneath them.
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.