SPRING DISCOUNT
Get 30% off on toolkits, course exams, and books.
Limited-time offer – ends May 26, 2022
Use promo code:
SPRING30
  • (0)

    ISO 27001 Risk Assessment, Treatment, & Management: The Complete Guide

    ISO 27001 Risk Assessment, Treatment, & Management: The Complete Guide - 27001Academy
    ISO 27001 compliance software
    ISO 27001 Risk Assessment, Treatment, & Management: The Complete Guide - 27001Academy
    ISO 27001 Templates
    ISO 27001 Risk Assessment, Treatment, & Management: The Complete Guide - 27001Academy
    ISO 27001 Courses
    Risk management

    What is risk management, and why is it important?

    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 114 controls.

    Main steps in ISO 27001 risk assessment and treatment:
    1. Risk management methodology
    2. Risk assessment
    3. Risk treatment
    4. Risk assessment and treatment report
    5. Statement of Applicability
    6. Risk treatment plan

    ISO 27001 risk assessment & treatment – six main steps

    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:

    1) ISO 27001 risk assessment methodology

    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.

    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, 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.

    4) Risk Assessment and Treatment Report

    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.

    5) Statement of Applicability

    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: 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 – 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.

    How does ISO 27005 help with risk management?

    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.

    Learn how to carry out risk assessment and treatment according to ISO 27001. Read the complete guide to ISO 27001 risk management now.

    How to write ISO 27001 risk assessment methodology

    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).

    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.

    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 the criteria for assessing consequences and assessing the likelihood of the risk.
    4. Define how the risk will be calculated.
    5. Define the criteria for accepting risks.

    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.

    Which options are available?

    Of course, there are many options available for the above five 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. 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 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.

    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.

    Risk management tips for smaller companies

    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:

    • Choose the right methodology. The methodology needs to be simplified and contain only the five elements that are required by ISO 27001. If you end up using a methodology that you copied from some large corporation, you’ll be doing risk assessment and treatment for months instead of in a couple of days.
    • Choose the right tool. Find the software that follows your (simplified) methodology, not the other way around. In some cases, a good Excel template will do a better job than complicated software.
    • Include the right people. You shouldn’t try to do this on your own; you should include the heads of all of your departments because they know their processes the best, which means that they know where potential problems could happen.
    • Do not try to be perfect. Do not try to find all the risks the first time you do this – it will only slow you down; instead, you should finish your risk assessment and treatment, and come back later on to add any risks that were missing.

    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.

    How to address opportunities in ISO 27001 risk management using ISO 31000

    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.

    How ISO 27001 defines and treats risks

    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.

    Opportunity options for 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:

    • Risk enhancing– This includes taking measures to increase the probability of a risk happening. This one can be considered as the counterpart of the risk mitigation option for negative risks. For example, to take the opportunity to increase productivity, an organization decides to implement remote access by sharing existing resources and personnel to build and run the service which, in effect, increases risks.
    • Risk exploiting– This means taking every possible action to ensure the risk will happen. It differs from the risk enhancing option in the fact that it involves more effort and resources, to effectively ensure the risk will happen. This one can be considered as the counterpart of the risk avoidance option for negative risks. For example, you intend a risk with a small impact to materialize because you would like to test how your incident response procedure works.

    Additionally, risk sharing and risk acceptance also may be used in the context of handling opportunities.

    • Sharing opportunities. When an organization realizes that, by itself, it cannot harness the benefits of an opportunity, it may share the risk, seeking a partner to split costs and efforts, so both can share the opportunity that neither of them could take advantage of by themselves. This differs from sharing negative risks, because in this last case the organization only transfers the costs of a negative impact to a third party. A joint venture between a system development company and a project management services provider is a good example of risk sharing considering opportunities.
    • Do nothing. The organization may also consciously decide to do nothing about the opportunity (if it does occur, all the better, but considering the effort it would take to make it happen, it is not worth pursuing) – this is similar to accepting the negative risks.

    When is it acceptable to increase risks?

    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?

    Don’t only hope for the best; be prepared for it

    “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.

    Risk assessment

    How to perform ISO 27001 risk assessment

    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?

    Do it alone or hire a consultant?

    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.

    Should you use a tool for risk assessment?

    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.

    Options for gathering the information

    Risk assessment means that you have to get quite a lot of input from your employees – essentially, there are three ways to do it:

    1. Perform risk assessment through interviews– this means that the coordinator will interview the responsible person(s) from each department, where he will explain the purpose of risk assessment first, and make sure that every decision of the responsible person about the level of risk (consequence and likelihood) makes sense and is not biased.
    2. Perform workshops with responsible persons– in these workshops, the coordinator explains to all responsible persons the purpose of risk assessment, and through several real-life examples, shows how to identify risks and assess their level.
    3. Send the sheets with detailed explanation– here you don’t help the responsible persons directly, but you send them risk assessment methodology or some other instructions on how to fill in the risk assessment sheets, and they do it themselves.

    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.

    Who decides on the level of risk?

    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.

    Don’t be a perfectionist

    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.

    Main steps in ISO 27001 risk assessment

    ISO 27001 requires that risk assessment have five main steps, the same ones that are explained in the section about the risk assessment methodology:

    1. Risk identification (listing assets, threats, and vulnerabilities)
    2. Assigning risk owners (persons responsible for risk)
    3. Risk analysis (assessing consequences and likelihood)
    4. Risk calculation (determining the level of risk)
    5. Risk evaluation (accepting the risks based on criteria)

    Each of these steps is described in the following sections.

    How to match assets, threats, and vulnerabilities

    The current 2013 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?

    How 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: 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:

    • threat: fire; vulnerability: document is not stored in a fire-proof cabinet (risk related to the loss of availability of the information)
    • threat: fire; vulnerability: there is no backup of the document (potential loss of availability)
    • threat: unauthorized access; vulnerability: document is not locked in a cabinet (potential loss of confidentiality)

    Asset – digital document:

    • threat: disk failure; vulnerability: there is no backup of the document (potential loss of availability)
    • threat: virus; vulnerability: anti-virus program is not properly updated (potential loss of confidentiality, integrity, and availability)
    • threat: unauthorized access; vulnerability: access control scheme is not properly defined (potential loss of confidentiality, integrity, and availability)
    • threat: unauthorized access; vulnerability: the access was given to too many people (potential loss of confidentiality, integrity, and availability)

    Asset – system administrator (a person):

    • threat: unavailability of this person; vulnerability: there is no replacement for this position (potential loss of availability)
    • threat: frequent errors; vulnerability: lack of training (potential loss of integrity and availability)

    This might seem complicated at first glance, but once you start doing it, you’ll see that it goes rather quickly.

    Grouping the assets

    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:

    • If you have several laptops in your company, you should use one item called “laptops.”
    • If you have several servers, you can group them into, e.g., “physical servers” and “virtual servers,” or perhaps “servers for internal use” and “production servers with customer data.”
    • If you use several SaaS applications, you can group them into, e.g., “marketing & sales SaaS,” “software development SaaS,” etc.
    • You can group your employees into, e.g., “top management,” “IT system administrators,” and “other employees.”

    How many risks are enough?

    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.

    Why is this methodology still good?

    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.

    Assigning the risk owners

    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:

    • the person who knows the asset the best, and
    • the person who has the power to make the necessary changes

    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.

    How to determine consequences and likelihood

    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.

    Simple (or basic) risk assessment

    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.

    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 it looks nice.

    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) 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:

    • Simple risk assessment: Consequences (3) + Likelihood (4) = Risk (7)
    • Detailed risk assessment: Asset value (3) + Threat value (2) + Vulnerability value (2) = Risk (7)

    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.

    Risk evaluation

    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.

    Example of risk assessment

    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
    Risk treatment

    The purpose of risk treatment

    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 seems rather simple: to control the risks identified during the risk assessment; in most cases, this would mean to decrease the risk by reducing the likelihood of an incident (e.g., by using nonflammable building materials), and/or to reduce the impact on assets (e.g., by using automatic fire-suppression systems).

    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.

    Four most common treatment options

    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:

    • Decrease the risk– this option is the most common, and it includes implementation of safeguards (controls) – e.g., by implementing backup you will decrease the risk of data loss.
    • Avoid the risk– stop performing certain tasks or processes if they incur such risks that are simply too big to mitigate with any other options – e.g., you can decide to ban the usage of laptops outside of the company premises if the risk of unauthorized access to those laptops is too high (because, e.g., such hacks could halt the complete IT infrastructure you are using).
    • Share the risk– this means you transfer the risk to another party – e.g., you buy an insurance policy for your physical server against fire, and therefore you transfer part of your financial risk to an insurance company. Unfortunately, this option does not have any influence on the incident itself, so the best strategy is to use this option together with options 1) or 2).
    • Retain (accept) the risk– this is the least desirable option, and it means your organization accepts the risk without doing anything about it. This option should be used only if the mitigation cost would be higher than the damage an incident would incur.

    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: Overview of ISO 27001:2013 Annex A.

    Implementation of security controls

    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:

    1. Defining new rules: rules are documented through plans, policies, procedures, instructions, etc., although you don’t have to document some less-complex processes.
    2. Implementing new technology: for example, backup systems, disaster recovery locations for alternative data centers, etc.
    3. Changing the organizational structure: in some cases, you will need to introduce a new job function, or change the responsibilities of an existing position.

    Deciding which controls to select

    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.

    Residual risk

    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.

    The most expensive security controls are not always the best

    When considering the 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.

    Example of risk treatment

    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

    How to write a risk assessment and treatment report

    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.

    Risk Treatment Plan vs. risk treatment process – What’s the difference?

    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.

    What is the risk treatment process?

    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. See also: The importance of Statement of Applicability for ISO 27001.

    How do you write a 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:

    • which security controls and other activities you need to implement
    • who is responsible for the implementation
    • what are the deadlines
    • which resources (i.e., financial and human) are required for the implementation, and
    • how will you evaluate if the implementation was done correctly

    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 purpose of the Risk Treatment Plan

    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.

    Other aspects of risk assessment

    ISO 27001 gap analysis vs. risk assessment

    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.

    What is ISO 27001 gap analysis?

    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:

    • 0 – requirement not implemented nor planned
    • 1 – requirement is planned but not implemented
    • 2 – requirement is implemented only partially, so that full effects cannot be expected
    • 3 – requirement is implemented, but measurement, review, and improvement are not performed
    • 4 – requirement is implemented, and measurement, review, and improvement are performed regularly

    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.

    The difference between gap analysis and risk assessment

    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.

    Risk assessment vs. internal audit

    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 difference in timing

    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. See also: How to organize initial risk assessment according to ISO 27001 and ISO 22301.

    How is the internal audit done?

    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:

    • Examining all the documentation and records
    • Interviewing the employees
    • Personal observations (e.g., walking around the premises)

    See also: ISO 27001 Internal Auditor course.

    The main differences between the two

    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.

    Can ISO 27001 risk assessment be used for ISO 22301 business continuity?

    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.”

    Why the ISO 27001 risk management framework is a good solution

    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.

    Possible differences in approach

    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.

    Risk mitigation compatibility

    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.

    Risk assessment vs. business impact analysis

    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 risk assessment

    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.

    The purpose of business impact analysis (BIA)

    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.

    The difference between the two

    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.

    Which comes first – risk assessment or business impact analysis?

    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.

    ISO 27005 2005 revision vs. 2013 revision – what has changed in risk management

    Risk assessment in ISO 27001 has always been a hot topic, and especially with the changes in the 2013 revision – there are many doubts as to whether the risk assessment you’ve done according to the 2005 revision needs to be changed, and if yes – how big the change is.

    The myths

    Let’s start with a couple of myths related to risk management that have developed around ISO 27001:2013:

    • “We have to use ISO 31000 for risk management.” False – ISO 31000 is only mentioned in ISO 27001:2013, but it is not mandatory. (See also ISO 31000 and ISO 27001 – How are they related?)
    • “We have to delete assets, threats, and vulnerabilities from our risk assessment in ISO 27001.” False again – you can keep your old methodology if you like it, because ISO 27001:2013 leaves you the freedom to identify risks any way you want.
    • “We do not have to identify asset owners anymore.” Another false statement – although ISO 27001:2013 does not require you to identify asset owners as part of the risk assessment, it does require you to do it in control A.8.1.2. (See also Risk owners vs. asset owners in ISO 27001:2013)
    • “The identification of risks based on confidentiality, integrity, and availability (C-I-A) is a new concept.” False – this concept existed in ISO 27001:2005, too; actually, the whole standard is based on the concept of protecting the C-I-A from the very beginning.

    What has changed in risk management in ISO 27001:2013

    As you’ll see, the changes are not very significant:

    1. The top-level Information Security Policy does not need to establish criteria against which risks will be evaluated – this was the requirement of ISO 27001:2005 4.2.1 b) 4); in ISO 27001:2013, you still need to define the risk assessment criteria, but not as part of the top-level policy.
    2. As mentioned before, you do not need to use the assets-threats-vulnerabilities methodology to identify risks – for example, you can identify risks based on your processes, based on your departments, using only threats and not vulnerabilities, or any other methodology you like.
    3. You need to identify risk owners for each risk.
    4. ISO 27001:2005 required management to approve residual risks, as well as implementation and operation of the ISMS. On the contrary, in ISO 27001:2013, the risk owners must accept the residual risks and approve the Risk Treatment Plan.
    5. Treatment options in the 2013 revision are not limited only to applying controls, accepting risks, avoiding risks, and transferring risks as they were in the 2005 revision – basically, you are free to consider any treatment option you find appropriate.

    One indirect change that is not visible at first reading of the standard is that risk management has taken the role of preventive actions (preventive actions do not exist in the 2013 revision any more) – only when reading clause 6.1.1 of ISO 27001:2013 more carefully does this becomes obvious. But this change makes sense – preventive actions are nothing other than concluding what negative things can happen in the future, and taking action to prevent them – and this is exactly what risk assessment and treatment is also about. Therefore, ISO 27001:2013 has only corrected what was not very logical in ISO 27001:2005, and the good thing is you do not have to change your risk assessment process because of it.

    So, as you can see, the changes in risk assessment and treatment are relatively minor, and if you’ve done a good job with ISO 27001:2005, then you’ll find the transition to the 2013 revision of ISO 27001 relatively easy. All you need to do is identify risk owners for each risk, and give them the responsibility to make decisions about the risks.

    Qualitative vs. quantitative risk assessment

    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.

    Qualitative risk assessment

    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.

    Quantitative risk assessment

    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:

    • SLE (Single Loss Expectancy):money expected to be lost if the incident occurs one time.
    • ARO (Annual Rate of Occurrence):how many times in a one-year interval the incident is expected to occur.
    • ALE (Annual Loss Expectancy):money expected to be lost in one year considering SLE and ARO (ALE = SLE * ARO). For quantitative risk assessment, this is the risk value.

    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:

    • Database value: $2.5 million (SLE)
    • Manufacturer statistics show that a database catastrophic failure (due to software or hardware) occurs one time every 10 years (1/10 = 0.1) (ARO)
    • Risk value: $2,500,000 x 0.1 = $250,000 (ALE)

    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.

    Combining approaches

    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.

    Adapt your approach to optimize your effort and results

    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.

    What are the different types of risk assessment?

    One of the most significant changes in the 2013 version of ISO 27001 is that it no longer prescribes any particular approach in the risk assessment. While it still requires the adoption of a process-based risk assessment approach, the obligation to use an asset-threat-vulnerability model in the risk identification step no longer exists.

    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.

    The risk identification step

    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:

    • A power surge may cause a storage unit to fail, leading to data loss.
    • A lack of attention may cause an employee to send a report to the wrong person, leading to unauthorized information disclosure.
    • A change in environmental conditions may cause a device to make erroneous readings, leading to a compromise of data integrity.

    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).

    Potential methodologies for identifying risks

    According to ISO 31010, a risk description must contain some elements:

    • risk sources: elements in the scenario that, isolated or combined, have the potential to affect the expected results (e.g., the electricity to power the storage unit)
    • event: a specific set of circumstances (e.g., the storage unit failure)
    • cause: the initial condition that starts the event (e.g., the power surge)
    • consequence: the result of the event affecting the objective (e.g., the data loss, affecting the information availability)

    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.

    What about the asset-threat-vulnerability approach?

    Although asset-based methodology is not mandatory in the ISO 27001:2013 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 14-day free trial of Conformio, the leading ISO 27001 compliance software.

    Advisera Dejan Kosutic
    Author
    Dejan Kosutic
    Leading expert on cybersecurity/information security and author of several books, articles, webinars, and courses. As a premier expert, Dejan founded Advisera to help small and medium businesses obtain the resources they need to become certified against ISO 27001 and other ISO standards. He believes that making ISO standards easy-to-understand and simple-to-use creates a competitive advantage for Advisera's clients.

    As an ISO 27001 expert, Dejan is sought out to help companies find the best way to obtain certification by eliminating overhead and adapting the implementation to the specifics of their size and industry.
    Connect with Dejan: