ISO 27001 & ISO 22301

It’s actually funny, but it is rather difficult to find a list of all mandatory documents required by ISO 27001 anywhere on the Internet – this problem came to my attention when one of the readers of my blog told me he had to read several of my articles to assemble this list.

Anyway, a complete list of mandatory documents has two parts: the first part is related to documents which are required in the main part of the standard (clauses 4 to 8), and the second part is related to Annex A.

Mandatory documents required in the main part of ISO 27001

The first part is rather straightforward – most of required documents are listed in clause 4.3.1:

• ISMS scope
• ISMS policy and objectives
• Risk assessment methodology
• Risk assessment report
• Statement of Applicability
• Risk treatment plan
• Description on how to measure effectiveness of controls
• Procedure for document management
• Controls for record management
• Procedure for internal audit
• Procedure for corrective action
• Procedure for preventive action

Records required by the main part of the standard are as follows:

• Records related to effectiveness and/or performance of the ISMS
• Records of management decisions
• Records of significant security incidents
• Records of training, skills, experience and qualifications
• Results of internal audit
• Results of management review
• Results of corrective actions
• Results of preventive actions

Documents for Annex A

This is where it gets confusing – ISO 27001 doesn’t require all the controls from Annex A to be implemented, and it doesn’t clearly indicate how each control should be documented. To learn how to determine which controls to implement, read this article: ISO 27001 risk assessment & treatment – 6 basic steps.

The documents that are mandatory in Annex A (providing that the control is applicable) are the following:

• Information security policy
• Inventory of assets
• Rules for acceptable use of assets
• Definition of roles and responsibilities
• Operating procedures for information technology and communications management
• Access control policy
• List of relevant statutory, regulatory and contractual requirements
• Records provided by third parties
• Logs recording user activities, exceptions, events, etc.

And, here are the documents that are quite commonly used when implementing controls from Annex A, although they are not mandatory:

• Classification policy
• Change management policy
• Backup policy
• Disposal and destruction policy
• Information exchange policy
• Password policy
• Clear desk and clear screen policy
• Policy on use of network services
• Mobile computing and teleworking policy
• BYOD – Bring your own device policy
• Incident management procedure

Which documents do you think should be used in ISO 27001 implementation?

Click here to download a white paper Checklist of ISO 27001 Mandatory Documentation with more detailed information on the most common ways for structuring and implementing mandatory documents and records.

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.

Peter Drucker (one of the most influential thinkers on the subject of management theory) said “What gets measured gets managed”. The same goes for information security – if you don’t know how well you are doing, you’ll have a very difficult time steering your information security in the desired direction.

And it is exactly this ‘desired direction’ that is an essential part of measurement – setting the objectives. Only if you know exactly what you want to achieve, will you be able to know how far or how close you are to actually achieving it. Equally important – you’ll be able to answer your management’s question: “Did our investment in security pay off?”

Measurement in ISO 27001

Those of you who know the philosophy of ISO 27001 know that the so called PDCA management cycle (Plan-Do-Check-Act) is the foundation of this standard.

The concept of measurement is also best explained through this PDCA cycle:

• In the Plan phase you need to set the objectives (ISO 27001 4.2.1 b 1) and 4.2.1 g),
• In the Do phase you must figure out how to measure up to which point your objectives are achieved (ISO 27001 4.2.2 d),
• In the Check phase you need to start actual measurement (ISO 27001 4.2.3 c), and finally
• In the Act phase, once you realized you haven’t achieved your objectives (which is very often the case), you need to make certain improvements (ISO 27001 4.2.4 d)

And ISO 27001 requires at least two different levels of objectives to be set:

1. Objectives for the whole Information Security Management System (ISMS) – ISO 27001 4.2.1 b) 1), and
2. Objectives for each security control (safeguard) – ISO 27001 4.2.1 g)

Of course, depending on the size and complexity of your organization, you can choose to add another layer of objectives – e.g. at the level of individual organizational units (departments, etc.)

