PHONE: (305) 744-5447 / (866) 553-3779

FAX: (866) 582-4901

1722 Sheridan St., Hollywood, FL 33020

North America's Premier ISO 27001 Training & Consulting Services Provider

  • twitter
  • facebook
  • googlePlus
  • linkedin


ISO 27005 Risk Treatment Options for Your ISO 27001 ISMS

October 14, 2015



In this article we will be exploring how risk treatment options from ISO 

27005 can help business and technology leaders make informed risk trade off decisions in an ISO 27001 based information security management system.


No matter where we go or what we are doing in business, one consistent that we find behind every corner is Risk. Now imagine a world where we are paralyzed by Risk; organizations would be never develop anything new, never venture into uncharted space, ultimately innovation would come to a grinding halt! I'm not sure about you, but I think that is not necessarily the world I want to live in. I want to be in a world where technology and the human spirit evolves.




So, I think we're in general agreement at least on the technology side (the other side will follow). Given that acceptance, our world has already dictated the need to establish an approach to manage risk. In support of this, a number of frameworks and methodologies have been developed and published. Before going any further, I would like to offer a couple of definitions for these to ensure we're on a level playing field and speaking the same language. To this end, the difference between a framework and a methodology is quite simple:

  • Framework: is the basic building blocks or a standard structure i.e. ISO 27005. For our purposes, this is typically considered the what has to be done.

  • Methodology: is the detailed set of actions performed to achieve a desired outcome e.g. RCMP Threat Risk Assessment (TRA), OCTAVE, CRAM, NIST 800-30, etc.. This is typically called the "how" to achieve it.

So for those new to the topic, and a refresher for the acquainted, risk is a representation or result of vulnerabilities ("V") multiplied by the probability ("P") or likelihood of an occurrence of a threat manifesting, multiplied by the impact ("I") or consequence, or as show in a notional formula as, R =  V * P * I. In older documentation you may have, and still may come across this represented as R = T * V * P * I, wherein the "T" is simply the threat factor.   This risk can be expressed in either qualitative or quantitative terms, which will be determined based on your homework on risk management and the approach that is subsequently adopted by your organization.


So all that behind us, how do we apply this in our everyday world? So lets look at a new business initiative that requires IT to develop a new IT product (infrastructure + application) to support it. As we go through the software development life-cycle (SDLC) there are a number of infusion points, information security should be involved in to ensure the "IT Product" is secure before going into operations. For the sake of brevity, let's leave the topic of security in the SDLC for another blog post. As the security team members work with the project team, a variety of information security risks are identified. Once the risks have been identified, the must go through the Risk Management Process. So what does this Risk Management Process look like? Well, it will vary from one company to the next depending on the methodology chosen, and how you customize it to suite your unique needs. For the purpose of illustration for this article, on the right hand side of the screen we have included the risk framework offered by ISO 27005.


Risk Treatment Options (Rto)


For the purposes of this article will not be going through every step of typical risk framework as offered in the ISO 27005 framework illustration above, but rather focusing the conversation on being able to articulate the four risk treatment options. So, to get the ball rolling for those not acquainted with the topic, what are risk treatment options you ask? Without any mystery attached, they are simply industry accepted categories, ways or means to manage risk. A little later in this article we will talk about some case study exams from my experience to help you better understand each of these, but for now we will simple identify and give a brief explanation of the four accepted approaches to treat risk:

  1. Risk Modification (Rm) - risk modification is when you introduce something to the equation that can positively or negatively influence risk. In the business of technology management and information assurance, we are traditionally focused on the reduction of risk. For risk modification, when a risk is identified and validated, we identify a control (usually the introduction of a technology, process, procedure or employee training) and implement it to offset the original risk level.

  2. Risk Transfer (Rt) - risk transfer is when an organization identifies ways and means to move a risk off its own plate, and onto another. In the context of business initiatives, there are two traditional ways in which we do this. The first is through the acquisition of insurance, and the second is outsourcing. While this sounds quick and easy, we will talk later about the misconception and potential perils of this approach in our case study section.

  3. Risk Avoidance (Rav) - risk avoidance is quite straight forward, the business elects not to pursue a business activity that would cause the risk to be present. This is kind of like consciously choosing not to eat foods that are bad for you in your diet to avoid congenital heart disease. you know there is a risk, you know why it can happen, and you choose not to participate in activity that would allow that risk to manifest.

  4. Risk Acceptance (Rac) - risk acceptance is the conscious and deliberate acceptance of the identified level of risk, without any other alteration by way of modification or transference. There are some situations in which an organization deems it necessary to knowingly move forward with a business initiative or IT product into the organization's production environment. When doing so, if the level of risk is above the organization's risk tolerance otherwise know as threshold, an organization should consider the acceptance of risk as temporary to realize the business rewards, and in parallel begin efforts

