RGC, Not GRC: Why Risk Comes First ft Ricky Waldron

What if compliance wasn't just about passing audits—but about building trust from the ground up?

In this powerful episode of Security & GRC Decoded, Raj sits down with Ricky Waldron, Director of Security Audit & GRC at Navan, whose GRC experience spans tech giants like Microsoft, Disney, Oracle, and Smartsheet. Ricky shares how GRC is evolving into a strategic business partner, why automation and technical fluency are no longer optional, and what it takes to make compliance an engine of trust, not a blocker.

From FedRAMP horror stories to generative AI workflows, this conversation dives deep into the future of governance, risk, and compliance—and why it's time for GRC teams to start thinking like engineers.

🔑 5 Key Takeaways

• 💥 Compliance = Security (If Done Right): Internal compliance based on risk and business needs often leads to stronger security outcomes than external certifications alone.
• 🤝 Stop Policing, Start Partnering: GRC shouldn’t just point out problems—it should offer solutions and collaborate with teams to reduce risk.
• 📊 Quantify Risk to Speak Leadership’s Language: Turn technical risk into business impact using frameworks like FAIR to get buy-in and budget.
• ⚙️ Automation Is GRC’s Future: From policy drafting with AI to continuous control monitoring, GRC teams must become technical and leverage automation.
• 🧩 GRC as a Sales Enabler: GRC isn't just an internal function—it builds trust with customers, shortens sales cycles, and helps close deals.

✅ Take Action

• Explore risk-first approaches: Lead with R in GRC to align controls with actual business risks.
• Invest in automation: Save engineering hours and scale audits with continuous evidence collection.
• Use GenAI wisely: Leverage it for speed, but ensure strong human review before anything goes to auditors.
  
  

🔗 Powered by ComplianceCow.com – automate audits, collect evidence continuously, and shift GRC left.
🎧 Subscribe to Security & GRC Decoded for weekly insights from today’s top compliance leaders.
💼 Connect with Ricky Waldron on LinkedIn.

⏱ Timestamps (approx.)

00:00 – Intro
 01:35 – Hot take on GRC
 04:31 – Why GRC & Security clash
 08:44 – GRC is storytelling
 12:57 – Risk comes before compliance
 16:08 – How to talk risk with execs
 20:41 – Trust as a compliance goal
 24:50 – Keeping your promises
 27:54 – Why GRC struggles with automation
 33:15 – Speaking engineers’ language
 38:50 – GRC as the customer conduit
 45:00 – GRC as sales enablement
 47:15 – How Ricky learned FedRAMP
 50:20 – What is FedRAMP 20X?
 52:27 – Why OSCAL hasn’t taken off
 56:15 – Would you use OSCAL commercially?
 58:36 – GenAI in GRC workflows
 1:02:31 – Using AI with auditors
 1:06:45 – State of GRC tooling
 1:12:30 – Getting budget for automation

Transcript

Intro 0:00

Welcome to Security and GRC Decoded, the podcast where security, governance, risk, and compliance professionals, CISOs, executive leaders, and practitioners can stay ahead of industry trends and challenges. I'm your host, Raj Krishnamurthy. Thank you. Hey, hey, hey, welcome to Security and GRC Decoded. I'm your host, Raj Krishnamoorthy. And today we have the awesome Ricky Waldron with us today. Ricky, welcome.

Ricky Waldon 0:55

Thank you for having me. Super, super excited to be here.

Raj Krishnamurthy 0:59

Ricky is the Director of Security Audit and GRC at Navin. He is a long-time GRC veteran. He has built teams at the GRC teams at Navin, Smartsheet, Nuna. And he's also led the GRC teams at Disney, Oracle, Microsoft, and Expedia.

Ricky Waldon 1:14

Yeah, just a few stops, a few small mom and pop companies.

Raj Krishnamurthy 1:19

You have lived and breathed GRC for a long time.

Ricky Waldon 1:23

Yes, I've been there before frameworks, before, you know, when SOC 2s were SAS 70s, back when people used to mail some of these things. So yeah, I feel like you can see a little gray from the beard. It's either from my kids or from doing FedRAMP.

Raj Krishnamurthy 1:40

Okay, so Ricky, let's start with something interesting. What is maybe a hot take or a controversial opinion that you have on GRC?

Ricky Waldon 1:49

So, and I feel like I saw maybe one of your previous ones mentioned on this as well, but my stance is compliance is security. Compliance and security go hand in hand, and not in the way that if you meet compliance, you are the most secure, you'll never be breached, you're the greatest company ever made, is a lot of startups or a lot of companies, they don't have a framework to start with, so they just This is what we think we should do. And so if if you have if you're compliant now, when I say compliance, I'm not I'm not talking about a third party telling you you're the greatest in the world. And here's your certificate. You are compliant to your own policies, your own procedures, your own. business objectives. It's almost, you don't need that pretty girl to tell you you're pretty. You need to know you're pretty yourself before you look for that external validation. So it's, do I meet my own policy? Am I compliant to my own policies? Am I compliant to my own procedures? If you're internally compliant, you have most likely built those based on risk, hopefully, based on your business. And those will meet compliance, but they're also secure because you've determined your risk, you've put the controls in place, things like that. So I'm not saying it's the world's best security, but if you are compliant to your own internal stance, you should probably be also very secure.

Raj Krishnamurthy 3:18

That's a very interesting, it's almost you're taking a philosophical brand. You're saying compliance is almost like no thyself.

Ricky Waldon 3:24

Way better. Can we go back and cut that in? That's what I should have said. Yes, it is. It is very much. There's a million third party attestations and reports and all these things that say you are compliant with blank. But are you compliant with what you even say? And why are you saying I must do this? Why must I encrypt something? Why must I do background checks? There must be at the very beginning. There is a risk to the company that you're trying to remediate, transfer any of that. That's what you build the controls off of. And if you take that stance, you start with the R, you move to the G, and you get to the C, then a lot of the times you're going to be secure and then compliant by default.

Raj Krishnamurthy 4:07

Beautifully said. I think brilliantly said. But Ricky, let me ask you this. If compliance equals security, and I think you put this in the right context, right? It at least gives you a baseline security. Why do security people disagree with you? And I'm not saying in Nevan or any... I don't know if you have come across this. There is this constant tension that exists between engineering, security, and GRC. So why is there a tension between security and GRC?

Ricky Waldon 4:34

Yes. I have found many times in my career, and many times in my career, GRC has been somewhere in the company, but not always security. I've been under the PMO. I've been under finance. I've been under legal. So a lot of times, it's almost like GRC... the team and security are not against each other, but competing priorities because we're coming from different leadership and different objectives. A lot of the time, A, it's someone coming to the security person and saying, here's this really technical solution, rolling out containers on Fargate that are... And then they go, I need a screenshot with a time and date in the corner. And they go, what? I'm on the term? What are you talking... How does that show security? So a lot of it is you can be secure. It's proving that you are secure and compliant to something. And a lot of that is... You know, I remember when I was young in my career and it was, I have, I still, it keeps me up at night sometimes. It's 15 years ago. I went to, I was at Expedia. We had a finding that there was an issue with how credit cards were being viewed using shared accounts. I was 23, 24 at the time. And I went to the director of our database team and said, you're not compliant. And this is why. And he used some very loud words and short words. I can't say here.

Raj Krishnamurthy 6:08

Explicit words.

Ricky Waldon 6:09

Yeah, explicit words. Maybe if you have a Patreon, we can talk about that later at the after hours one. But I went back to my manager and said, I can't believe he said this. And she goes, he's right. You came to the guy and said, hey, you're not compliant with this general control where there is a, guess what? There's a business case where 40 people are trying to access all of these databases, not under SSO. And it was doing fraud analysis. So they had to do this quickly. And you went to him and said, this is what's wrong, period. Instead of, here's the risk we have. Here's some ideas of how we could remediate it. Do you have thoughts? Because you built the system from scratch and then partner with him. And so there's been some companies where I will almost immediately Use the tagline in Slack as, my name's Ricky, but you most likely know me as the compliance guy. And when the compliance guy's coming, you usually don't want to talk to me. And so over the course of my career, if security wants to do engineering and people ops, they want to do what's best. They want to be secure. They're getting other people. objectives. They're getting other requirements. They have other deadlines. And if you come to them with a problem and not a solution, a suite of solutions, a partnership that you can build a solution together that maybe meets security, but also helps the business, they're not going to want to talk to you. All you're going to do is bring problems and no solutions. And I will say in that situation, I went back to him. I apologized. I say I'm young. I don't know what I'm doing. And we worked together to determine a solution that ended up just a simple SSO solution. Took a little while to roll out and modify the infrastructure a little bit. But then then a other people in the company heard about it. And this SSO, you know, 15, 20 years ago, started to expand in the company to other companies. other tools, other teams. And then B, once I admitted I was wrong and built kind of a relationship with him, he started pointing out, he goes, Hey, I also have this, not all agents need to see the full credit card number right away. Maybe we can talk about a solution that last four hides the rest of the pan. And when they call the bank, if they need to decrypt it, we'll come up with some like service to do that. And so now he's almost Coming to me with, hey, I have this problem I think is a security issue. Can you help me? Now you're switching the relationship to I'm the little kid trying to tell you what to do to. That seems there's a guy security. Ricky, I'll go talk to him real quick and maybe get his idea. So now you're a partner. Now you're not a blocker. Now you're actually helping the business meet its business objectives, not just PCI DSS 1.2 has this one requirement.

Raj Krishnamurthy 9:06

No, Ricky, I love the story. It's a beautiful story. I think it is a story of empathy, but also it is a story of the art of storytelling. In some ways, what I'm hearing you say is that GRC teams have to be somewhat of storytellers.

Ricky Waldon 9:23

Yes, 100%. You are taking, in some of these situations, you are taking nebulous, high-level, you know, these people these controls that are written to fit so many different industries and so many sizes. And you have to, you know, I always say that GRC is one of the best translators in the world because you are taking, you know, SOC 2, for example, you're getting these high level, you know, you must do law. You must have a history of events, period. You know, paraphrasing. What if you go to an engineer and say, where are your logs? They're going to go, what logs do you want? And they start naming them. And then you go, I don't know which ones. And then you go back and again. So yeah, it is, you're translating, you're taking what maybe a framework says or a customer says, you're adding the business, the object, the tooling, whatever. And then you go to your controller and you go to your person and go, this is what we're trying to do. This is where I believe it's located or what I'm trying to find from you. And this is how I would love to get it from you or set up the integration or whatever. And can you help me? So it's, it's, it's, I, and it doesn't always work, but it's more, it's trying to get it to, can you help me instead of, Hey, I've got this issue. You fix it and you let me know when it's ready to go. So you're, you're not quite passing the baton. You're at the point where you're both holding the baton and you're running the track. You just don't, let go of it. You just kind of run the track with them in that race. So it's, yeah, a lot of storytelling. You got to be, and some of it's not over email. Some of it's over coffee. Some of it's over a Zoom. Some of it's a way to connect with the person.

Raj Krishnamurthy 11:08

And whoever thought of this idea of controlled narrative rather than controlled description, kudos to them, right? This goes to what you're saying, that it is a narrative. It's about I want to go back to one of the things that you touched on, which was a very interesting thing. You talked about RG, which eventually leads to C. Double-click for us.

Ricky Waldon 11:30

Yeah, I almost feel like the acronym GRC flows a little bit better than RGC. RGC. Sometimes people do, and again, this is my personal opinion. A lot of people at Reddit have yelled at me on the GRC subreddit, but my thought process is, you can't build a program if you don't understand the risks to the company or the solution, whatever you're trying to scope. And so I have, my thought is always it's, it's, it's RGC. The risk is the risk analysis is foundational. I have, I have started at companies that say, we, we have this in place, this, this suite of controls in place because PCI States that we have to have these. And, And I go, well, that, yeah, that's true. Our company doesn't take credit cards. So why are you using PCI as the baseline? And they go, well, a consultant, we paid a lot of money. They seemed really cool. They had a great tie. They told us that. And I go, okay. So usually when I start, even if the company's been, you know, when I was at Microsoft and when I was at Oracle, you know, you're not building it from scratch, but you're still, and you talked about control narrative, which is great as well, is the whole idea of a control is, you are trying to do something to a risk. You're buying insurance and I'm transferring it. We're going to remediate it and we're going to encrypt the credit cards. You're trying to do something with the risk. And so if you're building policies, if you're writing control narratives, if you're doing SOC 2 audits, it's all kind of a show if you don't know what you're actually putting controls up against. And that's why I say a lot of times, a lot of people will ask the question, what compliance regime should I meet? Is the risks will show you what controls you actually have to have in place. And then when you go to one of those audits, I've been in PCI audits where the auditor will ask me a question and I'll say, well, the control is, this is the intent of the control. And this is how we're meeting it. What you're asking is, do I have passwords? I'm going to fail it because my company uses pass keys or we use, you know, If I'm meeting the control to the T, I'm failing the control because we actually have this risk. And this is how we've actually rolled out a solution, a control. And so that's what I say is start with the R as much as you can. It might be a customer needs HIPAA. We're going to lose this deal if we don't have ISO 27001. Keep those in the back of your mind while you're building a lot of this. But in the end, if you're going to go to a HR person or a database administrator and tell them to do something, you better Better let them know why you're doing it and don't say, because FedRAMP tells me or because CSA Star tells me. That's a great way for them to shove you out of their office and probably not invite you to the birthday party next week.

Raj Krishnamurthy 14:22

And like the first guy, the engineering guy, throw expletives at you.

Ricky Waldon 14:27

Yes, exactly. And again, then they also start thinking about it. They go, well, if that's a risk, there's another thing over here that we do that's very similar. Then again, partnership. One of my companies, we were kind of doing the internal rebrand and someone said, oh, yeah, we should get like a police shield. And my boss said, that is the love the police, you know, but our kind of stance is not we're enforcing the law. And, you know, if you see us coming, it is. Again, the idea of the police, we're a partner in the community. We're trying to help you. We're pointing out things that maybe you should modify, but we're not here to police you and give you a big red X every time you push code that you didn't do the world's greatest commenting. So the idea is build that partnership and come with all the information. Don't just say, this is the control and you failed it. How are you going to fix it? Got

Raj Krishnamurthy 15:20

it. There was a fantastic presentation at A couple of weeks ago at the ISACA North America conference by Jack Freud, Dr. Jack Freud, I should say. He heads the technology risk as a company called Acrisure. And he made a phenomenally great argument on why risk should be quantified, and particularly in terms of dollars, so that you can get a top stone view. And one question that I want to ask you is that, and that seems to be a big problem with risk management, right? Which is that you have to relate with different people at different levels, right? And how do you relate yourself to the leadership team, especially in terms of quantifying risks? What has been your experience there?

Ricky Waldon 16:00

Yeah, that's a good one. And it has definitely changed over the years where it used to be a very, give me a dartboard and this risk is a low. Okay, great. Because the impact is this number and your probability is this number. So it's definitely changed. And a lot of the boards and a lot of leadership has started, security used to be this nice thing to have, but I've seen late, you're losing deals or customers. You don't even get past the RFI unless you fill out the 300 questionnaire and you have a SOC 2 on your website and those kinds of things. So it is one now that is driving the business. And yeah, I don't have it right in front of me. Behind me is the FAIR methodology book. I think it's right about there. So big fan of the quantification and of risk. But again, you do have to take into account the audience. So I've done board meetings where I use the FAIR methodology. I identify primary... you know, risk, secondary risk. I have a number at Smartsheet, we actually built out this whole program where we had the average engineer's salary broken down by hour, and we have the average cost of all of these things. And we could say, you know, our estimates, you know, Monte Carlo it to say that the primary impact is 2.6 million. But then you have to think about, you know, the initial breach is this, but have you thought about credit reporting that you have to pay for afterwards. All the lost deals. Here's the average deal amount for this industry. So you get all these really granular, which was great. But then there's some places where we bring all that information and they go, what does it mean? Tell me what it means to the company. And so there are some times where qualification of the risk, still using business objectives, still using is, is still comes into play. Sometimes a leader just loves a good story. And so I do feel the quantification when you're doing metrics, when you're talking to an audience that is very tech, when you're going to engineers and you're using metrics, downtime, you know, impact to co, you know, That really resonates with them. When you're going to people ops, sometimes talking about a background check and the cost per background, it doesn't resonate as much. But if you can maybe talk in a way that communicates the story about onboarding someone who ends up being not who they say they are and the impact to the brand and the impact to the morale of the company. So again, knowing your audience. But I will say at the board level, it has definitely become, if you can quantify, you're able to ask for budget a lot. You can say this amount of money with this amount of budget, you do some simple math and you're going to find that if you invest a hundred thousand, you're saving 200 million. You know, that's an easy story for them to understand, to put the rubber stamp. So again, it's, it's knowing that and yeah, going to the board, going to senior leadership. A lot of the times when, you have one slide or you have three minutes and for a quarter's worth of findings and issues, if you can, yeah, numbers are real easy to say. Numbers, impact are real easy for someone in leadership to go, okay, we make this much. Okay. That's a real quick. How do we fix this? You just need to make sure again, like a control and risk. You need to be able to back up those numbers. How did you get that salary? How did you get that time? So making sure you, there's a lot of examples of other companies. There's a lot of things that are going on that you can, that you can take from to just start the process to say, if this credit card was leaked, it costs this much money per record on average. we have this mini credit card. Like that's a real simple, you don't have to go full fair methodology with threat agents and all that stuff. You can start small, but if you can, the more numbers you can use, especially if you're asking for budget resources, time, people, money, it goes a long way.

Raj Krishnamurthy 19:54

Got it. Got it. And that's beautiful. Ricky, when we spoke last time and correct me if I'm wrong, you said that compliance is about Demonstrating that we are keeping our promises. Am I saying this right?

Ricky Waldon 20:07

Yes. Yes.

Raj Krishnamurthy 20:08

What did he mean by that?

Ricky Waldon 20:10

The industry has definitely pivoted to the idea of And a lot of places now it's called trust. Some places don't even call it security anymore. And I've worked in a lot of assurance and trust customers. The amount of data that people are providing nowadays, especially if you're in a B2C, if you have an end user and they're going to give you their credit card to buy your fund widget, they are trusting you with their data, their name, their address. And a lot of times, especially when I talk to my older relatives, they're like, I heard about this, my friend getting their credit card stolen, their identity stolen. A lot of people don't talk about how great a product is anymore. It's a lot of like, I need to go see if they've had a breach. I need to go check who their sub-processors are. And if they've had a breach, they're immediately worried about Because every day in the news, you know, something's happening. Coinbase is getting something and all my stuff's gone and that kind of stuff. So it's now, A, it's still, you know, making sure the product is secure. But again, back to your mention earlier about narratives and storytelling is now how do I take these technical things that not every customer is going to care about, but now wrap that in a story to say, okay, Your data is safe with us. We are going to not use your data in a way that you will not. be a fan of. How are we going to make sure this relationship continues and is fruitful and everything we provide to you is great? And on the back end, we're going to make sure everything's secure. We're going to use the newest technology. We're going to make sure that everything you give us is kind of the crown jewels and it's never going to be touched. So when I first started, it was get a report, send it to the businesses. And for the customers, maybe we'll have a note on our webpage that they're Data is private. And that's the extent. And so over the 20, it's changed trust centers, safe bases of the world, the anecdotes of the world. A lot of the positioning is now, oh, that's great. You do these audits. How are you going to tell the customer? How are you going to answer their questionnaires? How are you going to make sure that at the very beginning of their RFI, your name is on there because you check these boxes?

Raj Krishnamurthy 22:25

Welcome back again. We had a technical difficulty. My laptop shut down, and I'm on this other laptop. So, Ricky, thanks for staying on. I appreciate it. I don't know if I ever told you, I used to work for a company called SunGuard Availability Services. We were big on business continuity and disaster recovery.

Ricky Waldon 22:42

I was going to say, exactly. Right here, we just did a tabletop exercise live, and everyone at home, remember, it doesn't have to be that built out. We can do something as a computer shut down for auto-updates. So, continuity, Check.

Raj Krishnamurthy 22:57

Okay. And this is an unforced chaos engineering. So I don't know if I can say that. But Ricky, thanks for saying that. I think where we left off, where we wanted to continue was that you talked about R being fundamental, foundational, risk being foundational. G is about creating those policies and control statements that aligns with the risk. And then compliance is all about making sure that we keep the promises that we make. Can you double click on that?

Ricky Waldon 23:24

Exactly. Yeah, that's kind of that's exactly is now you do your risk assessment, however big, however small you go, okay, this is what the business is worried about, or these are the risks. And you also need to make sure a lot of people think risks is always a negative. It's also if you're not taking risks, you're also not you're losing opportunity. And so that's in there as a way of accepting, yes, we're going to accept that risk, because if we don't, we're going to miss out on that opportunity. That product, that market. So once you get that down, yeah, then the G. So the G is really the first step in that translation of these are the risks. Now, what are we going to put in place to alleviate or transfer or take that risk and make sure it doesn't impact the company to a level that's not acceptable? So you're writing those policies, those procedures. You're saying, you know, what do we do? Why do we do it? And then how do we do it? And so each of those at the government, probably everyone's seen the little governance pyramid of all the different docs and leadership loves when you've got a lot of documents. GRC is really good at that. But you're saying why we do something or a standard is what we're doing. And then you take that to engineering, you take that to people ops, you take that to physical security and you go, okay, great. I want you to tell us how you're doing that. Are you... you know, we can get technical. You can tell me about branch, you know, branch protection and, and we can talk about two factor and all this kind of stuff. But now, now you've taken these controls or these risks that you don't, you don't want to tell them the risks, all the, you know, sometimes they're, they won't understand it or they don't want to, it's not part of their job, but now you, now you can put it in a way of, we, we have a risk that we're trying to control. What do you do today? Or what, what should we start project managing or something to get that risk to be at an acceptable level? So you're, What you're doing is you do the risk analysis, you do the governance layer, then you kind of go back and forth. You go, okay, we're going to put these controls in place. Now let's do a quick analysis. Is the Is the control enough to get that risk all the way down to that acceptable level, or do we need to do something else? And so you're kind of going back and forth, back and forth. And then when you get to that point is where you want to do that way we talked about before, that compliance is security. Can I now comply? Can the company comply to this governance layer I've put in? And if so, that's really the first piece of trust. Not all companies are going to have a SOC 2 and ISO, PCI, FedRAMP, ATO to give to a customer, but At that point, you can start to build that trust story with a customer. If you're a small company and you want to show them some of the stuff you do under NDA, maybe that's the point where you say you're complying to those internal controls and this is how. And then you get to the point where you hire someone to do an ISO, someone to do an MTCS. You want to go to the Australian government with IRAP. you have a pretty good idea of at least the controls and methodologies you've put in place. Some of those have those little tedious control, the controls you don't really think about that you do have to put, but it's not zero to 100. It's 80 to 100. I've got these few random gaps that I never even thought of that maybe don't apply or not a huge risk for us. But I have to have a business continuity tabletop, or I have to have, you know, something, I have to have insurance on a retainer or something like that. That's a very small step to get to that new market or that new product or anything like that.

Raj Krishnamurthy 26:53

Got it. And nobody says no to automation. I've never seen that. But yet most customers, most enterprises, companies struggle with automating GRC or GNC in the way that you put it. Why? Yeah.

Ricky Waldon 27:07

At least in my life, GRC has not been an extremely technical group. And I, again, when I started, graduated from college with no idea what I was going to do. I got an internship at the Seattle Mariners. As you can tell by my sports, that was a dream internship. And then I went to a help desk role. And then I was doing SOX quarterly access reviews. I didn't know what socks meant. I didn't know why we did it quarterly. I wasn't sure what two-factor versus single sign-on versus logging. I didn't know any of this stuff. I was the only GRC person in the company. So a lot of times the GRC roles has not been very technical. And sometimes... I find that if a GRC person does get really technical, they move to engineering. They move to QA. They move out of GRC because they're really interested in what they've been working on. Lately, the shift left, the GRC engineering has been taking hold, which I'm a huge fan of. And so starting to get people involved in it that are a little more technical. The other thing, too, is when I was coming out of college... GRC, we didn't even have a security class. I took some accounting classes. I took some code. I took some database, some network, but never in there did they say, what's a cipher? What the heck do I do? Why do I have to have a password X? You know, just make sure you log into something. So now it's also, it's kind of happened where I went, Washington State University, go Cougs. They have a whole curriculum around cybersecurity, how to use AI and cybersecurity. There is now a class and people understand that it's a job and it's a career after that. Again, I fell into this job. I Again, working help desk, doing quarterly access reviews as part of my role. And the head of security came in, Gabrielle Gustav, one of the greatest managers I've ever had, came in and said, I'll just take the senior on the team. We need a resource. And the senior on the team had left two weeks earlier to start his own business out of his garage. And I became the senior at that time. So I said, I'm 22. I love a full-time job. I don't know what SOX is. I'll take it. And so- I feel like that happens a lot. I've worked with a lot of people who came from the biochemistry. I've worked with a lot of people who just got a job with a big four out of college because they were recruiting. And it's not always technical. But now with the tooling, the other thing is not a lot of tooling happens. A, there wasn't a lot of tooling in GRC in general, a lot of spreadsheets. You know, we were using a very well-built out Archer when I was at Microsoft. But again, it was huge. And it was, you know, we had full-time people managing it. It wasn't as easy as nowadays to, you know, get a token. And all of a sudden, AWS is flowing into a tool 20 minutes later. So the automation is happening. You're still working on getting the resources in GRC deployed. technical, which is, I say, job-wise, it is one of those things nowadays, I say that as I sound old, is a little bit easier to start to build your portfolio and learn about. You know, I was, one of my first forays into the scripting was just, I had to build a POAM for FedRAMP, and I had these insanely gigantic scans out of CrowdStrike that were in a whole different format. And how the heck, I was spending almost 10 hours a month just taking these scans and we had great scans. We didn't have 8,000 lines. We had about, you know, the normal 200 lines or so and putting them into another poems, you know, the poem format. I wrote a script, Python script, had some help from a great couple, great engineers. And all of a sudden that was down to an hour and it was really running the script and then just doing a quick QA on some of the little intricacies everybody knows about FedRAMP. So you can just, you know, scripts, the chat GPTs, the clods of the world. Super helpful in helping you. You don't have to memorize Python. I'm not a professional in Python. I'm a professional in ISO internal audit and FedRAMP, but it helps me do very basic. I want to, you know, right now I'm working on just a very simple, we want to review more of the Chrome extensions. Okay, I'm working on a simple script to download the package, look at the code, look at the privacy policy on the website. It's very simple little projects you can do to learn more the more technical side of it. And then it's also, I would say, make sure you get the basic AWS training, GCP, OCI, whatever platform, and you can get some of that information to get a little more technical to instead. Now, when I go to a database person, I don't say, hey, that database, I say, hey, you know, this S3, this EC2, the RDS, the Fargate, you know, you're using their terminology. I'm not an expert. I'm not going to tell them how to do and fix it. But now that I've used their language, it's a lot easier for them to communicate back. They understand what I'm looking for. It's a much cleaner exercise. And then probably more to the point is, or I don't even bother them at all. I integrate it into my tool API calls. If you're using a SOAR, like a times you're using a compliance cow, you, you don't even bother them. You just say, Hey, I got that. We have this PCI audit. I need you for 20 minutes, but I've already collected all the evidence. I already have it over the course of the year. I've already been using it. You start to get to the point where a lot of engineers are saying, hey, I thought we were getting PCI. Hey, it's already done. Remember that one question I asked over Slack? That was all I needed you for. And then they start to get real happy and they like you again.

Raj Krishnamurthy 32:49

So what I'm hearing is that the skills are improving, the tooling is improving, and people are getting more technical about dealing with sort of how you describe GRC engineering than ever before. So So is it fair to say that you're more optimistic that we are going to be seeing more of automation in GRC than dealing with spreadsheet

Ricky Waldon 33:10

before? Well, true. Budgets and everything. But I will say yes. I think GRC is becoming more technical. I think the industry is becoming more technical. Hoping the auditors become more technical. I had to explain a report to an auditor and why we put a hash in it to show... the integrity of the file and they were mad I didn't have a screenshot. So we're still working on making sure that the end, this is actually way better than the screenshot and this is why. But yes, it's getting more technical. And again, this is alleviating that C. I don't want to spend a lot of time on screenshots for a SOC 2 audit. I want to spend way more time on Analyzing the risk and putting controls in place and helping the business expand. You're now spending more time on the R and the G and the C again is just happening.

Raj Krishnamurthy 34:04

Beautifully said. And I think that that is very consistent with what you said earlier, right? The approach to R, G and C. But at the end of the day, you have to. So right now, it looks like there is a lot of onus on the GRC teams. They're sort of quarterbacking all of this to deal with auditors. They've always done this. But now you have more technical responsibilities as well to do it. How is that experience for you in terms of dealing with auditors? You said you're hoping the auditors to become technical. Are there any tips, advice that you would give our listeners on how to deal with auditors?

Ricky Waldon 34:34

That's a great question. I would say if you have great auditors, I've had some really great ones. I've had some really bad ones. A lot of times it's just people have not done it for a long time or have worked on the enterprise space to understand how it is. We had an auditor and an audit FedRAMP audit. with the VP of engineering and he was reading the FedRAMP, the state 153 controls word by word. And we got to the logging question. I brought it up earlier. He asked the question, how do you secure your logs? And the engineer said, what logs are you talking about? And he goes... I'll have to get back to you. So he didn't even know the difference between security application network. So I think there is more, you know, I see some of that. I have a good friend who works in the space that deals on the partnership sides with auditors and he's seen they are a, they're more open to some of these tools. When I first started using some of these GRC tools, our auditors said, these are great. We don't trust them and we're not going to use them. So now it's, It's in essence, a glorified file share that I have to download and now hand off. So now I'm having duplicates of evidence and I want to, I'm making it easier, but I'm making it harder. So they're starting to become a, or they'll make their own. I know coal fire has their own portal. Some of them now have their own product that you can, that you can use for this, which is great. So I think there is, there is hope. One of the things I'm dealing with the auditor right now, who's really great is they're We're having a lot more meetings, not just with the audit, but talking about the business, talking about the application or the service or whatever we're auditing, talking through how we meet the intent of the control. So we're giving... you know, this doesn't always happen, but some auditors are making more of an effort to understand more about the business and the controls and how you're putting things in place. So we get back to that intent of the control or intent of the, how we're rolling this out. So if you can get, I think it's getting better. There are this other side of, you know, We'll get you a sock too for a hundred bucks. We're going to fix everything. You know, we've also got the other side, which is, which is my LinkedIn is full of, but I think it's getting, it's getting better. It's more technical. The auditors are understanding that a screenshot is not the best way to do this. So we're getting there.

Raj Krishnamurthy 36:56

When I spoke with you earlier, Ricky, you made a very interesting comment, which is you said the GRC teams are a conduit between customers and internal teams. Why did you say that?

Ricky Waldon 37:07

This is why I let, and again, if they want to reach out on LinkedIn, ask me how the business is. This is, this is why I love working in GRC is, and this is again, also goes back to sometimes why GRC is not the most technical is, is you are, you are kind of, I don't know, sounds cock. You're the center of the world almost in your business is you are literally reaching. Yes. That's not

Raj Krishnamurthy 37:26

my term. That was some, somebody on our, one of our guests said this GRC is the center of gravity in a company, but please go on.

Ricky Waldon 37:32

I like that. I like that. Okay. I'm going to write that down. Put my name on it. But yeah, it's, you are working with, so many parts of the company you're working with, again, people, operations, sales, engineering. So, you know, a little bit about everything. And if you're, if you're lucky enough, I'm at the point where I'm help, you know, I'm in projects that are training the trap, you know, the sales agents, or we're doing instant response. Like you're getting more and more into the projects and the weeds of it. Then customers are, They don't know anything unless you tell them. So you might have a trust center, you might have a slash security page, or you might talk about something in a POC, but every company you work with cares about something different. They have their own risks. They've done their R's and they have their G's. And so one company might really want to know, how are you rolling out your code into production? What are all your tests? Another company is going to ask, how do you onboard a new employee and how do you delete their accounts within X amount of time? So we're, we're a great role where we're kind of at the edge of the business where that trust, where we will get on, I get on calls with customers all the time. My boss gets on calls with customers. We get on calls with our vendors to communicate what our worries are. You are, you are that almost that proxy you're filtering. You don't want to give them too much detail. You don't want to go super in depth on some of these things, but you want to be able to answer questions. a breadth of questions and be able to go from customer A who cares about encryption to customer B who cares about data sovereignty to customer C who just wants to know, do you have a security guard in your building? And so you're kind of that, everything comes through you. And if you can answer or be that person in front, again, the internal teams love it because they have other priorities and they're trying to make cool widgets and do other things. You can block all those questions from getting all the way to them and taking their time up. But then the customer, you have a single point of contact, security ad or trust ad. They can email and say, hey, this came up during an audit, and we've got a question. Can you help? You become that kind of single point, and then you can take those and say, hey, the business is asking for this, or the customer keeps asking for this thing to be available on the website. Hey, product. Great idea to roll this out. Now all of a sudden, oh, look at this. You're helping the business. You're helping the business objectives. You're pseudo sales because you're helping close deals because you have this security. So you get in a lot of, it's super interesting. You learn a lot about the business. You learn a lot about what people are doing, what other people are worried about. A lot of times I take questionnaires. I go, wow, those are really good questions. Let's add them on our site with answers and maybe we should be asking our vendors this. So you're also getting a lot of information. One of the oddest ones that I was a part of was I was doing an IRAP audit. I was in Australia at a data center. And one of the questions that I luckily could answer at the time was they cared about people dropping listening devices under the data room floor into another co-location. So I had to give them the specs of how big the holes are in the fencing and how far down below our raised floor it goes. So like that shows you Everyone cares about something different. And if you kind of know a little bit about everything, they may go, you know, you sound like you do something, you know something. Okay, we're going to checkbox you and get you past the RFI into the product.

Raj Krishnamurthy 41:03

So I think you're bringing up a very interesting point, which is GRC is not just an internal function. It is a sales enablement function. But more importantly, it also builds and retails customer trust. Do leaders recognize that, what you just said? Or is it just the GRC team feeling that way? Or do leaders of the company recognize that? And how does that show up in your work?

Ricky Waldon 41:30

Yeah. I feel like leadership, based on the industry and based on what you're doing, there are a lot of leaders. When I was at Smartsheet, we added a member of the board, was it? a security person. Like you're starting to see security people show up on boards. You're starting to see compliance people show up in meetings that usually they wouldn't be on. You're helping with product rolls out. So leadership is starting to see that a lot of deals are lost when you don't have a certain acronym on your website or you can't meet this customer expectation. A lot of times it is a security thing that will lose a deal. And so, especially in my last few roles, leadership has taken control and put it closer to the front. We have a sales engineer, like literally all they do is they update the trust center. They answer questionnaires. They meet with the sales team and train them. They meet with the customer to ask questions. Five, 10 years ago, that would never even been a thought. We would await for sales to come to us with one-off questions. So now we're, we're getting so close that we're in the sales process now. So it's, it's, And then back to leadership. Instead of saying, hey, we got this many new acronyms and this many cool policies, my metrics are, this is how many deals we've helped close. This is how fast we've turned around questionnaires for sales. These are the... These are the products we've helped roll out that have retained customers because they needed logging, they needed extra things. So it is this idea of the shift left and the idea of complaint, but it's almost like we're shifting left also in the sales process. We're getting earlier in the sales process, the reports are moving close. We don't want to wait until they send us a questionnaire or they ask us about SOC. It's, hey, Here's all of our certifications on our trust center. Here is a lot of questions and answers we get. Usually they're available. If you have an NDA in place, let's do that now. And then when we get further down, the worry is about integrations and things that aren't security. Those have already been dealt with way earlier in the process because you don't want that holding up. You're at the last day of the quarter and the vendor goes, oh, I've We got a 300, you know, SIG light we need you to fill out. And, you know, blah, blah, blah. No. So shifting left in the sales process. And then, yeah, the business record, you get a lot more kudos. You're asked to come to a lot more. Hey, sales, you got this new acronym. Sales really wants to know what that means and how that helps us in this market. And so we get in front of the sales team almost more than engineering professionals. People operate as they just want to know how can we sell this great new security enhancement we put in place.

Raj Krishnamurthy 44:16

Ricky, your experience has been primarily in the commercial space. How did you end up becoming so knowledgeable on

Ricky Waldon 44:24

FedRAMP? Again, accidental. It was, so I mentioned earlier, great management, Gabrielle Gustav. She ended up moving to Microsoft and called me up and said, hey, we have this data center compliance thing. that we're starting up. I know you don't, you've never, I went to one data center in my life in Las Vegas and I was like, this is cool and big and awesome. And she goes, I want you to come and I want you to start. Are

Raj Krishnamurthy 44:49

you sure it was, it was to a data center?

Ricky Waldon 44:53

Look at the size of these pipes. Oh my gosh. Backup generators. Look at all this fuel. So she goes, I need you. I'm going to have you come in. I'm going to have you start. I'm going to have you kind of build this and work with a great team in place and, And so came in and started doing these data sets. So what it was is I took the kind of the physical security, the data center specific controls of every framework. So there were people who ran the ISO, ran PCI, ran FedRAMP. But what I would do is I would go to the data centers. I'd work with the data centers on all the requirements. And then in essence, I would have in the morning, the SOC auditor would show up. I go get lunch in the afternoon, the ISO auditor would show up. And that's how I got introduced to FedRAMP was we did obviously FedRAMP audits and aisle five audits. And I did a IRAP in Australia, MTCS in Singapore. I, I, so I started getting into these again, it was physical security specific and data center specific. But when you start to do that, you just start to like, why, why the heck do they care about man traps? Well, let me see the, you know, so, you know, learn a little bit, learn about it. And then from there, I just kind of weaseled my way into helping other people with FedRAMP and IRAP. I ended up helping do one of the first IRAPs for Microsoft, going to Sydney, going to Melbourne, doing the audit, and then coming back and helping with the other controls that were in the framework. So super interesting. I don't know if tedious and administrative overhead heavy is... enough of a system of it, but yeah, that's kind of how I weaseled my way into these, into all these other frameworks. There's so many frameworks to work on and being at Microsoft and Oracle was great. I got exposure, you know, they, they need to meet all of they, there's not a customer base. The whole world is their customer base. So they've got to go, you know, the biggest to the smallest.

Raj Krishnamurthy 46:47

And what is FedRAMP 20X?

Ricky Waldon 46:51

