Digital sovereignty and Microsoft 365
Crisis data is among the most sensitive information an organisation holds. Here is our honest position on residency, access, keys and exit.
Why buyers are asking
Crisis management data includes incident timelines, personnel roles, contingency plans, vulnerability assessments — and in the maritime case, security-sensitive material under the ISPS Code. Increasingly, the question in procurement is not only "is it secure?" but "whose law governs it, who can compel access, and how do we leave?"
Three drivers sit behind that question:
Extraterritorial reach
US-based providers can be subject to US legal instruments that reach data even when it is stored outside the United States. This is the substance of the long-running CLOUD Act and Schrems II debate.
Regulatory direction
EU-level expectations on supply-chain security (NIS2) and data protection have pushed residency, access control and supplier assurance into the contract.
Strategic autonomy
For organisations with critical-society functions, dependency on a single foreign provider is itself a risk to be assessed — not only a cost or a convenience.
What Microsoft actually offers, stated fairly
Microsoft has moved substantially on this, and it is worth being accurate about it:
- EU Data Boundary. A formal commitment covering Azure, Microsoft 365, Dynamics 365 and Power Platform to keep customer content, personal identifiers and support data inside European datacentres.
- Cloud for Sovereignty. Sovereignty controls — data residency, encryption controls, regulated-environment management — delivered as a layer over Azure rather than as a separate cloud, with Sovereign Public Cloud and Sovereign Private Cloud variants, operationally managed within Europe and using external key management.
- Sovereign controls for regulated environments, available in European regions.
The honest reading, and the one the market has converged on, is that sovereignty is a spectrum, not a binary. Microsoft's offering is layered on top of a platform it owns and operates. For many organisations that is entirely sufficient. For others — defence-adjacent, critical infrastructure, or organisations with a hard requirement for control of keys and continuity of access — the layered approach is a mitigation rather than a resolution.
Where Honnimar sits, and why
Honnimar is deeply integrated into Microsoft 365, and that is deliberate. The platform runs on the infrastructure your organisation already operates, uses the identity and access model your people already know, and lives inside the document and collaboration environment they already work in. That is why adoption is fast, why training is short, and why the crisis tool is not a foreign body in your operations. It also means your documents and data are governed by your tenant configuration — not by ours.
Your data sits in your tenant, under your governance. Honnimar is built on a common data store that is owned by the customer. Practically, this means:
- Residency follows your tenant. Where your Microsoft 365 tenant holds data is a decision you make and can evidence — and Honnimar's data lives in the same environment.
- Access control is yours. Granular, hierarchy-based permissions are configured by the application owner through Honnimar Manager, within your own identity model.
- Keys and compliance posture are yours. Encryption, retention, DLP and audit are handled through your Microsoft 365 controls.
- Exit is not a migration project. Because the data store is a common store you own, the data is not locked inside a proprietary Honnimar silo. It is accessible to third-party applications and reporting — Power BI being the immediate example — and readable by other tooling.
- No AI lock-in. AI assistance can be delivered through Copilot or another compliant AI solution of your choosing, rather than through a model we select for you.
A layered strategy
We do not claim that one vendor choice settles sovereignty. No single dependency should be decisive.
Hardened configuration
Turn on and correctly configure the residency, access, retention and audit controls that already exist in your Microsoft 365 environment. Most exposure is misconfiguration, not platform design.
Residency commitment, documented
Know and record where your tenant holds data, including backup and support data paths.
Customer-controlled encryption and key management
Where your risk assessment demands it — external key management and customer-held keys, so that access can be withdrawn.
Data ownership in the contract
Written terms covering ownership, portability, deletion and audit rights, with the export format specified.
A tested exit path
Not a theoretical one: an exercised procedure for getting your data out and continuing to operate.
Optional sovereign data spaces or European components
For the subsets of data where the classification level requires it, rather than for everything by default.
Applied to a crisis platform, these six layers mean the thing that matters most: when the crisis is at its worst, you still have your plans, your logs and your access — and you are not dependent on a vendor's continued goodwill to reach them.
Questions we will answer in the procurement process
We will provide written answers, not verbal reassurance, to:
- Where is our data stored, and where is it processed and supported?
- Who can access it, under what legal instruments, and how is that logged?
- Can we hold the keys? What changes operationally if we do?
- What is the export format, and how long does a full export take?
- What happens to our data and our access if we terminate the agreement?
- Which sub-processors are involved, and how are they assured?
- How do we demonstrate compliance to our own regulator using your documentation?
Sovereignty questions belong in the first meeting, not the last.
Ask us the hard ones. We will put the answers in writing.
Book a demo