The dependency test¶

For every dependency, ask what happens if the provider decides that keeping the organisation has become more expensive than losing it.

Not what happens if the provider is hacked. Not what happens if it goes bankrupt. Not even what happens if a government orders it to stop.

Those are different failure modes. A hacked provider may still be trying to keep the relationship. A bankrupt provider has a liquidator with an interest in an orderly handover. A provider acting under an order can at least name the order it is obeying.

The question is different: What happens if the provider decides that the organisation has become too risky to keep?

The provider does not have to be hostile to the organisation. It only has to decide it would rather lose the customer than risk the fine.

Once that decision has been made, the provider may freeze the account, suspend the service, hold the domain, block the export, or refuse to renew something the organisation needs. Its appeal process may run through the account it has just suspended. Its support staff may no longer be able to help. Its contractual relationship may have become the thing the organisation can no longer use.

So every answer to the question has to work without that provider’s cooperation.

One level down¶

Then repeat the question one level down.

If the answer is that the organisation moves to another provider, ask: What happens if that provider makes the same calculation?

The replacement has just watched what happened to the previous provider. It may have the same upstream dependencies, answer to the same courts, use the same payment routes, or have its own reasons for avoiding the relationship.

And then ask: Where do the users go?

This makes the test recursive rather than a checklist.

A checklist can establish that provider A has a replacement. The dependency test asks whether provider B has a viable replacement, whether provider C has one after that, and whether the path ends at a provider that will not do the same sum.

The recursion can end in a viable independent path. It can also end in a statement that no such path exists yet, which names a dependency the architecture has not solved instead of hiding it behind the words “backup provider”.

Two branches¶

Threat model
     │
     ├── direct attack
     │     ├── technical
     │     ├── legal
     │     └── physical
     │
     └── transferred risk
           ├── provider exposure
           ├── jurisdictional exposure
           ├── financial exposure
           ├── reputational exposure
           └── coordination effects

Watching, harvesting, naming and intimate control are direct attacks. A runbook or playbook can say what to switch off, encrypt or refuse.

Transferred risk is different. The organisation has no say in the decision. The dependency can disappear because another party has decided that keeping the relationship is no longer worth the risk.

One graph is what the organisation controls, the other what it depends on:

                 what is controlled
                        │
           ┌────────────┴────────────┐
           │                         │
      technical graph          dependency graph
           │                         │
    server / network / app    identity / finance /
    filesystem               service / jurisdiction
           │                         │
           ▼                         ▼
     direct attack          transferred exposure

A service can have excellent control over its servers and applications while having little say over its domain, bank account, certificate authority, payment route, identity provider, legal entity or the courts that can serve it.

Spreading the servers does not spread the dependencies.

Ten independent servers and one shared registry: the registry can make all ten irrelevant.

Four things per dependency¶

For each important dependency, the test records four things:

1. what the provider can withdraw;

2. what the organisation can still operate without it;

3. where the organisation can move next;

4. what new dependencies that move introduces.

The fourth question is the one ordinary redundancy planning leaves out.

A replacement is not automatically an escape. It can move the dependency rather than remove it. A new host may depend on the same payment network. A new domain may remain under the same registry jurisdiction. A new identity provider may become the new single point of recovery. A move to another country may put the service under a different state’s legal powers.

The test therefore follows the dependency rather than stopping at the replacement.

Three stacks¶

The test has been run, layer by layer, against three stacks in Taking back the stack: a one-woman company’s seven static sites, a charity with a rented tenant, and the hosting provider on which the other two stand.

Each stack draws its graph, asks it at every important edge, follows the replacement to the next edge, and records the boxes it cannot yet tick.

The boxes it cannot tick are the ones the next designation will find.

Last reviewed: 2026-09-25.