Drata x Tevora: Proving the Value of GRC in a World of Continuous Change

What if your GRC program could do more than prepare you for audits?

As organizations face expanding regulatory requirements, evolving security risks, and increasing executive expectations, GRC programs are being challenged to deliver more than compliance. The most effective organizations are transforming GRC into a continuous operating model that strengthens security, improves efficiency, and supports measurable business outcomes.

In this expert-led discussion, Luke Mueller, Associate Manager of Strategic Services at Tevora, joins Joshua Struts, Director of Security and Trust at Drata, and Justin Lane, Principal Channel Business Manager at Drata, to explore how organizations can evolve beyond periodic audit preparation and build a continuous GRC program that creates lasting business value. Together, they’ll share practical strategies for connecting compliance activities to the metrics executives and boards care about most, while scaling governance without starting over.

Key Takeaways:

• How continuous compliance helps transform GRC from an audit exercise into a strategic business function
• Ways to connect controls and evidence to executive metrics like risk reduction, operational efficiency, and deal velocity
• Real-world examples of expanding framework and regulatory coverage without rebuilding existing programs
• Best practices for maturing your GRC program while keeping pace with evolving business and compliance requirements
• How partnering with experienced advisors can accelerate GRC maturity and strengthen long-term resilience

Whether you’re looking to optimize an established compliance program or build a more scalable approach to governance, this session will provide practical guidance for turning GRC into a strategic advantage that supports both security and business growth.

This is a best practice series that Drata puts on. We typically like to do this series once a quarter, four or five times a year. We really try to do this series when we have meaningful, insightful content, just through our conversations with customers, our conversations with partners, being out in the market, to try to really bring to the forefront a topic that is topical and relevant for modern GRC. The format for today is really going to be a 45-minute presentation with Mr. Stutz and Mr. Mueller here, plus some moderated Q and A at the end. The topic for today is proving GRC value while frameworks, regulators, and board questions keep shifting. Throughout that constant change, continuing to prove the value in this world of continuous change. The panel today, who you’ll hear from myself, Justin Lane, channel business manager here at Drata. I work on our partnerships team and work with our partners nationally. We are joined today by one of our great national partners, Tevora, Mr. Luke Mueller, Associate Manager of Strategic Services at Tevora, and also Josh Stutz here at Drata, Director of Security and Trust. Gentlemen, maybe just brief intros here at the top. Josh, you want to start, and then Mr. Mueller, you follow.

I’m Josh, Director of Security and Trust at Drata. I’ve had the pleasure of being at Drata almost five years, building the security and trust program from the ground up, and helping 1000s of customers along the way, prior to being at Drata, I started my career as a security engineer at J.P. Morgan, so I had hands-on experience building security controls at one of the largest enterprises, and now get to help large enterprises build out their security controls and programs. Looking forward to talking to Luke and the rest of you guys.

My name is Luke Mueller. I’m associate manager here at Tevora. Tevora is a cybersecurity consulting company, and I help support the strategic services team. Meaning that we help a lot with enterprise risk management, privacy, third-party risk management, as well as a lot of the compliance pieces when it comes to mapping a lot of these frameworks and things like that. Excited to talk about how we see some issues with our clients and the solutions that we’ve helped in the past.

Thank you, gentlemen. Just diving in here, what we’ll cover today and the topics for conversation. Really, four sections, and then as I mentioned, kind of some live Q&A moderated by me. We’ll move from the new GRC reality to the operating model. Talk about some executive metrics, being able to quantify those, discuss the value relative to them, and then end it with managing change without rework, continuous rework. As we go through this, please feel free to drop your questions in the chat section. I will call all those, and then we’ll have a segment at the end for the last 15/20 minutes for some Q&A. Please add your great questions in there, and we’ll have a discussion at the end. 

Let’s talk about the new GRC reality for enterprises. Compliance is now just table stakes. Proving value isn’t. It’s all about proving trust, enabling the business, and so the current state is most enterprises already had some, at least one, established framework like SOC 2, and they’re now being asked to expand rapidly, generally with same resources, doing more with less. Executives want clear line of sight for GRC investments, and they don’t want to just renew SOC 2. They actually want to see the value being delivered, and so we’ll talk about how we can do this with the new operating model in the future. But first, let’s like talk about the previous state and how we got here. Luke, what are some common pinpoints like the old GRC world?

I would say from a lot of the old GRC world, what we see is that you know the compliance work still operates in that buyer drill state. You have a lot of those audits that come in. You’re trying to meet those requirements, those deadlines. You might even have new customer deals. New vendors are coming to ask for, hey, do you have better certifications? The more updated certifications, ISO 27001 updated framework. A lot of other privacy or other risk, kind of frameworks. They’re all getting these new updates, including AI things of that nature. There’s a lot of framework expansion that’s happening, but what happens as a result is folks are really focused on really the audit time period, so really working on those the kind of fire drill state there. Also, what that leads to is some duplicative work. Folks are siloed in their state of, I need to get this ISO certification. I need to get HIPAA, PCI, whatever the case is, and it really creates that duplicate work, inconsistent controls. Folks are really focused on those driving those pieces there. 

What would you say is maybe like the top framework expansion that that you’ve seen recently?

I would say a lot of folks are seeing a lot the ISO 27001, and then also trying to get the SOC 2 right. A lot of folks are trying to understand, from a SOC 2 perspective, I’m trying to add this for a new customer, something of that nature. How do I tie those altogether? We’ll go through some use cases to kind of explain that how we’ve helped support that. I do think that is a very common control mapping piece that we often see.

Are there any examples of fire drills that happened a lot in the past that we want to avoid in the future?

Yes, I would say that’s a good question. Really, what we see in the past there is especially what’s coming up with a lot of the EU AI Act things of that nature from a lot of the AI regulations that’s coming down the pipeline is folks trying to get certified or are folks trying to meet that compliance requirements there, and so there’s a lot of the speed up of how do we address this from AI, how we incorporate those controls and really make it fit into our organization. The key piece there is how do you frame it to you know leadership? Everyone wants to adopt AI. Everyone wants to have these great capabilities quickly to the market, but you have to do it in a way that provides value to them, but also ties back to your risk piece. The overlap there really comes from all those different frameworks there.

With everybody moving so fast into AI, a lot of these new requirements and frameworks like EU AI Act, it’s not opt. in. You have no choice. If you’re serving businesses in the EU with AI, you’ve already built AI into your product. You now need to be compliant with it, causes an immediate fire drill, and we need to be on top of this with this new operating model.

There’s a lot of overlap that there actually is. You see it with SOC 2, ISO, those access reviews pieces like encryption requirements. Logging, monitoring-the the wording slightly differs there, but the evidence that expectations might slight slightly differ too. But really, at its core, the underlying control is the same. There’s an opportunity for each framework to kind of arrive at its own project, its own deadline, and it’s often owned by different owners, but nothing forces that into a shared control set, I think what’s key there is kind of unifying it all together, figuring out those deltas, and building it from there.

That’s a great segue into the next topic of the operating model of how can we achieve that continuous compliance. We have the two durable layers, not just one annual scramble to renew an audit at this point. For continuous monitoring, automation evidence, we have Drata as the system of record. We have our DCF framework for the Drata control framework that maps 10s of frameworks and requirements into one Drata control framework. With new AI frameworks like AIUC one, they’re asking for specific logging requirements that already maps to have a system for logging a control for logging. Now we just need to extend this to another framework, so it reduces repetitive work. Having tools like Drata gives you this live posture where leadership can see overall control readiness, not just tied to SOC 2 readiness or ISO 27001 readiness, but the whole picture of control readiness as a across the entire board, and that’s only half of the picture having a tool to help with the automation. The other half is designing the systems, getting advisory information on what are the new requirements and that’s where partners like Tevora really come into play too. Luke, on the operating, the human operating layer, what should customers look out for?

