Get 2 Documentation Toolkits for the price of 1
Limited-time offer – ends March 28, 2024

How to write business continuity plans?


If you started implementing business continuity management, probably the biggest challenge you are facing is writing the business continuity plans.

Why is it so difficult? Well, you have to think of various scenarios under which a disaster (or other kind of disruption of business activities) can occur, and you have to think of a way how to handle such exceptionally rare but potentially catastrophic incidents.

The problems that people who write such plans usually have include what the plan should contain (what are the main elements), how long (how detailed) it should be, what steps to include etc.

One of the best solutions to all these dilemmas is using the BS 25999-2 standard, which together with BS 25999-1 defines a framework as to how the plans should be written.

According to those standards, the business continuity plans should consist of (1) incident response plan, and (2) recovery plans. An incident response plan is usually a single plan written for the whole organization, and describes what has to be done immediately after a disaster occurs – reducing the effects of the incident, communicating to emergency services, evacuating the building, gathering at assembly points, organizing transport to alternative locations etc.

Recovery plans are usually written separately for each critical activity, and the steps to be included in the recovery plans are usually the following: when and how to communicate with various stakeholders (employees and their families, shareholders, customers, partners, government bodies, public media etc.), how to assemble the team, how to recover the infrastructure, how to check whether the applications are functioning and whether the access rights are appropriate, how to check which data is missing or has been corrupted by the disaster, how to recover the data, and how to decide when the recovery is completed so that normal operations can begin.

Disaster recovery plans (the recovery plans of ICT infrastructure) are the ones to be written with great care because they should describe how to set each system running within the recovery time objective of a particular critical activity. This is usually done by writing a detailed recovery plan for each system to be recovered.

The rule of the thumb says that the level of details in all these plans should be such that other employees (or external staff) should be able to execute the plan if the people working with that critical activity are not available. Therefore, use common sense when writing the plans – they should be understandable to anyone, not just you.

In my experience, the biggest challenge when writing these plans is that employees have to face something completely different, something they never had to think about. To overcome such a problem it is best to organize a workshop where, with or without a moderator, they could share their views about what would happen if… , how to react when…, etc.

The truth is, the mere fact that your employees have started thinking about business continuity is 50% of the job done – with such an approach, the results of business continuity planning will be much better.

This free webinar will also help you: Writing a business continuity plan according to ISO 22301.

Advisera Dejan Kosutic
Author
Dejan Kosutic
Leading expert on cybersecurity & information security and the author of several books, articles, webinars, and courses. As a premier expert, Dejan founded Advisera to help small and medium businesses obtain the resources they need to become compliant with EU regulations and ISO standards. He believes that making complex frameworks easy to understand and simple to use creates a competitive advantage for Advisera's clients, and that AI technology is crucial for achieving this.

As an ISO 27001 and NIS 2 expert, Dejan helps companies find the best path to compliance by eliminating overhead and adapting the implementation to their size and industry specifics.
Connect with Dejan: