ISO 27001 & BS 25999

They are both essential elements of business continuity, and they sound quite similar. But their purpose is quite different.

What is RTO?

So, what does RTO mean? BS 25999-2, a leading business continuity standard, defines RTO as “…target time set for resumption of product, service or activity delivery after an incident”.

This actually means that RTO is crucial when implementing business continuity in a company – calculating how quickly you need to recover will determine what kind of preparations are necessary. For example, if RTO is 2 hours, then you need to invest quite a lot of money in a disaster recovery center, telecommunications, automated systems, etc. – because you want to be able to achieve full recovery in only 2 hours. However, if your RTO is 2 weeks, then the required investment will be much lower because you will have enough time to acquire resources after an incident has occurred.

RTO is determined during the business impact analysis (BIA), and the preparations are defined in the business continuity strategy. See also this article Five Tips for Successful Business Impact Analysis to learn more about RTO and BIA.

What is RPO?

Recovery point objective is a totally different thing – according to Wikipedia, RPO is “… the maximum tolerable period in which data might be lost”. As this is quite difficult to grasp right away, I like to use this example instead – ask yourself how much data you can afford to lose? If you are filling in a database with various kinds of information, is it tolerable to lose 1 hour of work, 2 hours or maybe 2 days? If you are writing a lengthy document, can you afford to lose 4 hours of your work, the whole day or perhaps you could bear if you lost your whole week’s job?

This number of hours or days is the RPO. Recovery Point Objective is crucial for determining one element of business continuity strategy – the frequency of backup. If your RPO is 4 hours, then you need to perform backup at least every 4 hours; every 24 hours would put you in a big danger, but if you do it every 1 hour, it might cost you too much.

So, what’s the difference?

The difference is in the purpose – RTO has a broader purpose because it sets the boundaries for your whole business continuity management, while RPO is focused solely on the issue of backup frequency. They are not directly related – you could have RTO of 24 hours and RPO of 1 hour, or RTO of 2 hours and RPO of 12 hours.

But let me emphasize what is even more important: what do RTO and RPO have in common? They are both crucial for business impact analysis and for business continuity management. Without determining them properly, you would be just guessing – and guessing is the best way to ensure you never recover from a disaster.

You can also check out our Business Impact Analysis Questionnaire which describes how to gather all information necessary for RTO and RPO (commercially sold document template).

This is probably the second most common question I hear about ISO 27001 and BS 25999 (the first one is How much does it cost?). Well, the answer is not really encouraging – most of the people I speak to expect it to be a few months. But this is not realistic – the reality is closer to one year.

Of course, you can always produce 50 documents in a matter of days claiming you are compliant with ISO 27001, but this is not what I’m writing here about. I’m writing about the implementation that makes sense, i.e. that produces results – a lower number of incidents, higher efficiency, cost savings etc.

Time needed for ‘Plan’ and ‘Do’ phases

Your main implementation effort will be spent on the Plan and Do phases, i.e. the first two mandatory phases in which the risk assessment/business impact analysis is being done and in which all the controls (including business continuity plans) are being implemented.

The duration of implementation for these two phases depends primarily on the size of the organization:

• Smaller organizations (up to 50 employees) usually implement the standard in up to 8 months
• Mid-size organizations (up to 500 employees) usually implement the standard in 8 to 12 months
• Large organizations (500 employees and more) – implementation usually lasts 12 to 15 months

One note here – in my experience, the companies that drag such projects for too long (e.g. small companies for more than 12 months), usually never finish the project – in such organizations there is never enough recognition of the importance of ISO 27001 or BS 25999, so human or financial resources dedicated to such a project are never sufficient.

When speaking about implementation time, it is worth mentioning here that the work on ISO 27001 / BS 25999 doesn’t stop with Plan and Do phase – these management systems need to be maintained and improved (phases Check and Act), meaning that the work on information security and business continuity is not one-off, but continuous. However, the effort for maintaining and improving the system is not as great as in the first two phases.

Things that will speed up your implementation

The duration mentioned above depends of course on many factors, but generally the following factors will speed up the implementation:

• If you run the implementation as a project – if you know exactly what are the objectives, who is responsible for what, if the resources are available and what are the deliverables, you will not only speed up the process but also increase your chances of a successful outcome.
• If you already have ISO 9001 or some other management system – ISO 27001 and BS 25999-2 are not that different from other management systems, so you can use some of the existing procedures and processes and save probably 20% to 30% of your time.
• If you already have many security/business continuity policies and procedures already in place – chances are that your existing documentation will be acceptable for ISO 27001/BS 25999 and it will decrease your implementation time; not only that, you will already have an understanding in your organization about what information security / business continuity is all about.
• Having the appropriate documentation templates – here I don’t mean any documentation templates, but the templates in your language, appropriate for the size of your company, and made specifically for the purpose of ISO 27001/BS 25999. (Another note here – free templates downloaded from the Internet are not going to speed up your process because you’ll need considerable time for their customization.)
• Having the knowledge – you can obtain the knowledge either through literature, in-person courses, online courses (that’s our specialty!), or by hiring a consultant; without knowledge not only will your project last much longer, but you’ll probably never finish it.
• Last but certainly not least – the support of your management. If you don’t get their support in terms of money and human resources, your project will actually last quite short – it will be finished even before it begins.

So the point is – the implementation of standards like these does take quite a lot of time, so you need to make sure you do it with some purpose in mind. If implementation is done superficially or without clear objectives, you’ll not only lose time but miss an opportunity to help your company improve and grow.

And of course, you can decrease the implementation time – if you plan your project carefully.

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.

If you are an information security or business continuity professional, then you’re probably aware of the most difficult part of your job: to convince your management that investment in information security/business continuity makes sense.

Traditionally, “making sense” for management means that the revenues that will result from the investment will be larger than the total cost of investment. (Of course, there are some other aspects the management will also consider – read Management’s view of information security).

So what’s the problem? The problem is, even if you can calculate the total cost, there are no revenues to be made; OK, instead of revenues you might have cost savings, but the general opinion is that these are impossible to calculate.

However, I think there is a way to estimate the financial benefits (i.e. cost savings) of information security. Let’s take a deeper look of what it really means.

Is it really impossible?

First of all, you need to estimate the potential damage an incident could cause – it is also called the Single Lost Expectancy or SLE. But to calculate SLE you need to take into account several factors:

• The scope of the potential incident – which departments, locations, business units and processes would be affected.
• The cost of purchasing of equipment, goods and materials that were damaged by the incident.
• Employees – the cost of employees resolving the incident.
• Legal and/or contractual penalties – if you didn’t comply with legislation or contractual obligations.
• Lost revenues – both from your existing clients and from potential clients.

The next step is to estimate the likelihood – normally, you would have to consider threats and vulnerabilities, as well as existing security measures. The best way is to assess how often you think such an incident would occur – e.g. once every three months, once every three years or once every 30 years.

When you multiply Single Lost Expectancy and likelihood, you get the Annualized Lost Expectancy (ALE) – you could also consider this number to be the annual cost of that risk. For instance, the annualized risk of earthquake will cost you US$ 30000 if SLE is US$ 3 million and the likelihood is once in 100 years.

After that you would need to assess the frequency of the potential incident after you implement security measures – in the earthquake example, the frequency will stay the same; however, if you implement more effective anti-virus software, the likelihood of a successful malicious code attack will decrease.

Finally, you need to estimate how much your security measures will cost – to be accurate, you will again need to take into account various factors:

• Purchase value – cost of hardware, software, implementation services etc.
• Residual value of the security measure – its value after it is no more in use.
• External costs of maintenance – servicing, repairs etc.
• Internal costs of maintenance – mainly employees.

When you have all these inputs together, you will know whether your Return on Security Investment is positive or not – the point is that the decrease in your risk needs to be bigger than the total cost of security measures. It is best if you calculate both on an annualized level – this would mean that your Annualized Lost Expectancy has to be greater than the annual cost of security measures.

“Delusion or idiocy?”

