Business continuity for ISO 27001: BIA, plans and exercises in plain English

Business continuity is how you keep the business running, and protect your information, when something serious goes wrong: a ransomware attack, a cloud outage, a fire, the loss of a key person. For ISO 27001 you don't need a thick binder. You need to know what matters most, how quickly it must be back, and a plan people have practised.

Why it matters

ISO/IEC 27001:2022 covers continuity in Annex A:

• 5.29 (information security during disruption): plan how you keep information secure during a disruption, not just how you keep working.
• 5.30 (ICT readiness for business continuity): make sure your IT can be recovered in time to meet your continuity objectives, and test that it can.
• 8.13 (information backup) and 8.14 (redundancy) support both.

The 2022 version added 5.30, so auditors now expect evidence that recovery has actually been tested, not just planned.

The three parts

1. Business impact analysis (BIA). List your key activities, and for each one ask: how long can we be without it (the recovery time objective), and how much data can we afford to lose (the recovery point objective)? What does it depend on: systems, suppliers, people?
2. Continuity and recovery plans. For your most important activities, write down who does what when it fails: how to recover the system, how to work around it meanwhile, who to tell. Keep it short enough to use under pressure.
3. Exercises. Test the plan: restore from backup, walk through a scenario, check contact details work. Record what happened and fix what didn't work.

What an auditor looks for

• A BIA that identifies critical activities, their dependencies and recovery targets.
• Plans that match the BIA. Recovery steps exist for the critical activities, with owners.
• Tested recovery. Restore test records, and an exercise in the last year, with lessons learned.
• Security during disruption. For example, emergency access doesn't bypass all your controls.
• Supplier dependencies covered, such as what you'd do if your cloud host went down.

Common reasons it fails: plans that were never tested; recovery targets nobody can meet; backups never restored; or plans that depend on a person or system that's no longer there.

Common mistakes, and how to keep it manageable

• Planning for every possible disaster. Plan for losing things (a system, a site, a supplier, a person), not for each cause. One plan covers many causes.
• Untested backups. A backup you've never restored is a hope, not a control. Test restores on a schedule.
• Plans stored only on the systems that fail. Keep a copy somewhere you can reach during an outage.
• Copying asset and supplier details into the plan. Link to the registers so the plan stays current.

How to do it in ClearIMS

1. Open Business continuity. Business continuity planning is included in the price. If it isn't switched on for your organisation yet, ask us and we'll switch it on.
2. Do the business impact analysis: list your key activities, their recovery targets and what they depend on.
3. Write continuity and recovery plans for the critical activities, with owners.
4. Exercise and record. Run drills and restore tests and record the results. Recurring tasks bring restore tests round on schedule.

This supports ISO 27001's continuity controls. It isn't ISO 22301 certification, which is a separate standard.

Related pages

• Incidents: the first response when something goes wrong.
• Tabletop exercises: practising your plans.
• Assets and Supplier register: the dependencies your plans rely on.
• Risk register: the disruption risks your plans address.