When ransomware, a cloud outage or a failed server takes your systems down, the question is no longer how the attacker got in. It is how quickly you can take orders, pay people and serve customers again. An incident response plan focuses on containing and investigating an attack. A cyber business continuity plan focuses on keeping the business running and restoring the systems it depends on. You need both, and they should be written to work together.
This guide follows the structure federal agencies use for IT contingency planning, scaled down for a small or mid-sized business, and explains where cyber insurance fits.
Start with a business impact analysis
The National Institute of Standards and Technology (NIST) built its Contingency Planning Guide, SP 800-34 Rev. 1, around a business impact analysis (BIA). The BIA asks, for each important business process, how long you can be without it and how much data you can afford to lose. NIST uses three terms that are worth adopting:
Maximum tolerable downtime (MTD)
The total time leadership is willing to accept a business process being down, considering every impact: lost revenue, customer harm, contract penalties and safety.
Recovery time objective (RTO)
The maximum time a specific system can stay unavailable before it harms the processes that depend on it. It normally needs to be shorter than the MTD.
Recovery point objective (RPO)
The point in time before the outage to which data can be restored. If your RPO is four hours, you need backups at least that often.
A simple BIA worksheet can be built in a spreadsheet:
| Column | What to record |
|---|---|
| Business process | Order entry, dispatch, payroll, billing, scheduling, point of sale, email |
| Systems it depends on | Applications, cloud services, servers, internet connection, vendors |
| Impact over time | What happens after 4 hours, 1 day, 3 days and 1 week without it |
| MTD, RTO and RPO | Agreed targets, signed off by the owner of the process |
| Manual workaround | How the work gets done, if at all, while the system is down |
| Owner and backup owner | Who decides and who acts |
The BIA usually surprises people. The accounting system may matter less in the first week than the dispatch board, the shared drive with job files or the phone system.
Follow a structured planning process
NIST SP 800-34 lays out seven steps. They translate well to a smaller organization:
- Set the policy. Leadership names who owns continuity and what the plan must cover.
- Do the business impact analysis described above.
- Identify preventive controls that reduce the chance or length of an outage, such as multi-factor authentication, patching, spare hardware and redundant internet.
- Create recovery strategies for each critical system: restore from backup, fail over to another site or service, rebuild from images, or operate manually.
- Write the plan with contact lists, decision authority, step-by-step recovery procedures and the order in which systems come back.
- Test, train and exercise the plan.
- Maintain it as systems, vendors and people change.
Backups that survive an attack
Recovery depends on backups an attacker cannot reach. CISA and MS-ISAC's ransomware guidance recommends maintaining offline, encrypted backups of data and testing them regularly, because many ransomware variants try to find and delete any accessible backups. The same guidance recommends keeping regularly updated "gold images" of critical systems so they can be rebuilt, and retaining backup hardware, since hardware newer or older than the original can create installation or compatibility problems during a restore.
- Keep at least one copy offline or immutable, separated from your normal network credentials.
- Back up cloud data too. Microsoft's shared responsibility model keeps data with the customer under every cloud model, so confirm how email, files and line-of-business cloud applications are backed up and for how long.
- Test restores, not just backup jobs. Time a full restore of a critical system and compare it with its RTO.
- Restore in priority order. CISA's guide calls for restoring from backups based on a prioritization of critical services, which is what your BIA provides.
- Protect the backup console with separate administrator accounts and multi-factor authentication.
Our article on data backup strategies covers the 3-2-1 rule and retention in more detail.
Plan to operate without your systems
Restores take time, and forensic investigators may ask you to leave some systems untouched as evidence. Plan how the business operates in the meantime:
- Out-of-band communication. Keep a contact list for employees, key customers, vendors, your broker, your insurer's claim line and your IT provider somewhere other than the systems that may be down, including on paper. Agree on an alternate channel if company email or chat is compromised.
- Printed plan. Keep a current copy of the continuity and incident response plans off the network so they are available when the network is not.
- Manual procedures. Paper tickets, offline price lists, manual time sheets and a way to take card payments without your normal system, if your payment processor allows it.
- Vendor dependencies. Know the support contacts and service levels for your cloud, software and managed service providers, and what happens if one of them is the one that goes down. See vendor security assessment.
- Customer and employee messaging. Draft holding statements in advance, and route anything about a possible data breach through legal counsel and your insurer's breach coach. See breach notification.
Exercise the plan and keep it current
A plan that has never been rehearsed tends to fail in small, expensive ways: an expired password to the backup portal, a phone list with former employees, a restore that takes three days instead of six hours. CISA's Cross-Sector Cybersecurity Performance Goals recommend that organizations drill their incident response plans at least annually and update them after lessons are learned.
A tabletop exercise is a good start. Gather leadership, IT and operations for two hours, walk through a realistic scenario such as ransomware on a Monday morning, and ask at each step who decides, who acts and what information they need. Follow up with a technical test of at least one full restore. Our incident response planning guide includes scenario ideas.
Do not build your plan around paying a ransom. CISA's ransomware guide states that paying ransom will not ensure your data is decrypted or that your systems or data will no longer be compromised, and that CISA, MS-ISAC and federal law enforcement do not recommend paying. Payments can also raise legal issues. Any ransom decision should involve your insurer, counsel and law enforcement.
Where cyber insurance fits
A cyber liability policy can fund much of the recovery, but only according to its terms. Coverage parts that commonly apply to a disruption include:
| Coverage part | What it typically pays | What to check |
|---|---|---|
| Business interruption | Lost income and extra expense while your systems are impaired by a covered event | Waiting period (often measured in hours), period of restoration, how income loss is calculated |
| Dependent business interruption | Loss caused by an outage at a vendor you rely on, such as a cloud or software provider | Whether it applies to all providers or only named ones, and any sublimit |
| System failure | Interruption from non-malicious failures such as a botched update | Whether included at all, and sublimits |
| Data restoration | Cost to restore or recreate data and software | Whether improvements or upgrades are excluded |
| Incident response and extortion | Forensics, legal, notification and, where lawful, extortion costs | Consent requirements and required panel vendors |
Commercial property and general business income coverage are generally not designed to respond to a cyber event that causes no physical damage, so do not assume your property policy fills the gap. Two practical points matter at claim time: call the insurer's claim line early, before hiring outside vendors, because many policies require consent or use of approved firms, and keep the financial records needed to prove an income loss. Our cyber insurance guide explains the coverage parts in more depth.
When to call your broker
Call us when you finish a business impact analysis, because your RTOs and the revenue at risk should inform your business interruption limits and waiting period. Call us when you move a critical system to a new cloud provider, when a key vendor becomes a single point of failure, and immediately if an incident occurs. As a broker, we compare cyber options across the market and shape coverage around how your business actually operates.