エンタープライズGRCを継続的保証へ刷新する――Hyperproof創業者Craig Ungerが語る

Welcome, everyone, to the Emoid AI in Business podcast. Today's guest is Craig Unger, CEO and founder at Hyperproof. Hyperproof provides a unified platform for managing risk, compliance, and security workflows across complex enterprises. Its software helps organizations stay ahead of regulatory change, quantify and connect risk to controls, and maintain continuous assurance across business units, vendors, and emerging AI-driven operations. Craig explains why Fast Stop Start Regulatory Change is pushing enterprises to treat compliance as a continuous state rather than an annual audit, and why risk and compliance teams can no longer operate in separate silos. He also discusses standardizing one set of controls across multiple frameworks, connecting those controls to the organization's risk profile, and expressing risk in dollar terms so boards can see how much risk each compliance activity reduces.

Today's episode is sponsored by Hyperproof. In this episode, we cover why breaking down the silos between risk compliance and AI governance is essential. To go deeper on this topic and learn how leading organizations approach AI investments more like a venture portfolio and why interdisciplinary collaboration is critical for defining the right data for AI success, download our free PDF report beginningwithai at emerge.com.aik1. That's E-N-E-R-J dot com slash A-I-K-1 to download your copy. Now the conversation with Craig. Craig, welcome to the Emerge AI in Business Podcast Studio. Thank you, Yolande. A very interesting conversation waiting for us and for our listeners. Something that we keep noticing, especially this year, I think 2026 is definitely the year of all things changing,

is that the rules also keep on changing and they don't sit still. But as much as they're changing, they're also re-changing, if that's even a word. We've seen a big security rule for defense suppliers being paused just before it was supposed to start. We've seen Europe push back its main AI deadlines by, what is it, almost a year. And at the same time, inside companies, there is this very different culture around risk compliance and AI where everything is still in separate corners and not working together. So I guess that's where I want to start with all of this going on. What's creating the most friction points for GRC and risk leaders right now? I would say there are three main things that I would talk about with respect to that question. The first is absolutely the pace of regulatory change that's going on, and that's a phenomenon that's going on across the EU and the United States as well. In the EU, you have the AI Act, which is concerning itself with how you document your usage of AI, how you monitor to make sure the AI isn't suggesting things that we wouldn't want to happen to real people,

how you manage the overall risk portfolio that is touched by the AI, being transparent, and just overall oversight. The Cyber Resilience Act is another one I would call out in the EU. I mean, this is more on the manufacturing side, and this is really around the first phase being exploited vulnerabilities need to be reported. That particular mandate has actually come into being and is enforceable on September of this year. So we're about a month into that right now. And then in about a year from now, there's a newer mandate around full application security, secure by design, a secure bill of materials, how you handle vulnerabilities. And that's going to be enforced by each of, I think, 12 member countries. And the penalties are pretty significant. It could be $15 million or as much as 2.5% of your global revenue, your global turnover. So those are a couple of examples. But, you know, those are just the most recent. I mean, even nine months ago, if you would have asked me this question, I would have talked to you about NIS-2. That came due October 2026, and that's really pretty pervasive in terms of a requirement across Europe

that has to do with minimum risk management measures that you have to take, so risk analysis, how you handle incidents, and, of course, a very large and increasing concern in the industry around third-party risk and security. So that would be your supply chain security. And it turns out that this, too, has to be enforced for organizations of 50 or more employees or organizations that have more than 10 million turnover, which is 100,000 different organizations. Quick note on DORA for resiliency. Maybe we'll talk more about that later. That's just the EU. And then in the U.S., you've got a whole set as well. The ones that I'll touch on here fairly quickly are the ones that are related to government. I think you touched on them before. But you look at like the CMMC, which is really a set of requirements around how security is handled for all suppliers to the Department of Defense, right? And there's a kind of progressive set of requirements and audit requirements that are being kind of re-looked at right now, which we'll touch on in a minute. But there's been a lot of effort already in the base of companies in the United States to meet CMMC. FedRAMP is another one. That's been the mainstay of how you sell to public sector in the U.S.