So FedRAMP 20X is a great idea. I hope it works. I hope all of this works. So in essence, The 20X is a government process. Everyone loves the government process. Everyone's been to the DMV. It is trying to get ATOs through quicker. It's trying to not require an agent. The sponsorship part is extremely hard. It's almost like It's saying you can't buy this. You need someone who already wants the thing to help you get it through this process for 18 months so they can buy it. It's almost like I see bread at the grocery store, but I'm not allowed to buy it. I have to work with the bread maker for 18 months before I can get it. It's there, but I can't touch it. It's a very old process. At Smartsheet, I mean... A lot of what my boss was doing was talking to different, do you want to use us? Can we get you to sponsor us? It's finding a sponsor. It's a crazy idea to think of. You can't sell to us until you get through this whole thing, but you already have to have demand. So that's crazy. And then the other process is automating. If anyone's written an SSP, if anyone's written a POAM, I'm with you. I love you. I'm sorry. But you know, we're talking about, even when I did a tailored low impact SAS SSP, it was over 300 pages and that's a very small amount of controls. You can imagine a Microsoft, Oracle, smart, the SSPs. Again, I had a full-time person doing SSP and POAM work. So the, the hope with this X is again, your automate automation to validate the controls. You're talking about getting things on the marketplace and, As a normal commercial company, hey, I have this product. Does anyone want to buy it? Instead of, hey, I have this product, I have to get someone inside to then help me get the product. And you have to wait 18 months. So by the time I get the original thing approved, I've made 20 other contracts. great upgrades that now I need to do. Anyone here has also done an SCR through FedRAMP. I'm with you. Getting those things in there is now, and now my commercial and my Gov product is so different that now I have to have more teams to just manage both of them. So I love it. It's a great idea. I hope it happens. But as, as, as we saw with OzCal, it's going to, I wish, I wish it the best and I hope it happens.

Raj Krishnamurthy 49:15

Yeah. Yeah.

Ricky Waldon 49:44

Again, yeah, a great idea. And my team, when I was at Smart, we jumped on Git as soon as AusCal was available and we started looking through the code and how to implement it. But again, you're talking about, we alluded this to before, the GRC team is not always the most technical team. And to roll out, in essence, a full language for them to figure out how to, A, read, reading it alone, and B... being able to then take the 700, 600 page document and convert it into this code is a tall ass. Because again, like a lot of FedRAMP is one of the things you're working on. You're working on other frameworks, you're doing other things. And so then it comes to play, do you have an engineering team or an IT team that's willing to help you with this stuff? If you're not an engineer, you're not probably going to be able to roll out the code. You're not going to know how to make changes. You're going to need someone who's more technical to help you. So I think when AusCal first came out, we looked at it for a little bit and we tried. We definitely tried. I had a very technical person on my team that was running our scans and working with engineering and architecture. And I had another gentleman on my team. He's retired now, but he came from the FBI doing internal SCRs and internal. They just couldn't figure it out. The other thing that I think it's getting better now with the paramifies and the tools of the world is there's no user-friendly tool to do it. You had to figure out how to roll out AusCal in your environment. How are you going to do that? And so... Now that things are, again, tooling, the secure frames, the parametrizes, they see FedRAMP, they see CMMC, they see that world as a market that they can get into. And hopefully this also allows them to get there easier. I remember rolling out E-Ramba, an open sort, great tool when my budget was very small. But that's something you could roll out in your FedRAMP environment and fully manage the tool. You can't fully manage a lot. And so... Hopefully with this text, it's allowing the compliance cows and the GRC tools of the world to maybe touch some CUI or be considered an SBA with SPD, all the other acronyms in the world. So I think it'll catch on. Instead of managing the code, the OSCAL itself, you manage a tool with easy GUI and I can, okay, here's my, you know, here's RA5 and here's how we meet it. And I press enter and all of a sudden it prints out in a nice format. That's going to make the adoption of it. It's kind of saying, here's the language. Everyone has to learn it. It's always going to be hard. PCI came out. Everyone who takes a credit card has to meet this. Bill's bakery who takes credit cards has no idea what any of this means. And so, A, he's not going to take credit cards. He's going to go to a third party and do it. He's not going to be able to roll it out. So it's the same ideas. You're rolling out a framework, a thing that everyone has to figure out how to meet. And it's a little bit tough, especially in a non-technical role sometimes like GRC, to be able to adopt that quickly.

Raj Krishnamurthy 52:59

If you're not doing FedRAMP, StateRAMP, or any of the RAMPs, would you use OSCAR?

Ricky Waldon 53:07

If the auditors or the regulators will accept it, I would love to. If we could make it. But my role, the tools that we use, I don't think I would adopt AusCal as is unless I had a magic tool that did everything for me. And then just one of the exports happened to be out of AusCal.

Raj Krishnamurthy 53:26

That's a beautifully said statement because I think that's one of the fundamental reasons why, in spite of some glorious efforts, AusCal has not... seen success in the commercial space because to your point they are very complex because there is nothing about oscal that limits itself to nest and 53 or fedramp or any of them right but i think it has become so complex that it is very difficult to adopt this easily in enterprises i would love to see a world ricky where somebody with your caliber and your experience sort of builds a compromise of building something like an oscal light that anybody can use, including the enterprises, where we can borrow the principles that we learned through our scale and sort of simplify them, right, for even the smaller customers to be able to use that as a protocol.

Ricky Waldon 54:11

Yeah, yeah, I completely agree because then that helps that, you know, it's almost like a Scantron. If I can build it in a way that all these other things accept it in a machine-readable language, it also makes the, and I think with the 20X, that's the other idea with FedRAMP, is an SSP protocol Yeah, absolutely. in essence, make a Scantron and then you put the SSP through the machine and you get a green light or a red light. So it helps with that. I think that is great. And if I could take my SOC 2s and my ISOs and my IRAPs and all of that, my C5s and do a similar, I would do that in a heartbeat where I can hit go and it says, okay, great. Your SSP, your AOC, it's great. And it took five minutes to review.

Raj Krishnamurthy 55:17

That's a great segue to the next question, which has become sort of a mandatory question in all podcasts, which is what do you see as the role of generative AI in GRC?

Ricky Waldon 55:29

I will say I love it. I love it. I use it daily. I use it in my personal life. My wife's been making some awesome recipes based on what's in the fridge, you know, things like that. And yeah, I... I would highly suggest everyone to figure out what it is for them. I have been using it to, you know, you're in a meeting and someone says, we need this policy. This is kind of the idea we need. This is the audience. These are the stakeholders. And Ricky, go write a base. Five minutes later, I've got a corporate approved Gen AI system. Put in some basics. I will emphasize, take a prompting class. Learn how to write a prompt in a way that that you can get some really good output. But you can get a skeleton of a policy in 20 seconds. You can get an idea of control narratives in 20 seconds. It helps, I will say, don't rely on it to Fix your controls, meet things, do risks, but it's going to help you do a lot of things that are tedious. I've got right now, we've built an internal agent that reviews a SOC 2, a PCI AOC, a security identity, a lot of attachments and spits out a report. I don't rely on that report to say that vendor's not risky or not, but now... it does a way better job of figuring out where does it say if it's qualified or not? What are the comparative, you know, complimentary user entity controls? Well, do they have any, you know, a SOC two again is 70, 80, 90 pages. It's, it's going to look through it and point out what you want. What are you going to emphasize? What's the scope? Okay. It also has a PCI AOC. Go look through that. Tell me if it's going to look through those things that are tedious. It's going to build, it's going to give you initial information. Documentation that you then can build upon, or you can use the gen AI to here's the skeleton. Now I've got, I had a meeting about it. Here's a lot of meeting notes about it. Put those, those thoughts. Now let's do a version two. So I love it. I do basic gap analysis with it. I do, again, a lot of scripts. I say, hey, it's in this format. I want it in this format. I can do a lot of stuff within two minutes that used to take me a whole day to do. So I would say learn it. It's not going anywhere. I think a lot of people are scared of it. It's at the moment, it's not going to take your job. I still have to say, hey, I asked you to do it in Markdown. You did the wrong Markdown. This table doesn't, can you please, you know, we're still, we're still early, but it's a huge leap. It's the iPhone, it's the tech, you know, it's changed everything, but you got to learn how to, it's a tool in the tool belt. You learn how to use it, learn how to use it to your advantage. A lot of companies I see now have job roles where you are required to know how to use AI. And so again, some companies are scared, you know, use a corporate approved one, write some maybe governance around it, but use it. Use it as much as possible. It is fantastic. It is terrifying. It is wonderful. It's all at the same time. No,

Raj Krishnamurthy 58:34

