Episode 107 - Compliant but Exposed: Rethinking GRC for Real Security

Speaker A: Welcome to the Cybersecurity Readiness podcast series with Dr. Dave Chatterjee. Dr. Chatterjee is the author of the book Cybersecurity a Holistic and High Performance a Sage publication. He has been studying cybersecurity for over a decade, authored and edited scholarly papers, delivered talks, conducted webinars and workshops, consulted with companies, and served on a cybersecurity SWAT team with Chief Information Security Officers. His work on proactive of Cybersecurity has been featured on USA Today. Dr. Chatterjee has been a tenured professor at the Terry College of Business at the University of Georgia. As a Duke University visiting scholar, Dr. Chatterjee teaches in cybersecurity programs at the Pratt School of Engineering.

Speaker B: Hello everyone. Welcome to the Cybersecurity Readiness Podcast Series. I'm your host, Dave Chatterjee. Before we meet today's guest, I'd like to set the stage with a story. In May of 2025, Marks Spencer, one of United Kingdom's most iconic retailers, was hit by a cyber attack that brought its online operations to a halt. For weeks, customers couldn't place orders. Gift cards stopped working. The company was forced to pause new hire onboarding. Estimated losses climbed past 300 million pounds. The attacker's entry point? A contractor, a uh, third party with legitimate access whose credentials were socially engineered. That opened a door that no dashboard had flagged as a risk. The organization was by most formal measures compliant. However, this happened around the same time a well documented compromise of a third party support provider gave attackers access to customer data across multiple platforms, including Discord. Again, the breach did not originate inside the primary organization. It arrived through a vendor relationship that was presumably on file, vetted at onboarding and largely forgotten. Compliant on paper, but exposed in practice. These are not edge cases. They are illustrations of a pattern. Organizations investing heavily in in GRC platforms, building out compliance programs, generating dashboards full of green indicators, and still facing catastrophic breaches that those tools never saw coming. The gap between being compliant and being secure is not abstract. It is where attackers live. That gap is what we are exploring today. My guest is Richa Kaul, Founder and Chief Executive Officer of Compliance, a uh, platform purpose built to bring intelligent information to the GRC function while preserving the human judgment that distinguishes genuine security posture from the appearance of one. Richa, welcome to the podcast.

Speaker C: Thank you so much Dave. I'm so happy to be here.

Speaker B: It was a little bit of a long winded introduction and I apologize for that. But I had to set the stage and I also wanted to inform the audience that when we use the word GRC we're talking about governance, risk and compliance platforms. Uh, so Richard, how about you share some of your professional highlights before we get into the heart of the discussion?

Speaker C: I would love to. I come at GRC more from the regulatory, uh, side of things. I used to work in public sector, uh, first to be a, uh, consulting firm, and then actually worked for the State of Virginia or the Commonwealth of Virginia, if you're particular. And I worked in Richmond there and supported basically the creation of different policies and investments that kind of were a balance against some of the regulations and requirements coming from the state for tech companies. And so, for example, supported kind of the creation of things like autonomous vehicle security rules, drone privacy rules, and so on. I then moved into a role as chief strategy officer for an AI company. And there I did oversee security for the beginning of my time there and learned how the tech companies actually operationalize a lot of the regulation that I was previously supporting at the beginning of my career. And it was really eye opening to see kind of the difference in the intent between some of that regulation and the burden that it creates for these companies every day. And in owning this, I think for me it became really clear that the way that we're handling GRC today is suboptimal, to put it lightly. It creates a lot of work. It doesn't create a lot of insight. It checks a lot of boxes. It doesn't actually reduce risk. And so the whole idea of compliance with a why our company is to get to the reasons behind compliance or the why behind compliance and to help these enterprises automate the busy work and the admin manual tasks and really focus on risk reduction, which is the core of what every GRC team really cares about protecting the business.

Speaker B: Excellent. So you started this company because you were motivated by, you felt strongly about, like you said, suboptimal utilization of these platforms. So let's drill into that. There are several vendors providing these platforms with the relevant or standard functionalities. And let's assume companies are using it the way they are supposed to use it. So what's missing? What's the missing link or what are the missing pieces here?

Speaker C: Yeah, great question. So the core of this is that was any of the platforms that existed before we decided to start compliance, did any of them actually achieve the mission that I just said I would venture? No. So basically what happens is that a lot of the tooling that existed in the GRC space, in the governance, risk and compliance space, was at minimum was, uh, just centralizing data. It was just a repository of Data, a glorified SharePoint, if you will. At, uh, best, it was automating parts of existing workflows. Okay, that helps for sure. But what was missing was the next generation of technology that was actually doing the work on behalf of these clients so that their time could be freed up for the important work that nobody ever had time for because they were dealing with and running after these urgent items. And to me, it's about getting to the heart of why we do compliance. We do it to reduce risk. And if the tools are just going to help you centralize and maybe speed up a couple notifications to evidence owners, that's not innovation, that's not, that's not high roi. What is high ROI is a platform that allows you to offload that manual work to the platform, of course, with guardrails and controls in place, and then frees you up to focus on the really hard strategic work of risk reduction. And by the way, that's the work that GRC teams want to do, but they don't have time to do because they're always chasing, you know, the next audit or policy approvals or so on and so on. And now they have time. And that is a wonderful thing to watch.

Speaker B: True, very true. So, you know, let's hone in on the word compliance.

Speaker C: Yeah.

Speaker B: Let's say I represent an organization, I'm, um, the ciso, and we implement a GRC platform. The purpose behind implementing such a platform is it's going to help us be compliant with the relevant rules and regulations that comes down the pipeline. So my question to you is, when you implement such a platform, what are the regulations that it supports from a compliance standpoint?

Speaker C: Yeah, great question. I just want to tweak the premise slightly and just say that I believe that compliance with certain standards is a happy byproduct of really good security practices. And the idea of the platform is not to check the box on the standards, but rather to centralize your security practices and controls, monitor them, address and monitor the risks and so on that may be created as a kind of result of any gaps, and have the compliance with certain standards and audits be a happy byproduct of everything that is already in the solution that is working towards the bigger goals. Of course, some of our clients do see this as, hey, look, stage one, we just need to pass our audits. No problem. We support over a hundred frameworks and every cut and shape of them that you would imagine. Everything from SOC2, ISO, 27001, NIST, CSF to GDPR, EU, AI act, and you know, a number of things. PCI, DSS and so on and so on. So there's a lot of different standards that are in there, but I like to think of it as company a. What are your controls? What are the practices that you want to have in place? Let's lay those out. Oftentimes they're informed by controls, no problem. But let's lay them out and then decide. What does it mean for you to track these? What is actually required for you to feel the peace of mind that these are in play? Or in the inverse, what is a signal that this is not working? And that's where we start.

Speaker B: Okay, so that's great. Now you mentioned several regulations and again I'm thinking about it from the standpoint of. And you mentioned about audits, different types of audits, uh, security audits, and so on and so forth. So if the goal is to pass these audits, shouldn't it be implied that yes, my organization has passed these audits. That means my security state is like, it's not a steady state, I should be comfortable. In other words, I am trying to imply that when I'm in compliance, I'm at a certain reasonable state of security readiness. Is that a fair statement or is that a myth?

Speaker C: So I think it is all in the details. I think that I would actually almost answer this question by a company segment. I think that for enterprises, they are oftentimes with compliance does come a baseline level of security. And there's reasons for that, to be honest. Their auditors are more stringent. There's more subject matter experts on their team who recoup, just enforce by sheer presence of being there and knowledge of what it means to be actually secure, they are enforcing really good controls and practices. I think that when you look at startups very honestly, a lot of them don't have those same inherent checks and balances. They don't have subject matter expertise on their security side. They oftentimes are going for cheaper auditors who do less stringent checks. And I think the smaller the company, the honestly the less that compliance even really assures a baseline level of security.

Speaker B: You know, it's funny you mentioned about cheaper auditors. Uh, that brings me to share that in my first career I was an auditor, but I of course focused on uh, primarily financial audits, uh, not security audits. So I have, I know a few things about audits definitely. As an auditor you must be objective in your approach, do as rigorous a job as you can. However, there are always there are loopholes and which do get exploited. But on a related note, and this came out of my research as I was prepping for this podcast, audits are done periodically, probably quarterly, sometimes annually, which is not something I align with these days. It should be as real time as possible. But, uh, in between audits that time period, how do organizations ensure that they are maintaining the same state of readiness given the evolving threat vectors with the use uh, of AI? Everything is moving at such a fast pace. If the goal for GRC platforms is to achieve compliance, but compliance at a certain point in time, but not on a continuous basis, that leaves a gap, doesn't it?

Speaker C: A huge gap. And thank you for case in point making the point I was making earlier, which is why the goal of our platform at least is not passing audits. Again, compliance with a, uh, why? What is the why? The why is to reduce risks. You cannot achieve risk reduction with point in time. Not only point in time, but point in time samples. Because don't forget that when we're doing audits, it's not even like you're doing a complete assessment at that point in time. You are doing a fraction of the assessment that you technically should be doing to see visibility across your organization. So if you're once a year checking the anti malware settings of 10 of your devices across 500 employees, that is not giving you the picture that you actually need as a GRC team. What you need to do is first of all, of course, have an endpoint monitoring tool and link that right into a compliance platform like ours, alongside all of the other monitoring and different source of truth systems that you have. So you get one single pane of glass across your controls, flagging and alerting you of risk before it materializes into a potential breach and.

Speaker B: Exactly. And I like that because you want to make it as simple as possible for the organization, so being able to centralize it. So there, there's one dashboard where everything is visible and whoever is providing oversight, or whichever team is providing oversight, works off that dashboard and connecting all the systems to this, let's say your system or any other competitor systems. I like that design, that approach, that architecture. Now let me ask you this again. Based on my research, when the dashboard shows green, which means everything is in order, is that, uh, believable?

Speaker C: Great question. Okay, let's wind back to what we were saying before. As a company, ideally you are not just taking only the controls from your different standards and putting those requirements or your audit evidence requests as kind of your checklist. Ideally, what you're saying is, what are our Risks as an organization and what are the mitigating controls or things that we have to check for to show signals of potentially materialized risk? Right? That is the real starting point. That's the real starting point. And if that means that you do that initially by, you know, starting with your controls, so be it. At least it's a point. But then what you have to ask yourself is, okay, so based on these signals of risk, if I continuously monitor those, then I should be actually getting some orange or red on my dashboard at some point because it's just reality, right? Like businesses face risk, period, and there's usually at a certain, at least past even a minimum scale, there is always going to be potential risk affecting your business. And you should have a few red, orange, yellow things directing you to that, ah, source of risk and telling you, hey, something's wrong, you should take a look at it. But what a wonderful world that is. Right? And it's a pivot. It's a complete paradigm shift from today's world where we are prepping for audits. And honestly, at best, we're responding to risk real time when it materializes, okay, if we're lucky or sometimes the risk kind of materializes unchecked, like you mentioned with, uh, M and S and with discord. If you look into tomorrow's world, you're not focused on risk identification and responsive management. You're focused on risk reduction because the risk identification is happening automatically and you are now dealing with the outputs of that, which is basically potential risk, potential risk, potential risk. And your entire workday changes. There's an entire conversation to be had about what does the GRC team look like in a post agentic world. Right. Which we don't have to go through right now. But, uh, I hope that explains that shift and what I guess to more directly answer your question, Dave, I hope you're never looking at a green dashboard because it's almost always going to be nonsense if that's what you're really seeing. Because that's not realistic for any business today.

