How do you set up a working BCM process?

Business continuity management (BCM) is the management process that keeps your organisation delivering its critical products and services, even when something goes seriously wrong. Setting up a proper BCM process means more than having a plan on the shelf: continuity becomes a living part of how you run the organisation every day. This article walks you through building that process step by step, the products and registers that belong to it, and how to make the whole demonstrable under the Dutch Cyber Security Act (Cyberbeveiligingswet, Cbw).

In short

• BCM ensures that your critical services continue at an agreed minimum level during a disruption.
• The international standard is ISO 22301, built around a cycle of planning, doing, checking and improving.
• You manage it at three levels: strategic (direction), tactical (design) and operational (execution).
• The core is the business impact analysis (BIA), which produces the recovery objectives RTO, RPO and MTPD per process, plus the minimum service level (MBCO) you intend to maintain.
• Continuity only becomes demonstrable when you manage the outcomes in registers that you keep current, and not in loose documents.

What is business continuity management (BCM)?

BCM is the coherent whole of policy, analyses, plans, provisions and exercises that enables your organisation to absorb a disruption. The goal is threefold: absorb the disruption, keep functioning at an acceptable minimum level while it lasts, and then return to normal operations in a controlled way.

The international standard is ISO 22301. It describes BCM as a continuous process rather than a one-off project. It is important to realise that BCM is broader than IT alone. A disruption can just as easily be caused by the loss of key staff, the failure of a supplier or an unusable building as by a cyber attack.

Why a BCM process is urgent now: the duty of care in the Cbw

Continuity is no longer optional. In the Netherlands, the Cyber Security Act (Cbw) applies: the national implementation of the European NIS2 directive. NIS2 itself is addressed to the member states and does not apply directly to Dutch organisations. The obligations run through the Cbw.

The Cbw imposes a duty of care: you must take appropriate measures for the continuity of your services and for managing your risks. Final responsibility rests with the board, with personal liability as the ultimate consequence. A working BCM process is exactly the evidence a regulator wants to see. It shows that continuity is not merely arranged on paper, but tested and kept current.

The three levels of BCM: strategic, tactical and operational

A sound BCM process is anchored at three levels. This division applies both to routine management in quiet times and to the crisis organisation you activate during a disruption.

At the strategic level sits the ownership. The board adopts the continuity policy, determines the risk appetite and designates the critical products and services. This responsibility cannot be delegated. During a crisis, this level forms the policy team that guards the course, the reputation and the legal position.

At the tactical level, most of the professional work takes place. This is where you carry out the analyses, choose the continuity strategies and design the plans and exercises. During a crisis, this level directs the actual recovery and forms the link between board and execution.

At the operational level, execution happens under pressure. This is where the concrete recovery procedures, the call and escalation schedules and the technical failover live. The IT disaster recovery plan also lives here, as the technical implementation of the recovery objectives set at the tactical level.

The BCM process as a continuous cycle

ISO 22301 structures BCM as a cycle of planning, doing, checking and improving. You first establish the context, the policy and the objectives, and carry out the analyses. You then choose strategies, put provisions in place and draw up the plans. After that, you test those plans in exercises and verify that they work. Finally, you process the lessons from exercises, incidents and evaluations, and report back to the board.

That last step makes the difference between a file that ages and a process that keeps working. Plans you never exercise count as untested.

The core products of a BCM process

When you set up a BCM process, you produce a set of connected documents. Each product answers its own question.

The continuity policy is the framework adopted by the board. It records the objective, the scope, the starting points and the responsibilities.

The business impact analysis (BIA) is the analytical core. For each critical process, you determine how the impact of an outage grows the longer it lasts, and from that you derive the key figures. Those key figures are the foundation under every plan:

• The RTO (Recovery Time Objective) is the time within which a process must be running again.
• The RPO (Recovery Point Objective) is the amount of data loss that is acceptable.
• The MTPD (Maximum Tolerable Period of Disruption) is the outer limit beyond which the damage becomes irreversible. The RTO always falls within it.
• The MBCO (Minimum Business Continuity Objective) is the minimum level of service you maintain during a disruption.

The threat analysis complements the BIA. Where the BIA looks at the consequences of an outage, the threat analysis looks at the causes. You assess scenarios such as a ransomware attack, the loss of a data centre or the failure of a critical supplier for probability and impact, and determine which measures are needed.

The continuity strategy connects the analyses to practice. For each process you choose how to absorb a disruption: with redundancy, with failover to an alternative environment, with a manual emergency procedure, with a fallback supplier, or by consciously accepting a residual risk.

The continuity plans, finally, turn those choices into concrete playbooks that you follow during a disruption.

From analysis to living management: the BCM registers

Here lies the step many organisations skip. The BIA and the threat analysis are a snapshot. A register is the living counterpart: it keeps track of the current state and forms the evidence for your duty of care. A mature BCM process therefore keeps the following up to date continuously.

The continuity risks are the ongoing successor of the threat analysis. Every disruption scenario is recorded with probability, impact, risk score, an owner and the status of the measures. You do not need a separate register for this: in Kantyra you manage these risks in the shared risk register, recognisable by the Continuity category.