that's beautiful. And going back to the earlier question, and how do you sort of demonstrate the results that you generate out of any generative AI process, right? Whether it is sort of looking at systems or producing a piece of evidence or whatever you're doing, right? Or looking at a policy. How do you work that with your auditor?

Ricky Waldon 59:01

Ooh, that's a good question. Yeah, there is a lot of things you can do to put some guardrails or quality checks in your AI to make sure that that what is being generated out is meeting your requirements. You, there's also, you know, the risk of shadow AI, shadow IT has always been a big deal. Now the shadow AI within your company. So again, it's, it's working with, you still have that tough of auditors who you're still trying to get past the screenshots. Now you're trying to talk about how you use AWS bedrock, but you've also implemented llama within there. Like, What is happening? Like, I just wanted a policy. So in GRC fashion, I have a lot of diagrams. I have a lot of documentation about what's approved and not. How do we use it? We have a very bold bulleted statement in our policy that says all AI output must be reviewed by a human. There are things that you can put in place to show. And just like a control is we're going to do something, but there's a way to check the something before it becomes production ready. And so we... We have shown some of the tooling that we use as well suggests things that sometimes you do have to put guardrails of. It's okay to suggest it, but we're not okay for the AI to take the action as well. We've got a tool that we use where it will suggest firewall rule changes or will suggest actions still at the point where we will human review it. Because again, it doesn't understand business. It doesn't understand maybe we just rolled out a new product in that country and now you're telling me all these IPs should be blocked. Actually, it shouldn't. So you have a little bit more, you're still at that point where it knows what it knows and it doesn't know what it doesn't know. You may be able to add to say, that's great. Let me add some more context. And now all of a sudden that AI can make, oh, okay, now I've relearned and now I'm not going to flag that. So we're still a little bit you know, some companies are, and it's totally okay. If that's part of your business, let it do as much as it wants. Just make sure that there's guardrails, there's quality control. You're making sure that the output is meeting some sort of threshold to say, if we put this quality control in place and it's 90% or above, move to the next step. If it's less, let's check it. Let's see what it generated. Let's see what terms it used. You know, I've read a lot of policies from third parties that at the bottom of the policy, it states, you know, this is, you know, have some statement. You're like, well, that's what Claude says when it has like a follow-up question, you didn't chunk your document. Right. And it couldn't do enough tokens. And now I see a little comment on the bottom. So that's another thing you need to look out for is, is that trust portion is if I get something where I know it came direct, you didn't even do a quality control check. You've actually now killed a little bit of the trust I have with you because I didn't I don't think you're doing the proper steps. And so that's why you kind of need that human interaction or at least some sort of threshold. Again, it's risk. I'm transferring the risk almost to generative AI to operate this thing. I need to make sure it's operating efficiently. And if not, I will come interject and modify the LLM or I will modify the document that was output.

Raj Krishnamurthy 1:02:27

So what I'm hearing is that you would actually definitely want Look at the process, put some guardrails in place, make sure there is some sufficient level of human review right before you work present with anything to your auditors. Is that a fair thing to say?

Ricky Waldon 1:02:44

Yeah, yeah, exactly. And yeah, it's almost like having another employee is you trust it to do a lot of work, but in some cases you just want to double check. You want a second set of eyes. You want something on it before it makes it too obvious. your auditor who, when they ask you questions, you better have a good answer of why it says that in there.

Raj Krishnamurthy 1:03:02

In fact, Salesforce calls their agent force digital workforce. That's what they call it. That digital person, right? So it makes sense. What do you see as the current state of tooling? You've been in this space for a long time and you have seen it evolve, Ricky. What do you see as the current state of GRC tooling? And where do you think it should go?

Ricky Waldon 1:03:25

I will say I love where it is right where it's heading and kind of where I was there when GRC was not really a market. Not a lot of people saw money, maybe socks. I think the very first tool tool that I ever had that dealt with controls was a, it was a socks tool we used for narratives and that I never really used GRC tool until I got to Microsoft, which was Archer, which was this built out millions of, I mean, it was, it was great for how we used it. Um, But it wasn't like we were going to move off it to another one. There wasn't another one to move off to. So I see it as finally people understand it's a big market. Sales companies are now requiring you to have this acronym. How do you get there? This tool will help you. There has been a huge kind of influx in tools, and that's caused some confusion because some people don't. quite know what they, us GRC people, we might not know what we want. We rely on others to tell me how to do the control. You're now asking me to take, you know, is this tool the right thing? And, and, but it was a lot of, you do the integration, you figure out how to, you download it, you know, you run this report out of Salesforce and you upload it. You know, that was kind of the, the, the phase two. Then it's got to the phase of, I think the all-in-one tool, you do the G, the R, the C, the trust, the assess, you do everything in a single tool, which is, is great and sounds great for a lot of a lot of companies but now we're starting to get to the point i feel where they're scaling you want kind of best in class you want this platform or this tool that does a trust yeah i want this trust center and that's all i want them to do or maybe they do questionnaires but i don't want all the ancillary stuff i need integrations i i i'm tired of writing my own sore integrations and figuring out the api endpoints and reports right you know, I want a best in class platform for that continuous control management. Boom. So I think it's, it's getting to the point where we're starting to get to that. There's still the all in ones and that works for a lot of companies, but we're starting to get more of the, of the, I don't want to say niche, but you know, yeah, very perfect. Special. I, I, a lot of businesses that I've been at a lot of companies, they, one part of the GRC is they're, is what they care about the most is a trust. And I need to get to the cut is that I have a million systems and I need them all integrated and monitored real time. I need that to be my focus of a tool or a solution. And so I'm a lot of good specialized tools and then built in, you know, the integrations, the, a lot of times it was the homegrown or I wrote a script or something. And every day it runs on a server is now integrated. I can integrate more natively or I can I can get these, you know, in 20 minutes, I've got 10 tools feeding into my platform. I can care more about the risk. I can care more about the evidence. I don't need to care about how it's getting there. I can now focus on actually remediations or adjusting my risk because actually the automated pull is showing me that. This firewall rule wasn't meeting requirements, but there's actually a web app firewall ahead of it that is, okay, now I get more context. So I think we're in a good place, a lot more specialized for the bigger use cases. We still have the all-in-ones. I think we'll probably see, I know we have it, but a lot more acquisitions will probably occur. We've got some of these big players that now are with draw to buy and safe base. And there's a lot more of these acquisitions where they will build up Maybe not so much vendor sprawl, but vendors will have more use cases instead of I have a GRC tool or I have a tool is I'll have all these tools. You can buy one or you can buy many.

Raj Krishnamurthy 1:07:06

That makes sense. As a leader, GRC leader, Ricky, how do you go to your leadership to build this case for automation, either whether it is buying a tool or whether it is skilling your employees to go take it to the next step? How do you sort of build a business case?

Ricky Waldon 1:07:24

Yeah, but that has been a fun struggle. And I think anyone who's in GRC and security knows about, you know, is a lot of leadership will see you as a cost center. Even if you're helping sales, you know, at the end of the year, you go, well, this part of the company costs this much. And, you know, they didn't directly sell a single thing. So you want more money? So it is, I mean, my number one metric, and I still do this today is, How many pieces of evidence did we collect? How many people did we have to interact with? How many hours did they spend on pulling evidence or setting up an integration? How many, you know, we went with different auditors. How many interviews did they spend time in? So a lot of my sales pitch to leadership or others is not making my life easier, making the business's life easier and using those metrics. Either A, hey, this is, the efficiency we just, we got this much more efficient this year. And if we had this other thing, we would get even closer. Or I got this training and then someone on my team can manage part portions of AWS command center and look at it themselves or AWS config or something. So you can start to use the efficiency in the rest of the company. Obviously, I also use the metrics of sales and we don't have these frameworks and our sales team in Salesforce clicked the IRAP box 30 times. We need to go for this certification because we lost out on this much money. And so you talked about it earlier, that quantification is how can I take hours, person power, fraud, incidents, the kind of things that are maybe not directly affecting GRC as a team, But we're interacting with or we're forcing other teams to do or or PCI is. And so I use those to say, I don't want my life. I don't want my life to be easier. I'm just a I'm just a simple man. But my engineering team, I'm tired of bothering them. I'm tired of Slack messages at 2 a.m. saying, hey. You gave me the code, but it didn't have a date on it. You know, those are the kind of things where, and then you could partner with them as well as you go to them and say, hey, can you just add on the Jira ticket, like how much time this took or how many clicks it took or things like that. They're more than happy to say, yes, you are a pain in my rear. And this is how big of a pain in my rear you are. And leadership goes, okay, okay. All right, well. But I