When we have published our ROSI Calculator based on the abovementioned logic, one of the leading information security experts (whom I really do respect) has commented our tool on his Twitter account as follows: “delusion or idiocy? take your pick: http://bit.ly/lAeFZv – just enter ‘probability of incident occurrence’ :-( #ROSI #ROI”.

Why did he react this way? – Let’s be realistic, it is quite difficult to calculate all the costs related to the potential damage of an incident; however it is even more difficult to estimate precisely the likelihood of such an incident occurring. Especially if there are no statistics to support such an estimation.

But the question is – is it better to have nothing at all, or is it better to have at least some feeling about the financial consequences of the work you are doing? If you are a perfectionist, you will probably wait for another 10 or 20 years for a better methodology / statistics to evolve (by the way, the banking sector is now developing those under Basel II – Advanced Measurement Approach); or if you are a realist, you could use this logic to help you, keeping in mind that it is not perfect.

If you take the latter approach, you won’t be the only one in your company – just take a look what your marketing department is doing. They usually spend a lot of money on TV and radio commercials, but they cannot calculate exactly if that is profitable either, can they? What they sure are good at is presenting why this investment is needed, guessing along the way quite a lot of factors. Instead of making fun of them you should learn from them.

Something is better than nothing

So is it possible to calculate exactly what the Return on Security Investment will be? Unfortunately, the sceptics are right – it is impossible to calculate it precisely – mainly because it is difficult to estimate the likelihood of incident occurrence. But chances are you wouldn’t miss the probability that much – you wouldn’t assess the likelihood once in 100 years if it is more likely that an incident is going to happen every five years. That, together with taking into account all other relevant factors, will give you a much better picture of the risk your organization is exposed to.

And having that information in hand is much better than having nothing at all. More importantly, you will start speaking your management’s language (Profit & Loss language), which increases your chances of being heard.

To access the free Return on Security Investment (ROSI) Calculator, click here.

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.

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.

Have you ever heard something like “It can’t be done”, “It has no use”, or “It’s useless if a major disaster occurs”? If you implemented business continuity management, you probably did. Naturally, such an attitude would not help your project, so here are some suggestions how to handle such people.

“If a major disaster occurs, we won’t be able to do anything”

This is probably the most common one. Well, they may be right, unless you really prepared your business continuity strategy and business continuity plans taking into account all the possible scenarios – if you did that, then you can explain to them that you have prepared an alternative site which is distant enough to withstand any kind of disaster, that you’ve made a backup copy of data, that there is a replacement for any employee in the company, that you have alternative suppliers for any critical service etc.

“If a nuclear war breaks out, it won’t work”

Well, unless you are a military supplier, it wouldn’t matter, would it? Basically, in this kind of catastrophic scenarios, your business probably wouldn’t have a purpose anymore.

“It has no use”

Just pray you’ll never have to use business continuity. Even without mentioning the well-known examples like 9/11 or Hurricane Katrina, it is enough to ask – have you ever experienced a power outage? Or did your server break down? Or maybe a PC with important data on it? Have you ever heard of a building that burned down completely? It is enough to read newspaper headlines to understand that those things can happen to anyone.

“We will do this only to satisfy the auditor”

Wrong priority. If you do it properly, you’ll protect yourself, and as a consequence your auditor will be happy.

“We can’t foresee all the incidents”

This is true, at least in the beginning. But if you perform your risk assessment right, use literature and various resources, and review the assessment regularly, the chances are that in time you’ll be able to take into account all the possible risks. Once you know them, you can prepare your response.

“In case of emergency, people will start looking after their families, not after the business”

True also. Who wouldn’t call his/her family first to see if they are all right in case of an earthquake? But if you plan very carefully who can go home right after an incident occurs and who must stay and resolve the situation, and if you take care of the family of the employees that must stay (e.g. by assigning some other employees to this task), then you’ve probably solved this problem.

“People will react irrationally in crisis situations”

Definitely true. But if you train your employees (and suppliers/partners) regularly, and if you exercise your business continuity plans, they will get used to stressful situations, and will probably respond in the right way if such situations occurs.

