An asset inventory tells you what exists. It does not tell you what must work together for the institution to act. Payroll may depend on a file produced by one person, stored in a cloud drive, approved through email, uploaded to a bank portal and verified by a phone held by a director. Every named application can be healthy while the outcome fails because the approver is unavailable or the file format changed. Resilience begins with dependency, not equipment.
Start from the outcome
Choose the outcomes whose interruption creates immediate consequence: move cash, communicate with staff, protect a property, serve a client, meet a filing deadline, recover an identity or make a binding decision. For each outcome, trace the chain:
- Trigger: what causes the work to begin?
- Information: which records and current facts are required?
- People: who prepares, decides, executes and reconciles?
- Authority: which mandate, limit or approval makes the action valid?
- Technology: which systems, devices, accounts and integrations perform it?
- Third parties: which providers or counterparties must cooperate?
- Evidence: what confirms that the outcome completed correctly?
Look for shared dependencies
Different outcomes often fail through the same hidden component: a domain registrar, identity provider, administrator, mobile number, managed-service provider, cloud region or executive assistant. These shared dependencies create a larger blast radius than their cost or visibility suggests. A low-spend vendor can be existential if it controls recovery for several critical services.
Value object — The Outcome Dependency Map
Build one page per critical outcome with:
- Maximum tolerable interruption and the consequence of missing it.
- End-to-end dependency chain, including human and external components.
- Single points of failure and common dependencies shared with other outcomes.
- Minimum viable alternative that preserves the essential result.
- Named owner with authority to activate the alternative.
- Latest test evidence and the assumptions the test did not cover.
- Open improvements ordered by reduction in consequence, not technical elegance.
Keep the map readable enough to use during an event. A perfect architectural diagram that requires its author to interpret is not an operational control.
Map degraded modes
Continuity does not always require full restoration. Define what reduced operation looks like. Payroll may be released through a controlled manual process. A private office may communicate only through a small verified contact tree. A transaction may pause new recipients while existing obligations continue. A property may shift from automation to staffed control. The degraded mode should state what remains permitted, what stops and when normal authority returns.
Test the dependency you do not own
Internal teams tend to test systems they control. The failure may sit with a bank, telecom provider, cloud service, registrar or specialist adviser. Exercise unavailability at the boundary. What evidence will the provider demand? Can another authorised person reach them? Is support available in the relevant time zone? Does the contract promise recovery that the operating channel cannot deliver?
Update after change
Dependency maps decay after acquisitions, staff departures, application migrations and new advisers. Make update part of the change, not an annual documentation project. When a new system is introduced, identify which existing outcomes now depend on it and which previous alternative disappeared.
Resilience is a property of the chain
A critical application can be highly available while the institution remains unable to decide or authenticate. A modest tool can support a resilient outcome when authority, data and alternatives are clear. Map the whole chain. Recovery can only be as credible as the dependency nobody remembered.