The other key definition to have a level setting on is Residual Risk (Rr). Residual Risk is nothing more than that risk that is present after the introduction of a given risk treatment option.

Talking About Your Rto with Business & Technology Leaders

To set the scene, we're involved in supporting the development of a new IT product (application + IT infrastructure) to support a new business initiative, which will deliver very sensitive personal information to the customer's smart phone or 3/4G enabled mobile devices such as an iPad. A number of risks have been identified and as we prepare for a conversation with the business owner and technology leaders, we prepare an illustration using a basic formula, which is expressed as follows:

R + Rto = Rr

The formula in brief: R = Risk, Rto = risk treatment option, Rr = residual risk. So what the formula is saying, when you have a risk and then introduce a risk treatment option, the risk may be affected resulting in some positive or negative affect, resulting in a change which creates what we refer to as residual risk. Remember, before this you would have already gone through the process of qualifying or quantifying the risk using the standard model of R = V * P * I.


While you may or may not like the options offered in the examples below, please keep in mind this is for illustration purposes only and not specific recommendations on how do deal with this kind of risk. Risks and technology solutions changes each and every day, and what might be thought to be a good solution today, may be found to be flawed or weak in its core foundational structure, and thereby make it a bad option tomorrow. With that as a base understanding and agreement, we then represent four or more risk treatment options, leveraging each of the four categories. These approaches when expressed in an equation look like this:

Risk Modification
R + Rm = Rr

To represent this is practical terms for your conversation it might look like:        

High Risk + Elliptic Curve Cryptography

= Low Risk

Here the original risk was qualified as being in a high category (qualitative methodology used) and it is proposed that we introduce a risk modifier, in this case elliptic curve cryptography to protect the data in transit to the customer's 3/4 G enabled mobile device, and by doing this the data will be better protected and the result is a risk rating reduction from "high" to "low."


Risk Transfer

One important thing to consider up front when considering risk transference as a risk treatment option; while you can manage some of the financial risk, transferring risk will not mitigate damage to your organization's brand, as the media will not leave your company's name out of the press just because you've outsourced or bought insurance.

R + Rt = Rr

To represent this is practical terms for your conversation it might look like:   

High Risk  + Outsourcing = Medium Risk


Here the original risk was identified qualified as being in a high category (qualitative methodology used) and it is proposed that we transfer the risk to a third party, in this case a communications company who can incorporate elliptic curve cryptography which they already have setup and have in their operational environment to meet customers demands. This can be used to support speed to market challenges, thereby avoiding the lengthy time to acquire the knowledge and expertise in-house, build the supporting infrastructure, test and integrate the solution into an IT product. While this is similar to the Risk Modification example above, the variance relates to the mitigation activity by a third party, which you have reduced control over. As a result, you may not perceive the full impact of reduce risk equal between the two options, and afford a low mitigation factor, thereby qualifying risk at a medium level.

An alternative option for risk transference might look like this:

High Risk  + Cyber Security Insurance

= Medium Risk

In this example, we could offset the risk by simply purchasing cyber security insurance to cover any losses if the risk was realized. This is slowly becoming a more and more difficult this to purchase in lieu of implementation of good foundational controls. In some cases the policy may require a baseline set of controls or due diligence in place.

Risk Avoidance
R + Rav = Rr

To represent this is practical terms for your conversation it might look like:  

High Risk  + Abandon The Business Initiative = Low Risk

In this example, the business would have to agree that the risk including consideration of any residual risk of any other risk treatment option exceeds its risk tolerance, and subsequent chooses to abandon the business initiative, which created the risk situation.

Risk Acceptance

R + Rac = Rr

To represent this is practical terms for your conversation it might look like:  

High Risk  + Accept the Risk = High Risk

In this example, the business would acknowledge the high level of risk and make a conscious decision to move forward and be ready to face the consequences for such acceptance. In this scenario as it always is, it would be prudent to cite several examples of impact or consequences such as regulatory scrutiny and sanctions, law suits, damage to brand name, loss or revenue, etc., whatever is real and relevant to your organization.


Case Study

