Save time with unbiased, independent feedback on vendor solutions.
Watch weekly bite-sized webinars hosted by IANS Faculty.
Information security risks cover any risks that adversely affect the CIA of data. Such risks may be technical in nature (e.g., unpatched or misconfigured systems) or may be caused by management failures (e.g., lack of technical risk ownership, lack of
organizational accountability or failure to find and fix root causes of technical risks). Establishing a consistent and comprehensive risk management methodology based on commonly applied terminology can help information security teams enhance awareness throughout the organization.
Practicing information security requires balancing the risks associated with each of those elements, because they may be in tension. For example, the more an enterprise concentrates on protecting the confidentiality of data, the more likely such data
will be less available for use when needed. Conversely, organizations can emphasize availability by giving a lot of people access to data, but that increases the risk of loss of confidentiality. (Cybersecurity is information security applied to data
in electronic form. Information security is the broader term – it covers data even in paper form.)
Risk involves two elements: the probability of an event, and the consequences if the event were to occur. A very high risk usually means the probability of the event is high and the consequences are severe.
There are three types of information security risks:
Threats and vulnerabilities must also be fully understood.
Usually threats and vulnerabilities go hand in hand. If there is a threat but no vulnerability to exploit, the threat may not be a problem. This may be the case if external hackers are trying to attack, but all your systems are fully patched, leaving
no easy avenue for them to use.
In general, the presence of threats or vulnerabilities increases risks (i.e., increases the probability of an event and/or the consequences if the event were to occur). If both exist, the risk increase is greatest.
Common misconceptions regarding information security risk management include:
A mature information security program recognizes this and requires active risk management, which means it keeps track of the worst risks and how they are being addressed (usually through mitigation). It also keeps track of lesser risks to see if they
have become more serious and warrant action. Additionally, the security program tracks mitigations, because too often, a mitigation is put in place but then later defunded because no adverse event occurred. The act of defunding the mitigation may
increase the risk it mitigated from a tolerable to intolerable level.
Often organizations use a risk management program to help establish where they need to focus their information security resources. A risk management program usually focuses on:
Determining the organization’s risk appetite from the risk register can be useful, and it is relatively straightforward. Specifically, the highest risks from the risk
register represent the risks the enterprise determines warrant the most attention. And, most importantly, those highest risks already reflect substantive input from the executives, so focusing on them is well aligned with what the executives want
to concentrate on. A risk appetite can be discerned by determining whether executive leadership agrees – or not – with the following thought process:
That approach has an important nuance: It does not fully consider the benefits of accepting a risk, even if it were a high risk. It simply focuses on addressing all the worst risks in the risk register and avoiding any actions that may exacerbate them.
There may be situations where a proposed action has such significant business benefits, it is worth pursuing – even if you must accept very high risk in the process.
The way to address it in a risk appetite statement is to add a fourth paragraph which can be similar, but not necessarily limited to the following:
Finally, the enterprise may have some risks it declares “inviolate,” i.e., the enterprise is unwilling to accept any actions that may worsen these risks. Examples can include regulatory risks (i.e., risks associated with a regulator citing
the enterprise for things such as quality of care, protection of patient data under the Health Insurance Portability and Accountability Act – HIPAA), and so on. Another example could be risks associated with violating the PCI Data Security Standard
(PCI-DSS), because that could imperil the use of credit cards for payment.
The enterprise should list such risks and include a final paragraph to cover them:
The enterprise risk register must truly reflect the full input of executive leadership, or the risk appetite statements will have no real effect. Leadership must be fully committed to what the risk register contains, and that can only happen if they have
a key hand in its formulation. You need to be able to trace risk register contents back to the “areas of concern” or “worries” the executives expressed, or the contents can be dismissed as just an academic exercise.
Understanding the scope of information security risks, and the terminology used to describe them, are critical to ensuring such risks are managed properly. The definitions provide the building blocks for identifying and discussing risk. Clearly defining
information security risks allow everyone, from information security professionals and IT professionals to business unit staff and executives to understand and discuss information security risks in a useful way and allow risk owners (typically business
process owners) to decide which risks to accept, reject, transfer or mitigate.
Ultimately, that is what you strive to accomplish: informed decisions by the business leadership on information security risks. Mathematically, the definitions are a
necessary, but not a sufficient, condition for that to happen. The final ingredient for success is a willingness by business leadership to engage in the risk management process – using the definitions to guide the discussion.
Although reasonable efforts will be made to ensure the completeness and accuracy of the information contained in our blog posts, no liability can be accepted by IANS or our Faculty members for the results of any actions taken by individuals or firms in
connection with such information, opinions, or advice.
February 21, 2024
By IANS Research
Learn why cloud IR is critical to security and not just another box to check. Find guidance to get started building a strong cloud IR program.
February 15, 2024
By Alex Sharpe, IANS Faculty
IANS Faculty member Alex Sharpe discusses the risks around AI adoption and provides governance guidance to make your AI launch safe and mitigate risk.
February 13, 2024
By IANS Faculty
Learn how to how to use NIST to modify secure baseline configurations to account for risk and improve security posture.