A CISO’s Take: How to Build (and Learn From) Your First GRC Program

Building a Governance, Risk, and Compliance (GRC) program from the ground up is no small feat—but it’s one that Drata’s CISO, Matt Hillary, knows well. In this Q&A, Matt reflects on the early days of his security career, the lessons he learned while building his first GRC program, and how the landscape of security and compliance has evolved over the years. Whether you're just starting out or refining a mature program, Matt’s insights offer practical advice and a candid look at the realities of getting GRC right.

Q: What was the world of security and GRC like when you first started out vs now?

A:  You know, I started as a compliance person. I originally started my career at Ernst and Young in the Seattle area and worked with a number of SaaS companies up there. I worked on both sides of the house—internally helping organizations prepare for audits and achieve compliance (like ISO 27001, which was new at the time) and externally as an auditor conducting assessments like the predecessor to SOC reports, SAS 70.

Q: What was your thought process as you helped these companies achieve compliance?

A:  When I was at Ernst and Young, I longed for the opportunity to own my own program from end to end. We did a lot of consulting where we would deliver a report and they chose whether or not to act upon it. Then we’d move on to the next one.

 I remember feeling like, man, I'd like to be a part of an organization where I could receive one of those reports or do one of those assessments and help build a program myself, shepherding and maturing it over time.

Q: How did you make that happen?

A:  An opportunity came up where I was asked to join a large cloud service provider that was new at the time to help start their compliance program from the ground up.

 That's where the fun really began. I took ownership and started to understand what we needed to do as an organization to really define compliance for the cloud.  The thing I love to do is to distill the requirements from these frameworks into two different buckets. One is like, Hey, can you help me understand the risks behind these controls, like why they exist in the first place? And the second is, can I distill this control down into understandable language that any person internally in the organization can understand so they  can become compliant and stay compliant over time?

Q: What kind of impact did that approach have?

A:  People enjoyed that because sometimes compliance and security is seen as a very convoluted, hard to understand space. And I felt like, hey, if you really know something, you can take that and distill it down so that any part of an organization can understand and comply with that.

 It helped shape the controls and made it very clear what they meant and where they applied. From there, we continued to grow and iterate and add additional control frameworks. We started with SAS 70, then moved that over to SOC 2, SOC 1, ISO 27001, PCI, HIPAA, and eventually federal authorization as this was before FedRAMP.

 It was fun to see an organization go from the very grassroots beginnings and pioneering all the way through to a comprehensive GRC program and even building a whole service to help display their reports for customers.

Q: What surprised you about that process?

A: There were a few things.  I was surprised by the amount of manual effort that we needed to do, but at the time, we didn't really have a lot of systems and capabilities to automate any of the efforts.  The manual efforts were pretty intense.

The other thing that surprised me was  the lack of engineering resources that were needed to build these automated checks, especially in an organization where everything was built in house.

 They had built so many custom in-house capabilities from scratch, so there weren’t very many programmatic interfaces between some of these SaaS providers to be able to build something like Drata at the time.  It was largely still the original way of doing GRC.

Another surprise was the lack of standard understanding of the purpose of some of these reports at the time. SOC 1, 2, and 3 were new to the industry, and many organizations didn't know how to use it or understand what it was meant for. It really was fun educating organizations about how we were keeping them and their customers secure.

Q:  What would you say was the first big mistake you made, and what did it teach you?

A:  Oh man, a couple come to mind.  I'm one that likes to jump right into the weeds and get started, get my hands dirty, just start figuring stuff out. And in many ways that's a good way to get an understanding of where the company's at, but  it didn't allow me to take a step back after gathering that knowledge to then kind of pop my head up and say, Hey, are we still going in the right direction, guys? And how much effort is this really going to take so we can get from point A to point B in a way that makes sense?

I think it’s good to  jump right in. Figure everything out about the organization, its control owners, processes, and technology.  Then take that information, step back, and write out a strategy for the top five to 10 things that need to be addressed. What is it that needs to be done and supported, and what do internal teams need to do?  Write out that plan, share it internally, and request what you need to make that journey possible for the organization.

Another mistake was when I was first starting out on the security side, it was really hard to realize that some things within an organization weren’t as ideal as I thought they were.  Those were a big hit to me. One, because I felt like, oh man, Matt, how did you not catch these? When they were first identified. And then number two is I would look a little more harshly towards the organization. Like, man, I thought we were better than this. And that was a big mistake because I quickly realized that no one is at one hundred percent. Giving organizations grace actually helped us toward our goal. I had a better understanding of where we’re at in our journey and how to propel forward. And actually, we take a moment and celebrate.

The third mistake is  sometimes, security people and GRC people are seen as people who really feel like they're the smartest person in the room, and they ask the most important questions, almost to the point of alienating others. It’s not helpful. It’s really painful in a lot of ways.  Yes, the security and GRC people in the room have some understanding about how things should operate and their ideal setup, but people aren’t excited to work with you when you have an attitude about it.

 I had a friend that pulled me aside and said, “Hey Matt, being the smartest person in the room is cheap. Being able to meet someone where they're at versus expecting them to meet you where you're at is where leadership is born.”

 If we can show up in the room with this experience, with this background, with this knowledge, and still be a very collaborative, connecting human being where other people want to work with you, that’s where the real joy is.

Q:  How did you prioritize risks back then versus how you do it now?

A:  In the past I would look at things and be like, oh man, that feels bad. And how bad something felt is kind of where it fit on the list.  And honestly, if you think about risk management, that's no different than how many organizations do it today. It is largely subjective.

 Now, there's a really good book out there called The Failure of Risk Management by Douglas Hubbard, and he actually calls out this method as inadequate. He argues for more quantified based risk management approaches, and ultimately I think that’s where we all want to go.  But originally, and even today, many of us are still using the likelihood and impact assessment when something comes across the board.

There is also more communication involving risk management today.  Many infrastructure team members have more context than the security team does, so asking them to provide additional context around a risk will help you understand it better.

Q: How has security culture changed over the years?

A:  Security culture varies by organization. I’ve been at door to door organizations where security wasn’t a thought at all, and they were grossly negligent. Unfortunately, they’re out of business now.

 Now, most SaaS providers, because they’ve been hit the hardest with security breaches, they’ve really upleveled their security and  compliance practices. Now it’s table stakes to really make sure that we incorporate security at the right level.  There are a lot of us that are like, man, we gotta take it up to a hundred percent.

I think a lot of us need to focus on what is that commercially reasonable amount of security to still make it priority zero to still protect our companies and our customer's data while also staying vigilant and making investments to  mitigate likely and impactful threats.

Q: Lastly, what advice would you give to someone building their first GRC program?

A: Relationships with other people are the most important foundation for your success. I try to take the time to get to know control owners, my peers in this space, the different business departments, and build those relationships on a genuine level.

Especially approaching it from a place of, life is short, I want to do something that matters, and I want to work with people who also want to work on meaningful stuff and want to do the right thing.

My second piece of advice is to be able to explain the “why.”  Taking a control, distilling it down, and explaining the associated risk is what really helps build relationships.

Lastly, approach those conversations with the belief that people are inherently good and want to do the right thing,  and we're just a coach, a seat at the table, to help the organization get there.

Ready to get started on your GRC journey? Schedule a demo today.