To better illustrate the Risk Treatment Options, we'll now explore a real life case study for each. It is our hope that these case studies will serve to bring the theory written in this article to life for you, much the same as it does when we are teaching our certification classes and cite case studies throughout the classes. I am going to use two settings for these case studies:

  1. The first will be a US-based mortgage company with operations in the US, Canada and Europe. I was on contract as an interim CISO to help them get out of trouble with the SEC by building a comprehensive information security program and hiring a suitable team to sustain it, as well as helping in the restructuring and realignment of its business services and helping to secure the confidence of rating agencies and prospective venture capital investors. This organization had just gone through a SEC investigation due to very weak security that allow one of the partners of this privately held firm, to alter his commission rates directly in the database (without an audit trail) facilitating an unauthorized elevation of his commission based earning in the millions of dollars. This case did receive some public attention when the SEC held a press conference and posted public updates on their case. The partner that was the subject of the investigation in the firm was arrested, criminally charged and incarcerated. As part of the settlement with the SEC, in order for the organization to continue to operate, it had to implementer a strong information security program and provide regular attestations; and

  2. The second is a healthcare company with its own laboratory and diagnostic services. While serving as an interim CISO for this company, it was going through massive growth and market expansion. As like many companies, it was feeling the pain of the constant barrage of new regulations across its global presence.

Risk Modification Case Study

To start this off, I'd have to say that probably 99%+ of risk treatment options employed in program and project-based risk management efforts, fall into the category of a risk modifier.


The company was going to be receiving PII from a customer electronically, in large batch file transfers nightly. The project team determined there were two optional mediums for the transfer (1) a connection through a public switched telecommunication network (PSTN) into one of the company's frame relay network egress points, or (2) over the public Internet. It was determined from an ongoing run cost perspective, connectivity via the public internet would be the preferred communication channel. The principle risk associated with the initiative was unauthorized disclosure of customer PII.


To ensure this risk would not materialize, the project team implemented the recommend internally hosted SFTP solution, as a risk modifier. This allowed the organization to realize a high risk situation to be reduce to a qualified "Low Risk" status, within the acceptable risk tolerance level set by the organization.


Risk Transfer Case Study

The company decided it wanted to start accepting credit cards as an alternative payment option for customers. As part of this business initiative, IT was considering building an application and supporting infrastructure to perform the credit card processing internally. Because the information security posture was not foundational sound and would take some time to get there, to help the business achieve this goal expeditiously I recommended, they strongly consider initially looking at outsourcing the payment processing to a PCI - DSS certified processor for a period of one to three years while their internal security program matured and then perform a feasibility assessment with respect to building the capability in-house, to which they agreed.


The principle risks that were identified were unauthorized disclosure of customer PII and violation of contractual obligations (merchant agreement - non-compliance with PCI - DSS). In this case study, the business made a wise decision and transferred the risk off its own shoulders and onto an outsourced technology partner.


Risk Avoidance Case Study

The company had a large pool of private (external) mortgage brokers who sold mortgages on behalf of the company. Quotes for the brokers were facilitated by calling into a call center, and the company's staff there would enter the data provided by the brokers into their quoting system, and generate a custom quote for the broker's client. In an effort to reduce operating costs, the company wanted to look at options to move the quoting system to the public internet gateway and allow brokers to generate quotes in a self service approach, allowing them to reduce the call center staff by 70% initially. The caveat was that the system could not be vulnerable to excessive quote generation by an individual authorized broker, or access by unauthorized persons. It was offered that the algorithm built into the quoting system's business logic was the reason the company won the majority of the quotes it generated, therefore they would not accept any risk of compromise of this system. They elaborated, if a competitor collaborated with an authorized broker and ran a number of quotes, at a certain point in time, they would eventually be able to decipher the algorithm and change their system to beat the quotes generated by their system.


After performing substantial creative solution options in collaboration with the application development team as well as IT infrastructure, we determined that no matter what we built we could not give 100% assurance that it could not be compromised, a critical decision criteria set by the business client. After presentation of the risk modification options and the residual risk for each, the business elected to abandon the business initiative as their risk tolerance for the compromised of this system was nil.


Risk Acceptance Case Study

The organization was working on a new web-based application development initiative to support a business initiative where it was suggested by the business sponsor that it would generate $1MM of new revenue per day. As part of the initiative an assessment was performed by the Information Security Team, which identified a number of risk issues. In performing the assessment, it was determined that it would be difficult, but not impossible for someone on the Internet to identify the higher risk rated vulnerabilities, however it was also determined that if detected, it would take a high degree of technical expertise to exploit the vulnerability, thereby reducing the probability of compromise.


Unfortunately, Information Security was brought in later on in the development life-cycle and there was significant pressure to go live, as is. A number of risk mitigation options were tabled including the associated cost and the the 90 day plan for closure. The true time was about 30 days, however as many projects do have other competing priorities, a 90 day plan was the official proposal to the business.


When the issues were laid out to the business owner, the business leaders was not comfortable with the impact if the risk was realized, but could not withdraw the revenue projections in the business' financial forecast for the coming quarter. As a result, the business leader elected to accept the qualified risk and move forward into production. He also agreed to fund the 100% of the proposed mitigation plan, provided the full IT proejct team committed to following through and close issues in the acepted 90 day window of risk.

Please reload

Recent Posts

Please reload


Please reload