How to Build a System Outage Recovery Plan

A system outage recovery plan must reconcile every action taken through telephone, email or manual workarounds before normal processing resumes. Restoring technical access is only one part of recovery. The operation is not under control until fallback records have been matched, possible duplicates have been reviewed and every unresolved item has an owner.

This matters wherever teams handle payments, bookings, applications, repairs, staffing requests or complaints. Work continues elsewhere during an outage and can collide with new activity when the platform returns.

What happened at CAF Bank

CAF Bank’s online banking service became unavailable on 24 July 2026 after suspicious account activity was identified. A Financial Times report published on 28 July said the bank had found a vulnerability involving third-party software that connected to its online portal. The report said the core bank was unaffected and customers were directed to telephone support, with time-sensitive payments such as payroll receiving priority.

By 4 August, the CAF Bank service update said online banking was available again, although traffic might sometimes be limited. Its recovery message also warned customers not to replicate payments already authorised through telephone or other processes.

That warning is operationally important. It shows why an outage does not finish when a login screen returns. The recovery team must bring fallback work back into the primary process without creating duplicate actions or losing valid requests.

The National Cyber Security Centre published recovery guidance on 28 July 2026. It separates immediate response, minimum viable operations and longer-term rebuilding, a useful distinction for any service operation.

Why restoration creates a second operational risk

During an outage, staff still try to achieve customer outcomes. They take calls, accept emailed instructions, record forms, make promises and use spreadsheets. These workarounds are necessary, but they create a parallel operating record.

1. Fallback records become fragmented: One agent records a call, another emails a specialist team and a manager maintains a priority list. No single view shows what was received, authorised, completed or promised.
2. Duplicate actions become possible: Customers may resubmit because they cannot see whether a telephone or manual instruction succeeded. Staff may also re-enter completed work. Without matching rules, the same request can be processed twice.
3. Ownership becomes unclear: An outage item may lack a recognised case number. If its fallback record names a department rather than one person, it can remain outside the normal queue after service resumes.
4. Customer updates move ahead of evidence: A payment, booking or repair can be described as complete before the primary system confirms it. Conflicting messages then create repeat calls, complaints and investigation.

System outage recovery plan: seven controls

The following controls turn restoration into a managed operational process.

1. Define the recovery trigger: Technical teams confirm stability, but operations decides when normal processing resumes. Define the decision owner, required evidence and whether access returns in stages.
2. Freeze and timestamp fallback intake: Set a clear cut-off. Later requests enter the restored channel unless an exception is approved. Retain when, where and by whom each fallback request was accepted.
3. Protect the highest-consequence outcomes: Separate urgent payroll, safeguarding, emergency repairs, cancellations and other time-critical work from routine requests. Priority should reflect customer consequence, not call order.
4. Give every fallback item a reference: The reference follows the request into the primary system. Record the customer, outcome, authorisation, promised response, owner and evidence.
5. Reconcile before reprocessing: Compare fallback records with restored-system activity using identifiers, timestamps, amounts, property references or request details. Hold uncertain matches for human review.
6. Separate matched work from exceptions: Create three states: confirmed match, confirmed new item and unresolved exception. Give each exception an owner and deadline. Keep high-risk exceptions visible until closure is evidenced.
7. Communicate and close formally: Tell customers whether their request was accepted, completed, duplicated or remains under review. Close only when the backlog is reconciled, outstanding work is owned and lessons are recorded.

Organisations reviewing these controls can use IT consulting to map the operating process before changing technology. Where the agreed workflow requires a controlled integration or purpose-built record, custom software development may be relevant after the process and responsibilities are clear.

An illustrative property-services example

Consider a property-maintenance company whose customer portal becomes unavailable. Its contact team accepts urgent repairs by telephone and records routine requests in a shared spreadsheet. Contractors continue receiving jobs from duty managers.

When the portal returns, agents begin entering the spreadsheet backlog. A tenant also resubmits a leaking-pipe report online because no reference was received during the outage. Without reconciliation, a second contractor could be dispatched while another routine request remains untouched.

A controlled recovery would freeze the spreadsheet at a recorded time, match every entry against portal activity and contractor assignments, hold likely duplicates for review, and tell each tenant which reference now owns the job. This example is illustrative and is not presented as a Don-Clem Technology customer result.

What technology should and should not do

Technology should preserve the source and time of every fallback request, suggest likely matches, display unresolved exceptions, enforce ownership and retain the evidence used to close the item. It should also support staged recovery when a restored service needs controlled traffic.

Technology should not assume two similar records are identical, approve a sensitive action without the required authority, erase a fallback record because a possible match exists or declare the incident closed because the platform is online.

The FCA’s operational resilience guidance emphasises identifying important services, setting tolerances, testing disruption scenarios and learning from incidents. Those principles are useful beyond regulated financial firms. Good recovery joins people, process, communications and technology around the customer outcome.

The objection: “We can manage the backlog manually”

Manual handling can be appropriate for a short disruption. The risk is not the spreadsheet itself. The risk is using it without a defined reference, cut-off, owner, matching rule and closure test.

If the team cannot prove which requests were accepted, which were processed and which remain uncertain, manual work has become an uncontrolled second system. The practical response is to design the reconciliation process before the next outage and test it with a realistic scenario.

Frequently asked questions

• When is a restored service ready for normal use?, When technical stability is confirmed and operations can safely control fallback work, new demand and possible duplicates. Access may need to return in stages.
• Who should own outage reconciliation?, One accountable operations leader should own the process, supported by technology, compliance and service teams. Individual items still need named owners.
• Should every fallback request be entered into the main system?, It should be accounted for, but not automatically reprocessed. Confirm whether it is new, already completed or an unresolved exception before taking action.
• What should be tested before an outage?, Test intake, priority rules, authentication, ownership, customer updates, capacity, matching, exception review and formal closure using a severe but plausible scenario.

Conclusion

A system outage recovery plan must control the journey from temporary workarounds back to the primary process. Technical availability is an important milestone, but recovery is complete only when fallback actions are reconciled, possible duplicates are reviewed and customers receive an accurate next step.

If your service team has no controlled route from fallback work back into the main system, message me AUDIT for a free 20-minute Call Operations Audit.