How to Create an Enterprise Risk Appetite Statement

April 29, 2021 | By IANS Faculty

Describing and documenting an enterprise’s risk appetite is complicated, because usually it can only be done in qualitative or subjective terms. A common measure of risk appetite can be what the enterprise decides to spend to mitigate risks.

That said, some key principles can be documented and serve as guidance to organizational units as they try to decide how to allocate resources against the enterprise’s key information security risks. This piece explains how to use a risk register to document leadership’s approach to risk and create an effective enterprise risk appetite statement.

Risk Management Programs

This begins with the general topic of risk management, which is key to how the enterprise organizes and runs an information security program. Often, organizations create a risk management program and use that program to help establish where they need to focus their information security resources. Typical risk management programs focus on:

  • Establishing and rank-ordering the information security risks the enterprise confronts. This is often documented in the form of a risk register.
  • Ensuring the risks in the risk register fully reflect input from executive leadership, often including the board of directors. This is usually done by finding out what those leaders are worried about concerning the confidentiality, integrity, and availability (CIA) of data and then translating those worries into information security risks.
  • Ensuring each risk in the risk register has an owner. Someone in the organization must be responsible for ensuring the risk is properly addressed (this is usually, but not always, the risk decision-maker for that risk).

Constructing the Risk Appetite Using the Risk Register

Constructing a risk appetite from the risk register is relatively straightforward. Specifically, the highest risks from the risk register represent the risks the enterprise determined warrant the most attention. And, most importantly, those highest risks already reflect substantive input from the executives, so they are well-aligned with leadership strategies and goals.

A risk appetite can be discerned simply by considering what you plan to do or want to do and measuring it against the highest risks to determine whether it moves the needle on them. Clearly, if the matter being considered makes one or more of the highest risks worse, the executives could be more amenable to spending resources to mitigate that effect.

In looking at this through the optics of a risk appetite statement, an example of a typical statement boils down to:

  • The full list of our information security risks is captured in the risk register.
  • That list already reflects what the enterprise, as executives and the board of directors, are most worried about regarding the CIA of data.
  • That the organization does not agree with any proposed action or activity that makes the worst risks worse, or that moves lower-level risks into the category of the worst risks, unless suitable mitigations are put in place to avoid those effects.

The approach outlined above has one nuance: It does not fully consider the benefits of accepting a risk even if it is high. It simply focuses on addressing all the worst risks in the risk register and avoiding any actions that may exacerbate them.

However, there may be situations when a proposed action has such significant business benefits it is worth pursuing, even in the face of having to accept very high risk in the process. Typically, in every case where a proposed business plan or action engenders very high risk, the business decides to take actions to mitigate that risk to bring it down to tolerable levels. But, that does not necessarily mean that such a situation may never happen. One option is to address it in a risk appetite statement is to add a fourth paragraph. An example of which may read something similar to the following:

"Where a proposed action or activity makes the worst risks worse or elevates a lower-level risk to a high-risk category, and suitable mitigations are unavailable, ineffective, or prohibitively expensive, the impact of accepting the risk shall be measured against the business benefits expected to result from the proposed action or activity. In rare cases, the latter may outweigh the former, but such a judgment shall only be rendered by senior executive leadership."

Inviolate Risks

Finally, the enterprise may have some risks it wishes to declare “inviolate.” That is, the enterprise is unwilling to accept any actions that may worsen them. Examples can include regulatory risks, i.e., risks associated with a regulator citing the enterprise for 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 Payment Card Industry Data Security Standard (PCI-DSS) because that could imperil the use of credit cards for payment. The enterprise should list such risks and could include a final paragraph in the risk appetite statement to cover them:

  • No action that increases the level of risk beyond that captured in the risk register will be accepted for the following risk categories:
  • Violation of requirements specified by law or regulation, including those specified by the Food and Drug Administration (FDA) and under HIPAA.
  • Violation of requirements captured by contract, including PCI-DSS.

Enterprise Risk Register & Leadership

It is critically important the enterprise risk register truly reflect the full input of executive leadership or else the risk appetite statements cited above will have no real effect. Leadership must be fully committed to the risk register, and that can only happen if they have a key hand in its formulation. InfoSec leaders should be able to trace risk register contents back to the areas of concern or worries the executives expressed, or you could run the risk of the contents possibly being dismissed as just an academic exercise.

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.


Find additional resources from our security practitioners.


Learn how IANS can help you and your security team.