Business continuity is not just about restoring technology. It is about keeping the business moving while technology is unavailable.
In August, Boston Scientific experienced a cybersecurity incident that disrupted portions of its technology environment. The company said the outage affected certain operating systems and applications, including its ability to manufacture products and process and ship customer orders.
Boston Scientific later reported that the unauthorized activity was limited to certain on-premises systems while its cloud-based systems and applications were not affected. By September 9, manufacturing, order fulfillment, and shipping had been restored, although teams were still working through backlogs.
That is a useful business-continuity lesson. An incident does not have to take down every system to create a serious operational problem. If systems supporting production, customer orders, accounting, scheduling, or another function become unavailable, the business can be disrupted even while other technology continues working.
So here is the question leaders should answer before the next cyberattack, equipment failure, internet outage, application problem, or human error:
If one of the systems your business depends on disappeared tomorrow morning, how would your organization continue operating while it was being recovered?
Downtime is a business problem, not just an IT problem
When core technology stops, the impact quickly moves beyond the IT department. Sales teams may lose access to quotes and customer information. Accounting may be unable to process invoices or payments. Employees may not know how to reach one another. Customer service may lose access to case histories. Managers may be unable to see schedules, documents, or operational dashboards.
The technology failure is only the trigger. The real issue is whether the business can continue operating at an acceptable level while recovery is underway.
That is why business continuity planning should start with business functions rather than a list of servers and applications.
1. Identify the business activities that cannot stop
Start by asking what your organization must still be able to do if technology is unavailable for several hours — or longer.
Which customer-facing activities must continue? Which employees need access to information immediately? Which financial processes have hard deadlines? Can staff still communicate with customers? Can your team retrieve emergency contact information if Microsoft 365, the internet, or your normal collaboration tools are unavailable?
Not every system needs the same recovery priority. Microsoft’s reliability guidance makes the same point: criticality is a business decision. Recovery investments should reflect what the workload does, who depends on it, and what happens when it is unavailable.
A practical continuity plan therefore ranks business functions by impact instead of treating every application as equally urgent.
2. Understand that backup and business continuity are different
Backups matter, but a backup by itself is not a business-continuity plan.
CISA recommends maintaining protected backups of critical data and regularly testing whether those backups can actually be restored. That is essential for ransomware and data-loss scenarios.
But imagine that your data is completely safe while the application used to access it is unavailable. Or your cloud service is healthy, but your office has no internet. Or your systems can be restored in six hours, but no one knows what employees should do during those six hours.
Business continuity fills that gap. Microsoft defines business continuity broadly to include disaster recovery, people, communication, and processes. The question is not only, “Can we get the data back?” It is also, “How do we keep operating until we do?”
3. Decide how much downtime the business can actually tolerate
Technology teams often use two terms that are worth understanding at the executive level: recovery time objective, or RTO, and recovery point objective, or RPO.
RTO is the maximum acceptable time a system or business function can be unavailable. RPO describes how much data loss the business can tolerate.
Those should not be arbitrary IT numbers. Microsoft recommends that business and technical stakeholders establish recovery targets together because the right answer depends on revenue, customer impact, regulatory requirements, and operating risk.
For example, an eight-hour outage for an internal training platform may be inconvenient. Eight hours without the system used to dispatch technicians, process patient information, or complete customer transactions may be unacceptable.
The business needs to make that distinction before an incident, not during one.
4. Have a communication plan that does not depend on the failed system
One of the most common continuity gaps is communication.
If email and Teams are unavailable, how will employees receive instructions? If your phone system is cloud-based and affected by the same outage, what is the alternate method? Who has an offline copy of the leadership, vendor, and emergency contact list?
Your plan does not need to be complicated. It may include alternate phone numbers, text-message groups, an external notification service, documented contact trees, customer-message templates, or another approved communication channel.
The important part is that the alternate method does not depend entirely on the technology you are planning to survive without.
5. Know who makes the decisions and what gets restored first
Recovery slows down when everyone is waiting for someone else to decide what to do.
A useful plan identifies who can declare an incident, who coordinates business communications, who works with technology providers, who approves emergency spending, and which systems are restored first.
Microsoft’s disaster-recovery guidance emphasizes defined roles, responsibilities, failover steps, and communication workflows. These are not just technical details. They prevent confusion when the organization is under pressure.
A short priority list can be more valuable than a hundred-page plan nobody can execute.
6. Test the plan before you need it
A continuity plan that has never been tested is still an assumption.
Testing can be as simple as a tabletop exercise with leadership: “Microsoft 365 is unavailable for the next six hours. What do we do?” Or, “Ransomware has taken the primary file system offline. What must be restored first?”
Technical teams should also test backups and recovery procedures. CISA specifically recommends testing backup availability and integrity, while Microsoft recommends testing recovery against defined RTO and RPO targets.
Use the exercise to find practical problems: missing phone numbers, undocumented dependencies, unclear decision authority, recovery instructions stored only on the unavailable system, or a backup that takes much longer to restore than expected.
Those are inexpensive problems to discover during a test and expensive problems to discover during a real incident.
Resilience starts before the outage
Recent cyber and technology incidents are reminders that even well-designed environments can experience disruption. Ransomware, power loss, failed hardware, internet outages, vendor incidents, and human error create different technical problems, but they ask leadership the same business question: how long can we operate without this?
The Federal Trade Commission recommends that small businesses maintain and regularly test incident-response, disaster-recovery, and business-continuity plans. That is a useful way to think about resilience: prevent what you can, detect problems quickly, respond deliberately, and have a realistic path to keep operating and recover.
For organizations that depend heavily on Microsoft 365, Azure, and other cloud services, ICG’s Microsoft Cloud Services can help leaders think about how cloud architecture, identity, security, and recovery fit together. Our Cybersecurity for Small Businesses: The Complete Guide also provides a broader framework for reducing operational risk.
You do not need a plan for every imaginable disaster. You need clarity around the systems and processes your business cannot afford to lose, realistic recovery targets, tested backups, alternate communication methods, and people who know what to do.
If you are not sure how your current environment would hold up during a cyber incident or technology disruption, an ICG Cyber Posture Review can help identify security and resilience gaps that may make an outage harder to contain or recover from.
The goal is not zero downtime. The goal is making sure downtime does not become business paralysis.
Frequently Asked Questions
What is the difference between disaster recovery and business continuity?
Disaster recovery focuses primarily on restoring technology and data after a disruption. Business continuity is broader: it addresses how critical operations, people, communications, and processes continue during and after the disruption.
Is having cloud services like Microsoft 365 enough for business continuity?
Cloud platforms provide significant resiliency, but no service is immune from incidents. Organizations still need a plan for communications, critical workflows, identity access, local connectivity, recovery priorities, and periods when a cloud service or dependent system is unavailable.
Are backups enough to protect a business from ransomware?
No. Protected, tested backups are essential for recovery, but ransomware can also disrupt identity, applications, networks, endpoints, and business processes. A continuity and incident-response plan is needed in addition to backups.
What are RTO and RPO?
Recovery Time Objective (RTO) is the maximum acceptable amount of time a system or function can remain unavailable. Recovery Point Objective (RPO) describes the maximum acceptable amount of data loss, usually expressed as a period of time.
How often should a business continuity plan be tested?
There is no single schedule that fits every organization. Testing should reflect business risk and system criticality, and should also occur after significant technology or process changes. The important point is that recovery assumptions are validated regularly rather than remaining untested.
.png)
