A flight processing system issue at NATS disrupted UK air traffic operations this week, and airlines were still working through the backlog on September 9. NATS said its operations were stable, that it was helping airlines and airports recover, and that a full investigation would look at what happened and what else needs to change.
That may sound far away from a New Jersey office, medical practice, school, nonprofit, or manufacturer. It is not. The business lesson is local: when one critical system slows down, the operational mess can last longer than the technical failure. Customers wait, staff improvise, vendors point to status updates, and leaders have to explain what is known before the investigation is finished.
The Risk Is The Recovery Gap
Many technology plans focus on the moment a system goes down. The harder question is what happens after the fix is applied. Backlogs still have to be cleared. People need current instructions. Work may need to be re-sequenced. Customers need realistic answers. In aviation, that means displaced aircraft, passengers, and crews. In a smaller business, it might mean missed appointments, stalled orders, delayed billing, inaccessible records, or a vendor queue that suddenly becomes the bottleneck.
This is where business continuity planning moves beyond a document on a shelf. Owners need to know which workflows are truly critical, who owns each recovery step, and what evidence shows the plan has been tested. A vendor saying that a platform is stable is useful. It is not the same as proving your business can operate while the cleanup continues.
What Owners Should Ask
Before accepting the next uptime claim, renewal proposal, or support explanation for a critical service, ask for specifics:
- What business process stops first if this system is unavailable? Name the workflow, not just the server or application.
- Who owns recovery decisions? Identify the internal decision-maker and the vendor contact who can authorize action during an incident.
- How will customers and staff be updated? Define who communicates, what channel is used, and how often updates are expected.
- What backlog forms after service returns? Recovery planning should include delayed work, manual entries, missed alerts, and data reconciliation.
- When was the fallback tested? A backup, alternate process, or failover plan should have a recent test date and a clear result.
The Practical Next Step
Pick one system that would hurt if it were unavailable for half a business day. It could be phones, email, scheduling, payment processing, internet service, cloud files, EHR access, shipping, or a line-of-business application. Ask your IT provider or internal team for a short recovery map that explains the dependency, the fallback, the communication path, and the expected recovery work after service returns.
The goal is not to predict every outage. The goal is to remove ambiguity before the clock starts. A continuity plan earns its keep when the first answer is not, "We are waiting to hear back from the vendor."
Sources and further reading