It’s really from our perspective; there’s the technology people and process. Like you mentioned, they’re drawn to help support with the technology piece. It gives you the capabilities that you need to see help report that up to the board. One thing I do want to emphasize too: what we see, especially with the change in driving requirements from executives, is they’re wanting to have more real-time data. They want to know, at its core, what’s this costing the organization? Whether it’s an audit, whether it’s the controls, a lot of those pieces and how we see it framed to executives. It’s really important to tie it back to some sort of risk, that way it’s a little more backing rather than hey, this is just an audit finding. So what I would say from from the Tevora side, right, is the the process piece that comes into play, How we help support organizations is we help walk into people’s environments, understand your culture, what’s going on with the requirements you need to do, what you’re trying to sell, what are the cases that come from a business perspective, translate that into the cybersecurity language and jargon there, and then able to translate that to then executives.  Who may not have necessarily that technical background, but they also want to understand from a financial perspective or an operational perspective. How does unifying it and using a unified control framework really set that set that apart? One of the big pieces I see from the operational layer, to really create this not to prevent that annual scramble there, is really creating a unified control framework. What we see with other organizations is there’s a single set of controls, where each control is mapped to the requirements for each of the frameworks. It also what the key differentiator of successful implementation of that. Often, what we see with some unified control frameworks is it’s just table mapping all these different requirements, all these different pieces. It gets confusing to control owners. They’re not sure what they’re owning, what they’re doing doesn’t meet the key measurable outcome is then associating a certain risk to that. That helps not only the control owner have some buy into understanding, why am I doing this, but also helps translate that to executives and their expectations of how do you address that? What we see from that perspective too, right? A risk taxonomy, right? Ultimately, you have a list of the company, you know, risks, cybersecurity, whatever the case is. It’s written really in the business language. It’s not something that, maybe from an engineering perspective. Super technical people can understand. It’s also translated to really those core executive level business language that everyone will understand. Then ultimately, some examples of that, would be like an authorized access to production data, exposure of customer data through a vendor, stuff like that. Ultimately, the findings that associate that control, you can map that to the risk, and that really creates the audit output usable in an executive conversation, rather than being, “Hey, we are 94% compliant, or X, Y, and Z.

Jonas Services, a great system of record for a risk register where you can track those risks. But as you’re mentioning, just tracking the risk alone is not enough, right? We need to establish these governance routines of like quarterly risk reviews and things like that. What other examples do you have of governance routines that are aided by tools like Drata?

I think the key piece is right. You have that that merging of the technology and presenting that versus the governance routines that built behind that in the process. Typically, what we see is having some sort of risk counsel that’s associated with that. You have leadership that has buy-in and visibility into a lot of the risk decisions that happen. Typically we see that at a quarterly basis, right? They review risk list. You’re reviewing those risks that you have outlined. You review the exposure that comes from that, and then ultimately making those risk treatment exceptions or acceptance or mitigation treatment decisions there, aided with another monthly control review. It’s maybe an hour session, whatever the case is, depending on the scope and size of your organization. But really, it’s where you meet with the control owners and talk through. Through the regular auditing or review or the technology or automation we have in place, where do we see any failures or drift? Especially when it comes to incorporating AI, into maybe pulling some information or using some automation there. How do we really address the drift as we see it proactively right before the audit? Or that kind of immediate, emergency put out the fire. This preliminary assessment has led to us finding some controls weren’t operating as intended. We now have to do an expedited remediation review before our formal audit. Things like that. That’s where you can catch up proactively in that monthly control review, and then adjusting as needed there. Finally, that third layer is going to be that that independent validation. You’ll have that audit and certification cycle to have that third party come in and help validate that. I think that’s a good piece to kind of shift slightly over to a little bit more on the, how do you connect it to those executives. They’re going to come have some insight into those governance routines, but how do you actually, really communicate that to the executives there? 

Tying continuous compliance into what executives actually care about, the big three buckets are risk reduction, revenue impact, and operational efficiency. My personal favorite is the revenue impact, especially it being like a B2B business. It’s much easier to use revenue as a driver for pursuing new compliance frameworks than trying to quantify $1 value associated to a risk. If you can set dollar values associated to risks, I think that is a great way to go. But many times, it’s hard, so it’s a lot easier to say, if you have $100 million in pipeline for federal agencies, that is a great justification to go for a framework like FedRAMP. Asking for budget to pursue FedRAMP to just to pursue some of those controls to reduce risk is one way. If you can say, if we implement these controls and we can become FedRAMP compliant, therefore unlocking 100 million in revenue for these federal agencies that we have in the pipeline, that’s like a no-brainer. For leadership to pursue going in that direction, the CFOs love that. Where you could say, “Hey, we are able to close deals faster. We’re able to have shorter cycles. We spend less money on these projects.” That were the core revenue impact there. Of either cutting the costs or allowing us to find potential new opportunities. I think is a very good driver for that.

With tools like Draw and SafeBase, I love being able to put dollar values to the controls. With SafeBase, we’re able to see how many customers are requesting a specific report or document from our trust center. We could see how many customers are requesting our pen test report, and then if there’s a specific pen test for a specific product, we can see how much revenue is being driven by like interest in, a pen test for a new AI product or something like that, and that can justify improving compliance and adding controls in that space.