Speaker B: And see, that itself is an important disclaimer because when I'm looking at a green dashboard, let's say I should not automatically assume everything is in order. There has to be some guidance that will get the, uh, GRC team looking for those potential vulnerabilities. There are several factors here. One, organizations have to be proactive in their threat and risk management. So whichever tools and technologies they have in place or they should have in place to help them do that is definitely a step in the right Direction number two, there are tons of tools out there. It's a challenge for many organizations to figure out what combination of tools should they have in place that's going to enable them to do better security management, better security governance. So I'm trying to picture, where does GRC fit in in the bigger framework of security governance? Is it fair to assume that if you did GRC well, you would do security governance well? Or are there any missing pieces? For instance, using the risk label, how good are these GRC platforms in identifying the risks associated with humans falling victims to, say, phishing attacks? How good are these GRC platforms? So maybe you can answer my question by highlighting what are the strengths of these GRC platforms, which you've already done. So I'm not asking you to repeat everything, but a little bit of redundancy never hurts. Maybe more importantly, shared, what are the things that GRCs don't do that should be done?

Speaker C: Great point. First things first, the security team is larger than the GRC motion that I feel very sure about. The security team is the operationalization of many GRC controls. The GRC team is almost like the cameras around the house to make sure that things are working the right way. The security team also is in charge of the locks on the door. They're in charge of making sure that there's like a safe walkway leading up to the house. All of those things are, uh, the operationalization of security. And so therefore, of course, they require separate subsections under the security team, as we see every day today, including things like vulnerability management and many others, threat intelligence, monitoring and so on. What the GRC team does though, if done well, is that it has line of sight across the entire risk profile of the business and it won't like just, uh, to give an example based on the vulnerability management one I just gave, in a perfect world of grc, you have one, if not at least five to seven vulnerability management controls that are checking different things and they directly integrate with your vulnerability management tool to send up to the GRC team anything that's breaking the, uh, threshold of your kind of risk tolerance. Right? So, okay, there's 35 medium vulnerabilities. Maybe you don't need that to flag anything because that's not at your risk threshold. But maybe what it needs to flag on the GRC system is when there's been a severe or critical vulnerability that has been resolved within two days, now you want to start to flag that. Now you want to consider, is that going to become a risk. So at the end of the day your GRC should be the cameras watching the house should be that roof over the security and beyond kind of security compliance risk architecture across an organization that says I need to have eyes on, I need to be making good decisions about where we put our m money, about where we focus our time, all based on where the risk really lies in this organization. And unfortunately or fortunately, that's a really hard job. And so what happens is that in today's world, at best you're kind of getting silos of signals based on wherever attention has been put so far. But without GRC you're missing the full picture. And that is the most important thing when you're at a board level deciding where to put money, how to spend our time, how to make better decisions. So I hope that answers the question, Dave.

Speaker B: Absolutely, I think you've addressed it very well. So as you were explaining, a couple of things I picked up on and correct me if I'm wrong. So a GRC tool supports monitoring, supports detection. Does it support remediation of threats?

Speaker C: Absolutely. A good one should. So for example, in our platform there's two forms of remediation that are supported and again, just to recap, a good GRC platform is surfacing risk from across the organization and all the different source of truth systems that are looking for risks or potential risks in each of their specific domains, right, the GRC tools and surfacing that across the business and prioritizing based on risk scoring and risk quantification, which risks are the most urgent and what you have to go after. In our platform and I'm sure some others as well, there's a couple ways that you can kind of help to remediate that risk. One that I know that is more unique to us is that we have AI guidance built in for every control gap and that guidance can be to the GRC person or route itself directly to the business owner and it will actually even give step by step instructions on how to bridge a, you know, a configuration that might have gone astray or how to write, you know, maybe a policy that's missing a key enforcing mechanism or something like that. It will actually give you the instruction or do that work for you. It also helps you to risk plan. So basically what is the right treatment strategy, what are the steps that I should take? And basically auto creates and assigns out tasks to the risk owners for any follow on steps and then tracks that progress and reminds those folks to do the work because right now that doesn't happen. And so it's about taking it from A perspective of, okay, I'm going to respond to this risk after it's materialized to saying, okay, I now see the risks beforehand. I'm going to prioritize them for the ones that are, you know, past a certain risk threshold or tolerance for my organization, I'm going to action them some right away and some will be escalated to the risk register where we have a longer term treatment plan. That's it. That's great GRC right there. There's not much more that you really need to do, uh, but it's really hard to get to that point. And it's complex, especially in our level of clients. We have Fortune 500 companies and household name organizations and they're complex. It's a hard thing to achieve.

