Here is an excerpt from an article written by Jim Boehm, Nick Curcio, Peter Merrath, Lucy Shenton, and Tobias Stähle for the McKinsey Quarterly, published by McKinsey & Company. To read the complete article, check out others, learn more about the firm, and sign up for email alerts, please click here.

* * *

Even today, “maturity based” approaches to managing cyberrisk are still the norm. These approaches focus on achieving a particular level of maturity by building certain capabilities. To achieve the desired level, for example, an organization might build a security operations center (SOC) to improve the maturity of assessing, monitoring, and responding to potential threats to enterprise information systems and applications. Or it might implement multifactor authentication (MFA) across the estate to improve maturity of access control.

A maturity-based approach can still be helpful in some situations: for example, to get a program up and running from scratch at an enterprise that is so far behind it has to “build everything.” For institutions that have progressed even a step beyond that, however, a maturity-based approach is inadequate. It can never be more than a proxy for actually measuring, managing, and reducing enterprise risk.

A further issue is that maturity-based programs, as they grow organically, tend to stimulate unmanageable growth of control and oversight. In monitoring, for example, a maturity-based program will tend to run rampant, aspiring to “monitor everything.” Before long, the number of applications queued to be monitored across the enterprise will outstrip the capacity of analysts to monitor them, and the installation of monitors will bog down application-development teams. The reality is that some applications represent more serious vulnerabilities—and therefore greater potential for risk—than others. To focus directly on risk reduction, organizations need to figure out how to move from a stance of monitoring everything to one in which particular applications with high risk potential are monitored in particular ways.

Another issue related to the monitor-everything stance is inefficient spending. Controls grow year after year as program planning for cybersecurity continues to demand more spending for more controls. But is enterprise risk being reduced? Often the right answers lie elsewhere: for example, the best return on investment in enterprise-risk reduction is often in employee awareness and training. Yet a maturity-based model does not call for the organization to gather enough information to know that it should divert the funding needed for this from additional application monitoring. Spending on both will be expected, though the one effort (awareness and training) may have a disproportionate impact on enterprise-risk reduction relative to the other.

If the objective is to reduce enterprise risk, then the efforts with the best return on investment in risk reduction should draw the most resources. This approach holds true across the full control landscape, not only for monitoring but also for privileged-access management, data-loss prevention, and so forth. All of these capabilities reduce risk somewhat and somehow, but most companies are unable to determine exactly how and by how much.

The final (and most practical) drawback of maturity-based programs is that they can create paralyzing implementation gridlock. The few teams or team members capable of performing the hands-on implementation work for the many controls needed become overloaded with demand. Their highly valuable attention is split across too many efforts. The frequent result is that no project is ever fully implemented and program dashboards show perpetual “yellow” status for the full suite of cyber initiatives.

The truth is that in today’s hyperconnected world, maturity-based cybersecurity programs are no longer adequate for combatting cyberrisks. A more strategic, risk-based approach is imperative for effective and efficient risk management (Please see Exhibit 2).

Reducing risk to target appetite at less cost

The risk-based approach does two critical things at once. First, it designates risk reduction as the primary goal. This enables the organization to prioritize investment—including in implementation-related problem solving—based squarely on a cyber program’s effectiveness in reducing risk. Second, the program distills top management’s risk-reduction targets into precise, pragmatic implementation programs with clear alignment from the board to the front line. Following the risk-based approach, a company will no longer “build the control everywhere”; rather, the focus will be on building the appropriate controls for the worst vulnerabilities, to defeat the most significant threats—those that target the business’s most critical areas. The approach allows for both strategic and pragmatic activities to reduce cyberrisks (Please see Exhibit 3).

Companies have used the risk-based approach to effectively reduce risk and reach their target risk appetite at significantly less cost. For example, by simply reordering the security initiatives in its backlog according to the risk-based approach, one company increased its projected risk reduction 7.5 times above the original program at no added cost. Another company discovered that it had massively overinvested in controlling new software-development capabilities as part of an agile transformation. The excess spending was deemed necessary to fulfill a promise to the board to reach a certain level of maturity that was, in the end, arbitrary.

Using the risk-based approach, the company scaled back controls and spending in areas where desired digital capabilities were being heavily controlled for no risk-reducing reason. A particular region of success with the risk-based approach has been Latin America, where a number of companies have used it to leapfrog a generation of maturity-based thinking (and spending). Instead of recapitulating past inefficiencies, these companies are able to build exactly what they need to reduce risk in the most important areas, right from the start of their cybersecurity programs.

Cyber attackers are growing in number and strength, constantly developing destructive new stratagems. The organizations they are targeting must respond urgently, but also seek to reduce risk smartly, in a world of limited resources.

A transformation in sequential actions

Companies adopting the risk-based approach and transforming their “run” and “change” activities accordingly inevitably face the crucible of how to move from maturity-based to risk-based cybersecurity. From the experience of several leading institutions, a set of best-practice actions has emerged as the fastest path to achieving this transformation. These eight actions taken roughly in sequence will align the organization toward the new approach and enable the appropriate efforts to reduce enterprise risk.

Fully embed cybersecurity in the enterprise-risk-management framework.
Define the sources of enterprise value across teams, processes, and technologies.

Understand the organization’s enterprise-wide vulnerabilities—among people, processes, and technology—internally and for third parties.
Understand the relevant “threat actors,” their capabilities, and their intent.
Link the controls in “run” activities and “change” programs to the vulnerabilities that they address and determine what new efforts are needed.

Map the enterprise risks from the enterprise-risk-management framework, accounting for the threat actors and their capabilities, the enterprise vulnerabilities they seek to exploit, and the security controls of the organization’s cybersecurity run activities and change program.

Plot risks against the enterprise-risk appetite; report on how cyber efforts have reduced enterprise risk.

Monitor risks and cyber efforts against risk appetite, key cyberrisk indicators (KRIs), and key performance indicators (KPIs).

[Here are the first two of eight approaches.]

1. Fully embed cybersecurity in the enterprise-risk-management framework

A risk-based cyber program must be fully embedded in the enterprise-risk-management framework. The framework should not be used as a general guideline, but rather as the organizing principle. In other words, the risks the enterprise faces in the digital domain should be analyzed and categorized into a cyberrisk framework. This approach demystifies cyberrisk management and roots it in the language, structure, and expectations of enterprise-risk management. Once cyberrisk is understood more clearly as business risk that happens in the digital domain, the organization will be rightly oriented to begin implementing the risk-based approach.

2. Define the sources of enterprise value

An organization’s most valuable business work flows often generate its most significant risks. It is therefore of prime importance to identify these work flows and the risks to which they are susceptible. For instance, in financial services, a loan process is part of a value-creating work flow; it is also vulnerable to data leakage, an enterprise risk. A payment process likewise creates value but is susceptible to fraud, another enterprise risk. To understand enterprise risks, organizations need to think about the potential impact on their sources of value.

Identifying the sources of value is a fairly straightforward exercise, since business owners will have already identified the risks to their business. Cybersecurity professionals should ask the businesses about the processes they regard as valuable and the risks that they most worry about. Making this connection between the cybersecurity team and the businesses is a highly valuable step in itself. It motivates the businesses to care more deeply about security, appreciating the bottom-line impact of a recommended control. The approach is far more compelling than the maturity-based approach, in which the cybersecurity function peremptorily informs the business that it is implementing a control “to achieve a maturity of 3.0.”

The constituents of each process can be defined—relevant teams, critical information assets (“crown jewels”), the third parties that interact with the process, and the technology components on which it runs—and the vulnerabilities to those constituent parts can be specified.

* * *