Why Use an RLA?
We refer to these as “agreements” because they codify the shared awareness, negotiation, and decisions between the organization’s business users and its IT infrastructure providers; with respect to the balance of benefits, costs, and risks in any aspect of the business.
The RLA is a formal business record, persisting the context and tradeoffs of critical business decisions, across changes in the organization, until such time as any decision needs to be revisited.
Each RLA includes discussion of 6 key topics:
- the organization’s Risk Tolerance,
- Risk Scenarios,
- Inherent Risk,
- Recommended Controls to mitigate risk,
- Risk Mitigation Decisions, and
- remaining Residual Risk that is either accepted, transferred, or avoided.
Risk Tolerance ("Appetite")
The U.K.’s Institute of Risk Management defines Risk Tolerance or Appetite as “the amount and type of risk that an organization is willing to take in order to meet their strategic objectives”.
A qualitative approach to characterizing an organization’s Risk Tolerance/Appetite might use a subjective spectrum from
“Risk Averse – to Risk Neutral – to Risk Seeking”.
A quantitative approach to characterizing an organization’s Risk Tolerance/Appetite might use an objective, numerical threshold to describe specific levels of acceptable loss (e.g., % of revenue lost).
Each Phenomenati RLA begins by documenting the organization’s current benchmark for Risk Tolerance.
Risk Scenarios
Any serious discussion about “risk” must transform abstract concepts into concrete expressions using tools such as “risk scenarios”.
A “risk scenario” begins with identifying a specific Threat that is directly relevant to the Assets of the organization. This should include the Likelihood or probability of the Threat materializing.
- e.g., a threat actor attempts to steal customer records, 4-5 times per year.
Next, across the organization, any Vulnerabilities relevant to that Threat are identified.
- e.g., use of single-factor authentication [weak passwords] on accounts with bulk access to customer records.
Finally, the potential Impact of the Threat exploiting the Vulnerability is characterized, either qualitatively or quantitatively.
- e.g., a possible $xM in regulatory fines, a potential 20% loss of customers, and potential 35% drop in revenues due to reputation damage.
Inherent Risk
Inherent Risk is traditionally thought of as the “untreated” risk in a process or activity. Meaning nothing has been done to either reduce the “likelihood”, or mitigate the “impact”, of potential threats.
In his book “Measuring and Managing Information Risk: A FAIR Approach”, author Jack Jones (creator of the FAIR model) provides a more practical definition of “inherent risk” as… “the current risk level given the existing set of controls”.
In these RLAs, the Inherent Risk is captured as the collection of potential Impacts from the Risk Scenarios identified.
Effective methods for prioritizing and communicating the set of “Inherent Risks” to an organization include:
- a simple “Risk Matrix” diagram (qualitative), and/or
- a tabular “Risk Register” (quantitative).
Recommended Controls
For the highest priority Risk Scenarios, Controls (also called countermeasures) which may directly impact each scenario are enumerated and assessed for practicality.
Some controls will attempt to reduce the Likelihood of a specific Threat exploiting a Vulnerability. e.g., use of 2FA, or 3FA for privileged accounts
Some controls will attempt to reduce the Impact of a possible compromise. e.g., obfuscation or tokenization of customer record information
Each Control identified is assessed for practicality based upon anticipated Benefits, related Costs, and any additional Risks it may introduce. e.g., self-inflicted service outages
Phenomenati’s RLA captures the current inventory of Recommended Controls using a simple table, often simply additional columns in the Risk Register described earlier.
Risk Mitigation Decisions
Within the constraints of both Budget and Risk Tolerance, the Controls with the most optimal Benefit/Cost/Risk balance are selected, recommended for implementation, and either approved/rejected by senior leadership.
The resulting investment decisions are the foundation for the organization’s Information Security Program.
Effective methods for communicating the set of “Risk Mitigation” decisions include updates to the original:
- “Risk Matrix” diagram (qualitative), and/or
- “Risk Register” (quantitative).
Residual Risk
Finally, any “Residual Risk” (those Risks remaining unaddressed) is clearly documented, often using the same Risk Register described above.
The Residual Risk is then compared to the overall Risk Tolerance of the organization.
Where Residual Risk still exceeds the organization’s Risk Tolerance, additional Risk Mitigations may be considered.
Where Residual Risk remains, each Risk should be clearly documented as either:
- accepted as being within Risk Tolerance,
- transferred to an external party (e.g., via an insurance policy), or
- avoided all together by ceasing the threatened business process or activity.