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.

“Your ISO 27001 is nice in theory, but if our system administrator goes crazy, we’re dead.” – I hear this quite often when speaking to my clients about which security controls they should apply.

And it’s not only system administrators, it is also the line managers, engineers, top management, etc. – actually, anyone who has access to sensitive information or systems could be a potential threat. For instance, the biggest damage in banks is not done by robbers (with guns in their hands), but by inside jobs (with computers in their hands).

Of course, money theft is not the only purpose of these kinds of attacks – it can also be sabotage, theft of confidential corporate information, altering of data, theft of identities, etc.

Since this is such a complex issue, how can you deal with it?

Risk assessment

ISO 27001 is a standard which approaches security management mainly from the preventive point of view – the first step is to find out which incidents could happen regarding your employees (but also external partners with access to your systems), and then to choose appropriate security controls in order to avoid those incidents. In ISO 27001, this process is called risk assessment and risk treatment.

However, risk assessment shouldn’t be done superficially. If you didn’t think really hard about all the bad things that can happen, then you won’t mitigate those risks and someone could exploit those vulnerabilities.

Therefore, don’t rush through this step; do it systematically.

Preventive measures

Once you know how an insider can exploit your vulnerabilities, you can start planning your security controls in a comprehensive way. Again, ISO 27001 offers a catalogue of security controls in its Annex A – here are a few examples of the most common controls to mitigate the risk of insider threats:

• Access control (section A.11 in Annex A) – access to sensitive data can be approved on a need-to-know bases only. This way you decrease the number of people that can do harm, but also decrease the damage if someone’s identity is stolen.
• The access privileges must be regularly reviewed (control A.11.2.4) – very often quite a few employees have access to information they don’t really need.
• The accounts and access rights of former employees must be removed (A.8.3.3) – yes, sometimes there are open accounts a few years after an employee has left the company…
• Strong password policy (control A.11.2.3) or some other authentication method should be enforced to disable identity theft.
• Segregation of duties (control A.10.1.3) – you probably wouldn’t allow a single person to authorize large payments – the same goes for any other sensitive system.
• Backup (A.10.5.1) – of course, it should be regular; but also access to backup information cannot be allowed to employees who can harm your production systems the most.
• Document policies and procedures which clearly define the security roles and responsibilities (A.8.1.1; A.10.1.1) – you cannot expect your employees to observe the security rules if they don’t know what the rules are.
• Awareness & Training (A.8.2.2) – all of your employees need to know why it is necessary to protect sensitive data, as well as how to do it; for certain jobs (like monitoring logs) you may need to send your employees to special trainings.

Of course, there are other controls that are more technically oriented, like segregated network architecture (A.11.4.5), regular security patches (A.12.6.1), spyware scanning (A.12.5.4), anti-virus (A.10.4.1), firewall (A.10.6.1), physical entry controls (A.9.1.2), etc.

People issues

However, someone with high motivation and skills can bypass all of these security controls and achieve whatever agenda he or she has. Therefore, in my opinion, the most important thing is to develop some early warning indicators. And that requires a little bit more sophistication.

First of all, you need to know who you are employing – you probably wouldn’t allow some total stranger to access your sensitive data and/or systems only because he or she has a very nice diploma and a letter of recommendation. You need to dig deeper, or as ISO 27001 puts it – perform the background verification checks (A.8.1.2).

The second, and probably the most important control, is to constantly monitor what is going on – both on the “soft” side (most of the times you can observe if someone is starting to behave in a strange way) and on the “hard” side – by monitoring logs (A.10.10.2), i.e. monitoring whether there is anything suspicious in the use of information systems. Actually, the two can often be viewed together – whenever you conclude that someone’s behavior is peculiar, then this person’s logs need to be observed in more detail. And vice versa – if you spot some strange usage of information system, the soft side should be monitored more closely.

To conclude, insider threats will probably remain the biggest risk to the security of information – the complexity of information systems and amount of data will only increase this threat in time. And the best way to deal with them is to prevent them – once they happen, you can only hope they won’t go too far.

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.

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.

Your management has given you the task to implement business continuity, but you’re not really sure how to do it? Although it is not an easy task, you can use the BS 25999-2 methodology to make your life easier – here are the main steps necessary to implement this standard:

1. Obtain management support

Although this is not a mandatory step in BS 25999-2, this is certainly the crucial step in the beginning – if the management does not understand the benefits of business continuity and is not committed to this project, your project is most probably going to fail.

2. Treat it as a project

It will take quite a lot of time and resources to set up your business continuity management system (BCMS) – you have to define clearly what needs to be done, in which timeframe, and what are the roles in project implementation. In other words, you have to apply project management methods.

3. Define objectives and scope; write down a BCM Policy

You have to define what is it you want to achieve with the BCMS – compliance, decreasing the level of risk, requirements of your customers/partners etc. You also have to define what you are going to include in your BCMS – the whole organization, or just a part of it. For instance, you may decide that you are going to include only your data centre if you are providing hosting services to your customers. All of these have to be documented in the BCM Policy.

4. Defining roles and responsibilities for BCMS

Because the BCMS is going to become a permanent activity in your organization, you have to define clear responsibilities for it, especially for the “sponsor” of the BCMS (someone accountable for the BCMS but not engaged in day-to-day BCMS activities) and “BCM coordinator”, “BCM manager” or something similar to it – one or more persons with active duties regarding the BCMS. It is the best to document these roles and responsibilities in your BCM Policy.

5. Implement mandatory procedures

BS 25999-2 requires the following four mandatory procedures to be implemented: document and records control, internal audit, preventive and corrective actions – these procedures are actually the foundation of your management system, similarly to ISO 27001 or ISO 9001.

6. Perform business impact analysis and risk assessment

Through business impact analysis you have to indentify the critical activities, their maximum tolerable period of disruption, the dependencies of those critical activities (including dependencies to suppliers and outsourcing partners), and set recovery time objectives.

By doing the risk assessment you actually find out what could be the causes to the disruption of your critical activities – those could be natural, but also man-made activities (either malicious or accidental). You would also need to do risk treatment, which means you need to decide how to decrease the possibility of something going wrong. Unfortunately, the risk assessment and treatment are not very well defined in this standard, so you might take a look at ISO 27001 which describes them in more detail.

7. Determining the business continuity strategy

Before you proceed with writing business continuity plans, you actually have to determine which resources you will need for resuming your critical activities – which people, locations, data, hardware, software, suppliers, outsourcing partners etc.

The business continuity strategy has to determine not only what you need, but also how you are going to provide those resources.

8. Developing incident management plans and business continuity plans

The purpose of incident management plans is to describe how you are going to respond directly to the occurrence of an incident (e.g. fire, earthquake, bomb threat, power failure etc.) in order to prevent it to spread, and to try to decrease its direct effects.

On the other hand, the purpose of business continuity plans is to describe how you are going to recover your critical activities – how you are going to put all the resources you have prepared into action. This means you have to describe who is going to do what, in which time, using which data and technology, in order to put your organization back into operation.

All of these plans have to be described in detail, because they must be executed even in case the main personnel is not available – therefore, they have to be written in such a way that somebody else would be able to execute them.

9. Training and awareness

You need to define the level of competence needed for the execution of business continuity plans in case of disruption, and then train all the personnel (both employees and external partners) to reach this level of competence.

However, this is not enough – you also need to explain to your personnel why BCM is necessary. Let’s face it – your business continuity plans will be used maybe only once in a life time, so most people consider it as a waste of time. Therefore, you have to explain to them why such a thing must exist. (See also How to deal with BCM sceptics)

10. BCMS exercising

If you thought you have written your plans perfectly, you are probably wrong – it is almost impossible to write a plan with no errors right at the beginning. This is why exercising is a mandatory part of BCMS – you have to test your plans in a situation that more or less resembles a real disruption. Only then will you find out what you planned well, and what you didn’t.

11. Maintaining and reviewing the BCMS

Another way to keep your BCMS up-to-date is by defining the intervals at which you will review your business continuity plans, but also other arrangements (e.g. contracts with suppliers and outsourcing partners, training and awareness etc.). There are all sorts of changes in the environment that are threatening your documentation to become obsolete – it is enough for an employee to leave the company to have an unusable telephone number in a plan if that person had a role in the BCMS.

