Published
Summary: Business continuity management does not begin with a plan, a standby server or a crisis organisation. It begins with the question of which parts of the business must be able to continue, how long they can be disrupted, and what it takes to keep them running at an acceptable level. The route there is the business impact analysis: critical activities, the maximum tolerable period of disruption, recovery objectives set by the business itself, and a map of the dependencies those activities rest on. Only then do the continuity plan, the workarounds and the exercise become meaningful.
Continuity is not backup, and not crisis management
When continuity is discussed, the conversation quickly turns to backup, standby servers or crisis management. All three matter, but business continuity management starts somewhere else: in the business.
The first question is not which system to restore. The question is which parts of the business must be able to continue, how long they can be disrupted, and what it takes to keep them running at an acceptable level.
Four concepts that are often conflated:
- Continuity is about how the business carries on during the disruption.
- Recovery, DR, is about how the technology comes back.
- Crisis management is about strategic leadership, priorities and communication in a major disruption.
- Incident management is about the event itself.
How they fit together once something actually happens is covered in our insight on incident triage. This article is about the work before that: how the capability is built.
Start with the impact analysis, not with the continuity plan
It is hard to write a good continuity plan before the organisation knows what actually has to be prioritised. The Swedish Agency for Civil Defence, formerly MSB, publishes a methodology for business continuity management based on selected parts of SS 22304:2023, the Swedish handbook for continuity management under SS-EN ISO 22301. It starts precisely by identifying the organisation’s critical activities and analysing the consequences of disruption, and uses the results of the impact analysis and the risk assessment as the basis for the measures that follow.
So do not start with the question of which plan to write. Start with the question: what happens to the business if this activity cannot be carried out?
Then describe the consequence over time:
- after 30 minutes
- after four hours
- after one day
- after three days
- after a week
And across different types of consequence:
- customers, patients or citizens
- finances
- law and contracts
- safety and security
- trust
- other organisations that depend on you
This analysis, the business impact analysis or BIA, is a central foundation for the continuity work that follows under ISO 22301. It decides what is worth protecting, and how fast.
Identify critical activities, not just critical systems
A business will often say the ERP system is critical. But the first question should be: which business activity is critical, and why is the ERP system needed to perform it?
Asked that way, the question shows that the same critical activity usually also depends on:
- people and key competence
- premises
- information
- telephony and networks
- suppliers
- access rights
- manual records
- other processes
ISO’s dedicated guidance on business impact analysis, ISO/TS 22317:2021, makes exactly this point: the analysis should identify the prioritised activities and the resources and dependencies required to perform them during a disruption, including suppliers, partners and other external parties.
How long can we accept the outage?
This is where the time concepts come in. They do not need to become a glossary, but three of them carry the whole exercise:
- MTPD, maximum tolerable period of disruption. When does the consequence of the disruption become unacceptable?
- RTO, recovery time objective. When does the activity or service need to be back? The RTO needs to be shorter than the MTPD, and in practice there should be a reasonable margin between them.
- RPO, recovery point objective. To which point in time must information be recoverable, in other words how much data loss, expressed in time, can the business accept?
ISO/TS 22317 describes the impact analysis as the basis for judging when consequences become unacceptable, setting the MTPD and RTO for the prioritised activities, and identifying the relevant RPO requirements and dependencies.
The most important thing about the three concepts is who owns them. The RTO should not start in IT. IT should be able to say what the technology can deliver, but the business first needs to say how long it can manage without the capability.
If the business needs to be back within four hours and IT’s realistic recovery time is two days, the organisation has identified a gap. That is exactly what the analysis is meant to reveal. The gap is not a failure, it is a basis for a decision: invest in faster recovery, build a workaround that covers the two days, or accept the risk knowingly.
Map the dependencies
For each prioritised activity the organisation needs to know what it rests on:
- people and key competence
- information
- IT systems
- premises
- equipment
- power and communications
- internal processes
- external suppliers and their subcontractors
- other organisations
The Swedish Agency for Civil Defence provides a process-map template precisely to visualise the critical activities and dependencies identified in the impact analysis. It distinguishes between internal resources the organisation controls and external resources it does not.
That distinction matters. If a critical activity only works as long as a particular SaaS provider, consultant or haulier is available, that supplier dependency is part of continuity planning, not merely a procurement question.
From analysis to continuity strategy
Once the organisation knows what is critical, how long it may be down and which dependencies exist, it can decide how the business will carry on. The options are more numerous than people tend to think:
- manual working methods
- alternative premises
- replacement systems
- standby equipment
- alternative suppliers
- stockholding
- redundancy
- reprioritising staff
- reduced service levels
- technical failover
The strategy is the choice among these options for each activity, weighing cost, time and risk. The plan then becomes a result of the analysis and the strategy, not a free-standing document written in order to exist.
Four plans that are often confused
| Plan | Main question | Normally owned by |
|---|---|---|
| Incident response plan, IRP | How do we detect, assess, contain and handle the incident? | IT, security or the incident organisation |
| Business continuity plan, BCP | How does the business carry on during the disruption? | The business |
| Disaster recovery plan, DRP | How do we restore IT, data and technical infrastructure? | IT |
| Crisis plan | How does the organisation lead, prioritise and communicate in a serious event? | Management |
The four plans may need to be activated at the same time, but they solve different problems. An organisation that only has a recovery plan has technical recovery, not business continuity management. The technical side of recovery, including how RTO and RPO are met in practice, is explored in our insight on Microsoft 365 backup and recovery.
The workaround has to be realistic
“Work manually” is not a continuity plan. For that workaround to function, someone has to have thought through:
- what information staff need
- whether that information is available when the system is down
- how new records are captured in the meantime
- how the volume is handled
- how long the routine works before it breaks down
- what staffing it requires
- how the information is fed back once the system is restored
The last point is often forgotten. A workaround that works for two days but leaves the organisation with three days of backlog entry has moved the problem, not solved it.
Exercise to find what you did not know
The aim of a good continuity exercise is not to score green on every point. It is to find the problems in a controlled exercise instead of during a real outage.
One scenario goes a long way. It is Tuesday, 09:15. Your most important SaaS service is down. The provider cannot give a prognosis. At lunchtime they say the outage may last at least 48 hours. What do you do?
- When is the continuity plan activated, and by whom?
- Which workaround starts?
- Who contacts the provider, and what do you demand of them?
- What happens when staff change shift?
- What is communicated to customers, and when?
- When does this become a matter for crisis management?
The answers to those questions, and above all the silences where answers are missing, are the result of the exercise.
Maintain the capability, not the document
A continuity plan is perishable. It needs reviewing when:
- a critical system is replaced
- a supplier changes
- the business is reorganised
- new critical processes are added
- the RTO changes
- an exercise or a real incident reveals gaps
- new dependencies arise
Both ISO 22301 and the Swedish handbook SS 22304 treat follow-up and improvement as part of the continuity management system, not as a separate afterthought. It is also where continuity meets the broader work on operational resilience that more and more regulation demands.
How Kristensson i Skåne can help
Kristensson i Skåne helps organisations move from a general ambition of continuity to a concrete, tested capability, as part of our work on preparedness, continuity and resilience. Support can include, for example:
- scoping and establishing the continuity programme
- business and impact analysis
- identifying critical activities
- setting MTPD, RTO and relevant RPO
- mapping internal and external dependencies
- risk assessment
- continuity strategies and workarounds
- drafting or quality-assuring continuity plans
- linking the continuity plan, recovery plan, incident and crisis management
- continuity exercises and tabletop
- action plan and ongoing follow-up
Our starting point is that the plan has to work when it is used. A document that looks complete but does not survive the first shift change has not made the business any more resilient.
Frequently asked questions
What is the difference between business continuity management and backup?
Backup is a technical measure for restoring information. Business continuity management is about how the business carries on during a disruption, whether the cause is an IT outage, a supplier failing to deliver, staff absence or unusable premises. Backup is often part of the continuity strategy, but never the whole of it.
What is a business impact analysis, or BIA?
A business impact analysis describes what happens to the business over time if an activity cannot be performed. It identifies critical activities, how long they can be disrupted, and which resources and dependencies they require. ISO 22301 makes it a central foundation for the continuity work that follows.
What do MTPD, RTO and RPO mean?
MTPD is the maximum time an activity can be disrupted before the consequence becomes unacceptable. RTO is the target for when the activity should be restored and needs to be shorter than the MTPD, in practice with a reasonable margin. RPO states the point in time to which information must be recoverable, in other words how much data loss expressed in time is accepted, and drives how often information needs to be secured.
Who should decide the RTO?
The business. IT can say what the technology can realistically deliver, but it is the business that knows how long it can manage without the capability. The difference between the business requirement and IT’s capability is a gap to be surfaced and decided on, not hidden.
How often should the continuity plan be exercised?
As a rule of thumb we recommend at least one exercise a year, and additionally when critical systems or suppliers are replaced, the business changes materially or a real incident has revealed gaps. Some regulated organisations face specific requirements on test frequency. The exercise is meant to find problems under controlled conditions, not to confirm that everything works.
Want to know how long your business can actually stand still? Read more about our business continuity management and exercise offering or contact us for an informal conversation.
Sources: ISO 22301:2019 with Amd 1:2024, Security and resilience – Business continuity management systems – Requirements, the current published edition at the time of verification; a new edition is under development; ISO/TS 22317:2021, Guidelines for business impact analysis; SS 22304:2023, the Swedish handbook for business continuity management under SS-EN ISO 22301; the Swedish Agency for Civil Defence (Myndigheten för civilt försvar, formerly MSB), methodology for business continuity management with its process-map template for impact analysis. Verified 21 September 2026.
This text is general information. Which activities are critical and which recovery objectives are reasonable always depends on the individual organisation.