ISO 27001 & ISO 22301

The alternative site for your data center must be 50 miles away from the primary site. No, make that 100 miles… or is it 200 miles? Or perhaps kilometers? Well, none of this is correct – the truth is, there is no one-size-fits-all answer to this question.

Regulations and standards

Let me start with an example here – in 2002 and 2003, U.S. federal regulators had planned to require financial institutions to move their disaster recovery centers 200 or 300 miles away from primary sites. However, this initiative had failed not only because the banks have strongly opposed such regulation, but also because it has proved to be quite unfeasible.

The situation in the majority of other countries is similar. Of course, I’m not familiar with every regulation in the world, but from those I read, I didn’t find any with a precise definition. (If I’m wrong, feel free to add such regulations in the comments below.) Most of the regulations that deal with this matter do, however, say there must be a disaster recovery site at a “safe distance.”

Regarding standards, the situation is similar – neither ISO 22301 (new international business continuity standard), nor BS 25999-2 (its predecessor), or any of the standards from NIST SP 800 or ISO 27k series are precise about it.

Risk assessment

So, the decision is obviously left to the companies themselves – and such decisions cannot be made based on someone’s feeling, but on a study. In this case, a study is called “risk assessment,” and its purpose is to take into account all the relevant factors.

Here are the factors that tend to push the location further away:

• Earthquakes – if your location is in a seismic-sensitive area
• Floods – you should position an alternative site out of the same flood plain
• Tsunamis – you shouldn’t place both primary and secondary location on the coast of an ocean
• Other natural disasters – e.g. forest fires, tornados/hurricanes, volcanos – if your primary site is close to such areas, the disaster recovery site should be further away
• Large industrial facilities, nuclear power plants, or military installations – again, at least one of your locations should be at a safe distance
• Dependence on the same source of electrical power – you should look for locations on a different power grid
• Even if your risk assessment proves none of the above are applicable to you, take into account risks like pandemic diseases – in such cases, authorities will likely close the whole metropolitan area

However, there are some factors that force you to position a disaster recovery location as close as possible:

• Telecommunication links – the further the sites are away, the more difficult it becomes (i.e. more costly) to replicate the data between these sites
• If your employees are expected to travel to an alternative site in case of disaster – they have to be able to make it within the RTO (Recovery Time Objective); besides, the road between the sites shouldn’t be full of bridges and tunnels.

Main problems – small countries and small budgets

From the position of United States (or for that matter, Canada), the distance of few hundred miles is never a problem; imagine now you are a company in a European country with the geographical size of the Los Angeles metropolitan area, and the population of one city block in L.A. In such situations, the easiest solution would be to position a disaster recovery site in a neighboring country with compatible laws and regulations.

The main problem is usually the cost – building such a site and maintaining it costs far more than just an ordinary office building. This is why you could rent such a space for your alternative data center site from companies specialized in disaster recovery services. Or, there is a cloud computing option, but this is a completely different story…

To conclude, to mitigate most of the risks I would suggest you place a disaster recovery location somewhere between 30 miles (50 kilometers) and 100 miles (160 kilometers) away from your primary location. But again, please do your risk assessment first.

Click here to see a template of Business Continuity Strategy that will help you with making decisions about disaster recovery locations (commercially sold template) .

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).

Has it ever happened to you that your management has given you the responsibility to implement business continuity just because you are in the IT department? Why is business continuity usually identified with information technology?

This is probably because business continuity has its roots in disaster recovery, and disaster recovery basically is all about information technology. Twenty or thirty years ago business continuity (BC) did not exist as a concept, but disaster recovery (DR) did – the main concern was how to save the data if a disaster occurred. At that time it was very popular to purchase expensive equipment and place it at a remote location so that all the important data of an organization would be preserved if, for instance, an earthquake would occur. Not only preserved, but also that the data would be processed with more or less the same capacity as if it was at the main location.

But after a while it was realized – what use would there be of the data if there were no business operations to use such data? This was how the business continuity idea was born – it’s purpose is to enable the business to keep going on, even if in case of a major disruption.

Definitions

Let’s take a look at the definitions – business continuity is the “strategic and tactical capability of the organization to plan for and respond to incidents and business disruptions in order to continue business operations at an acceptable predefined level” (BS 25999-2:2007), while disaster recovery is “the process, policies and procedures related to preparing for recovery or continuation of technology infrastructure critical to an organization after a natural or human-induced disaster” (Wikipedia.org).

As you can see from the definitions, the emphasis in DR is on technology, while in BC it is on business operations. Therefore, disaster recovery is part of business continuity – you might consider it as one of the main enablers of business operations, or the technological part of business continuity.

However, you may have noticed something else too – the definition of BC is quoted from BS 25999-2, the leading standard on business continuity management, while the definition of DR is quoted from Wikipedia – actually, “business continuity” is an official term recognized in standards, while “disaster recovery” is not.

Implications for implementation

So why is it a bad idea for an IT department to implement business continuity for the whole organization? Because business continuity is primarily a business issue, not an IT issue. If the IT department was implementing business continuity for the whole organization, it would neither be able to define the criticality of business activities, nor the criticality of information. Further, it is a question whether it would achieve commitment from the business parts of the organization.

The best way to organize the implementation of BC is for the business side to lead such a project – this is how you would achieve greater awareness and acceptance of all parts of the organization. The IT department should play its role in such a project – a key role – to prepare disaster recovery plans.

You can also check out our webinar BS 25999-2 Foundations Part 1: Business Impact Analysis that explains how to define RTO and RPO for business critical activities (commercially sold training).

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).