What other examples do you have, Luke, of operational efficiency as a metric to track.

That revenue impact, that’s really good with CFOs. Folks are focused on the financial impacts of compliance. The other piece there is then when you talk to the actual control owners, or the executives that are really more focused on the operational side of things. One piece that what we see there is that there’s a lot of that less manual evidence collection. Fewer rework cycles, when those frameworks change. Ultimately, you’re able to tie that back to the risk the control owner is going to have really the dashboards. The one pagers and things like that. It really creates that ability for the board to understand where they stand at that point in time, rather than that typical, you have the risk and the control implementation there. It’s kind of done at the audit. You have those metrics right after that point, but over time, when you go to do either a reassessment or something else, that evidence might be stale, that reporting data might be stale. It’s kind of a reactive control there. Operational efficiency too. If you’re able to showcase, engineers, you go get these evidence, these showcase. Good example would be, show me your Active Directory. Groups and things like that. Screenshots of that nature. You’re able to then have engineers focus on more of the core work they want to do, drive the innovation and pieces where they’re helping improve a product or whatever the case is, and then having that less manual input there. Then they don’t get burnt out. They get fewer reworks. They don’t have it tied to that operational efficiency there.

Everybody will love spending less time on compliance, and if you’re able to say, how much time it took last year to pursue a framework and become compliant? Let’s say like 400 hours for SOC 2, and then you can pitch with Drata and Tevora. It’s it maybe will only take 40 hours. I think that’s a huge unlock in getting time back for the whole team across the board.

I think how you can really measure that and how we see that presented to executives in that the metric perspective is, there’s the control scores trend over time. You also have the incidents or exceptions rates that are tied at that. So, if you see the control health improving, we’re having quicker audits. We’re able to pass those things, and we see that our number of incidents or exceptions to the policy or controls are falling. Then that should show that as we improve our health and continuously monitoring that, then those exception that score is being managed. That helps kind of reduce the risk there. Also, what you said, the other metric that we see there, is time to a test across those multiple years. We see that speed increasing year over year. You’re able to correlate that with the audit findings too. We were able to do this assessment in six weeks compared to eight weeks last year, and there was only two critical findings versus six last year. Things like that, really to show that timeline is shrinking, and speed is coming from the readiness and the continuous model that you’ve built there, rather than that those pieces there. One other piece I would add there too, is then the before and after program maturity. Of how do you tie that together with business opportunities that come out of that? A good example would be pipeline, maybe you’re trying to do a new deal with a new vendor the security review from either a TPRM perspective or other program pieces you’re able to show, this deal that came in was stalled because we didn’t have enough answers for the security questionnaire or the evidence requests therefore it took us six months to go through that validation process through the next year of their review or anything like that. We were able to reduce that by another two months. We have that speed and ability to have those opportunities tagged and kind of showcase that that that build and that measure there.

Absolutely, and so tracking and communicating these KPIs is one thing, but visualizing them to show it to leadership is another. What tips do you have for dashboards? What should dashboards look like for leadership?

The dashboards you got to keep them simple and focused. When you have the leadership in front, they’re only going to take a few minutes at it. You’ve got to really create it focused on trend lines and the business impact. Ultimately, what we see there, is keep those dashboards simple and have it with those trends over time. Kind of what I alluded to or mentioned there, is over time, we saw these incidents drop. We have all those pieces kind of tracked over time. You have those trend lines that show that it’s either decreasing or increasing, and then you’re able to really have those dashboards then tied to stories that are anchored data. A great example would be, we had this control failure for an ISO audit or something like that. It delayed three deals. Ultimately, those three deals, here’s what’s changed from that perspective. We saw that risk, we were able to identify it, we then implement the change that is needed, and then here’s ultimately the driver. Here we’re able to recognize that revenue now, or we have the ability to move quicker to market in order to really create that missed opportunity there from that perspective, I think what great from working with partners like Drata, is that there’s that ability for you to gather those metrics within the tool and then create the dashboards that work for your business. There’s customization that needs to happen for every business. Ultimately, organizations will have their own ways of how they want to interpret it, and really surface those metrics. I really do think try to leverage that data that pulls from different tools, that will help drive that ability to meet those the change there. Josh, you want to speak to how Drata is kind of help with those dashboards?

