If a ransomware attack, power outage, hardware failure or cloud disruption stopped part of your business tomorrow, what would happen next?
Most leadership teams can answer that question broadly: We have backups. Our IT team would handle it. We’d figure out how to keep working. But those answers leave a lot of room for uncertainty.
Which systems would be restored first? How quickly could they actually be recovered? Who has authority to make decisions? How would employees communicate if email or Microsoft 365 were unavailable? What happens if a critical vendor — or a critical employee — is unreachable?
Those are business continuity questions, and a disruption is the worst time to answer them for the first time.
September is National Preparedness Month, making it a good opportunity to put one short meeting on the leadership calendar. You don’t need to build an entire business continuity plan in 15 minutes. Instead, use the time to find out whether your leadership team agrees on the answers to five basic questions.
If it doesn’t, you’ve identified exactly where your planning needs more work.
1. If our business stopped operating tomorrow, what would need to be restored first?
“Get everything back online” isn’t a recovery priority. When multiple systems are unavailable at the same time, your IT team needs to know which applications, data and business functions have to come back first.
For one organization, that may be its ERP or production environment. For another, it could be customer support, payment processing, scheduling, order fulfillment or access to shared files.
Start with the business function, not the technology.
Ask:
- Which functions directly affect revenue?
- Which systems are required to serve customers?
- What can’t be unavailable for more than an hour? Four hours? A full business day?
- Which applications or data do those functions depend on?
- Are there systems that can remain offline while more critical systems are recovered?
This is the beginning of a business impact analysis (BIA) and helps establish realistic recovery priorities.
It also leads to two important disaster recovery metrics: recovery time objective (RTO) and recovery point objective (RPO).
RTO defines how long a system can be unavailable before the downtime becomes unacceptable. RPO defines how much data the organization can afford to lose, measured in time.
For example, saying “our accounting system is critical” isn’t specific enough. Leadership should be able to say something closer to: We need access to this system within four hours, and losing more than one hour of transaction data would create a significant business problem.
Those requirements should then match what your backup and recovery infrastructure can actually deliver.
What to determine in the meeting: Identify your three most critical business functions and the systems each one requires. Then ask whether IT knows the expected RTO and RPO for each.
For a deeper look at identifying recovery priorities, risks and dependencies, see our Business Continuity Planning Guide.
2. Who is responsible for making decisions during a disruption?
Technology can recover faster than an organization can make decisions. That’s a problem.
Imagine discovering ransomware on a server at 7:30 a.m. Who decides whether systems should be disconnected? Who contacts the cyber insurance carrier? Who tells employees not to log in? Who approves customer communications? Who contacts outside IT and security providers?
If those decisions require an improvised group text among five executives, valuable time is already being lost.
Your continuity plan should establish clear ownership for areas such as:
- Declaring an incident and activating the response plan
- Making operational decisions
- Coordinating with IT and cybersecurity teams
- Communicating with employees
- Communicating with customers
- Contacting insurance, legal counsel or other outside resources
- Coordinating with critical vendors
- Approving the return to normal operations
You should also identify backups for the people assigned to those roles. A plan that depends entirely on one executive, IT administrator or department head being available isn’t much of a plan. CISA recommends involving senior business leadership in response planning and exercises rather than treating incident response as an IT-only responsibility.
What to determine in the meeting: Name the person with authority to activate your response plan and identify at least one alternate. Then make sure everyone knows who owns internal communications, external communications and technical recovery.
3. How would we communicate if our normal tools weren’t available?
There’s an easy way to expose a weakness in an emergency communication plan:
Take away email. If your organization experienced a Microsoft 365 outage, account compromise, ransomware attack or internet disruption, could leadership still reach employees? What if Microsoft Teams or your VoIP phone system were affected at the same time?
Business continuity planning should assume that the incident itself may disable the tools you normally use to coordinate the response.
Your alternate communication plan could include personal phone numbers, SMS, an emergency notification platform, alternate email accounts or another predefined communication channel. What’s important is that the method is established before an incident and that employees know where to turn for reliable information. Leadership should also know how it would communicate externally.
If your website, email and phone system were unavailable, how would customers know whether you were operating? Who could publish an update? Where would customers be directed? Keep in mind that contact information changes. An emergency list created two years ago may include former employees, outdated vendor contacts or executives who have changed roles.
What to determine in the meeting: Identify one communication method that doesn’t depend on your primary email, collaboration or phone environment. Confirm where emergency contact information is stored and who is responsible for keeping it current.
4. What’s our biggest operational dependency?
Every organization has dependencies. The dangerous ones are the dependencies nobody recognizes until they’re gone.
Consider what would happen if you suddenly lost access to:
- Your internet connection
- Microsoft 365 or another cloud platform
- Your ERP, CRM or line-of-business software
- A third-party SaaS provider
- A payment processor
- A key supplier
- A specific server or network device
- One employee with specialized knowledge
Now ask a harder question: Which one of those failures could stop several parts of the business at once?
That’s where continuity risk can become significant. A SaaS platform, for example, may support several departments. A single employee may know how to perform a critical process that isn’t documented anywhere. A business may have redundant servers but only one internet connection. Or an organization may assume a cloud provider is responsible for protecting data that actually falls under the customer’s responsibility.
Third-party dependencies deserve particular attention because your recovery plan can be affected by systems you don’t control.
Our review of [real-world business continuity examples] shows how vendor outages, cyberattacks and other disruptions can cascade when organizations don’t have workable fallback procedures.
What to determine in the meeting: Have each leader name the one system, vendor, person or resource their department would struggle most to operate without. Then ask whether there is a documented workaround.
You may discover several single points of failure in less than five minutes.
5. If a disruption happened tomorrow, what would we wish we’d prepared today?
This may be the most valuable question in the meeting. Instead of asking whether you’re “prepared,” put yourself one day into an actual disruption. Your primary server is down. Employees can’t access files. A critical SaaS application is unavailable. Your network has been encrypted by ransomware.
Now ask: What would we desperately wish we had done yesterday?
Common answers might include:
- Tested our backups
- Documented a manual workaround
- Updated the employee contact list
- Written down administrator credentials and recovery information securely
- Documented who has decision-making authority
- Created an alternate communication method
- Verified our cyber insurance requirements
- Documented critical vendors and support contacts
- Established recovery priorities
- Tested an actual server or file restore
Pay particular attention to the word tested.
Having a backup is not the same as knowing you can recover. CISA recommends maintaining protected backups of critical data and regularly testing their availability and integrity in disaster recovery scenarios. Testing matters because operational environments change: systems are upgraded, applications are added, employees leave and recovery requirements evolve.
A recovery test can expose those changes before a real incident does. Our Disaster Recovery Scenarios Test Guide walks through practical scenarios businesses can test, including data loss, ransomware and backup recovery.
What to determine in the meeting: Ask everyone to complete this sentence: “If we had a major outage tomorrow, I would wish we had already ______.”Write down every answer. That’s your first preparedness to-do list.
Don’t Stop at the 15-Minute Meeting
The purpose of this exercise isn’t to prove that your business is prepared. It’s to expose the assumptions that need to be tested. If everyone in the room agrees on your recovery priorities, decision makers, backup communication methods and critical dependencies, that’s a strong start. The next question is whether those plans actually work.
A simple tabletop exercise can walk the team through a hypothetical disruption without affecting production systems. More advanced disaster recovery testing can verify whether systems and data can actually be restored within your required recovery window.
CISA’s continuity guidance recommends testing plans and using the results to identify improvements. Testing can range from basic tabletop exercises to partial or full recovery exercises, depending on the criticality of the service.
If you’ve never tested your plan, start small. Pick a scenario — ransomware, internet failure, Microsoft 365 outage, server failure or loss of access to a critical application — and walk through what would happen from the first five minutes through full recovery.
Our Business Continuity Plan Guide and Template provides a more complete framework for documenting risks, responsibilities, recovery procedures and testing.
Where Backup and Disaster Recovery Fit In
Business continuity is bigger than IT. But for most organizations, technology is involved in nearly every critical business function.
That means your recovery strategy needs to answer more than “Do we have backups?” You need to know:
- What is being backed up?
- How frequently?
- Where are the backups stored?
- Are backups isolated from the production environment?
- Are they automatically verified?
- When was the last successful restore test?
- How quickly can a critical server be recovered?
- Can workloads run somewhere else if primary infrastructure fails?
- Does the recovery capability meet the RTO and RPO the business actually requires?
This is where business continuity planning and disaster recovery technology need to align.
Solutions such as Datto SIRIS BCDR can provide capabilities including cloud replication, automated backup verification and virtualization designed to help organizations restore operations quickly after an outage or cyberattack.
But no technology eliminates the need for a plan. The strongest recovery strategy combines resilient technology with documented responsibilities, realistic recovery objectives and regular testing.
Your 15-Minute Business Continuity Checklist
Before you leave the meeting, see whether your leadership team can confidently complete these five statements:
- We know which three business functions must be restored first.
- We know who has authority to make decisions during a disruption.
- We have a way to communicate if our normal systems are unavailable.
- We know our biggest operational dependencies and single points of failure.
- We know which preparedness gaps we need to address next.
If you can’t check all five boxes, that’s useful information. You just identified where to start.
How Resilient Is Your IT Environment?
The five questions above provide a quick leadership check, but business resilience also depends on what is happening underneath your technology environment.
Take Invenio IT’s free 3-minute IT Resilience Assessment to evaluate your backup and recovery, cybersecurity, email and human risk, cloud and identity security, and business continuity readiness.
You’ll receive an instant IT Resilience Score, your strongest areas and the priorities that may deserve more attention.
[Get My IT Resilience Score →]
No signup required.
