The Fundamentals of Risk Management in ISO 27001

What is risk vs. opportunity?

Most people are familiar with the idea of managing risks, but opportunities can be a little harder to understand in this context.  Opportunities are essentially the positive side of risk.  A risk is something uncertain that could have a negative impact, while an opportunity is something uncertain that could lead to positive results if you choose to take advantage of it.

Consider this from the perspective of placing a bet on a football match.  You risk losing your money if your side loses, but you have the opportunity to win money if your side wins.  Uncertainty exists at the start of the match and you need to determine how much money you are willing to lose in order to chase the opportunity.  In the business world, uncertainty may exist regarding a new market, fo.  A decision will need to be made about how much money and other resources the organisation is willing to risk in order to chase the new business opportunity, which could lead to significant rewards, ultimately making the risk worthwhile.  

With effective risk management in place, you are able to pursue opportunities available to your organisation with a comprehensive understanding of the risks associated with doing so.  If there are too many negative risks, you may avoid taking the course of action in question, especially if the potential reward isn’t particularly significant.  On the other hand, you might identify through risk assessment that there are fewer negative risks and more potential benefits to be gained, leading you to make  a confident and informed decision to pursue that opportunity.  

Clause 6.1.1

Clause 6.1.1 of ISO 27001 focuses on the risks to and caused by the ISMS itself.  We periodically come across organisations that do not understand the intention and purpose of this aspect of the Standard, instead focusing solely on information security risk assessment and risks to their information assets.  While this is important, you also need to ensure that your ISMS is effective and can achieve its intended outcomes.  What are the risks to the management system?  What will enable it to operate effectively, facilitating the secure management of information and supporting the prevention of information compromise?  This is not unlike project management; when embarking on a new project, you will consider the risks to the project and the actions that need to be taken to ensure the project works, and of course, sometimes, those actions could be prohibitively expensive, leading to the project being cancelled.  

You will need to ascertain aspects such as whether the appropriate resources are available, including the right people, adequate finances and relevant technology, whether buy-in from top management has been achieved, including processes for oversight and control of the ISMS.  It is also important to ensure that the ISMS supports the organisation’s business objectives and the reasons for the ISMS being implemented in the first place.  Once the ISMS has been designed to support business objectives, you will be able to take appropriate action, integrate the ISMS across the organisation, and take steps to evaluate how effective it is.

In practice, conformance to Clause 6.1.1 involves identifying not only risks to the ISMS, but also the risks that may arise from the ISMS itself.  For example, implementing overly complex controls may mean that they are not effective as people do not understand them, leading to the controls not being embedded across the organisation.  Or, excessively restrictive security measures could reduce the efficiency of critical organisational processes.    

In addition, you need to ensure the performance of the ISMS is regularly reviewed, identifying any necessary improvements and subsequently ensuring these improvements are actually implemented (i.e., continual improvement).  Where it has been decided that actions are needed to address any risks or opportunities, such actions need to be integrated across every area of the organisation that the ISMS touches.  As part of the development of the ISMS, you will also need to understand how you determine what ‘good’ looks like, and how monitoring and measurement of performance is achieved.  These elements need to be in place across the entire organisation, and implemented in a way that leads to genuinely valuable feedback being provided and a comprehensive understanding of whether the ISMS is operating as expected and intended. This review is generally undertaken by top management representatives as they tend to understand the performance of the organisation and what effect the ISMS is having upon it.

‍

Clause 6.1.2 of the Standard focuses on the information security risk assessment itself, and one of the first elements it focuses on is risk acceptance criteria, i.e., the rules associated with when risks can be accepted, by whom, for how long and under what circumstances.  When done properly, risk acceptance criteria can make risk management far less cumbersome and lead to efficiency gains, for example by delegating authority to individuals and teams at different levels of the organisations to accept different levels of risk.  

If you’re using ‘RAG’ (red-amber-green) status to classify risk, you may decide that any classified as ‘green’ are within appetite and can be accepted by anyone within the organisation dealing with risk.  Risks at this level are likely to be reviewed on an annual cycle or similar.  ‘Amber’ risks likely need to be reviewed by individuals with a greater level of authority and more often, e.g., quarterly.  Bearing in mind that risks are simply incidents that haven’t yet happened, it may be more appropriate that these can only be accepted by more senior members of staff.  These may be heads of department, budget holders, or other personnel who can make key decisions for their part of the organisation, understand the potential consequences of accepting the risk, and have been given authority by top management for this purpose.  

Finally, only top management themselves should be involved in determining whether ‘red’ risks are required to be accepted.    These risks are the most significant and could have far reaching consequences for the organisation if they turn into incidents.  These risks are likely to be reviewed at least monthly, enabling top management to determine whether the risks should continue to be accepted or whether extra effort should be made to mitigate them.  