You’re only as good as your data, right? And so, Drata having continuous monitored tests that are gathering evidence every single day, we have a real time dashboard of what your compliance posture looks like, rather than the old school just data points once every three months. It’s really hard to tell the picture of what does it actually look like today, and so with Drata having hundreds of connections and data points, we’re able to get daily insight into what our compliance program actually looks like.

I would assume from the risk registered pieces that you guys have within your platform, that helps tie all those numbers together and really associate. Here’s our compliance obligations, but how do we associate that with the risk that comes from either having those controls or not having those controls? The overall impact it might have on an organization. Ultimately, what you would want to have is, have that tied back to the risk thresholds that are defined, in those governance pieces that we’ve discussed a little bit earlier. That risk would then drive the ability for you to prioritize what controls need to be addressed first, and the biggest impact there, to where you can get that conversation with your executives and have the investment or the buy-in from them to have kind of a justification of why you need these certain things to be put into place.

Having the data lets you connect the dots of connecting a specific risk to a specific control. That we can come up with control remediation plans directly mitigating risks and seeing risk burn down as control readiness goes up.

I think that’s a probably a good transition then into your ability to manage that constant change. That you have all these new frameworks, new requirements that are coming in. How do you actually perform that? How do you manage that change without all that rework and stuff like that? I think from our perspective, we have a couple of use cases here. Josh, before we go into that, do you want to talk maybe a little bit about the typical change drivers and things like that.

As I mentioned at the start, a lot of this change we don’t have a choice. If we’re already using AI tools and there’s now new acts like the EU AI Act, we have to adapt to this change in requirements and the old failure mode leads to those fire drills of trying to solve this problem after you’re already in it. But if you’ve already done the work up front to have the unified control mapping and things like that, it sets us up to be able to adapt and change really fast, it’s critical to have that playbook to be able to adapt to the change without having to do complete rework. What are some real-life examples that you guys have seen at Tevora?

We can go through these use cases in a second, but I think a piece there that we want to emphasize is the common failure pieces that come into play here when you have these new adoption pieces or these customer-driven requirements. What we see common failures with a lot of our clients who try to do this from their perspective, is they try to stand up these parallel control sets for each framework. You have ISO 27001, you have PCI, you have HITRUST, HIPAA, whatever the case is.  You the different owners, the GRC team might have ownership of actually supporting the audit and pieces behind that, but the control owners are then having multiple requests, those parallel control sets that they’re required to meet, and then GRC is coming to them every couple weeks; I need this evidence for this audit, I need this evidence for this other audit. That creates a lot of failure from really just the presenting of GRC as a partner rather than kind of being the kind of the pre auditor right there, the nagging and things like that other piece would be then okay when you have those parallel control sets then rebuilding the evidence request lets that come from the edit every audit and that that drives through that going back to the same teams repeatedly asking for same or similar data. It creates this tension between a lot of the control owners of they don’t take either the audits as seriously or they are just getting burnt out having to respond to these pieces here. How we see that play out in a couple of use cases here. For example, this med tech company that we’ve worked with, they’re really a SOC 2 organization. They had it required that their product to have the SOC 2 certification there, but in order for them to do some work into an international deal or anything like that, they wanted to their client or customer wanted to have some sort of ISO certification. What we see from a rework perspective, is SOC 2 in the ISO Annex A kind of requirements there. A lot of that piece, a lot of those control pieces are covered.  You’ve got approximately 70% that are documented risk treatments that are already coexisting with the SOC operational controls. What was missing there in this case was the ISO documentation. A lot of the specific ISMS policy pieces, the documentation that an ISO auditor is going to want to see versus the SOC kind of documentation pieces there. What we see in organizations, either from our perspective of helping support that, is doing a risk based gap assessment, mapping against ANXA, and then rather than going against the cold start of an ISO project, starting from scratch, understanding scope, system build there. Ultimately, it’s the separation of the genuinely new risk that comes from the ISO requirements. What the risk is already be treating with those SOC pieces, and then facilitating those risk owner workshops. You know that really boosts that statement of applicability. That work that’s already been done. Ultimately synergizes those pieces. You work from the net new, and then you’re able to pull from the previous control set that you had with SOC two. You already have the risk buy-in.

The risk understanding from a SOC perspective, and therefore you can leverage some of that information there, or adjust the actual evidence you’re pulling for that assessment to be maybe a little more specific to meet the more granularity there right for ISO that might not be necessary there for SOC 2 or other requirements there and then ultimately what helped prefer the outcome of that is we had on a period of four to six months, the readiness was reached in six to eight weeks, They’re able to really streamline that process and have that unified, and they’re able to do it a lot quicker to get that certification. They’re able to then be quicker to the market to win that deal, and then you can showcase that. Mention those metrics of how do you meet that core business driver there of, we’re providing value because we’re able to get these deals done quicker and have that trust with our partners or customers wherever the case is. Anything Josh from your side on the ISO front or anything from a kind of the mapping there from your perspective.

I think you summarized it well. If you’ve done the work up front to unify your control framework, if there’s already 70% overlap, it really reduces the work that the control owners have to do to extend it to these additional frameworks, and so the other great application is all these new AI questions and the new AI frameworks that are coming in. As I mentioned earlier, if you already have a control for a logging system for SOC 2, and now you’re pursuing an AI framework that’s requiring some specific AI logging requirements. Instead of building a whole new system for logging, you just need to figure out what new AI specific logs do I need to send to this existing logging system, and that’s something my team is working on right now as we pursue AIUC one. From the start, we’ve already eliminated probably 70% of the work there.

The use case that we’ve seen in AI front, is NIST AI RMF has already been out there. ISO 42001’s already been out there. Obviously, the EU AI Act, even other regulations that are coming out. I know the current administration has some gold AI kind of requirements and pieces that are coming out as well. As folks who are adjusting to these AI requirements, the rework that we see with some of these AI governance pieces is a lot of folks have these processes in place. If they already have some of these certifications for you know ISO 27001, they have SOC 2, whatever the case is. They just have to tie it to the risk and use cases that kind of come from incorporating AI into that. So really, what we see in our advisory work from the AI perspective, is how do you scope as you do those risk assessments, as you do those compliance assessments? What are the use cases of AI that really drive into production and then help prioritize really those NIST, ISO, other functions that match the real exposure. There might be risks that have, like you mentioned there, Josh, logging and monitoring there for AI activity. There are potential gaps that could be closed there. Very easy rework there compared to kind of building it from scratch or whatever the case is. There are other pieces that we see from underlying business need. For answering security questionnaires, like for third party, what we see is, AI is being leveraged to help answer those questions rather than the manual yes no type in those pieces, add a little more assurance but detail that’s needed. But ultimately, it creates that kind of combination there. Of the ISO, those requirements are being added net new, but it’s tied to the risks that AI associate there, and then you’re able to then get the buy-in from leadership to prevent that, AI leaking data through a third party like what happened to OpenAI just recently, things like that you have the risks that are tied in exposure there and then they buy into those pieces to address that so it doesn’t happen to their team.

Another great benefit of this partnership of the dual operating model is working with partners like Tevora as to help with advisory advising on scoping for these new AI frameworks. So like ISO 42001, although Drata might already have access to monitoring across your entire organization and system of controls, maybe only some of it is relevant for ISO 42001. It’s helpful to have advisors who are experts in that framework come in and help you course correct before you over commit and gather evidence and build this program with too broad of a scope.

I think a key piece to there, is having advisory that has helped communicate some of these risks to executives, and how do you translate that to really make that work for your organization. One of the pieces that we see with a lot of the unified control framework issues, or people adopting multiple frameworks, it comes down to clear ownership too. Who owns what? Who’s covering the controls? Who’s controlling the risks? Who has the remediation obligations? Therefore, then you have it documented. That’s where advisory from Tevora comes in. We help you create that ownership model. The racing matrix that you need to have, who treats it, how do you approve the exceptions, the workflows, really the programmatic pieces behind it, in order for you to then leverage tools like Drata to really drive that the capabilities, the metrics, the monitoring, the automation pieces that you need to have to really drive the continuous improvement there, and then allows you to adjust and pull everything together there to really drive that continuous engineering piece right to where you’re pulling all that data. You’re able to reduce, from an operational perspective, that fatigue, things of that, from your actual control owners. But then also have it to where risk ownership and buying happens there too, where you create that that culture of risk rather than a culture of audit and compliance, and responding to these audits here.

I think these have been great examples on this new state of GRC and how we can continuously monitor, continuously adapt, and continuously grow the programs. With that, are there any other topics, Luke that you want to cover before we maybe jump into opening up for questions?

No, I think I think we covered a lot of it. How do you tie it back to risk, and how do you communicate that to the executive boards? We could definitely have deeper dives for folks who are interested in exactly how that happens and how we see that actually communicated in the metrics, but I think we covered a lot of that concept we want to cover today.

We did have some great questions come in. One of them was from Francisco Cabasis, who asked what to do if you work in a startup and your boss never wants to have meetings for reviews? Kind of as a good follow-up, Anir Desai from Tevora chimed in. Thank you, Anir, for adding that. Anir, the director of risk and strategic services at Tevora mentioned using dashboards and one-pagers and escalations that are risk-based has found really work really well. What do you gentlemen think about that, or anything to add to that, or thoughts on that question?

If your boss doesn’t want to have meetings or reviews, you better have good dashboards, right? And let the data speak for itself. If you have up-to-date data, it’s correlated. You have dashboards that are clearly communicating the health of your program. I think that can be just as effective as having a meeting like one-to-one. What would you answer that, Luke?

You have that data that backs what you’re saying, but I think you also got to try to drive into what is your boss’s ultimate outcomes. You have the conversation of, what’s your driving requirements here? What is your goals for our team, either our security program, whatever the case is, and then associating really that the metrics that you need to meet that. For example, maybe you report to a CFO, something of that nature, to where they care about in the in line bottom line what’s the revenue impact. That’s where you then can have a lot of those controls that are put into place. We’re able to reduce the audit times. We’re able to reduce the amount of emergency audit pieces that we need to have. The audit remediation activities that may happen before, so we reduce the cost of those projects. Those don’t happen because we’re continuously ready. You kind of create it that way. Operational side, if you report to CEO or CTO or whatever the case is, you have a different kind of piece that, we’re reducing the amount of asks. We’re reducing the amount of findings. We’re reducing the control response times, from control owners, things like that. So that way you shift it to the appropriate audience. There, what we see sometimes is if you come in with to a CEO and you say or a CFO, we’re operationally reducing our overall response times. They go, okay, great, I don’t have that as a driver. That’s not important to me. If you’re able to shift that right with the data that you provide from your tiller or anything like that. That’s really where we see a lot of those big gains and steps to get that executive buy-in that wasn’t there originally.

Another question, kind of in the in the same lane as framework scale and change management. What’s a realistic timeline for transitioning from more project-based audits to a to a continuous compliance model? I know that can be subjective, but in in a broad sense.

Step one: getting the tools to be able to do this continuous monitoring. Onboarding to a tool like Drata only takes days. While there’s much more to this project than just onboarding to Drata, that’s the starting point. Drata will start continuously collecting data, monitor tests, setting you up for the unified control framework with the Drata control framework from day one, so that it’s going to make your overall project much easier in the long run.

I think it’s something that you can even start building as you’re going into the development of your program. Ultimately, depending on the number of frameworks that you have, where your existing maturity is, sometimes we could see it happen in a few weeks where you’re able to spin it all together. Maybe the scoping there, the assessment, the baselining that you’re doing from really understanding your obligations, overarching kind of assessment. There, it could take a couple weeks. It could take a couple months. I think from our perspective, it’s all kind of dependent on your business. I know Justin kind of led that, it’s a little subjective, specifically depending on the business. I hate using the consultant answer. It depends, but really, it comes from having the core buy in too. I think if you have the buy in from leadership that this is a revenue or this is a benefit to your team, you’re going to have a longer timeline, more resistance from the organization. You’re going to have a lot harder time to get this fully implemented. Tying that back to the risk, and then tying that back to metrics that can get that buy-in is where you could drive and accelerate that timeline as you use tools to deploy it and things like that.

Excellent, and kind of along those lines, but leading more into the operationalizing the compliance. Where do partners like Tevora fit, Luke? What should you keep in house versus lean on external expertise for? Any thoughts relative to that?

Where the advisory comes into play is when you are either stuck hitting a wall trying to really drive those risk conversations with executives. How do you actually translate that to what matters to them? We help with your internal teams are going to have the daily control operation, they’re going to have the hygiene, they’re going to have the system ownership and the knowledge and the base to allow for that that we wouldn’t have right from the outside firm perspective. But where our advisory comes into place, is helping you design that control framework and tying that risk taxonomy to really drive those metrics. And then we also help with the judgment and deciding which risks are having that methodology either your internal risk methodology or other commonly risk methods of how do you assess that risk? How do you tie that to the controls? How do you translate that that’s how we come in help make those risk decisions and then ultimately doing a scope review with you, rather than to really drive. We’re committing to certain control requirements or control programs larger than maybe the situation requires for you. And then obviously that fourth piece there, we add that advisory piece capability. If you need additional headcount, additional support to actually perform the work. There is expansion opportunity for us to help support that as well.

