Business continuity · BIA · contingency planning
BCM++
First know what hurts. Then know what to do about it.
A business impact analysis is not a spreadsheet, it is a chain: process, protection requirement, dependency, recovery time, measure. BCM++ holds that chain together — and produces the report somebody eventually asks for.
BCM++ is the oldest application in the suite and is in production use. New organisations are enabled by granting a seat.
Record the processes
Business processes with their protection requirement, recovery time and owner. As fields rather than free text, so that later you can actually work out which outage hurts first.
Critical business processes
18 recordedMake dependencies visible
IT systems, people, suppliers, sites — and which process relies on which. This is where the unpleasant surprises turn up, and they turn up before the outage rather than during it.
Dependencies: order intake
2 of 4 resources are critical for the recovery time.
Rate the impact
Damage over time, per process and per scenario. The recovery order follows from that, rather than from opinions about what matters.
Impact over time
Order intakeRecovery time 4 h — derived from the first column that is no longer tolerable.
Reports on demand
The point at which it becomes clear whether the work was worth anything: a report in a form that survives an audit, generated from what is maintained anyway rather than written up once a year alongside it.
Business impact analysis 2026
Musterwerk GmbH · as of 31 Aug 2026
1. Scope
2. Critical processes
3. Dependencies
4. Measures and deadlines
Every figure in the report comes from the assessment — nothing is retyped.
Where to start
A complete BIA is a lot of work. The first pass is not — it needs the critical processes, not all of them. This order is the one from ISO 22301, and each stage depends on the one before it.
- 1Set the scopeWhich companies, sites and processes are in — and which are not.
- 2Name the critical processesThe ten to twenty whose failure hurts first. The most common mistake is trying to be exhaustive here.
- 3Protection requirement and recovery timeHow long may a process be down before the damage stops being recoverable.
- 4Record the dependenciesIT, people, suppliers, sites — and which process hangs on what. This is where the surprises appear, and they appear before the outage.
- 5Rate the impactDamage over time, per scenario. The recovery order follows from it.
- 6Turn gaps into measuresWith owners and deadlines. Organisations using PM360 work them off there — same organisation, same people.
- 7Generate the reportFrom what is maintained anyway, not written up beside it once a year.
- 8Schedule the reviewA BIA that is never revisited is an assertion after a year.
The order replaces neither advice nor an assessment of your individual case. It answers “where do I start”, not “am I finished”.
What BCM++ does
A BIA is built in an order, and every stage depends on the one before it. BCM++ follows exactly that order.
Track measures and risks
What follows from the analysis gets an owner and a deadline. Organisations using PM360 work them off there — same organisation, same people.
Review cycles
A BIA goes stale. BCM++ records when each part was last confirmed and speaks up before somebody outside asks.
Who this is for
For organisations that cannot leave their own continuity to chance — typically:
- Companies certified to ISO 22301 or ISO 27001, or planning to be.
- Operators who owe evidence under the BSIG or sector-specific rules.
- Groups with subsidiaries that need the same method in every company.
- Anyone keeping a BIA in spreadsheets who has noticed nobody maintains it.
A BIA that is still true next year.
We will show BCM++ against your own structure — your companies, your processes, your review dates.