The Supplier Graph You Have Not Drawn: A Dependency Census for UK Digital Stacks
Photo: Alistairlewis, CC0, via Wikimedia Commons
Most UK digital teams can name their CDN provider and their payment provider. Far fewer can say which single supplier would take down checkout, login and customer support at the same time. That gap is not a procurement oversight. It is a resilience blind spot. During an incident, the diagram nobody has drawn is often the one that explains why three apparently separate failures arrived together.
A dependency census is a practical way to close that gap. It is not a vendor register or a contract inventory. It is a map of the suppliers your critical journeys actually rely on, scored by criticality, concentration and the realism of failover.
The vendor list is not the dependency graph
Start with the journeys, not the contracts. For a UK retailer, the tier-zero journeys might be login, search, basket, checkout, payment authorisation and order tracking. For a financial service, they might be onboarding, authentication, balance lookup and payment initiation. For each journey, list every third party that must respond for the journey to complete: identity providers, card acquirers, fraud checks, address lookups, CDNs, WAFs, DNS providers, chat and support platforms, email and SMS gateways, tag managers, feature flags and analytics.
Tag each dependency with four fields: the journey it supports, the failure mode if it is unavailable, the fallback that exists today, and the owner who can invoke that fallback. The last field is the one most often missing. A fallback that nobody has permission to activate is a diagram, not a control.
Score concentration, not just criticality
Criticality alone produces a familiar but misleading picture. A payment provider is obviously critical. The more useful question is how many tier-zero journeys depend on the same supplier, and whether the advertised fallback is technically real. Score each supplier on three axes: the number of critical journeys it touches, the substitutability of the service, and the tested realism of failover.
Concentration risk hides in shared dependencies. Two CDN providers may sit on the same upstream network. Two identity providers may depend on the same cloud region. A status page may be hosted by the same vendor whose service it is meant to report on. These are cases of pseudo-redundancy: the contract says two suppliers, the architecture says one failure domain.
A worked example: the 01:40 identity incident
Consider an overnight incident at a UK multichannel retailer. At 01:40 the primary identity provider begins returning intermittent token errors. The public website is static and remains up. The mobile app cannot refresh sessions, so signed-in customers are logged out. Checkout still accepts guest orders, but returning customers cannot authenticate to use stored payment details. The customer support portal uses the same identity provider for single sign-on, so agents cannot log in to help. The status page is hosted by the same provider and is slow to update.
On the vendor list, this is one supplier with an availability problem. On the dependency graph, it is a single node touching login, checkout and support simultaneously. The runbook says there is a secondary identity provider, but it has never been configured for the support portal. The fallback for checkout is a guest flow that loses stored payment details and increases friction at the worst possible time. The incident is not just an outage; it is a concentration risk that was invisible because no one had drawn the edges.
Test failover realism before you need it
Failover plans should be tested in the same way as any other production change. Disable the supplier in a staging environment and observe what actually breaks. Then test a canary in production with a feature flag, if the architecture allows it. Measure how long it takes to switch, what data is lost, and which journeys degrade rather than fail. Check DNS time to live, certificate dependencies, authentication flows and static fallback pages. Confirm that the support team can still operate when their own tools depend on the failing supplier.
Supplier incident communication belongs in the same exercise. Keep escalation contacts outside the affected platform. Agree who declares a major incident when two suppliers fail at once. Update the runbook with the graph, not just the vendor name.
Running the census without a large programme
You do not need a new platform to start. Pull data from browser telemetry, content security policy reports, DNS logs, egress logs, single sign-on configuration and procurement records. Reconcile the lists. Assign a tier to each dependency and a named owner to each fallback. Draw the graph for your three most important journeys first. Review it quarterly and before peak trading periods, when concentration risk is most expensive.
The output should fit on one page per journey. If it does not, the map is probably hiding the complexity rather than explaining it. Resilience is a supplier-graph problem. The teams that can see the graph before an incident are the ones that can make a confident decision during it.
