The Evolution of GRC and Future Risks in Third-Party Ecosystems with Michael Rasmussen

In this episode, Michael Rasmussen, a leading expert in governance, risk, and compliance, shares insights into the origins of GRC, its ongoing evolution, and its critical role in managing complex third-party ecosystems amid rapid technological change. Discover how organizations can stay ahead of regulatory pressures and operational risks through innovative frameworks and proactive dependency mapping.
Key Topics Covered:

• How Michael Rasmussen pioneered the GRC concept with the first market models in February 2002
• The seven generations of GRC, from Sarbanes Oxley-driven GRC 1.0 to GRC 7.0 focusing on orchestration and AI
• The importance of treating risk as an appetite for value, not risk itself
• Why periodic risk assessments are insufficient in dynamic environments and the need for continuous intelligence
• Bridging the gap between technical threat detection and business risk perspective
• The risks associated with opaque AI supply chains and shadow tech, and how to govern them proactively
• Critical dependencies in third-party ecosystems and how to map and manage them effectively
• Practical steps organizations can take today, such as dependency mapping and defining systemically critical vendors
• The role of organizational culture and personal routines in staying informed and resilient

Timestamps:

• 00:00 - Introduction to Michael Rasmussen and his GRC background
• 02:45 - The origin story: How the GRC acronym was created in 2002
• 05:00 - The seven generations of GRC: From reactive to orchestrated AI-driven frameworks
• 09:00 - Common industry misconceptions and what should be retired in risk management
• 11:12 - How personal experiences and career pivots shaped Rasmussen’s expertise
• 15:13 - The future of vendor risk ecosystems and the dangers of shadow tech
• 17:24 - Governing non-transparent AI supply chains ahead of regulation
• 19:49 - Bridging the gap: Connecting technical threat intelligence with operational risk
• 22:13 - The importance of contextual analysis over simple scoring in third-party risk
• 24:32 - Risk management lessons from Star Trek and risk appetite misconceptions
• 27:27 - Practical advice: Building dependency maps for critical business services
• 29:09 - Final thoughts on identifying systemically critical vendors and ensuring resilience
• Want me to turn this into a LinkedIn post next?

Transcript

Copy Transcript Copied

SPEAKER_01 0:01

Hello, welcome to Third Party Threat Hunters Podcast. This is uh a special episode for me because I get to host uh Michael Rasmussen, who is somebody I want to be when I grow up because he's got this great consultancy and Lee's uh uh uh has been leading in the GRC space for quite some time. Uh I'll let Michael provide his his bio and then we'll get into the quick questions as we usually do.

SPEAKER_00 0:25

Excellent. Well, it's a pleasure to be here, Greg, with you. And I'm I'm excited for this discussion we're gonna have. But uh, I'm Michael Rasmussen, you know, uh the founder of GRC 2020 research. If you go back, I've got 3 years total experience um out there. Uh the 90s focused a lot on IT risk, information security, and things, uh, and then expanded beyond that. Uh besides GRC 2020, which is my analyst hat, I have GRC Report, which is a global news website and governance, risk, and compliance news around the world. And I have a team that works on that. And I have my two podcasts similar to yourself. You know, I've got my uh Risk is Our Business podcast with a Star Trek theme, and maybe we'll get into why on that. But I also have my Hitchhiker's Guide to the GRC Technology Galaxy podcast as well.

SPEAKER_01 1:09

Oh yeah. So you you're a sci-fi fan like myself, uh probably in the background, right?

SPEAKER_00 1:15

Yep.

SPEAKER_01 1:15

Yeah um well let's uh I'll make that one of the questions, but um uh yeah, I think you you parlay it perfectly with your background is the origin story. You're widely recognized as the father of GRC. What originally sparked that realization 20 years ago that uh governance versus compliance needed to be tied together into a single unified discipline? What was that the aha moment?

SPEAKER_00 1:37

Well, before moving in the analyst world, we have we have to actually have to go back to the late 1990s. I I led a risk and compliance consulting practice in the Chicago and Milwaukee markets. And uh I envisioned that we needed this technology to kind of map controls to policies to risks and all this. I had it in my mind, but I'm not a software developer. Uh and so uh I'm I'm at Forester, and so this is February 2002 on a cold, snowy day in the Chicago Office of Forester Research. And I just had a solution briefing uh from a vendor that uh showed exactly what I envisioned in the 90s. And I said, there's a need for this. Uh and uh and uh so I I thought about it, and what do we call it? And I came up with governance, risk and compliance GRC. And from there, you know, a year later, you know, worked on the first Forester GRC wave comparing solutions. Uh, but you know, that was February 2002. You know, I had a broad vision of what GRC should be to enable second and third line back office functions of uh of risk and compliance and control to work together. Uh but what else happened in 2002 was Enron WorldCom Sarbanes Oxleague.

SPEAKER_01 2:44

Wow. Yeah, that that's uh that's a whole podcast in of itself, actually, isn't it, Michael? Um uh so what was uh so your your your aha moment was that that that product demo kind of putting that together a little bit. Yeah. Interesting. Yeah, that's great. Um uh daily your daily information takes. So with things happening and evolving so quickly, uh particularly with global compliance regulations moving quickly and security, third-party risk. Um, what do you do to kind of consume and keep up to date daily? It's it's a lot, um, and and it's it's difficult. Even I'm challenged with that. I wonder how you do it.

SPEAKER_00 3:21

Well, first and foremost, I have conversations. Uh um, unlike some of the other analyst firms out there, I don't need to name names. Uh they they want to see video demos and they want to send uh client references, customer references, web surveys. Uh that's changed from when I was uh in the in one of the big ones. Um and I believe in conversations. So I go around the world. Like one one day in Denmark last year in Copenhagen, I had 12 meetings booked from seven in the morning all the way to two dinners at night. And so to me, uh a lot of my intelligence and research is coming and talking to organizations. What's working for you? What's not working? What are your headaches? What are you considering for your uh strategy and technology paths? So part of that uh daily routine is having conversations, whether they're remote on the phone uh or web, I should say, um, or whether they're in person. So I'm I'm heading to Ireland uh in the next couple of days and have a good, I think, dozen meetings planned over a few days in in Dublin. Uh, but uh but more to the practical aspect of it, uh as far as personal research, I rely heavily on GRC report. So I'm I focus on GRC 2020, but I own GRC Report. But I have a whole team that works on uh articles and stuff on GRC Report. So I I consume a lot of the global news and developments on GRCReport um.com uh to help me with my research. And then, you know, I get a lot of uh I follow a lot of different uh um thought leaders and people that I've had on my podcast, like Tony Martin Bagey who wrote the who was the head of cyber risk and Netflix and just wrote the great book from heat maps to histograms and uh you know and a variety of others that I interact with. I I follow them and what their thoughts are. Um and uh I of course LinkedIn, but LinkedIn I I I'm is a big benefit to me. I've got a lot of followers, but uh the content on it, there's great content, but you have to get through a lot. I'm a little bit tired of all the political posts and personal posts on LinkedIn Facebook.

SPEAKER_01 5:17

Yeah, I was you see uh same thing. I've seen the same thing. It's a bit all Facebooky lately. Um yeah, I I I I uh uh I viewed face uh LinkedIn as more almost marketing uh as as much as anything else for some of it. And the AI slop is getting a little bit too much, and I'm I'm a contributor to that, so I should probably shut up or put up. Um uh the next one is the unpopular opinion question, because it especially folks I've met a number of folks in in who lead in spaces, and and um they always uh uh generally have something where it's one widely best best practice or a buzzword in today's risk management space that you secretly or even openly think the industry should just move on with it. It's it's over with, should retire it, whatever, whatever, however you want to put the phrase.

SPEAKER_00 6:04

Well, if I had to say that, and this is getting into a personal quarrel with uh uh another analyst out there, but I retire the the term integrated risk management. To me, G or C covers that. It's the R and G or C. I never liked it because it really was an attempt to just sort of redefine G or C in somebody else's context as they went to retire. Uh well, not retire, but go independent like myself. Uh and to me, it's the R and G or C. Uh and and I I I don't mind using the term integrated risk management when it's referring to the R. Uh, but you know, governance is much broader than that. You know, and and it's about making decisions and setting objectives and performing against those objectives. And compliance is not simply part of risk management, it's it's uh it's it's more than it's about the integrity. So GRC is broader, it brings governance, performance, risk, compliance, ethics, assurance, areas of third party that you're covering, uh assurance and all this together. So I'd also challenge another thing is I challenge the assumption that an annual or periodic risk assessment represents effective risk management, or in your case of third-party threat hunting, third-party risk management. Periodic assessments have a role, but a questionnaire completed nine months ago does not tell you whether a third party or uh if it's an enterprise or operational risk internally is compromised today. You know, a point in time assessment is a photograph. You know, modern risk requires a live feed. So that you know the future is not simply more questionnaires or more risk scores, it's continuous intelligence, contextual analysis, and coordinated action.

SPEAKER_01 7:34

Yeah. You and I have never met and had this conversation at all, but I've said that, I've said it, thought it a thousand times. It's it's it's when I set up program uh it uh uh set up programs and consultants, uh it's about finding risks. It's not about just stamping a box and moving on it. That's that's usually the that's what a lot of organizations really focus on. Um is the future trend. So we've moved from basic vendor management to complex digital supply chains. We've seen SASPRAL, now we're getting third-party, fourth party AI. In your view at GRC 2020, what's the most dangerous assumption organizations are making about their vendor ecosystems right now?

SPEAKER_00 8:16

Well, the most dangerous assumption is that the organization believes they know who their third parties are and the risk they bring. I mean, I teach my supplier third-party risk workshop around the world and have had detailed conversations this last year, bite. You know, how do we measure the value at risk? Because so often historically we focus on the size of a contract. How much are we spending with a third-party or supplier? We think that's the most risky. But it could be that supplier out there that delivers this little widget that, and we don't spend a lot on it, but if it doesn't get delivered, we stop manufacturing. Um, or you know, you you look at the the breaches, you know, go back uh 12 years ago to the Target breach. You know, an HVAC vendor, a heating air conditioning vendor, was the doorway into one of the largest credit card breaches in history. You know, and and so uh who are our vendors and what risk do they bring? That's not easy to get your hands around. Uh, you know, most organizations have a vendor list. Uh they have a procurement system and that contract repository and with accounts payable database, and uh, of course, third-party risk platforms or maybe a module and GRC platform. They therefore assume that they have visibility into their external ecosystem. But you know, a vendor list is not the same as a dependency map. You know, a contracted third party may rely on several cloud platforms, software libraries, data processors, uh AI models, uh, subcontractors, offshore service centers, identity providers, fourth parties. Those dependencies may change without the organization's knowledge. At the same time, employees are adopting SaaS applications, browser extended, all this stuff. And it makes it even more complicated. Uh, the organization may have assessed the vendor uh named in the contract, but does not necessarily assess the ecosystem that actually delivers the service.

SPEAKER_01 10:00

Yeah, that's great. That's that uh yeah, you think you know really how deep the pool is, but it it it it's it's really you really don't really understand. And I that's a great, great way to put it. Um, big question number one is the future uh architecture uh and AI. So organizations are rapidly adopting third-party AI tools and cloud status integrations. Traditional GRC boundaries are are can be said to be dissolving. I guess that we could have that discussion about whether that's really happening. What core changes must uh enterprise GRC frameworks uh make right now to govern non-transparent AI supply chains in Shadow Tech before regulatory mandates force their hand? So, how how do we get ahead of uh the regulate regulators before because when the regulators get engaged, I my opinion is it generally gets uh it it's not the best way to usually fix the problem.

SPEAKER_00 10:47

Yeah. Oh gosh. Um, I mean, first off, we need to come to terms that the modern organization is not defined by brick and mortar walls and traditional employees. The modern organization is the extended web enterprise. Those vendors, suppliers, outsourcers, service providers, contractors, consultants, brokers, agents, dealers, partners, intermediars, and more. Their issues are your issues. Uh, you know, the traditional organizational boundaries have dissolved. And then artificial intelligence accelerates this, but it did not begin with AI. Cloud computing, outsourced business processes, uh, SaaS platforms, uh, remote work, uh, digital supply chains, uh, what data brokers, open source software, and API-driven business models uh have all contributed and steadily expanded the enterprise beyond its traditional perimeter. AI adds several new dimensions, though. It can introduce non-transparent decision making, uncertain data governance, and with that model drifts and autonomous action, uh, intellectual property exposure, uh, privacy risk and concentration risk, uh, and other dependencies and interdependencies on infrastructure that may be visible, really may be invisible to the customer, uh to the organization. Uh so an organization may believe that it is purchasing a single AI service. In reality, that service may depend on a foundation model, a separate cloud provider, a third-party training data, um, open source components, and and more. You know, the digital supply chain, and now with that, the AI supply chain can be several layers deep, and accountability often becomes less clear at each layer.

SPEAKER_01 12:24

But uh big question number two, which is the operational reality. And you kind of hit on this earlier about the fact that, you know, we we uh uh taking point-in-time assessments uh is perhaps necessary, but is it the same thing as assessing a vendor's security? So uh most TPR programs run on governance frameworks and periodic risk assessments. Um, but active threat hunting focuses on real-time compromise and uh technical telemetry. How can security and risk leaders bridge the gap between aesthetic GRC metrics and a dynamic technical threat intelligence so governance reflects actual the operational risk? And I I uh you cued it up earlier, I think, beautifully.

SPEAKER_00 13:00

Yeah, well, the gap exists because security and broader GRC often operate in different clocks in languages and different units of analysis. Threat hunters operate in seconds, minutes, and hours. They look at indicators of compromise, um, exposed credentials, uh, uh anomalous behavior behavior, uh, malicious infrastructure and activity, uh, vulnerabilities, of course, and attack patterns and technical telemetry. Traditional GRC programs often operate in quarters and years. Uh, they focus on policies, assessments, control attestations, audit findings, the risk registers, and committee reporting. Both perspectives are necessary, but they are frequently disconnected. The threat hunter may see urgent technical evidence without understanding the full business context. The risk leader may understand the business context, but work with information that is already outdated. Security knows what is happening, GRC knows why it matters, the organization needs both these views connected. Uh, I would frame the bridge uh you know around three capabilities of sensing, interpretation, and action. Sensing is about bringing uh dynamic intelligence into the GRC environment. Uh the first step is to connect you know relevant technical and external intelligence to the organization's third-party and broader GRC records. This uh does not mean copying every security alert into a GRC platform that would create noise and quickly really become unmanageable. The organization needs to identify signals that can materially change the risk of a relationship and the risk posture of the organization itself. These might include exposed credentials associated with the third party, evidence of active exploitation, material vulnerabilities, data leakage, service disruption, uh financial distress of a third party, uh, geopolitical events, of course. We're seeing that every day. All these collective signals should be linked to a known relationship, service, asset, identity, or dependency. This is where many programs actually struggle. They purchase several intelligence feeds, but the feeds remain separate. Uh, the information appears on dashboards without being connected to the organization specific business context. More data does not automatically create more awareness. Uh the second theme, because I mentioned uh three, sensing, interpretation, and action. Interpretation uh is the second one where we translate technical signals into business context. Uh, a threat indicator becomes meaningful when the organization can connect it to a potential business impact. Uh suppose a threat intelligence feed identifies compromised credentials at a third party. The the risk significance depends on questions such as whose credentials were compromised, what systems can those credentials access, are they privileged credentials, is multi-factor authentication in place, and more. You know, without that context, the organization has a technical alert. With that context, it has a risk decision. Uh the the same is true for vulnerabilities. A critical vulnerability does not automatically mean that every relationship with the provider has the same level of risk. The vulnerability may affect one product configuration version or service and not the other. The goal should not be simplistic scoring. The goal should be contextual analysis. I am cautious about programs that try to reduce third-party risk to a single number. Scores can help prioritize, but they often create false precision. I'm not a big fan of heat maps, for example, but because risk is a distribution. It's not a point on a heat map, and risk is not a color of red, amber, green. Uh and so that's another theme. Uh, but the third thing is action. Intelligence should help us with coordinated response. Intelligence without action is simply interesting information. When a meaningful signal is identified and placed into context, uh, the organization should be able to trigger a coordinated response. Uh the response should be risk-based and proportionate. Not every signal requires uh executive escalation, but every material signal should have defined ownership and decision criteria. This is where orchestration becomes essential. The organization needs workflows that cross security, risk, procurement, and all these different areas. Uh, and and uh we also have to understand that risk is our business. That's the theme to my podcast. Let's not get to Star Trek. Let's go 800 years in the past. I have a master's in medieval church history. So Thomas Aquinas, uh, he's a medieval philosopher and theologian. He said, he stated, if the highest aim of the captain was the preservation of the ship, he would leave it in port forever. That's what ships are designed for. They're meant to go out in the ocean and take risks. Uh now, moving 300 years in the future, you know, Starship Enterprise, season two, episode 20, the original series. Captain Kirk is in this meeting with Spock and Scotty and uh McCoy and others, and they're making a decision. Do we go on this mission? And Kirk gets up and says, risk, risk is our business. That's what this starship is all about. That's where aboard her. Every business is a starship of risk. You know, the business that's not taking risk is the business out of business. So we're not trying to eliminate risk, we're trying to manage risk and take the right risks. The other thing that comes up so often, and I'm maybe I'm just going down rabbit trails here, but we we hear a lot of this term risk appetite. And I have these dinners I do around the world called risk appetite, GRC executive dinners, and it's a great name for executive dinner. But at the end of the day, what organization actually has an appetite for risk? We don't. No organization has an appetite for risk. We have an appetite for value. You know, when I teach my workshops or speak at uh uh seminars and things, I I use the example. You know, we're gonna go on a break. Well why don't you leave a hundred dollars on your seat and come back after the break and see if it's there? Who has an appetite for risk? No. But if I tell you, leave a hundred dollars on your seat, come back after the break, and it might be three hundred dollars, all of a sudden you're doing a risk assessment. You have an appetite for value. You multiply your money by three. You're doing a risk assessment, you're looking at the people next to you. Do they look trustworthy? You're looking at the staff of whatever venue it's in. Do they look trustworthy? You're doing a risk assessment at that point. Technically, we don't have an appetite for value. I mean, I we don't have an appetite for risk. We have an appetite for value. Uh, and and we need to understand that. But uh but we also have to understand that organizations take risk. It's part of business.

SPEAKER_01 19:16

Uh uh breaking it down into those three three um uh subsections or sections, I think it also helps quite a bit because you go from you know getting the information, getting the signals, and understanding that it's also it's risk-based. But uh thank you, Michael. That's those are those are perfect uh statements. And I hope uh uh the listeners are able to take some notes from that or uh take the meeting, then the notes from the uh podcast itself. Uh if uh risk leader is watching this podcast, what's the one thing they can take back to their destiny to move the needle on GRC and AI risk, Michael?

SPEAKER_00 19:49

I mean, if we want to start small, I say take one critical business service and build a dependency map. Uh do not begin with the entire enterprise, do not begin at the you know, uh massive transformation programs, like one service that is essential to your customers, to operations or revenue and uh performance, um, or maybe it's a regulatory obligation, then put the right people in a room, uh, the business owner, security, risk, technology, procurement, uh, and others, and ask, you know, uh, well, I I've got six questions. You know, what objective or critical service are we trying to protect? Which third parties, technologies, cloud platforms, AI systems, data sources, and subcontractors does it depend on? What information and access do those parties have? What could fail, be compromised, or behave unexpectedly? Uh, what intelligence would tell us that the risk is changing? And what would we do if the dependency became unavailable or untrustworthy tomorrow? Most organizations will discover that they cannot fully answer those questions. That discovery is valuable. It identifies gaps between uh like vendor supplier inventories and operational reality. Uh, the organization may discover an unapproved AI tool or a hidden fourth party or an unsupported integration or concentration risk or something. But from there, the organization can define ownership, improve controls, establish monitoring, and develop a response or exit plan. The objective is not to produce a beautiful diagram that sits in a presentation. The objective is to create a living model that supports decisions. So start with one critical service or one business objective or whatever it might be. Map the dependencies, connect the intelligence, and define the action.

SPEAKER_01 21:31

Great. I I'll build off of yours. Uh my threat hunter's take is build off of yours is define what a systemically critical vendor is for you. Uh a lot of organizations, they may have high, medium, and low. Let's say they have a simple sort of high, medium, and low risk vendors. Uh define vendors that are systemically critical to you. These are the vendors where if you if they operate in a diminished capacity or can't turn their lights on, you're equally diminished or can't turn your lights on. Let's say if you're a manufacturer, the power company is a systemically critical vendor to you, to put it in that perspective. If you're a if you're in finance, if you're a bank, Swift is a critical third party to you, right? So if you want to do banking. Um so, so, so uh that would uh that's a critical step for a lot of organizations because then you can get to what Michael's talking about is the discussion about uh resiliency and understanding what the dependencies are for those critical vendors. Because you've identified what you're just saying, critical vendors, there may be other critical dependencies downstream for them as well. And so those are the conversations that Michael was leading you to have with those critical vendors as well, once you've identified them. Thanks again, Michael, for agreeing to be on my podcast. Uh a big fan and keep up the good work and a good fight in the GRC space. I think it's it's uh vastly underappreciated, but I do appreciate it and others too in this space. Thank you so much for coming and being a guest.

SPEAKER_00 22:50

Oh, it's my pleasure. Thank you for having me.

SPEAKER_01 22:52

Thanks.