CALL US +44 1502 449001

The ISO 27001 & ISO 22301 Blog

Dejan Kosutic

Explanation of the basic terminology in ISO standards

Updated 2015-12-11: Number of mandatory clauses

When I deliver various trainings for ISO 27001 and ISO 22301, it always turns out that one of the hottest topics is about which policies and procedures need to be documented, and which do not.

Of course, there are some other heated discussions as well, but many of those happen because for someone new in the ISO world (not only in ISO 27001 and ISO 22301, but also in ISO 9001, ISO 14001, ISO 20000, etc.) it is not easy to understand some specific wording in those standards – here is the explanation of the terms that cause the most common doubts.

Which policies and procedures need to be documented?

blogpost-banner-consultants-en

When you see the words policy or procedure in an ISO standard, this does not mean that such a document needs to be written. A policy or a procedure needs to be written only if the word documented stands next to it.

For example, Access control policy from ISO 27001 control A.9.1.1 needs to be written down because the control says “… policy shall be established, documented, and ….” As opposed to that, Backup policy does not to be written down because in control A.12.3.1 of ISO 27001 there is no mention of the word documented.

Why do ISO standards mention the words policy or a procedure if they don’t need to be documented? Because a policy or a procedure could also be expressed verbally, without writing it down. For example, you can define a simple procedure (like answering the phone) quite precisely by verbally agreeing with all participants on how it needs to be done – you don’t need to write a document for it. Also, some policies can be a part of the information systems configuration (e.g., the password policy) without having a separate document for it.

The difference between shall and should

You need to implement certain requirement of the standard only if you see the word shall – when you see should this is not mandatory. This difference is the most obvious between the standards that specify requirements (i.e., ISO 27001) and the standards that are only guidelines (i.e., ISO 27002) – in ISO 27001 you will repeatedly see the word shall, whereas ISO 27002 primarily uses should.

This is because ISO 27001 is a standard against which your company can get certified, so it specifies what you must do to comply with it; ISO 27002 are only the guidelines for the implementation, so this is something you may or may not use.  See this article for detailed explanation: ISO 27001 vs. ISO 27002.

Which parts of the standard are mandatory?

Basically, only the main part of the standard (clauses 1 to 10) is mandatory however in most standards only clauses 4 to 10 are mandatory for the certification; the annexes must be implemented only if they have the word normative next to them.

For example, Annex A of ISO 27001:2013 is called “Annex A (normative) Reference control objectives and controls,” which means it must be implemented (of course, implementation of each control depends on the result of the risk assessment). As opposed to that, Annexes A and B in ISO 9001:2008 are informative, which means they are not mandatory – they exist only to give you some additional information.

What can you exclude from the scope?

Be aware when you see the word scope, because it is defined rather differently from one ISO standard to another.

For example, when defining your scope in ISO 27001, you shouldn’t read only clause 1 called “Scope,” but also clause 4.3 called “Determining the scope of the information security management system.” When the word scope is mentioned in ISO 27001, it does not mean you can exclude some controls because you don’t like them or because you think they are too expensive; the exclusion of controls is allowed only after you assess the risks – once you realize there are no risks that would require certain controls. See also How to define the ISMS scope.

On the other hand, exclusions from the scope in ISO 9001:2008 are much better explained (clause 1.2 “Application”) since these exclusions are more straightforward – you can decide to exclude certain requirements from clause 7 without having to perform some kind of analysis first.

In ISO 22301, scope is defined in clauses 1 “Scope” and 4.3.2 “Scope of the BCMS.” As opposed to ISO 27001, the exclusions from the scope are not based on risk assessment – to define ISO 22301 exclusions, you have to make sure that they won’t affect the organizational resilience; therefore, some smaller prior analysis will be required.

Make your implementation easier

What’s the point of all this? If you understand how the ISO standards are written, you will have a much easier job in implementing them. For example, you don’t need a document each time a policy or a procedure is mentioned; you don’t need to implement something unless is says shall; you don’t need to implement all the annexes, only the ones that are normative; and finally, if you set your scope correctly at the very beginning you will have a much easier job throughout your whole implementation.

So make sure you read the standards correctly.

