A free, editable business continuity plan template you can copy or download as a
Word document, no sign-up. Below it, a section-by-section guide to what the plan has
to contain, the four clauses people reliably get wrong, what an auditor asks to see,
and how plans fail in practice. Or have PolicyMint write this one plan for your
business and check it before you see it - your first document is free.
Rather not fill it in yourself? Have it generated in your
branding instead. Card required to download that one; no charge today.
Generated from this page's structure, in an example company's branding
Free template
Free business continuity plan template
The complete business continuity plan, free to copy from this page or download as an editable Word document.
No sign-up. Replace every [bracketed placeholder] with your own details, delete anything that
does not apply, and have it approved before you rely on it. The guide below
explains what each section has to contain and what an auditor checks.
An editable continuity plan. Replace the bracketed placeholders with your own details.
[Organization] depends on a small number of activities that customers and staff notice immediately if they stop. This plan records what they are, how fast each has to be back, who decides the plan is live, and how we work meanwhile.
1. Purpose and scope
This plan covers how [Organization] keeps its critical activities running during a disruption and returns to normal afterward. It applies to [sites, teams and services in scope], the systems and data they depend on, and the suppliers behind them.
2. Critical activities and their dependencies
These are the activities we must keep running, ordered by how fast their loss hurts. Each is recorded with what it leans on: an activity is only as recoverable as its weakest dependency.
[Critical activity 1] - depends on [system], [data], [named people], [supplier], [premises or connectivity].
Everything not listed here is deferred during a disruption. Deciding that in advance is what makes the plan usable.
3. Recovery objectives
For each critical activity we set two numbers. The recovery time objective (RTO) is how long it can be down before the damage is unacceptable. The recovery point objective (RPO) is how much recent work we can afford to lose and recreate. Everything below exists to meet them.
Anyone who believes an incident threatens a critical activity reports it to [role or channel] without delay. [Role] assesses it and may invoke this plan; if they cannot be reached within [15 minutes], [deputy role] invokes it instead. Invocation is recorded with the time, who decided and why. Escalation runs [role] to [senior role] to [executive contact]; [regulator, insurer, key customers] are told once the section 6 thresholds are met.
5. Roles during a disruption
Incident lead [name or role] - invokes the plan, sets priorities, owns the decision log.
Technology lead [name or role] - runs system and data recovery against section 3.
Communications lead [name or role] - every message to staff, customers and outside parties.
Operations lead [name or role] - runs the workarounds and tracks the backlog they create.
Every role has a named deputy and a contact number that does not rely on our own systems.
6. Communications
Staff are told what has happened, what to do now, and when the next update is due, through [primary channel], with [out-of-band channel, for example SMS] as the fallback for when our usual systems are what is down. Customers are told through [status page or account managers] within [target time], with a realistic estimate rather than an optimistic one. Only [role] speaks publicly, using the holding statements at [location].
7. Manual workarounds
Where an activity can continue without its usual system, the workaround is written down before it is needed: what to do, who may do it, and what is reconciled afterward.
[Activity] - record [orders, cases, hours] on [an offline sheet held at location], then key them back in within [timeframe].
[Activity] - fall back to [alternative supplier, phone ordering, manual approval] with approval from [role].
Every workaround creates a backlog and usually loosens a control. Both are cleared before we call it normal again.
8. IT and data recovery
Systems are recovered in the order set by section 3, not by whoever asks loudest. Backups run [frequency] to [location], are retained [period], are held where a compromise of the live environment cannot reach them, and are restore-tested [frequency]. [Role] holds a runbook for each critical system at [location], reachable when our network is down. Recovery is complete when the data has been checked and the activity is usable, not when the server answers.
9. Supplier and third-party failure
A supplier outage is our outage as far as the customer is concerned. For every supplier a critical activity depends on we record the contracted recovery commitments, the out-of-hours escalation contact, and what we do if they are down beyond [threshold]: switch to [alternative], run the section 7 workaround, or accept and communicate the delay. An irreplaceable supplier is recorded as a risk and accepted in writing by [role].
10. Testing, review and version control
This plan is exercised at least [annually], after any significant change to our systems, sites or suppliers, and after any real invocation: a walkthrough by the people named above, a tabletop against a realistic scenario, and a technical restore of [system] from backup. Each exercise records what failed and who owns the fix by when.
Owned by [role]. Approved by [name], [title], on [date]. Version [x.x]. The current copy is stored at [location], in a form still reachable when [Organization]'s systems are down.
A solid starting point, but it is one document. ISO 27001 expects continuity to be joined up with the rest of your management system: the risks it treats, the suppliers behind it, and the Statement of Applicability that records the decision. PolicyMint generates that full set, written for your business and checked before you see it.
Write it yourself
How to write a business continuity plan
10
sections
4
with real wording
6
auditor requests
8
failure modes
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
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
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.
Wording that works
[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
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.
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
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.
Wording that works
[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
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
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
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
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.
Wording that works
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
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
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.
Worked example: how the two numbers get set
A 40-person company that sells online and invoices through a cloud finance system.
Order processing. A morning offline is embarrassing;
two days offline and customers go elsewhere. Management sets the RTO at four hours. Then
the data question: if it failed, how much order entry could the team rebuild by hand from
confirmation emails? About fifteen minutes worth - so the RPO is fifteen minutes, which
rules out a nightly backup and means near-continuous replication.
Payroll. Losing it for a day costs nothing, as long as
it is back before the run on the 27th. RTO three business days, RPO 24 hours - and a
nightly backup is genuinely sufficient.
Two activities in one small business, one number apart, needing completely different
technology. That is why the numbers are set per activity, and why "everything back
immediately" is the least useful answer management can give. Where an objective turns out
to be unaffordable, change the number and record why: an RTO you cannot fund is not a
target, it is a document that embarrasses you twice.
Meeting those numbers is the job of the IT side of recovery: which systems come back in
which order, from which backups, run by whom. That lives in its own document, and the
disaster recovery plan template
covers it.
What section 10 can honestly promise
Do not commit to an exercise program you will not run. Four levels are worth naming,
each finding a different class of failure; committing to the first one forever is the
common mistake, and it is the one an auditor notices.
01
Walkthrough
About an hour
The named response roles read the plan together and each says what they would actually do. This is where the year-old contact list, the deputy who left, and the step that only made sense to its author all surface.
02
Tabletop exercise
Half a day
A facilitator runs a realistic scenario and the team works the decisions live: ransomware hits the file server at 6am and the finance lead is on leave. It finds the decision gaps - who invokes, what gets deferred, when customers are told.
03
Technical recovery test
A day, plus preparation
Restore a critical system and its data from backup into an isolated environment, confirm the data is usable, and time it. This is the test that most often disproves an optimistic recovery time objective.
04
Live or partial simulation
Expensive, and worth it
Run a critical activity on its manual workaround for half a day, with the real team and real volume. The only exercise that shows whether a workaround survives a normal Tuesday.
Separately, restore something from backup on a routine schedule, because backups fail
quietly. Record every exercise the same way - date, scenario, who took part, what failed,
and the actions with an owner and a due date - then change the plan and bump the version.
The point is to find your failures on a Tuesday afternoon rather than at 3am.
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.
Failure modes
Where continuity plans fall over
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.
From draft to audit-ready
Where continuity fits in ISO 27001
ISO 27001 covers the information security dimension of continuity - keeping information
protected and available when things go wrong. ISO 22301 is the dedicated continuity
standard. If ISO 27001 is your goal, what you need is continuity arrangements that hold up
for the information and systems in your scope.
Two Annex A controls carry that. A.5.29, information
security during disruption, is about not quietly abandoning your controls in a crisis:
access approvals, logging and confidentiality still have to mean something while everyone
is restoring service. A.5.30 is the technology half. The
practical question it puts to you is whether the systems, data and services your critical
activities lean on can genuinely be usable again inside the recovery times management
agreed - and whether you can show it. In practice that means a named owner for each
recovery arrangement, a runbook they keep current, and a dated restore that proves the
timing rather than assuming it. ControlStack, our sibling site, has
a control-level walkthrough of that second one.
This is where a standalone plan starts to creak. An auditor reads it against your risk
assessment, your supplier records, your backups and your Statement of Applicability, and
expects the numbers to agree. A plan promising four-hour recovery on a nightly backup is a
finding, not a document.
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 page of the generated document, for an example company. The trial produces the whole
document, not a sample.
Where the guide says [role] or [system], the document says yours; where PolicyMint
cannot know a fact, it asks rather than guesses.
Guided reviewActual product
The one fact this document could not know stays highlighted in the document and the
export. The review explains what is needed and writes your answer in. Nothing is
invented. Fictional demo data.
Side by side
Writing it yourself vs generating it
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.
Dimension
Writing it yourself
Generating it with PolicyMint
What you end up with
One continuity plan you fill in yourself, section by section, from the free template and guide above
The same ten sections, written out in full and exported as Word, PDF or Excel in your branding
Tailored to your business
The activities, dependencies and suppliers are yours to work out
Written from the activities, systems, suppliers and scope you describe, with the square brackets resolved
Recovery objectives
Numbers you work out, cost and justify yourself
An RTO and an RPO drafted beside every activity, from the systems and backups you told us you run
Holds together at audit
Up to you - it is read against your risk assessment and supplier records
Every section cites the clauses and controls it satisfies, so the mapping is written in rather than reconstructed
Checked before you see it
No
Three independent verifiers on a different AI model, plus a repair pass
Time to a finished draft
A day or two of writing, then the reviews
Minutes, then your own review of a draft that already makes the decisions
Price
Free - the template and guide above, plus your own time
Your first document is free on signup, then priced per document, one-time and with no subscription
ISO 27001 documents
36
ISO 27001 documents
tiered by what you actually need
ISO 42001 documents
21
ISO 42001 documents
for AI management systems
Clauses and controls mapped
182
Clauses and controls mapped
every document cites the ones it satisfies
Verifiers per section
3
Verifiers per section
on a different model to the writer
Business continuity plan FAQ
The questions people ask
Including how recovery objectives are actually decided.
What is a business continuity plan?
It is the document that says how your organization keeps its most important work going when something disrupts it - an outage, a cyber attack, losing a building, a supplier failing - and how it returns to normal afterward. A useful one names the activities that must keep running, what each depends on, how fast each has to be back, who decides the plan is live, and how people carry on meanwhile.
What is the difference between RTO and RPO?
RTO, the recovery time objective, is about time: how long an activity can be unavailable before the damage is unacceptable. RPO, the recovery point objective, is about data: how much recent work you could afford to lose and recreate by hand. An RTO of four hours means the service must be back within four hours; an RPO of fifteen minutes rules out a nightly backup. Both are business decisions that then dictate what your technology has to do.
What should a business continuity plan include?
A better test than a checklist: could a deputy run it at 3am, from their phone, with your network down? That rules out anything true only because its author remembers it. Every critical activity needs an owner and its two numbers, every named role needs a named stand-in and a contact route that does not depend on your own systems, and there has to be a way to keep working and a way to keep talking to customers while the fix is still in progress. The guide above walks through the ten sections in that order.
How often should a business continuity plan be tested?
Once a year is the floor, but the calendar is the weaker trigger: a plan goes stale when something material changes, not when a date passes, so tie the next exercise to your change record as well as to the anniversary. A workable rhythm for a small company is a fifteen-minute check each quarter on the parts that rot fastest - phone numbers, deputies, and whether the offline copy is still where the plan says it is - and one facilitated scenario a year with the people who would really make the call. Watch who turns up, too: anyone who has joined a response role since the last exercise has never used the plan.
Does ISO 27001 require a business continuity plan?
ISO 27001 does not hand you a template, but it expects you to work out how information stays protected and available when normal operations break down, and to be able to show that the technology behind that promise really can meet the targets your business set - with someone accountable for it and a restore on record. In practice that means a plan agreeing with your risk assessment, your supplier arrangements and your backup reality. A plan promising four-hour recovery on a nightly backup is a finding waiting to happen.
Does ISO 27001 require a backup policy, and is it part of the continuity plan?
Yes to the first and no to the second. Annex A control A.8.13, information backup, expects you to keep and test backups in line with a documented policy: what is backed up, how often, where the copies live, and how a restore is proved. That is its own short topic policy in the document set, not a section of the continuity plan. The continuity plan depends on it - every recovery objective in the plan is only as good as the backup behind it - which is why the two have to agree, and why a plan promising four-hour recovery on a nightly backup is a finding.
Is this business continuity plan template free to download?
Yes. The complete template is on this page and as an editable Word document, with no sign-up and no card. Replace the bracketed placeholders, delete what does not apply, and have it approved before you rely on it. If you would rather have it written for your organization, with your critical activities, recovery objectives and suppliers filled in, PolicyMint generates it and your first document is free; we ask for a card only when you download that one, and it is not charged.
How much does a full ISO 27001 document set cost?
PolicyMint's Full ISMS / AIMS pack is a one-time A$350US$229£179€209 including GST and covers a complete certifiable ISO 27001 set of 36 finished documents, or a complete ISO 42001 set of 21. Each document is drafted from your own business profile, checked by three independent verifiers before you see it, and exported in your branding as Word, PDF and Excel. There is no subscription and credits are valid for 18 months. That is about A$8.75US$5.73£4.48€5.23 per finished document. For comparison, Advisera publicly lists about A$1,300 (US$897)US$897about £660 (US$897)about €780 (US$897) one-time for pre-written templates you complete with its AI copilot, and GRC Solutions (formerly IT Governance) about A$950 (£495)about US$670 (£495)£495about €580 (£495) excl. VAT. Certification itself is a separate cost, paid to an auditor and a certification body.
Ready when you are
Stop staring at an empty
document set
Set up your business once. Get the documents you actually need, written for how you really operate, in your branding, checked before you see them.
