The continuity trade-off
When many units share one system, one outage can stop all of them at once. That is the central tension in this topic. A shared platform is usually easier to manage and cheaper to protect than ten separate ones, but it also puts more weight on a single set of components. Whether centralization improves or weakens continuity depends mostly on how well the shared system is protected and how well the organization has prepared for its failure.
This article is general information, not professional advice. Organizations with serious continuity needs should involve qualified specialists in designing and testing their arrangements.
What business continuity covers
Business continuity is the ability to keep critical activities going, or restore them acceptably quickly, when something disrupts normal operations. Disruptions come in many forms: equipment failure, software faults, human error, cyber incidents, power or network loss, supplier failure, or physical events such as fire, flood or loss of access to a building.
Continuity is wider than IT. People, premises, suppliers and information all matter. But central systems often sit underneath many other activities, so their failure can have disproportionate reach.
Starting with what matters most
Business continuity planning usually begins with deciding which activities and systems are most critical and how much interruption is tolerable. Two ideas are widely used:
- Recovery time objective. How long the organization can accept a system being unavailable before the effects become unacceptable.
- Recovery point objective. How much recent data the organization can afford to lose, measured as time. If the objective is four hours, the plan should make it possible to restore data to a point no more than four hours before the failure.
A simple illustration: if a shared ordering system is backed up once every 24 hours, then in the worst case up to 24 hours of orders could be lost. If the organization decides it can tolerate losing no more than a couple of hours, backups need to happen more often, or the data needs to be copied continuously to a second location. The figures here are invented for illustration.
Tighter objectives generally cost more, so they should be set according to real business need and not by default.
Backups
A backup is a copy of data that can be used to restore it after loss or damage. A few principles are widely accepted:
- Keep copies in more than one place, and at least one separate from the main system, so that a single event cannot destroy both.
- Protect backups from the same threats as the original data. A backup that can be changed or deleted by someone who has compromised the main system offers limited protection.
- Test restores. A backup that has never been restored is an assumption, not a safeguard. Many problems are discovered only when someone tries to use the copy.
- Know what is covered. Configuration, applications and credentials may need protecting as well as data.
Backups protect data but do not by themselves keep a service running. Restoring a large system from a copy can take time, which is where redundancy and recovery planning come in.
Redundancy
Redundancy means having additional capacity that can take over if a component fails. It can apply to power, network links, servers, storage and whole sites. The aim is to avoid a single point of failure, a component whose failure stops the entire service. The topic of single points of failure in central systems is broader than this article, but in practice it often starts with listing the components a service depends on and asking of each: what happens if this stops?
Redundancy adds cost and complexity. A standby system that is never tested may not work when needed, and a more complicated design can introduce new faults. It also does not protect against mistakes that are copied to every redundant component, such as a faulty change applied to both. Good IT change control remains important for that reason.
Why geographic redundancy matters
Some events affect an entire location: a regional power loss, a flood, a fire or a major network outage. Redundancy that sits in the same building or the same site may fail along with the primary system. Geographic redundancy places backup capacity or copies of data in a separate location, far enough away that a single local event is unlikely to affect both.
Distance involves trade-offs. A secondary site farther away is more independent, but it may involve higher cost, more delay in copying data and more complex arrangements. Organizations also need to consider legal or contractual rules about where certain data may be stored, which is a question for qualified advisers. Using a hosted service does not remove this consideration; it only changes who operates the infrastructure. Sensible vendor due diligence looks at a provider’s design and promises instead of assuming them.
Recovery planning
Technology alone does not produce recovery. A recovery plan describes what will actually be done when something fails:
- who declares an incident and who is in charge
- the order in which systems are restored, usually following their dependencies
- how staff and customers are informed
- which manual workarounds can keep critical activities going in the meantime
- who has authority to make decisions and spend money
- how and when normal operations resume
The plan should be accessible even if the main systems are down. A recovery document that is stored only on the system that has failed is of little use.
Regular exercises, from simple walkthroughs to full restoration tests, reveal gaps in a plan before a real disruption does. Plans should be updated after significant changes, such as a legacy decommissioning project or a new supplier, because yesterday’s plan may no longer match today’s systems.
Balancing centralization and local resilience
Centralization can help continuity. A single, well-run, properly funded platform can be protected, monitored and recovered more reliably than a collection of neglected local servers. Skilled people are concentrated, and procedures can be consistent.
It can also hurt. A shared system without proper redundancy turns local problems into organization-wide ones. Heavy dependence on central teams can leave units unsure how to act when the center is unreachable.
For that reason, some organizations keep a minimum of local capability, such as documented manual procedures or local copies of essential information, even when systems are shared. Others adopt hybrid operating models in which the most critical functions are distributed or duplicated. The right balance depends on how critical the activity is and how much disruption the organization can tolerate.
No plan can eliminate disruption, and recovery estimates are uncertain until they have been tested. Qualified professionals should be consulted when designing arrangements for systems the business cannot afford to lose.