ISO 27001 & BS 25999

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.

The importance of Statement of Applicability (sometimes referred to as SoA) is usually underrated – like the Quality Manual in ISO 9001, it is the central document that defines how you will implement a large part of your information security.

Actually, the Statement of Applicability is the main link between the risk assessment & treatment and the implementation of your information security – its purpose is to define which of the suggested 133 controls (security measures) from ISO 27001 Annex A you will apply, and for those that are applicable the way they will be implemented.

Why it is needed

Now why is such a document necessary when you already produced the Risk Assessment Report (which is also mandatory), and which also defines the necessary controls? Here are the reasons:

• First of all, during risk treatment you identify the controls that are necessary because you identified risks that need to be decreased; however, in SoA you also identify the controls that are required because of other reasons – i.e. because of the law, contractual requirements, because of other processes, etc.
• Second, the Risk Assessment Report could be quite lengthy – some organizations might identify a few thousand risks (sometimes even more), so such a document is not really useful for everyday operational use; on the other hand, the Statement of Applicability is rather short – it has 133 rows (each representing one control), which makes it possible to present it to management and to keep it up-to-date.
• Third, and most important, SoA must document whether each applicable control is already implemented or not. Good practice (and most auditors will be looking for this) is also to describe how each applicable control is implemented – e.g. either by making a reference to a document (policy/procedure/working instruction etc.), or by shortly describing the procedure in use, or equipment that is used.

Actually, if you go for the ISO 27001 certification, the certification auditor will take your Statement of Applicability and walk around your company checking out whether you have implemented your controls in the way you described them in your SoA. It is the central document for doing their on-site audit.

A very small number of companies realize that by writing a good Statement of Applicability you could decrease the number of other documents – for instance, if you want to document a certain control, but if the description of the procedure for that control would be rather short, you can describe it in the SoA. Therefore, you would avoid writing another document.

Why it is useful

In my experience, most companies implementing the information security management system according to ISO 27001 spend much more time writing this document than they anticipated. The reason for this is they have to think about how they will implement their controls: Are they going to buy new equipment? Or change the procedure? Or hire a new employee? These are quite important (and sometimes expensive) decisions, so it is not surprising that it takes quite a lot of time to reach them. The good thing about SoA is that it forces organizations to do this job in a systematic way.

Therefore, you shouldn’t consider this document as just one of those “overhead documents” that have no use in real life – think of it as the main statement where you define what you want to do with your information security. Written properly, SoA is a perfect overview of what needs to be done in information security, why it has to be done, and how it is done.

Click here to download a free template of the Statement of Applicability.

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.

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.

One would think that these two terms are synonyms – after all, isn’t information security all about computers?

Not really. The basic point is this – you might have perfect IT security measures, but only one malicious act done by, for instance, administrator can bring the whole IT system down. This risk has nothing to do with computers, it has to do with people, processes, supervision, etc.

Further, important information might not even be in digital form, it can also be in paper form – for instance, an important contract signed with the largest client, personal notes made by the managing director, or printed administrator passwords stored in a safe.

Therefore, I always like to say to my clients – IT security is 50% of information security, because information security also comprises physical security, human resources management, legal protection, organization, processes etc. The purpose of information security is to build a system which takes into account all possible risks to the security of information (IT or non-IT related), and implement comprehensive controls which reduce all kinds of unacceptable risks.

This integrated approach to the security of information is best defined in ISO 27001, the leading international standard for information security management. In short, it requires risk assessment to be done on all organization’s assets – including hardware, software, documentation, people, suppliers, partners etc., and to choose applicable controls for decreasing those risks.

ISO 27001 offers 133 controls in its Annex A – I have performed a brief analysis of the controls, and the results are the following:

• IT related controls : 46%
• controls related to organization / documentation: 30%
• physical security controls: 9%
• legal protection: 6%
• controls related to relationship with suppliers and buyers: 5%
• human resources management controls: 4%

What does all this mean in terms of information security / ISO 27001 implementation? This kind of project should not be viewed as an IT project, because as such it is likely that not all parts of the organization would be willing to participate in it. It should be viewed as an enterprise-wide project, where relevant people from all business units should take part – top management, IT personnel, legal experts, human resource managers, physical security staff, the business side of the organization etc. Without such an approach you will end up working on IT security, and that will not protect you from the biggest risks.