MODULE 3- RISK MANAGEMENT

 This module will give you a short overview of the risk management process covering
the clause 6.1 from ISO 27001: Actions to address risk and opportunities.

 The risk-based approach is very important for information security management,

because it helps you identify the risks related to information security. In order for you to
be able to protect your information, you need to know what kind of risks it is exposed
to.

ISO 27001 risk assessment & treatment – 6

basic steps.
 Risk assessment (often called risk analysis) is probably the most complex part of ISO
27001 implementation; but at the same time risk assessment (and treatment) is the most
important step at the beginning of your information security project – it sets the
foundations for information security in your company.

 The question is – why is it so important? The answer is quite simple although not
understood by many people: the main philosophy of ISO 27001 is to find out which
incidents could occur (i.e. assess the risks) and then find the most appropriate ways to
avoid such incidents (i.e. treat the risks). Not only this, you also have to assess the
importance of each risk so that you can focus on the most important ones.

 Although risk assessment and treatment (together: risk management) is a complex job,
it is very often unnecessarily mystified. These 6 basic steps will shed light on what you
have to do:

1. ISO 27001 risk assessment methodology

 This is the first step on your voyage through risk management. You need to define rules
on how you are going to perform the risk management because you want your whole
organization to do it the same way – the biggest problem with risk assessment happens
if different parts of the organization perform it in a different way. Therefore, you need
to define whether you want qualitative or quantitative risk assessment, which scales you
will use for qualitative assessment, what will be the acceptable level of risk, etc.

2. Risk assessment implementation

 Once you know the rules, you can start finding out which potential problems could
happen to you – you need to list all your assets, then threats and vulnerabilities related
to those assets, assess the impact and likelihood for each combination of
assets/threats/vulnerabilities and finally calculate the level of risk.
  In my experience, companies are usually aware of only 30% of their risks. Therefore,
you’ll probably find this kind of exercise quite revealing – when you are finished, you’ll
start to appreciate the effort you’ve made.

3. Risk treatment implementation

 Of course, not all risks are created equal – you have to focus on the most important
ones, so-called ‘unacceptable risks.

There are four options you can choose from to mitigate each unacceptable risk:

1. Apply security controls from Annex A to decrease the risks – see this article ISO 27001
Annex A controls.
2. Transfer the risk to another party – e.g. to an insurance company by buying an
insurance policy.
3. Avoid the risk by stopping an activity that is too risky, or by doing it in a completely
different fashion.
4. Accept the risk – if, for instance, the cost for mitigating that risk would be higher that
the damage itself.

This is where you need to get creative – how to decrease the risks with minimum investment.
It would be the easiest if your budget was unlimited, but that is never going to happen. And I
must tell you that unfortunately your management is right – it is possible to achieve the same
result with less money – you only need to figure out how.

4. ISMS Risk Assessment Report

 Unlike previous steps, this one is quite boring – you need to document everything
you’ve done so far. Not only for the auditors, but you may want to check yourself these
results in a year or two.

5. Statement of Applicability

 This document actually shows the security profile of your company – based on the
results of the risk treatment you need to list all the controls you have implemented, why
you have implemented them and how. This document is also very important because the
certification auditor will use it as the main guideline for the audit.

For details about this document, see article The importance of Statement of Applicability for
ISO 27001.

6. Risk Treatment Plan

 This is the step where you have to move from theory to practice. Let’s be frank – all up
to now this whole risk management job was purely theoretical, but now it’s time to
show some concrete results.
  This is the purpose of Risk Treatment Plan – to define exactly who is going to
implement each control, in which timeframe, with which budget, etc. I would prefer to
call this document ‘Implementation Plan’ or ‘Action Plan’, but let’s stick to the
terminology used in ISO 27001.

 Once you’ve written this document, it is crucial to get your management approval
because it will take considerable time and effort (and money) to implement all the
controls that you have planned here. And without their commitment you won’t get any
of these.

 And this is it – you’ve started your journey from not knowing how to setup your
information security all the way to having a very clear picture of what you need to
implement. The point is – ISO 27001 forces you to make this journey in a systematic
way.

P.S. ISO 27005 – how can it help you?

 ISO/IEC 27005 is a standard dedicated solely to information security risk management

– it is very helpful if you want to get a deeper insight into information security risk
assessment and treatment – that is, if you want to work as a consultant or perhaps as an
information security / risk manager on a permanent basis. However, if you’re just
looking to do risk assessment once a year, that standard is probably not necessary for
you.

Diagram of
ISO 27001:2013 Risk Assessment and Treatment
process
 This helpful diagram will show you the ISO 27001 Risk Assessment and Treatment
