Transcript
A (0:00)
Foreign.
B (0:09)
Welcome to this episode of GRC and Me Logic 8's podcast focusing on the latest trends in GRC and cybersecurity. I'm Megan Manifold and joining me today is Eric Tseng and Vikram Carr from Google. I'm really excited to have you both here today as we dive deep into continuous assurance and automation. Welcome. Welcome. We're going to start with our myths and misconceptions section. And I'm going to start with you, Vikram. So let's talk about continuous oversight. So continuous oversight is perfect for the first line of defense, but auditors don't need to know about it, right?
A (0:46)
Yeah, that's something that's often said. We hear this a lot when we're talking about the need for containers, continuous monitoring, and introducing more automation. I think that statement somehow sandboxes and it takes compliance away from other IT disciplines. It somehow makes it so that compliance can't be automated. And oftentimes when you look in like the way organizations run, compliance organizations can be placed at a cyber security area. They could be standalone, there's different things like that. But I believe that, you know, anything should be open to continuous monitoring, testing and auditing. It's basically just introducing automation into the space. And in order to do that, you need to have standardization. So in terms of like, other lines of defense and potentially third parties benefiting from it, I do think that generally there's a lack of standardization in terms of like, how can we actually communicate what's needed for a particular compliance requirement or privacy requirement, and how do we share that between say, a cloud provider, a customer, a third party auditor, a regulator, different things like that. And there are proposed standards that are in place for that. But there's no reason why right now a second line of defense, third line of defense, a customer who has to audit, a SaaS provider, a cloud provider, or even a third party auditor can't look at evidence that's been automatically collected, evidence that has been generated in a more automated manner. And there's no reason why internal, you know, internal to us. Again, the second and third lines of defense can't benefit from reviewing data that's collected in an automated manner. I think probably the most important aspect of continuous assurance, monitoring, testing, auditing, is that it really forces you to understand how a control operates. Because when you start thinking about how to automate something, you have to make sure that you have a comprehensive understanding of what the business drivers and requirements are. So this is a very basic software engineering principle. You know, you, you need to have requirements, otherwise you don't know what you're really doing. And you know, the really important aspect of continuous assurance is that it's a forcing function for an IT organization. It forces you to go through an exercise where you look at a control, a very high level statement around your compliance and you break it down into how it's implemented. And each of those implementations have to be mapped to like specific assets in your IT environment. So if you're telling me that you have a vulnerability management program and you are doing vulnerability remediation, you have to understand the exact specific assets that those vulnerabilities could impact and how you're remediating them and that any auditor, regulator should care about it. Because without any sort of continuous testing approach, you're basically just operating on the concept of trust. I trust the evidence you collected is valid. So you know, I think that everyone can benefit from it. The challenge we face is that this forcing function requires a lot more effort on everyone's part up front. So we can do the proper data collection, data analysis, asset inventory mapping work, which IT organizations can really struggle with. But once you have that in place, it really can reduce a lot of toil down the road.