You have to be FedRAMP. There's been low. There's been moderate. There's been high. There's a whole new framework called FedorM20X, and that's a modernization of this, mostly so that you can cut down a bit the costs of actually doing the preparation and the audit so that more organizations actually can do it and do it faster. Those are just some examples of some of the big changes. I would point to a couple of other things around the fact that there's what I would call regulatory rubbernecking. This is a term that I came up with like two weeks ago for another discussion I was doing. But I think what it really does is it captures the idea that you touched on, Yolande, that regulators are fervently and feverishly trying to come up with new regulations that protect, you know, in the case of security, but also in the case of different permissions and privacy that may be violated by emerging AI technologies. Those are, like, important forces on the system that regulators are really working hard to keep up with. At the same time, you could point to several of these different initiatives, including the EU AI Act and including CMMC in the USA, that have been slowed down so that the government can go back and say, hey, what really is the right set of requirements that are necessary in order to make sure that we can get the widest swath of companies to actually kind of comply with it?

And the rubbernecking idea is the idea that there's a policeman. It's a popular term in the U.S. for when there's an accident on the highway. So there's a policeman who are the regulators. They're trying to move all the cars through really, really quickly. But at the same time, they have to slow them down because there's some event that's happening off to the side. In this case, the event, in many cases, is the advent of AI, right? So how do we actually deal with that event while still trying to move the cars in really, really quickly? And what you get is a start-stop type of motion from the regulators. Yeah. So I'm wondering with that, what is the smart move there? So when a rule gets paused or pushed back, what should our instinctive response be? should we keep building or should we wait and see what happens? I mean, it's a little bit of both. I mean you know you absolutely we seen that the most forward looking organizations absolutely keep building but what they tend to do which is the right thing to do in almost any regulatory environment is they tend to focus a lot of their effort on standardization the kind of standardization that will bring them benefits no matter what the regulatory environment looks like. And, in fact, that is kind of a key challenge of the environment as it stands,

is that when the forward-looking organizations have the energy and the focus to actually standardize, you know, a whole bunch of organizations really don't. That's one problem. But the ones that do also face problems because when they try to standardize what they're doing internally, they find that it doesn't quite match, like, all the different frameworks, right? They vary within region. They vary across region. And so what happens is there's a lot of, you can call it compliance debt, that actually adds up in the form of kind of small changes and modifications that have to be done to different processes or not just the processes themselves, but how you document them and how you communicate them out to your stakeholders. And so there's a little bit of a death by a thousand paper cuts going on there that really leads to just a very large volume of work challenge for people that are engaged in compliance and security. So that's a major thing. In fact, one last thing I'll say about that is it's kind of interesting. We talk to some of our larger customers or the busier customers who are doing multiple frameworks, and we say, hey, let's think about how much we can automate this compliance journey.

In our products, we have automations that you can use to bring in data from your whole environment. You can test it, all that stuff. But a lot of what we hear back is we're so busy doing audits, we don't have the time to automate. And that's kind of a funny thing because if you just took a little bit of time away from doing the audits, the audits would go faster, and then you'd open up more time. So I think that kind of challenge around true standardization, the lack of the ability to really standardize across all the compliance frameworks and regions, and the total volume of work that that creates is really one of the biggest sets of challenges that you see with a very active regulatory bodies. Yeah. Okay. So friction point one is the pace of regulatory change. We also think about different departments within the organization. They all react differently to the changes as well. And now thinking about the volume of work, is it also possible to see some things happening twice because we have the risk part not communicating with the compliance part, not communicating with whoever is in charge of AI governance?

I mean, I think it's very common. I would say that the compliance and risk areas in an organization today, for the most part, are fairly silent. And you can start to see that if you look at the kind of vector of communication and interaction between, let's say, an engineering team and the compliance team. It's very rigid and structured. It tends to happen along, you know, this kind of predefined schedule. I need you to provide me evidence that shows me blah. It's not really predictive or prescriptive coming from the compliance organization. It tends to be more of a forensic look back as to whether we did the right stuff. And so that is kind of a piece of the story that as organizations mature, they really need to break down those silos between the organizations and get them working both in a more facile way but also in a more continuous way. And that's something that we hear from a lot of our customers, which is the way that we really ought to be preparing is where we collect evidence every day, not just for an audit, but, like, we're constantly making sure that we're compliant

because it's not really an end in and of itself. It's an activity we do to make sure that we're secure and that we're treating all of our stakeholders' data in the proper way, right? So we want to do that continuously, but we're audited once a year. And that kind of dichotomy, you know, we can talk for an hour about that. It causes a lot of strange behaviors in how well-meaning people who are doing compliance kind of have to behave in order to really get the certification they need and the proof points that they need. Yeah, and I think that's a friction point that most of our listeners will be able to think of and identify immediately just from hearing that. And our thinking from the listener side, thinking from the other side of this, four years, like you just mentioned, compliance meant one big audit, a single snapshot at a specific time. And I think the thing with the snapshot is it's kind of outdated the next day already. So it's not accurate. And it takes us to how do we even think about continuous compliance or continuous auditing. But then also at the same time, we have our boards asking us harder questions than they used to ask before regarding risk and all of that.