In addition to risk management processes requiring reviews of risks at certain cadences depending on the level of risk, they should also be dynamic and able to respond to new or changed threats as and when they are identified.  

It should be noted that just because a risk is within the authority of someone to accept, this doesn’t automatically mean it should be accepted, especially if the risk is amber or red.  As part of defining risk acceptance criteria, there should be a valid reason for accepting the risk.  For example, perhaps there simply isn’t the budget to implement mitigating controls, or a regulatory or contractual reason why certain controls can’t be implemented.  Risks that have been accepted should be documented and a reasonable justification for acceptance of the risk should be included.  

By defining different levels of authority to accept commensurate levels of risk, risk acceptance becomes more efficient and less bureaucratic, allowing you to progress through the risk management process without unnecessary delay rather than waiting for the most senior people to be available for a meeting.  It also allows you to embed information security across the entire organisation, involving more of the business in the risk management process and helping to enhance understanding of information security risk.

Clause 6.1.2 also requires you to define criteria for performing risk assessments, and ensure that the risk assessment process can provide repeatable, consistent and comparable results.  Ultimately, you will need to define a methodology for performing risk assessments, and this methodology needs to be documented and embedded across the entire organisation or wherever risk assessments are being performed.  The methodology needs to contain the criteria that must be met when performing the assessment as stated in Clause 8.1, which deals with actually conducting the risk assessment.  The goal is to ensure that risk assessments are performed consistently across different parts of your organisation by making sure that the criteria are met every time the assessment is conducted.  This enables risks to be analysed and ratings assigned that are meaningful and can be compared reliably across different departments, sites, functions, etc.

Having identified and analysed your information security risks, they need to be evaluated against your risk appetite to determine which fall within your acceptance criteria.  This will help you to determine which risk treatment options to choose (more on this below).  You will also need to identify information security risk owners, who will make decisions around what actions need to be taken in relation to the risks they are responsible for.  Typically, these will be the same individuals as asset owners, which are the people responsible for different information assets, and incidentally are likely to be same people to whom risk acceptance authority has been delegated.  For example, the head of HR is likely to be responsible for HR information, and would also likely be the risk owner for information of this type and can determine if certain risks related to HR information are able to be accepted or not.

‍

One risks have been identified, analysed and evaluated, they will need to be treated.  There are 4 overarching risk treatment options available to you:

• Accept, as discussed above
• Transfer, e.g., through insurance, which offsets financial impact
• Mdify (i.e., reducing or mitigating risk), generally by implementing new controls or improving existing ones
• Avoid, by removing the asset.

When modifying or mitigating risk, Annex A of the Standard provides a set of 93 controls across 4 themes (organisational, technological, people and physical) that can be implemented to reduce risk levels.  ISO 27001 requires you to consider all of these controls, determine which are applicable and explain why in your Statement of Applicability (SoA).  However, the Standard also states that Annex A is not the only valid source of controls, and there are other steps you may need to take to mitigate risk.  You may consider controls from other standards / frameworks (e.g., the Payment Card Industry Data Security Standard or ‘PCI DSS’), contractual requirements, legislation, regulatory requirements, etc.  These need to be included in your ISMS and managed in the same way you manage the Annex A controls.  

If your primary goal is to achieve ISO 27001 certification and meet the Standard’s requirements as simply and swiftly as possible, you can just consider the Annex A controls initially to make the process of implementing and certifying to the Standard more manageable.  However, to gain the maximum benefit from your ISMS, you should then look to strengthen your risk management by considering these additional control sources over time.

There are several mandatory documents required by the Standard in relation to risk management, and it is not uncommon for organisations to find that they are missing one or more of these during a certification assessment.  This has been particularly true since the transition to the 2022 version of the Standard, which introduced some new elements to Clause 8.1.

While much of what has been discussed so far in this blog covers the planning phase of risk management, Clause 8 focuses on actually carrying this out.  ISO 27001:2022 has added to Clause 8 by specifying that you need to perform processes in line with the criteria you have defined and prove you have done so.  As such, you will need to be able to provide evidence that the criteria have been met.  The following mandatory documented information must be in place and available for review during an audit:

• Statement of Applicability or ‘SoA’ (6.1.3d)
• Risk treatment plan (6.1.3e)
• Risk assessment process (6.1.2)
• Risk treatment process (6.1.3)
• Records of completion in accordance with the plan (8.1)
• Results of risk assessment (8.2)
• Results of risk treatment (8.3).

It’s important that all of the above are included in your ISMS; if an auditor identifies that any are missing, a nonconformity will be raised against the relevant clause.

Effective risk management provides the foundation upon which a successful ISMS is built.  When implemented properly, risk management becomes an ongoing process of continual improvement, helping organisations respond to changing threats, make informed decisions, pursue opportunities with confidence, and strengthen their overall information security posture.