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.

In my previous blog post I analyzed the changes between the old ISO 27001 (published in 2005) and the 2013 draft; naturally, controls from ISO 27001 Annex A cannot change without changing ISO 27002 because the essence of these two standards is to be aligned.

So, let’s take a look at what changes are proposed for ISO 27002 (source: BSI website) – it is important to note here that since this is only a DIS (draft) version of ISO 27002:2013, it is expected that the final version will differ quite a bit. Here I’ll focus mainly on how the controls are structured, and not so much on their description – so here are the main differences:

Number of sections – as expected, the number of sections has increased – from 11 sections containing controls in the old standard to 14 in the new. This way, the problem in the old standard, where some controls were artificially inserted in certain areas where they did not belong, is now resolved.

Number of controls – surprisingly, the number of controls has decreased – from 133 to only 113! This is due to eliminating some controls that were too specific or outdated.

Structure of sections – Cryptography has become a separate section (#10) – it is (logically) not part of Information systems acquisition, development and maintenance any more. A similar thing has happened with Supplier relationships – as deserved, they have become a separate section (#15). Communications and operations management is divided now into Operations security (section 12), and Communications security (now section 13). Here is how the sections look now:

• 5 Security Policies
• 6 Organization of information security
• 7 Human resource security
• 8 Asset management
• 9 Access control
• 10 Cryptography
• 11 Physical and environmental security
• 12 Operations security
• 13 Communications security
• 14 System acquisition, development and maintenance
• 15 Supplier relationships
• 16 Information security incident management
• 17 Information security aspects of business continuity
• 18 Compliance

Placement of security categories – categories have mixed a bit:

• Mobile devices and teleworking, previously in Access control, is now 6.2 – part of section 6 Organization of information security.
• Media handling was previously part of Communications and operations management, but now it is 8.3, part of 8 Asset management.
• Operating system access control, and Application and information access control, have now merged into System and application access control (9.4), and have remained in section 9 Access control.
• Control of operational software, previously a single control in Information System acquisition, development and maintenance, is now a separate category 12.5, part of the Operations security section.
• Information systems audit considerations have moved from Compliance to 12.7, part of the Operations security section.
• A Security category called Network access control is gone, and some of its controls have moved to section 13 Communications security.
• Information transfer (previously called Exchange of information) is now 13.2, part of section 13 Communications security.
• The controversial category Correct processing in applications (part of the old Information System acquisition, development and maintenance) is now gone.
• Electronic commerce services does not exist as a separate category anymore, and controls are merged into 14.1 Security requirements of information systems.
• Two categories from the section Information Security Incident Management are now merged into one.
• The Business continuity section has received a new category – 17.2 Redundancies. Basically, this is about disaster recovery.

New controls – here are a few controls that are new:

• 14.2.1 Secure development policy – rules for development of software and information systems
• 14.2.5 System development procedures – principles for system engineering
• 14.2.6 Secure development environment – establishing and protecting development environment
• 14.2.8 System security testing – tests of security functionality
• 16.1.4 Assessment and decision of information security events – this is part of incident management
• 17.2.1 Availability of information processing facilities – achieving redundancy

Controls that are gone – finally, here are some of the controls that do not exist anymore:

• 6.2.2 Addressing security when dealing with customers
• 10.4.2 Controls against mobile code
• 10.7.3 Information handling procedures
• 10.7.4 Security of system documentation
• 10.8.5 Business information systems
• 10.9.3 Publicly available information
• 11.4.2 User authentication for external connections
• 11.4.3 Equipment identification in networks
• 11.4.4 Remote diagnostic and configuration port protection
• 11.4.6 Network connection control
• 11.4.7 Network routing control
• 12.2.1 Input data validation
• 12.2.2 Control of internal processing
• 12.2.3 Message integrity
• 12.2.4 Output data validation
• 11.5.5 Session time out
• 11.5.6 Limitation of connection time
• 11.6.2 Sensitive system isolation
• 12.5.4 Information leakage
• 14.1.2 Business continuity and risk assessment
• 14.1.3 Developing and implementing business continuity plans
• 14.1.4 Business continuity planning framework
• 15.1.5 Prevention of misuse of information processing facilities
• 15.3.2 Protection of information systems audit tools

Since the structure of ISO 27002 is completely aligned with controls from ISO 27001, all these changes are also valid for new ISO 27001 Annex A.

At first sight, there are many changes… However, I don’t think most of these changes are really fundamental – many of them have actually corrected the incorrect structure of the old ISO 27002, and added the controls that were missing in the first place. Some things did change – like network security and development process – these areas are now more loosely described and thus more freedom is given to companies on how to implement them.

To conclude, I like these changes – it seems to me implementing this new standard is going to be easier.

It’s been six years since the last revision of ISO/IEC 27002 (in 2005) – much has changed in information security since then, and this standard definitely needs some “facelifting”. Since ISO 27002 is closely tied to ISO 27001, this revision has to be done simultaneously for both standards, and is expected to happen in the latter half of 2012 or during 2013.

ISO 27001 and ISO 27002

What these two standards have in common are the 133 controls – they are offered as a kind of catalogue in Annex A of ISO 27001, with the idea that appropriate controls are selected based on the risk assessment. ISO 27002 lists all of these 133 controls again, but offers detailed explanation of best practices for their implementation. For a detailed explanation of the differences between ISO 27001 and ISO 27002, read ISO 27001 vs ISO 27002.

This relationship between the two standards is why ISO 27002 has changed its name in 2007 – it was previously called ISO/IEC 17799, but its name was changed to ISO/IEC 27002, making it part of ISO 27k series.

This most important link between ISO 27001 and ISO 27002 – identical structure of ISO 27001 Annex A and ISO 27002 controls – will most likely still be included in new revisions of both standards. However, the way it is structured and the individual controls will most probably change.

Expected changes

At the moment of writing this article (October 2011) it is impossible to predict all the changes in ISO 27002 because the final draft hasn’t been written yet. However, most likely changes can be judged by hearing what ISO 27001 experts have to say – here’s a summary of suggestions from ISO 27k Forum, the leading expert forum about ISO 27001/ISO 27002:

• Accountability – definition of what it means in relation to human resources management
• Authentication, identity management, identity theft – they need better description because of their criticality for web-based services
• Cloud computing – this model is becoming more and more dominant in real life, but hasn’t been covered in the standard
• Database security – the technical aspects haven’t been systematically laid down in the existing revision
• Ethics and trust – an important concept not covered at all in the existing revision
• Fraud, phishing, hacking, social engineering – these particular types of threats are gaining more and more importance, but aren’t covered systematically in the existing revision
• Governance of information – this concept is very important for the organizational aspect of information security and is not covered in the current revision
• IT auditing – needs to focus more on computer auditing
• Privacy – needs to go broader than existing data protection and legal compliance, especially because of cloud computing
• Resilience – this concept is completely missing in the existing revision
• Security testing, application testing, vulnerability assessments, pen tests etc. – these are essentially missing in the current revision

As Gary Hinson from the ISO27k Forum argues, several of these issues are already covered, but they were not given sufficient emphasis in the current revision of the standard – key terms widely used today are either completely missing or are only vaguely alluded to.

Also, the new ISO 27002 will refer more on other standards that define certain areas in more detail – for instance, Section 14 Business Continuity Management will refer to ISO 22301 (new standard dedicated to business continuity management) and ISO/IEC 27031 (focused on ICT aspect of business continuity).

All these changes mean that not only some of the controls will change or will be added, but it also means that the structure of the standard will change – instead of existing 11 sections of Annex A / ISO 27002, some new sections will probably have to be created, and others merged. And these structural issues are probably the toughest ones since the body in charge of the revision (JTC 1/SC 27 committee) will need to ensure compatibility with the existing revision. This is why we have no idea at the moment what these structural changes will look like.

ISO 27002 certification?

Many people still ask me whether it is possible to get certified against ISO 27002. The situation with the new revision will stay the same – currently it is not possible, nor will it be possible to get an ISO 27002 certificate because unlike ISO 27001, this is not a management standard.

This means ISO 27002 will remain a code of practice (or best practices) for implementation of security controls. It will not define the management system – e.g. the documentation management, internal audit, management review, corrective and preventive actions, risk management, etc.  – all these remain in the domain of ISO 27001. Therefore, ISO 27001 will remain the only certifiable standard in the ISO 27k series.

Implications for the ISMS

If you already have your Information Security Management System implemented, you don’t have to worry too much – no matter which changes the new revision will bring, you will have enough time (normally one year after both standards have been published) to implement the changes.

Once the revisions are published, you will need to align the structure of your controls in the Statement of Applicability with the new Annex A in the revised ISO 27001. And although the structure won’t change too much, this alignment will be the biggest job that’s ahead of you.

And this is where the new ISO 27002 will bring the most value – in the transition period you will have plenty of refreshed best practices to choose from. And since ISO 27002 is quite detailed, and you still have the freedom to choose only the appropriate stuff for your organization, it will definitely help you make such transition easier.

You can also check out our webinar ISO 27001 Foundations Part 3: Annex A overview (commercially sold training).

Annex A of ISO 27001 is probably the most mentioned annex of any management standard. Why is there so much talk about it? Why is it sometimes controversial?

If you have read the Annex A, you have seen that 133 security controls are listed there. If that is the case, what is the main part of the standard used for?

The purpose

Annex A contains the following clauses (sometimes called ISO 27001 Annex A domains):

• A.5 Security policy
• A.6 Organization of information security
• A.7 Asset management
• A.8 Human resources security
• A.9 Physical and environmental security
• A.10 Communications and operations management
• A.11 Access control
• A.12 Information systems acquisition, development and maintenance
• A.13 Information security incident management
• A.14 Business continuity management
• A.15 Compliance

As already mentioned, Annex A contains 133 controls which, as can be seen from the names of the clauses, are not focused solely on IT – they also cover physical security, legal protection, human resources management, organizational issues, etc.

Therefore, you could consider Annex A as a form of a catalogue of security measures to be used during your treatment process – once you identify unacceptable risks in risk assessment, Annex A will help you choose the right control(s) to decrease those risks. And ensure you don’t forget any important control.

Annex A is where ISO 27001 and ISO 27002 come together – the controls in ISO 27002 are named the same as in Annex A of ISO 27001, but the difference is in the level of detail – ISO 27001 gives only a short definition of a control, while ISO 27002 gives detailed guidelines on how to implement the control.

Drawbacks

If by now you are thinking that Annex A is a perfect implementation tool for your information security project, don’t be too optimistic – it also has some things that don’t make sense. For instance, some controls define almost the same issues, sometimes causing confusion – like A.9.2.6 (Secure disposal or re-use of equipment) and A.10.7.2 (Disposal of media). On the other hand some issues, like relationships with third parties, are scattered around various clauses of Annex A – you can find it in clause A.6.2 (External parties), A.8 (Human resources security) and A.10.2 (Third party service delivery management), and control A.12.5.5 (Outsourced software development). This sometimes makes Annex A difficult to use as an implementation tool.

But those are not the only ambiguities – in some of the controls, Annex A mentions policies and procedures, however it does not require those to be documented. It might seem funny, but only where the word “documented” appears, does the standard require written policies/procedures. When you analyze the whole Annex A, it mentions the word “documented” in only 6 controls (A.5.1.1, A.7.1.3, A.8.1.1, A.10.1.1, A.11.1.1, A.15.1.1) – that means you can implement all the other controls without documenting them.

However, you shouldn’t abuse this flexibility of Annex A – the larger the organization, the more documents you should produce in order to ensure that everyone is aware of (and complies with) your security procedures. On the other hand, you should be careful not to overdo the documentation – if it is excessive, no one is going to observe it.

Relationship with the main part of the ISO 27001

The main part of the standard, or more precisely the mandatory clauses 4 to 8 contain the management part of the standard – they prescribe the PDCA cycle (Plan-Do-Check-Act phases), including risk assessment and treatment, documentation control, records control, provision of resources, internal audit, management review, corrective and preventive actions, etc.

As said earlier, the risk assessment & treatment process is the main connection between clauses 4 to 8 and the controls from Annex A – it will help you decide whether individual controls from Annex A are necessary for decreasing risks or not.

It means clauses 4 to 8 and Annex A cannot exist one without the other – risk assessment does not make sense if there are no controls to decrease the risks, and the only way to determine the applicability of controls is through risk assessment.

In my opinion, this focus on risks and the flexibility to apply security controls according to what you consider as appropriate are the best things in ISO 27001 – you just have to be careful to take full advantage of them.

You can also check out our webinar ISO 27001 Foundations Part 3: Annex A overview (commercially sold training).

If you are starting to implement ISO 27001, you are probably looking for an easy way to implement it. Let me disappoint you: there is no easy way to do it. However, I’ll try to make your job easier – here is the list of sixteen steps you have to go through if you want to achieve ISO 27001 certification:

1. Obtain management support

This one may seem rather obvious, and it is usually not taken seriously enough. But in my experience, this is the main reason why ISO 27001 projects fail – management is not providing enough people to work on the project or not enough money. (Read Four key benefits of ISO 27001 implementation for ideas how to present the case to management.)

2. Treat it as a project

As already said, ISO 27001 implementation is a complex issue involving various activities, lots of people, lasting several months (or more than a year). If you do not define clearly what is to be done, who is going to do it and in what time frame (i.e. apply project management), you might as well never finish the job.

3. Define the scope

If you are a larger organization, it probably makes sense to implement ISO 27001 only in one part of your organization, thus significantly lowering your project risk. (Problems with defining the scope in ISO 27001)

4. Write an ISMS Policy

ISMS Policy is the highest-level document in your ISMS – it shouldn’t be very detailed, but it should define some basic issues for information security in your organization. But what is its purpose if it is not detailed? The purpose is for management to define what it wants to achieve, and how to control it. (Information security policy – how detailed should it be?)

5. Define the Risk Assessment methodology

Risk assessment is the most complex task in the ISO 27001 project – the point is to define the rules for identifying the assets, vulnerabilities, threats, impacts and likelihood, and to define the acceptable level of risk. If those rules were not clearly defined, you might find yourself in a situation where you get unusable results. (Risk assessment tips for smaller companies)

6. Perform the risk assessment & risk treatment

Here you have to implement what you defined in the previous step – it might take several months for larger organizations, so you should coordinate such an effort with great care. The point is to get a comprehensive picture of the dangers for your organization’s information.

The purpose of the risk treatment process is to decrease the risks which are not acceptable – this is usually done by planning to use the controls from Annex A.

In this step a Risk Assessment Report has to be written, which documents all the steps taken during risk assessment and risk treatment process. Also an approval of residual risks must be obtained – either as a separate document, or as part of the Statement of Applicability.

7. Write the Statement of Applicability

Once you finished your risk treatment process, you will know exactly which controls from Annex you need (there are a total of 133 controls but you probably wouldn’t need them all). The purpose of this document (frequently referred to as SoA) is to list all controls and to define which are applicable and which are not, and the reasons for such a decision, the objectives to be achieved with the controls and a description of how they are implemented.

The Statement of Applicability is also the most suitable document to obtain management authorization for the implementation of ISMS.

8. Write the Risk Treatment Plan

Just when you thought you resolved all the risk-related documents, here comes another one – the purpose of the Risk Treatment Plan is to define exactly how the controls from SoA are to be implemented – who is going to do it, when, with what budget etc. This document is actually an implementation plan focused on your controls, without which you wouldn’t be able to coordinate further steps in the project.

9. Define how to measure the effectiveness of controls

Another task that is usually underestimated. The point here is – if you can’t measure what you’ve done, how can you be sure you have fulfilled the purpose? Therefore, be sure to define how you are going to measure the fulfilment of objectives you have set both for the whole ISMS, and for each applicable control in the Statement of Applicability.

10. Implement the controls & mandatory procedures

Easier said than done. This is where you have to implement the four mandatory procedures and the applicable controls from Annex A.

This is usually the most risky task in your project – it usually means the application of new technology, but above all – implementation of new behaviour in your organization. Often new policies and procedures are needed (meaning that change is needed), and people usually resist change – this is why the next task (training and awareness) is crucial for avoiding that risk.

11. Implement training and awareness programs

If you want your personnel to implement all the new policies and procedures, first you have to explain to them why they are necessary, and train your people to be able to perform as expected. The absence of these activities is the second most common reason for ISO 27001 project failure.

12. Operate the ISMS

This is the part where ISO 27001 becomes an everyday routine in your organization. The crucial word here is: “records”. Auditors love records – without records you will find it very hard to prove that some activity has really been done. But records should help you in the first place – using them you can monitor what is happening – you will actually know with certainty whether your employees (and suppliers) are performing their tasks as required.

13. Monitor the ISMS

What is happening in your ISMS? How many incidents do you have, of what type? Are all the procedures carried out properly?

This is where the objectives for your controls and measurement methodology come together – you have to check whether the results you obtain are achieving what you have set in your objectives. If not, you know something is wrong – you have to perform corrective and/or preventive actions.

14. Internal audit

Very often people are not aware they are doing something wrong (on the other hand they sometimes are, but they don’t want anyone to find out about it). But being unaware of existing or potential problems can hurt your organization – you have to perform internal audit in order to find out such things. The point here is not to initiate disciplinary actions, but to take corrective and/or preventive actions. (Dilemmas with ISO 27001 & BS 25999-2 internal auditors)

15. Management review

Management does not have to configure your firewall, but it must know what is going on in the ISMS, i.e. if everyone performed his or her duties, if the ISMS is achieving desired results etc. Based on that, the management must make some crucial decisions.

16. Corrective and preventive actions

The purpose of the management system is to ensure that everything that is wrong (so-called “non-conformities”) is corrected, or hopefully prevented. Therefore, ISO 27001 requires that corrective and preventive actions are done systematically, which means that the root cause of a non-conformity must be identified, and then resolved and verified.

Hopefully this article clarified what needs to be done – although ISO 27001 is not an easy task, it is not necessarily a complicated one. You just have to plan each step carefully, and don’t worry – you’ll get your certificate.

Here you can download the diagram of ISO 27001 implementation process showing all these steps together with the required documentation.