ISO 27001 & ISO 22301

A few days ago I received the following question from one of our clients: “What is the difference between ISMS Risk Assessment and BCM Risk Assessment?” And, although the answer to this question might seem easy, in actuality it is not.

Here’s the rest of his question: “… Because on your blog I found that if I’ve done ISMS it should be fine for BCM. On the other hand, ISO 22301 recommends to use ISO 31000 standard.”

Why ISO 27001 risk management framework is a good solution

It is true that ISO 22301 refers to ISO 31000 regarding risk assessment, but ISO 31000 is written very generally since it covers all kinds of risks (not only business continuity, but information security, financial, market, credit, and other risks).

On the other hand, risk assessment framework is described much better in ISO 27001, and even more precisely in ISO 27005; the focus of information security risk assessment is on preserving confidentiality, integrity and availability. And availability is the key link between information security and business continuity – when performing ISMS risk assessment, all the business continuity risks will be taken into account.

And the good thing is, risk assessment as it is described in ISO 27001 and ISO 27005 is perfectly aligned with ISO 31000.

Possible differences in approach

But this is where it might get complicated – my client had another question because he wanted everything to be cleared out: “I think that another difference between those two Risk Assessment approaches is – with ISMS we deal with assets (both primary and supportive); however, with BCM we deal with critical activities and processes.”

And he was basically right – business continuity risk assessment does not have to be so detailed; it can be made high-level for activities and processes. But, although this approach is fine from the point of view of the standard itself, in my view the problem is in the implementation – how would you mitigate the risks if you don’t know exactly where the problems are?

This is where I think ISO 27001 risk assessment framework is better – it forces you to pinpoint where the weaknesses are, which assets should be protected better, etc. If you kept the risk assessment on the process level you probably wouldn’t get all this valuable information.

Risk mitigation compatibility

It is worth mentioning here – ISO 27001 risk treatment options are completely aligned with risk mitigation requirements in ISO 22301 and ISO 31000. Basically, business continuity mitigation comes down to 4 options described in ISO 27001: (1) applying appropriate controls, (2) accepting risks, (3) avoiding risks, and (4) transferring risks. There are no options listed in ISO 22301, while in ISO 31000 they are named a bit differently and organized a bit differently, but they are essentially the same:  changing the likelihood and the consequence, retaining the risk, avoiding the risk, and sharing the risk.

Further, ISO 22301 requires you to “plan actions to address these risks and opportunities,” while ISO 27001 asks for developing the Risk Treatment Plan – again, very similar requirement­ with a slightly different name.

And to finish with this: there is another good thing about ISO 27001 – in Annex A it gives you a catalogue of possible safeguards to choose from; this is something that neither ISO 22301 nor ISO 31000 has.

Hope I managed to persuade him. What do you think?

Click here to see a Risk Assessment and Treatment Methodology template.

When I heard the news that the DIS (draft) version of ISO 27001:2013 is publicly available at the BSI website (until 23 March 2013), I was very impatient to read it. Although one should not get too excited yet – this draft version might differ quite a bit from the final version of the standard (expected to be published in the second half of 2013) – the purpose of such a draft standard is to be revised based on many inputs during a public debate.

When compared to the old (still valid at the time of writing this article) ISO/IEC 27001 from 2005, the changes are actually not too drastic – here are the main differences I found:

The structure

As expected, the new ISO 27001 will be compliant with Annex SL of ISO/IEC Directives, in order to be aligned with all the other management standards – this is already evident in ISO 22301, the new business continuity management standard. So, here are the main clauses that you will see in all the management standards:

0 Introduction
1 Scope
2 Normative references
3 Terms and definitions
4 Context of the organization
5 Leadership
6 Planning
7 Support
8 Operation
9 Performance evaluation
10 Improvement

Naturally, Annex A is still here in the new ISO 27001 – this is where all the controls are listed. The quite useless Annex B from the old standard is gone, while there is no need for Annex C anymore.

Interested parties

The huge importance of interested parties, which can include shareholders, authorities (including legal and regulatory requirements), clients, partners, etc., is recognized in the new ISO 27001 – there is a separate clause that specifies that all the interested parties must be listed, together with all their requirements.

This is definitely an excellent way of defining key inputs into the ISMS.

Documented information

The concepts of “documents” and “records” are merged together; so, now it is “documented information.” Consequently, all the rules that are required for documentation control are now valid for both documents and records; the rules themselves haven’t changed much from the old ISO 27001.

The requirement in the old standard for documented procedures (Document control, Internal audit, Corrective action, Preventive action) is gone – however, the requirement for documenting the output from those processes remains in the new standard. Therefore, you don’t need to write those procedures, but you need to maintain all the records when managing documents, performing internal audits, and executing corrective actions.

Also, the clause from the old standard where all the required documents are listed (4.3.1) is gone – there is no central list of required documents.

Risk assessment and treatment

Assets, vulnerabilities and threats are not the basis of risk assessment anymore! It is only required to identify the risks associated with the confidentiality, integrity and availability – although this might seem too radical of a change, the authors of the new standard wanted to allow more freedom in the way the risks are identified; however, I assume that the assets-vulnerabilities-threats methodology will remain as a best practice for a long time.

The concept of determining the level of risk based on consequences and likelihood remains the same.

Further, Risk Assessment Methodology does not need to be documented, although the risk assessment process need to be defined in advance; the concept of asset owner is gone, too – a new term is used: “risk owners” – so the responsibility is pushed to a higher level.

Objectives, monitoring and measurement

A big change here: these are not mentioned within some other requirements, but now there are separate clauses with very concrete rules. The rules are that you need to set clear objectives, you need to define who will measure them and when, and you need to define who should analyze and evaluate those results. Further, comprehensive plans need to be developed that will describe how the objectives will be achieved.

This is definitely something that will bring ISMS closer to other management processes in a company. Hopefully, it will push information security onto the management agenda because – once you have very clear figures as to how your security performs – you cannot turn your head away from it.

Corrective & preventive actions

The biggest change is there are no preventive actions anymore, at least not at first sight – they are basically merged in risk assessment and treatment, where they naturally belong.

Further, a distinction is made between corrections that are made as a direct response to a nonconformity, as opposed to corrective actions that are made to eliminate the cause of a nonconformity. This way another ambiguity from the old standard is resolved.

Communication

This is also a new clause where all the requirements are summarized – what needs to be communicated, when, by whom, through which means, etc. This will help overcome the problem of information security being only an “IT thing” or “security thing” – the success of information security depends on both the IT side and the business side, and their overall understanding about the purpose of information protection.

What will this mean for the implementation?

I must admit I like all these changes – not only will the new ISO 27001 be easier to integrate with other management standards like ISO 9001, ISO 22301, ISO 20000 and others, but it also allows more freedom for companies (especially smaller ones) to scale the ISMS to their real needs and thereby avoid unnecessary overhead. But this may also turn out to be the greatest weakness of this new standard – because of its loose definitions, some companies may try to focus on satisfying the minimum instead of focusing on increasing security.

In other words, companies that mean well and really want to increase their level of security will find it easier to comply with this standard; however, the companies that not so positive and are looking for loopholes to implement it only for the sake of certification will see this standard as an opportunity.

P.S. I’ll examine the controls from Annex A more thoroughly in one of my next blog posts that will focus on new ISO 27002:2013.

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

Risk Treatment Plan is one of the key documents in ISO 27001, however it is very often confused with the documentation that is produced as the result of a risk treatment process. Here’s the difference:

Risk treatment process

Risk treatment is a step in the risk management process that follows the risk assessment step – in the risk assessment all the risks need to be identified, and risks that are not acceptable must be selected. The main task in the risk treatment step is to select one or more options for treating each unacceptable risk, i.e. decide how to mitigate all these risks. Four risk treatment options exist (for complete risk management process, please read  ISO 27001 risk assessment & treatment – 6 basic steps):

1. Apply security controls from Annex A to decrease the risks – see this article ISO 27001 Annex A controls.
2. Transfer the risk to another party – e.g. to an insurance company by buying an insurance policy.
3. Avoid the risk by stopping an activity that is too risky, or by doing it in a completely different fashion.
4. Accept the risk – if, for instance, the cost of mitigating that risk would be higher that the damage itself.