So a lot of things to think about. And I think everyone will be able to identify the problem areas. But how do we fix them? What modern capabilities and connected workflows will enable organizations to move beyond reactive compliance towards something that might be more unified, more measurable, and just give us that continuous assessment? Yeah, it's a wonderful question. I think first we'll just start with an observation, which is that compliance has really evolved from a point in time activity to a state of being. So it's something that's a state that you want to preserve through the whole course of the year. That's what leads you to this kind of observation that continuous compliance followed by ideally continuous audit is really the way to go because that's what actually keeps you in the state. The same way that there are silos between the different individuals that are practicing part of let's call it the development and operational lifecycle of a company. So developing and operating their code and their websites and their processes and their apps and all those different things. There's also silos between the different functional areas that are important to practice in order to be compliant.

So those would be things like your policies, the requirements and frameworks that you need to comply with, the controls, processes, and activities that you're going to go through with all the time, the quantification of the risk that all these pieces bring together. Those are siloed as well. And so I think one answer to your question starts with organizations realizing that they need to bring together more of a platform, right, that has a lot of these capabilities in it where these capabilities are aware of one another. A good example of that would be that whether you're updating a policy and making it tighter or you're adding more evidence to a control or you're identifying and mitigating a new risk, all of those things should actually have some type of quantification for how you're doing. That type of quantification, whether it's through a dashboard, a report, a score, whatever it is, should also be something that's really easily shareable with the important stakeholders, whether it's your CISO, your chief risk officer, and the board itself, which will very, very likely have an audit member that's actually assigned to the organization. So I think that is a key piece of it, is kind of choosing technology and a platform that has all the pieces that you need.

So you can kind of make more of a platform purchase than just a kind of single app and kind of iterate over the apps. but then also kind of set it up in a way where everything is aware of what the other pieces are doing with an eye towards where you want to go in terms of communicating that state. So we're thinking that we can't have our list of risks on the one side, and somewhere in a different spreadsheet we have our controls listed. Those things need to work together. They need to be connected. Is that the right assumption Absolutely I mean I think in some organizations including a lot of forward organizations the entire reason to do any compliance activity at all is so that you can control risk Now, that's not uniformly the case, but it's kind of among, I would say, the more mature organizations. They realize that it's the risk that they need to control every day, and the compliance activities helps them. There are other reasons to do compliance. One is the government tells me I need to do it, and I've got to do it, and I've got to go ahead and check that box. Another really important one is my customers ask me, and I'm not going to be able to really get that deal or unblock that business without showing that kind of maturity.

So, you know, there's a lot of good reasons to do it, but if you look at it, I think the risk piece that you're mentioning, Yolandi, really, it does kind of permeate all of them. And we personally at our company, at Hyperproof, we believe that a lot of the compliance activity, most everything you're doing in compliance, really should kind of put to the overall risk profile of the organization. and that that is a connection that sometimes we like to talk about it as the connection between operational compliance. These are small things that happen overnight when new proof gets automated in or whatever might happen when you're not looking, and then how that adds up to a strategic view of risk that may be held by, again, the CISO board. So I think connecting those two things is a great way to kind of like chart your course and make sure you understand what the goal is of all of these activities. And I guess with that, we'll also have our risk team and our compliance team work from the same information. So we'll kind of avoid having to do double the work. But what else will it change for them? Or how would their daily workflows change once they can use the same information to base their decisions off?

Well, one way to think about it, you know, without going too deep into the workflow, is that, you know, risks can sometimes be thought of as, you know, that kind of loss or that form of loss that would happen when a particular set of threats emerge, right? And they could be info, set type of threat security, but they could be acts of nature. They could be all kinds of different things, political, and all those different kinds of things can present threats that actually end up, you know, materializing a particular risk. Now, the answer to your question about, like, the benefit of connecting them is that the controls that you're using, which are really just the fencing in for the processes that you're running in your company, those are meant to actually attack the threats. They're meant to mitigate the threats. So the more threats you mitigate, the fewer of them actually end up showing up as some quantified risk, right? And so that's where the connection happens is actually really carefully thinking about what you need to do to control the risk. I will tell you that some organizations do that. Some organizations don't. And what they do is they look at the controls that they need to pass an audit in particular because the people who are doing the audits have a very – sometimes can have an opinionated view of what they need to do.

