The purpose of this document is to detail procedures to be followed to ensure continuity of the <service or capability> in the event of the loss of any of the elements on which it depends.
Version | Issued | Comments |
---|---|---|
0.1 | dd-MM-yyyy | … |
Role | RACI |
---|---|
… | … |
Review frequency | Next review due |
---|---|
? | ? |
This document is intended as a template for a Business Continuity Plan (BCP) but it is not a stand alone document which can be prepared in isolation. The template forms a checklist of the of information which should be included but before any attempt is made to populate the plan the following documents should be referred to and the recommendations contained therein followed.
The Infrastructure strategy gives details at a high level of the activities necessary to prepare for, document, test and maintain a BCP. The Business Continuity Management Toolkit available from Gov.uk provides a more detailed guide to BCP and is available by following this link BCP Toolkit
The following template assumes that these documents have been read and the recommendations contained therein have been adopted in full or in part depending on a business impact assessment and risk assessment.
<Clearly state the scope of the document including any reference to other relevant plans or documents e.g. Disaster Recovery Plan. Details of where such documents are stored and how they can be accessed should be provided. Where relevant you should also be clear on anthing that is out of scope, and explain why.>
<The owner of the plan should be detailed. Those responsible for reviewing amending and updating the plan should also be included. Regular review cycles should be detailed and scheduled together with events which will cause the plan to be reviewed outwith the regular cycle. This may include re-organisation of the business, lessons learned following an invocation or test, addition or removal of systems etc.>
<List all individuals with a role in the implementation of the plan and state their responsibilities. Contact details for all such individuals, both during and outwit working hours should be held. The following table gives examples.>
<List the people responsible for invocation of BCP. Depending on the incident, additional input may be required, e.g. if the incident is due to the failure of a third party then the third party would provide information on the nature and likely duration of the disruption as well as the recovery status.>
Name | Role | Responsibilities |
---|---|---|
… | … | … |
<List the people responsible for executing the business continuity plan, following a decision to invoke the plan.>
Name | Role | Responsibilities |
---|---|---|
… | … | … |
<_The invocation procedure should be clearly described including the individuals who have the authority to invoke and the circumstances which will trigger invocation. The circumstances which will trigger invocation will have been detailed in the Risk Analysis and Business Impact Analysis and may include the following:*
- loss of systems (IT and telecomms)
- loss of or damage to premises
- loss of utilities
- loss of key suppliers
- disruption to transport
- loss of key staff
- loss of suppliers
This section should also detail the process for mobilising the individuals and teams responsible for any recovery actions._>
<_List the scenarios that may may result in invocation of the BCP. For each scenario document:
- Description of the incident;
- An assessment of impact and likelihood of the incident;
- A summary of the recovery procedure (detailed procedures for each scenario are included in subsequent sections of this document);
- People required to assess the situation and invoke BCP;
- Maximum tolerable disruption period (MTDP);
- Recovery Time Objective (RTO);
- Recovery Point Objective (RPO)._>
Scenario | Impact | Impact Level | Likelihood | Recovery Approach | People | MTDP | RTO | RPO |
---|---|---|---|---|---|---|---|---|
… | … | {H/M/L} | {H/M/L} | … | … | … | … | … |
<_This section should detail the tasks that will be needed to manage the incident initially and the early steps to be taken before recovery can be started. In any incident the health and safety of staff takes precedence over any business concerns or recovery processes.*
*The plan should identify and detail the location from where the incident can be managed. An alternative should be specified at an alternative location in case the primary location is affected by the incident. Both locations should have facilities such as telecommunications so that the incident team can initiate response and recovery actions and co-ordinate activity. Copies of this plan and all related documents should be held at the primary and alternative site._>
<Details of the communication strategy should be included. This is likely to include procedures to inform staff, Stakeholders and any wider audience such as the media of progress. This will also record details of progress reporting from the individuals and teams involved in the recovery.>
<Contact details for all key stakeholders and individuals and teams charged with implementing the plan should be detailed. In addition, other third-party key resources such as suppliers, service providers, organisations providing workplace or disaster recovery or organisations with whom reciprocal arrangements have been made should be documented here>
<_This section should set out:*
- the critical business functions to be recovered
- the order in which these should be recovered
- the recovery time objective
- the recovery timeline
- the resources required and the times when these will be needed
This section of the plan should also detail all activities necessary to ensure the recovery and/or continuity of the business but may also refer to related documents such as a Disaster Recovery Plan. This section will comprehensively cover responses to all incidents which have been identified as candidates for invocation.
*The criteria for successful recovery of business functions, including any recovery testing and the person(s) responsible for signing off that recovery has been successful should also be specified_>
<_Where applicable, this plan should detail procedures for resuming normal operation following an invocation and recovery. For example this may include:*
- return to original premises following restoration of facilities
- reversion to a primary data centre following operation at a secondary site
- *reversion to normal working practices following disruption to transport_>
<_It is important that the plan is regularly tested.*
Some elements of the BCP lend themselves to realistic simulation of a catastrophic event, eg workplace recovery following the loss of premises. These elements should be tested at regular intervals by carrying out recovery instructions in a test situation. It is recommended that this is done at least annually and preferably every six months. Workplace testing should last only as long as is necessary to cover a range of critical business activities.
The scope of such testing should be agreed in advance, and a detailed report on recovery times, issues, failures and lessons learned should be produced and the results fed back into updates to the BCP.
*For other scenarios the testing may involve full simulation with different, realistic scenarios including role-playing and tabletop exercises that test the effectiveness of your BCP. This should be conducted at least annually but preferably every six months._>
<_The plan should be reviewed at regular intervals to ensure that*
- all key products and services and their critical activites and supporting resources have been identified
- *�arrangements still accurately reflect your organisation’s objectives and priorities �- arrangements are fit for purpose, and appropriate to the level of risk
- the plan reflects feedback and lessons learned from testing
- �the plan reflects feedback and lessons learned from any invocation
*All Stakeholders involved in the review process should be identified and responsibility for drafting, approving and committing changes should be assigned._>
<Provide any relevant appendices.>
<Provide any relevant references.>