process, considering an asset – threat – vulnerability approach.

 Get an easy
overview of the
connections
between an asset
and related
threats and
vulnerabilities.

 See how you can

provide a visual
interpretation of
the Risk Assessment
and Treatment
 process to facilitate the understanding and participation of everyone in your
organization.

How to write ISO 27001 risk assessment

methodology
 Without a doubt, risk assessment is the most complex step in the ISO
27001 implementation; however, many companies make this step even more difficult by
defining the wrong ISO 27001 risk assessment methodology and process (or by not
defining the methodology at all).

What does ISO 27001 really require?

 ISO 27001 requires you to document the whole process of risk assessment (clause
6.1.2), and this is usually done in the document called Risk assessment methodology.
Unfortunately, this is where too many companies make the first big mistake: they start
implementing the risk assessment without the methodology – in other words, without
any clear rules on how to do it. See also this article: ISO 27001 risk assessment &
treatment – 6 basic steps.

 There are many myths regarding what the risk assessment should look like, but in
reality, ISO 27001:2013 requirements are not very difficult – here is what clause 6.1.2
requires:
 1) Define how to identify the risks that could cause the loss of confidentiality, integrity
and/or availability of your information

2) Define how to identify the risk owners

3) Define criteria for assessing consequences and assessing the likelihood of the risk

4) Define how the risk will be calculated

5) Define criteria for accepting risks

 So essentially, you need to define these 5 elements – anything less won’t be enough, but
more importantly – anything more is not needed, which means: don’t complicate things
too much.
 And yes – you need to ensure that the risk assessment results are consistent – that is,
you have to define such methodology that will produce comparable results in all the
departments of your company.

Which options are available?

Of course, there are many options available for the above 5 elements – here is what you can
choose from:

 Risk identification. In the 2005 revision of ISO 27001 the methodology for
identification was prescribed: you needed to identify assets, threats and vulnerabilities
(see also What has changed in risk assessment in ISO 27001:2013). The current 2013
revision of ISO 27001 does not require such identification, which means you can
identify risks based on your processes, based on your departments, using only threats
and not vulnerabilities, or any other methodology you like; however, my personal
preference is still the good old assets-threats-vulnerabilities method. (See also this list
of threats and vulnerabilities.)

 Risk owners. Basically, you should choose a person who is both interested in resolving
a risk, and positioned highly enough in the organization to do something about it. See
also this article Risk owners vs. asset owners in ISO 27001:2013.

 Assessing consequences and likelihood. You should assess separately the

consequences and likelihood for each of your risks; you are completely free to use
whichever scales you like – e.g., Low-Medium-High, or 1 to 5, or 1 to 10 – whatever
suits you best. Of course, if you want to make it simple, go for Low-Medium-High.

 Method of risk calculation. This is usually done through addition (e.g., 2 + 5 = 7) or

through multiplication (e.g., 2 x 5 = 10). If you use scales Low-Medium-High, then this
is the same as using scale 1-2-3, so you have numbers again for calculation.

 Criteria for accepting risks.If your method of risk calculation produces values from 2
to 10, then you can decide that an acceptable level of risk is, e.g., 7 – this would mean
that only the risks valued at 8, 9 and 10 need treatment. Alternatively, you can examine
 each individual risk and decide which should be treated or not based on your insight and
experience, using no pre-defined values. This article will also help you: Why is residual
risk so important?

Methodology first, everything else afterwards

 So the point is this: you shouldn’t start assessing the risks using some sheet you
downloaded somewhere from the Internet – this sheet might be using a methodology
that is completely inappropriate for your company. You shouldn’t start using the
methodology prescribed by the risk assessment tool you purchased; instead, you should
choose the risk assessment tool that fits your methodology. (Or you may decide you
don’t need a tool at all, and that you can do it using simple Excel sheets.)

 In any case, you should not start assessing the risks before you adapt the methodology
to your specific circumstances and to your needs.

ISO 27001 risk assessment: How to match

assets, threats and vulnerabilities
 The 2013 revision of ISO 27001 allows you to identify risks using any methodology
you like; however, the old methodology (defined by the old 2005 revision of ISO
27001), which requires identification of assets, threats and vulnerabilities, is still
dominating. (See also: What has changed in risk assessment in ISO 27001:2013.)

 So, how do you combine assets, threats and vulnerabilities in order to identify risks?

How to document the risk identification

 Risk identification is the first half of the risk assessment process, after which comes the
