I used to write “ESRM vs ERM”, but as this ESRM conversation continues to mature, I see I was wrong. It’s faulty logic to think that there is a binary choice. It is also not accurate to say ESRM and ERM are the same thing and you only need one or the other. They are not the same concept and you don’t need to choose one or the other. In every way they’re complimentary to each other. They share similar concepts. They are built from the same risk principles as any risk program inherently is built. There is still confusion regarding the two, so let’s clear up the faulty logic thinking they are the same.
First, let’s start with the similarities. ESRM, like ERM is a risk based practice. There are many risk practices: safety, insurance, financial risk management, and business continuity to name a few. They all use risk principles in their discipline that is then applied to topics, or a scope of responsibility to be implemented. The risk principles used are fairly static. Risk principles come in various forms and use different terms, but the risk paradigm is static. So, in a way, they’re very similar; definitely of the same family, yet more like cousins. Either way, you know what you can’t do…you can’t marry the two.
What makes them different is their focus and implementation. I’ll start with ERM. ERM, using risk principles, applies the practice to any risk across the enterprise: capitalization, human capital, regulatory, all security risks, etc. The ERM practitioner will use the risk principles to guide their practice. The risk principles in practice doesn’t describe the scope to be focused on, it simply is the guiding principles the ERM practitioner will work within. The focus on enterprise risks defines the ERM designation.
The difference – ESRM defines the scope of focus on security risks and uses risk principles to define and guide the security practitioner in managing the security scope of risks. Let’s break this down into two parts. First, ESRM is narrowly scoped and focused on security risks. It doesn’t matter if you’re focused on physical security, cyber, information, terror, or workplace violence. It also doesn’t matter what discipline you’re practicing or at what level; a CSO, or line employee installing cameras or assigning online credentials. It defines scope in broad terms and can be as narrowed as needed so long as the scope remains within the realm of security risks.
Secondly, ESRM defines the security practice through globally accepted risk principles, not unlike ERM. Similar to how the risk principles would define the role of the ERM practitioner, the risk principles define the role of the security practitioner. There are many different tasks an ERM practitioner engages in that a security practitioner wouldn’t and vise-versa. For example, the actual implementation of any security program or the nuances of a program: conducting an investigation, implementing an identity management system, or assessing a workplace violence threat. It would be silly to compare the two by task, so we’re not going there. Clearly the role of an ERM practitioner and security practitioner is different. You can see though, that a large part of ESRM is about how any security practitioner would be guided through their practice using risk principles.
As a recap: ERM defines the scope and how to practice. ESRM defines the scope and how to practice. The scope and practice in each are different in many ways. The differences make them…well, different.
They are absolutely complimentary to each other. Enterprises need both.
I had a point of clarity around the similarities and differences of ESRM and ERM in my experience as a CSO that I found very satisfying. I was working with our ERM lead and we were working through all the main risks and risk owners: legal, finance, technology, security, operations, etc. He kept trying to find a placeholder for us to own the security risks, because of course we managed security risks, amongst other risks, all over the enterprise. At the point of this discussion, our security group was thoroughly practicing ESRM and it was clear we didn’t own any of the risks. Yet it seemed to the ERM group that we needed to own something, like security risks, because we were managing the entire security program; all the physical security, cybersecurity governance risks, business continuity, investigations, fraud management, etc. Our role wasn’t to own the risks. We were however, managing the security risks, using ESRM principles that defined our scope and discipline – the asset owners and stakeholders owned the risks.
At the end of the day, the ERM group and our security group had distinctly different roles and along the way they learned what our role actually was. It was to manage the asset owners and stakeholders through their security risks, being the subject matter experts along the way. We practiced our disciplines in many of the same ways, but we were very different in our scope and actual day to day practice. I’d say we were cousins.
Applying risk management to security is certainly not new or novel; in fact, it’s kind of old hat to think it’s new. We’ve just been stuck in a rut. Some of that rut is not finding distinctions with ESRM and ERM. I make no excuses – I used to write ESRM vs ERM. I was wrong. Happily, this conversation has matured and we’re making needed progress developing our security discipline. As discussed in prior blogs, it’s going to be necessary that we continually challenge our thoughts on how we’ve perceived ourselves and our role in the past. One final thought worth repeating…ESRM and ERM are similar in name, and of the same family, but there are significant differences. So, let’s keep some separation between the two.
I look forward to your comments and continuing the conversation!