Bert Hubert recently shared something that caught my attention: a blunt reminder that geopolitics can turn into operational risk overnight.

Met de dreigementen over Groenland en de straf-importheffingen die we krijgen is dit overzicht mogelijk nuttig. Welke stukken van onze overheid & maatschappij zijn TOTAAL afhankelijk van Amerikaanse clouds? En zouden bij storing onze samenleving ontwrichten? Het is een schrikbarend lijstje:

That last line, het is een schrikbarend lijstje, is doing a lot of work. Bert is pointing at a simple but uncomfortable question: if the US hyperscalers (or the legal and political environment around them) sneeze, which parts of our public sector and society catch pneumonia?

I want to expand on what Bert is really asking here, because it is bigger than cloud preference or vendor pricing. It is about national continuity: the ability to keep government, care, education, transport, and emergency response functioning when a critical dependency fails, is restricted, or becomes politically contested.

The real issue: dependency that can break society

Bert’s framing matters: not merely whether we use...

US software
US hardware
US services

...but whether we are totally dependent in ways that would be society-disrupting during an outage or conflict.

In risk terms, this is a concentration problem plus a recoverability problem:

Concentration: too many critical workflows rely on a small set of providers, patterns, or identity systems.
Recoverability: even if something fails, do we have an executable plan to continue service within hours or days?

This is why the conversation becomes political quickly. If trade conflicts escalate, if regulatory orders change, or if cross-border data access becomes contested, the risk is not hypothetical anymore.

What counts as critical cloud dependency?

When people hear cloud dependency, they often picture just data storage or email. But the truly destabilizing dependencies are usually the ones that sit under everything else.

1) Identity and access: the single point of failure

If your identity provider is down, locked, or misconfigured, the building might still exist, but nobody can get in. In modern public services, identity is the gate to:

internal admin systems
case management tools
collaboration suites
privileged access for IT operators
citizen-facing portals

A region that cannot authenticate staff cannot process benefits, dispatch resources, or even safely administer its own infrastructure. Identity is not just IT; it is continuity.

2) Communication and collaboration: the nervous system

Email, chat, videoconferencing, document sharing, calendars: these are often centralized on one ecosystem. The operational risk is not only that people cannot send messages, but that:

incident response coordination collapses
documentation and runbooks are unreachable
decisions cannot be logged or shared

During a crisis, communication systems are part of the crisis infrastructure.

3) Citizen services: the front door to the state

Many governments now deliver services through cloud-hosted portals, form systems, appointment schedulers, and contact centers. If those disappear, citizens experience it as the government itself being offline.

The hidden risk is that the back office may still work, but the intake fails. The result is backlog, distrust, and real-world harm.

4) Data platforms and analytics: policy depends on pipelines

From epidemiology dashboards to fraud detection to traffic planning, policy increasingly relies on data pipelines, managed databases, and analytics services.

These systems are often built using proprietary managed services. That can be fine during normal times, but it makes exits and fallbacks slow. If you cannot move a workload without rewriting it, you do not have leverage.

5) Emergency and safety: where failure becomes life-critical

Not every emergency system is in a public cloud, but supporting layers often are:

alerting and paging
GIS and mapping
logistics dashboards
shared situational awareness tools

Bert’s point about societal disruption lands hardest here: the question is not comfort, it is time-to-recover.

Outage vs. restriction: two different failure modes

A useful extension of Bert’s post is to separate two scenarios.

Scenario A: technical outage

This is the familiar one: a region-wide service incident, an authentication failure, a DNS issue, a cascading update problem.

Key questions:

Can we operate degraded for 24 to 72 hours?
Do we have offline procedures?
Are there alternate channels for citizens?

Scenario B: restricted access (legal, financial, political)

This is the scenario implicit in Bert’s mention of threats and tariffs. Not necessarily that a provider goes down, but that access becomes constrained:

procurement is blocked or delayed
contracts are suspended or altered
cross-border data transfers become disputed
sanctions or counter-sanctions create sudden noncompliance risk

This is harder, because it is not a single incident to ride out. It is a new environment.

A practical way to map your own schrikbarend lijstje

If you are in government, education, healthcare, or critical industry, you can turn Bert’s prompt into a concrete inventory exercise.

Step 1: Identify truly critical services

List services that, if unavailable, would cause immediate societal disruption. Use simple criteria:

impact within 24 hours
impact within 7 days
legal obligations breached
safety implications

Step 2: Trace dependencies down to the control plane

Many orgs map apps, but not the layers beneath them:

identity and authentication
key management and certificates
DNS and networking
logging and monitoring
ticketing and change management

If the control plane fails, your ability to fix the outage may fail too.

Step 3: Measure recoverability, not intentions

It is easy to say we can switch providers. The real question is: have you tested it?

Do you have an exit plan per system?
Do you have data egress procedures and budgets?
Can you restore from backups without the original platform?
Do you have a second communication channel for crises?

Step 4: Reduce single points of failure where it matters most

This does not mean banning US clouds. It means designing so that no single vendor event can halt essential functions.

Options include:

multi-region and multi-tenant architecture
escrowed encryption keys and independent key management
open standards for identity where feasible
interoperability requirements in procurement
alternative collaboration channels for crisis operation

Digital sovereignty is not self-host everything

A common trap is to treat sovereignty as a binary choice: either hyperscalers or everything in a national data center.

Bert’s post, as I read it, is pushing us toward a more nuanced target: operational sovereignty. The ability to keep going, to choose, and to change course.

That usually means:

fewer proprietary lock-ins in the most critical layers
clearer contractual and technical exit routes
more transparency about what depends on what
routine continuity drills that include cloud failure assumptions

The leadership question hiding in the tech debate

The hardest part is not technology; it is governance.

Who owns the risk register for cloud concentration?
Who can mandate an exit plan?
Who decides which services must remain operable under worst-case assumptions?

If nobody has that authority, the list will remain schrikbarend, and the remediation will remain optional.

Closing thought

Bert Hubert’s prompt is powerful because it forces specificity. Not are we modernizing, not are we in the cloud, but: which parts of society break if this dependency fails?

If you can answer that clearly, you can prioritize fixes that actually matter: identity resilience, communications fallback, tested recovery, and procurement that buys optionality instead of just capacity.

This blog post expands on a viral LinkedIn post by Bert Hubert, Researcher, advisor, publicist, geek. View the original LinkedIn post →