Speaker B: Okay, so you explained the various functionalities. One functionality that I'm very big on. I recommend companies do a good job of logging, recording the various events that have come to their attention, what steps or actions they plan to take, or they are taking what they ended up taking. Because these logs are helpful, particularly in a court of law, if and when an organization is accused of gross negligence or so and so forth. Uh, based on the way you describe the GRC platform, I would think that such a platform will allow for quick creation or generation of these logs. Is that a fair inference?

Speaker C: Yeah, they are actually quite inherent to the platform itself. I think a lot of our, even security leaders, you know, CISOs who enter our platform, their teams are working in our platform all day, all week long. And when something happens, or maybe when there's an audit finding, you know, at best they might want to look at. Okay, well, what are some of the actions that have been taken in the past against this specific topic? It's really easy to find that, so. Exactly right.

Speaker B: Okay, fantastic. Now let's talk about, uh, the risk that comes with connecting with vendor systems. When I introduced this episode and I talked about the two incidents, and for both the two incidents, the malware came from vendor systems, which is a very common way for the vulnerability, uh, to be exploited. What role does GRC play in reducing vendor risks?

Speaker C: My goodness, it is such a critical part of grc. When I think about risk today for an organization, I basically see three sources where that risk information can come from. The first source is from your control gaps, which is exactly what we've defined. What are the things you want to have in place? How do you monitor them or pick up signals that there's risk? That's one source of potential risk. The, uh, second is your third parties. And we're going to go into that in a second. And the third one is actually risks raised from the business, which requires an immense amount of training, which is now becoming easier with our new AI agents. But again, we'll hit that at the end. So these are the three basically signals for risk that you need to have true risk visibility across the org. Of these three, the hardest one is third party risk. And that's because there's so much that you don't know, it's not within your full control and there's a lot of trust that's involved. Now, if we break this down right, if you think about the MNS attack, for example, it was a combination of third party plus social engineering. That is tough. That is really, really tough. Really tough thing to, uh, kind of manage. But the reality is that when you're onboarding third parties, there's an entire third party security review process and workflow that should be happening with all potential risks identified in that. And then of course, all of those need to be addressed and closed out as and how possible based on the criticality of the vendor. I'm not suggesting that every single vendor goes through the same level of scrutiny, but there needs to be a prioritization of critical vendors or tier 1 of vendors based on, for example, what data they have access to, um, how critical they are to your infrastructure and processes. And for those ones, yeah, the process has got to be really tight because you should see it as an extension of your own business. And I think that's where a lot of the gaps happen.

Speaker B: Absolutely. I couldn't agree with you more. Vendor management, um, assessing the security posture of vendors is a hugely important aspect of the vendor selection process. And you have to continuously evaluate. There has to be an oversight team or an individual who's constantly in touch to make sure that the vendor systems maintain the same level of security as the client organization. Or else, uh, you have to revisit the agreement and have a serious discussion. So in this whole vendor management space, let's assume the client organization is big enough, has resources enough to afford a GRC platform, and they have one in place, but the vendor organization doesn't have one. Is that a big deal?

Speaker C: Depends, uh, on the criticality of the vendor. I would say in almost all cases it is a big deal. Of course, if this is a Tier 4 vendor with access to only public information, then, okay, whatever, it doesn't matter so much. But the second that vendor crosses the threshold into having either your customer's pii, your employees PII, or any sort of sensitive information about your company, then it starts to matter. And what really matters is when there's sub processors of customer data. So I will say, Dave, when I talk about third party risk with clients, sometimes it feels daunting. And even as I hear myself talk about it, sometimes I feel like, oh, I'm setting up someone to feel like this is overwhelming and I don't want to do that. And what I really want to do is say, look even at our biggest clients, Fortune 500 companies, they have been able to draw a clear line around their critical vendors. There are tier one vendors, the ones that really, really matter. And for those ones, they trace back what is every point of data that we have with them, what is every potential interaction point that somebody could exploit and they close those because in reality it's the tier one vendors that really matter the most. Once you have that done, then you can move to tier two, then to tier three. Then I don't think you actually need to do tier 4 if it's only public information. So it starts to make it a little bit more bite sized and manageable. And you use AI to help you. I mean honestly, really, that's the only way we've been able to do it. Even us, internally. You have to use AI to send those questionnaires, review those folks answers, review their evidence, otherwise you don't have time to monitor. All of your vendors use, uh, AI to do vendor monitoring. All of the tooling is available in our platform, but moreover, it's just what is required at this moment.

Speaker B: Excellent, excellent. So another question that I have to ask you before we, and we still have time, I'm not rushing to uh, close this episode and the question is, and I use it a lot in my talks and in my writings, that we have to go past checking the box kind of a mindset. We means the organizations, organizations must be more substantive in their approach to security governance, security control. For instance. Let's say there is a requirement that there should be regular workshops, training workshops for increasing the level of awareness amongst the organizational members in terms of the do's and don'ts. As far as security controls go, uh, that's a basic standard, let's say, and almost all organizations that I know of achieve it by having programs in place where their organizational members have to go and access a portal, listen and watch stuff and then they answer questions and they have to sign off saying that they have completed the program. So that's one level, however, a more advanced and a more effective form of governance or awareness, uh, security awareness. Is when it is customized, when it's contextualized, when it's immersive, and when there are mechanisms to assess how the level of knowledge has improved or how these programs have become more effective. I don't see much of that because that's a bigger ask. That's a bigger investment, though it's substantive. But often organizations shy away from that. Why bother if you're able to check the box and get our certification or whatever the goals are. So coming back to again, compliance, since we are having a discussion on compliance and obviously we're talking about compliance as a best practice or we want it to be done well. So would you agree or disagree with this natural inclination to somehow check the box as opposed to doing it very well? So where am I going with this? I feel that a really good GRC platform will not allow an organization to simply check the box. That platform will ensure or it'll raise red flags if the organization is not either implementing or enforcing the security controls. Well, your thoughts, your reactions?

Speaker C: Yeah. The difference between bare minimum, meeting the box and actually being secure is the difference between treating compliance with audits, ah, as the end all, be all, and actually thinking of passing audits as the happy byproduct of good security practices. I just am going back to what I said at the beginning because I really believe that this is exactly the point. I mean, employee training one is a great one. Most of these standards require annual training that can be a PowerPoint deck or a click through upon hire in your HR platform, who is that helping? There are so many more potential attack vectors on employees than we give it credit for. Give these folks credit for, for fighting every day. And I think that it's about saying, what are the risks to your organization? What's the quantification of this risk and how much do you care? And what I will say is that the smaller companies, I'm um, going back to segments, the smaller companies have a higher risk tolerance. Right. Because they have other things on their minds and bigger companies have a lower risk tolerance. And therein, I think, lies the lies, the actions that you take to go above and beyond checking the box. And uh, should the GRC platform help with that? Absolutely. Should it force them into it? I think that's an interesting question. I think the reality is that a GRC platform should have the tools to allow you to go far beyond checking the box. It should offer you the tool to monitor compliance and risk. Exactly. Custom to your organization as you see it, and not as a factory cookie cutter approach to passing SOC 2. And that has been my firm belief in the way that our platform has been built.