Click here to see a list of  ISO 27001 mandatory documents, a white paper that provides a short explanation of the purpose of each mandatory document.

If you enjoyed this article, subscribe for updates

Improve your knowledge with our free resources on ISO 27001/ISO 22301 standards.

12 responses to “Explanation of the basic terminology in ISO standards”

  1. Shreyas H says:

    Dear Dejan,
    I need some help in deciding the appropriate Risk Assessment Methodology. So far until the revision to the standard we had to stick to the Threat-Vulnerability approach. I needed your help in guiding me to a few risk assessment methodologies that we could use to conduct risk assessment which is not as trublesome and time consuming.
    Any help would be much appreciated.
    Regards,

    Shreyas

    • If you want to simplify your risk assessment, you can identify your risks by e.g. matching threats with your processes or departments – this way you will have far less items in your assessment. However, this approach won’t be as precise as the asset-threat-vulnerability methodology.

      • jean-luc Allard says:

        Hi
        May I add that you can find a list of ‘methodologies’ (= set of tools) for risk management and risk treatment on the ENISA site: hhttp://rm-inv.enisa.europa.eu/methods/rm_ra_methods.html.
        While doing this, please remove
        – ISO 13335-2 from the list as it has been withdraws a few years ago.
        – ISO 17799 (renamed ISO 27002 in 2005) is a code of practice (ist of controls) and current version (2013) only recommend to select the controls using a risk management methodoogy in its introduction
        – ISO 27001 only gives a summary of the main steps of the risk management process (and is not a methodology).

  2. Sai says:

    Hi

    As part of 27001:2005 we are going with Assest based Risk assessment Methodology, as part of migration of management system to 2013 can we still go with same methodology?

  3. Jean-Luc Allard says:

    Hi

    Let me give some hints on the relation between ISO 27001, ISO 31000 and ISO 27005.
    ISO 27001 as Dejan tells is a set of requirements for a Management System (for Information Security). iI requires a complete and comprehensive risk management.
    ISO 27001 refers to ISO 31000 as this shows a ‘generic’ process for risk management (for all potential domains where risks exist: financial, health, information, etc.). ISO 31000 is too generic and lacks a series of parameters that are needed for information security. Hence the presence of ISO 27005.
    ISO 27005 is a description of the risk management process for information security. it is ‘subordinated’ to ISO 27001 (and can’t for this very reason be ‘above or referenced by ISO 27001).
    But ISO 27005 is NOT a methodology. It presents (and the future version will be much more detailed on this) and explains criteria to use, ways of doing, etc. You are totally free to use any methodology… but it is highly recommended the select one that ‘complies’ – that provides all/most of the elements presented in the ‘process’.
    Risk management methodologies evolve with the referentials (e.g. 27002). Some are ‘information’ focused, others are more ‘IT’ focused. An auditor won’t care as long as you 1° explain why you choose it and 2° show that you used it on a correct way.
    Don’t hesitate to ask questions through this channel.
    Regards

  4. Zack says:

    Hi,
    in your opinion who sets the activities in RTP that would lead to risk mitigation? Risk owners or?

  5. kiran says:

    What is Management of control after risk assessment which is based on the 27001 controls??

  6. Pavan says:

    Hi Dejan,
    Currently I am conducting a risk assessment based on the asset threat vulnerability methodology. I just wanted to know if identifying vulnerability is also equally important as threats.

    Thanks

    • Antonio Segovia says:

      Yes, threats and vulnerabilities are equally important, because they are closely related: A vulnerability is a weakness of an asset or control that can be exploited by one or more threats (this is an official definition in the ISO 27000). There are catalogue of threats and vulnerabilities that you can use for your methodology, if you are interested on this, you can see this resource “Threats & vulnerabilities”: http://www.infosecpedia.info/threats-vulnerabilities

Leave a Reply

Your email address will not be published. Required fields are marked *

OUR CLIENTS

OUR PARTNERS

  • Advisera is Exemplar Global Certified TPECS Provider for the IS, QM, EM, TL and AU Competency Units.
  • ITIL® is a registered trade mark of AXELOS Limited. Used under licence of AXELOS Limited. All rights reserved.
  • DNV GL Business Assurance is one of the leading providers of accredited management systems certification.