Mind the gap
No, this isn’t the famous London Underground announcement cautioning passengers of the gap between the train door and station platform. This is a decades-old gap that has existed between GRC (Governance, Risk & Compliance) and security. And whether you choose to call this group GRC, IRM (Integrated Risk Management), or ERM (Enterprise Risk Management), the pains are essentially the same (in addition to the acronyms).
Before we go deeper, I have to call out two articles:
- Bridging the GRC and Security Divide by Charaka Goonatilake (Infosecurity Magazine)
- Bridging the gap between business goals and security requirements by Alex Armson (GRC World Forums)
While plenty has been written on this topic, I highlight these two because it got me thinking about the nature of how these two groups operate – their motivations, priorities, pains, and above all, what separates them for essentially achieving a common goal. In order to get to those answers, we needed to start at the beginning, put our research hats on with our analyst community, and hear from the leaders in the middle of it all1.
The GRC chain of command
This picture is pretty reflective across the board, regardless of an organization’s size. The exception to that rule is when the security team also takes on the burden of representing GRC. It all starts with the C-Suite of course in an effort to focus on growth, risk and people. Typically led by the CEO (Chief Executive Officer), CFO (Chief Financial Officer), and CRO (Chief Risk Officer), this translates to the need for business continuity. In other words, any interruption to the operations of the business will be detrimental. But that’s the easy part…
The GRC committee now gets to take that need for business continuity and translate it in terms of risk. This committee is led by the CIO (Chief Information Officer), CISO (Chief Information Security Officer), with some influence from the CEO. This is a committee that dissects those C-Suite needs into compliance, IP protection and risk reduction. Managing risk is the top priority for this group as a result. For this group to be successful, they must prove the following to the C-Suite:
- COMPLIANCE & POLICY (Prove that the organization is adhering to compliance and policies)
- RISK + or – (Prove that the risk posture has either been reduced or increased)
- TALENT RETENTION (Prove that the organization is retaining and attracting talent)
- ROI (Prove that recommended investments have shown value)
- DATA PROTECTION (Prove that the organization’s IP is safeguarded)
This is where the security team typically led by a CISO and CIO come into the picture. This is a security-driven group where risk mandates translate to data security, GRC alignment, and risk management. And this is the underlying nature of the problem because as we are about to find out, there are often tradeoffs with a security solution and the ability to manage risk. Ultimately, what the security team needs to deliver back to the GRC is as follows:
- ROBUST REPORTING (Empower the GRC with complete and simple reporting)
- RISK MANAGEMENT (Empower the ability to make data-fueled decisions with complete context & visibility)
- WORKFORCE CULTURE (Empower the creation and growth of a security-aware workforce – driven to stay & grow)
- DATA DISCOVERY & VALUE (Empower the ability to uncover risky data and understand the associated value to the business)
- DATA SECURITY (Empower a robust data security strategy focusing on protecting the crown jewels (IP))
The GRC ultimately cares about the output, while the success of security is driven by the input. This is where we need to understand more about the pains these groups are likely to experience.
GRC & security teams relationship status – it’s complicated
First things first, it’s important to recognize that security leaders align to GRC needs first. This is important to recognize because whether it’s the CIO or CISO tasked to make the purchase, they are setting out to also appease GRC mandates. Exceptions do tend to apply though because security (going back to what’s top of mind for them above) will buy the best security product even if it means compromising GRC mandates (60% of security leaders will purchase this way)1.
So quite naturally, these groups are constantly engaged in healthy debate. While most of the time (53%), security will deliver a solution that meets GRC requirements, it’s the other 41% that are failing to deliver a solution in line with initial requirements1. And this is leading to the pain points we typically see across the GRC and security teams.
GRC & security pains are essentially the same – in different languages though
Let’s take a closer look at the world of a GRC committee that isn’t getting what they need. When you unpack areas like risk management, data discovery, complex technology and risk quantification, you’re hearing a cry for help suggesting “I need a better way to prove my risk has gone down.” Correlating this fact with recent Forrester data suggests the confidence levels attributed to GRC technology. When asked to rate the level of satisfaction with their GRC vendor, buyers went from a 51% confidence level in 2018 to a 28% confidence level in 20202. And that percentage is projected to go even lower!
This is where things get very interesting and we get a closer picture of just how aligned these worlds are. When asked the question of how solution providers can provide better security with solutions that meet GRC requirements, we see a clear trend in the need for better output related to managing risk1. This is the GRC asking for better, simple, and more contextual reports. Why? Because they need to prove this to their C-Suite. As you look at the answers toward the bottom of the graph, you get to the need for input. This is typically the pain point for the security team because they can’t drive to those holistic reports without understanding where all the risky data is. And as many organizations quickly understand, there is often a choice between a security product (built around investigations and response) and a proactive risk management tool.
So where’s the disparity? Security tools aren’t built with risk in mind
Let’s take a closer look at the needs of a security team:
- This team needs to align with the C-Suite/GRC to identify priority focus areas and resource requirements
- This team is struggling to operationalize ways to stop data leak with limited time, money and people
- This team wants to prove value with the right security metrics for C-suite
Addressing key blindspot areas is an imperative first step to addressing some of the other GRC needs. GRC-driven CISOs have blindspots when it comes to data regulations and compliance audits. Their pains revolve around the data they care about most residing in untrusted locations:
- Personal storage & devices
- Personal clouds
- Personal email
- Unsanctioned apps (Shadow IT)
- Unmanaged services (3rd Party Risk)
As I often like to state, you CANNOT arrive at a trustworthy report or dashboard unless you have your data blindspots covered. In addition, measuring risk is virtually impossible if you aren’t factoring in the data that is valuable to your organization (but often overlooked). Understanding risk is about knowing in-depth information about files (the data), the vectors (sources/destinations of data exfiltration), and the user (the associated behaviors with risk or carelessness).
Bridging GRC & security – using Insider Risk Management as the connective tissue
There’s a reason Insider Risk Management Solutions have signaled a clear path away from legacy GRC technology. The reality here is that the conversation has vastly shifted to understanding risk posture vs reaction time. Business leaders (who are driving the discussion now) are asking for clear and simple metrics to understand organizational risk. Measuring this risk must begin with a data-centric approach focussed on uncovering data risk within an organization.
And by design, the pillars of the Insider Risk Management approach are all about understanding, measuring, and ultimately managing risk. Fundamental questions to answer here are:
- Identify – Where and when is your organization’s data exposed to Insider Risk?
- Define – What data risk is not acceptable to your organization?
- Prioritize – When is the data your organization cares most about at the greatest risk?
- Automate – How do you best respond to Insider Risk?
- Improve – Is what you’re doing actually working?
Getting to step 5 is imperative in terms of being able to quantify risk and ultimately report it back to the C-Suite. And security practitioners concerned about a tradeoff, fear not! Step 4 in the Insider Risk Management process is all about right-sizing the response measures you need to take. Think of it as leveraging those risk indicators and turning them into actionable insights to mitigate insider risk. Response controls matter, as they should!
The end result? An approach and solution GRC and the CIO/CISO can both shake hands on. If you are ready to start an Insider Risk Management program at your organization, we expand more on these 5 steps to starting Insider Risk Management here.
What does GRC and security synergy look like?
When you take the top-of-mind needs from one department and start thinking about how that translates to another, you need to start thinking about what the reverse deliverable of that might look like. In this case, the GRC needs to prove to the C-Suite (as simply as possible) that they are maintaining compliance, measuring and managing risk, enabling the workforce, proving value (in dollars), and protecting intellectual property.
In order to do this, the security team owes the GRC reports that are simple and translate to C-Suite lingo, a solution that proactively measures and manages risk, empowers the workforce (vs penalizes), focuses on data risk, and provides a robust security platform. This is exactly what Insider Risk Management solutions have set out to do.
And in the process, maybe even help bridge the divide between GRC and security.