The direct supplier does not define the risk boundary
Separate contracts can conceal the same infrastructure, identity provider or operating team. Digital resilience should therefore follow dependencies connecting suppliers to business capabilities. The number of logos in a procurement portfolio does not measure effective diversity. A company can distribute spending across three partners and lose all three services when a common component fails. Concentration may sit several levels below the commercial relationship.
The objective is not perfect knowledge of every global supply chain. Identify dependencies whose failure would exceed an acceptable interruption, then choose a testable protection. Procurement collects information, business owners define consequences, architecture examines technical paths and operations verifies recovery. A supplier questionnaire becomes useful when these roles confront it with an actual scenario.
Fictional case: three services, one common dependency
A fictional services company uses a customer platform, contact centre and document service from three suppliers. Every figure and situation is a teaching example. All three rely on identity provider X; two also use hosting region R1. What appeared to be three fallback options contains several common dependencies. The email used to contact support depends on the same identity service.
Business owners judge that an outage longer than four hours would jeopardise the day’s appointments. IT has document backups, but nobody has tested reading them without identity provider X. The committee replaces ‘Does the provider have a continuity plan?’ with ‘Which operations can we actually perform while the provider is unavailable?’ Answering requires independent access testing, offline contacts and a defined degraded operating arrangement.
Map paths rather than contracts alone
For each essential capability, record the direct service, known hosting, decisive subcontractors, identity, DNS, networking and key management. Record location, responsible entity, dependency type and strength of evidence. A contractual statement differs from a validated architecture and an exercise. Label unknowns explicitly: a missing answer does not demonstrate diversity. Distinguish uncertainty from confirmed concentration.
Trace useful paths far enough to make a decision. Hundreds of noncritical components are less valuable than understanding a single encryption key that could block everything. Ask what fails, how long the business can wait, how restoration works and who authorises fallback. Include scarce skills and support centres: a second infrastructure can remain unusable without people capable of administering it.
Worked shared-dependency register
| Fictional capability | Direct supplier | Transitive dependency | Evidence and action |
|---|---|---|---|
| Client appointments | Platform A | Identity X and region R1 | Declared diagram; test access without X |
| Contact centre | Provider B | Identity X and telecom operator T | Voice test available; prepare external contacts |
| Contract documents | Service C | Identity X, region R1 and supplier-managed keys | Readable export; test keys and local consultation |
| Supplier payment | Service D | Region R2 and bank E | Distinct known path; test substitute approvers |
Measure exposure beyond spending
One teaching measure is exposure to a common node: the sum of business weights for dependent capabilities divided by total weights studied. Assign fictional weights of four to appointments, three to contact centre, two to documents and one to payments. Identity X carries nine out of ten, or 90% of the chosen exposure. This is not an outage probability. It shows that one dependency carries almost all prioritised activity.
Agree weights with business owners using service loss, obligations and substitution possibilities. A large expense may support a nonurgent tool while a small key-management service can block the entire portfolio. Also calculate recovery margin: maximum acceptable interruption minus demonstrated restoration time. Four acceptable hours minus five tested recovery hours gives a negative one-hour margin. That result requires action even when the commercial SLA reports high availability.
Averages can conceal common failure. Do not naively multiply three availability rates if services share identity or hosting. Their events are not independent. Describe correlated scenarios and consequences rather than presenting misleading mathematical precision. Exposure numbers support a decision; they cannot replace testing or knowledge of operating constraints.
Match evidence to criticality
For an indispensable service, request decisive dependencies, separation mechanisms, observed restoration times and relevant exercise results. A general audit report may describe controls without proving recovery for your configuration. Where information is confidential, arrange a protected review or request a targeted statement. Contracts should address material subcontractor changes, access to information and incident cooperation.
Evidence must include the customer side: network capacity, approvers, keys, quotas and procedures. A secondary region provides little protection if the account activating it depends on the failed service. Examine provider staffing and priorities during an incident affecting many customers. A response commitment does not imply unlimited simultaneous recovery capacity. Procurement should retain these limitations in renewal decisions.
Choose mitigation that changes the scenario
In this fictional case, the company creates independent emergency access for authorised operators, keeps an encrypted external contact directory and prepares limited appointment processing. Security checks expiry, logging and revocation. This reduces reliance on X without claiming to reproduce the entire platform. Another capability may justify a second provider, but only if its dependency chain is genuinely different.
Compare mitigation cost with avoided loss in a stated scenario. A fictional degraded arrangement costing EUR 18,000 annually may aim to preserve half a day’s appointments. Demonstrate that capacity through a volume exercise instead of assuming a written procedure establishes it. Decide which functions can wait. Protecting every function equally may dilute the resources needed for the few essential operations.
Define decision thresholds and stop conditions
For this exercise, a common node carrying at least 60% of studied weight requires an outage scenario and an owned action. Any negative recovery margin requires a decision before renewal. These fictional thresholds must be adapted and are not NIST prescriptions. Suspend adding another critical service to the same dependency until protection is validated or residual risk is explicitly accepted.
Stop an exercise if emergency access creates uncontrolled exposure, the supplier forbids the necessary test or fallback data cannot respect personal-data rights. Mitigation must preserve the controls it protects. The business sponsor sets tolerable interruption, security approves controls, operations demonstrates results and procurement negotiates cooperation. Revisit decisions after subcontractor changes or incidents rather than letting accepted risk become invisible.
Maintain the map and exercise cooperation
Update the register at renewal, architecture changes, supplier acquisitions and subcontracting notifications. Date evidence so an old declaration is not mistaken for a current guarantee. Exercise the most concentrated dependency and record detection, escalation, data access and business restart times. A discussion prepares people; technical and business testing establishes stronger evidence where feasible.
Use independent incident communications and a named decision authority. Close exercise actions with observed outcomes rather than supplier promises. Track known critical paths, recovery margins and unassessed changes. Leadership can then explain why two contracts create effective diversity or remain exposed to the same event. Resilience becomes a joint operating capability between the enterprise and its partners.
Sector implications
Financial services may share dependencies across payment, reporting and control, requiring governance under the applicable sector framework. Manufacturing should include maintainer access, control software and spare parts. Restoring a server does not restart a line without a licence or specialist. Retail can share a payment provider across sales channels that otherwise appear independent.
Professional services are sensitive to identity, documents and collaboration. Public services may need a degraded arrangement accessible to the whole population. These differences change weights, acceptable interruptions and evidence requirements. They do not change the principle: verify diversity through dependency paths and achievable operations rather than contract counts.
Sources and method
This 2022 retrospective uses the original 2022 NIST SP 800-161 Rev. 1 rather than its 2024 update. The 2019 EBA guidelines inform their financial-sector scope; the GDPR addresses personal-data subcontracting responsibilities. Later sector obligations are not treated as already applicable in 2022. Metrics, weights and thresholds are the author’s teaching model, editorially checked in 2026.
Primary sources checked in October 2026. NIST SP 800-161 Rev. 1, édition 2022. EBA, Guidelines on outsourcing arrangements, 2019. CNIL, RGPD, articles 28 et 32.
All situations, amounts, durations and thresholds are fictional teaching examples. They illustrate a decision method and do not describe any CYTIZEN engagement or market benchmark. The operational recommendations are the author’s proposals, separate from the cited documents.