Raj Krishnamurthy 1:09:47

think you're making a very interesting point, Ricky. And the reason is that engineers, tend to cost more. I'm talking about particularly software engineers. And they may outweigh or even eclipse the cost of GRC as a function. So in other words, what that means is a lot of value of what you're doing through automation accrues to that VP of engineering or director of engineering or the CTO organization. Do they feel that when you present these numbers?

Ricky Waldon 1:10:16

I would say that they know the numbers perfectly. Before I even tell them the numbers, their standups, their ticket queues, they ask questions all that. Why are we making this? Why do I all of a sudden have to know all the scripts on my payment pages? Well, the GRC guy said 11 dot something and six dot something. Anyway, I got to work on it's going to take 20. Oh, geez. So it does. It resonates with them. And they are, I will say it, my role now. And as I learned that I needed to be more technical and speak the language, I My last few roles, like engineering has been such a great partner because I can take their salaries or I can take something. I can take a measurement and say, I love what you guys are doing. I don't want you to be taking screenshots. I don't want you working on this stuff. I want to come to you and talk about security architecture for this cool new thing. Or I want to talk to you about this branch protection. You don't want to talk about it. So how do I work with you to maybe quantify it, even qualify, like just give me a story of how this day you woke up at 2 AM and take that. And then if it's going to the board or it's going to someone else, CEO, then I work with the VP of engineering or the SVP of engineering. And we couple our story of how he goes, well, I didn't want to do it. And I go, I didn't want you to do it. Let's combine our stories. And then you can go. And a lot of times my other selling point, which I will say is helped me a ton in my life. And I would, recommend everyone doing it is I work with all the other teams as well on projects they have and say, hey, it's not directly a PCI requirement, but I can help you get this tool because it sort of aligns to this. And so they're using, it's almost compliance as a service. They are using a compliance stick for a lot of their projects. They want to get a new onboarding vendor. Well, guess what? Background checks. I can kind of throw something in there. But, you know, so they're using me to get their budgets. And when you build that kind of partnership, come to them with a little ask and they'll go, you know what? You helped me get this. I wanted to go to GitHub EMU that you really helped with that. I'll help you. You know, I'll help you. And I'll say why engineering also thinks this is a good thing to buy.

Raj Krishnamurthy 1:12:30

Beautifully said. In fact, I would love to, maybe it's an entire session, right? I think enough to do a masterclass in terms of how people should partner and build these budgets. Because it's an interesting area. The reason I'm saying this is that many GRC professionals and leaders struggle with this, right? And it'll be super cool to sort of hear from you. Maybe we'll do a follow-up session sometime. Exactly. For a person who's graduating out of college and they are trying to enter into your team, What do you look for? What would you advise them?

Ricky Waldon 1:13:03

Yeah, that's a good, that's a great question. It's happening. I know a lot of people are, there's no jobs. AI has taken my job. So they, they, they're worried. I will say, and I'm, I've joined the board of advisors at my college to speak to the kids and the, you know, the future is, and again, I'll go back, back in my day is I find that your degree to me does not matter. If you have a degree, if you're coming out of the military, I don't, a whole lot. What you majored in is it's all about a GRC. Again, it's not the sexiest topic. So can you make it interesting? Are you hungry to try different things? When I fell into GRC, I fell into it at very, you know, quarterly access reviews for socks, very, very small portion of, of GRC. But what I did was I sat next to the business continuity guy, Howard Manilla, one of the great mentor that I had and still had great, great guy. And I was like, I said, hey, I don't know anything about business continuity and disaster recovery, but I see you have a really cool case with a really fancy phone. Can I help you test that for emergency? And he goes, yeah, go outside and make a call. So I was hungry to try these different things. I had another great mentor, Ed Amdahl, who he was building out a risk program. He let me build a form. If anyone has ever used InfoPath before, a long time ago, but he helped me build the form. But while I was building the form was why, what is impact and probability and controls and residual? I don't know what any of this means. And he goes, yeah, great. I'll let you, you're helping me. So I'll sit down with you and help. So it's, are you hungry? I can teach anything. Anyone in the world, my wife knows about PCI compliance controls. Controls are easy. Framework A, C5, IRAP, Cyberset. There's a control. There's a way to meet the control. There's some evidence for the control. You can teach a lot of people it. It's, are you hungry enough to learn about the tools or the business to implement something that makes sense? Are you hungry enough to bother someone to say, hey, I don't know anything about Identity verification during onboarding. Can I just, can you walk me through how to do a background check? Is, you know, bother people. Sometimes they don't want to work with you, but a lot of engineers, a lot of people, they love when people come to them and just ask. They don't tell, they ask. So I would say, you know, take a look at GRC. There's a lot of interesting things. I have been to 17 countries. I've been to over 20 states doing data center audits, doing other audits. It's an interesting role. Almost every company in the world has some sort of compliant. They have to meet SEC. They have to meet HIPAA. They have to meet, you know, TSACs. I want to work in the automotive industry in Germany. They got their own. There's compliance and regulations everywhere. And if you can just kind of figure it out and get into it, it's very easy. Well, I shouldn't say very easy, but you can transition to other frameworks. You might get super interested in, Doing SOX user access reviews, you may become an IAM engineer because identity management's that big of a deal. The other thing I would say, and this is a company by company basis, is you will make mistakes. You will break something. As a compliance person, even if you have no technical access to anything, my fourth month doing quarterly access reviews was I shut down an entire call center for eight hours by myself. A spreadsheet shut down half the business. And as you know, if you, the travel industry, a call center is very important to a travel industry. I was doing quarterly access reviews. I had a macro that ran in Excel that would, I was doing 62 different call centers, access reviews. We had two call centers in the Philippines and the way that the script was built, it didn't dictate everything. You had to look at the email address of each person to identify which call center they were in. Well, I had already done it a few rounds. I was, you know, I'm cocky 22. I got this. This is easy. I sent it out. I did not send it to the second. I sent all of them to the first travel call center. They came back and said, yeah, these users are all approved. I'm not quite sure who these are. We might have off-boarded them or they don't need their accounts. Great. Sent that to our tech team and said, hey, we need to remove all these counts. I shut down an entire call center. So my manager was great. The company was great. They've said, hey, this is the problem. We actually see the issue with how the script was built. We're going to modify that. We'll make it easier. Not all companies will let you shut down a call center, but you may not have production access. You may not have access to a single tool outside of your GRC tool. You're going to break something. You're going to shut something down. You're going to make a bad policy statement that people mess up on. It's going to happen. Got to be okay with it. It's not the end of the world most of the time, but it's, it's a great learning process of how to communicate or how to do a process or how our tools work or how a spreadsheet can shut down a whole call center. You kind of, you start to understand how these things affect other things and how to communicate. We learn from our failures. We don't learn from our successes. So make sure you fail a lot. Just, Maybe like two people at the call center.

Raj Krishnamurthy 1:18:25

Okay. No, I think with that, this was a fantastic session, Ricky. And I think you gave us a lot to think about. Thank you for joining the show.

Ricky Waldon 1:18:34

I appreciate the time. Thanks for having me.

Raj Krishnamurthy 1:18:38

Thank you for listening to Security and GRC Decoded. We are your go-to resource for staying ahead in governance, risk, and compliance. If today's episode resonated with you, we would love for you to subscribe, leave a review, and share it with your network. To dive deeper into these topics, visit us at compliancecow.com and follow us on LinkedIn for more insights and community conversations. Join us next time as we continue decoding the future of GRC. Thank you.