Business Continuity and Crisis Response Checklist: A Practical Checklist

Summary. The difference between a continuity plan and a continuity capability is testing, and the difference is discovered at the worst possible moment. Most plans are written to satisfy a customer questionnaire, describe a structure nobody has rehearsed, and live on the network that goes down. This checklist builds the capability: the impact analysis that determines what must be recovered and how fast, the dependency map that surfaces single points of failure, the crisis structure that names who decides and with what authority, the communications prepared in advance including the contractual notice obligations most companies have never extracted, recovery procedures for technology and facilities and people, the insurance that responds, and the exercises that find the gaps.

What this checklist is for. Building and testing a continuity and crisis capability. For the reasoning behind each step, see Preparing a Business Continuity and Crisis Management Plan.

Phase 1 — Business impact analysis

List the business processes, specifically — "operations" is not a process.
For each, estimate the financial impact per hour and per day, and how it escalates.
Identify the non-financial impact: regulatory consequences, customer attrition, safety, and contractual breach.
Set the maximum tolerable downtime — the point beyond which the damage cannot be absorbed.
Set the recovery time objective, inside the maximum tolerable downtime.
Set the recovery point objective, which drives backup frequency — an RPO of four hours means backups every four hours.
Note seasonality: the same disruption in the peak week may cost ten times what it costs in a slow month.
Rank the processes. Most organizations find three to six are genuinely critical and the rest can wait days.
Force the tradeoff by attaching cost to the RTO, because business owners asked for an RTO will say "immediately" for everything.

Phase 2 — Dependency mapping

For each critical process, identify every dependency:

People — who performs it, who else can, and what happens if the one person who knows it is unavailable. Single-person dependencies are the most common and most correctable vulnerability.
Technology — applications, infrastructure, data, network, and the interfaces between them.
Facilities — locations, equipment, utilities, and physical access.
Suppliers and vendors, including the ones behind the ones you know about — a SaaS provider dependent on a single cloud region is a dependency nobody chose.
Data — where it lives, who holds it, and how it is recovered.
Third-party services — payments, telecommunications, logistics, and outsourced functions.
Records and regulatory approvals required to operate.
Mark every single point of failure, and decide explicitly whether to accept, mitigate, transfer, or eliminate each. Documenting a decision to accept is a legitimate outcome; not having identified it is not.
Build playbooks by effect — lost facility, lost system, lost people, lost supplier — rather than by cause, because four playbooks cover nearly everything including the scenario nobody predicted.

Phase 3 — Crisis structure

Name the team by role, with at least two alternates each: crisis leader, operations, technology, communications, legal, human resources and safety, finance, facilities and security, and a scribe whose only job is to maintain a timeline. The scribe role is always omitted and always needed.
State the decision authority explicitly: what the crisis leader may decide alone, what requires the CEO or the board, and the emergency spending authority available without normal approval.
Define activation levels — localized, significant, and enterprise — and state who can declare each. The most common failure in a real event is that nobody declares anything for six hours.
Establish the communication channel: a bridge line, a chat channel, and a location, with the details on a card people carry.
Define the battle rhythm for sustained events: status call intervals, a standard reporting format, a shared situation log, and shift handoffs.
Confirm the crisis leader is not the person performing the technical recovery.

Phase 4 — Communications, prepared in advance

Maintain an out-of-band contact list — personal phone and email for every employee, kept current — because a company email outage makes the directory useless.
Deploy and test a mass notification tool.
Prepare employee messaging templates: what happened, what the company is doing, what to do, and when there will be more.
Prepare customer templates, and identify who communicates with each account.
Extract the contractual notice obligations from every customer, supplier, lender, and lease agreement into a one-page schedule kept with the plan — deadlines, required content, and method. Several agreements require notice of a disruption within hours, and companies routinely discover this the following week.
Read the force majeure clauses in both directions: the enumerated events, the prompt written notice condition on which relief usually depends, the mitigation obligation, and any termination right after a defined period.
Map the regulatory reporting obligations that a disruption or an incident triggers, with their clocks — cyber incident reporting measured in hours in several regimes, data breach notification, securities disclosure, and sector-specific requirements.
Maintain the insurer notice list.
Prepare a holding statement and name one spokesperson.
Stand up a status page hosted independently of the company's own infrastructure.
Pre-approve templates with legal, so review during an event is a check rather than a drafting exercise.

Phase 5 — Recovery capability

Technology

Backups on a schedule matched to the RPO, with offline or immutable copies, because ransomware encrypts connected backups first.
Restoration tested and timed at least annually. A backup that has never been restored is a hypothesis, and the most common finding in a real event is that restoration takes far longer than assumed.
Documented recovery runbooks, with credentials accessible to more than one person and stored where they can be reached when the primary systems are down.
Failover capability for critical systems, exercised.
Vendor escalation contacts and contract support terms, current.
A one-page manual workaround per critical process.

Facilities and people

Alternate work locations, which for many businesses means remote work with tested equipment and network capacity.
Alternate production or fulfillment capacity, including reciprocal or contract arrangements.
Utilities — generators, fuel contracts, and how long they last.
Cross-training for the single-person dependencies the map identified.
Succession for key roles, with delegated signing authority documented.
Payroll continuity — how people get paid if the payroll system or the office is unavailable.
Safety, evacuation, headcount accountability, and employee assistance.

Supply chain

Alternate suppliers identified and qualified in advance, because qualifying one during a disruption takes weeks.
Safety stock sized against realistic replacement lead times.
Visibility into subtier suppliers for components with no alternative.

Phase 6 — Insurance, legal, and testing

Review business interruption coverage: it responds to loss of income from direct physical loss, which means a cyber event or a vendor outage with no damage generally does not trigger it. Check the period of restoration, the extended period of indemnity, the waiting period, and whether the limit reflects an actual recovery period.
Confirm contingent business interruption coverage, and whether it covers unnamed suppliers or only scheduled ones.
Confirm cyber coverage for network interruption and dependent network interruption, with the waiting period, indemnity period, sublimits, and any mandatory vendor panel understood.
Confirm civil authority, ingress/egress, and service interruption coverage.
Assign someone to track incremental costs and lost revenue from hour one, in the format the proof of loss requires.
Agree the ransom decision framework in advance — backups, exfiltration, sanctions legality, and insurer requirements — because it cannot be reasoned through calmly at hour four.
Confirm a litigation hold would issue where claims are foreseeable, and that forensic imaging precedes restoration where evidence matters.
Structure any investigation likely to produce claims under counsel from the beginning.
Run a tabletop exercise every six months, varying the scenario and varying who is in the room — including a scenario in which the primary decision-makers are unavailable.
Run a functional test annually: restore a backup and time it, fail over a system, activate the notification tool, or run a shift on the manual workaround.
Hold an after-action review after every exercise and every real event, with specific assigned actions, owners, and dates, checked at the next review.
Keep the plan usable: a one-page activation card, role checklists, and effect-based playbooks, with the reference material separate — and store offline copies where they can be reached when the network is down.
Assign an owner with a review calendar, and integrate the plan with vendor onboarding and employee onboarding.

Common mistakes

A plan written for a customer questionnaire, never exercised.
No dependency map, so single points of failure are unknown.
No named decision authority, so nobody declares an incident for six hours.
Contact lists that are stale, and no out-of-band list at all.
Backups never restored, so the restoration time is a guess.
No manual workaround, so a system outage stops the business entirely.
Contractual notice obligations never extracted, and discovered after the deadline.
Assuming business interruption insurance covers a cyber or vendor outage.
The plan stored on the network that is down.
After-action reviews with no assigned actions, which is a meeting rather than a correction.

Primary authority

Standards and frameworks: ISO 22301 (business continuity management systems), NIST SP 800-34 (contingency planning), and NIST SP 800-61 (incident handling).
Regulatory drivers, by sector: cyber incident reporting obligations including the SEC's material cybersecurity incident disclosure requirements for public companies and sector-specific reporting rules; the HIPAA Security Rule contingency plan standard, 45 C.F.R. § 164.308(a)(7); the GLBA Safeguards Rule incident response requirement, 16 C.F.R. Part 314; state data breach notification statutes; and the NAIC Insurance Data Security Model Law's 72-hour notification requirement as enacted.
Contract law: force majeure provisions, which are creatures of the specific agreement and are construed narrowly, and which typically condition relief on prompt written notice.

This checklist is educational and not legal advice. Regulatory reporting obligations, contractual notice requirements, and insurance coverage vary substantially by industry, jurisdiction, and policy language. Consult qualified counsel and a licensed broker when building or activating a plan.