SPRING DISCOUNT
Get 30% off on toolkits, course exams, and Conformio yearly plans.
Limited-time offer – ends April 25, 2024
Use promo code:
SPRING30

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?

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.

Advisera Dejan Kosutic
Author
Dejan Kosutic
Leading expert on cybersecurity & information security and the author of several books, articles, webinars, and courses. As a premier expert, Dejan founded Advisera to help small and medium businesses obtain the resources they need to become compliant with EU regulations and ISO standards. He believes that making complex frameworks easy to understand and simple to use creates a competitive advantage for Advisera's clients, and that AI technology is crucial for achieving this.

As an ISO 27001 and NIS 2 expert, Dejan helps companies find the best path to compliance by eliminating overhead and adapting the implementation to their size and industry specifics.
Connect with Dejan: