GRC Analysts are Starved for Data

I was listening to a recent episode of GRC & Me, "CISO to CISO--Let's Get Real About AI" and a guest said something that really resonated with me. They said, "The GRC & Risk side are starved for data", yet the security operations teams have an overwhelming amount of it.

Resolving the data dependency between SecOps team (left) and GRC team (right)

I currently work for a Security Operations platform and I have been thinking about GRC a lot. We have no shortage of data. We have visibility into assets, identities, vulnerabilities, exposures, logs, threat alerts, threat intelligence, IT context, business context, and much more. Much of this data makes up the evidence needed to assess technical controls. Customers use our tools to create inventories, dashboards, and reports that can be used for internal assessments, or audits. These are often accomplished by use of spreadsheets or where possible custom creation of reports, dashboards within the features of a product that can provide the necessary evidence. This is largely because SecOps platforms have focused on operational security outcomes, not GRC, even though we have the majority of the data needed to assess & prove cyber controls.

To put it bluntly, SecOps platforms don't help customers prove tool value

This is a huge miss, and a key area where vendors can demonstrate the ROI of their solution to customers. Vendors overstate the complexity without understanding the relationship, synergy, and business value.

The need is clear. Organization's must prove their tools implement the appropriate regulatory or compliance controls so that they can continue to do business, or grow their business in new markets.

As business grows, so does the compliance demands

This, coupled with the demand for good security practices from customers & business partners, and the increase of regulations have driven explosive growth in a new wave of GRC vendors, the Automated Compliance or Continuous Control Monitoring (CCM) vendors like Vanta and Drata who have reached $100m in revenue, and ~10k customers in less than 4 years.

Who Owns GRC & How Does it Function Today?

In small to mid sized organizations that are lightly-regulated, security engineers or analysts typically perform both security operations and GRC functions. They spend most of their time in SecOps toolsets like SIEM and Vulnerability Management solutions. Spreadsheets, along with the data from those tools drive the majority of their assurance processes. In contrast, enterprise organizations, or smaller but heavily regulated orgs typically have both a GRC team and SecOps team. In most cases, these teams both report to the CISO.

In nearly all organizations, the CISO is the primary buyer for GRC technology as it relates to IT and cyber functions, and in large enterprises or the most regulated businesses, the responsibility is shared but with clear delegation of GRC domains. The CISO needs to achieve alignment with the Chief Compliance or Risk Officer, who often maintains GRC for financial, ESG, and other G&A domains, and may use separate tools. I've talked to several organizations that have 3, 4 or 5 different GRC tools with overlapping functionality. While there is clear value in consolidation, the difficulty in achieving alignment across multiple departments and areas of ownership stops them short, so they buy another one that meets their teams needs.

CISO's are not just concerned with breaches but also audit failures which can lead to job termination.

Within an organization that has separate teams, the GRC analysts are dependent upon the SecOps team for data: for the purposes of evidence collection. The GRC analysts often don't have access to the SecOps tools and so they have to communicate over chat, e-mail or with an in-person shoulder tap to get what they need. There's constant back and forth and this really slows down both teams. The SecOps teams has constant disruption when there's an upcoming audit, and as a result doesn't achieve delivery of their security roadmap objectives. The GRC team cannot make progress without the direct help of the SecOps team. And then when an audit occurs, add the auditor in the mix and now you're playing telephone between Auditor <-> GRC -> SecOps. It creates a very painful, slow and expensive process for everyone.

For organizations that don't have automated compliance tools, evidence collection is the majority of the expense, in labor, for GRC. It's about 60% of the work in preparing for an audit. The data used for evidence mostly resides within the SecOps team, leaving GRC analysts to unnecessarily be the middle-men. Providing GRC analysts access to the SecOps platform, along with growing their technical skills to understand SecOps tooling and their environment can go a long way in improving productivity. It will reduce the dependency on the SecOps, and improve productivity for both.

But what if your SecOps platform was also your GRC platform? What if your biggest cyber risks automatically populate your Risk Register with Attack Surface, Business Impact, and Vulnerability context? Consolidation is afoot, and it's desperately needed.