Speaker B: Thank you for saying that. And that also aligns with the framework that I use to advise organizations. It's called the CPD Framework Commitment, Preparedness and Discipline framework. As I'm m listening to you, I literally uh, can hear these three pillars of security governance come alive like commitment. When we're talking about commitment, we're talking about leadership, ownership and accountability. So even in the context of GRC management, there has to be uh, somebody who takes ownership of the effectiveness of this platform, making sure that it is being used as appropriately, as effectively as possible, and more. And then when it comes to preparedness, that refers to the operational capability to enable organizations identify, assess and respond to the different types of risks and threats. And this is where once again, you have to hold the GRC platform. I don't know if accountable is the right word, but maybe use this as a benchmark to assess the effectiveness of the platform. And then finally, discipline, uh, is about sustenance, is about systematic execution that is embedded in the organizational processes. It's uh, institutionalized within the organizational processes. So these three pillars of commitment, preparedness and discipline, they are critical whether we are talking about vulnerability management, whether we are talking about identity and access management, whether we are talking about vendor risk management, or in a bigger way, if we are talking about GRC management. So I really, really, uh, think this episode has gone a long way to dispel some of the myths that GRC is not just about passing an audit or somehow getting through with compliance. It is much more than that. My final question to you is, as an organization, when I'm trying to make a selection of a GRC platform, what should be the evaluation criteria? How should I go about evaluating the offerings out there?

Speaker C: The first thing that most folks overlook is that it has to be a configurable platform. If it's not configurable, what's going to happen is that you are going to be shoehorned into the processes, the fields, the restrictions that are set by the platform's capabilities and metadata itself. And that doesn't work for a world in which you need to be managing compliance and security tailored to your organization. So that's number one. Number two is actually around agentic AI right now. What's happening is a shift in how people think about grc. We're just at the beginning, but I can see, partly because I feel like I'm helping to create that next reality of what GRC is going to be and it requires AI agents to do that manual work to free up the GRC team to actually take on the strategic risk reduction work that needs to happen. And third, what is really overlooked, I feel oftentimes is the implementation partnership. I think, uh, software is only as good as its implementation. And a lot of times people overlook that in the process in favor of whether it be price or name brand or something else. And again, it's that partnership that actually brings the product to life for your org and it's that change management that makes sure that people actually use it. And without that, it falls. And so I think for me, those are the top three things I would look for if I was out there buying a GRC platform today.

Speaker B: Well, thank you so much, Richard. This has been such a pleasure. So insightful. We'll close out the episode, but once again I'll turn it back to you. Any final takeaways that uh, any final messages for the audience?

Speaker C: I guess this conversation has been so lovely, Dave, in part because I've had the chance to talk about about the philosophy that connects my true beliefs about GRC and security with what we're building. I sometimes think that in these philosophical discussions we paint a picture of an ideal state. And I think that it is not only daunting, but can sometimes feel unrealistic. And I want to just check us before we close out today and say that don't let perfect be the enemy of done. Progress is still progress and we're to going working towards a state of, uh, true automation and risk. Visibility brings you so much closer to those things than not doing it. And so even if it feels a little idealistic and we've let ourselves be our most philosophical selves on today's call, the realities of organizations can get closer and closer to what we're talking about with that effort and focus. Just wanted to end with that.

Speaker B: Fantastic. Well, thank you again for your time and insights. Looking forward to talking to you again. A special thanks to Richa Kaul for her time and insights. If you like what you heard, please leave the podcast a rating and share it with your network. Also, subscribe to the show so you don't miss any new episodes. Thank you for listening and I'll see you in the next episode.

Speaker A: The information contained in this podcast is for general guidance only. The discussants assume no responsibility or liability for any errors or omissions in the content of this podcast. The information contained in this podcast is provided on an as is basis with no guarantee of completeness, accuracy, usefulness or timeliness. The opinions and recommendations expressed in this podcast are those of the discussants and not of any organization.

Speaker D: Um, SA.