- Implement & Learn
Implementation Products - Resources
- For Consultants
- About Us
ISO 27001 Expert - Contact Us
Risk management is probably the most complex part of ISO 27001 implementation; but, at the same time, it is the most important step at the beginning of your information security project – it sets the foundations for information security in your company.
Risk management consists of two main elements: risk assessment (often called risk analysis) and risk treatment.
What actually are risk assessment and treatment, and what is their purpose? Risk assessment is a process during which an organization should identify information security risks and determine their likelihood and impact. Plainly speaking, the organization should recognize all the potential problems with their information, how likely they are to occur, and what the consequences might be.
The purpose of risk treatment is to find out which security controls (i.e., safeguards) are needed in order to avoid those potential incidents – selection of controls is called the risk treatment process, and in ISO 27001 they are chosen from Annex A, which specifies 93 controls.
Although risk management in ISO 27001 is a complex job, it is very often unnecessarily mystified. These six basic steps will shed light on what you have to do:
This is the first step on your voyage through risk management in ISO 27001. You need to define the rules for 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 different ways. Therefore, you need to define whether you want qualitative or quantitative risk assessment, which scales you will use for qualitative assessment, what the acceptable level of risk will be, etc.
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.
Of course, not all risks are created equal – you have to focus on the most important ones, the so-called “unacceptable risks.”
When implementing the risk treatment in ISO 27001, there are four options you can choose from to handle (i.e., mitigate) each unacceptable risk, as explained further in this article.
Unlike previous steps, this one is quite boring – you need to document everything you’ve done so far. This is not only for the auditors, as you may want to check these results for yourself in a year or two.
This document actually shows the security profile of your company – based on the results of the risk treatment in ISO 27001, 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 this article: Statement of Applicability in ISO 27001 – What is it and why does it matter?
This is the step where you have to move from theory to practice. Let’s be frank – 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 the Risk Treatment Plan – to define exactly who is going to implement each control, in which timeframe, with what budget, etc. I would prefer to call this document an “Implementation Plan” or “Action Plan,” but let’s stick to the terminology used in ISO 27001.
And this is it – you’ve started your journey from not knowing how to set up 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.
ISO/IEC 27005 is a standard dedicated solely to information security risk management. It is very helpful if you want to get 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.
Many companies make risk assessment and treatment too difficult by defining the wrong ISO 27001 risk assessment methodology and process (or by not defining the methodology at all).
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.
There are many myths regarding what the risk assessment should look like, but in reality, ISO 27001:2022 requirements are not very difficult – here is what clause 6.1.2 requires:
So essentially, you need to define these five 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.
Of course, there are many options available for the above five elements – here is what you can choose from:
Risk identification. The current 2022 revision of ISO 27001 does not prescribe a methodology for risk 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 defined in the 2005 revision of the standard. (See also the article Catalogue of threats & 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.
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 the Low-Medium-High scale, then this is the same as using the 1-2-3 scale, so you still have numbers 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?
In the section “Risk assessment,” you’ll find details on how to perform the risk assessment.
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.
I have seen quite a lot of smaller companies trying to use risk management software as part of their ISO 27001 implementation project that is probably much more appropriate for large corporations. The result is that it usually takes too much time and money with too little effect.
Here are some tips on how to make risk management more manageable for smaller companies:
To conclude: risk assessment and treatment really are the foundations of information security / ISO 27001, but that does not mean they have to be complicated. You can do it in a simple way, and your common sense is what really counts.
When organizations think about risks, they generally focus on what could go wrong, and take measures to prevent that, or at least to minimize its effects. But risks can also mean that something good can happen, and by not being ready to take advantage of the situation, you can miss the benefits.
This section will present how to consider and handle positive risks, also known as opportunities, in the context of ISO 27001. By including opportunities in an ISMS approach, organizations may increase the benefits of information security.
For ISO 27001, risk is the “effect of uncertainty on objectives,” and the “uncertainty” is the reason we cannot completely control all risks (after all, you cannot defend against what you do not know or understand).
ISO 27001 itself does not prescribe how to treat risks, while the supporting standard, ISO 27005, suggests four options: risk modification, risk retention, risk avoidance, and risk sharing. Detailed information about these risk treatment options can be found further in the article, but in short, all the options aim to decrease the likelihood of a risk happening and/or minimize its effects; i.e., they consider scenarios when something may go wrong.
Although this approach may have been appropriate in the early days of the standard, organizations today can no longer simply think in terms of what can go wrong in relation to their information security.
In the ISO’s most comprehensive standard about risk management, ISO 31000 – Risk management – Guidelines, besides options to handle negative risks, an organization may also consider taking or increasing the risk in order to pursue an opportunity, which can be achieved by:
Additionally, risk sharing and risk acceptance also may be used in the context of handling opportunities.
The answer may seem obvious… and, in fact, it is: when the rewards are greater than the potential losses, and you can accept the losses if they occur.
In the remote access example, you will have to consider not only lost opportunity related to a failure in implementing the service (e.g., loss of team time and effort), but also potential losses related to risks arising from the use of the remote access itself (e.g., loss of information confidentiality).
If these potential losses can be accepted by the organization, if they were to occur, and they are smaller than the potential gains from increasing productivity, why not take the risk?
“Hope for the best and prepare for the worst” is a common motto for risk planning, but in a time when organizations demand the best use of resources, and every opportunity is crucial, simply hoping for the best does not work anymore.
By adopting the opportunity treatment approaches from ISO 31000 and introducing them into the ISO 27001 risk management process, organizations may unveil and take advantage of a new set of opportunities that can not only improve internal operations, but also increase profits and market visibility.
Normally, doing the ISO 27001 risk assessment is a headache only when doing this for the first time – which means that risk assessment doesn’t have to be difficult once you know how it’s done.
So, how can you prepare yourself to make this headache smaller?
Since risk assessment and treatment are quite time-consuming and complex, you can decide whether they will be managed by the project manager/chief information security officer alone, or with the help of some hired expert (e.g., a consultant). A consultant could be quite helpful for larger companies, not only to guide the coordinator through the whole process, but also to perform part of the process – e.g., a consultant could do the workshops and/or interviews, compile all the information, write reports, etc., whereas the coordinator should manage the whole process and coordinate people within the company.
Larger companies will usually have project teams for the implementation of ISO 27001, so this same project team will take part in the risk assessment process – members of the project team could be the ones doing the interviews.
Smaller companies do not need to have a consultant or a project team – yes, the project manager will have to get some education first, but with the appropriate documentation and/or tools, this process can be done without expert help.
Tools can speed up the process of risk assessment and treatment because they should have built-in catalogs of assets, threats, and vulnerabilities; they should be able to compile results semi-automatically; and producing the reports should also be easy – all of which makes them a very good choice for larger companies.
However, for smaller companies, the price of such tools could be an obstacle, though in my opinion an even bigger barrier is the fact that such tools are sometimes too complex for smaller companies. In other words, the time needed to learn to work with such a tool is usually much longer than it would take to handle dozens of Excel sheets. Not to mention that such tools usually require you to follow overly complex risk assessment methodology, which could be overkill for smaller companies.
In other words, if you are a smaller company, choose the risk assessment tool carefully and make sure it is easy to use for smaller organizations.
Risk assessment means that you have to get quite a lot of input from your employees – essentially, there are three ways to do it:
The last option is probably the easiest from the perspective of the coordinator, but the problem is that the information gathered this way will be of low quality. If the risk assessment process is not very clear to you, be certain that it will be even less clear to other employees in your company, no matter how nice your written explanation is.
Of course, performing interviews will probably yield better results; however, this option is often not feasible because it requires a large investment of the coordinator’s time. So performing workshops very often turns out to be the best solution.
The decision about the level of risk (consequence and likelihood) should always be left to those persons responsible for the activities – the coordinator will never know the assets, processes, and environment well enough to make such decisions, but the persons working there will certainly have a better idea.
However, the coordinator has another important function during the risk assessment process – once he starts receiving the risk assessment results, he has to make sure they make sense and that the criteria between different departments are uniform. Even though the workshops have been performed, or an explanation was given during the interview to the responsible person, they will always tend to give much larger importance (meaning higher risks) to their own department – in such cases, the coordinator must question such assessment and ask this person to reconsider his or her decision.
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 it is extremely hard to list all potential risks that there could be), or is your goal to finish this process in a reasonable timeframe, knowing that it won’t be 100% accurate?
If you choose the latter approach, you will identify the main risks, and will get your people to start thinking about the necessity of protecting company information. And you will always have the opportunity to add the other risks later on, once you finish your initial implementation. This is what ISO 27001 requires from you anyway, as part of continual improvement.
ISO 27001 requires that risk assessment have five main steps, the same ones that are explained in the section about the risk assessment methodology:
Each of these steps is described in the following sections.
The current 2022 revision of ISO 27001 allows you to identify risks using any methodology you like; however, the methodology called “asset-based risk assessment” (defined by the old 2005 revision of ISO 27001) is still dominating, and it requires identification of assets, threats, and vulnerabilities.
So, how do you combine assets, threats, and vulnerabilities in order to identify risks?
To make your risk assessment easier, you can use a sheet or software that will list assets, threats, and vulnerabilities in columns; you should also include some other information like risk ID, risk owners, impact and likelihood, etc.
If you use a sheet, 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: Asset management according to ISO 27001: How to handle an asset register / asset inventory, and click here to see a catalog of threats and vulnerabilities appropriate for smaller and mid-sized companies.
So, let’s see what this matching of the three components could look like – for example:
Asset – paper document:
Asset – digital document:
Asset – system administrator (a person):
This might seem complicated at first glance, but once you start doing it, you’ll see that it goes rather quickly.
In order to speed up the process, you should group your assets so that you have fewer items to do the risk assessment with – for example:
Very often, people ask me how many risks they should list. If they start being really thorough, for each asset they could find 10 threats, and for each threat at least five vulnerabilities – this is quite overwhelming, isn’t it? 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 – e.g., three to five threats per asset, and one or two vulnerabilities per threat.
So the number of risks should depend roughly on the number of employees in your company:
| Number of employees | Number of assets | Number of risks |
| Up to 5 | 5 to 10 | 30 to 60 |
| 5 to 20 | 10 to 15 | 60 to 90 |
| 20 to 50 | 15 to 30 | 90 to 180 |
| 50 to 200 | 30 to 60 | 180 to 360 |
| 200 to 500 | 60 to 200 | 360 to 1200 |
There are other factors that will influence the number of risks – for example, if you are a financial institution, or you provide services to the military, you should probably make additional effort to identify more risks than displayed above.
Of course, over time you’ll find out other risks that you did not identify before – you should add these to your list of risks later on. After all, this is what continual improvement in ISO 27001 is all about.
I personally like this assets-threats-vulnerabilities methodology quite a bit, because I think it 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.
Once you have a list of your risks, you need to define who’s responsible for each of them.
In very small companies, you can nominate only one person to be the risk owner for all risks; however, for both big and small companies, a much better approach would be to consider each risk separately and to define risk owners based on these factors:
For example, the risk owner of a risk related to personnel records might be the head of the HR department, because this person knows best how these records are used and what the legal requirements are, and they have enough authority to pursue the changes in processes and technology necessary for protection.
The next step is to calculate how big each 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 decide what is the most appropriate approach for you.
Based on ISO 27005, there are essentially two ways to analyze the risks using the qualitative method – simple risk assessment, and detailed risk assessment – you’ll find their explanation below. ISO 27005 also suggests some other approaches to risk assessment, but they are more complicated and are not covered in this article.
You’ll find an explanation on why the quantitative risk assessment cannot be used in normal practice later on in this 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:
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:
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.
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 it looks nice.
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) of consequences and likelihood. 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 examples from the previous section, here is how to calculate the risk using addition:
In the detailed risk assessment explained in the previous section, you’ll notice that I used the 0 to 4 scale for assessing the asset value, and the smaller 0 to 2 scale 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.
This step is easy – you simply have to compare the level of risk that you calculated with the acceptable level from your risk assessment methodology. For example, if your level of risk is 7, and the acceptable level of risk is 5, this means your risk is not acceptable.
All the unacceptable risks must go to the next phase – the risk treatment in ISO 27001; all acceptable risks do not need to be treated further.
In the table below, you’ll see an example of a simple risk assessment using an asset-based approach.
| Asset | Threat | Vulnerability | Risk owner | Impact (1-5) | Likeli-hood (1-5) | Risk (=I+L) |
| Server | Electricity outage | No UPS | CIO | 4 | 2 | 6 |
| Fire | No fire extinguisher | 5 | 3 | 8 | ||
| Contract | Access by unauthorized persons | The contract is left on a table | Managing director | 4 | 4 | 8 |
| Fire | No fire protection | 4 | 3 | 7 | ||
| System administrator | Accident | No one else knows the passwords | Department head | 5 | 3 | 8 |
ISO 27001 risk treatment refers to the process of modifying a risk, by changing its likelihood and/or its impact. In most cases, this would mean decreasing the risk by reducing the likelihood of an incident (e.g., by using nonflammable building materials), and/or reducing the impact on assets (e.g., by using automatic fire-suppression systems).
Most people think risk assessment is the most difficult part of implementing ISO 27001 – true, risk assessment is probably the most complex, but risk treatment is definitely the one that is more strategic and more costly.
The purpose of risk treatment according to ISO 27001 seems rather simple: to control the risks identified during the risk assessment.
During the risk treatment, the organization should focus on those risks that are not acceptable; otherwise, it would be difficult to define priorities and to finance the mitigation of all the identified risks.
Once you have a list of unacceptable risks from the risk assessment phase, you have to go one by one and decide how to treat each – usually, these options are applied:
Decreasing the risks is the most common option for treating the risks, and for that purpose the controls from ISO 27001 Annex A are used (and any other controls that a company thinks are appropriate). See here how the controls are organized: Understanding the ISO 27001 controls from Annex A.
Before starting your implementation process, you should be aware of unacceptable risks from the risk assessment, but also your available budget for the current year, because sometimes the controls will require an investment.
When selecting new controls, there are basically three types of controls:
ISO 27001 risk treatment is a step where you normally wouldn’t include a very wide circle of people – you will have to brainstorm on each treatment option with specialists in your company who focus on certain areas. For example, if the treatment has to do with IT, you will speak to your IT guys; if it is about new trainings, you will speak to human resources, etc.
Of course, the final decision about any new treatment option will require a decision from the appropriate management level – sometimes the CISO will be able to make such decisions, sometimes it will be your project team, sometimes you will have to go to the department head in charge of a particular field (e.g., head of the legal department if you ask for additional clauses in the contracts with your partners), or perhaps to the executive level for larger investments. If you have doubts regarding who can decide what, consult your project sponsor.
If you choose to measure residual risks, i.e., the risks that will remain after you apply the controls, it should be done together with the responsible persons in each department. You have to show these people which treatment options you have planned for, and based on this information, and using the same scales as for the risk assessment, assess the residual risk for every unacceptable risk identified earlier during risk assessment.
So, for instance, if you had identified a consequence of level 4 and likelihood of level 5 during your risk assessment (which would mean risk of 9 by the method of addition), your residual risk may be 5 if you assessed that the consequence would lower to 3 and likelihood to 2 due to, e.g., safeguards you planned to implement.
When considering the ISO 27001 risk treatment options, and particularly safeguards that involve an investment in technology, please beware of the following: very often, the first idea that comes to mind will be the most expensive. However, sometimes alternatives will exist that will be equally effective, but at a lower cost – therefore, think hard before you purchase some expensive new system.
Also, be aware that most of the risks exist because of human behavior, not because of machines – therefore, it is questionable whether a machine is the solution to a human problem.
In other words, when treating risks you need to get creative – you need to figure out 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.
An example of a risk treatment table might look something like this:
| Asset | Threat | Vulnerability | Treatment option | Means of implementation |
| Server | Fire | No fire extinguisher | 1) Decrease risk + 2) Share risk |
Purchase fire extinguisher + buy insurance policy against fire |
| Laptop | Access by unauthorized persons | Inadequate password | 1) Decrease risk | Write Password Policy |
| System administrator | Leaving the company | No replacement | 1) Decrease risk | Hire second system administrator who will learn everything the first one does |
ISO 27001 doesn't specify the contents of the Risk Assessment Report; it only says that the results of the risk assessment and risk treatment process need to be documented – this means that whatever you have done during this process needs to be written down. Therefore, this report is not only about assessment – it is also about treatment.
The report includes all the risks that were identified, risk owners, their impact and likelihood, level of risk, risks that are not acceptable, and treatment options for each unacceptable risk.
Typically, the report is written in short form (e.g., in one page), to which a detailed list of risks and controls is attached.
The Risk Treatment Plan is one of the key documents in ISO 27001; however, it is very often confused with the documentation that is produced as the result of a risk treatment process. Here’s the difference.
The risk treatment process is only one phase in the risk management process that follows the risk assessment phase – in the risk assessment, all the risks need to be identified, and risks that are not acceptable must be selected. The main task in the risk treatment step is to select one or more options for treating each unacceptable risk, i.e., to decide how to mitigate all these risks.
As explained in the sections above, there are usually four treatment options available for companies: decrease the risk, avoid the risk, share the risk, and retain the risk.
According to ISO 27001, it is required to document the risk treatment results in the Risk Assessment Report, and those results are the main inputs for writing the Statement of Applicability. This means that the results of risk treatment are not directly documented in the Risk Treatment Plan.
So, where is the Risk Treatment Plan in this whole process? The answer is: it can be written only after the Statement of Applicability is completed.
Why is this so? To start thinking about the Risk Treatment Plan, it would be easier to think of it is an “Action plan” or “Implementation plan,” because ISO 27001 requires you to list the following elements in this document:
But in order to write such a document, you first need to decide which controls need to be implemented, and this is done (in a very systematic way) through the Statement of Applicability.
The question is – why didn’t ISO 27001 require the results from the risk treatment process to be documented directly in the Risk Treatment Plan? Why was this step in between needed, in the form of the Statement of Applicability (SoA)?
In my view, the authors of ISO 27001 wanted to encourage companies to get a comprehensive picture of information security – when deciding which controls are applicable and which are not – through the Statement of Applicability. For the SoA, the result of risk treatment is not the only input – other inputs are legal, regulatory and contractual requirements, other business needs, etc. In other words, the SoA is a more strategic document that defines the security profile of an organization, while the Risk Treatment Plan is the implementation plan of that strategy.
Once you’ve written this document, it is crucial to get your management’s 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.
To conclude – the Risk Treatment Plan is the point where theory stops, and real life begins according to ISO 27001. A good risk assessment and risk treatment process, as well as a comprehensive Statement of Applicability, will produce the foundations for finding out what you have to do with your security, but the Risk Treatment Plan is where you need to start doing the real thing. But you can’t start doing the real thing before you figure out the right thing to do.
Very often, I see people confuse gap analysis with risk assessment – which is understandable, since the purpose of both is to identify deficiencies in their company’s information security. However, from the perspective of ISO 27001, and from the perspective of a certification auditor, these two are quite different.
Gap analysis is nothing but reading each clause of ISO 27001 and analyzing if that requirement is already implemented in your company. When you do so, you can either say Yes or No, or you could use a scale similar to this:
Gap analysis is not mandatory in ISO 27001; it is done indirectly when developing your Statement of Applicability – clause 6.1.3 d) says you need to determine “… whether they [the necessary controls] are implemented or not.”
Therefore, you don’t need to perform the gap analysis for clauses of the main part of the standard – only for the controls from Annex A. Further, gap analysis doesn’t need to be performed before the start of ISO 27001 implementation – you must do it as part of your Statement of Applicability, only after the risk assessment and treatment.
Gap analysis tells you how far you are from ISO 27001 requirements/controls; it doesn’t tell you which problems can occur or which controls to implement. Risk assessment tells you which incidents can happen and which controls to implement, but it doesn’t give you an overview of which controls are already implemented.
While risk assessment is crucial for ISO 27001 implementation, gap analysis is only indirectly done when writing the Statement of Applicability – therefore, one is not a replacement for the other, and both are required, but in different phases of implementation and with different purposes.
Sometimes companies perform gap analysis before the start of ISO 27001 implementation, in order to get a feel for where they are right now, and to find out which resources they will need to employ in order to implement ISO 27001. However, the usefulness of such approach is doubtful, since only risk assessment will show the real extent of what needs to be implemented and in which form.
Quite often, I see people searching for ISO 27001 checklists for performing the internal audit; however, they expect those checklists to help them with, e.g., what information the organization has, who has access to it, how it is protected, how confidential it is, etc.
The problem is – these kinds of things are not part of an internal audit; this is part of the risk assessment.
The purpose of risk assessment is to find out which problems can arise with your information and/or operations – that is, what can jeopardize the confidentiality, integrity, and availability of your information, or what can threaten the continuity of your operations.
Consequently, risk assessment needs to be done at the beginning of the ISO 27001 project, while the internal audit is done only after the implementation has been completed.
The internal audit is nothing more than listing all the rules and requirements, and then finding out if those rules and requirements are complied with.
Typically, rules and requirements are the following:
When performing an internal audit, you need to check if each and every rule and requirement was complied with, in the whole scope of your Information Security Management System or Business Continuity Management System.
This is done by using various techniques:
See also: ISO 27001 Internal Auditor course.
So, I would say that one of the main differences is in the mindset: risk assessment is thinking about the (potential) things that could happen in the future, while the internal audit is dealing with how things were done in the past.
The second major difference is that the internal audit focuses on compliance with various rules and requirements, while risk assessment is nothing but analysis that provides a basis for building up certain rules.
The third difference is that the risk assessment is done before you start applying the security controls, while the internal audit is performed once these are already implemented.
However, they (unfortunately) do have one thing in common: they are both very often neglected in companies because they are perceived as only a bureaucratic exercise with no real value. However, the people who think this don’t realize they are both crucial for building up your information security.
A few days ago, I received the following question from one of our clients: “What is the difference between ISMS Risk Assessment and BCM Risk Assessment?” And, although the answer to this question might seem easy, in actuality it is not.
Here’s the rest of his question: “… Because on your blog I found that if I’ve done ISMS it should be fine for BCM. On the other hand, ISO 22301 recommends to use the ISO 31000 standard.”
It is true that ISO 22301 refers to ISO 31000 regarding risk assessment, but so does ISO 27001 – this does not mean you can actually use ISO 31000 for implementation, because this standard is written very generally since it covers all kinds of risks – not only business continuity and information security, but also financial, market, credit, and other risks.
On the other hand, the risk assessment framework is described much better in ISO 27001, and even more precisely in ISO 27005; the focus of information security risk assessment is on preserving confidentiality, integrity, and availability. And availability is the key link between information security and business continuity – when performing ISMS risk assessment, all the business continuity risks will be taken into account as well.
And the good thing is, risk assessment as it is described in ISO 27001 and ISO 27005 is perfectly aligned with ISO 31000.
But this is where it might get complicated – my client had another question, because he wanted everything to be cleared out: “I think that another difference between those two Risk Assessment approaches is – with ISMS we deal with assets (both primary and supportive); however, with BCM we deal with critical activities and processes.”
And he was basically right – business continuity risk assessment does not have to be so detailed; it can be made high-level for activities and processes. But, in my view, the problem is in the implementation – how can you mitigate the risks if you don’t know exactly where the problems are?
This is where I think the ISO 27001 risk assessment framework is better – it forces you to pinpoint where the weaknesses are, which assets should be protected better, etc. If you kept the risk assessment on the process level you probably wouldn’t get all this valuable information.
It is worth mentioning here – ISO 27001 risk treatment options are completely aligned with the risk mitigation requirements in ISO 22301 and ISO 31000. Basically, business continuity mitigation comes down to the four options described in this article above. There are no options listed in ISO 22301, while in ISO 31000 they are named a bit differently and organized a bit differently, but they are essentially the same.
And to finish with this: there is another good thing about ISO 27001 – in Annex A it gives you a catalogue of possible safeguards to choose from; this is something that neither ISO 22301 nor ISO 31000 has.
If you are implementing ISO 27001, or especially ISO 22301, for the first time, you are probably puzzled by the risk assessment and business impact analysis. What is their purpose? How are they different? Can they be performed at the same time?
To put it briefly, risk assessment will show you which kinds of incidents you might face, while business impact analysis will show you how quickly you need to recover your activities from incidents to avoid larger damage.
The purpose of this assessment is to systematically find out which incidents can happen to your organization, and then through the process of risk treatment to prepare in order to minimize the damage of such incidents.
In my experience, the employees (and the organization as a whole) are usually aware of only 25 to 40% of risks – therefore, it is not possible to try to remember all the risks by heart, and this identification needs to be done in a systematic way.
Business impact analysis is mandatory for the implementation of business continuity according to ISO 22301, but not for ISO 27001.
The purpose of the BIA is primarily to give you an idea of (1) the timing of your recovery, and (2) the timing of your backup, since the timing is crucial – the difference of only a couple of hours could mean life or death for certain companies if hit by a major incident.
More precisely, business impact analysis will help you determine the Maximum Acceptable Outage/Recovery Time Objective, Maximum Data Loss/Recovery Point Objective, required resources, and other important information that will help you develop the business continuity strategy for each of your activities. Learn more here: How to implement business impact analysis (BIA) according to ISO 22301.
As already concluded, BIA is usually used only in business continuity / ISO 22301 implementation; it could be done for information security, but it wouldn’t make much sense. Risk assessment (RA) is mandatory for both ISO 27001 and for ISO 22301.
Secondly, the outputs from RA are a bit different from those of BIA – RA gives you a list of risks together with their values, whereas BIA gives you timing within which you need to recover (RTO) and how much information you can afford to lose (RPO).
So, although these two are related because they have to focus on the organization’s assets and processes, they are used in different contexts.
Actually, ISO 22301 allows both approaches, and you might hear many theories on which is better. However, I prefer to do risk assessment first because this way, you will have a better impression of which incidents can happen (which risks you’re exposed to), and therefore be better prepared for doing the business impact analysis (which focuses on the consequences of those incidents); further, if you choose the asset-based approach for risk assessment, you will have an easier time identifying all the resources later on in the business impact analysis. What you definitely shouldn’t do is perform risk assessment and business impact analysis at the same time, because each of them separately is already complex enough – combining them normally means trouble.
The good news is that there were no changes in risk assessment requirements, so whatever you were doing to be compliant with the 2013 revision will still make you compliant with the 2022 revision.
Let’s remember a couple of myths related to risk management that have developed around the previous version, ISO 27001:2013, that are still myths when it comes to ISO 27001:2022:
So, as you can see, there are no changes in risk assessment and treatment, and you’ll find the transition to the 2022 revision of ISO 27001 relatively easy. All you need to do is keep identifying risk owners for each risk, and give them the responsibility to make decisions about the risks.
In the risk assessment process, one common question asked by organizations is whether to go with a quantitative or a qualitative approach. The good news is that you can use the easier approach (qualitative approach) and be fully compliant with ISO 27001; you can also use both approaches if you want to take a step forward in making your risk assessment highly advanced.
In qualitative risk assessment, the focus is on interested parties’ perceptions about the probability of a risk occurring and its impact on relevant organizational aspects (e.g., financial, reputational, etc.). This perception is represented in scales such as “low-medium-high” or “1-2-3-4-5,” which are used to define the risk’s final value.
Since it has little mathematical dependency (risk may be calculated through a simple sum, multiplication, or other form of non-mathematical combination of probability and consequence values), qualitative risk assessment is easy and quick to perform.
One problem with qualitative assessment is that it is highly biased, both in terms of probability and impact definition, by those who perform it.
For example, for HR people, HR impacts will be more relevant than IT impacts, and vice versa. Regarding a bias in probability, a lack of understanding of the timeframes of other processes may lead someone to think errors and failures occur more often in his own process than in the others, and this may not be true.
This situation with bias generally makes the qualitative assessment more useful in the local context where it is performed, because people outside the context probably will have divergences regarding impact value definition.
On the other hand, quantitative risk assessment focuses on factual and measurable data to calculate probability and impact values, normally expressing risk values in monetary terms, which makes its results useful outside the context of the assessment (loss of money is understandable for any business unit). To reach a monetary result, quantitative risk assessment often makes use of these concepts:
By relying on factual and measurable data, quantitative risk assessment has as its main benefits the presentation of very precise results about risk value, and the maximum investment that would make risk treatment worthwhile, so that it is profitable for the organization. Below is an example of how risk values are calculated through quantitative risk assessment:
That is, in this case, the organization has an annual risk of suffering a loss of $250K in the event of the loss of its database. So, any implemented control (e.g., backup, patch management, etc.) that costs less than this value would be profitable.
The problem with quantitative assessment is that, in most cases, there is no sufficient data about SLE and ARO, or obtaining such data costs too much.
As you may notice, qualitative and quantitative assessments have specific characteristics that make each one better for a specific risk assessment scenario, but in the big picture, combining both approaches can prove to be the best alternative for a risk assessment process.
By using the qualitative approach first, you can quickly identify most of the risks. After that, you can use the quantitative approach on the highest risks, to have more detailed information for decision making.
A general example would be a medical appointment. The doctor first asks a few simple questions, and from patient answers he decides which more detailed exams to perform, instead of trying every exam he knows at the beginning.
Risk assessment is one of the most critical parts of risk management, and also one of the most complex – affected by human, technical, and administrative issues. If not done properly, it could compromise all efforts to implement an ISO 27001 Information Security Management System, which makes organizations think about whether to perform qualitative or quantitative assessments. But you do not need to rely on a single approach, because ISO 27001 allows both qualitative and quantitative risk assessment to be performed.
If your company needs quick and easy risk assessment, you can go with qualitative assessment (and this is what 99% of the companies do). However, if you need to make some really big investment that is critical for security, perhaps it makes sense to invest time and money into quantitative risk assessment.
In short, by adopting a combined approach considering the information and time response needed, and data and knowledge available, you can enhance the effectiveness of the ISO 27001 information security risk assessment process, and also take a step further from what the standard requires.
The 2022 version of ISO 27001 does not prescribe any particular approach or methodology for performing the risk assessment.
While this provides more freedom for organizations to choose the risk identification approach that better fits their needs, the absence of such orientation is the source of a lot of confusion for organizations about how to approach risk identification.
Here I’ll explain how ISO 31010 (a standard focused on risk assessment) can help you, by presenting some of its risk identification approaches that can be used to find, recognize, and describe risks. Even though the approach suggested by ISO 31010 is not mandatory for ISO 27001, companies that want to explore other approaches to risk assessment might find it useful.
According to ISO 31010, the purpose of risk identification is to identify what could happen, or which situations could exist, that may affect the achievement of proposed objectives. Considering information security, some practical examples are:
Once a risk is identified, the organization should also identify any existing controls affecting that risk, and proceed to the next steps of the risk assessment (risk analysis and risk evaluation).
According to ISO 31010, a risk description must contain some elements:
ISO 31010 suggests the following risk identification methodologies that help collect all risk elements:
Brainstorming: a group creativity technique for collecting a large amount of information to find a conclusion for a specific situation. Because of its strong emphasis on imagination, it is useful to identify risks in situations that require a quick response and have few formal data available (e.g., selection of less harmful measures to contain an ongoing attack), or are new to the organization, like risks involving the entrance in a new market segment.
Interview: a conversation where pre-defined questions are presented to an interviewee to understand his perception of a given situation (e.g., market trends, processes performance, product expectations, etc.), and by that identify risks considering his perspective. It is recommended when detailed particular opinions are required (e.g., from the CEO, CFO, clients, etc.).
Delphi method: an anonymous collaborative technique used to combine different expert opinions in a reliable and unbiased way toward a consensus (e.g., selecting a security supplier, defining a protection strategy). It differs from brainstorming because it works to eliminate solutions during its realization, instead of creating them. It should be considered in situations where the characteristics of participants may affect the opinions of others (e.g., all agree/disagree with someone just because of his position).
Checklist: a technique where a list of items is elaborated to ensure that the most common topics, as well as the critical ones, on the subject matter are not forgotten during risk identification (e.g., common failures in software development, or protections required by contract). This increases the consistency and completeness of risk identification. Its use is recommended in cases where historical information, market references, and knowledge of previous situations are widely available.
Scenario analysis: methodology that uses models describing possible future scenarios to identify risks considering possible outcomes, strategies and actions leading to the outcomes, and possible implications to the business. A common approach in information security is, e.g., the use of permissive, restrictive, and balanced scenarios to identify risks in access control. It should be considered in situations where multiple solutions are available or results can present great variation.
Although asset-based methodology is not mandatory in the ISO 27001:2022 standard, it still is a valid approach that is used in a large majority of compliance projects. Of course, organizations that have already implemented an asset-based approach and think it is a good fit for them can continue to use it normally.
However, if you would like to use a different approach that can take the most advantage of the situation and the available information, your organization can consider some other approaches to risk identification and make your risk assessment more advanced.
To see how to use the ISO 27001 Risk Register with catalogs of assets, threats, and vulnerabilities, and get automated suggestions on how they are related, sign up for a free trial of Conformio, the leading ISO 27001 compliance software.
Dejan Kosutic