evaluation part (assessing the impacts and likelihood) – see the details here: How to
write ISO 27001 risk assessment methodology.

 To make your risk assessment easier, you can use a sheet with assets, threats and
vulnerabilities in columns; you should also include some other information like risk ID,
risk owners, impact and likelihood, etc.

 I found it the easiest to start listing items column by column, not row by row – this
means you should list all of your assets first, and only then start finding a couple of
threats for each asset, and finally find a couple of vulnerabilities for each threat.

 To learn which types of assets you should take into account, read this article: How to
handle Asset register (Asset inventory) according to ISO 27001, and click here to see a
catalog of threats and vulnerabilities appropriate for smaller and mid-sized companies.
Relationship between assets, threats and vulnerabilities

So, let’s see what this matching of the three components could look like – for example:

 Asset: paper document:

o threat: fire; vulnerability: document is not stored in a fire-proof cabinet (risk related to the loss
of availability of the information)
o threat: fire; vulnerability: there is no backup of the document (potential loss of availability)
o threat: unauthorized access; vulnerability: document is not locked in a cabinet (potential loss of
confidentiality)
 Asset: digital document:
o threat: disk failure; vulnerability: there is no backup of the document (potential loss of
availability)
o threat: virus; vulnerability: anti-virus program is not properly updated (potential loss of
confidentiality, integrity and availability)
o threat: unauthorized access; vulnerability: access control scheme is not properly defined
(potential loss of confidentiality, integrity and availability)
o threat: unauthorized access; vulnerability: the access was given to too many people (potential
loss of confidentiality, integrity and availability)
 Asset: system administrator:
o threat: unavailability of this person; vulnerability: there is no replacement for this position
(potential loss of availability)
o threat: frequent errors; vulnerability: lack of training (potential loss of integrity and
availability)
o etc.

This might seem complicated at first glance, but once you start doing this you’ll see it goes rather quickly.
Some people prefer using tools for this kind of work, and I agree this could be a good move for larger
companies, but for smaller ones using a tool would only take too much time: When to use tools for ISO
27001/ISO 22301 and when to avoid them.

How much is enough?

Very often people ask me – how many risks should they identify? If they start being really thorough, for each
asset they could find 10 threats, and for each threat at least 5 vulnerabilities – this is quite realistic, isn’t it?

Now if you are a small company with 50 assets, this would mean you would end up with 2,500 risks, which
would probably be overkill for this size of a company. This is why you should focus only on the most
important threats and vulnerabilities, while including all the assets; that would mean that per each asset you
should identify on average 5 threats, and for each threat on average 2 vulnerabilities. This way you would end
up with 500 risks for a smaller company with 50 assets, which is quite manageable.

Why is this methodology still good?

I personally like this assets-threats-vulnerabilities methodology quite a bit – not that I’m nostalgic for the
2005 revision of ISO 27001, but I think this methodology gives a good balance between doing the risk
assessment quickly, and at the same time doing it both systematically and detailed enough so that one can
pinpoint where the potential security problem is.

And this is what risk assessment is really about: find out about a potential problem before it actually happens.
In other words, ISO 27001 tells you: better safe than sorry.
In this free ISO 27001 Foundations Online Course you’ll see examples on how to identify assets, threats and
vulnerabilities compliant with ISO 27001.

How to assess consequences and likelihood in

ISO 27001 risk analysis
If you’re assessing the information security risks in your company, then identifying assets, threats, and
vulnerabilities is only the first half of the job. (See also ISO 27001 risk assessment: How to match assets,
threats and vulnerabilities.) The second half of the job, no less important and no less difficult, is to calculate
how big the risk is – this is achieved through assessing the consequences (also called the impact) if the risk
materializes, and assessing how likely the risk is to happen; with this information, you can easily calculate the
level of risk.

ISO 27001 doesn’t really tell you how to do your risk assessment, but it does tell you that you must assess
consequences and likelihood, and determine the level of risk – therefore, it’s up to you to figure out how to do
it. You’ll find a couple of approaches in this article: these are my favorites, but there are other ways to do it as
well – for more approaches see ISO 27005, the standard that explains information security risk assessment in
more detail.

Note: No matter which approach you select, you have to document it in your risk methodology – see this
article for explanation: How to write ISO 27001 risk assessment methodology.

Simple risk assessment

There are basically two ways to analyze the risks using the qualitative method – let’s call them simple risk
assessment, and detailed risk assessment. (I’ll cover the quantitative method in another article.)

