Working More Effectively With Enterprise Risk Management
Eric Bonnell is the SVP, Manager of Technology and Asset Risk at Atlantic Union Bank, a $17.9B bank located in Richmond, VA. Eric is part of the Enterprise Risk Management function at the second line of defense. His team is responsible for Risk Programs for Technology, Facilities, Corporate Security, and Vendor Management, as well as the Enterprise Business Resiliency Programs (Crisis Management, Incident Response, and Business Continuity Management)
How can an Information Security professional work more closely with the Enterprise Risk Management team? My answer is simple. Learn to speak the same language!
As I write this, I am thinking of a member of my staff that I am growing into a Technology Risk role. I am working with him on this: the trick to understanding risk from an enterprise perspective is to speak the same language as the business. Relationship building is your key. Understanding your place in the Enterprise Risk Management ecosystem helps.
Is This How You Probably Perceive Risk?
Information Security professionals use frameworks for threats, vulnerabilities, and controls to address risk. As these frameworks are technical in nature, they are usually very prescriptive, and control-centric. After all, when you are looking to prevent the threat of protecting the data on your network, most technology controls are cut and dry: encrypt wherever possible, provide strict segmentation for the critical systems your network, closely control file access, and put in a process to monitor and alert for threat events. To understand this, refer to the closest technical framework: NIST, FFIEC, PCI, etc. All of these are control-centric because the issues in technology are, for the most part, static and predictable once understood.
“The trick to understanding risk from an enterprise perspective is to speak the same language as the business”
How Most of Enterprise Risk Perceives Risk
The processes on the business side are not as predictable. In fact, business processes are fluid and always changing, as the business is always growing, adapting, moving, reorganizing, and, well, changing. This is the nature of business, as its main function is to bend toward opportunity and to be profitable. As a result, Operational Risk Management professional focus on the impacts of processes and process changes, the likelihood that bad things will happen, and the opportunities available to mitigate risk (which means to reduce likelihood of bad events and the impact that those bad events would have if they do happen). Operational Risk generally leverages a qualitative analysis to provide a view into risk, though will use quantitative metrics wherever possible to corroborate their conclusions. Credit Risk, Market Risk, and Liquidity Risk professionals view risk in almost purely quantitative metrics, as these disciplines are the most mature risk management processes with the most direct relationship
to mathematics. Model Risk is a hybrid; involving risk relating to both data and business rules, it uses both quantitative and qualitative analysis equally. Regulatory Risk focuses on the risk of not complying with specific requirements and is more control-centric in nature; this is closest to how you probably view risk as an Information Security professional.
Reputational Risk applies to all of these risk categories in some way or another. Some companies look at Reputational Risk as a separate discipline while others aggregate Reputational Risk into its own category.
How To Speak Business Risk
A common taxonomy for assessing and managing is in order. Here are the basics:
● The product of Likelihood and Impact with no Controls is the Inherent Risk score.
● The product of Likelihood and Impact, as recalculated given the effectiveness of existing Controls, is the Residual Risk score.
● You can do one or more of the following actions to manage the residual risk:
a. Mitigate Risk - adding more or strengthening existing controls to be more effective against risk
b. Accept Risk - live with the existing level residual risk with a business
justification and proper approvals (often used to address short-term risk)
c. Transfer Risk – purchase adequate insurance to protect against excessive business impact due to an actual negative event occurrence
d. Avoid Risk – remove the business process, system, or resource that causes the risk (e.g., retire a business product, legacy application, or vendor relationship, etc.)
You may be surprised to find that those dealing with these different risk categories are struggling as much as you are to understand each other in a common way.
Your best bet to finding common ground is to speak the language of these business risk categories. While you may be used to a more security-centric view of risk (threats and vulnerabilities counteracted by controls), try to view risk as a mathematical product between likelihood and impact, lessened by varying degrees of controls. A common taxonomy will help the business understand how you fit into their world and increase understanding of the risks you are trying to mitigate. You do not need to abandon your technical frameworks to make this happen; instead, use these to build your control sets and find a standard way to measure the effectiveness of these controls. Normalizing your risk assessments in this way will also help you to leverage your Integrated Risk Management reporting system more effectively in order to be included in the enterprise aggregated view of risk.