Francisco Cabeza asked another great question here. Could you explain a bit? Explain this a bit more, maybe with some examples. Advisory scope the assessment to real use cases, and talk the client out of a full ISO 42001 bill they didn’t need.

Part of that use case there is, in this case, I’m trying to frame it right here. Right is this individual company was looking to. They had ISO 27001. They were looking to expand some of their AI use cases or their obligations to meet those requirements. But really, the core of what they were using was more Gen AI than agentic AI, and more the streaming controls that were in place there. There are certain controls that come into play for the full ISO 42001 audit. They were just trying to showcase that their use of Gen AI is kind of offloaded to some of the pieces of the third parties. The SaaS tools that they used OpenAI, whatever the case is, versus really them having their own AI development where they have to do a lot of that drift. The other controls that come into place as a the terminology is escaping me, but the AI controller, something of that nature versus the AI kind of processor kind of user. That’s where we help them kind of descope, ultimately drive that to where they can get the certifications that they need in order to meet their obligations or help kind of showcase that have that AI capability without really driving that full blown ISO 42001 audit, having all those use cases defined, things that maybe not have been at scope for them. Hopefully, that answers the question there.

Great example. I recognize this name, Sashan Sharma, one of our channel managers here on the partnership side, Sashan said for companies or asked for companies that are investing heavily into Gen AI across the organization, what compliance standards should they pursue, or what would be the best foundation for them to build?

I say ISO 42001 is a good place to start. Good foundation. It depends on what you mean by Gen AI across the organization. If you’re building out like agentic AI products, I’m really excited for the new AI UC1 framework. That’s kind of shaping up as like the new SOC 2 for AI agents, and Drata just announced support for that last week, and we are pursuing it for our actual Drata agents in the future, and I’m really optimistic of the future of that new exciting framework.

I would say kind of piggyback on that too, the ISO 42001 that’s been that’s been out for a couple years now. That’s what happens with a lot of this legislation and obligations and AI. Europe really comes out as a leader in establishing those frame core pieces, and then U.S. obligations that come in NIST, for example, is another NIST AI or MRF. That I think, is a good secondary framework to use as well. Ultimately, it has a little more flexibility for your organization if you’re not really trying to get that ISO 42001 certified per se. There’s kind of a risk that comes, or risk balance that you have there of how much investment you have, what you alluded there, Josh. There’s Gen AI, which is like, you’re just going to use it for generative, ChatGPT, the generative AI versus agentic AI. If you have the agentic AI use case. I would definitely focus more on the ISO. They have a lot more better controls, explicit pieces that help drive and reduce a lot of that risk. Versus, the NIST AI RMF has a little more flexibility in how a business actually addresses those controls. Allows you to really drive really your use cases. Picking back off that. Both are good, but I would say ISO is your strong leader, and then the NSAIRMF helps support that.

Thank you, Josh. Thank you, Luke. Those were all great questions. Thanks everybody for submitting those and for participating Today, in closing, a few key points. We talked about GRC continues to move from being more project based to a continuous operating model, and that shift is what we perceive is really unlocking real executive value. Continuous compliance as an operating model unlocks better metrics, less rework, and really just stronger positioning for GRC as strategic within the enterprise. Draw it into Tevora. Lastly, Drata and Tevora together, we can help organizations design that operating model, implement the tech, and then really guide change management throughout the entire process. A reminder to all attendees that joined today: This session has been recorded. We will make this available to you on demand. You’ll see a follow up from us. In the way of next steps, really encourage anyone who joined today share the recording within your organization and your GRC partners. Please feel free to reach out and engage with Drata and Tevora for a deeper assessment or our GRC value workshop. If you’d like to see the software in action, I know we had we had a question out there about the software. I don’t think we quite had time to showcase it, but please reach out. Feel free to engage with us. I believe we’re adding the information right here. There’s some of the outreach and the contact information there in the in the Q&A box. You don’t have to capture or scribble it all down furiously. We will send this recording to you in a follow up as well. Thank you to our speakers. Thank you, Mr. Stutz. Thank you, Mr. Mueller. And again, thank you to the audience. Thanks everybody for joining today. Really appreciate you attending and giving us an hour your time and participating.