BCM Based on ISO 22301
We build your business continuity management so that it is maintained day to day and holds up in an emergency: business impact analysis, robust recovery objectives, emergency and recovery plans, and an emergency response organization that is actually staffed. You decide on the level of implementation, from a lean start based on BSI Standard 200-4 to a certifiable system based on ISO 22301.
The question nobody answers before the outage
Almost every organization has backups, and almost none can say which process must run again first after an outage and how long it can actually survive without it. As long as these two questions remain open, every recovery is improvisation, and when in doubt, whoever shouts loudest decides.
For many, the trigger now comes from outside. In Section 30(2), the BSIG explicitly requires measures to maintain operations, including backup management, disaster recovery and crisis management. For financial entities, DORA is even clearer in Article 11: a dedicated business continuity policy, a business impact analysis and tests of the plans at least once a year.
However, neither set of rules says how quickly you need to be running again. Nobody can give you that number; it comes from your business. That is exactly where BCM begins.
The business impact analysis: damage over time
A risk analysis works with two variables: likelihood and impact. What should you expect, and what does it cost when it happens? The business impact analysis deliberately does not ask about that. It assumes the outage has occurred and only measures how quickly the damage grows. So the risk analysis answers the whether and the how much, the BIA the how fast. Time objectives can only be derived from the second question, which is why neither replaces the other.
The result of this analysis is one number per critical process: the maximum tolerable period of disruption, MTPD for short. It describes how long the process may be down before the damage seriously endangers the organization. It is the only figure in BCM that is not negotiable, because it comes from the business and not from planning.
When the line stops, the damage is immediate: output, delivery reliability, contractual penalties. The transition from noticeable to critical takes barely one shift. For processes like this, expensive redundancy pays off, because every hour saved counts directly.
At first, the organization absorbs the outage by phone and email. It becomes critical at the point where service commitments break and customers leave. This tipping point is what a risk analysis does not show: the damage does not grow evenly.
Almost without consequences for days, and then the calendar decides: reporting deadlines, payroll, financial closings. Here, the tolerable downtime depends not only on the duration but on when the outage happens. At the end of the month, the same process is a different one.
The MTPD is not one number for the company but one per process. Production reaches its limit within a few hours, the customer portal after one to two days, and for accounting it is not the duration that decides but the calendar. Anyone who turns this into a uniform recovery time over-provisions some processes and leaves others unprotected.
The BIA also covers the dependencies without which no process runs: upstream products, service providers, sites, key personnel and only then IT. For financial entities, the BIA is not optional: Article 11(5) DORA explicitly requires it, including consideration of dependencies and their interactions.
RTO and RPO: two numbers, two directions
The maximum tolerable period of disruption yields the two numbers you can plan with. They are easy to tell apart once you put them on a timeline: the outage sits in the middle, availability collapses and returns in steps, and the two objectives point in different directions.
The RPO measures from the outage back to the last consistent data state. It answers how much data loss the organization can cope with, and is therefore a direct statement about backup frequency. An RPO of four hours and a nightly backup do not fit together.
The RTO measures forward from the outage to the point at which the process can work again. Important: this means emergency operations, not normal operations. The RTO determines the effort for redundancy, fallback procedures and standby.
The MTPD is not a planning figure but a limit. It comes from the business impact analysis and describes the point at which the continuation of the business is seriously threatened. The RTO must lie below it, with a margin, otherwise the plan has already failed on paper.
The practical value lies in what follows from the numbers. The RPO is a statement about your backup frequency: if you can cope with four hours of data loss but back up once at night, you do not have a time objective, you have a hope. The RTO is a statement about your budget, because every hour less of recovery time costs redundancy, reserve capacity or standby.
A detail that often gets lost: the RTO ends at emergency operations, not at normal operations. In practice, the longest stretch lies between the two. Anyone who plans the RTO against full recovery buys redundancy they do not need; anyone who does not define emergency operations does not know when they are done in an emergency.
It doesn’t have to be ISO 22301 right away
The most common reason why BCM never gets started in mid-sized organizations is the size of the undertaking. The BSI responded to this and gave Standard 200-4 a tiered model. There are two simplified entry stages and one full stage:
Only the full stage conforms to ISO 22301:2019 and is therefore certifiable. No certification is currently planned for the BSI standard itself. In practice, this means: if nobody wants to see a certificate, you can start with the Reactive BCMS and still be better off when measured against a real emergency than with a binder full of untested concepts.
From analysis to the first exercise
We work in the order that holds up, and we do not stop once the plans are written:
Which stage makes sense for you is something we clarify at the beginning, not at the end. If it turns out that an orderly emergency response organization and three solid plans already get you a long way, we will say so.
BCM is not IT disaster recovery
The most common oversimplification: BCM is what IT does after an outage. In fact, technical recovery is only one part of it. BCM asks about the business process first and only then about the systems, and it also covers cases with no IT connection: the loss of a site, an upstream supplier or key personnel.
That is also why we do not build technical redundancy. We determine what it has to achieve and translate that into requirements for your IT or your service provider. Implementation in the data center stays where the responsibility for it lies anyway.
And we do not certify. Certification to ISO 22301 is granted by an accredited body, not by the consultant who built the system. We prepare you for it and support you through the audit; anything more would not be permissible in our role.
Frequently asked questions about BCM
What is the difference between RTO and RPO?
Both are time objectives, but they point in different directions. The recovery point objective (RPO) looks back from the incident and answers how much data loss is tolerable; it therefore determines the required backup frequency. The recovery time objective (RTO) looks forward and answers how long a process may be at a standstill; it determines the effort for redundancy and fallback procedures. Both must lie below the maximum tolerable period of disruption, which comes from the business impact analysis.
Do we really need a business impact analysis?
Without it, RTO and RPO are guesswork. The BIA is the only step that makes the damage over time visible, that is, the difference between two hours of downtime and two days. The risk analysis works with likelihood and impact; the BIA assumes the outage and measures time. Only the second view allows a maximum tolerable period of disruption to be derived. For financial entities, it is also not optional: Article 11(5) DORA explicitly requires it. The effort can be controlled by starting with a small scope rather than including every process in the company at once.
Do we have to get certified to ISO 22301?
Only if someone demands proof, typically a major customer, a parent company or a regulator. With the Reactive BCMS and the Build-up BCMS, BSI Standard 200-4 offers two simplified entry stages; only the full stage, the Standard BCMS, conforms to ISO 22301:2019 and is therefore certifiable. No certification is currently planned for the BSI standard itself.
Does NIS2 require BCM?
In Section 30(2), the BSIG explicitly lists maintaining operations, including backup management, disaster recovery and crisis management, as part of the risk management measures to be taken. It therefore does not require a certified management system, but it does require demonstrable arrangements. How far they need to go depends on the proportionality rule in the same section.
How often does an emergency plan have to be exercised?
For financial entities, DORA sets a clear minimum: Article 11(6) requires tests of the business continuity plans and of the response and recovery plans at least once a year and additionally after significant changes. Outside the financial sector, there is no fixed number. Our recommendation from practice: the first exercise as soon as the plans are in place, because plans that have never been exercised reliably fail in an emergency.
How long does it take to set up BCM?
That depends on the scope and the level of implementation. An orderly emergency response organization with a business impact analysis for the critical processes and the first recovery plans can be achieved in a manageable time. A certifiable Standard BCMS across the whole organization is a program, not a project. The usual mistake is to want the big solution right away and therefore never get started.