Identify the people, information and systems a team needs when an ordinary workflow is interrupted.
Choose a specific workflow
Start with a defined activity rather than an entire organization. Scheduling, a clinical handover or coordination with an external service can each reveal different dependencies. Involve the people who perform the activity and the operational owner who can explain what an interruption changes.
List the information and access needed
Record the applications, accounts and communication channels used at each stage. Ask which information must be current and which approved alternatives exist. A procedure stored only in the unavailable system will not help the team carry out that procedure.
Make the decisions visible
Identify who can authorize temporary arrangements and who must be informed. Distinguish operational decisions from technical troubleshooting. A contact list is useful only if it identifies the responsibility and can be reached through an available channel.
Plan the return as carefully as the interruption
Restoring an application does not automatically reconcile work performed during downtime. Define the checks and record-handling responsibilities needed before returning to the ordinary workflow. Those decisions must be made by the appropriate operational and information owners, not inferred from a successful server restart.
Exercise the assumptions within scope
A discussion exercise can expose missing contacts or unclear authority without changing production systems. Technical restoration testing is a different activity and needs its own approvals and safeguards. Capture findings, assign owners and revisit the workflow after significant system or provider changes.
Follow the information needed for one workflow
A scheduling service becomes unavailable, but the broader impact depends on the people and systems that use its information. Administrative staff may need a current appointment list, a trusted communication route and a way to record changes for later reconciliation. Walk through that workflow with its operational owner. Identify which supporting systems, identities and suppliers must remain available. Any alternative clinical or patient-care procedure must be approved by the responsible organisation; a technology exercise should not invent one.
Evidence to collect
- Choose one clearly bounded workflow and involve its operational, technical and information owners.
- Record dependencies such as identity, network access, telephony, printing and external services.
- Identify where an approved downtime procedure is stored and who may access it during an outage.
- Agree how temporary records will be protected, checked and reconciled when normal service returns.
What a useful result looks like
The test should show whether the approved procedure can actually be reached and followed under the chosen outage conditions. Record missing access, unavailable contacts and unclear handoffs. Distinguish observations made in a discussion from activities demonstrated in a technical test. Neither a restored server nor a completed tabletop by itself establishes that the full operational workflow is ready.
Who should approve a downtime workaround?
The organisation’s authorised operational and, where relevant, clinical leaders should approve it with input from technical and information-governance teams. The purpose of the dependency review is to expose gaps, not to substitute general website guidance for those decisions.