On 10 November 2026 heise online reported that Delos, which heise describes as an SAP subsidiary, says its cloud for German federal, state and local government will launch in early 2027. Microsoft is to supply the software and updates, the BSI’s review of its cloud requirements is still underway, and critics keep calling the model sovereignty washing.

You cannot settle that label from the outside, and it matters less than the question underneath it, which applies to every sovereign offering you might buy: what happens to your workload when the upstream supplier stops shipping? That is the cloud update dependency, and you can test for it before you sign.

Here is what Delos and the coverage report. Delos Cloud GmbH, founded in 2022, says it took over operations fully in October 2026, with Arvato Systems as operating partner, and says the datacenters belong to Delos. It holds ISO/IEC 27001 from TÜV Nord Cert for its ISMS and its Direct Connection; the C5 attestations and an IT-Grundschutz-based ISO 27001 are still to come.

The Gesellschaft für Informatik argued in October 2024 that a cloud built on Microsoft technology depends on a continuous supply of Microsoft updates. Delos rejects the charge. We are not going to rule on that; we are going to give you a test that works on any vendor, including us.

A sovereign cloud checklist in five questions

1. Who ships the updates, and who decides what runs?

Separate three roles: who writes the code, who builds and signs the release you actually run, and who decides when it goes into production. Then ask the question that tells you the most: can the operator show you what changed in a release, and ship a security fix itself on its own timetable?

Ask the vendor to name the party at each step, and what the operator does if upstream is slow or silent.

2. Who owns the operator, and what sits above it?

Get the ownership chain from the register, not from press descriptions. heise and trade outlets call Delos an SAP subsidiary, while other coverage ties it to Bertelsmann and Arvato; that gap is why you ask for the cap table.

Then ask a second question about jurisdiction. Delos says the operator is subject to German jurisdiction, which is the point of the structure. The Bundesverband für digitale Souveränität answers that Microsoft remains subject to US law, including the CLOUD Act, so data outflow cannot be fully excluded. Jurisdiction over the operator and jurisdiction over the supplier of your updates are two different exposures, and a tender should price both.

Owning the building tells you where the data sits. Owning the update path tells you who can keep it patched.

3. What access does the upstream have, and who can prove it?

The coverage disagrees with itself here. A Delos spokesperson says Microsoft has “no independent access”; another outlet reports that Microsoft may access the platform only in a controlled and logged way. Delos’s statement is self-reported and unaudited.

Put the access model in the contract: who approves a session, what is logged, and whether the logs reach you. “No access” and “logged access” should never be allowed to blur into each other in a sales deck.

4. What keeps running if upstream updates stop?

Börsen-Zeitung wrote that Delos could keep running without updates for a while, perhaps a few months. Neither that report nor the summaries of Delos’s own claims give a technical basis, so treat it as an assertion, not a property of the platform.

Ask for a dated, written figure and for evidence that someone has tested it, for example by cutting the upstream feed in a staging environment. Ask which components degrade first, and whether security patching stops on day one even if the workloads keep running.

Then ask for the exit plan that goes with it. Exporting your data is the easy half; you also need a destination and a rehearsed migration time.

5. What does each certificate actually cover?

Read the scope statement, not the logo. Delos’s ISO/IEC 27001 covers the ISMS and the Direct Connection operation, not the platform’s services. For the C5 attestations, read each one’s stated scope and the period it covers, and check which type it is before you compare two vendors.

The approval path is staged accordingly. States and municipalities can use the platform once C5 Type 1 is done and ISO 27001 is in place. Federal agencies need C5 Type 2 and IT-Grundschutz first, and then a usage recommendation from the Federal Ministry for Digital and State Modernization.

BSI cloud requirements: do not mix up the documents

Two BSI texts get conflated in this discussion. The BSI cloud platform requirements are the ones being reviewed now; heise describes them as requirements for platforms used by the federal administration, and one that Delos and Arvato cite is that all German administration data is processed within Germany. We could not find a public text, so we will not describe their content beyond that.

The Mindeststandard for the use of external cloud services is a separate, published standard that uses the C5 basic criteria as security requirements for cloud providers. If you are buying for a German government body, check which one your procurement actually references.

Treat dates the same way. In September 2024 the target for the German government cloud was availability from 2025; it is now early 2027, and that is a target, not an approval.

How we answer the same questions

Ownership: we are privately held, owned by founders and leadership, nobody outside the company holds a share, and there is no parent or holding company above us on which a foreign order could be served. Operation: we run four datacenters, MAD1 in Madrid, AMS1 in Amsterdam, MUN1 in Munich and HEL1 in Helsinki, all in the EU; the facility operators provide space, power and cooling, and the network and transit are ours. We resell no one else’s cloud, and our Cloud instances run on KVM.

Access: only authorised DIVERSITY staff located in the EU can reach the infrastructure, and administrative access is logged and needs multi-factor authentication. Exit: Cloud instances export as a raw disk image plus JSON configuration, managed databases as a full dump, Object Storage through its S3-compatible API and Bare Metal as a full disk image, with no switching or egress charges. A savings plan still runs to the end of its term, so read the commercial side as well.

Questions 1, 4 and 5 we do not answer here: we do not state our update path or a no-updates fallback in this post, and we will give you both in writing on request. None of that removes upstream dependencies, which every stack has, so hold us to the same standard as any other vendor.

This is the work our IT Consulting team does in architecture reviews and hyperscaler or VMware exits: map each layer of your stack to who ships it and who owns the operator.

What to put in your tender: six items

  • The ownership chain of the operator and of every entity above it.
  • The party responsible for each step from source code to production.
  • The upstream access model, with logging delivered to you.
  • A dated, tested figure for operation without upstream updates.
  • An exit plan with a named destination and a rehearsed migration time.
  • Certificate scopes and periods, with the pending ones marked as pending.

A vendor that answers all six tender items in writing has earned a serious look, whatever the coverage calls it.

Sources