In simple risk assessment you assess the consequences and the likelihood directly – once you identify the
risks, you simply have to use scales to assess separately the consequences and the likelihood of each risk. For
example, you can use the scale of 0 to 4, where 0 would be very low, 1 low, 2 medium, and so on, or the scale
1 to 10, or Low-Medium-High, or any other scale. The larger the scale, the more precise the results you will
have, but also the more time you will spend performing the assessment.

So, for example, in simple risk assessment you might have something like this:

 Asset: laptop
 Threat: theft
 Vulnerability: employees do not know how to protect their mobile devices
 Consequences: 3 (on a scale from 0 to 4)
 Likelihood: 4 (on a scale from 0 to 4)

Detailed risk assessment

In the detailed risk assessment, instead of assessing two elements (consequences and likelihood), you assess
three elements: asset value, threat, and vulnerability. So, here’s an example of this detailed risk assessment:

 Asset: laptop
 Threat: theft
 Vulnerability: employees do not know how to protect their mobile devices
 Asset value: 3 (on a scale from 0 to 4)
  Threat value: 2 (on a scale from 0 to 2)
 Vulnerability value: 2 (on a scale from 0 to 2)

When you think about this more closely, through these three elements in detailed risk assessment, you will
indirectly assess the consequences and likelihood: by assessing the asset value, you are simply assessing
which kind of damage (i.e., consequence) could happen to this asset if its confidentiality, integrity, or
availability is endangered; both threats and vulnerabilities directly influence the likelihood – the higher the
threat and the higher the vulnerability, the more likely the risk will happen, and vice versa.

And basically, this is it – if you’re a smaller company, simple risk assessment will be enough for you; if
you’re a mid-size or a larger company, detailed risk assessment will do the job. And you don’t need to add
any more elements, because that would only make your job more difficult. See also: How to organize initial
risk assessment according to ISO 27001 and ISO 22301.

Why is evaluating both assets and consequences wrong?

Very often I see companies implementing simple risk assessment (i.e., they directly assess consequences and
likelihood), but they also add the asset value to this assessment.

Why is this wrong? Because of the simple fact that they already assessed the consequences once, so they don’t
need to assess them again through the asset value.

So, again – don’t try to outsmart yourself and create something complex just because you feel like it.

How to calculate the level of risk

Calculating risk is actually very simple – this is usually done through addition (e.g., 2 + 5 = 7) or through
multiplication (e.g., 2 x 5 = 10). If you use a Low-Medium-High scale, then this is the same as using 1-2-3, so
you still have numbers for calculation.

So, using the above examples, here is how to calculate the risk using addition:

 Simple risk assessment: Consequences (3) + Likelihood (4) = Risk (7)

 Detailed risk assessment: Asset value (3) + Threat value (2) + Vulnerability value (2) = Risk (7)

In detailed risk assessment, you’ll notice that I used the scale 0 to 4 for assessing the asset value, and smaller
scales 0 to 2 for assessing threats and vulnerabilities. This is because the weight of consequence should be the
same as the weight of likelihood – since threats and vulnerabilities jointly “represent” the likelihood, their
maximum added value is 4, the same as for the asset (i.e., consequence) value.

After you’ve calculated the risks, you have to evaluate whether they are acceptable or not, and then move on
to the next step: the risk treatment. To see all the steps in risk management, read this article: ISO 27001 risk
assessment & treatment – 6 basic steps.

Don’t be a perfectionist

So, to conclude: risk management in general, but especially risk assessment and risk analysis, may seem like a
perfect opportunity to make things complicated – since the requirements of ISO 27001 are rather simplistic,
you can add numerous elements in trying to make your approach more “scientific.”

But, you have to ask yourself one question: is your goal to create a perfect risk assessment that will need to be
performed for several months or maybe years (because your employees simply won’t understand what is it all
about and will try to avoid you), or is your goal to finish this process in a reasonable timeframe, knowing that
it won’t be 100% accurate, but it will at least identify the main risks, and will start your people thinking about
the necessity of protecting company information?

Click here to register for a free webinar  The basics of risk assessment and treatment according to ISO
27001 that will explain the details of the risk assessment (webinar recording also available).

The importance of Statement of Applicability for

