Business Continuity Risk Register: The Essential 2026 Guide with 12 Fields

A business continuity risk register is the working record of everything that could interrupt your most important activities, how likely each event is, how badly it would hurt and what you are doing about it. ISO 22301:2019 expects you to run a risk assessment process for continuity, and the register is where the output of that process lives. Without one, a business impact analysis produces recovery targets but nobody knows which threats could actually break them.

This guide covers the twelve fields a business continuity risk register should contain, how to feed it from your business impact analysis, how to score risks in a way that ties back to recovery time targets, and how to keep it alive after the first workshop.

What a business continuity risk register is for

ISO 22301 separates two questions. The business impact analysis in clause 8.2.2 asks which activities matter most and how quickly they must resume. The risk assessment in clause 8.2.3 asks what could disrupt those activities and their resources. The business continuity risk register records the answers to the second question in a form you can score, assign, treat and review.

Its audience is broader than the continuity manager. Executives use it to see where the organization is exposed, auditors use it to test whether risk work is real, and plan owners use it to check that their continuity strategies address the threats that matter. Our guide to ISO 22301 risk assessment covers the method, and the comparison of BIA and risk assessment explains how the two fit together.

The 12 fields every business continuity risk register needs

A short list of well-defined fields beats a wide spreadsheet nobody completes. These twelve give an auditor a full story from threat to residual risk.

#	Field	What to record
1	Risk ID	A unique reference that other documents can cite
2	Prioritized activity affected	The activity from your BIA that the risk could disrupt
3	Resource at risk	People, premises, technology, information or suppliers
4	Risk description	Cause, event and consequence in one sentence
5	Existing controls	What already reduces likelihood or impact
6	Likelihood	Rating on your defined scale
7	Impact	Rating linked to disruption time against your recovery targets
8	Inherent and current rating	Score before and after existing controls
9	Treatment decision	Treat, accept, avoid or transfer, with a reason
10	Continuity solution	The strategy or plan that responds if the risk happens
11	Owner and due date	A named person and a date, not a department
12	Residual rating and review date	Expected score after treatment and when you will revisit it

Start every risk from a prioritized activity

The most common failure is a register full of generic hazards such as fire, flood and cyber attack, with no link to the activities the organization cannot afford to lose. Fields two and three fix that. Take each prioritized activity from the BIA, list the resources it depends on, and ask what could take each resource away. A payment run that depends on one data center, one supplier and three named people produces very different risks from a marketing team that can work from anywhere for a week.

Phrase each risk as cause, event and consequence: “a power failure at the primary site stops the payment platform, so settlement misses its cut-off”. That structure makes scoring and treatment far easier than a bare label such as “power outage”.

Who to involve in the workshop

Do not fill the register in isolation. Bring the owner of each prioritized activity, someone from IT or facilities who understands the resources involved, a procurement or vendor manager for supplier dependencies, and a representative from risk or compliance. Run the session activity by activity, asking each owner what would stop them working and what they would do first. People close to the work often name risks that no template would suggest, such as a single person holding a critical credential, a manual step nobody has documented or a supplier that has only one delivery route.

Record who attended and the date, since that shows the register reflects real input rather than a desk exercise.

Scoring the business continuity risk register against recovery targets

Impact is where continuity risk differs from general enterprise risk. Instead of scoring impact in isolation, tie each level to how long the activity can be down. ISO 22301 works with the maximum tolerable period of disruption and recovery time objectives set in the BIA, so use them as the anchor for your scale.

1. Define impact levels in time. For example, level one is a disruption well inside the recovery time objective, and level five is one that would exceed the maximum tolerable period of disruption.
2. Define likelihood in words. Give each rating a plain description and an indicative frequency so different assessors score consistently.
3. Score the current position. Rate the risk with existing controls, and record what those controls are so the rating can be challenged.
4. Plot on a heat map. A simple grid shows executives which risks sit above your tolerance at a glance.

If you need the definitions behind these terms, our guide to RTO and RPO explains how the targets are set. Keep the scale small, three by three or five by five, and use the same one for every risk, or your heat map will not be comparable.

Linking the business continuity risk register to treatment and plans

A score on its own changes nothing. Each risk above your tolerance needs a treatment decision, and for continuity risks the treatment usually means a continuity strategy and solution under clause 8.3: an alternate site, a manual workaround, a second supplier, remote working capacity or a data replication arrangement. Record the chosen solution in field ten and reference the plan that activates it.

Some risks are better prevented than planned for. Moving a critical system out of a flood-prone basement removes the risk; a recovery plan only manages the damage. Others are accepted, which is a legitimate outcome if a named person with authority records the reasoning and a review date. Accepting a risk silently is the finding auditors like least.

Test the treatments

Treatments that are never exercised are assumptions. Feed exercise results back into the register: if a failover test missed its recovery time objective, raise the likelihood or impact rating for the related risks and open an action. Our guide to business continuity exercises shows how to plan tests that produce useful evidence.

Keeping the business continuity risk register current

A register completed once for certification decays quickly. Set review triggers that fit how the organization changes: a new supplier for a critical activity, a move of premises, a merger, a major system change, a real incident or a failed exercise. Add a fixed review cycle for everything else, quarterly for high risks and annually for the rest.

Assign one owner for the register as a whole, usually the continuity manager, and one owner per risk. Present the top risks to management at your regular review meeting, along with overdue actions. This guide is written against ISO 22301:2019, and Amendment 1:2024 added climate action considerations, so include climate-related disruption such as flooding, heat and storms in your threat list; check the ISO 22301 page on iso.org for the latest status of the standard.

Common mistakes in a business continuity risk register

• Generic hazards with no activity link. Every risk should name the prioritized activity and resource it threatens.
• Impact scored without recovery targets. If the scale does not reference disruption time, it cannot connect to your BIA.
• Owners set to a team. Accountability needs a name.
• No residual rating. Without it, nobody knows whether treatment worked.
• Ignoring suppliers. Third parties are a frequent source of continuity failures, and your supplier’s disruption becomes yours.
• Never updated after exercises. Test results should change ratings.

Start from a finished business continuity risk register

You can build the register in a spreadsheet in a day, but the scoring scales, heat map and treatment links take the most agreement. The Business Continuity Risk Assessment Report and Workbook gives you a ready structure with a risk register, heat maps, continuity measures and a live workbook to adapt to your own activities. For a worked case, see our business continuity risk assessment example.

Business continuity risk register FAQ

Is a business continuity risk register required by ISO 22301?

ISO 22301 requires a documented risk assessment process and evidence that it is applied. A register is the standard way to hold that evidence, although the standard does not dictate the format.

How is it different from an enterprise risk register?

A business continuity risk register focuses on threats to prioritized activities and their resources, and it scores impact against recovery targets. An enterprise register covers strategic, financial and compliance risks more broadly.

How many risks should it contain?

There is no correct number. Include every risk that could disrupt a prioritized activity beyond its tolerance, and group similar events so the register stays usable. Many organizations find a few dozen well-defined entries more useful than hundreds of vague ones.

How often should it be reviewed?

Review it whenever something material changes and on a fixed cycle. Quarterly for high-rated risks and annually for the remainder is a common pattern.

Who should own it?

The continuity manager usually owns the register, while each risk has a named owner who is accountable for the treatment and for updating the rating.