Digital sovereignty is the set of controls that decide who can compel access to your data, not merely where the disks sit. For a security team buying cloud, communications, AI or exposure-management tooling in Europe in 2026, it is a scored procurement requirement. The European Commission grades cloud tenders on eight sovereignty objectives; Swiss and UK buyers are writing equivalent tests into RFPs even when they sit outside EU law.
The longer legal and market treatment is the Panop Research paper Digital Sovereignty: Why, What, How. This article is the operational reading: what to put in the scorecard, and why an exposure-management platform is part of the same decision.
What digital sovereignty is, in one definition
Security keeps data from people who should not have it. Residency fixes the country or region where it is stored. Sovereignty decides whose law, and whose staff, can reach it anyway.
A provider can encrypt everything, publish an ISO 27001 certificate, and keep copies only in Frankfurt, and still be obliged to produce that data to a foreign authority. The CLOUD Act reaches the provider, not the building. That is why a tender that only asks “is the data in the EU?” is answering the residency question and leaving the sovereignty question blank.
Why this landed on the CISO’s desk
Three things moved at once, and none of them is a values debate.
Boards started treating foreign dependency as an operational risk alongside ransomware. Public buyers started scoring sovereignty, with a floor below which a bid is rejected. And the estate itself changed: voice, prompts, transcripts and exposure graphs are now production data, not log files you can wave through on a processor-to-processor clause.
Gartner has forecast that more than 75% of enterprises will have a sovereignty strategy by 2030. Swiss market research in 2026 still finds hybrid cloud as the default pattern: sovereign workloads held beside global services, not a single flag on the contract. The UK NCSC reported a roughly 50% rise in attacks over 2024–25, which is why “we will deal with jurisdiction after the incident” is no longer a plan.
Security teams feel this first because they buy the tools that see everything: EDR, SIEM, CSPM, and now exposure management. An exposure graph of your attack surface is among the most sensitive datasets you will ever generate. If that graph is hosted by a vendor whose government can compel it, you have bought a new dependency in the name of reducing risk.
The scorecard: five controls, each of which costs something
Sovereignty is bought in increments. Each control below raises assurance on one dimension and takes something away on another.
- Classify first. Canada caps public cloud at Protected B. If you have not said which data class this tool will hold, you are negotiating in the dark.
- Hold the keys. Encrypt with keys the provider cannot use. Processing is the remaining gap: data must still be decrypted to be analysed.
- Write disclosure into the contract. Clauses that compel notice of access, where notice is lawful. Some orders forbid notification; the clause still creates a record of what you asked for.
- Local operation. A national operator, a certified host, or a company that is itself incorporated where you need it to be. Germany’s trusted-operator model and Australia’s hosting certification framework are two different answers to the same worry.
- Keep an exit. A tested migration path is what keeps the other four negotiable at renewal.
No single row delivers sovereignty. Residency without key control is geography. Key control without an exit is dependency with better encryption. The working paper maps those rows onto the EU’s SEAL-0 to SEAL-4 assurance levels.
What this means when you buy exposure management
Apply the same five rows to EASM, CTEM and pentest platforms. They collect the map of what you actually own.
| Question on the RFP | What a complete answer names |
|---|---|
| Where is customer exposure data stored? | Country, operator, and whether that can be changed by the vendor alone |
| Under which law is the vendor incorporated? | Not the same as the data-centre pin |
| Who can compel production of the graph? | CLOUD Act, Chinese Cybersecurity Law, and equivalents, named rather than implied |
| Can EU or Swiss staff run the service unaided? | Operational sovereignty, not a logo |
| What is the exit? | Export of findings, evidence and asset graph in a usable form |
Panop SA is a Swiss company. Customer exposure data is hosted in Switzerland. That pair of facts is residency plus jurisdiction for Swiss buyers, and a distinct cell on an EU scorecard that already has an EU-hosted option. It is not a claim that foreign law never applies to anyone in the chain; sub-processors are listed, and the Trust Center is the place that document lives.
Fill those rows from each shortlisted vendor’s public documents, not from a slide. Sovereignty questions belong on the RFP, asked the same way of every bidder.
What to do this quarter
If a renewal or a CTEM shortlist is already in flight, you do not need a sovereignty programme. You need the classification, the two jurisdiction questions, and an exit clause in this contract.
- Name the data class the exposure graph belongs to, in writing.
- Ask every shortlisted vendor where the data sits and where the company is incorporated. Put both answers on the same page.
- Require export of the asset graph and the evidence pack in a documented format, tested once before signature.
- Read the paper before the legal review, not after. The SEAL language is what EU public buyers will use on you.
Sovereignty has stopped being a position you hold. It is a specification you either wrote into the order form or you did not.