ISO 27001
The importance of Statement of Applicability in ISO 27001 (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 (ISO 27001 Clause 6.1.3 d) 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 114 controls (security measures) from ISO 27001 Annex A you will apply, and for those that
are applicable the way they will be implemented. As Annex A is considered to be comprehensive, but not
exhaustive for all situations, nothing prevents you from also considering another source for the controls.

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 Statement of Applicability justifies the inclusion and exclusion of controls from Annex A, and the
inclusion of controls from another source.
 Third, 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 a row for each control (114 from Annex A,
plus the added ones), which makes it possible to present it to management and to keep it up-to-date.
 Fourth, 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 (list, justification and description) of what needs to be
done in information security, why it has to be done, and how it is done.

To learn how to write Statement of Applicability and other mandatory documents, check this free ISO 27001
Foundations Online Course.

Risks and opportunities need to be addressed in order to:

1. Demonstrate management commitment – Incorrect! Risks and opportunities should be addressed in

order ensure an effective ISMS. Management should demonstrate commitment by conducting numerous
relevant activities.

2. Ensure achievement of the ISMS outcomes – Correct!

3. Prevent or reduce undesired effects – Correct!

4. Achieve continual improvement – Correct!

5. Ensure all employees are aware of the risks and opportunities – Incorrect! Risks and opportunities
should be addressed in order ensure an effective ISMS.

Arrange in the appropriate order the steps from the risk management process:

1. Define risk assessment methodology

2. Conduct risk assessment

3. Select risk treatment options

4. Create Statement of Applicability

5. Create risk treatment plan

Which of the following represent assets from an information security perspective?

1. People – Correct!

2. Unauthorized modification – Incorrect! This is a threat.

3. Software – Correct!

4. Low awareness of information security – Incorrect! This is a vulnerability.

5. Paper-based information – Correct!

For the cells that are empty in this Risk assessment table, match the correct answers below.
 Match
the empty cells with the following answers:

1. Cell 1 - Stolen

2. Cell 2 - The laptop was left in a car

3. Cell 3 - 3

4. Cell 4 - Access by unauthorized persons

5. Cell 5 - Leave the company

6. Cell 6 - 9

Which of the following actions are accepted as good risk treatment practices?

1. Risk transfer – Correct!

2. Avoiding risk – Correct!

3. Ignoring risk – Incorrect! There are four options for risk treatment: applying controls to decrease risk,
avoiding risk, accepting risk, and risk transfer.

4. Risk acceptance – Correct!

5. Doubling risk – Incorrect! There are four options for risk treatment: applying controls to decrease risk,
avoiding risk, accepting risk, and risk transfer.

The Statement of Applicability document should include:

1. Only the controls from Annex A – Incorrect! The Statement of Applicability should list all the controls
from Annex A and any additional controls that might be identified in the risk treatment process.

2. All the controls from Annex A and any additional controls that might be identified in the risk
treatment process – Correct!
3. Only additional controls that might be identified in the risk treatment process – Incorrect! The
Statement of Applicability should list all the controls from Annex A and any additional controls that might be
identified in the risk treatment process.

The risk management process consists of the following steps:

1. Define the information Security Policy – Incorrect! This is a requirement from the standard, but is not a
part of the risk management process.

2. Conduct the risk assessment – Correct!

3. Create the risk treatment plan - Correct!

4. Understand the organization and its context – Incorrect! This is a requirement from the standard, but is
not a part of the risk management process.

5. Create the Statement of Applicability – Correct!

6. Define the risk assessment methodology – Correct!

7. Select risk treatment options – Correct!

According ISO 27001, the risk assessment must include the following elements:

1. Risk evaluation – Correct!

2. Risk transfer – Incorrect! Risk transfer represents a risk treatment option; it is not part of the risk
assessment.

3. Risk treatment – Incorrect! Risk treatment is a requirement of the standard, but it is a step that comes
after risk assessment; it is not part of the risk assessment process.

4. Risk identification – Correct!

5. Risk analysis – Correct!

Risk analysis includes assessment of the impact the risk can have on the company and assessment of the
likelihood that the identified risk can really happen. The assessment scale for the impact and the likelihood
can vary between the values 1 and 10.

1. True – Incorrect! Companies can choose different types of assessment scales for the impact and the
likelihood, such as a “high, medium, and low” scale, or one with numerical values from 1 to 5, etc.

2. False – Correct!

After formulating a risk treatment plan, the Statement of Applicability must be documented.

1. True – Incorrect! First, the Statement of Applicability is documented, and after that, the risk treatment
plan is formulated.

2. False – Correct!

The Statement of Applicability must include the following information:

1. List of all the controls from Annex A and any additional controls that might be identified in the risk
treatment process – Correct!

2. Information regarding whether the listed controls are implemented in the organization – Correct!

3. The risk owner – Incorrect! This information should be included in the risk assessment table, not in the
Statement of Applicability.

4. Reason why the controls are implemented and how – Correct!

5. The value of the risk – Incorrect! This information should be included in the risk assessment table, not in
the Statement of Applicability.

6. Justification for exclusion of those controls that are not implemented – Correct!