This article is a collaborative effort by James Kaplan, Charlie Lewis, Lucy Shenton, Daniel Wallance, and Zoe Zwiebelmann, representing views from McKinsey’s Cybersecurity Practice.
Risk-based management measures risk against an organization’s risk appetite to determine where further technology and cyber controls are needed. The goal is to reduce the remaining technology and cyber risks to a point the business can tolerate. To succeed, it must have clear, measurable statements on its technology risk and cyber risk appetite, defined in business terms, with clear ownership.
In addition, regulators are now pressuring organizations to better articulate their risk appetite. A clear risk appetite statement is the cornerstone of successful risk-based management. Major regulators—for instance, the Office of the Comptroller of the Currency—have recently issued findings to major US banks about how to define and structure their technology risk and cyber risk appetites. It is believed that this trend will also be seen in Europe, as the European Banking Authority has already set out guidelines for managing cyber risk and continues to see it as an emerging concern. However, though regulators have described the characteristics of an optimal cyber risk appetite framework, there is no consistent picture of what the risk appetite should actually be or how to implement it across an organization.
Because of this lack of direction, financial institutions often struggle to understand how they should build a risk appetite framework that meets regulatory expectations and provides real value as a basis for decisions.
Many organizations find that they already have components of an optimal risk appetite framework (such as thresholds for key risk indicators) or overarching, enterprise-wide statements that present the overall appetite for risk as high, medium, or low. These organizations, however, struggle to measure their risk appetite against real-world business events and to agree on risk appetite–based thresholds for metrics.
For example, it is easy for organizations to say that they have a low appetite for cyber risk. But debate begins when they ask what constitutes such a low appetite in terms of control implementation and when the first and second lines of defense ask whether residual risk falls within or outside of that overall appetite. To manage technology risk and cyber risk effectively, organizations must lay out an objective risk appetite framework that supports business decisions on risk and uses objective metrics and reporting to achieve alignment with the risk appetite.
Financial organizations need a systematic, impact-driven structure that communicates their technology risk and cyber risk appetites, from the board level down to control objectives and metric thresholds. Determining the risk appetite should be a team activity that takes into account the needs of various stakeholders, including the board, the business, the technology function, and the second line.
Risk appetite frameworks, structured against the technology risk and cyber risk taxonomies, should cascade from the risk taxonomy to control objectives and support metric thresholds.
The technology risk and cyber risk taxonomies should encompass all current and emerging technology risks and cyber risks. Organizations commonly structure taxonomies according to the possibility that different impacts of technology risk or cyber risk will be realized. For example, the tech and cyber taxonomy may be structured by availability loss of systems, confidentiality compromise, data integrity compromise, project management risks, or any combination of those possibilities.
Once the key risks are understood, organizations should define their appetite for them. Such an enterprise risk appetite statement should not only be business oriented and quantitative but also correspond to the technology risk and cyber risk taxonomies. In addition, these quantitative statements should be stratified by importance to the business. For example, enterprise risk appetite statements for the unavailability of systems might be “no more than X minutes of unplanned downtime for systems associated with critical business services” and “no more than Y minutes of unplanned downtime for systems associated with noncritical business services.”