Business Continuity Plan Template

10

sections the document needs

4

wordings people reliably get wrong

6

things an auditor asks to see

8

ways it usually fails

Ten short sections, in the order they are easiest to write. Before section 1, rank what your organization does by how fast its loss hurts - after an hour, a day, a week - then write down what each activity leans on: people, systems and data, premises and connectivity, suppliers, and the equipment and records nobody misses until they are gone. That ranking is what lets the plan decide in advance what gets deferred.

1. 1

   Purpose and scope

   What it must contain

   Name the organization, the sites, teams and services the plan covers, and the systems, data and suppliers behind them. Say plainly what it does not cover, so nobody assumes a subsidiary or a product line is in when it is not.

   What the auditor checks

   The first contradiction they can find for free. A continuity plan drawn wider or narrower than your ISMS scope statement means one of the two documents is wrong, and they will ask which.

2. 2

   Critical activities and their dependencies

   What it must contain

   The short list of activities that must keep running, ordered by how fast their loss hurts, each one recorded with what it leans on: people, systems and data, premises and connectivity, suppliers, and equipment or records. An activity is only as recoverable as its weakest dependency, so the dependency line is the work.

   What the auditor checks

   That the list is short, ranked, and matches your asset inventory and supplier records. A plan where everything is critical has made no decisions, and they can tell within a minute.

   [Critical activity] - depends on [system], [data], [named people], [supplier], [premises or connectivity]. Everything not listed here is deferred during a disruption.

   The first sentence forces a dependency per activity rather than a title and a hope. The second is the one people delete, and it is the one that does the work: without an explicit deferral line the plan can tell the team what to restart but never what to stop doing, which is the decision that actually frees up the day.

3. 3

   Recovery objectives

   What it must contain

   An RTO and an RPO for every activity in section 2. The recovery time objective is how long it can be down before the damage is unacceptable; the recovery point objective is how much recent work you could lose and recreate by hand. Both are set by the people who feel the pain, and then priced by whoever runs the technology.

   What the auditor checks

   Who chose the number and on what basis, then whether your backup and replication configuration can genuinely deliver it. This is the section that produces the most findings, because the numbers are usually aspirations nobody costed.

   [Critical activity] - RTO [4 hours], RPO [15 minutes].

   Two numbers per activity, not one number per company. Writing them side by side is what exposes the mismatch: a four-hour RTO next to a 24-hour RPO promises you will be back fast with yesterday's data, which is almost never what anyone agreed to when they said four hours.

4. 4

   Invocation and escalation

   What it must contain

   Who can raise it, who decides the plan is live, how long they get before a named deputy decides instead, and how the decision is recorded with a time and a reason. Then the escalation chain, and the threshold at which regulators, insurers and key customers are told.

   What the auditor checks

   They read this one hardest, because it is the only section that can be tested on paper. A clause saying management will assess the situation, with no name, no time limit and no record, is unauditable.

   [Role] assesses it and may invoke this plan; if they cannot be reached within [15 minutes], [deputy role] invokes it instead.

   A named decider, a time limit, and a named fallback in one sentence. Most plans stop at the first clause, which at 3am on a Sunday means nobody in the building has the authority to start, and the first hour goes on finding someone who does.

5. 5

   Roles during a disruption

   What it must contain

   The handful of jobs somebody has to be doing: leading the incident and owning the decision log, running system and data recovery, handling every message in and out, and running the workarounds. Each with a named deputy and a contact route that does not depend on your own systems.

   What the auditor checks

   Whether the names are current and the deputies exist. A response role held by someone who left in March is the fastest finding on the page, and it is the one a one-hour walkthrough would have caught.

6. 6

   Communications

   What it must contain

   What staff are told, through which channel, and when the next update is due. An out-of-band fallback for when your usual channel is the thing that is down. A target time for telling customers, with a realistic estimate rather than an optimistic one. One named person who speaks publicly, and holding statements written before you need them.

   What the auditor checks

   The fallback channel, and what happens to confidentiality while you are using it. Crisis communications that leak customer detail into a personal messaging app is a second incident inside the first.

7. 7

   Manual workarounds

   What it must contain

   For each activity that can run without its usual system: what to do, who is allowed to do it, and what gets reconciled afterward. State outright that a workaround creates a backlog and usually loosens a control, and that both are cleared before you call it normal again.

   What the auditor checks

   This is A.5.29 territory. They will ask how access approval, logging and confidentiality survive the workaround, who approved relaxing them, and when the control went back.

8. 8

   IT and data recovery

   What it must contain

   Recovery order taken from section 3 rather than from whoever asks loudest. Backup frequency, location and retention, held somewhere a compromise of the live environment cannot reach. Restore testing on a schedule. A runbook per critical system, held where it is readable with the network down. And a definition of recovered that means the data has been checked and the work can restart.

   What the auditor checks

   A.5.30, and the evidence most often missing: a dated restore with an elapsed time on it, measured against the objective in section 3, plus the runbook and the person who owns it.

   Recovery is complete when the data has been checked and the activity is usable, not when the server answers.

   It moves the finish line from infrastructure to the business, which is where the RTO was set. It also makes your recovery time honest, because the clock now stops when work can restart - so any restore test has to be timed to that point, not to the login screen.

