3

I am writing our internal information security risk management procedure. This procedure should describe how exactly we do our risk identification, assessment, treatment and monitoring.

I wanted to follow ISO 27005, but I am stuck in Context Establishment section. Is this a one time process that I have to define in my procedure or is this a repetitive task that has to be done in the beginning of each risk assessment process (given that risk assessment conducted for certain limited scope such as a web service)?

If you have one could you share an example of your procedure or at least the part that matches Context Establishment section?

0

TL;DR:

[...] is this a repetitive task that has to be done in the beginning of each risk assessment process (given that risk assessment conducted for certain limited scope such as a web service)?

Exactly. But the part you put in brackets is really important. Take a look at this picture.

You can see here that context establishment takes place before every risk assessment. The scope is defined within the context establishment.


Long answer:

First of all, we have to answer the following question:

What does 'context' mean within the ISO/IEC 27005?

Consider the following note:

ISO/IEC 27001:2005 does not use the term “context”. However, all of Clause 7in ISO/IEC 27005 relates to the requirements “define the scope and boundaries of the ISMS” [4.2.1 a)], “define an ISMS policy” [4.2.1 b)] and “define the risk assessment approach” [4.2.1 c)], specified in ISO/IEC 27001:2005.

and the output of the context establishment process:

Output: The specification of basic criteria, the scope and boundaries**, and the organization for the information security risk management process.

These three "items" establish the context.

Basic criteria

Basic criteria are the criteria that detail your risk management process. These criteria follow your risk management approach and this approach follows the objectives and the scope of your risk management.

Basic criteria can be:

  1. Risk evaluation criteria
  2. Impact criteria
  3. Risk acceptance criteria

I don't want to go into these criteria too much, because they are all well described within the norm.

Scope and boundaries

The scope and boundaries always refer to the information security risk management. They need to be defined to "ensure that all relevant assets are taken into account in the risk assessment. In addition, the boundaries need to be identified to address those risks that might arise through these boundaries."

This part is crucial and probably the most complicated in the whole process. If your scope is too wide, the gathering of information can take so much time, that once you are done you have to start over again, because so much has changed in the meantime. The more time you need, the more money and ressources will be spent. If your scope is too narrow, you will exclude a lot of and important information and therefore a lot of possible risks. The worst part about this: there is no standard or "good" recipe for this. If you have never done this before, get help from the outside and go through this process step by step.

Important note that is often forgotten: "Additionally, the organization should provide justification for any exclusion from the scope."
Do not just leave parts of your organization out. This isn't only meaningful for an audit, but it's also helpful for you and your team. Why would you choose a scope the way you did and why does it make more sense than any other way?

Organization for information security risk management

This one is pretty easy (to understand): your risk management process has to be organized. Roles and responsibilities have to be alloted, and all formal activities that come with a risk management process have to be conducted. This is all very straightforward and highly formalized.

All quotes as well as the figure are taken from ISO/IEC 27005, Second Edition 2011-06-01

0

Yes, but.

Context establishment is meant to be repeated, but if you look at the actual content of the step, the practical implementation of that is basically a checking step. Context is unlikely to change considerably, but checking if it did is what you should be doing, because it could have.

Note that ISO 27005 is a guideline (and one of the lower quality ISOs) and not relevant for certification. The requirements that you have to fulfill are the ones in ISO 27001.

If you look at the certification relevant ISO 27001, it says:

The organization shall continually improve the suitability, adequacy and effectiveness of the information security management system.

So the question becomes whether or not reviewing the context is necessary to ensure this goal. And coming from these basic principles it seems obvious to me that a review of the context definitely should be part of the regular review cycle. In other words: Yes, you have to check regularily if the context as established initially is still appropriate. If not, and only if not, you need to repeat the "context establishment" step to determine the new context.

There is also strong support against establishing a new context every year. What you are doing right now is chapter 6.1.2 in ISO 27001 (establishing the risk assessment process), which has a hard requirement:

b) ensures that repeated information security risk assessments produce consistent, valid and comparable results;

I would challenge that if your context shifts all the time, your results are not ensured to be consistent and comparable.

In the risk management processes I establish (I'm an ISMS architect and risk management trainer) the context establishment is a "tick this off" step. Yes, in the yearly review, check if the context is still correct and valid. Context is not set in stone for all eternity and it can change. But only establish a new context if there has been significant change that has an impact on the risk assessment. For example, due to a merger, the risk appetite of the company could have changed. Or the scope of the ISMS could have been enlarged. Or a new law like the GDPR changes the legal responsibility for certain types of risks. These changes can change the risk management context.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.