Enterprise security risk management (ESRM) has been a topic of increasing interest for security managers over the past few years, and ASIS International has identified it as a strategic focus. But a review of the literature, beginning with the 2010 CSO roundtable paper on ESRM, raises two issues that could make ESRM implementation difficult.
First, the initial papers on ESRM appeared to encourage security to fill the gap left by traditional enterprise risk management (ERM) systems, which often focused on financial and market risk exclusively. Although an effective ERM system should incorporate all risks, having security fill these gaps via the ESRM system would quickly overwhelm the chief security officer (CSO). Appealing though it might be to have “Head of Risk Management” appended to one’s job title, “I’m not busy” is NOT a common refrain among security managers. In many organizations, managing the risks across all security functions—that is, physical, cyber, and information—is already an enormous task, so operational and reputational risk should remain elsewhere.
The idea that all responsibility for risk should fall to security seems to have tapered off somewhat since the first few papers on ESRM, but security managers will still be better served if they ensure that ESRM focuses on the “S” in the title, security.
Second, there is often a tendency towards complexity and granularity in ESRM systems where simplicity is more appropriate. Risk management is an area where it is easy to quickly become bogged down in detail, and the drive for more and better data can stymie the process. If we consider the ISO definition of risk as “the effect of uncertainty on objectives” (ISO 73), trying to become more and more specific overlooks the baked-in nature of uncertainty.
Moreover, when quality data is not available, as is often the case with security issues, trying to analyze risk at a more and more granular level can produce a less-accurate assessment. Granularity and massive amounts of information can be used in Big Data systems, but most organizations don’t produce enough security-specific data for that kind of analysis. Even with large amounts of data this can still go wrong. As an example, tinkering at the micro level while assessing the risks in the U.S. mortgage bond markets back in 2008 gave the impression that things were fine, even though all the warning signs were visible (but largely ignored) at the macro level.
Moving to ESRM with a KISS Approach
Although more complicated than a purely security-centric approach, a risk-led approach is an effective way to approach security. This directly links security activities to the organization’s overall objectives and goals, integrating security risk with the organization’s overall ERM system. This approach also helps bridge the gap with contingency planning, business continuity management, and crisis management, and it significantly improves response and post-event recovery. Moreover, ESRM helps the elements within the security function coordinate more effectively.
Finally, a robust and effective risk management system also removes a great deal of subjectivity from planning and decision making, which enhances organizational efficiency. In many ways, risk is the common language of business and the sooner we all share that language, the more effective we will be. Investing time and effort into the ESRM system and moving towards a risk-led approach does pay off in the long run.
So there are real benefits in implementing an ESRM system but these two issues—pushing security to take on a wider risk management role and a tendency towards complexity—could make implementation seem an impossible task and one that many CSOs would find daunting, deterring them from taking this course. However, an ESRM system does not have to be overly complex, nor something that disrupts day-to-day operations. In fact, for most security managers, a KISS approach—keep it simple, security folks—is the best way to tackle ESRM. This does not suggest that there aren’t challenges in implementing an ESRM system or that additional work and change won’t be necessary. But a KISS approach facilitates implementation and makes the ESRM system much more effective.
But how can we do this and keep things simple?
Four basic principles can assist with the implementation of a simple yet effective ESRM program: use a standard approach, start speaking risk, become objectives-led, and accept uncertainty.
Use a standard approach to risk management, not one that is security-specific.
Each business or function will want a solution that is tailored to its needs, but this causes inefficiency when working in a cross-functional environment. Imagine for one second what would happen if every department used its own accounting processes: mayhem, and probably lawsuits, would ensue. This problem could even arise within the security function itself if cybersecurity tried to use one approach to risk management, and asset protection used a different one.
A robust, comprehensive risk management system will allow room for adjustment at the functional level while still applying a standard approach that can be used across the entire organization. So, rather than finding a security-specific definition for risk, or processes tailored to the department, start with a basic approach to risk management. Ideally, this would mean adopting your organization’s existing system and processes that you can adapt to fit the needs of the security team. In some instances, you might need to start from scratch—in that case I would recommend going back to basic, first principles which can then be scaled up to integrate with a future ERM system.
Learn to speak risk.
Risk provides organizations with a common language and mindset that can be applied across departments and functions to help with discussions and decision making. Even within the security function itself, having cyber, information, and physical security teams use a common language will make life easier for the CSO. “Speaking risk” can be more complicated than it might first appear, because terms can be applied differently and there are some complex influences that affect how we perceive risks. At first, there will be a need for regular clarification on how terms are being used until the correct usage becomes commonplace. Adapting existing materials to suit the new lexicon will also take time, but the ERM system should define the key terms and concepts and these should be adopted as early in the ESRM process as possible.
Become objectives-led, rather than assets-focused.
Using a risk vocabulary doesn’t just help with discussions: it also helps change mind-sets and perspectives. If something akin to the ISO definition—that risk is “the effect of uncertainty on objectives”—is used, the focus on objectives should become second nature, which has multiple benefits:
- It allows individuals and teams to practice what the U.S. military calls disciplined initiative: leaders at all levels understand the commander’s (in this case the organization’s) overall intent and can shape their activities to support that without step-by-step direction.
- Being objectives-led moves from a reactive to a proactive mindset. Instead of thinking, “x has happened, so we need to do y,” organizations can consider “what effect could x have on our objectives?” and act accordingly.
- Security can better support the organization when mitigation measures and contingency plans are developed with the organization’s top-level objective in mind. This is best summed up by something an embassy regional security officer said while discussing security in a higher-risk country: “The best way to keep everyone safe here is to keep them inside [the embassy] but that’s not my job. My job is to help them get out there and do their jobs as safely as possible.”
Becoming objectives-led is not only applicable in day-to-day “peacetime.” It is extremely important during the response to an event where a proactive, objectives-led stance will significantly improve the organization’s chance of survival.
Accept uncertainty and avoid over-specification.
We are awash with data, email alerts, and warnings that swamp us with information. That can quickly lead to analysis paralysis: if we are presented with every possible permutation, possibility, and outcome for a situation, how can we effectively decide what to do next? From an ESRM perspective, avoiding this paralysis requires two things.
First, the system should accept uncertainty and avoid trying to become too specific. Ultimately risk management is a decision-making tool that helps put risks into a comparative order, but it doesn’t measure risk per se. Trying to measure risk to one or two decimal places is extremely difficult in all but the most well-documented, highly regular, technical systems. If you think about it, an asset assessment that gives you a loss expressed down to single dollars should be taking pocket change into account. However, day-to-day security management has neither that kind of stability nor the data, and there are simply too many variables for that kind of accuracy. The ESRM system should work in broader strokes than the CSO might initially be comfortable with, but that will help remove some of the uncertainty and simplify the assessment and reporting process while still producing useable results.
Second, information overload is not just something we can experience, it is also something to which we can contribute. Security should therefore avoid swamping the overall ERM system with too much data. Too much information from each department will overwhelm the ERM system and cause paralysis at the organizational level. The risk management system should specify where a departmental risk is severe enough to become an organizational risk and needs elevating, and this should be mirrored in the ESRM system. Again, using broad strokes will also help get the point across as to which risks are a priority without having to overwhelm the senior leadership with every possible security concern.
In both cases, technology can make things more efficient, but if care isn’t taken when designing a technical solution, managing the risk management system can become a major task in its own right. As mentioned earlier, security managers are not looking for more work to fill their time, so whatever systems are used must be robust, simple, and effective. Even with IT, KISS is still important.
ESRM is a welcome initiative that will embed security management more thoroughly into organizations, add much-needed objectivity to decision making, and improve resilience. However, a tendency towards making ESRM too specialized, or trying to have the CSO lead too much of the overall risk activity, will likely be counterproductive. However, taking a KISS approach will help achieve the overall aim of integrating security into the broader ERM framework while also avoiding these pitfalls. Even within the security function itself, a risk-led approach will provide much-needed coordination between security functions because it gives CSOs and their teams a common language. Although a highly complex, granular system may seem attractive, taking a KISS approach is going to be more straightforward to implement when CSOs and their teams are already working close to capacity. Once the basic ESRM system is in place, the tinkering can begin.
Whatever specific approach is taken, adhering to the four principles outlined above—use a standard approach, start speaking risk, become objectives-led, and accept uncertainty – will help implement an ESRM system that allows the organization to better understand security risks, integrate these into the wider ERM program, and ensure that the security team takes a risk-led approach.
This article was published as “Less is More: A KISS Approach to ESRM” in ASIS Security Management Magazine in September 2017 and is (C) ASIS. It appears here with permission.
Use this link to see the magazine version and other ESRM articles.