How to set (measurable) security objectives

My clients always ask me “OK, but how can I measure my backup, or my firewall?”. The secret lies in setting objectives which are easy to measure – you might have heard of the S.M.A.R.T. concept: objectives need to be Specific, Measurable, Achievable, Relevant, and Time-based.

So, what would it look like for the firewall? Something like ‘We want our firewall to stop 100% of unwanted network traffic’. Is it measurable? Yes – you will find out, sooner or later, whether some unwanted traffic has passed through the firewall.

Another example – backup. The objective could be ‘We want to achieve our loss of data is maximum 6 hours.’ Measurable? Yes – and you don’t have to wait for data loss to happen, you can test your backup and see how much of the data you can restore.

An example of the objective for the whole ISMS could be ‘We want to decrease the number of information security incidents by 50% in the next year’. Again, pretty specific and therefore measurable.

Objectives should help you manage your security…

Setting the objectives and measuring them is a rather new and unexplored aspect of information security. It is very often considered as an overhead because of the lack of knowledge in the first place, not so much because of practical reasons.

But nowadays there is more and more literature on this topic (ISO 27004 standard being one of the best sources) and an increasing number of information security practitioners with experience in this field, so measurement is slowly making its way into information security mainstream.

To finish this post with another quote – “If you don’t know where you’re going, you’ll probably end up somewhere else.” Don’t let that happen to you.

You can also check out our webinar ISO 27001 and ISO 27004: How to measure the effectiveness of information security? (commercially sold training).

Term ‘residual risk’ is mandatory in the risk management process according to ISO 27001, but is unfortunately very often used without appreciating the real meaning of the concept.

What is residual risk?

According to ISO 27001, residual risk is “the risk remaining after risk treatment”.

Here is how it works: first you have to identify the risks, and then you need to mitigate the risks you find unacceptable (i.e. treat them). Once you treat the risks, you won’t completely eliminate all the risks because it is simply not possible – therefore, some risks will remain at a certain level, and this is what residual risks are. The point is, the organization needs to know exactly whether the planned treatment is enough or not.

Residual risks are usually assessed in the same way as you perform the initial risk assessment – you use the same methodology, the same assessment scales, etc. What is different is that you need to take into account the influence of controls (and other mitigation methods), so the likelihood of an incident is usually decreased and sometimes even the impact is smaller.

For more information about the risk management process read ISO 27001 risk assessment & treatment – 6 basic steps.

How is it related to acceptable level of risk?

I mentioned that the purpose of residual risks is to find out whether the planned treatment is sufficient – the question is, how would you know what is sufficient? This is where the concept of acceptable level of risks comes into play – it is nothing else but deciding how much ‘risk appetite’ an organization has, or in other words whether the management thinks it is fine for a company to operate in a high-risk environment where it is much more likely that something will happen, or the management wants a higher level of security involving a lower level of risk.

Both approaches are allowed in ISO 27001 – each organization has to decide what is appropriate for its circumstances (and for its budget). The former approach is probably better for high-growth startup companies, while the letter is usually pursued by financial organizations.

Residual risk management

Once you find out what residual risks are, what do you do with them? Basically, you have these three options:

1. If the level of risks is below the acceptable level of risk, then you do nothing – the management needs to formally accept those risks.
2. If the level of risks is above the acceptable level of risk, then you need to find out some new (and better) ways to mitigate those risks – that also means you’ll need to reassess the residual risks.
3. If the level of risks is above the acceptable level of risk, and the costs of decreasing such risks would be higher than the impact itself, than you need to propose to the management to accept these high risks.

Such a systematic way ensures that management is involved in reaching the most important decisions, and that nothing is overlooked.

So the point is – top management needs to know which risks their company will face even after various mitigation methods have been applied. After all, top management is not only responsible for the bottom line of the company, but also for its viability.

You can also check out our Risk Assessment and Treatment Methodology which describes how to set an acceptable level of risk and how to manage residual risks (commercially sold document template).

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