The critical products and services are recorded with their recovery objectives. This is the living outcome of your BIA: which processes are critical and how quickly they must be running again.

The plans and exercises are maintained as two connected parts: which continuity plans exist and which version applies, and when they were last tested. This is how you demonstrate that plans do not merely exist, but work.

The improvement actions are collected with an owner and a due date. Everything that comes out of exercises, incidents and evaluations is managed as tasks you complete.

The suppliers are recorded with their availability and the agreements about fallback. A supplier without a fallback is immediately a visible continuity risk that falls squarely under your duty of care in the Cbw.

The incidents are registered with the actual recovery time and the question whether the reporting duty in the Cbw applied.

Together these parts form a loop. An incident produces an improvement action, an improvement action changes a plan, a plan is tested in an exercise, and a disappointing exercise or a supplier without a fallback raises a risk in the risk register again.

Continuity risk or enterprise risk?

A frequent question is how the continuity risks relate to the organisation's central risk register. They look alike, but they answer a different question.

The enterprise risk register, in the tradition of ISO 31000, contains all risks to the organisation's objectives: strategic, financial, personnel and more. The question is: are we drifting from our objectives, and does that fit within our risk appetite?

A continuity risk is a specialised subset of that. It deals exclusively with disruptions of your critical services, and the question is: can we keep delivering, and how quickly do we recover? The associated recovery objectives and recovery strategy are recorded in the BIA and the continuity plan, while the risk itself is recognisable in the risk register by the Continuity category.

What matters most is anchoring the relationship properly. In Kantyra you therefore do not keep two separate registers side by side: you manage all risks in one register and label the continuity risks with the Continuity category. That gives you a single board-level overview without double counting. That coherent risk management is exactly what the Cbw asks of you.

Do you work with Excel or with a GRC platform?

You can keep these registers in Excel or in a shared library, and as an interim step that is defensible as long as ownership, version control and a review rhythm are in place. But as your BCM process matures, you run into the limits. Loose files drift apart, the risk score does not calculate itself, and you lack the history you need to demonstrate your duty of care.

In a GRC platform, you manage the registers as connected overviews within a single environment. The risk score calculates itself, the risk matrix fills itself, and every register has an owner, a status and a review date. The connections also make the loop visible: an exercise that does not fully succeed is automatically turned into an improvement task by Kantyra, and an expired exercise date stands out immediately.

At Kantyra, BCM is an extension of the ISMS and GRC platform. That means you do not organise continuity separately, but on top of the information security you already manage. You record the crisis organisation in the BCM strategy and manage your continuity risks in the same risk register as the rest of your ISMS, so you never do the same work twice. Your BCM components and your Cbw obligations come together in one environment.

Setting up a BCM process in six steps

1. Adopt the continuity policy. Have the board determine the objective, the scope and the risk appetite.
2. Designate the critical products and services. Determine what must remain standing under all circumstances.
3. Carry out the BIA. Determine the RTO, RPO and MTPD per critical process, and the minimum service level (MBCO).
4. Make a threat analysis and choose your strategy. Assess the scenarios and decide per process how to absorb a disruption.
5. Draw up the plans and exercise them. Translate the strategy into playbooks and test them periodically.
6. Manage everything in registers. Keep the risks, services, plans, improvement actions, suppliers and incidents current, and connect them to each other.

Frequently asked questions about BCM

What is the difference between BCM and a continuity plan? BCM is the management process as a whole, from policy to exercises. A continuity plan is one product within it: the playbook you follow during a disruption. You need both.

What is the difference between a BCP and a DRP? A business continuity plan (BCP) keeps a business process running, if necessary without the usual systems. An IT disaster recovery plan (DRP) restores the technology. The DRP is therefore a technical component under the broader BCP.

Does my organisation have to comply with NIS2 or with the Cbw? In the Netherlands, only the Cbw applies. NIS2 is the European directive on which the Cbw is based, but it does not apply directly to Dutch organisations. You comply with the Cbw, not with NIS2, and certainly not with both at once.

What do RTO and RPO mean? The RTO is the time within which a process must be running again after a disruption. The RPO is the amount of data loss you can tolerate, in other words how far back you may fall onto a backup. You determine both per critical process in the BIA.

Can I do BCM with Excel? For a simple start, yes, as long as you secure ownership, version control and a review rhythm. As your process matures and you want to make it demonstrable under the Cbw, a GRC platform with a BCM module is more practical and more reliable.

Getting started with BCM in Kantyra

Would you rather not manage your BCM process in loose files, but in one environment that connects to your information security and your Cbw obligations? With Kantyra's BCM module you maintain your continuity plans and exercises, risk scores are calculated automatically, and your continuity becomes demonstrable. Request a demo and discover how to build continuity on top of your existing ISMS.

Kantyra is a Dutch ISMS and GRC platform that lets organisations manage their information security, risk management and continuity demonstrably, in line with ISO 27001, ISO 22301 and the Dutch Cyber Security Act.