Most businesses only discover the gaps in their resilience planning when disruption has already started. A ransomware attack, a flooded server room, or a supplier collapse forces the question nobody wants to answer under pressure: who does what, and in what order? A solid business continuity planning policy stops that scramble before it starts, giving your organisation a written standard for how it prepares for and responds to disruption, rather than relying on memory and good intentions.
This guide walks through exactly how to structure and write one, from setting the policy’s purpose and scope to defining roles, recovery priorities, and review cycles. You’ll end up with a document that satisfies auditors, reassures insurers, and actually holds up when something goes wrong, not just a file that sits untouched on a shared drive.
We’ve built this guide around what we see working (and failing) in real incident response and business continuity plan policy reviews across our client base. Whether you’re drafting your first policy from scratch or tightening up an existing one ahead of an ISO 27001 audit, you’ll find a clear structure to follow, practical wording to adapt, and the common mistakes worth avoiding before your next disaster recovery test.’
What is a business continuity planning policy?
A business continuity planning policy is the governing document that sets out why your organisation prepares for disruption, who is responsible for that preparation, and what standards any resulting plans must meet. It sits above the operational detail. Think of it as the constitution, not the playbook: it establishes the principles, authority, and scope that everything else, including your actual continuity and recovery plans, must follow. Without this document, individual teams tend to write their own ad hoc procedures, which creates gaps, duplication, and confusion about who has final say when an incident hits.
Policy vs plan: what’s the difference?
Confusion between the policy and the plan is one of the most common mistakes we see during audits. The policy answers "why and under what authority do we do this?" The plan answers "exactly what do we do, step by step, when disruption happens?", which is why it helps to know how to build the continuity plan itself before you finalise the policy. Keeping them separate makes both documents easier to maintain, because you can update operational detail in the plan without triggering a full policy review every time a phone number or supplier changes.
| Document | Purpose | Typical audience | How often it changes |
|---|---|---|---|
| Continuity policy | States commitment, scope, authority, and standards | Board, auditors, senior management | Annually or after major organisational change |
| Continuity plan | Details recovery steps, contacts, and procedures | Incident response teams, IT, operations | Whenever systems, staff, or suppliers change |
| Business impact analysis | Identifies critical functions and recovery timeframes | Risk owners, department heads | Every 12 to 18 months |
A continuity policy tells people what your business promises to do about disruption; the plan tells them how.
What a business continuity planning policy typically includes
Most policies that hold up under audit scrutiny cover the same core ground, regardless of company size or sector. A well-written policy usually includes:
- A statement of intent from leadership committing the organisation to continuity planning
- The scope, meaning which sites, systems, departments, or subsidiaries the policy covers
- Defined roles and responsibilities, including who owns the policy and who can invoke a response
- A commitment to conducting a business impact analysis at set intervals
- Recovery time objectives and recovery point objectives as guiding principles, not detailed figures
- A requirement for regular testing, review, and version control
- References to related standards, such as ISO 22301 for business continuity management or ISO 27001 for information security
This list isn’t decoration. Each item maps directly to a question an auditor, insurer, or client due diligence questionnaire is likely to ask. Missing any one of them is usually what triggers a finding during a certification audit.
Why it matters for compliance and insurance
Insurers increasingly ask to see a documented continuity policy before they’ll quote cyber cover, and they’ll ask again after a claim to check whether you actually followed it, so it pays to know what insurers expect to see before they offer cyber cover. Certification bodies assessing you against ISO 27001 expect a continuity policy that links directly to your information security management system, not a generic template lifted from the internet. We’ve seen organisations lose points at audit purely because their policy and their information security controls referenced different recovery objectives, a mismatch that’s easy to avoid once you know it’s a common trap.
Beyond compliance, the policy protects your organisation when it matters most: during an actual incident, when there’s no time to debate who’s in charge. Our CyberSOS incident response service exists precisely because businesses without this groundwork lose critical hours arguing over authority instead of executing a response. Get the policy right first, and the plan, the testing, and the incident response all become far more straightforward.
Step 1. Define the purpose and scope
Every business continuity planning policy needs a clear starting point before anyone writes a single procedure. This first step forces you to answer two questions: why does this policy exist, and what exactly does it cover? Skip this stage and you end up with a document that tries to be everything to everyone, which usually means it protects nothing properly.
Write a purpose statement that means something
Open with a short statement of intent that says why the organisation is committing to continuity planning, not a vague mission statement. Something like: "This policy establishes the framework by which [organisation name] prepares for, responds to, and recovers from disruptive incidents, protecting our people, data, clients, and operations." Keep it specific enough that leadership can be held to it, and general enough that it doesn’t need rewriting every time a new system gets added.
A purpose statement without teeth is just a sentence; tie it to accountability and it becomes a policy.
Draw the boundaries of your scope
Scope defines what the policy actually governs, and this is where most first drafts go wrong, much as they do when setting your ISMS boundaries for certification. Businesses either scope too narrowly, covering IT systems only, or too broadly, promising coverage they can’t operationally support. Be explicit about what’s included and, just as importantly, what isn’t.
When you draft the scope section, work through these questions and record the answers directly in the policy:
- Which sites, offices, or facilities does this policy cover?
- Which business units, subsidiaries, or departments are in scope?
- Which systems and third-party services fall under the policy, including cloud providers and outsourced IT?
- Does the scope extend to suppliers and partners whose failure could disrupt your operations?
- Are there any exclusions, such as newly acquired entities not yet integrated, and if so, by when will they be brought in scope?
Document these decisions plainly rather than leaving them implied. If your policy covers UK operations only, say so, and note when overseas sites will be reviewed for inclusion. Auditors and insurers will ask exactly this question, and "we assumed it covered everything" isn’t an answer that holds up during a claim or certification review.
Finally, keep the scope realistic against your actual resources. Promising continuity coverage for every system and supplier when you have no budget for redundant infrastructure sets the policy up to fail its first real test. Narrow, honest scope beats broad, unenforceable ambition every time.
Step 2. Secure leadership commitment and assign roles
A business continuity planning policy without a named owner and a signed-off budget is a wish list, not a policy. This step is where you convert good intentions into accountability, because when disruption hits, someone needs the authority to declare an incident, spend money, and make decisions without waiting for a committee to convene. Get this wrong and you end up with a document everyone agrees with in theory but nobody actually acts on when it counts.
Get sign-off from the top, not just the middle
Leadership commitment has to come from someone who can actually allocate budget and override departmental objections, typically the board, CEO, or an appointed director. A policy signed off by an IT manager might satisfy an internal checklist, but it won’t carry weight when a department head refuses to release staff for testing or a finance director questions the spend on backup infrastructure. Get the signature of whoever holds real authority, and record the date of that approval directly in the document, since auditors will ask for it.
A policy with no named owner belongs to nobody, and nobody-owned policies don’t survive contact with a real incident.
Build a role structure that survives an actual incident
Once you have commitment, assign specific recovery roles and responsibilities rather than vague statements like "IT will handle it". Every role should have a named person and at least one nominated deputy, because incidents rarely wait for someone to return from leave, and clear response roles speed up recovery.
| Role | Typical responsibility | Who usually holds it |
|---|---|---|
| Policy owner | Maintains and updates the policy, schedules reviews | Senior manager or CISO |
| Incident commander | Declares an incident, coordinates the response | Operations director or nominated deputy |
| Communications lead | Manages internal and external messaging, including regulators | Head of communications or HR |
| IT recovery lead | Restores systems, data, and infrastructure | IT manager or outsourced provider |
| Business unit contacts | Coordinate recovery within their own department | Department heads |
Write these roles into the policy by title, not just by name, so the structure survives staff turnover without a rewrite. Include a short line on how authority passes if the incident commander is unreachable, because that gap is exactly where response time gets lost.
Make ownership visible day to day
Roles only work if people know they hold them before an incident starts. Circulate the finalised policy to everyone named in it, confirm they understand what’s expected, and revisit the assignments whenever someone changes job or leaves the organisation. Reviewing role ownership annually, alongside your wider policy review, keeps the document tied to real people rather than outdated job titles nobody occupies anymore.
Step 3. Assess risks and conduct a business impact analysis
With purpose, scope, and ownership settled, your business continuity planning policy needs to commit the organisation to actually understanding what could go wrong and what it would cost you. This step doesn’t require you to list every risk in the document itself, but it must require, in writing, that risk assessment and a business impact analysis (BIA) happen on a set schedule, using a consistent method, with results reported to the policy owner.
Identify what could disrupt you
Assessing cyber risk matters, but risk assessment for continuity purposes looks beyond cyber threats alone. Consider the full range of disruptions your organisation could realistically face:
- Cyber incidents, including ransomware, data breaches, and denial of service attacks
- Physical events, such as fire, flooding, or loss of premises
- Supply chain failure, including a critical supplier or cloud provider going down
- People-related risks, like sudden loss of key staff or a widespread illness event
- Utility and infrastructure failure, covering power, internet, and telecoms outages
Rank each risk by likelihood and impact, then feed the highest-scoring ones into your BIA. The National Cyber Security Centre’s guidance on incident management is a useful reference point when scoping cyber-related risks specifically.
A risk register nobody’s read is just a spreadsheet; a business continuity plan policy that mandates action on it is a control.
Run the business impact analysis
Unlike the risk register, the BIA focuses on your critical business functions rather than the threats themselves. It asks a different question: if this function stopped today, how quickly would that hurt, and what does recovery actually require?
| BIA element | What it captures |
|---|---|
| Critical function | The process, e.g. payroll, order processing, customer support |
| Maximum tolerable downtime | How long the business can survive without it |
| Recovery time objective (RTO) | Target time to restore the function |
| Recovery point objective (RPO) | Acceptable data loss, measured in time |
| Dependencies | Systems, people, suppliers, and data the function relies on |
Your policy should state who conducts the BIA (usually department heads with the policy owner coordinating), how often it’s refreshed, and where the results get stored. Eighteen months is a reasonable maximum interval, but any material change, a new system, a relocated office, an acquisition, should trigger an earlier update rather than waiting for the scheduled one. This is the evidence base everything in Step 4 depends on.
Step 4. Set objectives and recovery priorities
Once the business impact analysis has told you which functions matter most and how quickly they need restoring, your business continuity planning policy must translate that data into a clear order of priority. This step is where good intentions meet hard trade-offs: you can’t recover everything at once, and pretending otherwise leaves teams arguing over resources mid-incident instead of following an agreed sequence.
Turn BIA findings into a priority order
Rank your critical functions from the BIA by combined impact and urgency, then write that ranking into the policy as the standard every continuity plan must follow. A typical priority tier looks like this:
- Tier 1 (restore within hours): payroll processing, customer-facing systems, core network access
- Tier 2 (restore within a day): order fulfilment, internal communications, supplier ordering systems
- Tier 3 (restore within a week): reporting tools, non-critical archives, internal training platforms
Recovery priorities decided during a crisis are guesses; recovery priorities decided in advance are decisions.
Set realistic recovery time and point objectives
Attach a realistic RTO and RPO target to each tier, based on what the BIA actually showed rather than what sounds impressive on paper. Setting a four-hour RTO for a system your IT provider can’t realistically restore inside two days only guarantees the policy fails its first real test.
| Tier | Example RTO | Example RPO |
|---|---|---|
| Tier 1 | 4 hours | 1 hour |
| Tier 2 | 24 hours | 12 hours |
| Tier 3 | 5 working days | 24 hours |
Numbers like these belong in the policy as guiding standards, with exact figures per system left to the operational plan rather than repeated here.
Align priorities with budget and capability
Finally, check every objective against what your organisation can actually afford and support. A recovery priority backed by no infrastructure, no contract, and no tested procedure isn’t an objective, it’s a hope dressed up as a plan. Where the gap between ambition and capability is too wide, either invest in closing it or revise the objective downward and record the accepted risk in the policy, signed off by the same leadership that approved the document in Step 2.
Step 5. Document response and recovery procedures
With priorities agreed, your business continuity planning policy needs to require that someone actually writes down what happens when an incident hits, rather than leaving it to memory under pressure. The policy itself doesn’t need to contain every phone number and server name; that detail belongs in the operational plan, and a ready-made continuity plan structure makes it easier to capture. What the policy must mandate is that such procedures exist, follow a consistent format, and get approved by the policy owner before they’re relied upon.
Define how an incident gets declared and escalated
Every procedure needs a clear starting trigger, because confusion at the declaration stage wastes the hours you can least afford to lose. State in the policy that any continuity plan must specify:
- Who has the authority to declare an incident, and who deputises if they’re unavailable
- The criteria that trigger a declaration, such as system downtime exceeding a set threshold
- The escalation path, including when to involve senior leadership, insurers, or regulators
- How the incident commander communicates status updates internally and externally, backed by a communications plan written before the incident
A recovery procedure nobody can find at 2am is worse than no procedure at all.
Document the recovery sequence, not just the destination
Once declared, the plan needs a sequence, not just a target outcome. Require that each critical function identified in your business impact analysis has a documented recovery route, covering the practical steps a team follows rather than the result they’re aiming for, which is exactly the discipline behind putting a disaster recovery plan together.
| Procedure element | What it must specify |
|---|---|
| Contact list | Names, roles, and backup contacts for every team involved |
| Alternate working arrangements | Site, remote access, or third-party facility if premises are unusable |
| Data and system restoration | Backup location, restoration steps, and who executes them |
| Supplier and vendor contacts | Emergency contact details for critical third parties |
| Communication templates | Pre-approved wording for staff, clients, and regulators |
Standardise this structure across every department so an auditor, or a new incident commander, can pick up any plan and follow it without translation. Templates like our CyberSOS incident response documentation follow exactly this logic: consistent structure, named owners, and steps written for someone acting under pressure, not someone reading at leisure. Store the finalised procedures somewhere accessible even if your primary systems are down, because a recovery plan trapped on the server you’re trying to recover helps nobody.
Step 6. Review, test and maintain the policy
A business continuity planning policy that never gets tested is just a document you hope works. This final step requires you to build review and testing directly into the policy itself, with fixed intervals and named responsibility, so maintenance doesn’t quietly slip once the initial drafting excitement fades. Without this commitment written down, policies drift out of date within a year, and nobody notices until an incident exposes the gap.
Schedule reviews before you need them
Set a fixed review cycle in the policy rather than leaving it open-ended. Annual review is the standard most organisations settle on, but certain triggers should force an earlier look regardless of where you are in the cycle:
- A significant organisational change, such as an acquisition, office move, or new critical system
- Any incident or near-miss that revealed a gap in the current procedures
- Changes to regulatory or certification requirements, including updates to ISO 27001 or ISO 22301
- Staff turnover among the named roles assigned in Step 2
A policy reviewed only when the calendar demands it will always lag behind the risks it’s meant to cover.
Test the plan, not just the paperwork
Testing the continuity plan properly proves whether the procedures written in Step 5 actually work under pressure, and it’s where most weaknesses surface before a real incident does. Vary the format so you’re not just repeating the same tabletop exercise every year:
| Test type | What it checks | Suggested frequency |
|---|---|---|
| Tabletop exercise | Whether roles and decisions make sense on paper | Every 6 months |
| Simulated incident | Whether teams can execute the procedure under time pressure | Annually |
| Full failover test | Whether backup systems and sites actually work | Annually or after major system changes |
Record the outcome of every test in writing, including what failed, because those findings are exactly what feeds back into the next policy revision.
Keep version control and evidence tight
Auditors and insurers want to see a clear trail: who approved each version, when it changed, and why, which is one of the records ISO 27001 expects you to keep. Maintain a simple version log inside the policy itself, noting the date, the change, and the approver’s name. This small habit does more to satisfy an ISO 27001 assessor than almost anything else in the document, because it demonstrates the policy is a living control rather than a file created once and forgotten. Treat this step as ongoing rather than final; a continuity policy earns its trust through repeated proof, not a single sign-off.
Turning your policy into practice
A written business continuity planning policy only earns its keep once it’s tested, referenced, and kept current, not filed away after the first draft. Work through the six steps in order: define purpose and scope, secure real leadership commitment, run the business impact analysis, set honest recovery priorities, document the procedures, then commit to reviewing and testing on a fixed schedule. Skip any one of them and the document becomes exactly the kind of untouched file that fails an audit or leaves your team guessing during an actual incident.
Most organisations get stuck somewhere between the risk assessment and the recovery procedures, either lacking the internal resource or the objectivity to spot their own gaps. That’s where a second pair of expert eyes pays for itself many times over. If you’d rather have specialists stress-test your policy, run the business impact analysis properly, and align it with ISO 27001, talk to TrustedIA about expert continuity and disaster recovery support before disruption forces the question.
