ISO 27001 & BS 25999

Have you ever found yourself in a situation where you have been given the task to write a security policy or a procedure? But you don’t want your document to end up like so many others – gathering dust in some forgotten drawer? Here are some thoughts that might help you…

The steps I’m about to present to you are designed based on my experience with various kinds of clients, large and small, government or private, for-profit or non-profit – I find these steps applicable to all of them. Actually, these steps are applicable to any kind of policies and procedures, not only those related to ISO 27001 or BS 25999-2.

1 Study the requirements

First you have to study very carefully various requirements – is there a legislation which requires something to be put in writing? Or maybe a contract with your client? Or some other high level policy that already exists in your organization (perhaps a corporate standard)? And of course the requirements from ISO 27001 or BS 25999-2 if you want to comply to those standards.

2 Take into account the results of your risk assessment

Your risk assessment will determine which issues you have to address in your document, but also to which degree – for instance, you may need to decide whether you will classify your information according to its confidentiality, and if so, whether you need two, three or four levels of confidentiality.

This step may not be relevant in this form if your policy or procedure is not related to information security or business continuity. However, risk management principles are applicable to other areas as well – quality management (ISO 9001), environmental management (ISO 14001), etc. For instance, in ISO 9001 you have to determine to which extent a process is crucial for your quality management and accordingly to decide whether you will document it or not.

3 Optimize and align your document(s)

An important thing to consider is the total number of documents – are you going to write ten 1-page documents or one 10-page document? It is much easier to manage one document, especially if the target group of readers is the same. (Just don’t create a single 100-page document.)

Moreover, you have to be careful to align your document with other documents – the issues you are defining may be already partially defined in another document. In such case, it may not be necessary to write a new document, maybe only expand the existing one.

If you are writing a new document about an issue that is already mentioned in another document, be sure to avoid redundancy – to describe the same issue in both documents. Later it would become a nightmare to maintain those documents; it’s much better that one document makes a reference to another, without repeating the same stuff.

4 Structure your document

You also need to take care that you observe your corporate rules for formatting the document – you already may have a template with pre-defined fonts, headers, footers etc.

If you already implemented ISO 27001 or BS 25999-2 (or any other management standard), you’ll need to observe a procedure for document control – such a procedure defines not only the format of the document, but also the rules for its approval, distribution etc.

5 Write your document

The rule of the thumb is – the smaller the organization and the smaller the risks, the less complex your document will be. There is nothing more useless than deciding to write a lengthy document no one is going to read – you have to understand that reading the document takes time, and the level of one’s attention is inversely proportional to the number of lines in your document.

One good technique to overcome the resistance of other employees to this document (no one likes change, especially if that means something like an obligation to change passwords on a regular basis) is to involve them in writing or commenting this document – this way they will understand why it is necessary.

6 Get your document approved

This step is rather self-evident, but its underlying importance is this – if you are not a high ranking manager in your company, you won’t have the power to enforce this document.

This is why someone with such a position has to understand it, approve it, and actively require its implementation. Sounds easy, but believe me – it is not. This step (and the next one) are the ones where implementation most often fails.

7 Training and awareness of your employees

This step is probably the most important, but sadly it is one that is very often forgotten. As mentioned before, employees are tired of constant changes, and they surely won’t welcome another one especially if it means more work for them.

Therefore, it is very important to explain to your employees why such a policy or procedure is necessary – why it is good not only for the company, but also for themselves.

Sometimes training will be necessary – it would be wrong to assume that everyone possesses the skills to implement new activities. For you, who wrote this document, it may seem easy and self-evident, but for them it may seem like brain surgery.

End of story?

If you thought you’ve reached the end of your document-implementation story, you’re wrong – the journey has just begun. It is not enough to have a perfect policy or procedure that everyone just loves, you also need to maintain it.

Someone has to take care this document is up-to-date and improved, or else no one is going to observe it anymore – and that someone is usually the same person who has written it. Not only that, someone has to measure if such a document has fulfilled its purpose – again, it may be you.

As you may have noticed reading this article, it is not enough to have a nice template for a successful policy or procedure – what is needed is a systematic approach to its implementation. And in doing so do not forget the most important fact: the document is not an end in itself – it is only a tool to enable your activities and processes to run smoothly. Don’t let the opposite happen – that such a document makes these activities and processes run with more difficulty.

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.

Quite often I see information security policies written in too much detail, trying to cover everything from strategic objectives to how many numerical digits a password should contain. The only problem with such policies is that they contain 50 or more pages, and – no one is really taking them seriously. They usually end up serving as artificial documents whose sole purpose is to satisfy the auditor.

But why are such policies extremely difficult to implement? Because they are too ambitious – they try to cover too many issues, and are intended for a wide circle of people.

This is why ISO 27001, the leading information security standard, defines different levels of information security policies:

• High-level policies, such as the Information Security Management System Policy – such high level policies usually define strategic intention, objectives etc.
• Detailed policies – this kind of policy usually describes a selected area of information security in more detail, with precise responsibilities, etc.

ISO 27001 requires that Information Security Management System (ISMS) Policy, as the highest-ranking document contains the following: the framework for setting objectives, taking into account various requirements and obligations, aligns with the organization’s strategic risk management context, and establishes risk evaluation criteria. Such a policy should be actually very short (maybe one or two pages) because it’s main purpose is for top management to be able to control their ISMS.

On the other hand, detailed policies should be intended for operational use, and focused on a narrower field of security activities. Examples of such policies are: Classification policy, Policy on acceptable use of information assets, Backup policy, Access control policy, Password policy, Clear desk and clear screen policy, Policy on use of network services, Policy for mobile computing, Policy on the use of cryptographic controls, etc. Note: ISO 27001 does not require all these policies to be implemented and/or documented, because the decision whether such controls are applicable, and to what extent, depends on the results of risk assessment.

Because such policies should prescribe more details, they are usually longer – up to ten pages. If they were much longer than that, it would be very difficult to implement and maintain them.

In other words, information security is too complex an issue to be defined in a single policy – for different aspects of ISMS and different “target groups” there should be different policies. Middle-sized organizations usually build up to fifteen policies for their ISMS.

One could argue that this number of policies is nothing but overhead for a company. I would certainly agree if such policies are written only with the certification audit in mind – such policies will bring nothing but more bureaucracy. However, if a policy is written with the intention of decreasing the risks, then it will most probably show its value – if not right away, then probably in two or three years, by decreasing the number of incidents.