9. 9

   Supplier and third-party failure

   What it must contain

   For every supplier a critical activity depends on: the recovery commitments actually in the contract, an out-of-hours escalation contact, and what you do if they are down past a threshold - switch, run the section 7 workaround, or accept and communicate the delay. A supplier you cannot replace is recorded as a risk and accepted in writing.

   What the auditor checks

   They cross-read this against your supplier register and the contracts themselves. An assurance that the cloud provider handles it, with no commitment written down anywhere, does not survive the question.

10. 10

    Testing, review and version control

    What it must contain

    The exercise schedule, and the triggers that beat the calendar: a new core system, a new supplier, a restructure, a new site, a real invocation. What each exercise records. Then the housekeeping - owner, approver, approval date, version, and where the current copy lives in a form still reachable when your systems are down.

    What the auditor checks

    The last exercise record, and the actions it raised, closed. An exercise that found nothing reads as an exercise that was too easy.

Nobody is marking your writing. A continuity assessment is six questions, and every one of them is answered with a record rather than a paragraph. Draft the plan so these are easy to say yes to, and the assessment stops being an event.

? Show me the current plan, and tell me who approved it.

Satisfies A version number, a named owner, an approval date inside the last twelve months, and a copy that is readable when your network is down.

Fails A plan whose only copy sits on the file server is a finding on its own, because the file server is one of the things it exists to survive.

? Who decided four hours, and on what basis?

Satisfies A dated record of management agreeing the objectives against the impact of the outage, activity by activity.

Fails The reverse order: technology picking numbers the current backup already meets, then the business being asked to nod at them.

? Show me you can meet it.

Satisfies A dated restore of a critical system with the elapsed time written down, a note that the data was checked rather than just present, and the result compared to the objective. This is the single piece of evidence most often missing, and the one no amount of prose replaces.

Fails A successful-backup screenshot with no restore, elapsed time or check that the recovered data was usable.

? When did you last exercise the plan, and what did it find?

Satisfies An exercise record with the date, the scenario, who took part, what failed, and the resulting actions with an owner and a due date - and then those actions closed and the plan reissued at a new version.

Fails A calendar invitation and attendance list with no scenario results, actions or change to the plan.

? Do your suppliers agree with this?

Satisfies The recovery commitments in the contract for each supplier a critical activity depends on, an out-of-hours escalation route you have actually used, and a written acceptance of the risk where a supplier cannot be replaced.

Fails A supplier website promising high availability, with no contractual recovery commitment or tested escalation contact.

? Does the plan agree with everything else?

Satisfies The same critical systems as your risk assessment, the same suppliers as your supplier register, the same retention as your backup configuration, and the same decision as your Statement of Applicability. Findings live in the gaps between documents far more often than inside one.

Fails A four-hour recovery promise beside a nightly backup, or a critical supplier absent from the supplier register.

Plans rarely fail on the big things. They fail on eight small ones, and every one of these is visible in a draft before anything goes wrong. Read your own against the list.

• ! Everything is critical

  Two-thirds of the activity list marked critical, most of them with an RTO of immediately. A plan that prioritizes nothing has made no decisions and buys the response team no time. Cut until the list is short enough to hold in your head, then write the sentence that says the rest is deferred.

• ! A four-hour RTO on a nightly backup

  The classic finding, and it is arithmetic rather than judgment: if the recovery point is up to 24 hours old, no amount of speed makes the activity usable. Either fund replication or change the number and record why you changed it.

• ! No RPO at all

  Plans routinely carry a recovery time and no recovery point, so nobody notices they have agreed to be back within the hour with yesterday's data. The number belongs to whoever would have to recreate the lost work by hand, not to whoever runs the backup job.

• ! The plan lives where the incident is

  The only copy is on the intranet, the file server, or the laptop that is currently encrypted. Name a location in the plan for an offline copy, and check every quarter that it is still there and still the current version.

• ! The fallback channel runs on the failed system

  Notify staff by email, when email is what is down. Reach the deputy through the directory you cannot log into. A fallback has to sit on different infrastructure, and the numbers have to be somewhere you can read without your own systems.

• ! The contact list is a year old

  Deputies who left, mobile numbers from a previous role, a supplier escalation contact who changed companies. This is the failure a one-hour walkthrough finds every single time, which is exactly why the cheapest test is worth running quarterly.

• ! Written once, never exercised

  Or exercised as the same comfortable walkthrough for four years and never as a technical restore. Each level finds a different class of failure, and only the restore test can disprove an optimistic recovery time.

• ! The workaround quietly drops a control

  Orders on paper, approvals given verbally, a shared login just for the outage. If the plan does not say which control is relaxed, who approved it and when it goes back, you finish the incident with a second one to report.

Your plan comes back with your own critical activities listed, the dependencies under each one, and an RTO and an RPO beside every activity. The invocation clause, the escalation chain, the supplier failure thresholds and the workarounds are written as prose against the roles, systems and suppliers you told us you run, with the square brackets resolved rather than left for you to fill. It arrives in your branding, exported as Word, PDF or Excel. The cover in the hero and the body page below are the opening sections of exactly that document, generated for an example company and rendered by the product's own export.

One continuity plan, two ways to get there. This is about the single document - the rest of the ISO 27001 set is a separate decision, and a later one.

Scroll the table sideways to compare both routes.