It is also mandatory to perform post-incident review if an incident really occurred – the purpose is to find out how the organization really reacted – did it follow the plans or not.

12. Internal audit

The purpose of internal audit is to find out if there is something wrong, in an objective manner – the internal auditor should be a person who can find out if something is done wrong within your BCMS in order to correct it. If done properly, internal audit could be one of the best ways to improve your BCMS. (Read Dilemmas with ISO 27001 & BS 25999-2 internal auditors)

13. Management review

As said before, it is very important to get your management involved in the project – management review is designed exactly for that. The standard requires the management to examine all the relevant facts about BCM and decide whether it has fulfilled its purpose. Once that is done, the management has to decide which improvements must be made.

14. Preventive and corrective actions

The best thing would be to prevent mistakes (or in terms of BS 25999, the “non-conformities”) from happening – this is what the preventive actions are used for – they are a systematic way of correcting things before a problem occurs. Similar to preventive actions, there are also corrective actions which resolve the problem that has already occurred.

Now the question is – why would you use BS 25999-2? Although it is (still) not an international standard, it is the most popular standard for business continuity worldwide – the abovementioned steps are designed by the best business continuity experts, so if you want to implement the best accepted practices for business continuity, you have to look no further.

Here you can download the diagram of BS 25999-2 implementation process showing all these steps together with the required documentation (registration required).

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.

I have seen quite a lot of smaller companies (up to 50 employees) trying to apply risk assessment tools as part of their ISO 27001 implementation project. The result is that it usually takes too much time and money with too little effect.

First of all, what is actually risk assessment, and what is its purpose? Risk assessment is a process during which an organization should identify information security risks determining their likelihood and impact. Plainly speaking, the organization should recognize all the potential problems with their information, how likely they are to occur and what the consequences might be. The purpose of risk assessment is to find out which controls are needed in order to decrease the risk – selection of controls is called the risk treatment process, and in ISO 27001 they are chosen from Annex A which specifies 133 controls.

Risk assessment is carried out by identifying and evaluating assets, vulnerabilities and threats. An asset is anything that has value to the organization – hardware, software, people, infrastructure, data (in various forms and media), suppliers and partners, etc. A vulnerability is a weakness in an asset, process, control,etc., which could be exploited by a threat; a threat is any cause that can inflict damage on a system or organisation. An example of a vulnerability is the lack of anti-virus software; a related threat is the computer virus.

Knowing all this, if your organization is small, you don’t really need a sophisticated tool to perform the risk assessment. All you need are an Excel spreadsheet, good catalogues of vulnerabilities and threats, and a good risk assessment methodology. The main job is really to evaluate likelihood and impact, and that cannot be done by any tool – it is something your asset owners, with their knowledge of their assets, have to think about.

So, where do you get the catalogues and methodology? If you are using the services of a consultant, he/she should provide those; if not, there are a few free catalogues available on the Internet, you just have to do a search on Google. The methodology is not available for free, but you could use ISO 27005 standard (it describes risk assessment & treatment into detail), or you could use some other websites selling the methodology. All this should take considerably less time and money than buying a risk assessment tool and learning how to use it.

A good methodology should contain a method for identifying assets, threats and vulnerabilities, tables for marking the likelihood and impacts, a method for calculating the risk, and define the acceptable level of risk. Catalogues should contain at least 30 vulnerabilities and 30 threats; some contain even a few hundred of each, but that is probably too much for a small company.

The process is really not complicated – here are the basic steps for assessment & treatment:

1. define and document the methodology (including the catalogues), distribute it to all asset owners in the organization
2. organize interviews with all the asset owners during which they should identify their assets, and related vulnerabilities and threats; in the second step ask them to evaluate the likelihood and impact if particular risks should occur
3. consolidate the data in a single spreadsheet, calculate the risks and indicate which risks are not acceptable
4. for each risk that is not acceptable, choose one or more controls from Annex A of ISO 27001 – calculate what the new level of risk would be after those controls are implemented

To conclude: risk assessment and treatment really are the foundation of information security / ISO 27001, but it does not mean they have to be complicated. You can do it in a simple way, and your common sense is what really counts.