Most companies have plans for normal days, but not for the day the office is unreachable, the servers are encrypted or the internet is down for several days. On that day, a company that planned ahead knows who does what and where to start; everyone else spends hours on the phone. A business continuity plan is written for exactly that day, and a large part of it depends on IT.
How Is Business Continuity Different from Disaster Recovery?
- Business Continuity: How the company’s critical operations, such as sales, customer service and payments, keep running during a crisis, even in a limited or manual form.
- Disaster Recovery: The technical side: how, and in what order, systems and data are restored.
Having backups means data is not lost; business continuity means work does not stop, or resumes quickly. They are not the same thing.
Step 1: Business Impact Analysis
Sit down with each department head and answer these questions:
- Which processes are critical? Which work causes serious damage if it is not done for a day?
- Which systems does each process depend on? Accounting software, email, phones, the file server or the internet.
- What is the maximum tolerable downtime (RTO) for each system?
- What is the maximum acceptable data loss (RPO)? The last hour of work, or the last day?
The result is a priority list: on the day of a crisis, which system comes back first and which comes next.
Step 2: Understand the Scenarios
For each scenario, determine what is lost and what the alternative is:
- Server or storage failure: Restore from backup or run the virtual machines on another host.
- Ransomware: Every system on the network may be hit at once; you need immutable or offline backups and a clean environment for recovery.
- Office unavailable: Fire, flooding or a long power outage. Where will staff work from, and with what tools? This is where remote access and services hosted in a data center prove their worth.
- Extended internet outage: A second link or an alternative path.
- Key person unavailable: What happens if the only person who knows the passwords cannot be reached?
Step 3: The Plan Document
The plan must be short, practical and usable under pressure:
- Roles: Who declares a crisis, who makes decisions and who leads the technical work.
- Contact list: Key staff, the IT support provider, internet and hosting providers, and software vendors.
- Recovery order: Based on the priority list from Step 1.
- Temporary manual procedures: For example, recording orders by hand until the software is back.
- Communication: What is communicated to staff and customers, through which channel and by whom.
- Emergency access: Critical passwords kept in a secure place that remains accessible when key people are absent, such as a password manager with emergency access or a sealed envelope in a safe.
Do not keep the plan only on the company server. A document that gets encrypted along with the servers is useless on the day of the crisis. Keep a printed copy and a copy outside the company network.
Step 4: Practice
A plan that has not been practiced will not work on the day of a crisis. Two simple types of exercise:
- Tabletop exercise: The team sits around a table and walks through a scenario step by step, for example “Monday morning, all servers are encrypted”, to find the gaps in the plan.
- Technical exercise: Actually restore a critical system and compare the time it takes with the agreed RTO.
Update the plan at least once a year and after every major change, such as adding a branch or a new system.
Checklist
- Critical processes and the systems they depend on have been identified.
- The RTO and RPO for each system have been agreed with management.
- An alternative exists for each major scenario.
- Roles, the contact list and the recovery order are written down.
- An offline and printed copy of the plan is available.
- The plan is practiced and updated at least once a year.
ITPlus724 engineers can work alongside your team on analyzing IT dependencies, designing backup and recovery, and running crisis scenario exercises.