And there's nothing wrong with looking at that. Passing the audit is an important part of it, but we do believe that the company that needs to be broadened out. And when you think of your compliance as a state, you think of controlling your risk as part of that state, and you want to put the activities to where you're trying to get to, you know, with those metrics. Okay, that makes a lot of sense. I want to get into the quantification of risk as well, because when I think about risk, you always think about a red light popping up or something saying high risk or maybe just color code it in some other way. But I'm sure that if you change it to risks in dollars, we do get a better response or maybe a real response from the board. Why does that help when we report to the board? Why does it help to quantify it in monetary value? There's probably just a couple of really simple reasons why that helps. One is the dollar figures. We like to think of the company, by the way, as red, yellow, green is kind of like one way to do the risk, and the other way is dollars and cents or euros and cents. Okay. The reason why is that it gets people's attention. And there's always a fear of like not wanting to be on top of a loss of however many dollars. And at the same time, there's actually a real sense of satisfaction of really watching that risk number go down.

And so it's the difference between like when you take activities like putting in a new control, it's kind of the difference between generally feeling better and actually like going to the doctor and knowing that like, you know, you don't have this particular disease and like you've actually taken it down and your financial risk is much better off, your job is secure and all that stuff. So that's probably one of two main reasons. The other one I would say is that there are some organizations tend to look at the compliance activity and the costs associated with running that compliance activity as justified by the risk that it reduces. So there's a very practical implication there that if I want to actually invest in compliance, software, people, processes, and all those things, policies, I'm going to need to show what the dollars and cents risk reduction is. There's a set of people that want to see that. Last thing before we get into the leadership part of this conversation is, so I'm just wondering, obviously, if we think about continuous auditing or just being ready at any time for an audit. It also kind of gives the idea that, okay, so we'll obviously have a lot more alerts,

a lot more noise maybe. So should we see that as a good thing that we get to solve those little problems as we go and we don't have an overload of alerts once a year? In any system, you can tune it. What we found is you can tune it so that there's too little or too much notification. You know, we've definitely, in the course of the history of our experience, we've had people say, hey, I love all the data, but can you kind of like give it to me in a digest form or get it to me twice a week, all those kinds of things. I think the key is, you know, here going forward, the most forward-looking way to talk about this is to say that there's a baseline of making sure that what your system is watching and monitoring is communicated out in a reasonable way in terms of frequency and volume. Okay, that's there. But the more interesting forward-looking way is to think about how technologies like AI can come in and actually really separate the wheat from the chase. And when they say something like, okay, well, you know, we always want to make sure, and by the way, just to kind of refer to the first part of the discussion, this is an important part of what the regulatory agencies want to see.

I mentioned it earlier. They want to see that the human is in the loop right at the right time, and this is like a perfect use case where it's like, hey, how does the AI learn and tune itself looking at the different things it's communicating and the things that are motivating particular behaviors or lack of behavior and ignoring from your side? And then kind of summarize it into decisions that the AI can make on your behalf that you opt into. But those decisions cannot just be based on some searching of the web. That really forms the basis of a lot of the data the AI gets. It's got to be based on how you interact and operate with your data, which is somewhat of a reason why these kinds of systems, whether it's a GRC system we're talking about or other B2B systems, right, are still incredibly important in this AI age. They have the proximity to the data, to the people in the workflow, and the business process. But they can be married with this incredible method of really being able to summarize large bodies of data from within the app and out there on the web to make better decisions and then hone the workflows.

And that's the way you'll get to what you need is by teaching the AI what you want. I guess it ties back to also your AI appetite and knowing what you need for your institution or your organization and knowing how much AI to allow into the workflows That basically what you base all of those decisions on. So I know that we have leaders listening and they've been agreeing with everything that you've been saying, but their reality is on Monday morning, they're going to walk into an organization where the teams are still split. The data still lives in 10 different Excel spreadsheets, and the next change in regulations is already being speculated or already being discussed. So what needs to happen here? If they want risk compliance and AI oversight to work as one motion, where do they even start? I would give the same advice to anybody listening here that I would give if I were asked that question outside of this particular discussion, which is we have something we've developed. You don't have to use ours, but I like ours. we have a maturity rubric that we use for your compliance, risk, and maturity.

