Building a business continuity plan alongside ISO 27001 means treating continuity as one control set inside your Information Security Management System, not a separate binder nobody reads. This guide walks through the exact steps, in the order auditors expect to see them, for a 2026 certification cycle.
Why this matters
ISO 27001:2022 folded business continuity squarely into Annex A, under control 5.29 (Information security during disruption) and 5.30 (ICT readiness for business continuity). Auditors in 2026 no longer accept a continuity plan that sits outside the ISMS scope — it has to reference the same risk register, the same asset inventory, and the same incident response procedure.
Miss this link and you get a nonconformity at certification, or worse, at the first surveillance audit a year later. Get it right and continuity planning becomes one more automated control instead of a parallel compliance project competing for the same two people's time.
If your organisation is heading toward stricter continuity obligations — client contracts requiring demonstrable resilience, or regulated-sector procurement — read the dedicated guide to ISO 22301 business continuity certification alongside this one. ISO 22301 goes deeper than what ISO 27001 requires, and some clients will ask for it specifically.
What you'll need
- A completed or in-progress ISO 27001 risk assessment and asset inventory
- Access to your incident response procedure (continuity plans reference it directly)
- Business impact analysis inputs: recovery time objectives (RTO) and recovery point objectives (RPO) per critical system
- A list of critical suppliers and their own continuity commitments
- Two to four hours of leadership time for the tabletop exercise
- A document or platform to store evidence — auditors expect version history, not a single static PDF
The steps
1. Run a business impact analysis before you write anything
A business impact analysis identifies which processes cause the most damage if they stop, and how fast. Skip this step and your continuity plan protects the wrong systems.
Score each critical process on financial impact per hour of downtime, regulatory exposure, and customer-facing visibility. Set an RTO (how fast it must come back) and an RPO (how much data loss is tolerable) for each one.
Common mistake: treating every system as equally critical. A plan that gives your CRM and your internal wiki the same four-hour RTO wastes recovery budget on the wrong priority.
2. Map continuity controls onto your existing ISO 27001 risk register
Don't build a second risk register for continuity. Annex A control 5.29 expects continuity risks — power loss, ransomware, supplier failure, key-person absence — to sit in the same register as your information security risks, scored the same way.
This is also the point to run or revisit an ISO 27001 gap analysis if you haven't already, because continuity gaps often surface controls you'd missed elsewhere in Annex A.
Expected outcome: one register, one set of owners, no duplicate risk entries for the same event.
3. Write recovery strategies for each critical process
For every process scored in step 1, document the recovery strategy: backup site or cloud failover, alternative supplier, manual workaround, or accepted downtime. Attach the RTO and RPO you already set.
Be specific. "Restore from backup" is not a strategy. "Restore production database from the last automated snapshot, verified restorable within 4 hours, tested quarterly" is.
Common mistake: writing a strategy that assumes the same team member who normally handles it will be available. Continuity plans exist for the scenario where that person isn't.
4. Draft the plan document itself
Structure it in four parts: activation criteria (what triggers the plan), roles and responsibilities, the recovery procedures from step 3, and communication protocols for staff, customers, and regulators.
Keep activation criteria measurable — "primary data centre unreachable for over 30 minutes" rather than "a serious incident occurs." Vague triggers cause delayed activation, which is the most common real-world failure auditors flag.
Expected outcome: a document any trained staff member could follow without you in the room.
5. Test it with a tabletop exercise
A written plan that's never been tested is a guess. Run a tabletop exercise for incident response that walks a chosen scenario — ransomware, key supplier outage, office inaccessible — through the plan step by step with the actual response team in the room.
Do this annually at minimum; auditors treat a tabletop conducted within the last 12 months as standard evidence in 2026 surveillance audits.
Common mistake: only testing the technical recovery and skipping the communication protocol. Half of tabletop failures in practice are about who tells whom, not whether the backup restores.
6. Feed test results back into the plan
Every tabletop exercise surfaces gaps: a missing contact number, an RTO that turned out to be unrealistic, a supplier who couldn't be reached. Log every gap and update the plan document with a version number and date.
This version history is exactly what auditors check first — it proves the plan is a living document, not a certification-week artefact.
7. Assign an owner and a review cadence
Name one person accountable for the continuity plan, separate from whoever owns day-to-day IT. Set a review cadence — most organisations land on annual, tied to the ISO 27001 management review cycle.
Expected outcome: a named owner an auditor can interview, who can explain the last update and why it happened.
Troubleshooting
- Auditor flags the continuity plan as disconnected from the ISMS — cross-reference the same risk IDs and asset names used elsewhere in your Statement of Applicability. Disconnected documents are the single most common nonconformity here.
- RTOs were set but never tested against real recovery time — run a controlled failover or restore test and correct the RTO to match reality, not aspiration.
- Tabletop exercise keeps getting postponed — schedule it against a fixed calendar date tied to the management review meeting, not "when things quiet down."
- Plan references a supplier that no longer exists — this happens more than most teams admit; review supplier lists every time you update the plan, not just at renewal.
- No one can find the latest version — store the plan in the same evidence system as your other ISO 27001 documentation, with version control, not a shared drive folder.
- Continuity plan duplicates the incident response plan almost word for word — they should reference each other, not repeat each other; continuity covers sustained disruption, incident response covers the initial hours.
Automate ISO 27001 continuity evidence
OneClickComply keeps your continuity plan, risk register, and audit evidence in one place.
Tools and resources
- Your existing ISO 27001 risk register and Statement of Applicability
- A tabletop exercise template covering at least two disruption scenarios
- A control mapping showing how continuity requirements tie back to ISO 27001 Annex A controls already in place
- Automated evidence storage so version history and audit trail exist without manual filing
- Supplier continuity questionnaires for any critical third party in your recovery strategy
What to do next
Once the plan exists and has survived one tabletop exercise, the next job is making sure the evidence trail survives an audit without a scramble. Read the guide on automating evidence collection for audits to see how continuous evidence capture replaces the pre-audit document hunt.
OneClickComply handles the evidence side of a business continuity plan under ISO 27001 automatically — version history, control mapping, and audit-ready exports without a spreadsheet marathon each renewal.
Frequently asked questions
One last thing
Most organisations write the continuity plan once for certification and never open it again until the next audit. The ones that pass surveillance audits without findings are the ones who fed at least one tabletop exercise result back into the document within the same year — that single update is often the difference between a clean audit and a nonconformity in 2026.