ISO 27005 and the risk assessment process

ISO 27005 describes the risk management process for information and cyber security. It’s part of the ISO 27000 series, which means its advice is part of a wider set of best practices for to protect your organisation from data breaches.

As with every standard in the series, ISO 27005 doesn’t outline a specific approach that organisations must take towards compliance. So how do organisations get started? We take a look in this blog.

AWS Builder Community Hub

Context establishment

The basic objective in establishing the context of risk management is to know the risk appetite, or the level of risk that an organisation is willing to accept.

ISO 27005 provides guidelines for establishing this context, which in turn determines the criteria for information security risk management.

This could include the criteria for defining the impact of specific risks (e.g. damage to the organisation’s reputation, financial loss, legal penalties, etc.), for estimating what the acceptable level of risk will be, and for determining the organisation’s objectives.

An example of risk acceptance criteria could be a risk that may negatively affect productivity for more than one day. This could be considered an unacceptable level of risk.

Risk identification

Risk identification involves defining things that could cause a loss to an organisation, such as:

  • Information assets (such as hardware, personnel, processes);
  • Information security threats (such as criminal hacking, internal error);
  • Existing and planned security measures, also known as ‘controls’;
  • Vulnerabilities; and
  • The potential consequences of those risks to the business.

Risk estimation

To address the risks your organisation faces, you must first understand how they work and potent they are.

There are many ways to do this, but the most common approach involves the following equation:

Risk = (the probability of a threat exploiting a vulnerability) x (total impact of the vulnerability being exploited)

There is no set way of scoring threat, impact and risk – indeed, you can choose to do it either qualitatively (i.e. based around subjective measurements, such as ‘moderate’, ‘severe’, etc.) or quantitatively (i.e. based on absolute measurements, such as a mathematical calculation).

Whichever approach you use, the aim is to have a consistent, comparable list of risks that takes into account damages such as monetary loss, technical damage and human impact.

Risk assessment: risk identification + risk estimation + risk evaluation

The risk assessment process enables the risk assessor to make decisions while taking the organisation’s objectives into account.

The risk assessment includes the above two stages for risk analysis, but also includes an additional step, which refers to risk evaluation.

In the risk evaluation phase, the level of risk is compared against the risk evaluation criteria and the risk acceptance criteria, which were defined during the context establishment phase.

The risk evaluation compares each level of risk against the risk acceptance criteria and prioritises the list of risks with plans for treating the risks.

The risk assessor is usually required to make a decision about how to respond to the risk based on the outcome of the risk evaluation.

Risk response 

During the risk response phase, the risk assessor must make a decide what to do about the risk. They have four options:

  • Treat the risk by, for instance, implementing a policy to mitigate it
  • Tolerate the risk. In other words, the company may choose to do nothing because the likelihood of the risk occurring is so small that the cost of treating it would outweigh the benefit.
  • Transfer the risk. This generally means hiring a third party to handle security or investing in cyber insurance.
  • Terminate the risk – i.e. change the way the organisation operates so that the risk is no longer present. An example of this is upgrading a legacy operating system to remove vulnerabilities that are no longer being patched.

Risk communication, monitoring and review

The risk management process isn’t over after the risks have been addressed. Organisation must analyse how successful their solutions were and make amendments where necessary.

The first part of that is risk communication is risk communication. This means, first of all, keeping a record of how you are tackling the risk and informing anyone who might be affected.

For example, if you’ve modified the risk of certain sensitive documents being misappropriated by applying access controls to them, you should tell your employees.

Similarly, if you’ve terminated the risk and created a new work process, anyone whose work will be affected by that must be informed. If you don’t, they may end up continuing to follow previous protocols and undermining your work.

Next, you must regularly monitor risks to make sure your risk response is working as intended and that risks aren’t transforming and affecting you in new ways.

This is indicative of the fact that risk management is an ongoing process and must be an essential part of your cyber security measures.

Ongoing risk assessment support with Vigilant Software

Are you looking for help creating a consistent, repeatable risk assessment? Vigilant Software’s vsRisk provides guides you through every step of the process quickly and simply.

Fully aligned with ISO 27001, vsRisk can generate six audit-ready reports, including the risk treatment plan and the Statement of Applicability.

And thanks to its built-in control set and integrated risk, vulnerability and threat databases, there’s no need to go through the legwork of compiling a list of risks or trawling through applicable legal requirements.

Conduct simple, fast and accurate risk assessments with vsRisk

A version of this blog was originally published on 3 October 2014.

The post ISO 27005 and the risk assessment process appeared first on Vigilant Software – Compliance Software Blog.

*** This is a Security Bloggers Network syndicated blog from Vigilant Software – Compliance Software Blog authored by Vigilant. Read the original post at: