ISO 27001/ISO 22301 documents, presentation decks and implementation guidelines


Have a question on ISO 27001 or ISO 22301?

Ask an Expert

Free eBook

Free eBook 9 Steps to Cybersecurity
Becoming Resilient: The Definitive Guide to ISO 22301 Implementation
Sign up for our free Newsletter and as bonus you'll receive my tips on how to launch an information security and business continuity project.

Recent Posts




ISO 22301: An overview of BCM implementation process


September 10, 2014


Business continuity plan: How to structure it according to ISO 22301

ByDejan Kosutic on September 24, 2012

In my experience, companies usually find two things in their business continuity or information security management to be the most difficult: risk assessment, and business continuity planning. Here I’ll give you some tips on business continuity plans (BCP).

What is a business continuity plan?

According to ISO 22301, business continuity plan is defined as “documented procedures that guide organizations to respond, recover, resume, and restore to a pre-defined level of operation following disruption.” (clause 3.5)

This basically means that BCP focuses on developing plans/procedures, but it doesn’t include the analysis that forms the basis of such planning, nor the means of maintaining such plans – all these are required elements of business continuity management that are necessary for enabling successful contingency planning.

To read more about analysis, see Five Tips for Successful Business Impact Analysis, and to find out how to interpret the analysis, read Can business continuity strategy save your money?.

Business continuity plan example

Here’s what I found to be the optimal structure for the business continuity plan for smaller and midsize companies, and what each section should include:

Purpose, scope and users – why this plan is developed, its objectives, which parts of the organization it covers, and who should read it.

Reference documents – to which documents does this plan relate? Normally, these are Business Continuity Policy, Business Impact Analysis, Business Continuity Strategy, etc.

Assumptions – the prerequisites that need to exist in order for this plan to be effective.

Roles and responsibilities – who will be responsible for managing the disruptive incident, and who is authorized to perform certain activities in case of a disruptive incident – e.g. activation of the plans, urgent purchases, communication with media, etc.

Key contacts – contact details for persons who will participate in the execution of the business continuity plan – this is usually one of the annexes of the plan.

Plan activation and deactivation – in which cases can the plan be activated, and the method of activation; which conditions need to exist to deactivate the plan.

Communication – which communication means will be used between different teams and with other interested parties during the disruptive incident. Who is in charge of communicating with each interested party, and the special rules of communication with media and government agencies.

Incident response – how to react initially to an incident in order to reduce the damage – this is very often an annex to the main plan.

Physical sites and transportation – which are the primary and alternative sites, where the assembly points are, and how to get from primary to alternative sites.

Order of recovery for activities – list of all the activities, with precise Recovery Time Objective (RTO) for each.

Recovery plans for activities – description of step-by-step actions and responsibilities for recovering manpower, facilities, infrastructure, software, information, and processes, including interdependencies and interactions with other activities and external interested parties – these are very often annexes to the main plan. To read more about them, see How to write business continuity plans?

Disaster recovery plan – this is normally a type of recovery plan that focuses on recovering the information and communication technology infrastructure. To read more about the relationship between disaster recovery and business continuity, see Disaster recovery vs business continuity.

Required resources – a list of all the employees, third-party services, facilities, infrastructure, information, equipment, etc. that are necessary to perform the recovery, and who is responsible to provide each of them.

Restoring and resuming activities from temporary measures – how to restore business activities back to business-as-usual once the disruptive incident has been resolved.

What I like about ISO 22301 is that it requires all the elements that are necessary for this plan to be useful in case of a disaster (or any other disruption in a company’s activities). However, no standard can help you unless you understand this task seriously – a properly written and comprehensive plan can save your company in tough times, while a superficially written plan will only make things worse.

Click here to see a sample Business Continuity Plan.

Activation procedures for business continuity plan

ByDejan Kosutic on September 26, 2011

Having a business continuity plan is nice, but if you don’t know when and how to start using it, the money you’ve invested in it was spent in vain. Even worse, you’ll likely lose quite a lot of money because your business operations will be disrupted.

What is a business continuity plan?

Before going into the activation procedures, let me go through some of the basics of business continuity plans. BS 25999-2 standard defines a business continuity plan as a “documented collection of procedures and information that is developed, compiled and maintained in readiness for use in an incident to enable an organization to continue to deliver its critical activities at an acceptable predefined level”. (Click here to read more about BS 25999-2).

Therefore, a business continuity plan is not a single procedure or a single document. It usually consists of at least two parts: (1) incident response plan, and (2) recovery plan. An incident response plan is a procedure that clearly defines what to do immediately after an incident occurred – e.g. how to evacuate the building, who to call for help, how to contain the incident etc.

The purpose of the recovery plan is to resume business critical activities within the recovery time objective. It is activated right after the incident response plan, and can be used e.g. to recover the ICT infrastructure (also called “disaster recovery plans”), to recover production sites, to recover business processes in a service company, etc.

Since the business continuity plan consists of several parts, each of these parts is activated separately – here I’ll focus only on the two parts mentioned earlier.

Activation of incident response plan(s)

Well, the activation of this one is quite obvious. If anyone notices fire, an explosive device, flood in the basement or malicious code, he or she should notify someone immediately. Now, who is it they are going to call? In case of a smaller company, there is usually one responsible person who must be notified in case of any incident; however, in larger companies there could be more people responsible – e.g. one person for all IT related incidents, and one person for all non-IT related incidents.

It is up to them to activate the appropriate incident response plan – the company should have quite different incident response plans for e.g. fire as opposed to a threat letter.

Activation of recovery plan(s)

At first thought, it is not so obvious who should activate them. But good practice says that recovery plans should be activated by top level management dealing with crisis – usually it is the Crisis Manager. Such a decision should be made by a high level authority because it could prove quite costly to activate the recovery plan if there was no reason for it – e.g. someone at a lower level might panic and initiate transportation to the alternative site, which could prove quite unnecessary. But also someone who is not informed about the whole picture of the crisis could wait too long to make such a decision, which could prove even more expensive.

Therefore, the decision to activate certain (or all) recovery plans must be made by the Crisis Manager (or similar) – the criteria for activation are based on an estimate whether the disruption of business activities caused by the incident is going the last longer than the RTO (Recovery Time Objective). If so, then an appropriate recovery plan must be activated.

The question which recovery plan to activate is rather simple – if, for example, the whole company is affected by the incident, then all the recovery plans must be activated; however, if only one department is affected, then only the recovery plan for that department must be activated.

Emergency preparedness

Of course, for all this to work, it is not enough to write nice activation procedures – it is essential that those activation procedures are customized to the company’s situation, that they are remembered by all employees involved, and that they are practiced. If they are just a theoretical document which no one has seen for 2 or 3 years, then it is hard to expect employees to observe such procedures. It is true that preparing for an emergency is quite a wide topic that must include exercising and testing of all elements of the business continuity plan, but sadly, activation procedures are very often neglected in this respect.

Once again, for your business continuity plan to work, you need good activation procedures. But good activation procedures are useless if no one knows about them.

You can also check out our webinar BS 25999-2 Foundations Part 3: Business Continuity Planning which explains how to write incident response plans and recovery plans (commercially sold training).

Does ISO 27001 mean that information is 100% secure?

ByDejan Kosutic on May 02, 2011

You have probably heard that important web services like Reddit, HootSuite, Quora, Foursquare etc. have recently suffered a quite lengthy outage – what you also probably know is that this outage was caused by Amazon Web Services (AWS), their cloud computing service provider. What you probably didn’t know is that AWS is ISO 27001 certified.

But isn’t ISO 27001 a guarantee against such service outages? Didn’t a certification company check the AWS? What’s the point of ISO 27001 if such things can happen?

The answers are: No, Yes, and Lower risk.

Let me explain…

ISO 27001 certification does not guarantee that the Internet service provider is going to have uptime of 100%, or that none of the confidential information is going to leak outside the company, or that there would be no mistakes in data processing. ISO 27001 certification guarantees that the company complies with the standard and with its own security rules; it is guarantees that the company has taken all the relevant security risks into account and that it has undertaken a comprehensive approach to resolve major risks. ISO 27001 does not guarantee that none of the incidents is going to happen, because something like that is not possible in this world.

A certification body (in this case Ernst & Young CertifyPoint) probably did check whether Amazon Web Services complied to the standard and to their own security policies & procedures, including their procedures for incident response and business continuity plans; they should have also checked the AWS risk assessment and whether all the relevant risks were taken into account. However the certification body does not have a crystal ball to predict all the incidents that could occur, neither is that their job – their job is to check whether the company has done its homework – developed a security system.

So the final and the most important question is – what’s the point of ISO 27001 then?

The point is in lowering the risk of doing business. If your company is implementing ISO 27001, that means you will have to consider very carefully what could endanger the confidentiality, integrity and availability of your information; knowing those risks, you need to implement various security measures in order to decrease risks to an acceptable level. If you are doing business with a company that is ISO 27001 certified, you will know that this company has done all that.

Does it mean that ISO 27001 will eliminate all the potential problems? Obviously it won’t. But it will decrease the chances of something like that happening, and if it does happen, the reaction of the company will be much quicker and more efficient, and the damage to the business will be lower.

You can also check out our video tutorial How to Write the ISO 27001 Risk Assessment Methodology (commercially sold video).

BS 25999-2 implementation checklist

ByDejan Kosutic on November 16, 2010

Your management has given you the task to implement business continuity, but you’re not really sure how to do it? Although it is not an easy task, you can use the BS 25999-2 methodology to make your life easier – here are the main steps necessary to implement this standard:

1. Obtain management support

Although this is not a mandatory step in BS 25999-2, this is certainly the crucial step in the beginning – if the management does not understand the benefits of business continuity and is not committed to this project, your project is most probably going to fail.

2. Treat it as a project

It will take quite a lot of time and resources to set up your business continuity management system (BCMS) – you have to define clearly what needs to be done, in which timeframe, and what are the roles in project implementation. In other words, you have to apply project management methods.

3. Define objectives and scope; write down a BCM Policy

You have to define what is it you want to achieve with the BCMS – compliance, decreasing the level of risk, requirements of your customers/partners etc. You also have to define what you are going to include in your BCMS – the whole organization, or just a part of it. For instance, you may decide that you are going to include only your data centre if you are providing hosting services to your customers. All of these have to be documented in the BCM Policy.

4. Defining roles and responsibilities for BCMS

Because the BCMS is going to become a permanent activity in your organization, you have to define clear responsibilities for it, especially for the “sponsor” of the BCMS (someone accountable for the BCMS but not engaged in day-to-day BCMS activities) and “BCM coordinator”, “BCM manager” or something similar to it – one or more persons with active duties regarding the BCMS. It is the best to document these roles and responsibilities in your BCM Policy.

5. Implement mandatory procedures

BS 25999-2 requires the following four mandatory procedures to be implemented: document and records control, internal audit, preventive and corrective actions – these procedures are actually the foundation of your management system, similarly to ISO 27001 or ISO 9001.

6. Perform business impact analysis and risk assessment

Through business impact analysis you have to indentify the critical activities, their maximum tolerable period of disruption, the dependencies of those critical activities (including dependencies to suppliers and outsourcing partners), and set recovery time objectives.

By doing the risk assessment you actually find out what could be the causes to the disruption of your critical activities – those could be natural, but also man-made activities (either malicious or accidental). You would also need to do risk treatment, which means you need to decide how to decrease the possibility of something going wrong. Unfortunately, the risk assessment and treatment are not very well defined in this standard, so you might take a look at ISO 27001 which describes them in more detail.

7. Determining the business continuity strategy

Before you proceed with writing business continuity plans, you actually have to determine which resources you will need for resuming your critical activities – which people, locations, data, hardware, software, suppliers, outsourcing partners etc.

The business continuity strategy has to determine not only what you need, but also how you are going to provide those resources.

8. Developing incident management plans and business continuity plans

The purpose of incident management plans is to describe how you are going to respond directly to the occurrence of an incident (e.g. fire, earthquake, bomb threat, power failure etc.) in order to prevent it to spread, and to try to decrease its direct effects.

On the other hand, the purpose of business continuity plans is to describe how you are going to recover your critical activities – how you are going to put all the resources you have prepared into action. This means you have to describe who is going to do what, in which time, using which data and technology, in order to put your organization back into operation.

All of these plans have to be described in detail, because they must be executed even in case the main personnel is not available – therefore, they have to be written in such a way that somebody else would be able to execute them.

9. Training and awareness

You need to define the level of competence needed for the execution of business continuity plans in case of disruption, and then train all the personnel (both employees and external partners) to reach this level of competence.

However, this is not enough – you also need to explain to your personnel why BCM is necessary. Let’s face it – your business continuity plans will be used maybe only once in a life time, so most people consider it as a waste of time. Therefore, you have to explain to them why such a thing must exist. (See also How to deal with BCM sceptics)

10. BCMS exercising

If you thought you have written your plans perfectly, you are probably wrong – it is almost impossible to write a plan with no errors right at the beginning. This is why exercising is a mandatory part of BCMS – you have to test your plans in a situation that more or less resembles a real disruption. Only then will you find out what you planned well, and what you didn’t.

11. Maintaining and reviewing the BCMS

Another way to keep your BCMS up-to-date is by defining the intervals at which you will review your business continuity plans, but also other arrangements (e.g. contracts with suppliers and outsourcing partners, training and awareness etc.). There are all sorts of changes in the environment that are threatening your documentation to become obsolete – it is enough for an employee to leave the company to have an unusable telephone number in a plan if that person had a role in the BCMS.

It is also mandatory to perform post-incident review if an incident really occurred – the purpose is to find out how the organization really reacted – did it follow the plans or not.

12. Internal audit

The purpose of internal audit is to find out if there is something wrong, in an objective manner – the internal auditor should be a person who can find out if something is done wrong within your BCMS in order to correct it. If done properly, internal audit could be one of the best ways to improve your BCMS. (Read Dilemmas with ISO 27001 & BS 25999-2 internal auditors)

13. Management review

As said before, it is very important to get your management involved in the project – management review is designed exactly for that. The standard requires the management to examine all the relevant facts about BCM and decide whether it has fulfilled its purpose. Once that is done, the management has to decide which improvements must be made.

14. Preventive and corrective actions

The best thing would be to prevent mistakes (or in terms of BS 25999, the “non-conformities”) from happening – this is what the preventive actions are used for – they are a systematic way of correcting things before a problem occurs. Similar to preventive actions, there are also corrective actions which resolve the problem that has already occurred.

Now the question is – why would you use BS 25999-2? Although it is (still) not an international standard, it is the most popular standard for business continuity worldwide – the abovementioned steps are designed by the best business continuity experts, so if you want to implement the best accepted practices for business continuity, you have to look no further.

Here you can download the diagram of BS 25999-2 implementation process showing all these steps together with the required documentation (registration required).

How to write business continuity plans?

ByDejan Kosutic on April 08, 2010

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.

You can also check out our webinar BS 25999-2 Foundations Part 3: Business Continuity Planning (commercially sold training).