If you already implemented similar projects, you know how awareness is important – if your co-workers do not recognize the purpose of such projects, you will experience great difficulties with implementation. Not to mention that your project might altogether fail – this is why you need to consider awareness raising in advance.

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 are thinking about implementing the business continuity management/BS 25999-2 standard? But then you hear it will cost you a lot? It probably will cost you, but not necessarily as much as you thought – this you can solve with good business continuity strategy.

Business continuity strategy, as defined in BS 25999-2 standard, is an “approach by an organization that will ensure its recovery and continuity in the face of a disaster or other major incident or business disruption”. Therefore, the point is to prepare yourself in the best possible manner to counteract a disaster if such would occur. This preparation can include organizational measures (drawing up plans, making contracts with suppliers/partners, exercising, reviewing, awareness raising, etc.), and measures including investment in equipment, infrastructure etc.

Time is a very important factor in recovery – if you do not recover your business in time, you will probably lose your customers and consequently lose your business as well. So the business continuity strategy must set the recovery time objective (RTO) for each of your critical activities, whereas RTO can be different for each of those.

One important consideration: the shorter the RTO, the bigger the investment you will need – for instance, if you want to recover your data centre in less than one hour, you will have to invest in an alternative location almost the same equipment as in the primary location; on the other hand, if you want to recover your data centre in two weeks, the investment will be much lower because it would be enough to store the backup tapes at the alternative location, allowing you two weeks to obtain the necessary equipment. All this means that your RTO must not be too long, but not too short either.

Once the RTO is set, you will still need to make some investment; however, with a good business continuity strategy you will be able to decrease that investment, while still being able to recover your critical activities within the recovery time objective. Here are some examples:

• you might not need your own data centre at an alternative location – in most countries you can rent such a location from a specialized company, which means you don’t need to invest in infrastructure, maybe not even in equipment or software,
• you might not need offices at an alternative location – employees who do not have to meet customers face-to-face can work from their homes,
• you might not need an alternative location at all if you have other business units at different locations which could take over the critical activities affected by the disaster,
• you might not need to purchase equipment in advance if you can find the supplier that could guarantee the delivery of equipment within your RTO,
• etc.

In all these examples you will need to increase your organizational capabilities, but if you want to save some money, it sure is something worth thinking about.

At first glance, information security and business continuity don’t have much in common – some would add that the only similarity is that they are both about IT.

Information security management is best defined in the International standard ISO/IEC 27001, while business continuity management is defined in the British standard BS 25999-2 – therefore, if we want to compare these two topics, the wisest thing to do is to take a look at what these two standards have to say.

First of all, IT is an important part of both ISO 27001 and BS 25999-2, but by no means are those two standards about IT only – the emphasis is on business processes & assets, and associated risks. It is true that IT is the main tool to process the data, but the fact remains that the biggest risks are connected to both malicious and unintentional activities of people. Therefore, the risks associated with information security or business continuity cannot be resolved by information technology only – it is much more important to define the organization, processes and responsibilities within the organization.

But what is essentially information security? ISO 27001 defines it as “preservation of confidentiality, integrity and availability of information”. On the other hand, BS 25999-2 defines business continuity as “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”.

The two don’t seem very much alike. However, there is one thing which makes them very similar – availability. The focus of both information security and business continuity is to keep information available to those who need it – in that respect, Annex A of ISO 27001 offers some controls dedicated solely to business continuity.

Further, both standards require carrying out the risk assessment, in order to identify potential problems related to information; both standards require document management, conducting internal audits, management reviews, and corrective and preventive actions. It means that if you already have documentation for ISO 27001, you can use those same procedures for BS 25999-2 (with only minor adjustments).

What are the differences? The main difference is in the level of detail. ISO 27001 covers a much wider area, and is therefore not very precise when it comes to business continuity; on the other hand, BS 25999-2 describes in detail how to perform business impact analysis, how to define business continuity strategy, or what the contents of business continuity plans shall be etc.

To conclude – the point here is that you can think of business continuity as part of information security. The practical use of it is that when it comes to implementation of business continuity in the context of ISO 27001, it is best to use BS 25999-2 as a guideline.