Risk treatment is usually done in a form of a simple sheet, where you link mitigation options and controls with each unacceptable risk; this can also be done with a risk management tool, if you use one.  According to ISO 27001, it is required to document the risk treatment results in the Risk assessment report, and those results are the main inputs for writing Statement of Applicability. This means that results of risk treatment are not directly documented in Risk Treatment Plan.

Risk Treatment Plan

So, where is the Risk Treatment Plan in this whole process? The answer is: it can be written only after Statement of Applicability is finished.

Why is this so? To start thinking about Risk Treatment Plan, it would be easier to think of it is an “Action plan” where you need to specify which security controls you need to implement, who is responsible for them, what are the deadlines, and which resources (i.e. financial and human) are required. But in order to write such a document, first you need to decide which controls need to be implemented, and this is done (in a very systematic way) through Statement of Applicability.

The question is – why didn’t ISO 27001 require the results from risk treatment process to be documented directly in the Risk Treatment Plan? Why was this step in between needed, in the form of Statement of Applicability? My opinion is that the authors of ISO 27001 wanted to encourage companies to get a comprehensive picture of information security – when deciding which controls are applicable in Statement of Applicability and which are not, the result of risk treatment is not the only input – other inputs are legal, regulatory and contractual requirements, other business needs, etc. In other words, SoA serves as a kind of a checklist that takes a global view of the organization, and Risk Treatment Plan wouldn’t be complete without such a check.

To conclude – Risk Treatment Plan is the point where theory stops, and real life begins according to ISO 27001. Good risk assessment and risk treatment process, as well as comprehensive Statement of Applicability, will produce very usable action plan for your information security implementation; skip some of these steps and Risk Treatment Plan will only confuse you.

Click here to see a sample Risk Treatment Plan.

I noticed that many people running ISO 27001 projects who have downloaded documentation templates think “I have the templates now – the rest is easy. I’ll write a few documents, show them to auditor, and it’ll be over in a few days”.

Unfortunately, it’s not that easy. Here’s why:

1. Writing the documentation requires time and effort

You shouldn’t write the documents just for the auditor to read them – you should write them because you want to define some rules for your organization.

But if you want your documentation to be useful, you have to adapt it to the realistic needs of your company. It probably doesn’t make sense to create a rule to change passwords every month, but it might make sense to change it every 3 or every 6 months – so you have to find out what is appropriate for your level or risks and for your organization.

Further, some documents are rather complex, and require certain knowledge to write them – for example, to perform the risk assessment first you need to write the Risk assessment methodology. If such a methodology is not suited for your organization, your employees doing the risk assessment may end up spending an enormous amount of time, to eventually realize that you could have done it in a much quicker and more efficient way. On the other hand, you may choose to take shortcuts, and by doing so omit some of the requirements of ISO 27001 with the result of failure at the certification.

So you need to invest time and effort in your education, and in the analysis of your company.

2. Documentation without implementation is nothing

Once you finish writing, you realize the documentation doesn’t make any sense if those rules are not really applied in your organization. In other words, having perfect documents alone isn’t going to raise your level of security.

But the problem is – if you want to implement new rules, you have to change habits in your organization. And changing habits isn’t easy, especially if it means restricting the freedom that employees enjoyed until now (and this is what security rules usually do). Taking again the example of password policy – if no such rule existed before and suddenly you ask your employees to change passwords every 3 months, they certainly won’t be happy. Moreover, they will look for ways to avoid such a rule.

So, besides making sure this rules makes sense from a security point of view, you have to explain to your employees why it is necessary, and in case of some more complex rules you will have to explain how to do it. These are called awareness and training programs, without which you will have high chances that your employees will simply reject such a change. And these programs also require time and effort.

3. Maintenance is often neglected

Most of the companies that have completed the documentation and implemented all the rules and processes, start forgetting about the documentation – new issues keep occurring that change how things are done, but that fact is not reflected in documentation. As a consequence, more and more people notice that documents are not useable anymore, and this in turn results in less and less people adhering to them.

This happens if no one is in charge of documentation maintenance – good practice says that for each document an ‘owner’ should be designated, a person who is responsible for keeping it up-to-date. But again – this requires time and effort.

Therefore, purchasing your documentation templates is not the end of your information security journey – it is just the beginning.

You can also check out our series of video tutorials for ISO 27001 implementation which explain how to fill in the documentation templates (commercially sold videos).