And it's got a number of stages. And it's hard to give a singular piece of advice because a lot of organizations are at different places in their maturity level. It's one of the things that we talk to them about when we first start engaging with them. How many people are on compliance? How many audits have you done? Have you standardized controls? Different things. Just to give a somewhat brief overview of what that maturity model looks like. Ours, in particular, has five stages to it. The first is when you look at your organization and you say that compliance is ad hoc. Processes, you know, nothing's really written down. Processes just depend on the individual who's working on it. There's not really a central governance function or really nobody's really managing risk centrally. So those organizations are leaning on auditors and a lot of external risk, external advice to try to get to a reasonable place. The second one would be where you kind of defined and documented the processes that you're using for compliance. What are the roles? What are the responsibilities? who's doing what and when. You may still be in a reactive mode over there, but you've got structure in how you react, the same way you might react to some kind of security incident.

You have some structure, you know who's doing what, and you know what needs to be done when. I talked about the third level before, which was around standardizing. So that's where you want to standardize and try to apply the same processes across multiple business units, multiple products, multiple subsidiaries, and importantly, multiple frameworks in multiple regions. So what that practically means is I set up one set of controls. I map it to multiple requirements because that's my one set of controls. Why? Because it's not really geared towards a particular compliance framework. It's geared towards a set of security policies that I think are the right policies that I want to follow. And obviously you have some knowledge of what the regulators want when you're creating that, but you feel that that's what works for your company and its systems. And so then it's documented, and then the processes are documented, and then you start to get a little bit more ahead of the game. The fourth is what we call integrated. We've already talked about this as well. The silos come down. This would both be silos between the different people involved, the business, the risk team, the IT team, the security team, all those,

but also the different modules and capabilities, policy talks to controls. Controls are mapped to risks. All of these things in the way that we talked about. And then the final is what we call optimized. That's where when you're already able to almost really run compliance at the state, but now what you want is the most predictive and adaptive type of environment that you can have. So AI is on the lookout. You have long-running agents. They're actually showing you different things that really need to be addressed in the organization. You have a system of prioritization, and you're really tackling a lot of these issues before they ever come up from any kind of external body or other stakeholder. So we have a method of implementation that guides you through getting to this, you know, through the maturity curve. And I would say to your specific questions, first map out where you're at, then look at the next level and say, well, what do we need to do to get to that level? And I think that's really a good suggestion. Great conversation. I think I'm going to have you back on the show in a while. And I really want to deep dive into risk there as well. So a lot of our listeners already think about,

I think they now understand that the rules are going to keep on moving and that's not going to change. But we need to stop slowing down to watch every change and kind of build a way of working where we can absorb the change in real time, basically. And that, you know, our risk compliance and AI governance can't live in separate corners anymore. They need to share one picture. They need to use the same information. And that will also help us to see problems sooner and stop doing the same work twice. I think that saves us money just there. Anything that you'd like to add before we wrap up this episode? No, actually, I think you summarized it really, really well, Yolardi, on the integration, looking at it holistically, mapping out where you are, creating a plan. And you made a very important point, which is just start, right? If you just start and start to pull things together, you end up peeling the onion one layer at a time. I've not only, you know, been involved in creating compliance software and services, but I've also done it for organizations. I've done that role where I've had to actually, you know, do the face-up to the auditor and actually, you know, kind of make sure that all of our processes are working right.

And, you know, after the first day or two of diving into it, like, you get on a roll. and you're like, oh, we've had, you see what it is that you're actually fixing and improving and enhancing. And it's really very fulfilling. And sometimes we call our customers heroes. They're really the heroes of their organization making this happen. They don't always get the credit that they need. That's another topic of how to get all the stakeholders to really, you know, recognize you, but they're doing heroic work. And, you know, we really love creating a community for them at iGoProof. But I think you really summarized it well. Absolutely. Craig, thank you. It's been an absolute pleasure having you in the studio today. I'm very excited for the next part of this conversation. Me as well, Yolanda. Thanks so much for having me. Wrapping up today's episode, let's look at the three key takeaways from our conversation with Craig. First, organizations that keep building through regulatory forces should focus on standardizing one set of controls

that holds up no matter which frameworks change. Second, compliance works based as a continuous space with evidence collected every day and every control connected to the organization's overall risk profile. And finally, expressing risk in financial terms gives pause a clearer picture and helps justify compliance investment by showing how much risk each activity reduces. In this episode, we covered why breaking down the silos between risk, compliance, and AI governance is essential. To go deeper on this topic and learn how leading organizations approach AI investment more like a venture portfolio and why interdisciplinary collaboration is critical to defining the right data for AI success, download our free PDF report beginning with AI at emerge.com.ai.k1. That's E-M-E-R-J.com.ai.k1 to download your copy. For further executive level analysis and to join our network of leaders delivering workflow impact with AI, visit emerge.com. On behalf of the team at Emerge, we'll see you on the next episode. Thank you.