0:06vacation and beyond. And so, this morning, David and I are going to talk to you a little bit about the institute to get things started and warmed up. And then we are going to share with you some of the results of one of the things that we've been working on here at ERQI, which is evaluating some of the top global risk reports and seeing what they have to say about what are our top risks these days, and how are people trying to address those.

0:37So, I am thrilled as co-board of, excuse me, co-director of the board with my friend David White here at ERQI to welcome you all. Welcome, everyone. Welcome, everyone. I'm David White from Axio, and I am a co-founder and the co-chair of the institute with Andrew. I'm thrilled to have you with us today, and I'm thrilled for this being the inaugural event for the institute, or the inaugural summit, I should say, for the institute, not the inaugural event. A couple of housekeeping items.

1:19For those of you who are joined as an attendee, you will be muted so that we're not dealing with noise issues. And if you have a question, please ask the question in using the Q&A interface, and we will get to it either with a text response or we'll answer it live. And the first question, will we get a recording of the sessions?

1:46It is our plan to post recordings of the sessions. Stay tuned for that. It'll take some editing work to get that done. But yeah, they will ultimately be posted to the ERQI website, so follow along there. And please remember, if you haven't already, please do follow ERQI and me and Axio on link, oh, sorry, me and Andrew on LinkedIn.

2:19And I'll post links in the chat to make that easier for you. There you go. We will be using the chat during the presentation. During all of the sessions, the chat will be live. And with that, let's take a look at who's in the room. And as of yesterday morning, when we completed this analysis, we had 217 registrants from 34 countries, six continents. A lot of them are C-suite, SVP, or VP level, and 95% of them are registered for today, day one. 92% are registered for tomorrow. So we expect great turnout on both days. And there's a little bit of information about what they do and where they're joining from across the bottom of the screen.

3:18And with that, thanks all of you for joining this morning. Let's... I forget what's next, Andrew. There we go. - Talk about the institute for a minute. I was going to talk about the institute or something, Mr. White, I believe, so. Yeah, go ahead. Yeah. So I think it's kind of interesting sometimes to understand the origin of a organization, of an individual, of a approach to risk analysis or risk management. But for the moment, we're going to just talk about the origin of the Enterprise Risk Quantification Institute.

3:53And that really, I think, goes to helping understand our charter mission and objectives. So, on a personal note, as somebody that got started in the world of enterprise risk quantification on the cyber side, I was looking after being in a particularly brutal meeting with one of my clients where we were talking to, this was a CISO for a large organization, and we were talking to the folks on the enterprise risk management side.

4:24And we were telling them about all the wonderful work we were doing with cyber risk quantification. And they said, "That's really nice, but really, you guys are under the operational risk area, under tech, under cyber. So thanks for the information. We appreciate it. We'll get back to you." So that sent me off on a course of trying to find a means by which to help articulate why we needed to have an integration of cyber and enterprise risk management. And at that time, I stumbled across a inter-agency document called NIST IR 8286.

4:59For those of you that aren't familiar with that, I recommend it highly. I, with several other people that are also members of the institute, decided to do a web series of webinars around the four pieces of that. During that time, I had the pleasure of talking to Mr. David White about the merger of these two areas. And so it began this journey, right, of thinking about enterprise risk management and cyber risk management as significant partners, if you will. And that led me down the path of thinking about enterprise risk quantification as a concept. And just speaking to a number of individuals, all of a sudden we got started, and there were five or eight of us initially, and now we are up to

5:47over 200 members. We have over a dozen distinguished fellows and I think 30-something co-founders now. So this is all within the period of a year. So very excited about how quickly things have taken off for us. So, for all of those that have ever read a comic book, that is the origin story for the Enterprise Risk Quantification Institute.

6:11Mr. White, any comments that you want to talk about from an origin perspective? No. I didn't know Andrew before we started a conversation about this, and I'm thrilled for all of the groundwork that Andrew had done and continues to do. It is my great pleasure to work closely with Andrew and with the co-founders to foster this community. And with that, let's segue to what we're about here at ERQI.

6:51Absolutely. I'll kick it off, David, if you want me to. Please do. Sure. So why are we here? What's the end game? And I just want to say before we go down this path that one of the things that's... There are a couple, like what's called dimensions of the institute, the way that I see it. One of them is that it's kind of a living, breathing organism, as it were. And I say that because we talk about what are the purpose and objectives of the organization. While we've laid some good foundations for it, we are constantly in a process of kind of re-evaluating how we're describing what our mission and journey is, right?

7:33And I can attest to this because as recently as 4:36 PM Central Standard Time, Mr. White and I were talking about exactly how we were going to articulate the purpose of our organization. So, if we talk about something that's living and breathing, I think that's a excellent sign, right? That we are not afraid to move forward on any topic at any time.

7:56So the purpose is laid out here, right? And I think that one of the key things that we are obviously trying to help people understand is the criticality of adding or integrating quantitative measurement and analysis right into the process. And what we've decided early on is that we weren't going to create a standard per se.

8:18We were going to provide a series of guidance, because as my good friend Chris Patterson likes to say, "You use the right risk analysis approach for the right risk." And so that means that there might be a significant quantitative analysis piece, but there will always be some part of human judgment involved. And so it's not, strictly speaking, always a quantitative type of playing field that we're on.

8:43But then there's the end game, right? What are we trying to focus? So introducing quantitative, promoting that as a key element, right, in terms of how we are approaching enterprise risk management. So that's a key element. Systems thinking. I was fortunate to be in a class that was put on by a gentleman by the name of Bob Zukis, who owns an organization called the Digital Directors Network, and he has a very excellent approach that he's created around systematic thinking. So thanks, Bob, for helping inspire me, by the way. So ergo the name drop.

9:18But really, the reality of the world that we live in is complex, and it's fast-moving, right? I think there's three different acronyms, David, now I'm seeing to describe our world, VUCA, BANI, and another one which basically says we're living in fairly turbulent and crazy times, right, with uncertainty being a chief factor amongst them. And so, the reality of it is, how do we create a system and systems thinking, right, that can wrap its arms around that? And so that becomes the challenge. One of the elements that's important as well is the output, right? We always want the output to be informing a decision, right, or a series of decisions, like things around

9:57capital allocation, things around budgeting. How can we inform how cybersecurity and technology is looked at from a different perspective, perhaps as a cost of goods sold rather than as an expense line item? So all of this is to say that we are trying to create a means by which to create another way of looking at risk that ultimately ends in being able to inform decisions between business unit owners, executives, and the board.

10:29Mr. White, any thoughts on the purpose part of our discussion? Yeah. Well, I think that trust is so important as an element of our purpose and as an objective for any risk analysis. And so... Sorry, finally it was storming and now it's getting sunny here. So, trust is a very important word in our purpose statement because we have to, and I think you'll see this thread throughout a number of the talks today about trust and placing trust in the numbers, but making sure that the numbers are trustworthy, that they are, in fact, rigorous and we can bet the organization on them, so to speak. So- Yeah, I like to think of defensibility, David, right?

11:35Defensibility. Like I think that's kind of a key word, right? Absolutely. Coming from somebody that worked in cyber for a long time, where I was always working with people in organizations where we were trying to help the CISO, right, to defend a budget, right? Or ask for a budget increase, right? So the defensibility of that budgetary ask, what is the reason for that? Why do you need that, right? And so I think the defensibility element is cool, and we'll see that brought out in a couple of our different sessions, right, including one on model risk, including another around the world of GRC. And so, I think that's kind of core. I think one of the things that I'm excited about,

12:13too, as we talk about our function, right, is we are here to create work product that practitioners can use, right? And so we talk about education, for example. One of the things that you'll hear us talk about a little bit later in the two days is one of the work products that we're working on, which is a knowledge graph of how do you professionally develop to become an enterprise risk quantification professional, right? So promoting education by the work products that we provide, as well as some tooling, right, to help people look at what a path would look like to become an enterprise risk quantification professional is part of it, without question. And then I think

12:52for me, the other piece that's important to note here is this has really been a year of getting things off the ground. I sit here kind of in awe of the effort of all everybody that's been a part of this journey so far. We are, to those of that you aren't aware, we're about a little bit over a year in recently celebrating our one-year birthday, as it were. And so year one has been about getting the foundation laid, right? It has been about trying to define our purpose and objectives and creating our initial set of work product, which we have seven or eight. You'll see another dozen or so come up from us before the end of the year. A lot of those

13:31have, interestingly enough, been focused on how do we think about our enterprise risk quantification or some element of it. And as we go forward, if you look at number four on the slide here, we will be moving to creating open source toolkits, right, that will be available for people to actually execute on things within that realm. So that part is important to me and make sure that we are educating and sharing and helping practitioners be successful, so...

13:57Absolutely. And I just want to give a shout-out to all of our co-founders. We started in this first year by engaging and enlisting co-founders to help us build the first set of work products to begin this journey of providing valuable work products that support risk practitioners around the world. And we all have day jobs. Nobody's getting paid to do any of this ERQI stuff. And so everybody has a day job, and we're a volunteer army producing work products for the benefit of risk practitioners. So thank you, co-founders, for joining us on this journey and rolling up your sleeves. We appreciate it.

14:57Yeah, just one final note there. I have been overwhelmed with kind of the wonderful nature of the folks that are part of this institute, and to David's point, I can't thank enough the co-founders, the members, and the distinguished fellows for their willingness to share, right? I mean, I think one thing that's kind of, to me, was kind of core about what are some of the values that we want to espouse at the institute, and one of them is openness and forthrightness and sharing, right? And the things that I've learned from everybody that's presenting today has really been astounding. And so I encourage you, for those that aren't members today, right, to join us because I guarantee you

15:42it will change your perspectives on risk management or risk quantification in a positive way. Sometimes it might challenge some of your assumptions that you have, and sometimes it will help you to evaluate things from a different prism or through a different facet. And so those two elements to me, right, are really kind of critical. And to that end, David, would you be surprised that I'm going to quote from our newest distinguished fellow, who is Mourad Berrahoui, who hails out of the Middle East. He had a series of articles recently around governance, and one of those items he was talking about is the necessity for lean governance, which should remove process but not accountability.

16:32And I think that's one of the things that as we evolve, we always have to be conscious of, right, is looking at the processes we have and how do they help us to inform risk. And I think that one of the things that he said that I really liked was he said, "Do activities improve decision quality or accountability? And if that action that you're working on does not do that, then do not waste your time." So, in the spirit of not wasting time, I am going to pause, which is difficult for me, for those of you that know me, to be quiet for a little bit. But Mr. White, I will come back to you and let you talk about our wonderful, amazing sponsors.

17:07Yeah. Look, we are also very fortunate in this year one to have four amazing sponsors who have helped fill our sails with wind this first year and given us the ability to do some things that we wouldn't have otherwise been able to do. These are the four sponsors, and Axio is my company. Citalid is a competitor of ours working primarily in France. Cyentia Institute is an incredible data source, and Ostrich Cyber Risk is another vendor like my company, providing risk quantification software solutions. These are four amazing companies, and we're very fortunate to have them at our backs with sponsorship in year one. They make the summit possible. So thank

18:11you, sponsors. In a moment, I will drop a link to their LinkedIn pages in chat. Please do follow our sponsors on LinkedIn. And with that, Andrew, let's look forward. Sure. One thing that I promised I would do this morning because it's just a recent discovery of mine, was to highlight the amazing individual that is co-hosting with me at the moment. So, there are a couple words out there that just frankly bug me because they get overused, and/or phrases.

18:52And so sometimes I'm afraid even to say these words because I don't know that people will think of it in the same terms I am. But, for example, one of those terms that we see each and every day in the world of LinkedIn is AI governance, right? What does AI governance actually mean, right? That's- The subject for probably 17 different books based on the number I've seen released on that already. But the reason I bring this up is that, boy, I don't know if I'm going to get the years right, so correct me, David, if I'm wrong, but maybe 15 years ago, there was a book published about operational resilience. Operational resilience. And so, when I was making that

19:36comment about terms, resilience, everybody uses that and they use it in so many different ways, and what does it actually mean? Everybody has their own definition of it. But there was a gentleman with two other people that wrote a book about operational resilience 15 years ago. So, I'm sure you're thrilled that I'm bringing this up, David, so it's not an intentional plug, but I just thought I would surprise you because you know I like to do that. So, congratulations on being a true thought leader 15 years ahead of the resilience curve, if you will, so.

20:09Yeah, we didn't get a lot of traction in that term 15 years ago. We fought tooth and nail to convince people that we should use it, and we didn't get a lot of traction. But it did very much alter my career, and the work that went into it was like a mini PhD. As a friend of mine jokes, Andrew, it may not be the best book on operational resilience, but it's definitely the heaviest at 1,000 pages. So, thank you for mentioning that. I appreciate it. You're welcome. So, I mentioned a few minutes ago this notion of moving from guidance, where we're talking about how do you do things in the world of enterprise risk quantification.

21:02And if you go to our website, you'll see seven different pieces of work products, right, that are out there today. And so, many of those explain the individual's perspective, right, on how to, for example, think about putting together an enterprise risk quantification program within their organization. There are a couple of work products out there by Lisa Wagner, by James Hanbury and Jonny Mattey, right, that go to that particular question. But there's also pieces out there that are talking to us about how do we need to think about a model risk?

21:38How do we need to think about trying to put together in an integrated fashion the world of governance, risk, compliance, right? And so, all of these things I would put under kind of the guidance category. And so from a tooling perspective, the next year for us, right, is going to be focused on having tools that people can use to execute along those. Now, guidance is a form of tooling. Yes, that's true.

22:03But helping to provide tools that actuate will be part of that. And to that end, we'll be establishing a GitHub repository where that information will live in. One of the recent adds to the world of ERQI, which I'd like to thank our director of member engagement, Mr. Teaser Sweeney, for putting together, is our online community on the Circle platform. So we got to move from the very advanced state of emails and a box website, or excuse me, a box file share, to a true community environment. And so, again, if you sign up and become a member with us, right, you'll have access to, for certain, everything that's being talked about over the next two days, but

22:45really a wealth of other work product that people have put out there, and that will be the interface into this repository as well. I think just to address a couple of other points, we have, to David's point, we're a nonprofit, right? We have several wonderful sponsors, so thank you, Citalid, thank you, Axio, thank you, Cyentia, thank you, Ostrich.

23:07But we need to grow our community in order to continue to thrive, right? And so, please, if you like the content, if you like the direction, our purpose objective, please share out what we're doing here. We really need everybody's assistance. And it's coming up towards the end of 2026, and will we continue to be a organization where it is a no-charge organization for members?

23:35I can guarantee you that will be the case through the end of 2026. Will that be the case in 2027? To be determined. There might be a marginal fee. We are yet to discuss that as an institute. But I just say that to you as a means to say, join us now because it's free. I think the other thing for me that I want to mention is the world of AI. I don't know many folks in the space now that aren't really working closely with one of the frontier engines, right, and they're training up their own kind of capability, if you will. And so one of the things that you'll see a couple demonstrations of is how we're using knowledge graphs to communicate.

24:16I hope everyone that registered got their agenda and synopsis HTML applet, as I like to call them. But the nature of it is providing a visual way to communicate using AI as an underlying layer. Because the world of risk is so interconnected and so quick-moving, right, we need to have tooling, right, that can support that, right? And so whether we're talking about how do you use AI to do risk analysis, what are the challenges of governance of AI and managing the risks from AI, whether those are strategic, operational, or technical, that will be a topic that we will continue to focus on. And we're very lucky to have some really talented people in the world

25:00of AI. I'll just give a shout-out to Rock Lambros in particular, right, who is doing some amazing work with OWASP and I don't even know, 17 other organizations on trying to create means by which for us to responsibly manage the world of AI. Shout-out to Caroline Wong for her recent book on AI as well. So, that is the looking forward picture, right? And- I would just ask that you consider, if you're not a member, joining us, and you can do that through our Contact Us page on the website. Super. Thank you, Andrew. And I'm thrilled about what's coming next in this session because you've put together a great overview of the world of risk.

25:52Are you ready to jump into that? Probably. Let's do it. He said humbly, so- Let's do it. - Okay, let's do it regardless, right? I suppose. At this point, that's where we're at, David. So along this notion of providing guidance, and also thematically talking about the use of AI, right? I went around and looked at trying to absorb several of what I would call the more recent reports in 2026 by various sources and combined them into kind of a single perspective.

26:30And you can see at the bottom the sources that were used, right? The World Economic Forum, United Nations, the IRM Risk Trends, and a document by AICPA, CIMA. And they all had, they were talking about what does risk look like in 2026, what are the key trends, et cetera. And so thought what we could do, right, to try and help those that are interested, right, trying to understand where, directionally speaking, what do we need to be thinking about? So not surprisingly, right, when we look at what are some of the key trends, there's a focus on geoeconomic and geopolitical conflict.

27:11I do not want to speak a lot about that in detail, but it's critical, right? Whether we're talking about the impact to supply chains, whether we're talking about hybrid-based attacks that we're seeing, which are both kinetic and digital, right, at the same time. And that becomes number one risk across the board, really, when people were asked in these various surveys or studies, right, kind of what is your key area of risk right now? And so, for me, that is one of these areas that I'm hoping to see, I know you'll see in 2027 more kind of development from a thought leadership perspective from ERQI on. When we look at risk, right, I am a major fan of the notion of all risks should be tied to a risk scenario because

27:59it provides the appropriate context, right, for understanding risk. But there are always macro factors, right, or meta factors, right, that are going to impact any particular risk scenario. And whether it's geoeconomic, geopolitical, or climate, right, all those elements, right, should be part of how we model and look at risk ultimately. And so that piece of it, right, becomes very significant.

28:26I don't think it's a surprise to anybody that one of the key areas of focus and discussion is also around supply chain and third-party risk management. For me, this is a core area, and I have a very strong core belief that third-party and supply chain risk management should be integrated into other components of within the risk management framework. And for those of you coming from the enterprise risk management side, you're probably going, "Yeah, duh, Andrew."

28:53And to that I say, remember that I come from the cyber side, so I'm still learning more and more about enterprise risk all the time. But fundamentally, right, when we look at the technology side of the equation, we have every risk scenario that you can dream up will have, almost every risk scenario you can dream up, will have third parties involved. Meaning if I'm looking at how a potential breach could occur, there are third-party providers that are providing infrastructure to me, or applications, or software as a service, right? And so I need to be able to have that woven in their risk profile into my overall kind of risk analysis. So the integration of third-party risk in a more

29:32effective manner is a key theme that we see as well. And I think the more critical one is two things that I don't think get enough kind of airplay sometimes when we're talking about risk, and one of those is time and thinking about the time element. And by that I mean if an event occurs, what is the impact and what kind of timeframe?

29:57Some people refer to that as velocity, the velocity of the actual impact. I think of it both from a velocity and time perspective. But those were two items where the evolution of enterprise risk was noted. So, that is all I have to say for this slide. Fantastic. Let's move merrily forward. I actually want to double-click on the thing that was at the bottom of that page of the changes in the world happening at a pace faster. The risk landscape is changing faster than organizations are able to respond. And I think that's a mirror of how many of us feel personally right now of, and for organizations, it's also certainly true.

30:50And I'm concerned that that pace of change is going to get even faster in 2027. Yeah, it certainly appears that way. I couldn't agree more. So this notion of time and velocity is absolutely critical to how we are analyzing and thinking about critical business risk, right? And on that note, because we're in the midst of this very data-driven element, I did want to mention one of the reasons why starting ERQI was important to me at a personal level. I was blessed three years ago with my granddaughter, Lenny. And so, as I look forward to her being ultimately a- ... tweener and a teener and an adult, et cetera, right? I'm hoping that we can create, right, and promote this notion of

31:47a concerted effort, right, to look at and manage risk. And if we do not get that into the corporate mindset in an effective way, right, our ability to do that is going to be challenged, right? So our ability to manage risk without inserting enterprise risk quantification, which is agile, which can deal with risk and velocity, right, we need to create that and have that be just kind of a standard approach to managing risk. Or the world that we'll be handing to Lenny, right, will not be nearly as ideal as it could be. So, having said that, thank you, Lenny, for being an inspiration to me.

32:23These items on here, I think the one thing I'll just note here is, when you talk about a material global crisis, cyber insecurity, right, is at the bottom. So all of my cyber friends, right, don't be alarmed, right? The difference in when we look at what percentage of people responded to this, right, while it's 3% seems low, note that, look at the other percentages that are there, right? So don't be like, "Oh my God, cyber's not being given its due in court." It certainly is. Next.

33:00Risk is converging. This is not news to anybody, right? And we look at the likelihood, right, of a significant event occurring from an emerging standpoint. What a surprise, right? AI is on the forefront. And since we started putting together this notion of having this summit, right, we've seen just in that time, which is now maybe 60 days ago, right, just some really critical kind of discussions emerging around AI. And I'm not going to belabor them too far, but when we talk about this whole discussion that's occurring around slowing down AI and AI development, right, clearly, right, and that coming from the frontier companies themselves, that clearly is an indicator that we need to pay attention.

33:48That we need to pay attention to the potential for AI to disrupt things and to be thoughtful about not just the execution of it, but its overarching impacts. And so, we talk about AI and digital disruption. Just to be clear, what we see across, excuse me, these different reports, right, is a discussion about how AI and technology can disrupt the fabric of society, right, for example.

34:14Not only if an organization deploys AI and, oh my goodness, the government of the country that I live in has decided that that poses too much of a risk, and so now that frontier model that I've based my new set of AI applications on is not available. That is a strategic concern that people are talking about, and should be talking about. The notion of data sovereignty, now AI sovereignty, right?

34:43What does that look like? How will that impact our AI plan going forward from a strategic perspective? These are the kinds of things that we need to be looking at when we talk about AI in terms of strategic disruption, if you will. The other one I want to just touch on, because it's near and dear to my heart, is this notion of climate and climate impact. And so, as somebody that's been on the planet for 60 years now, I'm using that as my data set for analysis. And what I believe we're seeing, right, is more significant climate events, and more quickly. And so, that means that we need to factor that into the equation. And I was talking to Dr. Bob Mark, who we'll introduce you to tomorrow, who is one of

35:34our distinguished fellows, and he has become very focused in looking at how can we quantify climate-related risk. And there's been some great work done on that already, just to be clear. But that is an area where it is an essential thing that we need to consider. If there is a hurricane, would that knock out our power? Would that knock out our manufacturing facility, right?

35:56Looking at it through that lens is really critical, and the reports all echo that. And David, look, there's that word resilience. Wow. Resilience, yeah. Look at that. - How about that? It seems to have caught on finally. - We can move it along, sir. All right. Governance exists, decision use lags. So, for people that have been working in the enterprise risk space, and in particular, trying to communicate enterprise risks to business unit leaders, to the C-level, to audit committees, to board of directors, and other strategic stakeholders, one of the things that I have learned in a significant manner, right, has been the challenge, right, of being effective from a governance perspective, and what does that even mean?

36:53So, how do we supply information, data sets, right, risk scenario analysis, both singular and aggregated, in a way that is going to inform a governance model in an effective way? And a lot of some of the sessions that you'll see will be talking about how do I effectively communicate issues to the board, for example, right?

37:17And not only just communicate them, but how do I then try to drive a environment, right, and a culture as much as I can in my role, right, where we look at risks and we are identifying issues like accountability and ownership. And so, the reality of helping governance to evolve and making sure that our governance approach informs decision-making in a meaningful way. And that is really kind of one of the key data points coming out of the State of Risk Oversight Report.

37:57I think one of the beautiful things too is, just to the far left here, talking about risk management as a strategic advantage, right? What is the value of this? And so that area of focus, being able to articulate that, is something that will definitely be an area of focus for us in ERQI as we go forward. Now David, if you don't mind, I'm going to let you speak to that underlying note, if you will. Something about risk appetites or something, I don't know, might be important. - Yeah. Well, I think, just to foot stomp this a little bit, that structure doesn't guarantee strategic value. And I think from my observation, Andrew, I think governance is one of those things that's definitely struggling to keep up with the

38:50pace of change right now. And I do think that enterprise risk management and enterprise risk quantification in particular can supply the bridge to help us keep up with, to fine-tune our governance and make sure that we're standing on decisions that make sense from a risk perspective because we've done an appropriate analysis of those risks against our appetite. And I know we have Markus and Matthias session. I'm very excited to hear that. I think that's session three today, right?

39:28Yep. Markus and Matthias talking about risk appetite tolerance and the cost of losing control. These are two great experts in that subject matter, and I'm thrilled that that's coming up as session three. So please stay tuned for that. They'll have much more insight on this issue than I'm able to provide. - Excellent. Excellent. Let's move along. Yeah.

40:06So for those of you that are used to what I would call traditional approaches to communicating risk, including tooling like the risk register, the heat map, please know that we understand that these have been valuable tools historically. And please know that we understand at ERQI that these are tools that are currently used widely today.

40:32What we are suggesting here is that there is a way to communicate in a means that can be more helpful to decision-making. And the reason that we say that is, if we say that the outcome, right, of a risk scenario is a dot on a heat map that indicates a high level of likelihood and a high level of probability, how do we use that then to inform what kind of capital should be held in reserve in case this scenario occurs?

41:11And so when we look at this particular slide, I want to make sure that we're not putting off those of you that have been working in this realm, right? But we're in support of it. We're really in support of trying to provide another level of detail, going back to one of David's initial comments around the defensibility of the results.

41:31And I think one of the things that on my own personal journey on enterprise risk quantification that I learned was when I was trying to look at another level of doing risk quantification and looked over at the world of financial risk analysis, there are all these wonderful tools that have been created to look at assets and determine how to allocate capital to maximize return.

41:54So using these same foundational principles that have been in place for 30, 40 years, when we talk about things like risk-adjusted return on capital, value at risk, right? We talk about these things, right? These are things that are used today in the boardroom to determine how to effectively move the company forward, where to invest, how to invest intelligently against a particular opportunity size, right? And so we look at this unit of conversation must change again, right? We are trying to make sure that we are moving into a world where we are providing an additional level of analysis.

42:33So, we think in many cases that moving from just a heat map to using things like loss exceedance curves- Yeah ... which help you to look at the potential of risk across a spectrum of potential probabilities and magnitudes is significant. So a loss distribution is a good significant part of that. I mentioned velocity and time earlier. There's the M word, materiality, right?

43:01So the great M word, which is all powerful and yet seemingly still so undefined. So significantly, having a discussion around materiality and having that have ranges of understanding what is the likelihood of it occur and what's the impact of it, and then how do we evaluate that from an overall risk perspective in terms of what we expect the company's existing operating capability today? How much of that are we okay to absorb today? And then we look at the tail, if you will, of a potential loss exceedance curve for a particular loss scenario, understanding what isn't covered and how do we ensure that we are minimizing the potential impact while at the same time maintaining as much economic capital as we can.

43:56So RayRock, I just like the sound of that as I say it. So RayRock, it sounds- RayRock ... like something a cool enterprise risk- Rock ... quantification superhero would say. Does go to, again, my point, right? Like, which way are we going to invest? And thinking about the world of risk and as a risk investment, right, or just as an investment period, right, really is something that we need to do a better job of explaining, I think, and articulating. Continue to do that. Excuse me. So...

44:24Rock on, RayRock. - And I just want to say, Andrew, I wanted to emphasize something that you said when you were talking about the first row of this table, moving from a color scale to a loss distribution. And I think that there... Personally, I believe that there remains a role for that as a beginning place, and all are welcome here. This is ERQI is a home for risk practitioners who want to hone their skills and help move the world toward more quantitative decision-making. And we are, in fact, I wanted is another opportunity to mention the agenda. The final session tomorrow, day two of this event, will be a debate, the great debate on quantitative versus qualitative risk management methodologies. So please plan

45:44to tune in for that tomorrow at 4:00 PM US Eastern Time. And, yeah, with that, I guess the other thing, Andrew, that I'll say is, look, part of my own journey to risk quantification came from the book that you mentioned earlier that I worked on, that I co-authored 15 years ago on resilience. And the bottom line on an organization's resilience, will an organization live to fight another day?

46:23That answer is financial, 100%. Because if you've got enough financial, if you've got appropriate financial resources to live and fight another day, that's the bottom line on resilience. And understanding risk means we have to understand whether the organization does, in fact, have the wherewithal to live and fight another day.

46:50With that, let's... I'm going to stop running my mouth. Let's move on. It's almost time for Linnea and Stefan. How about that? Looking forward to that very much. So when you look from left to right here, this becomes not only a slide about the report for me, but becomes really kind of a foundation, right, of how to think about doing risk quantification.

47:25The absorption, right, of various type of signals, whether those are internal requests in the form of signals from the CEO or the chief risk officer or the COO or the CFO who's concerned about a particular risk, that's a signal. There are signals that we think of in a more empirical fashion when we look at technology or cyber-originating risks. We look at things like threat intelligence, which is a signal that helps to inform us the kinds of threat actors who might be targeting our organization. So yet another form of signal that helps to inform the risk scenario development that we are working on on a daily basis. These strategic reports, right, provide a signal to us to think about

48:15risk from a strategic perspective. I think it's one of the interesting learnings I've had over the last 12 to 18 months is that when you talk about a risk scenario, it can be impactful from a strategic perspective, from an operational perspective, from a technology perspective. And then, of course, our good friend AI, and I don't mean to overly personify AI when I say that. Kind of wish I had that statement back, but oh well. - - They've kind of designed it to make us anthropomorphize it, right? - I mean, it really is, it's part of how it grabs you and holds on, right?

48:54Sorry, Andrew. It's true. It's true. I forgive you. I do it all the time. It crossed one of these veins is my point. - Yes. Yeah. Resulting, right, in scenario creation. And I would argue that one of the most important tasks we have in the world of risk management analysis is scenario creation. I will attest to the fact that the more that we not only create these but evaluate the ones that we have created because we thought it was a top risk, we need to do that type of backtesting, if you will, of the ways that we... and the signals that we use and how we use those signals to create the set of scenarios, right, that are informing our overall enterprise risk picture, right? And so the notion of

49:41were we on target with top risks, and how do we evaluate that? Do we evaluate by what we saw inside our company, inside our sector? What's the best way to do that, right? So scenario, it's not just about development, but it's also analyzing how effective were we in forecasting potential risks. Um, to me, frequency and magnitude has moved into this phrase that I like to use, which is these are my two friends, LEFE and LEMI, which stands for loss event frequency estimation and loss event magnitude estimation. So just kind of a little bit more interesting way to think about those two terms in a childlike manner, since I am an adult child some days still. So

50:26LEFE and LEMI, thank you for being my good friends, and this is absolutely critical part of... Breaking news, Andrew Shea is working on a comic book. Being sure you're executing on it. Certainly call it Monty, our friend Monty. Monte Carlo simulation is a means by which, right, we are evaluating a particular scenario and looking at it from with an output perspective, right, that is not just about a singular number. It's not just about an annual loss expectancy, right? When we're looking and using the output of simulation, right, we have this, again, going back to the loss exceedance curve, right? We have these elements, and then we have being able to look at them from a P10, P50, or P90

51:10perspective, which P stands for probability in this case. And so what along that loss exceedance curve, if we're looking at that kind of probability or probability estimation would be more accurate, right? Like, how do we consider that, right, ultimately in terms of the decision we're making? One of the things that I think we're seeing more frequently discussed these days is the output, right, of doing this scenario analysis, and then is that above or below our risk appetite?

51:42Is that single scenario in aggregate for a particular area of risks, is that above or below our risk appetite and/or risk tolerance, right? And so that becomes one of the more instrumental discussions, and we do have a couple different sessions, right, that relate to that, the one from Matthias coming up. But it's really littered across many of the discussions, including the one from Astrid Yee-Sobraquès a little bit later today.

52:11Concentration and correlation, I'm going to skip on that for a second, but I think risk concentration, right, is one of those areas that we see a lot of discussion in, in particular these days, and from a third-party risk management standpoint. When we're looking at our third parties, who are the folks that they are relying on, and do I have too much of my operations focused on and being supported and provided by core operational providers? And if we do, how do we then reduce that risk?

52:43There has been a motion, right, in procurement for two decades, right, to have lean procurement and reduce the number of vendors so that we can have the quickest, best process for procurement that works. And then, unfortunately, against this notion of having multiple providers which provide us with potentially greater resilience. So, I think we've covered most of these fairly good. Again, I'll come back to models we can defend tomorrow. Laura Voicu and Graeme Keith will be in a session. It's actually a video with Graham commenting on it. And David, I know you're talking about this as well, but if we talk about model risk analysis as an important component, right, of models we can defend,

53:32we had sponsored some research earlier in the year, and sponsorship in the form of encouragement and emotional support some great work done by Marco Nutini in a session tomorrow, where he'll be talking about the results of an ontology research and survey that he's been working on and what that looks like and how that relates, by the way, to the findings of that, how that relates to how we need to look and think about AI risk. And then one of my favorite topics is around this notion of how do we evaluate risk and mitigate it? We're ultimately going to find ourselves talking about controls. And what area is focused on controls? Many are, but certainly the world of GRC or governance,

54:23risk, and compliance is one of those areas, and we have two sessions that are going to help illuminate this topic, one later today with Ayoub Fandi coming, who's really one of the writers of the GRC Engineering Manifesto. And then we have Harshit and Ed Covert talking about what does GRC look like in 2026. So this goes to this notion of how do we build out an infrastructure? How do we think about controls? How do we look and think about how to provide a dataset that's continuous in its nature, not point in time, so that we have a data stream that can be continuous and continually update the risk scenarios that we develop, right? And so that underlying element is critical for it

55:09as well. Other thoughts that you have on common threads, good and kind, sir? Andrew, I actually thought when we first started talking about the agenda and deciding which sessions you're going to host and which sessions I'm going to host, I thought, "Well, this will give me an opportunity to sit out," right? But the more I look at the agenda, the more I think I'm just going to be glued to this chair and glued to this screen for today, all day, and again tomorrow.

55:50So bravo you for putting together a great agenda. I do want to acknowledge Andrew, who engineered the agenda. He engineered the flow. He arranged all the speakers and invited the panelists and put everything together. So Andrew- Great job putting the agenda together, and I can't wait to watch it unfold on my screen throughout the rest of the day and tomorrow. And I hope all of you will stick around. I know some of you will come and go. That's fine.

56:23We want you to get the most out of it, and we'll be here, one of us, the whole time to make sure that happens and to help the panelists and session participants do that. So with that, let's issue a challenge. What kind of session would it be if we didn't issue a challenge? I agree. So we're providing along the notion of guidance, which is the world that we're living in now, you can see a challenge that we're issuing to those of you who are attending. And maybe some of you are using something similar to today, and maybe this is new territory for you.

57:10I think that 10 to 20 enterprise scenarios is a little aggressive, so I'm going to push our challenge down to five scenarios. But I challenge those who are participating to not just be informed by the decisions, but actuate, right? I am a notorious lover of the term operationalize because anything in theory is great, but it's not meaningful until you operationalize it. So this is an approach that we are recommending for you to operationalize the knowledge that you will capture over the next two days.

57:47And with that, I think we are ready to move on, David, to-

0:06I have to stop sharing too. There we go. Yes, see. That's the part that I haven't done. Sorry for clumsiness, folks. Bear with me. I'll get the hang of this by the end of the day. And- Oh, until the next upgrade, the platform does. Exactly. I swear, the last time I did a webinar, all of these controls were in different places. And so- - ... it's like an adventure. So, here we are. Welcome everyone to session two, "The Evolution of Enterprise Risk Management," with Stefan and Linnea, Stefan Hunziker and Linnea Solem.

0:49Stefan is the head of the Competence Center Risk and Compliance Management at Lucerne University of Applied Sciences and Arts, and the head of research at the Institute of Financial Services, ZUG. He teaches risk management, decision-making under uncertainty, and research design at graduate level and the executive level, including EMBA programs. Linnea is CEO and founder of Solem Risk Partners LLC, a management and consulting and advisory services firm focused on privacy program management, third-party risk management, and enterprise risk management. She is a management consulting executive and former chief privacy officer and vice president risk and compliance for large, diverse technology

1:33service provider. She has a cross-functional background with 30 years of experience working in regulated industries and over two decades of experience working with executive management and audit committee board of director expectations for data privacy, public company controls, and service provider relationships. We are thrilled, Stefan and Linnea, that the two of you are joining us and providing this session. And also, I just want to thank you and acknowledge you for being part of ERQI as distinguished fellows. So, thank you for that, and take it away. Yeah. Thank you, Dave. Can you hear me well?

2:20Yes. Yes, you can? Very well. Thank you, yes. I just realized that my logo is much bigger than everyone else. - So let's call that a visual statement of full commitment to ERQI. - There you go. Thank you. And my Zoom platform defaulted to my company. Well, welcome. Thank you so much for that introduction. I'm excited to be here. Stefan and I have had a good time trying to pull together, knowing we were one of the first sessions after the intro.

2:53So, we really want to have this be a strategic conversation between the two of us and have that really start to build on what will be your two-day journey, really talking about all different aspects, depending on which track people are in, in looking at the concepts of enterprise risk and quantification. We're going to start with a little bit of just how you ended the conversation in the intro, looking back at how enterprise risk has evolved over time. I think that's important to really create that foundation as then we dig a little bit deeper into the methodologies. So, we're going to be doing kind of a combined viewpoint here from both an academic and research and methodology perspective, and I'm going to

3:45pepper in, here's the reality of applying those principles in the corporate environment. So, let me start with you, Stefan. How do you think the methodologies have really evolved over time from a research and academic perspective? That's a great question, Linnea. So maybe just a quick disclaimer before we start. So English is not my first language, so if I create any ambiguity today, I promise it's rather linguistic uncertainty, not model uncertainty.

4:16- Back to your question. Back to your question. If we look at this slide, it's a great slide, I think, we clearly see a history of risk management. So from insurance, hazard and loss prevention, through financial risk management, enterprise-wide frameworks, toward, let's say, a much broader view of risk. But I would add a second history, maybe a little bit more an intellectual one to this, because I think some of the most crucial and important advances in risk management did not actually originate in risk management. That sounds strange at first, but let me briefly explain. So for example, probability theory gave us the best language for uncertainty. There is decision theory. Decision theory connected

5:06uncertainty to objectives, alternatives, and actually value exactly what we want in risk management, right? Operations research, another discipline, gave us simulation approaches, optimization, and sensitivity analysis, for example. And my favorite is for sure behavioral economics and psychology, because both disciplines showed us that people do not process probabilities and uncertainty in a neutral, fully rational way.

5:33And organizational research told us that technically good information can still have surprisingly little influence in companies. So in a sense, I like the slide, I like the story. Everything I agree with. But risk management has imported a lot from neighboring disciplines. I think it's really also important to understand this.

5:56We imported many of the tools. I'm not sure we always imported the logic behind them. But anyway, for me, that leads to the next evolution, moving from risk first to- I'm calling it decision first. Yes, indeed. Mm-hmm. Linnea, what's your take on this? So, I agree that it has been a journey. I think when I look at it from a corporate perspective, I've stood up two different risk committees over my career at various levels of complexity.

6:29And I think one of the key things is that you learn along the way. Mm-hmm. It's not a linear journey, whether you're looking at the research or you're looking at how corporations apply principles. They adopt something, see what works. Sometimes things happen and their business changes, and they take a step backwards. Their risk has changed, not due to their failure to act on it, but the environment has changed. So, I think we have to always adapt the approach over time.

6:59And I think for a lot of companies, the risk started with either a fear or how they feel about risk, or something they had to do, whether there was a regulatory driver that forced them to justify business actions or decisions or to prevent a loss. But over time, the types of risk really started to evolve, and you can't measure every risk in the same way that you can measure something very tangible in those early days of insurance and loss prevention. So, you really have to start to apply a layered approach as you look at how technology risk, geopolitical risk, I mean, just the risk environment has dramatically changed.

7:47Mm-hmm. And I think that has really created both some pain points, but also some opportunities for organizations to look at risk differently. Mm-hmm. Yeah, I think also traditionally, we usually start with the question, what is the risk or what are the risks? Mm-hmm. How do we assess them? What goes into the risk register and so on. So, and decision theory, for example, would almost reverse that sequence.

8:14So, starting with the objective or the decision first, so asking, what are we trying to achieve? What alternatives do we have and which uncertainty could make us choose differently? Mm-hmm. And there's an interesting paradox here, I think, because managers have always managed uncertainty. That's nothing new, actually, whether they called it risk management or not.

8:35Right. Choosing between investments, deciding whether to launch a product, challenging a business plan, allocating capacity, or whatever. All of those involve true uncertainty. So, the formal ERM function is not valuable because it invented the management of uncertainty. That's not the point. Its challenge is to demonstrate that it helps managers do it actually better. So, this is my view on modern risk management.

9:06Yeah, that's a good point. I think let's dig into that topic a little bit deeper, because I think- Mm-hmm ... as organizations try and do that, they do incorporate some challenges. And I think, just like you were saying, too many times we're focused on the activity. We logged the risk, we tracked it, we defined it. We demonstrate, well, just by recognizing it, we're doing something about it, right?

9:31Mm-hmm. Well, that's a lot of activities, but what have you done to actually reduce the risk, mitigate it, or manage it? And those are different decision points. From your perspective, do you think we're measuring the wrong things? It's a great question. Yeah, and I like the slide here and the numbers. Maybe I'm just briefly explaining what I see from the slide or what I think about these numbers. I think there are actually four slightly different problems behind these bullets.

10:07Let me briefly touch on these bullets. What I find actually striking is the gap on this slide. So because 98% say ERM should play a more strategic role, but only 7% report full integration into strategy decisions. - By the way, this is in full alignment with my experience in Switzerland. I'm a professor of risk management in Switzerland. Yes, we have less companies, smaller companies on average, but the same problem sections. It's exactly the same.

10:33Mm-hmm. So I would actually say these numbers matches also more or less the situation here in Switzerland and maybe also in Europe. So at least in this survey, the aspiration is not the main bottleneck, it's the integration, right? So into actual decision routines. First, activity versus impact. Risk management is very often good at proving that the process happened.

10:56Workshops completed. We all know these risk workshops. Risks updated, actions closed, but that is evidence of activity only. It's not necessarily evidence of influence or impact on good decision-making. Second, I'm a little cautious with the term analysis paralysis. So, because in my experience, paralysis often begins because the decision question was never clear at first. If I do not know which decision the analysis is supposed to support, and this is often the case in my experience, I also do not know when I have enough information.

11:30The decision theoretic logic is pretty simple, I think. Additional analysis is valuable exactly then when it's reducing uncertainty, and uncertainty can plausibly change the choice, the conditions for proceeding maybe, or how we manage the exposures, actually. So one question I find extremely useful here is, which assumption would make us change the decision?

11:55Third, demonstrating value becomes difficult. If you assume that risk management only had an impact when management changed from yes to no. And fourth, managing risk before it becomes like a crisis requires signals, thresholds, and triggers, not only an annual snapshot, as is very often the case. So, my reading is actually of this slide- ERM may not measure too little or the wrong things. Maybe the wrong things, yes, but not too little.

12:26It just may measure the wrong evidence of success. And also, this exactly matches my experience of the last 20 years. So we are very good in measuring activity, in developing and creating reports, but not in measuring risk management effectiveness and the success, finally, of risk management. Mm-hmm. What do you think about this? Do you agree with my experience and the research behind it? I do, because I think when you look at it in terms of where people are at today and where they want to be, one of the things that I've experienced, depending on the nature of a risk, right, is that when things are a crisis- Mm-hmm ...

13:12it's easy for people to respond because you take accountability and decision-making off the table because everybody agrees we have a crisis. Mm-hmm. It's when the risk is not at the crisis level, you have to have some tangible way to say, "Okay, if we call this risk red, yellow, orange," whatever your color met- whatever your metric is, you need to be able to say, "And what specific things can we do to mitigate or reduce that risk?" Some risks will always stay high, and you have to make sure that executives understand that that inherent risk is there sometimes because of the nature of the business- Mm-hmm ... the nature of the data. I worked for a

13:52service provider, and no matter what product we had, we had 80% of the personally identifiable information of every citizen in the United States or non-citizen who had a checking account. Mm-hmm. That risk was never going to go away. That was our business. But what we had to do was figure out how do we manage and reduce a negative outcome.

14:16And I think that changes decision-making, and you have to have more tangible examples to make that real. Definitely. Yeah, it's a great point, Linnea, and I agree with you. Mm-hmm. And I think that's part of the approach that I like those statistics that we shared were from a recent COSO update on really trying to explore more thoroughly risk scenarios. And they used a great example that really hit home for me, because I've had to present to the board the annual risk updates or to the quarterly audit committee materials, and you're providing a lot of information.

14:58But it's challenging to then interpret those things. And I think one of the difficulties is that there's sometimes a gap between the teams that are accountable to present the risk and the board or the senior executive who's receiving that information, because what they want to know is, "Okay, don't tell me about the risk.

15:22What's changed? What matters now? And what do you want from us or what do I need to do, or what are you doing?" And the materials sometimes don't help that conversation. Mm-hmm. Do you know why that gap continues to exist today? Because it feels like that's part of what those statistics we're sharing is that there's a gap, an uncomfortableness, and yet we haven't figured out how to close that gap.

15:51Yeah, it's a great question, and I have an answer or a potential answer to this question. So I would frame it less as a methodology problem and more as an attention and decision context problem. So let me briefly explain what I mean by this. So I think the scarce resource at board level, specifically in Switzerland, where I have a lot of experience with, at board level is usually not information, it's attention. It's basically the same also in other countries. It's attention.

16:25But low management attention, I'm often hearing that there is too low management attention. Risk management produces a lot of information, which is never used then later on in decision-making. It's a symptom, not a diagnosis. Before trying to create more attention, I would first ask why the formal risk process is not being pulled into the decision, because this is the proper question to raise.

16:52So on this slide, like the top 25 risk list may contain a lot of information, but in a 20-minute discussion, 25 priorities are not really priorities. They are competitors for attention, and that's a huge issue. And there is an important distinction here between governance information and decision information. So a heat map, I'm not a fan of heat maps. We're coming back to that tool in a few minutes, I think. A heat map, a top 25 list, and an appetite statement may all fulfill a perfectly legitimate governance purpose, yes, but that does not exactly mean they influenced a management choice at this point. So I increasingly think of a board risk report not only as an information

17:38product. It's more an attention allocation mechanism. So what does management need to notice now? What changed? What decision or action follows? There is actually a much older management idea behind this. Herbert Simon wrote in, yeah, it's 50 years ago in 1971, that the wealth of information creates just a poverty of attention. So research is backing up this perfectly here.

18:08And Ocasio later made attention central to organizational decision-making. So what decision-makers do depends partly on which issues and answers actually reach and hold their attention. So that is exactly why I see the board risk report as an attention allocation mechanism, not simply an information product. Yes. Mm-hmm. Mm-hmm.

18:31I agree with that, and I think, when I think back over time, you know, creating the, um, risk reports, the scorecards, uh, as the, the head of the risk committee or as the leader trying to present that information, I found what was the most valuable wasn't when I presented the report- Mm-hmm ... but if I strategically knew I had to change a metric to show a risk was changing color, meaning the risk was getting larger or there was more negative influence, we were sliding backwards, when they got their materials, that's the only one they looked at.

19:11Mm-hmm. So I knew that that was going to focus the conversation. So it almost became strategic- Mm-hmm ... to be able to say, "This risk is changing. We need to call attention to it," and be able to justify that decision because you're right, it focused their attention. If they just looked, "Oh, this looks like the same thing as last quarter, let's get on to the next conversation." But if all of a sudden there was some trigger point with arrows going the wrong direction or a visual cli- click, you know, it, it, it forced them in their pre-read materials to look at that section of the materials back first. Mm-hmm.

19:46So it, it's one part of a technique, but I think you're right, it's about so many risks, they're not controllable internally because some of the risks are based on the, the external landscape and the environment. Yes. Um, and that really makes it challenging to say, you know, "What can we control about that?" And so it really requires a different way- Mm-hmm ... to present the information to make it more manageable and, and useful.

20:14Yeah, exactly. Maybe if I may add a specific example, because just recently I saw this very clearly in a hospital board meeting. So I've been consulting and coaching companies for the last 20 years, um, across several industries, and recently I, I joined, like, a board meeting in a hospital, and the risk report came near the end of the agenda- Mm-hmm ... just before lunch. There were essentially, like, two questions. "Has anything materially changed since last year?" And the answer was no. "And can we approve the report?" And the answer was yes, and the job was done. This was very efficient, five minutes maybe. - Literally five minutes. Perhaps a little too efficient for decision support, I

20:56think. So from a- Mm-hmm ... governance perspective, and that's exactly my point, the job was done in Switzerland. So, uh, the legal requirements were met actually with, with this report and with this discussion in the boardroom. And that may be perfectly legitimate. It's fine from a governance perspective maybe. But if I ask myself whether that discussion actually improved as any significant management decision, I'm not sure where that happened. Actually, it didn't. So governance success is, is pretty much different from decision support success. It's just not the same thing.

21:30And, uh, I think this is really also important. And whenever risk reports are discussed at the very end, after all the decisions, uh, have been taken, then this is a strong signal that they are reporting as more a governance purpose and not a decision-making purpose, because it's not an integral part of the management decisions. It's after the fact, actually, when everything is done already, and then it's- Mm-hmm ... of no use. This is a very strong signal in practice.

21:56Mm-hmm. Just attending board meetings and, and, uh, just checking the agenda. If risk management is an integral part of the management discussions and decision-making processes, fine. But if it's just another agenda item pretty much towards the end of these meetings, then we all know it's just for the purposes of, of meeting the legal or- Mm-hmm ... the governance purposes, actually. So that's my view. Mm-hmm.

22:22That's actually a good way to transition to really starting to think through, how do we evolve this? - How do we start to shift, uh, the perspective of how we're, we're looking at enterprise risk and risk scorecards? Mm-hmm. Um, so w- how do, how do you think we should start to evolve from that heat map and risk matrix and start to shift the thinking?

22:49Yeah. It's a crucial question, Linnea. So luckily, Andrew has already saved me some work today. - So he introduced already the, the big issues with the, with the heat map. So he has made a very strong case about the limitations of heat maps, and I suspect many of you left, hopefully left the five by five years ago. - Um, but your management may not have. So this is my experience in Switzerland. Nine- 98% of all the Swiss companies are still using risk maps, even if they do know, uh, they're not useful and they do not work. They're proven not to work, by the way. It's one of the tools that is really well, uh, empirically researched and well-known that it's not working, right?

23:30So, but that's not my main point. Uh, hopefully all the, the, the attendees today already know that risk, uh, maps are flawed and they do not support decision-making. So my point is that the same failure repeats also one level up, by the way. So of course, high doesn't... Highest is not a number. You cannot use it for decision-making. 12, we do not know anything, because risk is a distribution. Ri- risks are ranges, right? Risks are uncertainties, not single point estimates. So it's of no use. So it's, it's actually quite the opposite of risk management, what we have here. So to say a risk is 12, this is exactly the opposite. It's an expectation value, and expectation values

24:08are not a risk measure. So it's of no use, actually. But the problem is also, let, let me repeat that, um, usually one layer above, um... So let, let me use the matrix only as a starting point for the problems. Here, I would make an important distinction. A risk matrix is, is often treated as if it were the risk analysis itself. It's called the risk assessment or risk analysis. It's not. I, I do not think it is. It can't be. At best, it's like a vi- visualization or, yes, maybe a classification layer on top of- ... of the analysis for reporting purposes, but it's definitely not risk analysis. It has nothing to do with risk analysis. The real analytical work should

24:52happen before the dot appears on any heat map. So, what is the uncertainty behind? What do we know? What do we don't know? What are the assumptions? What is the time horizon, and what are the possible consequences? Then we may compress all of that into likelihood three, impact four, and suddenly we have a 12. A 12 what? So, I mean, the matrix is a display format. It's not an analytical engine. And there is another problem. It does not remove judgment. It hides judgment actually inside a cell.

25:27So once the dot is there, the output looks much more objective than the judgments that produced it, so it's a huge problem. So, my concern here is not only simply false precision, so it's pretending false precision. It's false precision combined with hidden subjectivity, and this is really, yeah, it's a catastrophe to risk management, I think. It's not even neutral. It's worse than neutral using these risk maps and compressing our numbers into expectation values. It's just the opposite of good risk management, actually, and we should drop these instruments.

26:05Mm-hmm. - Yeah, I think as you look at the colors and that false precision that you're talking about- Yeah. ... I think one of the things that is challenging, whether you're leveraging the tools, is you're spot on. The hard work happened before you figured out which box the risk is in, because you had to apply the environment back into the organization, to their products- Okay ... their services, their market, their stakeholders. There's a lot of those internal factors and the external environment.

26:39Mm-hmm. The other thing that I've experienced over time is that people will think about a risk appetite statement and risk culture. You've got to almost look at that like the Rubik's Cube, because you've got- ... the risk appetite and culture of the enterprise organization, but you may have a business that has a very conservative line of business and a very aggressive line of business. So you might have two different diverse sets of services, and now how do you reconcile different risks?

27:14Mm-hmm. And then even if you're presenting to senior leadership, or specifically at the board level, depending on where that report is going, to the overall board, to the audit committee, every stakeholder has a different risk culture based on where they came from and what their accountability is on the board. So, I think one of the things that's difficult for a lot of organizational resources presenting risk is that if you're having an IT security, cybersecurity conversation, you tailor the risk map to that audience- Mm ... because people already have that fear and they know exactly what the big red threat is. But if you're presenting more resilience,

28:05business continuity, disaster recovery, you've got all these external factors, you've got to change your metrics and your measurements, and that's challenging without something to stand on. - Yes, exactly. Otherwise, it's an emotional reaction to whatever you're presenting. Yes, it is. It often is, actually. And I think we could ask ourselves, why is this risk map still used? Why is it still so popular? Yes, there are several answers to that. It's easy, it's well-known, it's fast, and you reach very quickly consensus about risks, but this is usually misleading. So my critique is not only about the risk management per se, but it's linked to the decision-making, which I think is the most valuable part of risk

28:56management. Because let me just briefly summarize, then we can leave it, and we won't- Mm-hmm ... talk again about the risk map - hopefully today too often. Mm-hmm. So first of these four points, just briefly. First, ordinal categories are useful for classification maybe, but we cannot multiply these labels. The resulting score has no clear quantitative meaning. It's just wrong mathematically, not useful. So second, the apparent consensus, and that's really tempting to reach this consensus so fast, and it's also appealing for managers, risk managers, because you can reach consensus that fast. You can agree on a color very briefly, but it's usually misleading. So everyone may agree that the risk is

29:36yellow, so we have a tendency to the middle there anyway, while disagreeing substantially about probability, time horizon, consequences, and assumptions. Third, and that's important, you cannot meaningfully aggregate colors into an enterprise exposure. So speaking of also risk appetite, comparisons of risk exposures to risk appetite statements, it's just not possible to add, to aggregate risks into an enterprise exposure. So portfolio effects depend on distributions, that's a fact, and dependencies, not on adding red and yellow dots. It's just not possible. And fourth, the usual matrix is also fundamentally downside-oriented.

30:16Strategic decisions, however, are different. So management has to compare downside and upside together, and it's just not possible by using risk maps. So the deeper issue, I think, is the risk map can classify some exposures maybe, but it cannot do the decision analysis for the management. Mm-hmm. I think this is really, we have also a paradox here, because we call it a tool of enterprise risk management ultimately, but the basic measure we often use, colors and ordinal scores- ... cannot be meaningfully interpreted or, or, or aggregated.

30:56So yes, it's not really useful, this tool. Mm-hmm. So let's, let's shift into some of the other areas to improve, um, that approach. Um, and I think, uh, as you look at enterprise risk, uh, as a discipline or as a function, uh, within an organization, um, it does tie back to, you know, how an organization looks at risk statements.

31:26But the reality is, you need data to create an insight- Mm-hmm ... that then helps create an action. And I think the data supports the, you know, the, the analysis that was done. It shows that we've looked at all aspects. But I think the key for making it more meaningful, whether you're presenting it to the C-suite, to the board, or to line managers, is that you have to put it into tangible examples within the business, so that they can say, "We do this X or Y, or somehow we've got to do, you know, something in between." But you've got to take it from something esoteric and, um, aspirational- - ... in terms of a risk statement, to something that, you know, everyone can agree we, we know what our thresholds and

32:21our, our boundaries are. Yes, I agree with you, Linnea. So I, I think it's a very misunderstood concept in practice, a useful but misunderstood one. Risk appetite is just a great example of a concept that often sounds more operational than in, than it actually is in practice. So that's my experience. So le- let me just make an example. Maybe a statement could be like, "We have a lower risk appetite for cyber risk."

32:50Is this useful or not? So fine, it sounds good, and most would agree probably on, on this, on this statement. Um, but what should, what should a manager do differently tomorrow just because of this specific risk appetite statement? Um, and in practice, risk appetite becomes only useful when it is translated into a decision boundary.

33:12I saw a very simple version of this in, in an hospital also recently. So management had defined a minimum EBIT level, and if the risk analysis showed that EBIT could fall below that specific threshold, management action was deliberately required. So that could mean cost measures or changing the timing of initiative or, or any, um, other i- intervention.

33:35No complicated color scale. A number, a specific threshold, and a consequence, and that's very important. Um, but the threshold did not determine, like, the right decision. It ter- it determined when management had to have the decision conversation. And I think this is really important. I've seen rarely companies which...

33:58or risk appetite statements triggering specific co- decision conversation in, in companies. They look great. They sound good. Also, they can be communicated well, disclosed also publicly. But if we look at these statements and ask ourself, "Are they really actionable? Do they alter decisions, or do they make decisions better? Do they have specific consequences in, in daily operations?" And my answer is often no.

34:27They just look- Mm-hmm ... or sound good, but they do not have an impact in practice. Mm-hmm. That's a huge problem with these risk, uh, appetite statements. Mm-hmm. I think they are useful indeed, but you need to define them, them properly and make them actionable, actually. Yeah, the simplest wrap-up on this topic is a, an example I heard from a CEO at a large national, uh, financial institution in the United States. This was at the time where consumer protection, ethics in sales and marketing practices were a huge regulatory focus. Mm-hmm.

35:01And even though they had an risk program and risk... all of the governance statements, he said, "It's the grandma factor." - "Look at what you're doing. Would you sell the product that way to your grandmother? If the answer is no, go back and redo." And it was simple, but it, it put it into something tangible that every employee could understand.

35:29Mm-hmm. And so you, we've gotta make it actionable in a way that's, that's meaningful. I, I love the example. It's a good one. - Really. It's a great one. - And I think, you know, in to- in today's term with AI, you know, it's a good one. I mean, you gotta- Yes ... you gotta just... We g- we all- Mm-hmm ... we all need to take sometimes a pause and say, uh, you know, "We gotta look at, you know, what we're doing or how we're saying things from different perspectives." - Exactly. Yeah.

36:01And I think that is changing the conversation a little bit more. Mm-hmm. Um, and, you know, and, and I think that requires more, more thought. I think in the intro- Mm-hmm ... I liked how the challenge in terms of framing, you know, looking at then, you know, different alternatives. And I think that's where the analysis part of enterprise risk management starts to evolve, because we have to look at different, um, i- i- different points, but also over time, different factors- Mm-hmm ... that factor into the decision-making.

36:37Mm-hmm. Yes, Linnea, I think quantification is, is one of the most hotly debated topics in risk management for decades, in my experience. And also, there's always the question, what's better? What's superior? Is it qualitative risk management versus quantitative risk management? And I don't like the question, what's better? So because it really... It, it...

37:01The answer here is definitely it depends. It depends on the problem at hand, the decision problem at hand, and sometimes it's also the combination of both qualitative and quantitative. I would never see us like this, this two distinct disciplines, and they're fighting against each other, um, searching arguments and, and, and looking for reasons why one is better than another one. And, and I don't like this discussion. I think we should merge both and, and exploit the best of both worlds, and asking the question, "What serves the decision most?" Not what's the best. Is, is quantitative or qualitative risk management better? That's just the wrong question, uh, usually. I think it's the

37:43biggest misconception in risk management, that quantification, by the way, means like replacing uncertainty with one precise number. I, I'm often hearing in practice, "Okay, we can't just... We, we don't have the data. We can't be as precise as you like. Uh, we, we can't end up with a number. That's just not possible. And the number is wrong anyway. Why should we calculate it, uh, it anyway?" So these are all the wrong arguments and- Yeah ... excuses for, for quantification, because risk management is quite the opposite of having like a precise number.

38:19It's about showing uncertainty in a meaningful way. So it should do exactly the opposite, not being precise. It should show the ranges, the uncertainty attached to, to- Mm-hmm ... decisions and, and risks. So a range does not create uncertainty. It, it reveals uncertainty that was already there, actually. So it's just a good starting point for a sound discussion- Mm-hmm ... about, about risks. Mm-hmm. And good quantification, in, in my view, does not eliminate disagreement. It's not the goal.

38:50Definitely not. It, it moves disagreement to like, uh, let's say a better place. Instead of just debating whether a risk is high, we can debate the probabilities, the ranges, the assumptions, or the causal mechanisms, also a very important topic. And that is progress in my view. And this- Mm-hmm ... is really a question of representation and communication of risks.

39:13Show the same distribution to three executives, for example. So maybe the CFO asks, "So what is the number?" And the CEO asks, "What is the downside?" Someone else asks, "Who made these assumptions?" There are three people and three different questions, and, and it is just still one distribution. And representation of risk is just not neutral. So this is a very important point also to make. Mm-hmm.

39:35It needs narratives, it needs context, it needs explanation. And this is, is- Mm-hmm ... is really important. And I... What I usually see is either it's too narrative in nature, not clear enough, or it's too precise number-wise, and there is missing context and missing narratives around the numbers. And both do usually not work. So it's a combination of both.

40:01Yeah. I think the narrative is critical because- Yeah ... you know, if you show sometimes, you know, all of the information, it, it gives the perception that you can control all these things. Mm-hmm. And we know that there's been a lot of things so far this year that weren't on anybody's risk scorecard or dashboard. You know?

40:22- So it's a case of, you know, the- Mm-hmm ... the dynamic nature of risk has uncertainty and things you can't control. What you're trying to put a wrapper around is, what can we do about it? What should we do about it? Mm-hmm. I always talk to my team. It's always at... When... Every time you talk, it's the whats, the so whats, and the now whats.

40:47- Mm-hmm. Because you can give me all of the fancy-schmancy, you know, way you got there. I don't care about how you got to the journey. I wanna know what the problem is, what bad things are gonna happen, or what good things are gonna happen, and then what do we do about it? You gotta make it real. Yes, indeed. Yeah. Yeah. And I think that's kind of what, what, what this example was, was just trying to weigh the two things about- Mm-hmm ... you know, you're having a conversation, um, and both are probably technically sound in terms of methodologies, the way you are presenting a risk.

41:25Mm-hmm. Exactly. But the way that the executives or the audit committee, the board, or the investors- Mm-hmm ... or stakeholders are gonna look at that, um, can be very... can be viewed differently. Mm-hmm. Yes. So how do you think the, the, this, the methodology really shifts the way you make decisions? Again here, the same hole. So does... The question, does quantification really make decisions better? So my answer to the little question is, is, is very clear. No, not automatically. So usually there's like a claim that numbers and quantified risks, uh, can easily be communicated, and they are taken more seriously than narratives or qualitative risk assessment. That's not true. So empirical evidence says, says

42:16quite, uh, the opposite. So my answer is not automatically. Um, it's like... It forms like also a false confidence. One is the red dot on a heat map maybe, and then this is transferred to a precise number. And an interesting thing here is that quantitative risk analysis, they, they really show the competencies of risk managers, so dealing with all the statistics, the, the data and everything.

42:45And usually management is impressed by this, and they also say, "Yes, our risk management is very, very competent in dealing with a statistical analysis and everything." But the question is, does really action... does really follow action from this? So- What actually management does with the information created, even if it looks very sophisticated, is a totally different story. And we know from research that well-quantified, sophisticated risk models, even if they are correct, technically correct, management is impressed by the sophistication of these models, but do not automatically take action on these numbers.

43:29Here we know also from research, and I think this is a very crucial learning also. So quantification, even if it looks impressive and even if it shows the competencies of risk managers, it needs these narratives. It needs the context. And here's a great example on this slide representing a whole research stream about risk communication.

43:52And risk communication is way underrated in practice. So we love to focus on risk identification, risk analysis, risk aggregation, all the technical stuff and the risk models, Monte Carlo simulations and everything. But that's just a means to an end, not the end itself. So the end itself is changing or making decisions better. And here, there's a gap between what risk management produces and what management really actually triggers to action. So the question is, what triggers action? And usually it's not the output of well-sophisticated risk analysis per se, it's the stories around these statistics and numbers. And the second example on this slide

44:34is the far better one in terms of that it can, or it at least increases the probability that management takes action on this, on the way the risk is communicated here. Chances are far higher than the first example, cyber event risk calculation just based on numbers. No narrative, no explanation, no context, no language of the business included. Looks good and it's technically correct, but still nothing changes. So risk communication is key, and this is way underrated and underrated in practice, I think. Mm-hmm. How to communicate risks meaningfully to the board and to the executives.

45:14Mm-hmm. Yeah, and from my experience, a simulation helps make it real versus the actual crisis event or the negative situation happening. And I think a lot of times we miss an opportunity to share a simulation or an event that maybe didn't happen within the own organization, that maybe it happened to a peer company or to a competitor. And sometimes that's also a safe way for a risk professional within the organization to look at that event and say, "What if? What if that scenario had happened to our company?"

45:57Mm-hmm. And then that's a way to change the narrative to say, "That was not something we were monitoring. Should we monitor it? How do we evolve that?" But I think it's again connecting the dots to what does it mean to the stakeholder? What does it mean to the company? What does it mean to the end customer? You've got to look at all of the people or resources that could be impacted by the risk to take it out of just a governance or a compliance scorecard to say, "Here's what it means to all of those different participants." Mm-hmm. And that's where there's not likely one approach to that. You've got to figure out which type of risk you're talking about

46:40and what's going to be the best approach or method to analyze that risk or determine how we prioritize. Mm-hmm. I would also, maybe you can just go back to the slide just for a second, if it's possible. Yep, yep, yep. Yeah, it is. So I would just, here, I would distinguish analytical quality, so just to make my point very clearly. So I would distinguish analytical quality from decision readiness. That's not the same. So again, a technically excellent distribution may still be only information.

47:18It becomes like decision-ready when management can connect it to something it owns, actually. A tolerance, an alternative, a consequence, or a choice. A tolerance breach tells management a decision is needed. It does not tell management this is the right decision. That's not the purpose of risk management. Judgment still belongs to the management ultimately.

47:39Mm-hmm. But the model informs the decision, and it does not make the decision. So this is really an important point to make. So- Mm-hmm ... yes, just to add that to this. Mm-hmm. Absolutely, because it's about management owns the decision- Mm-hmm ... but they need to feel comfortable that they can accept the negative outcome or downside. Exactly.

48:06And if that downside is not clearly articulated, did they make a good decision or did they get bad data? And I think that's where you get into that ongoing viewpoint of how do we continually look at the way we're having that conversation. Exactly. Because you're right, it's all about the discussion that then really brings all the perspectives together.

48:36Oh, I love that slide. - Well, and I think this is just kind of as we try and bring these themes together. Mm-hmm. I think quantification was easier in the early days when everybody was just worried about the cost of a data breach, the cost of cybersecurity. Let's quantify it and figure out how much, what's the expense side of- ... responding to the event.

49:09The expense side is always the easiest thing to measure. Mm-hmm. Because you can put it specifically into P&L terms. You can't always measure, will we really lose the customer? Will we really lose the client contract? Will we really... You need to be able to have different conversations in terms of quantifying based on the type of risk that you're talking about. Mm-hmm.

49:36Exactly. For me, the most important column here on this slide is definitely the left one. Because the research here on uncertainty and risk analysis is very consistent on at least one point. Yeah. There is no universally best analytical method. I'm sorry. There just isn't. So the appropriate method, because I've been hearing this discussion like, which is the best method? Should we use Monte Carlo simulation or more tornado diagrams, or should we use scenario analysis, or which aggregation techniques?

50:13How sophisticated is our statistical approach to model correlations and so forth? Usually, it's just the wrong discussion because the appropriate method... And we have all the methods already. We don't have to reinvent the wheel. Everything is here for decades, right? So we have just to exploit it, actually. So the appropriate method depends on the decision. So first of all, the uncertainty attached to that decision and the evidence available and the context. But I would go even one step beyond first the question, then the tool.

50:48Of course, this is correct, as showed on the slide, perfectly fine with it. But the decision does not only choose the tool, it defines the analysis ultimately. If management is like comparing investments, for example, I may care about distributions of outcomes, of course. If management, however, is testing like a strategy, sensitivity analysis may tell much more because I just want to know which assumptions make or break the business case. If evidence is thin in an M&A due diligence, for example, and usually evidence is thin, structured expert judgment can make assumption explicit, and Bayesian updating, a great approach, I'm a fan of Bayesian updating, can revise valuation

51:30assumptions as new evidence arrives. And under very deep uncertainty, and we have and we face a lot of deep uncertainty, actually more than we know or more than we assume, actually, a more sophisticated probability model may actually be the less rigorous choice. So, methodological sophistication is not the same as maturity, as I call it. So the mature method is one that fits the decision, not which one is the most sophisticated in statistical terms, for example. And these are just examples here on the slide, not prescriptions, of course. But I think the table does not mean every investment needs Monte Carlo or every M&A deals needs Bayesian analysis, of course. But my point is that the decision question

52:19should definitely determine what kind of uncertainty we need to analyze. Linnea, from your perspective, where do companies start with this decision-first logic, and where do they get stuck maybe? So, I think you've got your traditional types of risks that you're monitoring on a quarterly basis, right? You get your annual update on hot topics like cyber, resilience, regulatory compliance. What's often missed is the interdependencies- Mm-hmm ... across different risks.

52:55And I'll use an example. If you're presenting or monitoring third-party risk, you always start with who are your high-risk, critical, non-negotiable, critical third-party relationships. Well, in today's technology environment, it's not just them. It's their cloud hosting provider, and then it's that cloud hosting's provider, technology provider. It's third party to the nth party and all the way down the chain. And events, situations, threats, all of that can impact not only what the organization is monitoring, but an entire ecosystem. Mm-hmm.

53:35So I think sometimes people minimize portfolio thinking because they're looking at what they can control and just kind of throw their hands up to say, "Well, we can't control all of these things." Well, this is where your risk methodologies need to shift a bit because you need to be able to say, "How can we make this real so that we can inform actions that management might need to take?" Mm-hmm.

54:00What can we do to reduce our concentration risk? What can we do to diversify dependencies geographically? So, one methodology may look great for one event, one siloed, but just even if you negotiate a contract with a client and say- Mm-hmm. ... "We mitigated the risk by this contract term," okay, great, but did you look at all 1,000 contracts?

54:27What's your aggregate risk across that type of... And are we presenting the information in the right way? So that's where I think you need to tailor- Mm-hmm ... your risk approach based on what's the bad outcome, what's the positive outcome? Mm-hmm. What does management need to do or know to be able to either take action or feel okay with not taking action? Mm-hmm.

54:55Because not taking action is not necessarily the negative. It may be that we're okay with the status quo, or it's not something that we can necessarily control, and we're okay that if the negative outcome occurs, we can recover. So again, it's all about putting it back into business terms. Exactly. Yeah, great points, Linnea. Time flies. We're approaching the end- - ... I think so. Just may I add one thing here, just regarding the last slide, the previous slide? Just one thing, which I think is particularly important.

55:31We usually do not admit what we do not know. I think usually risk management lacks some honesty. For example, knowing when not to quantify. It's not on this slide. Yes, it's not. - But knowing when not to quantify. This is particularly important on the, let's call it deep uncertainty. Sometimes we do not know the relevant future states well enough to defend a precise probability structure, for example. And adding another distribution can then make the model looking more sophisticated and more sophisticated while making the analysis less defensible ultimately. So I think in exactly those situations, scenarios, ro- robust options, stress testing, or monitoring may be just more

56:14honest. I usually add a section in the risk report, what we do not know. This is just honest, and I think the board also deserves to know what we do not know, where we need to be careful, because many things, many risk reports look like they know everything. It's like a comprehensive list of all the potential risks a company faces. That's just not true. There are many risks not known, and we should declare and also be honest about this, that what we do not know.

56:43And I think this is also very appreciated, by the way, by executives and decision-makers. Otherwise, it just makes the impression that risk reports are a complete picture of the risk exposures, and that's just not true. It can't be. Mm-hmm. Yes. Thank you for letting me add this. And I think, David, that's a kind of a good transition to kind of our wrap-up thoughts, because, you know, again, we wanted to start today's first panel here with kind of an evolution of risk from different viewpoints, and I know that over the next two days, we're going to take this down into a lot of different topic areas. But it's all about helping organizations make good decisions.

57:24This conversation has been amazing. I've gotten so much out of it, and I look forward to having a recording of it that I can go back to- - ... because some of the framing, especially this concept of attention allocation mechanism, the importance of the narrative, the storytelling aspect of risk, fantastic. I would like to just get to at least one question. We have many questions, and, you know, if you want to, as, as Matthias and Markus start, if you want to answer some of these by typing answers in the Q&A interface- Okay ... you're, you're welcome to stay as a panelist and, and, and take care of some of them that way in parallel with Markus, because I, I love that people are asking questions. But one

58:19of the questions that I, I'm just picking one at random. Someone asked a question about the... Well, they're looking for advice on how to wean management away from the risk matrix because they perceive that management finds the ambiguity of the risk matrix reassuring in some way. Like, they, they like hiding behind that ambiguity.

58:55Yeah, exactly. Yeah. Do you have any advice? Yes. They should read my book on risk management. No, just kidding. - First of all, I would like... I see it like a transition towards getting into like a better place, as previously mentioned. So maybe you can just have the risk map in parallel to another more advanced approach. So for me, tornado diagrams specifically, they work very well. So I use... So sometimes the boards and the executives just tell me, "Professor Hunziker, you can do whatever you like to do, but just leave the risk map. We love and we like the risk map because it's, it's, we are, it's well known and we understand it, so don't drop

59:36it. Do whatever you like to do." Then I, I usually suggest to have like something in parallel. So just, it's like a fade-out process of the risk map, if you will. So first off, I- I'm just offering an alternative to the risk map. And in the, maybe the first one or two or even three years, sometimes it takes three years, it's, it's really, it's really a journey. You cannot have like the Big Bang overnight. That's just not possible to change everything. But then I have like two alternatives in parallel, and I'm reporting this to the board, and specifically transferring dots on heat maps to like ranges on a tornado diagram. So this is, this is a well-known diagram also drawn from decision theory. And it's, it's

1:00:19particularly useful because it can easily depict risks in, in ranges, and risks are ranges. And I'm using both. So I have an alternative. And the management, executives and boards, they start to understand that the, the richness of information in the di- tornado diagram is much higher than in the risk map. And so I'm usually very successful in fading out the risk map over years and then drop it ultimately. So you need to have an alternative, which is pretty simple, and the tornado diagram specifically is, is a great way to have like a, yes, a subtle transition to better risk management, as I call it.

1:00:58A stepping stone, if you will. Yeah, it's a stepping stone. Exactly. Yeah. I really, I really love that answer. So Stefan, Linnea, please, thank you very much for joining us today and for being involved with ERQI. If you'd like to stay on as a panelist for a few moments and answer some of the questions- We will. ... that would be fantastic.

1:01:24Maybe turn off your cameras so that we can hand the stage to Matthias and Markus. Sure. Andrew. Thank you very much. Also, Linnea, thank you very much for this conversation. Really appreciated it. Andrew, I pass you the baton.

0:06Excellent. Now coming to the stage, we have Matthias Pouyanne and Markus Kaufmann, if you would join me, gentlemen. Such a refreshing moment to see the smiling faces and the power and the intellect that is now sharing the screen with me. So thank you both for your time. I am fortunate to have known both these gentlemen for several years now.

0:36I met Markus Kaufmann several years ago when we were working on, lo and behold, some risk quantification efforts. And I still remember him asking me a question that I had no good answer to, but now I do, about how do we aggregate risks from multiple scenarios? So thank you for guiding me down that path, Markus. Also with us today is Matthias Pouyanne, who has educated me on a number of different topics but in particular, helping me to understand how to use things like threat intelligence and threat actor techniques and how to use those to create scenarios and evaluate the risk from scenarios. So Matthias, thank you for those.

1:23Unlike David, I am going to ask you to just give a quick intro. And if you speak too long about yourself, I will cut you off. Just kidding. But if you would make some remarks on your own, I would appreciate that. And Matthias, I'll start with you. Thank you, Andrew. First of all, I'm very happy to be here. It's the first risk summit of the Enterprise Risk Quantification. I see this as the very first step of a great way forward, so I'm very enthusiastic.

1:57So about me, I'm Matthias. I'm a founder of a small consultancy, actually a boutique consultancy. We've been there for three years. And all we do is risk quantification. But that's climate risk, strategic risk, operational risk, cyber risk, and so on and so forth. And we also work a lot on what do we actually do with the figures that we produce, because producing figures is now close to being a, I was going to say a commonality. Everybody is able to produce risk numbers and figures. And AI is helping a lot as well in that regard.

2:44But, well, what do we actually do with our figures and with these euros? And that's exactly what I've been focused for maybe 12 months. And I think that's one of the next steps of risk quantification, actually. What is the governance behind risk quantification, and what do we do with the figures that we produce? And Markus Kaufmann. Outstanding.

3:10Good morning, everyone. My name is Markus Kaufmann. I'm currently an executive director and risk information officer at Kaiser Permanente, a large nonprofit health organization in the US. I've been with them for a number of years. Prior to that, depending how far you want to rewind, I started out as an IT guy, got into cybersecurity with Wells Fargo, spent a number of years with them.

3:36And really through the lens of first being a risk assessor, traveling all over the world, looking at various security programs and the like, and trying to really struggling with consistently identifying risk and calling that out, right? And finally getting into how do we actually quantify that risk, right? How do you get to a point where you don't feel like you're just throwing a dart, right? Which your standard heatmap a lot of times feels like because you can't accurately map things out, right? You can't consistently do it, especially as you start looking at wildly different organizations, right? I mean, I would back in the day go to assess an insurance company with 10,000 employees, and two weeks later,

4:26I would assess a startup that had three people, right? And how do you consistently call out findings for massively different organizations like that? So over the course of time, got into risk quantification, how do we get more consistent? And that's what ultimately led me to cross paths with Andrew, so very fortuitous in that regard. And my current mission really is, as I've come from very much a cybersecurity lens, is, hey, how do we take some of the risk quantification practices that we've built in cyber, right, specifically things like FAIR, and how do we broaden the use of that to apply more of an enterprise scope, right? How can we apply it to different

5:18operational risk disciplines, for example? Yeah, and that's the path and mission that I'm currently on, and we'll talk to that a little bit here this morning. Fantastic. Well, it is my turn, Matthias, to ask you to take over, if that's all right. If you could launch your presentation. That would be great, if you don't mind, sir.

5:47And I'm here with you. Look at that. And pooyah. All right, Matthias and Markus, take it away. Thank you, Andrew. So my quick introduction is, why do we quantify risk at all? Obviously, that's not to produce numbers. We would never spend that much time, that much effort, and money just to produce numbers. The goal, from our instance, is to understand how exposed we are and what an incident could do to the business objectives we've committed to.

6:31I said business objectives. Of course, defining business objectives requires a little bit of brain power. But there is one common objective that we all have. Like every organization, listed, private, public, nonprofit, there is one objective that is actually obvious to all. That's survival. And everything else that we do is conditional on survival.

6:59When I say survival, we'll focus on that later, survival isn't bankruptcy. Survival is more keeping control and keeping the investment capabilities that we have and that we built. And that's actually the whole question I want to put in front of you today. The main point is not how much can we lose, but it's what is it that takes an organization's future out of its own hands?

7:34And I will start with a quick introduction from Markus on the fundamentals. Over to you, Markus. Thank you, Matthias. So, when we talk about an organization's survival, right, especially from a risk lens, that really translates into what we would normally term risk capacity, right? In other words, how much risk can the organization take on before they either cease to exist or, as Matthias put it, right, they lose control of their own destiny, so to speak.

8:09And as part of that, I want to quickly define some things that I think will help frame the context for what we're going to get into in this presentation, right? And that really is fundamentally the idea of a risk appetite, right? In other words, how much risk is an organization willing to take in its pursuit of business opportunities or regular course of action, business as usual type activities?

8:39And then, of course, risk appetite, we have to look at within the lens of overall risk capacity, right? Rarely, if ever, will we say that, "Well, our risk appetite is our risk capacity." Maybe some small startups may try to go that route, but will probably quickly realize that there is a threshold that you have to establish.

9:03And generally, we start looking at the concept of risk tolerance, right? In other words, "Hey, here's the risk appetite that we're willing to take on over the regular course of business, but in case we exceed that risk appetite, we'll also define a risk tolerance." And again, generally, that's a little bit less than your overall risk capacity.

9:26And then in conjunction with defining that risk appetite and risk tolerance, we're going to most likely also start setting some thresholds. And a lot of folks will say, "Well, yeah, we'll define a threshold, a single threshold." In my opinion, there's nothing wrong with establishing multiple thresholds. And as a matter of fact, I think if you look at a lot of risk programs that define things such as, "Hey, at a medium risk, we have to have a certain level of sign-off, right? At a high risk, at a very high risk."

9:59To me, those are very much synonymous with, well, you've actually set risk thresholds. They may be very difficult to manage using a qualitative approach, but they still do exist. And to me, I think risk appetite is something that's very foundational to enable everything else that we want to do in risk management. If I don't have an established risk appetite, if I don't know what my risk capacity is, I'm essentially flying blind, right? And I'll use an example from a prior role where, as an organization out of cybersecurity, we had established that, hey, anything that's more than a potential loss of 500 million dollars, that's a very high risk. That's critical, right? We're going to define that as our

10:54highest bucket. And at the time, when you looked at the corporate earnings, the company was earning a net profit of six billion dollars every quarter, which within that context, 500 million dollars becomes almost pocket change, right? It's not very relevant. It's barely material to the organization as a whole. And so, again, I think truly having that conversation with senior leadership and having them help establish what is our risk appetite, how does it relate to overall capacity, what's our tolerance, and what are some thresholds around that, where we start to trigger some kind of action or escalation, is, to me, very foundational to being able to build a strong risk management program.

11:53Next slide, please, Matthias. All right. I wanted to yeah, just show a couple of examples before we get into some of the details here of risk appetite statements. You know, risk appetite statements can be either quantitative or qualitative in nature. The most common one I see, unfortunately, is that second one, right, where you'll see something like, "The organization has a low tolerance for cybersecurity events."

12:22And that's very difficult to measure, to quantify, right? What does that really mean when something happens? The statement above it tries to quantify that a little bit, right? So for example, we could say, "The organization accepts up to $1 million in total losses from any single cybersecurity event, provided critical systems are recovered within their recovery time objective."

12:50So I try to be fairly specific in this one, but still probably leave some room to be desired, right? What does it mean to have up to $1 million in total losses, right? Does that consider cybersecurity insurance coverage, for example? But probably still a better approach and something that is more useful than simply saying that, "Well, we have a low tolerance," right, without any further definition.

13:16Now, one of the things that I've also seen done in this space is you can use a hybrid approach, right, where, for example, if you don't necessarily want to publicly disclose all the measurements or all the data that feeds into your risk appetite statement, you could say, "Hey, the organization has a low tolerance for cybersecurity events," and tie that to a more quantitative statement underneath it, right? Things that map into it, right?

13:44So part of your program will define that, well, this means that an incident can't exceed X amount of availability loss or financial loss, whatever that may be. So just some things to think about in terms of risk appetite statements. Again, I think they're absolutely foundational. And as Matthias looks at some examples, keep this in mind and maybe think about, okay, how would a solid risk appetite statements have helped in some of the examples that we're about to look at?

14:28Matthias, back to you. Thank you, Markus. So we mentioned risk capacity, and the question is, how should it be defined? So in other words, what is it that takes an organization's future out of its own hands? And as Markus said, I start with two companies as an example that has a pretty similar kind of incident in the same country, the same year.

14:55You probably know the example, Marks & Spencer. It was, I think, Easter 2025, a social engineering attack, well, widely attributed to Scattered Spider. It took down online ordering for about seven weeks. Marks & Spencer, they guided to approximately 300 million pounds profit hit. And, well, what we find out is that they recovered on their own, so they did not lose any control over the company.

15:27And yes, they lost some money, but as a matter of fact, we can see that the impact was relatively moderated. On the other hand, Jaguar Land Rover cyberattack at the start of September 2025 forced a global shutdown of production for five to six weeks, so the window is pretty similar. And what happened is that the UK government needed to step in with a 1.5 billion loan guarantee to keep the supplier base afloat.

16:03So what we see is we have a bigger company that endured approximately the same hit. Jaguar Land Rover, they would not have existed anymore if there wasn't that loan guarantee. And on the other hand, Marks & Spencer, they went away with it without any loss of control. I have two other examples because you might say, "Okay, this is cyber. This is a little bit out of common events." So I'm going to step aside and talk about non-cyber events. My first example is Airbus. January 2020.

16:43You may not know everything about this case, but it's fully public. I'm not going to disclose anything. They settled bribery charges over payments made through third-party intermediaries to win contracts, and they had to pay 3.6 billion euros, that's 5% of their revenue, across France, across the UK, and across the US in a deferred prosecution-style deal. Orpea, on the other hand, they are indeed much smaller, but in January 2022, they had an investigative book, "Les Fossoyeurs," alleged mistreatment of residents and misuse of public funds in the nursing homes. Orpea, they do nursing homes.

17:31So financing dried up, and in 2023, there was a full restructuring led by Caisse des Dépôts. And now Orpea does not exist anymore. It now trades as Emeis. So Airbus, that was the largest anti-corruption settlement of its time, and the impact actually was pretty moderate. 3.6 million, that was- Well, I'm going to say it, close to pocket change, not exactly pocket change, but they have a lot of liquidity, and 3.6 billion in a plane manufacturer is a whole industry. They have a lot of cash because the business model of manufacturing airplanes, it requires a whole lot of cash.

18:16So actually, the impact was pretty moderate. There was no change in strategy or in leadership. On the other hand, Orpea, well, they completely lost control of their destiny. It's my last example, and that's a little bit more in the US, and Markus is going to be able to say a little bit about it as well. Wells Fargo first. In, I think, February 2018, well, beforehand, staff was under sales pressure, and they opened millions of unauthorized customer accounts.

18:58And so in 2018, the Fed capped the bank's balance sheets, and the governance was fixed. This restriction was only lifted in 2025, so that's seven years of balance sheet capped. The penalties was only 195 million dollars, and that was really peanuts, believe me. But the true impact was absolutely not the penalties, of course.

19:27Goldman Sachs, well, bankers helped to raise 6.5 billion in bonds for Malaysia's 1MDB fund, from which billions were embezzled. And so in October 2020, it triggered a 2.9 billion fine in a global resolution, and the Malaysian unit pleaded guilty, and so on and so forth, but there was no business restriction. So actually, the impact, it was just 2.9 billion cash out, and that was not as much as a big deal as what happened to Wells Fargo.

20:08So just to be careful here, the penalty at Wells Fargo didn't cause the cap, right? Both came from the same finding. The Fed concluded that governance had failed. And well, actually, that's one of the kind of things that a single number, an exposure figure, a financial exposure figure, can obviously never show you. And Markus, I'll hand over to you if you want to add anything on Wells Fargo.

20:38Yeah, absolutely. I can add a little bit of detail. It's actually a very interesting case study, right, in terms of how do you run risk scenarios? How do you try to prepare for something like that? How do you model it? Capping the balance sheet, and it wasn't necessarily capped for those seven years. It was capped on the conditions that certain improvements and changes were made within the organization.

21:05But I don't think, I believe that the company did not anticipate the total impact, right? If we look, for example, at asset size of the top four banks in the US at the time the cap was put in place, Wells Fargo was somewhere around 1.8 trillion in overall assets, and they were frozen at just below two trillion, right? They couldn't grow their balance sheet beyond that.

21:32At the time, JPMorgan was at roughly 2.4 trillion dollars in assets, Bank of America at 2.1, Citi roughly even with Wells Fargo at about 1.8. If we fast-forward to the beginning of this year, with Wells Fargo just coming out from under their cap, they were at two trillion dollars in total assets. JPMorgan, in comparison, is at 4.5 trillion dollars, right? And Wells Fargo were very much on track to keep pace with them.

22:01So you're looking at a massive lost opportunity, right? Lost opportunities in terms of unable to take advantage of mergers and acquisition opportunities, unable to take advantage of the COVID stimulus money that helped drive balance sheets, nor the quantitative easing that happened during COVID. So, tremendous downstream business impact that I'm not sure was completely modeled out and thought out prior to the Fed issuing that order.

22:39Thank you, Markus. So, these three examples, we focused on three sectors, three countries, three kinds of trigger of loss events. And, well, in my examples, the company that lost the most kept control, and the one that lost less did not keep control. So as risk quantification analysts or quantitative risk management, we spend our working lives measuring how much a company could lose.

23:17But when we take a look at the reality, these outcomes are not necessarily always explained by how much was lost. So of course, it could have been taken into account in the model. And to be clear about what I did with these three case, they refute the claim, actually, but I do not establish one. I'm not trying to build a causal argument, right?

23:44But keep listening, and I'll state the limits, where the limits are, just at the end. So before we answer this big question, we have to agree on what we are measuring. So where do we have to put the focus? There are a lot of other examples. 3M, Bayer, BP, Volkswagen, Boeing, they all endured major crashes. They are actually still alive. But the thing is, none of them is deciding alone now.

24:23And I think, to me, this is a variable that we do not record enough, because bankruptcy is dated and filed, but the loss of control is absolutely not. And I think that's a part of why this question has not been answered. And there is actually a test of loss of control is, has a third party acquired either a veto or a prescription right over a category of decisions that the bank, or sorry, the company has to make?

24:59And the reason why we needed to code the outcome is that this is a way to go back through the record of past incidents and start counting. What is actually the trigger that pushes a company out of control of its own destiny? What we did is we performed a study on 44 documented cases. The 44 number, that's not a chosen one. 44 is the total number of easy to find and well-documented cases that we got.

25:40The total number could be much higher, but so far that's where we are standing, and we think it is enough to draw conclusions. Because it covers approximately every sectors, every geographies, and we chose to discard sector-wide contraction. Like, if every company of a single sector are, well, in difficulty, then we chose to discard these companies to make sure that we do not draw conclusions on flawed data.

26:17So, we defined simple rules of study that are listed below. We chose to focus mainly on cash out and value destroyed. The foregone revenue has been descoped because, well, that was a little bit difficult to defend. We boxed the analysis window on 12 rolling months, and we only focus on idiosyncratic shocks. And we landed a finding that can be used as a rule of thumb for, well, the max, max, max value that we can choose for to define risk capacity.

27:03Well, our main finding is that beyond a shock costing 7% of revenue in a single year, no company of our corpus managed to retain control of their own destiny without outside intervention. This is the main finding. It means that if you endure a hit bigger than 7% of your revenue, most likely, according to this corpus of analysis, most likely your company is going to lose control, or at least a little bit of control.

27:37Of course, I need to do a little bit of explanation on the wording. When I write costing, as I said, it excludes foregone revenue. When I say in a single year, I mean I have to exclude multi-year shock spreading, because if we include multi-year shock spreading, then we are landing on very big figures, and the company has time to react to the shock.

28:04If the shock is spreading across multi-years, most likely the management is going to react, and this is going to lower the shock figure, and there is going to be a reaction. When I say in this corpus, I mean I bound the claim to our corpus of 44 companies. And control of its destiny, this excludes bankruptcy. My 7% figure is a ceiling of observed survival, to make it clear.

28:42Now, of course, focusing on one single number is dangerous. I am talking to the risk quantification audience, and I know I cannot just stand on one single number. It's going to hide more than it shows. To be true to my job, I have to provide a hint on what the distribution looks like behind it, right? So, this is a little bit of data.

29:12I cut my threshold in three categories, events that cost under 7% of revenue, between 7 and 12% of revenue, and above 12%. I have a very clean middle band. Six cases between 7% and 12%, and absolutely no exception. Out of memory, these six cases include Boeing, 3M, Volkswagen, and well, three others. This is the case where you keep the company, but you do lose power in a category of decisions, at least for some time, because you can recover capacity of decision-making, but for some time, you lose power in some decisions.

30:01As you can see, we have three companies that, well, the company was lost, but the event was below 7%. I think this includes Thomas Cook and probably others, well, two others. All of those, they had a second stressor already in place. COVID, leverage, you name it. But there was another factor that put a flow to the company, and because of this flow, a smaller hit caused the company to be lost.

30:42Just one quick precision. I'm fully aware that the revenue cannot be the only perfect silver bullet proxy. In no worlds actually could one single metric be the only perfect silver bullet proxy. But at some point, right, we have to start somewhere and make some simplification to tackle a complex issue. That's what we do in our day-to-day job, make some simplification to tackle a complex issue, and that's what I did here, too. So, my conclusion so far is the loss exposure does not answer the real question on its own.

31:24So, I'm going to focus on what actually does the job. To any organization, you can define the pillars on which the organization is standing. What I did is try to identify some pillars that are most of the time valid, but of course, as a matter of fact, every organization have its own business model, and this model of pillars has to be adapted to every single business models.

31:58Of course, you cannot build... Well, if this model is going to be approximately true in most cases, of course, you can find cases where this model is not true and you have to adapt it in this case. What we see is that some pillars are sufficient to transfer decision rights on their own. Creditors, the regulator, and shareholders. These are the three main pillars that are sufficient to transfer decision rights.

32:27Wells Fargo, they hit one pillar. They had, well, close to zero direct loss, but they took seven years off balance sheet cap. You have another category of pillars. These are the amplifying pillars, the amplifiers. And by themselves, they transfer nothing. They have little to no impact if it's just one pillar that is hit.

32:53But they do trip the sufficient ones. What I saw is that if you have more than three amplifying pillars, by that I mean if you have hit your customer base and the rating agencies and your suppliers, then it's very likely that you are going to lose control of your company. Three is the minimum required counts of impacted pillars to be in danger to lose your company.

33:21Back to Jaguar Land Rover. The supplier pillar gave way before the financial one, which explains why a company losing proportionally less than Marks & Spencer needed the state to keep up and secure bankruptcy avoidance. Now, I'm fully aware this is a proposed mechanism. It's actually quite consistent, quite, quite consistent with the corpus, but it is not yet a full hands-on demonstration.

33:52And I have to go back to what you attendees actually need from me, which is something that's actionable, because I can present you whatever complex model or method. If you cannot do something with it, then it's probably pretty useless. So what you need is to understand where your edge is. 7%, that's probably not your number.

34:207% is useful to describe a population of companies. But at the scale of just one company, 7% is not going to be the trigger. Your capacity at your own company, this is going to depend on a number of metrics. It's going to depend on your margin, obviously. It's going to depend on your cash cycle, how quickly do you have cash coming in, cash flow as well, your leverage, your capital structure.

35:00Well, just a quick example. At 3% net margin, 7% is two years of profits. At 30% net margin, 7% of revenue is three months. So you see, depending on your business model, a 7% of revenue is absolutely not going to mean the same thing. My 7% number is mainly a vector of communication, but it is not yet a governance instrument. What a company needs, a company needs its own thresholds calibrated on its own anchors.

35:40What we build as ERQI is the risk threshold framework. It is published, actually. You can find the article on the ERQI website. It's been actually in production in a listed European group, and it has... Well, first, it has reached the board of directors, but more than that, it has set new expectations from the board of directors. What this means is it's more than just a communication tool, but risk quantification becomes actually a true governance tool, risk governance, thanks to the thresholds at board level.

36:24First question is to define your own thresholds. Can you quantify what you are willing to tolerate? Actually, from my standpoint, what we need to do to make this actionable is to cut into smaller pieces. Like Markus said, you can define thresholds to understand where you are standing in terms of risk triggers. And to me, there are three main questions, so three different quantities.

36:57I'll start with the first one, which is below, the capacity for loss. Capacity for loss is a financial fact. It's not a choice. It's not a decision. It's a financial fact, the maximum cyber loss the organization can absorb before triggering crisis big enough to lose control of the company. Then you can define risk appetite. Risk appetite, this is a governance decision.

37:23This is the board's willingness to consume the capacity for loss, and it can be defined as a percentage, actually, of capacity for loss. How much are you willing to be in danger in regards to how much you could lose? And this actually must be balanced with the will to invest into business measures. As always, investing in cybersecurity is going to drain the business capacity of investments, obviously.

37:55And actually, this is where risk appetite is useful because it is capping how much you would be willing to lose because of cyber. And when I say lose, I mean lose business investment capabilities. And then below risk appetite, you can define the risk tolerance. This is an operational budget. This is the acceptable loss from any single incident to make sure that in a given year, you remain within your appetite figure.

38:27So, capacity, this is judged on the worst single event. Well, it's useful to compare against the worst single event, so the P90 or P99 loss per event. And appetite is judged on the annual aggregate. These thresholds, they are nested. Capacity bounds appetite, and appetite is used to define tolerance. You could snipe a little difference between how tolerance is defined. Actually, tolerance could exceed appetite, as Markus stated, if the company would be willing to breach appetite in a situation where we reach very serious events.

39:27The thing is, crossing appetite will never threaten survival. It only just threatens the plan, like the business roadmap. So, appetite and capacity for loss, these are pretty different conversations for pretty different rooms. Now, what I'm saying is that you can define in euros those three thresholds. We did this, as I said, for one of the major European groups.

40:03But obviously, these figures, these numbers, they are only as useful as they are defensible to your stakeholders. If your board does not understand where the figures come from, and actually, you have absolutely, definitely, you have to involve your top management and your board in the definition of these numbers. But they have to understand them and to trust them in order to start using them.

40:40So, what we do when we calibrate thresholds, this is, well, actually a very, very simple diagram of how it's done, but actually, it's pretty much just a few arithmetic operations on public metrics. It's actually adapted from major financial regulations like Basel IV, Solvency II, for those who know the European context.

41:14So, what I mean is the methodological basis, I did not invent it. It comes from existing models and frameworks from the regulator. What I did is make it accessible to any company, any sector, any business models, because I think this is really useful. I see this as a cornerstone, but actually a missing cornerstone of quantified risk management.

41:48It can look pretty simple, and actually, I'm pretty convinced that it has to be very simple. Once it's working, then you can add tons of sophistication because, of course, you're going to think, "Okay, this has to be dynamic because if my geopolitical context changes, then my risk capacity and my risk appetite are going to change as well."

42:13That's absolutely true. If my business model changes, I have to update my risk thresholds. Absolutely true as well. And actually, I added a lot of sophistications to our internal models at Rule3. But to be honest, to be fair, it doesn't add much if it's your first steps towards this path. Just like risk quantification, you have to start simple, and once you manage to get the ball rolling, then you can add a lot of sophistication to make things more defensible and more mature.

42:48As always, I'm going to bridge an open door. What matters most is the transparency of the assumptions that you made and the auditability of the results. Just like risk quantification, you have to be able to explain and to make people understand on what this is standing. Now, of course, the binding anchors, cash, operating profit, revenue are going to change over the year, so they have to be recalculated at year-end close.

43:28Also, what I would recommend is to define some triggers for a dynamic recalibration. Because of course, at some time, there can be major events that push you to recalibrate your thresholds. Like, for instance, every single incident that you are going to endure, they are going to cost you some of your cash, for instance.

43:52So, if cash is the binding metric to define your thresholds, what you're going to do when you endure an incident, you're going to make your risk capacity smaller. So, this is going to have an impact as well on your risk appetite and on your risk tolerance. Hence, it's also going to have an impact on what are the risks you have the capacity to accept.

44:19I said a lot of things, but to my point, what actually changes on your next Monday morning? To me, what the thresholds allow to do is that if you express them in euros, they facilitate the discussion between the operations, the general managements, and the boards. And what's even way better is that you can define a pre-calibrated governance process when you can say, for instance, "If a risk is breaching my risk tolerance, then it has to be presented to the board."

45:00What this means is that it's going to trigger a risk acceptance process. Hence, the risk acceptance is going to be formalized on a paper, and the business owner is going to have to sign the treatment plan on the risk acceptance paper. What this does is it puts risk management processes under control using objective and repeatable triggers.

45:28And also, I have to say it, cherry on the cake, it does answer what French and European regulators expect on documented risk acceptance. And when I say the regulations, I mean NIS2 and DORA, obviously. So, what we just said is a pretty good coverage to the big decisions, like the major ones. When you compare a risk to risk tolerance or to risk appetite, obviously, these are the big guns. These are the major risks.

46:08But actually, most decisions aren't big. So, what we did is create a pretty well-working machine for maybe 5% of the decisions we have to make, right? So how do we do? Because we have a risk allocation issue. What we do is we build another layer called risk review thresholds, which is an answer to the budget allocation issue. What you're seeing is that this is a real case, right?

46:46It's a real case. What we do is we have RT. This is the risk tolerance. And as I said, if a risk is estimated above risk tolerance, the risk tolerance trigger, then you have to enter the risk acceptance process. This is a committee decision, and the business owner is going to sign on the paper. But below risk tolerance, we are going to have a lot of projects, a lot of business owners who want to go into production and who want to launch their projects.

47:19And well, cybersecurity, they have to give an answer, yes or no. Yes, you can go into production, or no, you cannot go into production. And I said cybersecurity, but it's also true for any other type of project, right? And what we did is we said, depending on the loss exposure, we have to allocate resources adequate to how much you could lose for the risk about this project.

47:51So in simpler words, if the project weighs less than 50K, then the treatment can be automated. And by the way, the thresholds figures that you see, they have been anonymized. These are not the true threshold figures. So, what we are saying is that we can automate risk assessments if we estimate a loss exposure below 50K euros.

48:18And when I say automate, it's fully automated. No manpower required. What this means is that our manpower, our budgets, we are going to be able to focus it where it truly matters. And where it truly matters is for projects between 50K euros and 50 million euros. So, that's a very, very wide range. So, between 50K and 50 mil, we can also do some resource allocation, saying that for projects with a lower exposure, we can push them to an analyst, and projects with an exposure between 250 and 50 mil, then we have to push them to a senior analyst.

49:03What we are doing here is turning a budget problem, we cannot review anything, into a rule that's anchored on appetite rather than on team capacity. This is very important because what we are saying when we say that is that we are going to focus our resources. When I say resources, of course, it's costly, it's rare, and it's difficult to find qualified manpower on cybersecurity and other aspects of risk.

49:35And what we are saying here is that we are putting our costly senior analysts on the projects that matter the most. And I think this is very important for governance. It's going to save budget, probably, and it's going to make sure that we focus our efforts where it really means something. I just have to add one important note, which is the risk review threshold mechanism, it isn't mine, actually.

50:05The governance idea, it came from a client site practitioner from Richemont Group, where this is actually being operationalized. What I did is built the methodology around it to make sure that everything is consistent with the whole risk threshold framework that is also in production at this company. And I have one final slide.

50:29Good thing that I have a little bit more than five minutes left. As I said, the financial anchors are going to move. Your treasury, your EBIT, and so forth, this is obviously going to move every year. So the thresholds, they have to move with them, obviously. So this is actually a governance cycle. When a financial situation changes, the thresholds have to follow mechanically.

50:58And to me, this is what makes it a governance obligation anchored into the ERM lifecycle, enterprise risk management lifecycle. This is not a one-off exercise. It has to be embedded into enterprise risk management practices. And that's my final slide. So I would be very happy to answer any question that we have. Markus, I'm going to ask you to chime in. Thank you for the wonderful presentation, Matthias.

51:32I want to make a couple of just quick comments, then Markus, I'm going to turn it over to you. One of the things that is very beautiful about the Enterprise Risk Quantification Institute is some of the thought leadership that's occurring. And so, Matthias, thank you for furthering our cause in that category. As we learned in our last session, there is no one right way to answer the overall question about what is the nature of risk for your organization. But what I love about Matthias' presentation is this notion of losing control, just to reemphasize that, right?

52:04Looking at risk in terms of could you lose control of your company? Will you survive, right? These questions are the things that we need to continue to drive and focus on asking and understanding these questions, and which ones are most significant, right, to the key stakeholders. So having said that, Markus, what do you got, my friend? You got some insight. I know you do. Don't hide it.

52:24Yeah. Hopefully something intelligent and intelligible, right? No, what I want to close with is, number one, I think, I hope folks see the fact that it is so crucial for every organization to really understand its capacity for risk, right? At what point do we start to lose control? And that's not always a purely financial question, right? Especially when you're operating in a regulated environment.

52:59Sometimes you just get on the bad side of the regulators, right? And that has to be accounted for as well, and it's a little bit more difficult than just financial thresholds. One of the things that I really, really like about what Matthias closed with is the idea of, hey, this is a cycle, right? It's a very ISO-ish, if I can say that, approach, right?

53:22It's continual improvement. It's continual monitoring. I think so many companies, they'll put a risk appetite statement out there, for example. They'll establish their threshold. But the business moves, right? I mean, realistically, the moment that you publish a risk appetite statement, right, the next day, it may no longer apply, right? So the idea of a continuous self-evaluation, whether that's quarterly or annual, I think that is so key to making sure that the scope of your enterprise risk program stays correct, right? Keeps up with the company, whether you need to scale up, scale down, redefine appetites and whatnot, reset thresholds.

54:02I think that is one of the real keys to making sure that your enterprise risk management program survives the test of time. The tests of time. I love that quote. As I mentioned earlier in my opening remarks, time is one of those variables, right, that is significant in this world of risk management, risk analysis, and risk quantification in a number of ways.

54:27And so, being able to do things on a continuous manner, being able to ensure that they are long-lasting, right? All elements of time that are critical for us to be thinking about as we try to really try to wrap our minds around what is a very complex risk system, right? So, Matthias, any final thoughts before we wrap up?

54:54Not much. I think I said a lot. You didn't say a lot. I agree. I mean, great stuff, though, just to be clear, right? So... Thanks a lot. No, what I was indeed going to say is that I know this is not yet used a lot, but I think it's just like the first steps of risk quantification. We did not have a lot of practitioners, right? But it does not mean that it does not have to get bigger. And to be fair, now that I started this journey, I cannot imagine how I could do without it, right?

0:06Hi, Caroline. How are you? I'm great. How are you today? Excellent. Well, listen, we have our panelists from the next panel arriving. Hi, Rock Lambros. How are you? So, Markus and Matthias, if you want to stay around and go off video and audio and answer any questions as you so desire, please do. One housekeeping note for those, and this we should have stated this up front, and I know not everybody on this particular summit is going to agree with this, but we are people who are putting in their note-takers and not attending physically, right? We are removing you from the summit, right? If you want information from us or the speakers, I can tell you that there is not a speaker or

0:55presenter that is on this summit who would not be thrilled to share more or further information about what they've said to you. So, that's one of the reasons we're giving you their LinkedIn information. So, feel free to reach out to them. If you have any issues with that, you may reach out to me, and I'd be happy to discuss it with you further. Having said that, David White is somewhere. There he is. There's my friend. Hi, Cody.

1:20Okay, I'm getting out of the way. Bye. Hey. Thank you, Andrew. Hello, Cody, Rock, and Caroline Thank you for joining. We're actually running two minutes ahead of schedule. Do you want a two-minute breather, or should we jump right in? Let's go. Let's go. All right. Okay. I think we might need the two minutes. - I think we might. So, this is a panel discussion.

1:54I'm going to kick it off here. So, Rock wrote this summer that a score which cannot tell the agent did not misbehave from we could not see it misbehave gives comfort, not assurance, and that you should ask how the number was made before you bet the enterprise on it. That's what this hour is about, not what AI can do and not how frightened we should be, what we can actually measure about these systems, what the numbers in circulation are really counting, and which ones are worth anything.

2:30I have three people who have spent this year arriving at that question from different directions. Caroline Wong is chief strategy officer at Axari and the author of "The AI Cybersecurity Handbook," published by Wiley this March. I'll put a link to that in the meeting chat in just a moment. She also wrote "Security Metrics: A Beginner's Guide," which is in the Cybersecurity Canon Hall of Fame, and she has been publishing all summer on how to govern AI agents. Caroline, welcome. Thank you. I'm thrilled to be here. - Rock Lambros is director of AI standards and governance at Zenity and the founder of RockCyber. He co-leads the OWASP Top 10 for LLM applications,

3:22which means he is one of the authors of the finding we are going to spend the middle of this hour on, so stay tuned for that. He is also a distinguished fellow at ERQI, and he writes weekly AI Security Roundup that I read. You can follow him on LinkedIn. I'll put a link to each of the panelists in the meeting chat momentarily. Cody Scott is GRC industry principal at Workiva, where he's helping build a GRC product.

3:53Before that, he spent years as an analyst at Forrester covering cyber risk quantification and enterprise risk. And before that, he was the first cybersecurity risk officer at NASA. How about that? That's so cool. That's actually where I first met Cody. He is a co-founder at ERQI, and he spoke three times at a conference last week in Las Vegas, so he arrives kind of warmed up already and probably a little bit travel-weary.

4:23Let's get into it. So, first segment here, let's talk about where we are behind. And to anchor this, let's do a rapid fire response to a question. Everyone watching has an AI governance program on paper. Name the thing that program believes about its AI risk that the evidence does not support. Caroline? I think that people believe that the risk tolerance for their organizations has been determined and is well understood across the board.

5:03I think that is false. Rock. I believe that our risk rankings come from evidence, and I think for most of you out there, it's a vote on what scares you the most or what scares the team most, dropped into some sort of heat map, and then nobody ever went and checked against what actually is happening. Cody. Yeah, and I would say, you know, it's interesting, I saw a study that said 74% of organizations believe they can pass an AI compliance audit. And I would like to know what exactly they think they are complying with, because that is a wild statistic to me, especially when we see that a lot of organizations say that their overall maturity around AI governance tends to be low.

5:52So, that's kind of an interesting tell on ourselves as practitioners, but also, I think, to Caroline's point about the assumptions that we make within our own enterprise. - Rock, I'm going to turn to you again. Where did you go? Did we lose... We lost Rock. I think we lost Rock. He might be having- We lost Rock ... internet issues. Okay. Let me just...

6:20He's back in the attendee. I don't know what happened. That was weird. I somehow got demoted to- Rock ... participant. Welcome back. Right? You disappeared right when I was going to ask you a question. It somehow demoted me to participant. I saw you guys. I just couldn't say anything. That's very strange. Apologies. I promise that if anybody else disappears, I will search for you as well.

6:52So, Rock, you co-lead the OWASP Top 10 for LLM, and this year the project stopped asking only what practitioners fear and checks that against the incident record. About 8,000 pulled, almost 8,000 pulled, almost 7,000 classified. Prompt injection came first on the vote, but around 12th on the record. Set that headline aside, what else moved and what does that disagreement tell us about how this industry ranks risk? Yeah. So, I'll get into it from a couple perspectives. So first of all, like, what else moved, right? Excessive agency was one of the ones that really stood out to me because it climbed from sixth to third. And for me, that move matters probably the most because this is where you start to see the

7:45agentic influence start to- Mm-hmm ... seep into the list here, right? And I think you're going to start to see the top 10 for LLM applications and the top 10 for agentic applications. That Venn diagram is getting, that middle section is getting bigger and bigger. Unbound and consumption is really interesting because that rose four places just on the vote alone, on the human vote alone, because the incident data can't really estimate how many of those attacks it misses, right? And then improper output handling fell the furthest from fifth to 10th, ironically, right? And for me, I think the widest flight in the data was misinformation. The incident record had it

8:30ranked second, and the experts, the vote, ranked it 13th, right, completely out of the top 10. And when we opened up these incidents, a big share of it came from the AIAAIC Harms database. So, like, it was heavily loaded with deepfakes and disinformation made with AI. So part of that was the way the data sources were skewed.

8:59But when we actually did the measurement against the data versus what the experts agreed on, it barely agreed, right? So there's a measurement called Cohen's kappa, which measures the agreement between two measurements, right? And that came out, I'm going to get a little nerdy, but it came out to a 0.2 with a 90% interval that ran across to zero. What does that mean?

9:26It means that we really can't rule out that what the practitioners feel and fear and what might actually happen in the data, we can't rule out that it's just by chance, right? So, what that tells me is that... I think there's a few things, right? I think there's, we use the word vulnerability in the document, top 10 LLM vulnerabilities, but the incidents are reported not based on the vulnerability, but based on the business impact, right? So there's a taxonomy kind of mismatch.

10:07And it also tells me, based on the movement that you see in a lot of that data, that what people fear doesn't necessarily match what's actually going on in the industry. Interesting. I'm going to shift to Caroline now. Caroline, your argument sits one level below Rock's. It's that not only the ranking is wrong, it's that we're scoring the wrong variable.

10:41Walk us through that with two agents, the one that runs every morning and the one that can move money, and tell us what a single agentic risk rating misses. Yeah, so I've been spending a lot of time thinking about these two terms, which are autonomy and authority. I think that when we're talking about agents, we talk a lot about autonomy, and I think there's a too simple model that says more autonomy is higher risk.

11:11David, you mentioned two examples. So one of them is, let's take an example of every morning I have an agent that runs, it looks at a bunch of public sources, and it provides me with a briefing. That agent is entirely autonomous, and I don't consider it to be very dangerous or very risky. Now let's switch to the dimension of authority.

11:38Imagine, I don't actually have an agent that does this, but imagine I have an agent that when I tell it to do so, it executes a 5 million dollar transaction. That agent is actually not autonomous. It's not doing anything until I tell it to. But when I tell it to do something, it has an enormous amount of authority. And so I think that these two different dimensions are really important. And I think that sometimes we oversimplify by only thinking about autonomy without thinking about authority.

12:17That was very clearly stated. Thank you so much for that. Cody, I'm going to shift to you now. You've written that most AI governance is detached from operational reality, and that GRC for AI is deeper and more technical than people assume. Be specific. Where does that detachment show up, and why has the GRC function been slow to claim a problem that is squarely theirs?

12:52Oh, I love this topic so much. So, a part of this thing, so one of the things I talk about is that AI governance is inherently a technical discipline, and that is at odds with the way that we have traditionally viewed governance in GRC programs, in risk programs, especially as you go up into kind of like the enterprise level of how people govern and assess risk.

13:16So, the interesting thing here too is like my organization, we just did this benchmark study where we found that over 84% of senior executives are confident in the accuracy of AI outputs and external content that they report. But at the same time, those same leaders, 26% of those same leaders are saying that their internal audit function is catching more and more issues that lead to public embarrassment. So, what I think is interesting here is that there's a real disconnect between how people are using AI and what they think they have done in the name of, quote-unquote, "governance," versus what we're actually finding on the technical side, the issues that we're finding that we're running into.

13:58We say this in security all the time, a system can be fully compliant but not secure. Compliance doesn't necessarily equal security. It's the same thing with AI and AI systems. We can have a, quote-unquote, "fully compliant AI system," whatever that means, but it can still have different failure modes that were not accounted for that still manifest because we haven't done that due diligence necessarily to plan it out. We've got a lot of folks who are looking at things like model security and model risk. We've got folks like in the data security realm who are looking at data security and application security, that are focusing on the inputs and outputs of these tools. But AI systems are

14:38inherently probabilistic, and they're going to take the path of least resistance to complete a task. So, we have to get used to this idea of securing intent, which is really hard to do practically. Now, from the AI governance perspective on a technical side, what does that detachment really look like to your question? These are things like, okay, well, we documented a policy. That's governance, right? Well, the problem is we don't have any way of enforcing those mechanisms, technically speaking. The other side of this is, great, okay, maybe we're logging data.

15:09We're logging what the AI did. But maybe to actually know how it reasons something, we have to go talk to the expert. That's still a manual process. That's not good technical governance. And then the last thing here is just what people do day-to-day for, quote-unquote, "governance." That can be everything from, "We stood up a committee." Great. Does that committee know what they need to actually do? Maybe not.

15:31We bought a tool or maybe we implemented a standard. Great. Good accomplishments, good things to do. But again, it goes back to the idea of how are we actually putting guardrails in at the data layer for what the AI is touching, how it has access to things, and that's where the detachment really shows up. The last part here with GRC claiming ownership, why are they slow to do this?

15:53I don't want to go too esoteric with this, but I love this topic because I've been in GRC for so long now, and GRC systems are inherently built around human actors. It's a human who interacts with a system to make system X do A, B, and C outputs. We use it for these functions. That's really easy to validate, relatively speaking. I can audit that, I can test it, I can make sure it's doing what it needs to do. But if I go back to that idea that I said of AI is inherently probabilistic and we're focusing on the idea of intent, that is so hard to do because now it's an agent that is operating and it has its own way of arriving at that path. So now it's an

16:34extra layer of complexity that GRC teams frankly are just not equipped to handle today unless we start to expand the horizon of what governance means and what those GRC teams should actually do and who they should work with. I'm getting a sense that a GRC team of humans might never be able to keep up with the risk from AI, but that's- There is an interesting topic about having an executive agent that oversees the orchestration of other agents from a GRC perspective, and I love that idea. And if anyone else is working on that, please talk to me because I would love to talk about that from a governance perspective. Cody, talk to us. Cody Rock.

17:25He's in Hollywood Squares on my screen. He's right under you. So let's talk about what good looks like. If... Let's do another rapid fire. If I walked into an organization that has this right, what would I see? Caroline, let's start with you again. I think you'd see an inventory that is accurate as far as the executive stakeholders know. Okay. Rock?

18:02Yeah, I think if you ask anybody out there how their agent risk number was made, their risk score was made, and then ask them to walk you through it, all the way through, let's say, an egress test that they ran, a la, I'm just going to pick on them, OpenAI. I think you would find that that approval logic runs somewhere where the agent won't be able to touch, and then nobody approves agent actions one at a time. Because people who try that end up clicking always allow, right? The rubber stamp. Yes.

18:36So, how do you start to govern that at scale? And I agree with all of that. And I think, too, what would be even more telling to me is if I actually look at a risk register and I see not just AI risk on the risk register, but I actually see different failure modes that are attributed to critical business processes. And then also an understanding of controls and compensating controls that have been documented, how we collect that evidence, and whether or not there's a risk acceptance in place for that, or if that warrants further remediation action. I just do not know of organizations who are at that sort of moment in their, I guess, AI fitness journey where they are actually doing that

19:24kind of thing on a day-to-day basis. And frankly, it's hard. I'm not going to sit there and say it's easy to do either, but a little bit more intentionality around understanding failure modes of AI agents. Just, yeah. Sorry. That failure mode set my mind... I'm going to stay on script, though. I'm not going to go off script, don't worry.

19:52Caroline, not that this is scripted, folks, but there is a set of questions that we talked about. You've said that you don't trust an agent into safety, you engineer confidence into it, and that confidence is something you can earn and something you can measure. You also wrote the book on security metrics. Make it concrete. Measure how, in what units, against what baseline. Walk us through that.

20:25Yeah, so I have been kind of contemplating these two words, trust and confidence. I think that trust is something that I do with a human. I trust Rock Lambros. I've known him for more than 15 years. I've seen him in real life hundreds of times. I text message him on the regular. I trust Rock. I trust Rock's ability to reason. I trust his intent, and I would hold Rock accountable.

20:58Now, when we're talking about agents and different tasks that agents can do, I actually want to put out this idea that I don't know that I can trust an agent. There's just so many... Maybe not at this point in time, right? Give me 18 months and maybe I'll be in a position where I feel like I can trust an agent. Today, in September 2026, I cannot trust an agent. I can examine the tasks that each of these agents does, and I can perform an analysis to tell me if I think that the task will be accomplished to my expectation satisfactorily. And I call that confidence.

21:40I actually think that we can think of building confidence in the tasks that agents perform, kind of like when we're onboarding a new human employee. On the very first day that I have an entry-level security person start at my organization, I'm not giving them admin access to absolutely everything. That's just not how it works. I'm going to start out by giving that person kind of smaller, lower-risk tasks, and when they've demonstrated to me that I can have high confidence in those performing tasks, then I'll give them more.

22:25And so, I really kind of want to put out there, because trust to me is a little bit touchy-feely. Trust to me is a little bit human to human. Confidence, I think, is something that we can actually think about, how do we measure that, and how do we measure that over time? And I think we've got to break it into these modular components.

22:47I don't think I can trust an agent. I don't even know if I can have confidence in an agent. But if you tell me what are the tasks that an agent can perform, then I can assign a confidence level to each of those tasks. I love these sharp distinctions that you're making, Caroline. Rock, you've written that inbound containment gets designed, built, and validated while outbound authority gets assumed.

23:18What does a real egress test look like on Monday morning, and after the two Codex sandbox escapes published last week, what's the right question to ask about the harness rather than the model? Where in your harness can you monitor egress, right? And at what points? And the challenge we have here, honestly, is that- Your different harness, whether it's...

23:47Hell, even within the Claude ecosystem, Claude Desktop, Claude CoWork, and Claude CoWork expose their hooks and what you can see do you control differently, right? So you're writing different sets of controls for each one of your harnesses. Go to Microsoft Copilot, another set of harnesses. Go to Amazon Bedrock, another set of harnesses. And kind of to Cody's point earlier around having a governing agent, this is all things that we're trying to address on the OWASP side under the agent control standard in trying to create almost this middleware layer, if you will, to harmonize your security controls so that way your harness is independent, right? Or your

24:34security controls are independent of the harness. Got it. Cody, you work at the program level, and your session last week, one of your sessions last week, I know you spoke three times at the conference, one of your sessions was called "Beyond Green Dashboards." Rock says a score that cannot separate the agent did not misbehave from we could not see it misbehave gives comfort rather than assurance. So what is the evidence chain that turns comfort into assurance at the program level?

25:21Oh, hold on. Sorry, my computer just froze right when you asked that. Oh, there we go. Okay. I am back up. Yeah, so at the program level, like thinking through this, the evidence, this is something where, like at my company, for example, we talk about the value of a connected data platform, and this is because we need to understand the practical dimensions of assurance. What is a committee going to actually care about? How do we know we've demonstrated due diligence?

25:51When I think about... I really think about kind of like the GRC engineering movement here in terms of how we get to actual evidence that is hardcoded into the way that we review how compliance is done. And that chain, to me, looks something like the agent has its own identity so that we can attribute actions to it, kind of to Caroline's point before.

26:13That action then passes through an enforcement mechanism that is outside the agent, kind of to what Rock was just saying as well. But then this is the hard part, because we have to be able to record the decision itself, not just the output of the agent. This is where a lot of organizations are really wrestling with this topic and figuring out how to do it. I mean, this is why we have AI governance software standing up at this very moment, and kind of that whole market coming about is to try and help solve this. But this is about being able to capture the why of the agent, so looking at things like the reasoning itself, any tool calls that it was doing, the context.

26:53What a lot of organizations are doing is that they'll try and log, so we'll log what the agent output is, as I've said before, but that doesn't tell us whether or not the thing it did was actually acceptable. Was it even supposed to be able to do that? And that's the context that we're missing that is really important for that assurance conversation.

27:13The last component of this is then being able to map that record that we create to an actual control, and then we have to tie that control to an obligation. So that's how we move this concept of AI risk management and assurance around AI back into the broader enterprise risk management conversation, when we can map the system, the data back to controls that are protecting the system and the agent and the data itself, back to the obligations and requirements, policies, whatever they are, that our organization has that ultimately we are responsible or accountable for. So it's about establishing sort of that chain of command all the way back up to the rest of things to help normalize the

27:53way we do risk and compliance. That's how we build assurance. But that hardest part comes in with the technology component of the fact that AI makes its own decisions, and the guardrails need to be around how it reasons, and we need to capture that context to be able to know if it's doing the right thing that it should. To make sure that that number is worth betting on, when we start to talk about what is presented at the assurance layer, this goes back to risk quantification 101. This is fundamentals. How do we know that that is a good measurement of assurance? Well, what was the loss event, or what was the scenario that we anticipated to see? Not just AI risk, as I've said before, but something like

28:34customer PII is exfiltrated via over-permissioned agents in the next year. That's something I can actually measure. I then also get a scoped asset that can be affected, and then around that, I can start to model frequency, and I can model magnitude of loss as a distribution. That's going to demonstrate way more assurance in how the agent behaves and what we can realistically expect from it than any single score would give us.

29:01Thank you, Cody. That makes sense to me, and I get the picture of the technology that's going to be necessary to put all of that together. I want to turn for a second to one of the questions from the audience. Parker Hannifin asks, "In terms of AI frameworks, are there any that y'all see as leading the way or emerging as the flagship framework to rely on for governance here?"

29:34Anybody want to take that, or- So governance- ... we can do another rapid fire. I mean, governance is such a broad word, right? So when you mean a framework for AI governance, like we've got many frameworks out there from both the OWASP Top 10s to- SANS just released an AI maturity model to things coming out of, what is it?

30:02UNESCO and ENISA, right? So, there's plenty out there, and I would say to ISO 42001, right? So I would say, quit doing analysis by paralysis, just as we've done on the traditional cybersecurity side for years. Like, which framework do I align with? Pick one that works for your organization and go. Yeah. It's a common question. A common answer I give is the right one for you is the one that you will use. That's said another way.

30:39Let's talk about what we should fix first in this journey toward AI governance nirvana. Budget and attention are always finite, and most people are already, most organizations are already behind. Over the next two quarters, what would you advocate we fix, in what order, and how do we, like, what do we stop doing to pay for that?

31:13Another rapid round. Rock, let's start with you this time. Sure. This shouldn't come as a shock to anybody. Inventory your agents, what they have, right, and then what they can do. Not what you think they can do, but what they can actually do. So after the inventory, credentials have to come first, right? So you have to inventory every agent's key, the authority granted to it, and swap it for a token that expires in minutes, if not seconds, right? And only works in one place at one time, right? Then that egress comes, right, where you lock down anywhere an agent reads content that you didn't write.

31:56I've seen budgets for that come out of the detection budgets, the SOC budgets, right? Those types of budgets. But it is right now still a lot of robbing from Peter to pay for Paul. And it's when you look at, there are over a hundred agentic identity drafts in IETF right now. And IETF is the body that puts out RFCs, and many of them are written by the creators of OAuth.

32:29That signals to me that even the creators of OAuth are telling you that OAuth isn't the answer. Mm-hmm. So, but it's what we have now. But it's really keeping the agency. Can the agent, should the agent be taking the action that it's taking right now and under this context? Keeping that as minimum as possible, and that goes to dialing that authority and autonomy dials, I see them as two different dials, accordingly.

33:02Back to autonomy and authority, where Caroline started. Caroline, what's your answer to that question? What do we fix over the next two quarters? So my best answer is what Rock said. Okay. And in order to kind of keep the conversation moving and keep things interesting, I'm going to say, let's take a look at the cost. How much is this all costing us? Let's take a look at the historical cost for the last 12 months. Let's see if it's possible for us to project the predicted cost over the next 12 months. I think that meeting business objectives does come before governance, and it comes before even cybersecurity.

33:47And so I think we just got to look at, like, what is this actually costing us? Yeah. I was wondering that myself when Rock was giving his excellent answer. Cody, what would you advocate? Yeah, I think we're all in violent agreement on this. I would have to double down. It's not the sexy answer, but the inventory really matters. And this is a problem that has been going on in IT and OT for so long already, but we really have to start there. But I'm going to step back two and even say, I was talking to a CIO back in my previous role a couple of months ago, and they were talking about this topic of AI governance. "Where do I get started with applying controls? How do

34:29I actually do this from a good top-down approach?" And I said, "Okay, well, tell me what your highest risk use case is." And the CIO said, "I don't know that." And I said, "Okay, that's not a problem. A lot of organizations don't know that. How would you go find that out?" And then the answer was, "I don't know. We just stood up an AI governance committee. Maybe I can take that question to the committee." Ding, ding, ding. That is a great way to start. Go and start there. Because even if you don't have a complete inventory, again, don't let perfect be the enemy of good here. Start somewhere so you're starting to do this. But even if you don't know where to start, if you've got a list

35:03of use cases, start with what you think the highest risk use case is, validate that with other stakeholders, because you alone should not be making that decision. And then from there, start to think about what a critical control might be that you need to apply universally across that use case. Break down the problem into bite-sized pieces that you can actually tackle, and don't be afraid to leverage stakeholders to help you make those decisions, because AI agents are an all-of-business strategy.

35:32So, Cody, I'm going to stick with you for a second. You spent last week asking rooms to assess their own GRC AI maturity. What does the bottom rung of that maturity look like? And then what's next from once you climb up off onto the curb? Yeah. What I loved about that session that I did, this was at Workiva's Amplify event, we did a session on assessing your GRC AI maturity. So again, AI is specifically within the context of how you're using it for GRC use cases. But I think this was indicative of where a lot of organizations are. So at the low, if you can imagine kind of a simple, you know, five-step maturity model, the lowest end of maturity

36:15is not that you're not using AI, right? And I don't think the answer to be more mature is start using AI in some capacity. That's not what we're talking about. What we're really talking about with kind of the lower end here is organizations who are using AI, but do not have significant visibility into the capability of what that AI is providing them. They don't know how the AI is being used, and by extension, they have no idea if any guardrails exist or whether existing guardrails that are in place are sufficient in any possible way for that use. This is especially important when we think about like data integrity, data confidentiality, and we look at those dimensions. But what I also say too, and

36:57this is kind of back to my point about governance being a technical domain, it is top-down and bottom-up. So yes, you need the policy. Yes, you need the committee. Yes, you need escalation paths and approvals and all of that, but you also need to double down on the fundamentals for data and system security and privacy that go into place for those inputs and outputs of the system itself and how that model behaves or how that agent behaves.

37:24At the top layer, you have to have that inventory, right? So that goes back to kind of that point too, not just the committee itself. And then from the bottom-up perspective, you've got to start thinking about how controls are applied as a class across agents based on the way agents interact with data and how they're expected to generate those outputs.

37:44It is not an easy task by any means. And the thing with AI maturity, again, we're not talking about more sophisticated use of AI in the environment. We're talking about the visibility that you have into the AI. So your maturity correlates with that visibility, which allows and unlocks you to do more from a security perspective, from a monitoring perspective, which then goes back to that ethereal thing of trust and actually builds trust. It builds your street cred that leadership knows that you know what you're talking about when you say that that AI is actually compliant or secure or whatever the case may be.

38:21So governance comes first in that situation because frankly, it's just the cheapest thing for us to do. It requires very little in terms of new tooling or technology, but it does require a deep understanding of how systems work. It requires a deep commitment from your leadership to actually pay attention to these things. And the human element of all of this, frustratingly, can be the highest friction point that we work with, not the actual agent itself. So that's always something to contend with. But that was also something that came out in the room when we did that assessment, and I found that to be super interesting.

38:58You heard it here, folks. Cody says humans are still a problem. Thank you. Rock, what's your answer for what's the cheapest thing with the highest yield that we can focus on? I mean, humans are still a problem for now, right? Until AI kills us all, including some of the doomers. But anyway , you know, I mean, honestly, like I think we already mentioned it, right? Like inventory.

39:28Inventory your damn agents. And then pull their static keys out for ephemeral tokens, right? That is probably the biggest bang for your buck. And then also, aside from the other things I mentioned earlier, test the kill switch. You say you have a kill switch, test the kill switch. Because remember, agents may call sub-agents that may spawn other agents that may go spawn other sub-agents, right? So if you hit the kill switch on one, does it cascade, right? Does it actually do what you're intending it to do?

40:07It's amazing to me how many people I ask and they're like, "Well, I mean, the button says the process stopped." Great. What about all the subprocesses it spawned? Or subprocesses are a little easier, but those subprocesses may have spun up other processes outside of its shell, separate agents altogether, right, that where any cascading effect wouldn't touch. So, right, those are the things to consider.

40:33Agents all the way down. Caroline, if a team can only instrument one thing about their agents this quarter, what should that be? Logging. Logging. Okay. All right. You know, it really does, like this conversation reminds me of like where we were with cybersecurity like 15 years ago. Inventory, logging , yeah. Access controls to get back to that, you know, ephemeral tokens.

41:13As we look forward 12 to 24 months out, what changes in the threat, in the rules, and in the job? I'm not asking you to paint an entire landscape. Tell me one concrete change each as we do a rapid round. Let's do Rock, Cody, Caroline, rapid round. Yeah, we've already started to see the hints of this, but I think now attackers are going to hand the entire intrusion to agents. So Unit 42, you know, Palo Alto's Unit 42 published one this month, right, that took under 10 hours.

41:56I think auditors are going to start grading you against- What you published. So every AI policy you can't evidence, going back to kind of Cody's original point, that turns into a liability. So the job shrinks to really the one part that a machine can't do, which is signing your name to the risk, right? Which is which human is accountable for the agent actions. And I wrote about this, I think last week, is like, it's amazing when you sit in a room and ask that, you learn what Simon and Garfunkel really meant about the sound of silence, because nobody wants to raise their hand.

42:40I love that. I love that reference, Cody. That was a good one. I think for me, I'm really interested in the job dynamic here, because I... And this is where I really lean into and really encourage folks to look at the GRC engineering movement if you're not following it. The role of the GRC analyst who is responsible for helping to secure and protect these agents and AI systems, this is especially important. We're talking about, we're dealing with the challenge that GRC people conventionally, and I'm painting a broad brush here, so hopefully I'm not offending anyone, but GRC analysts traditionally are not super technical. They are not comfortable talking to

43:22engineers or developers about how those systems that they use actually work to be able to communicate back and say, "Hey, this is exactly the kind of code output that I need to see. This is the exact kind of file I need to see when you generate this artifact that would satisfy this control." All they do is they go in and they regurgitate whatever the NIST control says. And don't get me wrong, I'm one of the biggest NIST fanboys on this planet, but I cannot go take a NIST control, say AC2 enhancement, whatever, and give that to some engineer and expect them to understand what to do. When, for example, when I was at NASA, we were working on trying to do exactly that. We were working with teams who were

44:04running a lot of space systems, and I showed up with my checklist of controls and started to talk to them, and I almost got laughed out of the room because nobody knew what the hell I was talking about. What did I do in that situation? I said, "Well, Cody, I got to level up and get better at what I'm doing." And I went and I actually pulled up the NASA Systems Engineering Handbook, and I went and looked at and did a lot, multiple years of research into how aerospace systems are engineered for different kinds of satellites, things like that, so that when I went back to those teams, I could be much more confident in what I was talking about, where the controls need to be applied, et cetera.

44:39We're in the same situation now with AI. We need GRC analysts to understand AI systems a little bit more, not be afraid of the technical jargon, to lean in and understand how these systems reason, what probabilistic versus deterministic actually means, and then the context in which those agents are actually deployed for different business processes. Unfortunately, this does mean we have to talk to more people. And as I said before, that can be a point of friction, but don't be afraid of the friction because it will make the profession better. It makes us better in the work that we do.

45:14Caroline, 12 to 24 months out, what changes? We're going to find out which tasks are actually cheaper to do with humans and what's cheaper to do with AI. Back to the money. I love it. I love it. It's all about the money. It's always about the money. Yeah, it is. And I love that you're pulling on that thread. And, oh, and Cody, I was shuffling through papers here because I was trying to find...

45:39I knew we have a GRC engineering session coming up. It's next, folks. So if Cody has gotten you interested in GRC engineering, the very next session is Ayoub Fandi, the author of the "GRC Engineering Manifesto." So stay tuned. Stick around and stay tuned. Back to this session, though. Rock, you track this weekly. I recommend everybody follow Rock, subscribe to his newsletter. Also, please note that Caroline dropped a link to her book and her blog in the chat, so please check those out.

46:23In the last three weeks, OWASP shipped an agent control standard, California enacted an AI auditor framework, NIST named AI agents in final token guidance, and OpenAI endorsed third-party assessment in the Frontier Act. Which of those becomes a contract clause, a log source, or a deployment gate for people watching, and which one is just wallpaper?

46:47Yeah, let me sort through all four. So, NIST IR 8587, right? That is essentially built out agent guidance regarding tokens, right? So I think that becomes a deployment gate. I don't think an agent ships with a credential that lives for days and works everywhere anymore. And your customers are going to start writing that into procurement before your engineers can even figure out what the IR means, right, and how to implement it.

47:20California's auditor laws, they're going to become a contractual clause because that's an actual law, right? So what is it? SB 813 and AB 1405 register the auditors and set their standards, and they don't force a single audit on their own. But the clause is effectively three questions for every model vendor, right? Who assessed it? Are they independent? And can they see it?

47:45OpenAI's endorsement, wallpaper, right? And it leads me to read it as PR, frankly. They back the assessment provision, which is the cheap part, but they skip the reporting duties, of course, right? Which is the expensive part. It goes back to the money. But what it does tell you is that the labs are grading themselves- They stop being credible, right? Anytime you grade yourself, right, you have to kind of look at it sideways, look at that statistic sideways.

48:17So, you should write that into your contracts, right? And then finally, the agent control standard. I would love to see it eventually become a contractual clause at some point, right? But we're kind of in public preview right now. The implementation samples haven't shipped. We do have a reference implementation now against the Microsoft Agentic Governance Toolkit.

48:46But we're a month into OWASP, probably about six months old in its latest iteration, if you will. If a vendor is coming out and telling you that they support it right now, and I'll be frank and open, if the vendor comes out and tells you they're supporting it right now because it's got the OWASP name on it, it's not ready, right? So, just look at it sideways.

49:18And this session is definitely leaving me with the impression that there's an awful lot to keep track of. So, please do follow the panelists on LinkedIn. And I was mistaken. Caroline did not post, but I now have posted a link to her book and blog in the chat, so check it out there. Cody, I'm going to shorten this next question to, what does the GRC analyst do in 2028? Looking forward two years hence, what does a day in the life of the GRC analyst look like? What are they doing?

50:17Well, one thing I want to call out specifically before I talk about this, just on the subject of cost that I think is really important here. I think as far back as I remember, even when I was a practitioner, one of the things that we talked about a lot in security was how over 60% of the budget goes to compliance, not actual security work. And I talk to CISOs all the time who still feel that. It might not inherently be true, but it's something that we still feel. We spend a lot of this work on compliance and making systems compliant, not necessarily on the security work that is the most strategic.

50:55If you are feeling any of that burn related to AI, I assure you, you're not the only one. But I would also say this is something that we need to especially pay attention to as we go forward in thinking about assurance, because the cost here that's actually going to be difficult for programs to maintain and to think about is the actual cost of assurance itself when it comes to AI.

51:20I've written about this when I was at Forrester previously, but a lot of the work that people put in, there's a high cost and a high amount of effort that organizations put into deploying and maintaining compliance systems. And agents are only going to multiply that and make that a sort of, from a change management perspective, a harder thing to reconcile.

51:42What I would say about that, and this is where the GRC analyst comes in, is that we need better prioritization. We need to think back from a business perspective and start to think in a little bit more of a macro way around what, quote-unquote, "high-risk use cases" actually are. Because if we're trying to approach every single AI system or deployment of AI or every single agent, God forbid, if we try and treat every one as its own instance that needs to have the same level of compliance, the same level of assurance every single time, we are going to just be repeating and perpetuating the bad practices in GRC that got us to the point today where a lot of people feel like they're just chasing

52:25paper, chasing emails, chasing evidence, and we can't be in that game. We really need to think about the optimization play on how we better prioritize what assurance looks like, because that cost is going to balloon. Now, from the GRC analyst, what does that job actually look like? Well, that gets into helping to drive strategy, believe it or not. That's also not something, maybe this is controversial, but that's not something that is comfortable for a lot of GRC leaders, because a second-line person, for example, usually sees themselves as the recipient of what leadership is telling them to do, not necessarily a partner on business strategy. How do we accomplish goals A, B,

53:02and C in a compliant, ethical way that is still secure and meets our obligations? That's a new motion for a lot of GRC teams to start thinking about. And what does this actually require? So if we get into the technology side of this, automation, automated evidence collection, designing controls from the start, thinking about policy as code, and putting practical mechanisms in place that put guardrails in at the beginning so that we're not waiting for audit cycles to actually understand how a system behaved or what did or didn't work.

53:38I'm sorry to say it, folks, but that is a prerequisite. We have to get there. That has to be the motion that is in place for the future enterprise. And I firmly believe that GRC analysts are some of the few people in organizations who can actually do that and who can lead that conversation. It doesn't mean you're going to have all the answers, but you have to be a leader in getting that conversation to happen, because this is an all-of-business problem, and it's not something that security alone will solve, or privacy or legal. The last thing I'll say, too, is that risk quantification becomes even more fundamental of a skill set for the GRC analyst by 2028, because-

54:17Going back to my point about failure modes, we can't rely on traditional risk assessment approaches to understand and to truly get a complete view of how these systems will fail. So in order to do that, it takes people, getting people in the room, not just the system owner or control owner, but the people who are impacted by the use of that AI.

54:37We need to turn ourselves into translators, and risk quantification is the means for getting there. So, highly encourage folks to lean into that. I love that you're describing a future in which humans have a role, Cody. Thank you for that. And Caroline, too. Let's double-click on humans for a minute. If agents take more of the work and the standards do catch up, what is left that is irreducibly human? You've written that context can be found in the public internet, but judgment cannot.

55:16I also think there's fun in creativity. Mm. When I think about my daily work over the past 20 years, there's work that I would prefer not to do, that I would just really like for a machine to do on my behalf. And I think we have that opportunity. Yeah. I'm so excited for that. There's also times when I've been severely under-resourced.

55:39How much would I love to be able to do my job with a set of digital twins? How about a team of 10 people, a team of 10 agents? This, I think, is what's exciting. And so humans are going to decide what needs to be done and why. Mm. And maybe agents are going to be helping us out with the how and the execution. Mm. I love this future you're describing. I want more and more assistants too, and I love that I have a dedicated on-demand assistant that does pretty dang good work, right? Right? Oh my gosh.

56:21- Yeah. Yeah. It's truly amazing what we can get done these days. And it's not everything, but it's stuff that... I don't know if anyone loves filling out expense reports. I don't know if that brings you joy, if it's what you look forward to every day. But there are so many things that we have to do at work that are not super fun.

56:44I did meet an AI researcher earlier this year at a conference who trained an agent to take all of his security awareness training for him. Okay, that's pretty funny, right? - It's pretty funny. That's funny. And I don't know- ... that I love taking security training either. That might get to Cody's point about, is this security or is this compliance? Right?

57:17And here's ahead of the curve. Now you don't even have to train an agent. Claude in the browser, go. Right. There you go. There you go, right? Love Claude in the browser. Great idea. So risky. Love it. Let's- Risk. Let's do one final turn here, and then if we have any time left, we'll look at some of the questions in the Q&A interface. And if the three of you have a few minutes to stay after the next session starts, we'll keep you as panelists and you can maybe answer some of those questions by typing responses.

57:59But let's give people something they can take to their AI program on Monday morning. Okay? One thing, one sentence, no preamble, go. Caroline, Cody, Rock. Just ask somebody with curiosity what they're doing with AI that you don't already know about. I think that sometimes security risk folks, we're like, "Uh-oh, don't go there." And I really encourage folks to just ask with an open mind and with curiosity. Yeah. Because then we'll find out about stuff that we didn't know about, and that's what we're terrified of, right? Security and risk people, we're like, "We're really scared about what we don't know about."

58:55And I think sometimes the way in which we approach these discussions, we actually unintentionally nudge people away from us, away from telling us what's going on. And so maybe just try a different approach, see how that goes, see what we find out. And don't freak out when they tell you. Or freak out internally. Freak out later.

59:15But I want us to preserve this idea of, please tell me everything. How do we get people to tell us stuff? People don't love telling security and risk people stuff. Love it. Cody. And once you ask them that, ask yourself, "Do I have a way of stopping that AI from potentially doing something wrong that I might think about, and what are my systems actually logging about that AI use once I discover it?" And to Caroline's point, maybe it's nothing, and that is a good answer if that's the case.

59:57Rock. Yeah. I would say, kind of building on that, if somebody lands a prompt in your coding agent tomorrow, what stops it from reaching your build server or your GitHub repo, right? And who on your team can really answer that question without having to go dig and check? If you haven't read about the Hacktron OpenAI thing that's been happening- ... over the week and over the last few days.

1:00:25Go look it up. Some scary stuff going from Slack into OpenAI's private GitHub repo. Mm. So, at the end of the day, right, you're going to need to let your models draft, but humans need to have accountability- Mm ... which fails at scale. And that's a problem I don't know if anybody's really solved yet. No, but I don't like accountability, Rock. Can't we just pass that off to the agents? Caroline said we could pass things off we don't want to do to the agents. Can we just- Yeah ... pass off accountability? People always sue where the money is.

1:01:00Yeah. Agents don't have the money. They may control- Yeah. What? ... money going from point A to point B. They may control going money from point A to point B, but they don't write the check. Yeah, they write the bill, not the check. Yeah. Back to- Yeah ... Caroline's point of whether we can... The total cost of ownership is, I think, something that really we need to sort of start thinking about, including the cost of governance and control, right?

1:01:37Yeah, tokenomics is definitely another panel. Yeah. A whole hour on tokenomics. Awesome. Well, thank you so much for that. I am looking at the questions there. So Jonathan has a question directed to Caroline. "My approach to how to govern agents lies in the same principles of how an organization needs to manage an insider threat program."

1:02:14Does that view make sense to you? I think it's cool. I think it's cool. Yeah. And what I would add to that is, if somebody in the organization wants to do something with AI that we, as security and risk professionals, are uncomfortable with, then my advice is to go and identify that person's executive and to present them with a document that says, "I have talked to security and risk person about the risks of AI. I understand and accept them.

1:02:49Here is my signature on today's date." It's not amazing, but an accepted risk by a business or technology leader is better than nothing, in my humble opinion. Mm. That is a great answer. Thank you. And we're right at the top of the hour, and I see Ayoub has arrived. So, we're now going to transition into the next session on GRC engineering with Ayoub and Andrew.

1:03:20Rock, Caroline, Cody, thank you so much. Big round of applause for you. It has been an absolute joy working with the three of you to prepare, and even more fun delivering this panel. So thank you so much for that. I got to jump in. Sorry. This is what was keeping me. Jump in. I got to ask- Jump away ... before these three fine panelists leave, rapid fire, unexpected, spontaneous variety version 1.0.

1:03:54Should the CEO be the chief AI officer? Yes or no, and why? Caroline Wong. No, they've got other stuff to do. Cody Scott. But their chief of staff could be. Ooh, okay. Cody Scott? Yeah, I was going to say no, absolutely not. The same reason, but it's an all-of-business approach, as I said. You need to have way more stakeholders involved. Cool. Rock Lambros.

1:04:18Oh, no, for the same reason they shouldn't be the CFO. Sorry, I just read that from somebody that I posted that the other day, that they should be the same person, so just wanted to get some- It's a great question ... share back. I like a little controversy. - And Ayoub- Rock ... you need to send some money to Cody, by the way, because Cody set up our conversation very nicely and was- - I will ... giving a lot of love and affection to the GRC engineering movement. So probably no surprise there, but thank you, Cody, for helping set up our discussion. And thanks, Caroline and Rock and David. Thanks, everyone. Appreciate it.

0:08All right. The man, the myth, the legend, Mr. GRC Engineering Manifesto. How are you today, sir? I'm great. I'm great. Very, very excited about the chat, man. Yeah, looking forward to hammering on the two very important topics. Excellent, excellent. And maybe we should just share with everybody else what we're going to be talking about, Ayoub, just for fun. So, we are going to be talking about GRC engineering, for sure. We're going to be talking about GRC engineering and how it intersects with, aligns with, is next to, and best friends of risk quantification. So just to set the table for everyone, that's kind of what we're going to be talking about today. Ayoub, is there

0:51anything else that you want to talk about, my friend? I mean, we can keep this fairly spontaneous, but I do have the set of questions that we went over, and so I'll ask you some of those at least. Yeah. No, sounds good. If we can get through that in some level of depth, it's already a win. Cool. Well, not everybody is familiar with GRC engineering and the GRC Engineering Manifesto that you created. So if you don't mind, let's start there. What was the driver behind that in particular?

1:19Yeah, 100%. So GRC Engineering Manifesto, you can check it out. You just type grc.engineering. So it came from a couple of practitioners. I think some of them are also in the audience. So Charles Nwatu, Justin Pagano from different B2B SaaS companies, and we were all kind of struggling with how GRC was practiced compared to our experience working in engineering-driven organizations.

1:41And we're thinking we should probably reinvent the field that has been a couple decades old with new primitives that are focused a lot more on how engineering itself works. And the high-level definition, I think Justin coined was like, applying software engineering principles like user-centered design and science and math, and it will be very relevant to this conversation, to existing governance, risk, and compliance problems. So that's the elevator pitch of what we're trying to do.

2:10Right on. So I'm going to take a couple more of your kind of key phrases here and ask you to delve into them. So, shift GRC left. What are we talking about, man? Yeah. So, if you think about especially compliance, right? I think risk, to an extent, has been practiced that way. Like, often we have key ceremonies we care about. Like, we care about audits, we care about kind of like control testing and evidence collection. And these often, they happen after the fact. Like, everything has been already done.

2:41And in a sense, we're not really steering the program. We're mostly reporting on the state of the program on which we had zero impact, right, in kind of shaping. And for us, shifting GRC left is kind of being actually involved in the context of building what would lead to a compliant outcome or what would lead to a risk-steered decision.

3:03But if we're not already happening when the design phase happens, then by the time we actually collect evidence or we do the risk assessment, most of what we could have done to steer in the right direction is already behind us. So we're mostly focusing on collecting checks or just being a professional note-taker. So interesting you said that. I'm going to quote Cody Scott in our last session, who, and he said this apologetically, to be clear, and not comprehensively. He said, "Yeah, a lot of GRC people are just not technical."

3:34And so, love for you to comment on Cody's comment. But in addition to that, let's talk just a little bit, and let's color that perhaps with the notion of policy as code, right? I love that phrase, by the way. So maybe you can start with the Cody comment, make your own comment there, and then shift over to policy as code, my friend, if you don't mind.

3:55Yeah, for sure, for sure. Yeah, on Cody's comment, yeah, I would say I agree. I think my newsletter last week was about the GRC people I respect the most have never shipped code anywhere. I think being technical has a spectrum. I would say being technical is like being a developer or pushing code. I consider being technical to be very context-dependent. So, if you understand the specific tech stack of your company, to ask the right question, to understand the risk appetite of the company in a nuanced way, I think you're technical. And I think just having this continuum of saying, okay, Python is a snake, which is like zero out of 10 technical, and 10 out of 10 is like,

4:37I'm a wizard, right? I can just push anything and everything. I feel like there's different spectrums, and we should not just think about it linearly on how strong you are at software development. Policy as code. So policy as code, it's a misnomer, of course, because it's been named by people outside our field. And policy, there's at least 10 definitions for what a policy is. But again, the context of policy as code, it's a way for you to enforce a specific behavior or record a violation based on specific rules you would set. And it's used often in Kubernetes, some of these contexts. And it's been applied to GRC as a way to say, "This is GRC engineering. This is policy as code." The way I think about it is policy as code

5:18is a way to enforce that deterministically, a check against a rule. It could be done in many other ways. It could be done in Python. It could be done inside Terraform's language or any way. So I think more about what you're trying to achieve, because sometimes we focus on a technology versus focusing on an outcome. And the outcome could be already done by the security team in a different way, and you trying to plug in policy as code as a solution there is one solution. Maybe it's not the one they picked, and maybe they had good reasons. So focusing on what you're trying to get out and then pick the right solution for the job.

5:51Cool. Right on, right on. So, the manifesto values evidence, logic, math, and reason over fear, uncertainty, and doubt. That sounds to me like a really good argument for quantification. So, when you were writing that, was that part and parcel of your thinking, or have you arrived at that? Or what's happened to your mind in that mindset? Because it's a really critical point, my friend. Yeah.

6:21Okay, to be blunt, I think it was not part of it. - I think maybe... Yeah, Justin was a bit more on the CRQ side. I've been part of the FAIR Institute for seven years, so I've been in and out, and you probably know, but when you speak to CISOs, you have different answers on what they think about it for good and bad reasons. And so, I was always on some kind of a spectrum of what I thought about it. But I think it was part of the discussion, but it was not central.

6:50But I felt like the math and reason part, some of the discussions were around we should think about quantifying risk as a part of how we think about GRC engineering. But it wasn't central, if we're really honest. I think it came across later, and people like Tony and others who kind of also said how those two things can collide kind of helped further our thinking. And I always thought, and I think we all agreed mostly, that risk is the key driver in GRC. It's not compliance.

7:19So, technically there's some indirect affiliation there. So it's interesting you bring up the R, right? There have been a number of GRC teams over the past, geez, three to five years, right, where there is an earnest attempt by folks in those organizations to move some of their attention onto the R in GRC and risk. And so, sometimes that's proved a little bit challenging because they've been kind of pushed into this kind of world where they're focusing so much on making sure they're responding to compliance requirements, or audits, or conducting audits, right? And so, the R to me means you really need to be looking at business context, right, and

8:05business objectives. Those need to be key driving factors. Would you agree with that, yes or no? And if so, why? Yes, I would agree for sure. I think I would not attack the GRC teams on this because, to be honest, compliance, especially through the SaaS era and trust centers, it became a business enabler. So, when I focus on compliance, of course I'm compliant, right? But the corollary is, okay, I can sell in new markets, new industries.

8:36So there's a direct way for both GRC and often, very often the CISO as well, to kind of tie ROI to the security program. And often, the compliance team becomes just like an external assurance function. And if you think about it as a maturity scale, then you focus on risk once you've kind of got the basics of what you would need through compliance. But in many cases, risk is a compliance control. Like, we need a risk program for ISO, so that's why we have one. We don't have one because we think it actually drives anything. And ISO says you need to have risks, and then those controls need to mitigate the risks.

9:11But very often, you focus on the controls that ISO says you need to get. You don't tie them... The way they tie them to risk is more as a mapping exercise versus a mitigation exercise. Right. Yeah. And I would say it's logical why compliance has taken all the kind of limelight. It's because the ROI feels more direct, which is so weird because quantification is all about ROI.

9:31But compliance ROI felt so clear because there's this thing where we can say that we tied into ARR and selling more, et cetera. Yeah, I love that you bring up business enablement as kind of a core value that comes out of that kind of activity, right? I mentioned it in my opening remarks, but I'm going to mention it again, right? I've been lobbying for a while to have GRC activity be considered a cost of goods sold, right, rather than as a expense. And if you think about it, that makes a lot of sense, I would argue. And so I'd love your two cents on this, right? Because you can't conduct business theoretically in a country if you're not compliant with

10:11their regulations around, for example, privacy, right, or data security, right? And so, would love your two cents on that. I like the idea. I just would say that every support function would say that. - Legal would say that. IT support would say that. You wouldn't have a workstation if I was not there sending it and doing the onboarding. I would just say cost of goods sold is something that we should earn, in a sense.

10:38So I think if we're not there, it means we haven't proven the value enough to the people that matter. I think more about it that way. I think more about it on me, what I should do to earn it, versus I should tell them and then they should do it. Because at the end of the day, if they don't see the value, there is some stuff that we do wrong, most likely.

10:54Excellent point. Earning it is a key component, and earning it is, we're only going to get there when they trust what we're doing and what our outputs are, which I know one of your points that I love too is around focus on outcomes versus outputs, right? Yeah. And so maybe you can just talk a little bit more about what that means to you.

11:17Give us a tangible example maybe of outcome versus output. I think everybody gets it, but I'd love to just hear if you can come up with a real-life example that might be helpful. If not, we can move on to the next question. You can hit pass on this one. No, no, no. That's good. Yeah. What I mean by, say, outcome versus outputs is... I give you an example.

11:37You have a risk register, right? In risk register, it might be hopefully not like 100 of risks, but maybe there's 20 or something. And you manage the risk register for two reasons, because maybe you think risk is important, but also because it's a mandated control. And you check one risk, and you're thinking, "Okay, what changed in the last quarter?" And you're trying to determine from those change how your risk posture has changed. So of course, it ties in into do you have a heat map? How do you actually check what has changed? And at the end of the day, you think, "Okay, some work has happened." Maybe the high is, I don't know, a medium high-low or something different.

12:16You kind of have to benchmark it somehow. But then if you focus only on outputs, once- You've seen the risk change, like you're kind of done with the activity. Okay, I've actually reviewed, I did the quarterly review of my top risks. If you focus on outcomes, you're like, "Why do I have risk?" Okay, I have risk because the business is okay taking risks for some potential benefit, right? The company exists because someone took a risk, and they're taking risks every day.

12:42And what makes this risk actionable? Like, what's behind this risk decision that makes this business potentially like in, like, there's a threat of some potential adverse effect, right? Because we took that risk. And if you think about it that way, like then it's more of an actionable way in a sense where you would try to tie in how each, like, activity that reduces the risk helps you help the business make money.

13:11And I think it's like the outcome is the company needs to make money, and sometimes a lot of the activities will be the same between outcomes and outputs. But the difference is because you think about it through the end goal and you focus on the first principles of what risk is, then most likely you'll go deeper while still satisfying whatever you care about for compliance.

13:32Whereas when you only focus on going through the motions, like at the end of the day, you don't think about it as something useful in of itself. You just think about it because you need it for compliance or whatever. So that's maybe a convoluted example, but that's one example of how we see it in practice. No, right on. That's super helpful. I think one of the things going back to that moving into the world of R, right, is being able to make those connections and have that thoughtfulness. And for me, like when I started down the path of risk quantification, that's why I was doing it, right? I was trying to help CISOs justify their budgets or look for ways to

14:12build a business case around why they should get an expanded budget, right? And so, like, it's really like tying that work that gets done, right, into what is a necessary business outcome, right? So, that is awesome. Let me ask you about trust for a minute. Trust came up in one of our prior sessions, right? So trust is one of those interesting terms, and I saw my friend Stephen Quinn chime in on this from the NIST group earlier, defining it, so thanks, Stephen.

14:47But it's interesting, Ayoub, because in the world we talk about trust, right? We talk about developing trust internally, and then we talk about third-party risk, of course. Mm-hmm. Trust is as a yet another dimension to it almost, right? Can we trust them? Should we trust them? Do we trust them, right? Like, so give me the GRC engineer perspective on who your key audiences are and how you build trust with them.

15:15Yeah. If you're asking more like how just engineering as a philosophy thinks through trust, then like there's two sides, right? Yes. There's you who's consuming a vendor, and then so you need third-party risk management- Sure ... supply chain security. And then on the other side, how they share their trust to you. So how can you trust them?

15:32Oh, right. Yeah, okay. Please. We call them, like, customer assurance. There's different names for it, but it's like how I go through TPRM, but from the consumer end. So thinking about third-party risk management, something I really believe, and I talked about quite a bit, is like I feel like third-party risk is an extension of first-party risk. So, like, if you think about assessing vendors, like we think about questionnaires, we think about do you have a SOC 2 report?

15:59Do you have a pen test? And we don't even know why we're asking these. We just think like everyone else is asking these. I've been asking these for 15 years. - It's like- You're asking. ... when you buy... Yeah, exactly. When you buy the top, like, vendor on the quadrant, right? No one would fire you because you did that. No one would fire you because you sent a questionnaire.

16:16But at the end of the day, like, when you onboard a vendor, you take an amount of risk. You don't know the amount because you don't track it, but you take an amount of risk. And in many cases, those vendors, like they have their own first-party risk that they compound when they join your supply chain. And I think, like many of the pitfalls of like, we hate TPRM, it's like a very antiquated team, is actually stemming from very bad first-party risk. We don't know where our actual crown jewels are. We don't know, like, we have this weird database from 18 years ago, and we have like 50 tools that have write access to it.

16:52I don't really track that because, hey, the standard questionnaire, they don't ask these questions, and it's not in their SOC 2 report because we're not focusing on, like, how they're expanding the potential attack surface for an attacker because we onboarded them. And for me, like, on the GRC engineering side is thinking about it that way. It's like asking a very small amount of questions that might be a lot more technical and a lot more detailed because you understand the amount of, like, practical risk with this vendor that has write access to XYZ tool, versus just going through the motions of like, I need a TPRM program and I need to ask AWS for the SOC 2 report. Like, yeah, that's fine. But, like,

17:32what's actionable about that? You know? We don't know. Yeah. And on the other side, on the trust side, like it's something recently shipped with Lovable, like Trust Center for Lovable apps. Like, I want the industry to find a way to communicate the security posture in a way that is more actionable than a trust center. Because the limitations for me as a trust center is like, if we're really honest, it's a marketing page, right? So it's like, "Yeah, we're good.

17:57We love security. We're all amazing. Buy us," right? And there's nothing actionable. Same, right? There's nothing actionable about Trust Center because anything that actually matters is not there because you would not want it to be there. Which means you need to think about how someone would assess you and, like, giving them the tools to make the best and rational decision with the limited number of hops, right? Instead of, like, lots of back and forth and meetings. And of course, it requires trust on both sides.

18:25But the core here is like, how you ensure that whatever I'm onboarding as a vendor, I understand with my eyes wide open the risk I'm taking. I think that would be the goal of that. But for now, there's not enough incentive alignment for that to work, because you're so scared of like, the competitor does not do that. They just lie, which means I should just pick them because they have to be more secure because they said everything is good. I love your support a little bit, and then you're calling into question the trust center, right? As you were talking about that, I was just thinking of an individual standing in front of a mirror and saying to themselves, "Look how

19:08handsome or beautiful I am," right? I mean, in some respects. Yeah, we all do that. There's an element to that, right? I mean, like, "Look at everything we do. We're amazing." Yep. That it is. Too good, man. All right. This is an interesting thread to pull on. I didn't mean to go down it, so I apologize because we didn't talk about this. But part and parcel, right, to the GRC engineering movement to me, right, is about being able to do a better job of evaluating controls, right? That's an Andrew evaluation of it, right? It's not the only value, but it's a significant one, right?

19:44Because we're actually looking at data that comes from a control or- Yeah ... from the system itself, right? Rather than looking at how somebody asked three questions as to whether or not that control was in place, right? That's different, right? So those are two very different data points to begin with. Let me just, before I ask my question, let me just pause on that and say to you, do you think that is a good way to summarize a core value for the world of GRC engineering and where you see GRC needing to go, moving from qualitative questions, right, to actually querying the controls?

20:24Yeah, I would say it's accurate. I would say it's accurate. It's the most natural fit, so I would say it's accurate. Okay. Fabulous, fabulous. So, let's go back and now to my question, right? So, again, the Andrew Shea belief is talking to about himself and the third party. Love that. In order to really understand the risk posture of a third party, you actually need some empirical data to work from, rather than just responses to a questionnaire.

20:53Is that a path that you think is important going forward, that we move to that type of world? And there are people who will say, "Well, that's not possible. I don't trust them enough," which is ironic because you're doing business with them, right? But- Mm-hmm ... so do you see that as a key path going forward, and any thoughts on how that gets enabled?

21:11Yeah. I think it's the key, but I think you can still get good things without having that, because of course, the lawyers probably be very, like legal counsel will be unhappy, right, with you trying to share vulnerability data or stuff like that to your vendors or to your customers. I feel like, I've heard this statement a few times, like, it's so tough to interview people now because with AI or whatever, you can fake being competent. And I feel like when you know your domain, when you're interviewing someone, it's very easy to probe the right type of questions to know if someone actually knows their stuff or if they've done it.

21:47And I feel like you could do that with vendors fairly easily. And there's actually a matrix for vendors where I feel like there's, now with AI, there's a ton of vendors who are very, very small in size, are very critical in impact to your system because you need them for a capability no one else does. So you have both leverage over them because they're orders of magnitude smaller than you and they need your business, but also because you have the leverage to actually enforce some security controls they have to implement and have that in writing because they really need your business.

22:21And I feel like you can't do that with hyperscalers because there's no point. Once again, they're actually orders of magnitude bigger than you. And then you just can't do that with smaller vendors are insignificant to you, right? If it's just like something that does fax copying or whatever, who cares? But there's now with AI, this middle layer that's both critical and very small. And I think if you intervene there, you can actually contractually enforce stuff they have to implement. And for me, it's like the risk-based approach to kind of doing third-party risk management, is just thinking about that middle ground when you have the impact and you're actually substantially reducing the attack surface

22:57instead of trying to get telemetry from big vendors who would never share it with you. That's right. Because at the end of the day, it will happen, but God knows when. But actually, these vendors, you can really have... I have seen it in practice, right? Especially with a startup, you really want to get the logos. Sometimes you have a lot more leverage than you think, and that's where you actually need to know your first-party risk to know what to ask, right? Because if you don't know, you just say, "I just need your SOC 2 report." I'm like, you lost a big opportunity. You could have asked for so many more interesting controls to implement on their side, and you just wanted a PDF. But that's fine,

23:33right? No, I'm with you, man. It's interesting, this integration of first and third-party risk, right? Some of the folks that I see who are doing, kind of advancing their programs faster, right, are focusing around, "I'm going to help you understand my risks," right? "I'm going to share with you my top risk scenarios," right? "Because I want you to know," right? Without the quantification piece, right, just what these scenarios are and which of these do you think, right, you would impact. So forcing them into a risk dialogue, right? I'm not saying it's the only path or the one true path, right? But at least there's a dialogue, to your point, right, that's more focused on risk rather than what documentation

24:16do you have that can support your position, right? So just starts the conversation differently. And so in that, right, then we're talking about risk scenarios. And I don't think you and I have ever spoken about the criticality or lack thereof from your perspective of well-defined risk scenarios, right? So to me, right, like that's a key element for us in order to be able to provide a GRC team, right, like an appropriate context, right? And the extent that they have those capabilities, that's great. What are your thoughts on that, my friend?

24:52Yeah, I think it's critical. I think what's been challenging for GRC teams is to properly scope out the level of abstraction for a risk scenario. You know, there's like those tiers, right? Tier one risk, tier two risk, and like tier three, which might not actually be risk, so it might just be like vulnerabilities or whatever lumped into risk.

25:09You know how shaky those definitions can be- - ... for us? I'm familiar, yes. And I think the main issue is like, you think, "Okay, I have a risk in a risk register." The risk could actually be a scenario itself, like the risk statement. And then if I need, like, I don't know, to scope it in like 50 different sub-scenarios to ensure I target like every asset in scope or every- Right ... attacker type in scope, I think very quickly you end up kind of trying to boil the ocean. Yeah.

25:39Instead of trying to focus on like a risk that is abstracted enough that you can still, like, instead of trying to create sub-scenarios, just have the same scenario but just iterate on the assets and like the attackers. I think it looks more, it's the way I think about it, and I think it's more practical. But people who try to do it right, often they end up boiling the ocean, and they'll just like revert back to the median risk program, which is crap, right, if we're really honest. - And I think that's the issue is like iteration. It's the same with CRQ. It's either it's perfectly accurate or we don't use it. Like, guys, like- - ... maybe there's a range, right? Maybe we can, you know?

26:16And I see that as well with a lot of the risk activities is like, if I don't get perfectly well, which is impossible because risk is about uncertainty, like if I don't get perfectly well, then I don't do it at all. And I think that's where we need like just more empirical. Like, we need to just try to test stuff out and see what works and then iterate, which we do all the time by pushing iteration and like agile and all this. But about a risk program, we're a lot more dogmatic in some interesting way.

26:43Sure. Right on. When we talk about the world of controls, right- Mm-hmm ... it's interesting. I think when most people hear the word control, the first thing they think about is what is the security application that I have in place, right, to prevent this breach from happening, right? At least in the cyber world. No offense, or forgive me for being so cyber-centric to those of you in operations, enterprise risk, and other risk domains.

27:11But there's more to it than that, right? I mean, we look at trying to understand our control structure overall, right? There is not just the software. There are the standards and policies and processes, right? Like, for somebody that's trying to evolve their program, right, is there any guidance that you can share about how you should be thinking about your control universe as you go forward?

27:37Yeah, you know, most frameworks divide controls into like some kind of human controls, technological controls, and sometimes could be like process-oriented controls. Sure. What I would say is like, if you're risk-based, then you should think first about the risk and how a specific risk could be mitigated through every type of control, right? Sometimes a strong process where you can check adherence could be a very strong control against a specific risk. But in some other instances, you know, there's so much variability into how people do the work that you can't really enforce it that way. I give you some examples. Like, nowadays, like the way people develop code with AI is very unique to everyone.

28:18Someone uses Lovable, someone uses Claude Code, someone uses Codex. And there's new types of coding agents that pop up every week. If you try to enforce a security control on every single agent, like there's no way you can get to every single one, which means you always have scope that isn't tracked by your control. And you need to think about what's the invariant. At some point, if they want to destroy my application, they'll push code to production. So GitHub and PRs and these, like the CI, will always exist no matter how they actually try to develop the code itself. So you have specific invariants, like everyone for now uses some kind of device to push code. Could be

28:59a laptop, could be a phone. So there is like invariants on which you can plug in control where you know that the control will be effective on most of your scope, on all of your scope. And there's all the moving parts. When you try to focus too much time on trying to enforce controls there, like the drift will happen very quickly. But the issue is, in many cases, especially in like more immature, like most GRC program, fortunately now, is like GRC engineering and technically is the way you help to match the visibility to the drift.

29:30So you should know if there is a massive drift in like adherence to the control because people have been downloading like new coding agents left and right, but you have full control over like the Claude desktop app, but no one uses it in practice. And this issue we have often because we have ceremonies that are quarterly, that are annual, right? We review the risk register, we do like control testing for audits, and we often completely miss that because we can still have full compliance with controls that had complete issues with the scope, right?

30:05Because it's an enterprise app, it's tracked, it's managed, it's under SSO. We've enabled and toggled those five things. I pass. But people are using Amp or like Slate or whatever conductor, and it's like, it's Shadow AI, right? And I think like the way you think about your controls in that context, it really helps to understand, especially in AI, what won't change.

30:29And if you want a specific mitigation done, focus on these, and for the rest, you know, give some liberty. Because you know you'll track it another way, and you know that to get some goodwill from control owners, it's sometimes good to lose a war to... No, lose a battle to win the war. I know what you mean, man. Oh, thanks, man. I appreciate that. You know, it's interesting, staying on the control topic for a moment, right?

30:57We talk about how do we assess or analyze controls, right? Historically speaking, as a senior citizen now of control discussions , the conversation for forever has only been about maturity, right? How mature is your program and the controls within it? You know, for me, when I was starting to go down the risk quantification path, I was like, "How do I use maturity, right, to help understand control effectiveness as it relates to a risk scenario," right? I'm like, "These things are apples and oranges and bananas and pears."

31:35And so, one of the discoveries then was, how do you do control effectiveness? How do you look at a control and determine whether it's effective both singularly and in aggregate? Yep. And so, I have my thoughts on that journey, but how important is that to you as you're trying to build out and answer the question about risk, right?

32:01How important is this notion of control effectiveness to you and finding a means by which to measure these things? Yeah, I think it's the key, right? I think it's the key because it's the only metric that actually tells you the truth about how your controls are operating. Like, you know in control, like in the GRC control world, you have test of design and test of effectiveness. So test of design is the control shaped the right way to reduce the risk, even though we don't track risk with the control, but that's fine. - We know it. And then there's control effectiveness, which is, is it actually doing what it stated, and is it actually doing that the right way and the way you intended it?

32:39And I think maturity is very difficult. I see so many... Like, I think NIST uses that sometimes as well as some. Like, I think 853 has that approach and a few others, where it's like gradual levels of hardening and locking down that creates maturity, right? It's like the more you aggravate control owners, the better your control is working.

32:59- Which I think is like a weird way of thinking about control maturity. So the way I think about it on my side, and I had a chat with, yeah, Justin also thinks about this the same way, is like, could you atomize a control into sub-controls where you atomize it small enough that everything ends up being a yes-no? So, I give you an example. Like, okay, you need a web application firewall because it reduces XYZ kind of like risk. You could say it's on and it's supposed to be on. Okay, it might be enough for some standards. And then it should be on and have rules enabled. Okay, that's the second level. But very quickly you can get into, does it have a default deny? And from the default

33:41on the allow list, does it have the specific rules I care about? Are they ordered in the right way? And if you get into a granular enough level, you could get like maybe 15 almost like binary checks that you could run. And if you only tick six out of 15, you don't even have to say it's like medium maturity or... It's just six out of 15, right? Right.

34:02And if you risk-base the 15, you know which ones are tied to the stronger or weaker kind of impact on mitigating the risk. So you know maybe if you have those 11, you're like 95% of the way there, and the other ones are like cosmetic, but they're still part of what would make a complete control. And I feel like it's a more... Because it's a weird opinion to say something is mature. Like, it's a statement that is subjective in nature. So I think the objective way of thinking about it is more everything you could do that maps back to specific control activity, and then how much of these things should be true at once for you to consider the control effective, which is a risk-based statement, right? Maybe you only need two

34:41things. Maybe the control only exists for compliance and you don't even care if it's effective, and you just have to not be... You don't have to be cynical about it, just understand why you have this control. But I think it's a more useful, pragmatic way of thinking about control maturity versus just like, yeah, increasing levels of pain to control owners.

35:02You know, it's interesting. I was in a conversation not long ago, Ayoub, where we were talking about how to get funding for a cyber risk quantification effort, right? And that went down a particular path, and I may come back to that later. But shortly thereafter, in talking to this individual, they were like, "Hey, we just got the results of our NIST CSF 2.0 framework assessment back," right? And as everyone's well aware, the govern function is a more recent add into that.

35:33And so, they did not score well on the govern function. And so there was an edict, right, that they needed to move their govern score from 2.7 to 3.1, and therefore funding was made available to do that, right? So, interesting kind of point and case of what we're talking about, where there is this belief in the maturity system and funding will be kind of associated with it, yet the challenge is trying to then articulate right back, right, what we actually did- Where we are at today, what are the controls we have, what are their status, right? And then what do we do to improve those, right? Which ultimately provides a better kind of path forward. So,

36:16you got some really great points there, man. And I just, when we talk about control effectiveness, for me, right, like I think of FAIR and I think of FAIR-CAM, because those were very formative to how I think about these things. And FAIR-CAM as a control analytics kind of function, right, where we're looking at things like defining the control and is this control, does it remain, right, at the state that I want it to in its kind of ideal state?

36:41And so there's this notion of control variance, right? So, I'm measuring how often this control works, again, singularly, but also in concert with the other controls that prevent a particular risk scenario. So, from a control effectiveness standpoint, right, like that's one path, one kind of approach. Are there any others that you are familiar with, or is there anything like in that world of control analytics that you'd like to share with as being critical items? Like, if it's you and you're given a project and they're like, "Hey, you, please design a control effectiveness program for us," right? Well, here's the first three things that you might do to go down that path.

37:19Yeah, I like FAIR-CAM. I would say FAIR-CAM is something that also was kind of formative to me in a sense. I really enjoyed the way, like it's very well thought out. And I saw recently there was a very good paper by Laura and Jack on kind of like how it was implemented on the agent side. The paper was very interesting as well for me. I feel like very often, GRC practitioners, like more traditional ones, feel it's like so far of what they should care about, but they speak controls every single day. So it's like a weird- - ... setup where they should actually care about these things a lot, but they feel like it's not for them.

37:55And I feel like there's a few, I think in one of my recent newsletter, I was talking about some of the core, like metrics I care about for controls. There was like five core metrics that I cared about for controls where I would say, like, when you have those five running, you kind of have a good way of thinking through what you would consider your controls to be effective. And in the list, there was like understanding the failure rate for the control. And that was a big thing for me that we don't care as much in GRC. Often we just like track the control is effective, but we don't think about, like, what happens when something goes wrong, right? How quickly are we able to find out that it's wrong

38:41or something has been failing? And understanding, like, how critical the failure is. Because sometimes a control could be effective and it could be failing in a completely irrelevant part of your scope. Sure. And sometimes, like, it could be failing 20% of the scope, but the 20% is useless. And sometimes it could be 99% effective, but the 1% is literally like your IDP or your EDR.

39:06- You know? Something extremely critical. Yeah, absolutely essential. So by itself, it's not enough to just think like, okay, like the control is effective or the control is failing. Like, it's also, once again, it's qualifying, right? So it's once again something that I feel like is risk-based, because you need to think through, like, what should I care about? So I talk about like remediation velocity was one.

39:28Another one I cared about was like the exception, right? I think it's something we don't talk about enough is like when you design a control is how often do you have exceptions that you log against this control? Like, you could think about stuff like having an endpoint detection and response, kind of like literally antivirus, right, installed on your local machine. And sometimes they have good reasons to not have one installed. Maybe you don't want to do some stuff on the side. Maybe you work in security and you want to do stuff that doesn't trigger alerts. But you need to log these, and when you get to a certain amount that you define, you might think, "Okay, is the control designed the wrong

40:03way?" Sure. Because a lot of the highest risks are getting accepted because people are circumventing the control because they have good reasons. But maybe we should actually apply the strongest pressure elsewhere to still get the outcome that reduces the risk. And you can only track that if you think about exceptions in them like a thoughtful way, in meaningful way, instead of just logging them in like some kind of like ticketing tool and not doing anything actionable with them. So I think like, as always, it's always the delta, right? It's the SLA, it's the severity distribution, the exceptions, the remediation velocity. Like these things are when everything has to

40:43go wrong is when you actually know that it's working. Because I said once on LinkedIn, like, if you track a control that is always on, like at this point it's like looking grass grow, right? - It's nothing like, okay, your computer has BitLocker installed. That's amazing. Thank you very much. But like, it's installed by default on all machines.

41:02Like, if you track a control that is 100%, like it's just like ego boosting at this point. - Yeah. So you need to track the stuff that has moving parts that is useful, actually ties to something meaningful. So yeah, that's some examples of how I think about control effectiveness. Thanks, man. I appreciate that. And I hope that one of the takeaways from our session today, right, is that if you want to be in the GRC engineering movement, right, like that you understand control effectiveness and its criticality. So, I know that's not the only one, but that's one that I think would be a nice win for us, if you would. One of your lines that I really liked was that

41:45GRC is the only function still running on audit cycle time. - Yeah. Which is an interesting comment and a challenge, right, for many organizations, right? Like the activity is tied to a specific quarterly, semiannual- ... annual basis, right? And now we have the world of AI, right, that we are dealing with on a lot of different levels, which even exacerbates that problem, right? And so for people who are trying to move their organization from this kind of audit time into real time, any thoughts on key things to communicate internally or key techniques to make that happen? Yeah, I would say a lot of it is self-inflicted.

42:30- People would think that. But that's true because a lot of people say, "Yeah, but like we need to maintain all those certifications." And once again, like passing a certification is, for me, it's not an outcome. It's just an activity. It's just something you do. But if you think like, "Okay, I passed my driving test." Okay, that's fine, but it was 15 years ago. Like now, you can just drive and do whatever. Go from A to B. And I think like we are often fixating on like making passing certifications as the core job that we have, even though like it kind of really pegs that. Like, it pegs our understanding and also the impact we can have. And from our perspective, I feel like

43:15to stop being like just audit-driven, like you just need to think about audits as just an externality of controls being run and being implemented, not the objective of the control being implemented. It's like if I'm a good driver, I'll always be able to pass a driving test, even though I'm like 15 or 20 years into driving. And you shouldn't think of like me when I drive, I don't think about the driving test.

43:41But we think about the driving test as GRC professional every single day. And I think the issue there is we think it's a beacon of trust that we share, which it is to an extent, but the value is dwindling because we know how little trust we can put in them. And if you actually were in industry for quite some time, you knew, especially our technical control owners who had to join in walkthroughs and speak to auditors, like they knew about the limitations.

44:05But us on our side, you're like, "Yeah, of course, that's my job. And we passed it. We have no non-conformities. We have no qualifications." And it's an incentive to kind of maintain that and use that to get promotions, et cetera. So for me, I feel like we should be risk-based, right? Yeah. Which means like compliance by itself, like these controls should specifically help like mitigate risks. And if they just exist for their own sake, just for audits, then just be clear about that and don't over-invest. Like if you do GRC engineering and automation on controls that only exist because an auditor asked them to exist, like the opportunity cost is insane, right?

44:44Yeah. So I think it's just like the objective is how you ensure that you track those controls because you actually need to, and they map to risks that the risk that security cares about, right? Because everyone focuses on like attackers and like threat actors, and us, we focus on auditors. Like imagine being a CISO, having six security teams, having one that speaks about auditors half the year, and everyone else who speak about post-Mythos and vulnerabilities and like Hugging Face. And us, we're like, "Yeah, whatever happens, they're still SOC 2 compliant, right? Everything's fine."

45:14- Right? So there's this whole like cognitive dissonance between us and the rest. And I think to get back in line, quote unquote, like we should focus on like just making the rest busy work and automating so we do less of it, and focusing on actually what moves the needle because that's what will make us relevant to the CISO and to the rest of security.

45:33Yeah, it's interesting you mentioned automation. Along those lines, another one of your quotes I really love is, "Automating the wrong thing just elevates theater." Yeah. Which in some ways summarized a bunch of what you just said, right? Or adds another layer of kind of this is why it's critical. This notion of GRC work as theater, though, right, gets a fair amount of play sometimes on LinkedIn. Like, why are we doing these activities, the point you were making, when what the outcome is and what the business value of that is not well known. So we'll just pause there, right? And now we have the world of AI, right? And a lot of people are using AI for automation.

46:18And so tell me how the guidance that you give to people so that they can use AI effectively, right, as part of their GRC program, but not elevate theater. Yeah. Very good question. Two things I would like to say. First one is AI is two capabilities. First one is it reasons, quote unquote, right? - It's a next token generator, but it reasons about things, right? So you give it a problem, it'll give you some answer. And AI's answer are always plausible, so they always look good.

46:53The other thing that AI can do is build deterministic things for you. So they can build a script, a API call. And I think something we've kind of like forgotten about AI is some stuff that we were not able to check before because they were costly or we didn't have engineering time, like AI is actually engineering time.

47:12So you could use it to build stuff that ends up being extremely deterministic, so the outcome you can trust. Instead of using AI, like, "AI, can you check if my S3 buckets are encrypted?" Like, it's just so dumb to ask AI to do that because it's not the best use of the reasoning part of the LLM. Sure. But you can ask it to build an API call that checks for all these things and like pipes it to a dashboard, and it always ends up with the same answer because everything in code is deterministic.

47:41And I feel like a maturity in kind of using AI for GRC is understanding where you need human judgment, when you need LLM kind of LLM judgment, so reasoning across like especially unstructured data. Sure. When you need something that should be fully deterministic. And like if you're able to understand where each fit, then you'll have closer- Like, you'll be more hyped about using AI, and I think if you're using it for the wrong thing, you often will say, "It doesn't work." Like, "It's not really giving me good things." And one other thing I want to say is AI is average at everything. It's like AI means average intelligence, something I heard a few times.

48:22Love it. And what you should remember is, everyone should be T-shaped. So, I'm extremely in-depth in my domain, and I'm kind of okay at everything else. If I'm extremely in-depth in my domain and I have access to an average designer, average PM, average software engineer, I can do so much more with my depth. And AI, you always think AI is crap at your space because you know your space very well, and you always think AI is disrupting everyone else's space because you don't get them. You think it's so good at everything that you don't know. And I think harnessing your key differentiator as a GRC professional and using the tools that AI gives you to build dashboards that match what a PM

49:00would consume, and something else for a control owner that lives in finance. And those kind of last mile things you could do now with AI that creates a delightful experience for the risk owner or the control owner, it can give you a ton of brownie points and really help you build a lot of rapport with stakeholders. We should think about it in that way, you know?

49:18Yes. Instead of thinking about it as like, "Yeah, it's so bad at, I don't know, checking if this control works." I'm like, "Yeah, that's fine, but it's your job." Like, you should codify your expertise in something that AI can use, because AI is not you, you know? Right on, right on. Let's stay on the AI path for another moment, right? So, our last session with Cody and Rock and Caroline and David was, there was a fair amount of discussion around AI governance.

49:45And AI governance is one of those phrases, Ayoub, that makes me crazy, because what are we talking about? Strategic, operational, technical? Are we talking about a harness? Where are you actually speaking? So, forgive me as I ask you this broad AI governance question, but certainly, as somebody that is really promoting, right, the world of GRC engineering, right?

50:09And AI being a very capable companion in some cases, as you mentioned, right? What guidance do you give, right, to folks that are trying to take AI governance from very broad-based, vague discussion points to practical, actual measuring of the reality, right, of a particular application or application set, if that's a fair question? Yeah, it is.

50:39Governance is a very elusive term. For some people, it means managing your policies. For some people, it means something that gets to the board. Like, if you think back on the Enron days, a lot of what we call was corporate governance, right, based on all the stuff that happened. I feel like on the AI governance part, I feel like, once again, risk is very critical. Mm-hmm.

51:00I feel like governing AI also stems from the risk appetite of the company. So, what's the willingness of the company to forego some potential revenue to govern the usage of AI, versus what's their kind of way in which they think we could take more risk and potentially have less go? Because for me, governance means, what's the intent of leadership towards this domain and how they transcribe this intent into actions which lead to policies, procedures, et cetera.

51:32Sure. And in AI, it is really how you govern the usage of these tools. What kind of level of access do you give to the data you have? And you think about risk around your IP and leakage and giving non-engineers access to pushing code to production and stuff like that. And I think it comes from literally the C-suite, in my opinion.

51:53Sure. Because at the end of the day, you don't take the risk. They do. Right. And AI governance is a way to kind of enforce the intent of leadership towards AI adoption. It's an imperfect definition because I don't even know how to define it, but- Yeah, no, man. I thought you did great ... in my pea brain, that's how I define it. Well, we take this broad corporate governance kind of phraseology, right, and now we're talking about and marrying it and asking somebody from coming from the GRC engineering world, who's data-driven, empirical-based, policy as code, right? It's an interesting question to pose because I think it shows the dichotomy of how people think about

52:33this term, right? So, all right, my friend, you have been wonderful, and I know I've jumped all over the place, so thanks for bearing with me. But I expected nothing less. I do... Wow, there is a jalapeno with a vest on it. Oh, it's a water vest. Last question to you. So, 10 years out, does the GRC engineer absorb quantification as a standard skill, or does CRQ stay a specialty that engineers integrate with?

53:02Okay. Okay, I have a hot take. - I would say GRC engineering in its current form would probably get absorbed by CRQ. Okay. So, I feel like for me, GRC engineering, the mindset part will stay, thinking in systems and all of that. But thinking in systems helps you... Like, GRC for me is decision support. Sure. Decision support should be risk-driven, because risk is about understanding uncertainty, and everything about business is uncertainty.

53:36The GRC engineering motions will probably get absorbed by automation at some point, because it's just like we go deeper in the level of abstraction, which is where AI is better than us anyway. It would read code bases way better than us. So, we need the muscles of engineering, but we probably will apply them at higher levels of abstraction. But CRQ, the whole quantification of risk is how you should drive your program, which I think will overlive and kind of probably absorb GRC engineering as a source or way to make sense of the telemetry, but it probably live past it. So in a sense, CRQ would kill GRC engineering.

54:17Excellent. Well, thank you. Thank you. Thank you so much, Ayoub. So, appreciate your time as always, and thanks for jumping in and sharing your insights with us. Again- Of course ... visit Ayoub on LinkedIn and make sure to visit GRC Engineering. And if you have any follow-up questions, please-

0:07So many options. ADHD overwhelm. All the way. All the way. So, welcome everyone. We're, we're, uh, two minutes early, but I say we get started. How about that? Um, I'm David White. I'm president and co-founder at Axio, and, um, I do a lot of work in risk quantification and risk management in the OT landscape. Um, and I'm joined for this session by Kristin King.

0:50Kristin, introduce yourself so that I don't butcher it. You're fine. I, I just totally took the biggest sip of water, so- - ... I'll probably choking in the middle of this. Um, yeah, I am Kristin King. I am the CEO and founder of Anson Sage, which is a cybersecurity firm that's, uh, handles risk strategy and management for food and agriculture, zoos and aquariums.

1:13And then I'm also the co-founder and CEO of Anson OT, which is a risk management SaaS platform that also helps manage industrial risk. I am the host of "Bites and Bytes" podcast. That's bites like you bite something, and bytes with a Y. And, um, I also am the author of "Securing What Feeds Us: Cybersecurity in Food and Agriculture," which is out and published a week from today.

1:39And- Boom ... Kristin got the, the screen. I also, David, I, this time I remembered to bring my copy up, so... Beautiful, beautiful. . Yep. So, I- We have really good friends that have written their lovely little praises on the back, so... I'm so excited about your book. Mine is pre-ordered, and I trust that Amazon will be delivering it next week. I- They are actually starting to arrive. I've gotten- Are they? ... a little bit. Oh my goodness. So, maybe it'll come today. Let's see. Who knows?

2:10Where is the... - Where is the chat? Okay, so I have posted, uh, connections to me and Kristin on LinkedIn. Please follow us on LinkedIn and, um, check out Kristin's book. Um, very exciting times for Kristin with the, uh, publication, well, or the release scheduled for one week from today. And this book is worth featuring, um, briefly, um, because it lands squarely on what this session is about. And it also, I think, um, points to some of our... I know, let's, let's do a f- our first spicy take here. So, what's your top pet peeve about... Well, wait, before we do that, should we distinguish what OT is for people who might be, who might be coming

3:08from the IT side of the house or banking and finance where they don't, like, have much less visibility to OT? Do you wanna... Do you mind taking a minute to do that? So, OT is still in finance environment. I mean, it powers the buildings they work in, right? So- That's... This is true. This is true. It's just even more hidden there. Yeah, it's just invisible. It's, it's all the stuff that powers the modern world that you need to thrive, essentially. Um, so that goes anywhere from an autonomous tractor to an elevator to an escalator to a space shuttle to a indoor greenhouse to a production line.

3:44It's all the stuff that you probably don't ever think to include in your risk assessments, and probably shouldn't if you don't understand those environments anyways. But, um, it does touch the enterprise environment most of the time. Uh, we don't like that. We want it to not do that. But, uh, dashboards are fun and they need connection. So, um, yeah, OT is, OT is all the things that are super important and often forgotten because they're invisible, like our food supply chain, David. Yeah.

4:15Because nobody thinks about where their food comes from. Yeah, it's, um... I love this. It's, it's, it's where... OT is where computers interact with the physical world. Mm-hmm. I know that's an overly broad generalization. I'm not gonna, I'm not gonna try to unpack it further. Um, Kristin, what- what's your, uh... W- would you number one spicy take, your biggest pet peeve about OT risk management?

4:51I think one of my biggest pet peeves is you can't look at risk in that environment the same way you would look at risk in other environments. It's almost opposite world, like you crash down and fallen into Wonderland. Um, I think that's why it was my first experiences with it was like, "Wait a minute, so this really isn't a risk here, but if it was in an office environment, it would be a so would be a risk." Um, and I think realizing that risk is very subjective and, um, really working through what that means facility by facility rather than organization by organization.

5:26You really have to look at OT based on the environment it's sitting in rather than the whole playing field in so many ways. I mean, it even could be down to different sections of, uh, a production floor or a factory or any industrial site. You wouldn't look at, like, um, an oil rig the same way you would look at, uh, a fish farm. You know what I mean? Like, it's- Yeah ... there's... it's apples and oranges, but it's still industrial, so that's what's important about it. Yes.

5:51Um, and I think my pet peeve comes from people trying to bolt on frameworks and ways of working to systems that are not going to, uh, appreciate or cooperate. Um, it's sort of like attaching a little connected internet device to a legacy, um- ... system that's 45 years old and doesn't understand what the internet is, and it speaks French, and you've introduced Russian to it, and it's like, "What is this?" And now you've got a whole other set of problems. So, that's probably my biggest pet peeve is how we manage risk between the two environments. And I don't think it's an us-versus-them type situation. It's not that for me. I don't do the whole convergence bullshit thing. But,

6:36what I do feel is if you don't know, ask. Don't assume, ask. Mm. And that's probably my second pet peeve is the fact that people don't stay curious and ask questions, and then they just assume, and then, oh my God, boom. So... Stay curious. For those who have been following along all day, Caroline Wong, two hours ago, was urging people on Monday morning to go in the spirit of complete curiosity, have a conversation with someone using AI in your organization. And emphasis on curiosity, remain curious.

7:15My biggest pet peeve is that it's invisible. It's invisible. We take all of this stuff for granted. We take the power grid for granted. We take water for granted. We take food supply for granted. We take hospitals for granted. We take the elevators for granted and HVAC for granted. All of this stuff that depends on OT, we take for granted. It's invisible.

7:42It can't be rebooted. It has to run for years, decades at a time, and it's invisible. I don't think it gets enough risk management involved. And it's a safety record, right? The fact that you can't take this stuff down, you can't interact with it because you probably end up causing an environmental disaster, or you're going to injure a bunch of people via environmental disaster or just a safety aspect. Right.

8:07I don't particularly care about the data that's in the environment. I care about safeguarding lives in the environment. And I know that's such a catchphrase that you hear a lot of OT people say, "Safeguarding whatever." It's true. I want to make sure people get home. I don't care about the data. I care about making sure the physical process is okay and the people in the physical process are okay. The rest of it will sort itself out as far as I'm concerned.

8:28And that's a real big difference, and I think that's part of the reason why it stays invisible, because it's not sexy, David. Yeah. Safety isn't sexy. Now it's yellow vests. Yes. We've stepped into the yellow vest and hard hat world now. And we've stepped away from confidentiality, integrity, and availability, and into safety, reliability, and performance, from CIA to SRP, as you indicated. So, in this session, what we're going to do is Kristin and I have assembled five cases of OT risk, examples of OT risk in the modern world. We're going to walk through those and describe them briefly. This is not an in-depth like, "Oh, here's what happened.

9:25Isn't this cool?" No. We want to elevate this to an OT risk management perspective with some spicy takes on, what can we learn here? What can we observe about OT risk management in each case? And we're going to start with blueberries. Blueberries. This is actually not an OT incident, so everybody just get your helmet. Yes. Talking about stepping through the looking glass.

10:00Right. So, Kristin, what happened here, briefly? So, I would like to give you a nod, because I actually didn't hear about this until you sent me the article, and then I went, "Oh, boy." And then we both went, "Oh, boy," together. So, long of the short of it is a US grower who is a very predominant US grower, you've had their berries before, I'm sure, and maybe even eating them right now for all we know, decided to start building in China. And I think most of us know that have worked with China or work in security in general know that China is really good about IP theft. We'll just call it what it is.

10:46So, I think the blueberry company went in, or the fruit company went in with the good intentions of, "We're going to put in these blueberry plants. We're going to help drive the price of blueberries. We're going to do the right thing." But they own patents on their blueberries. Their species are theirs, right? So, yeah. So China said, "Cool. Thanks for this," and did some blueberry clippings and started growing their own and at a lower market margin. And it was really kind of just naughty. It was very naughty. Let's just be honest. But, as David and I pointed out when we were looking at the story, they should have known the risk before they entered the market, because it's very well documented.

11:28I'm sure some of us have worked in industries where this has happened. I know I have. The electronic sector, for sure. Semiconductor sector, absolutely. So, of course it would work with fruit too, right? And then I'm sure some of you are like, "I don't care about blueberries," or maybe some of you are allergic to blueberries. I don't know.

11:50But it's interesting that this is now crossing over to food more and more, and this is happening quite frequently because there's patents on species and seeds and different things, and they can be transferrable or stolen because that's data. It's essentially just data. And we're going to see this more and more where people will be doing this. And to me, in some ways, this is almost a blatant food fraud incident, even though it's not food fraud because they literally took- ... that particular food and they made it in their own way, but it's sort of fraud because it's not underneath the company name that owns the, the rights to that particular species of blueberry. So that risk is really

12:33complicated. So when you translate that over to a, a security side or even an OT side, you start to see a little bit of the unraveling if you apply a little bit of systems thinking to that, how this could actually not only hurt the brand, but it could cause complications in the market with traceability and transparency.

12:51It can cause all kinds of potential food safety issues where, where's this actual blueberry from? Is it from the United States as the species that it is? Because that's what you'd assume. Or is it from China? We don't know now. So, they're in litigation. They're fighting. I think they're winning too, David. Yeah. They are winning. So, so this is...

13:10There's no reason we can't say the name. Look, this was, this was... We learned about this from an article in the Wall Street Journal just a couple of weeks ago, and we have prepared a participant handout that includes references for the five cases that we're talking through. So I'll, I'll try to upload that to the chat. If that doesn't work, then we'll just, we'll make it available once the videos from, from the summit are, are released. This is Driscoll's, the famous, you know, famous... I love, I love seeing Driscoll's clam shells coming home from the grocery store. And if I'm shopping, if I'm grocery shopping myself, I usually buy- It's usually strawberries, blueberries, and raspberries that most people associate

14:06with that brand name. Yeah. Although I love their, I love their, I love their blackberries. Don't, don't knock the blackberries. Oh, sorry. I forgot about blackberries. I love the Driscoll's blackberries. But, yeah. Anyway, this is Driscoll's and, you know, yeah. The... I certainly had a, "Well, of course this happened. What were they thinking?" moment when I learned about this case, and I think that's a natural, a fairly natural response.

14:34Bravo Driscoll's for fighting this in Chinese courts, and they are winning. They have filed 23 lawsuits and they've won, I think, three so far, and have been awarded damages in those three. Now, the fas- there were a lot of fascinating facts that I, I just found really interesting about this. One is I wasn't aware that you could get a patent on DNA, but you can, and Driscoll's has patents on, on the blueberry plant DNA.

15:15I also didn't know that blueberries were propagated by clippings. So all you need is a clipping from a blueberry bush and you can go and build an entire farm from that clipping that will make blueberries just like, that are i- that are genetically identical, as it turns out, to Driscoll's berries. But then to prove this in court, you've got to conduct some industrial espionage and secure a clipping from the blueberry farm or grower that you're suing, right? So that you can prove through DNA analysis that they violated your patent rights.

15:54And, it's like, it's all a little cloak and dagger, like, you know- Yeah ... the, the industrial espionage part of this points to, points to physical risk, but of course this happened, and bravo Driscoll's for fighting it. And because Driscoll's is privately held, we don't know, because we can't review their, their, you know, SEC filings because they're a private company. We can't, we can't see if they acknowledge this as a risk. We also can't see if the massive dilution of the blueberry market that happened in China as a result of this theft led to a situation where their investment in creating that market is not paying off.

16:45We know they're making a lot less money because blueberry prices have crashed because Driscoll's was making so much money, of course people stole it and ran with it. Correct. Yes. And I think the other thing that's interesting too is that it's possible there was some data breach or theft that happened, but we won't know either because it's a private company. It would make sense if they procured some data to help- Yeah ... grow said blueberries, or information about it, because, you know, it's all well and good to make the clipping, but do you know how much fertilizer is required or whatever needs to happen with that particular blueberry clipping?

17:25So there's a lot of factors in this. There could have been a little bit of a, a cyber situation that happened. I am, I'm quite sure that the, the food defense forensics was very well extensive in its investigations as well. I'm sure that the whole team... I mean, I, you got to give it to them, the quality team is probably running crazy. There's just been a lot. I personally don't know anybody at this organization, but I definitely feel for them because this is a lot to take in. But again, this was avoidable, and that's what I think kind of ticks everybody off on the risk side of the house, is that this is... Most of the time it's an avoidable

18:01situation that people just, you know, go screaming into. And then we've got to manage it and mitigate it and survive it. And it sounds like they're doing the right things, but I wonder how much money they're going to have to spend to litigate to get out of it. But yeah, it's, it's interesting. There are companies that own patents on life, whether that's seed or species. There's companies that- ... own the rights to certain breeds of animals that we ingest, which makes it even more fascinating. And we could go down this rabbit hole some other time if anybody wants to go down there with me, because it's very fascinating the compound nature of the lack of

18:47redundancy in certain places in food and agriculture and the conglomerates that own them. So- That's... Yeah. The whole- I might need a glass of wine for that conversation, so... - The whole thing was so eye-opening. Eminently quantifiable, this would make a fascinating risk quantification case study if you could ever get hands-on and permission from Driscoll's and cooperation from Driscoll's to do it. But all of this because royalty rates are per hectare grown and all this kind of stuff, it's eminently quantifiable. It would make a fascinating case. But let's move on from blueberries to cows.

19:32And Kristin, I know this case is one that you are very familiar with. I think you... Do you open your book with it? I do. I do open my book with it because it is the first OT, the first real physical OT incident that caused loss of life. And I know people are going to want to fight me on that. Please come find me. I will meet you in the street. But this is cow death, not human death, so let's be clear on that. This is a very tragic story, so if you are fragile, just hold on a second. There was a farmer in Switzerland.

20:13He's in his 70s, so he's obviously been farming longer than he's had the connected equipment that he has now. Dairy parlors are interesting. They either are allowing the cows to go in and be milked at their leisure. They have little lasers that kind of shoot up and go to the udder and just do what they got to do. They're self-cleaning. It's super cool tech if you want to nerd out on it.

20:38Tons of YouTube videos have at it if you want something to do. This gentleman, I believe, had one that isn't automated, so it was automated in the sense that the cows went in and it took care of itself. He had to walk the cows in. So, the nice thing is, is when the ransomware hit on the system, he was still able to operate manually. However, that's all well and good, and the cows were happy that they were still getting milked because a cow could give an absolute shit. If it's got ransomware, it's got to get milked. And also, a dairy business in general is very dangerous.

21:13Cows are complicated creatures. The real problem came as he lost access to his real-time monitoring data and he didn't know, and one of the cows that was pregnant was in distress. And unfortunately, the calf passed inside her, and they had to put the mother down. So, just because the farmer decided not to pay the ransom didn't mean he didn't get screwed in the end, because he still had to pay for the vet bill and then the system wipe of the dairy parlor in order to continue running again.

21:46They never actually disclosed who did the attack, but it came in coincidence in time where nation state actors were targeting other dairies. So they're just assuming this dairy was caught up in that mix, because as David and I always say, they put their shit on the internet and they shouldn't do that. Yeah. But I'm not upset at the farmer because he was just trying to do his job. He's not a security expert.

22:15But because he didn't have a secure system, whether you want to blame the equipment provider or whoever, it resulted in a loss of life. And for a dairy farmer with a small herd of about 70 cows, one loss, especially a pregnant loss, is a big deal, and that's really frustrating. And again, you could be sitting anywhere in the world and think, "Well, I don't care about one cow and one random farm in Switzerland." This has happened in other places that haven't resulted in death yet, but it's only a matter of time before a whole herd will get wiped because of something really ridiculous like ransomware hitting the PLC on a dairy parlor.

22:57I think for me, I think... So, my spicy take on this is that it's irresponsible for a manufacturer of this equipment to be selling it without- Yes ... proper handholding and support to make sure that... I don't care that he's small. He could be a multinational corporation and still doing the same thing. You buy this stuff, you plug it in, you assume that it works, even if it comes with some sort of manual. I suspect that manual says nothing about getting it firewalled, getting it segmented, doing all of the things that needs to happen with OT and industrial control system equipment to secure it because it's fundamentally insecure. And it is a place where a cyber exploit can go directly to a safety

24:10issue as it did in this case that leads to loss of life. For me, it's a lot like, I think it's irresponsible for baby monitor manufacturers also not to do that, right? And you can find all sorts of- Secure by design is a huge problem. Yes. It's a huge problem. Yes. So- And I think- ... shame on the manufacturer. Secure by design, it's deployment by design. It's like there's... Yeah, secure by design- ... has to refer to the product in its context by its target user, right? We have to have a very, in my opinion, expansive view of secure by design.

24:53Yeah, exactly. And I think this is... And I'm not one of those people that's going to poo-poo on ag tech. I think ag tech has its place. I do think we're doing a lot of running before we crawl, unfortunately, I feel. - Yes. Ag tech is kind of in an AI boom feeling to me at the moment. Maybe some of you know this, some of you don't. But technology and agriculture, the...

25:19I read something the other day that said it will probably be the first AI native industry, and I was like, "Ugh." Like, "I don't know. I don't know how I feel about any of that." Also, AI, you can't say that in agriculture. People think it means breeding. But- - Right ... the other thing that's hard about this is, I believe even the manufacturer may or may not have even had them change the default password. I don't know that for a fact, but most farmers wouldn't know to change the default password on a system, let alone that there was one, because it might have just been logged in by whoever installed it and walked away. Right.

25:51And I think any of us who have spent time on any type of purple team or red team, we know that you can go get a manual offline and then, boom, you've got your username and password, you can log in whenever you want. Yeah. I think it might have been one of those situations, opportunists as well, because it was just available and he didn't change anything.

26:11I like to say that I hope that they at least changed the password, but if you change it to cow123, that's kind of obvious, you know what I mean? Yeah. That's something that bothers me a lot, that there's no... Why is an agricultural facility responsible for understanding cybersecurity? That is not their job. That's not their job. And it's so frustrating to me that we've gotten to a place now with the invisible stuff that we were talking about at the beginning of our talk, that we've forgotten to the point where we're not protecting the things that matter the most.

26:45And that's part of the reason why the book was written, because I got angry, so... Yeah, from a... Well, I doubt the farmer has a risk management program. I mean, right? But, yeah. But he would have a disaster recovery and he would have- Yes ... a business continuity plan, which needs to include, would include safety, right? So whether it's a fire or animal gets loose or animal injures somebody or something, there would be a plan. So the trick is to get people to add cybersecurity or cyber physical, in this case- Yeah ... into that plan. Hitch it to something they already have- Right ... as I like to say. Let's look at another one. This one's also food and ag.

27:36I promise you all five of them aren't. We're going to move out of food and ag next. But this is United Natural Foods, or UNFI, as it's frequently referred to in the press. Talk about invisible. This is like distribution is invisible. This- But it's one of those things- ... mystical ... that if you get the Jenga peg to bump out or even just move over a little bit to the left or right, it's all coming down. And I think we all learned that lesson with CrowdStrike and Microsoft. Thanks, guys, by the way. Yeah. This is very similar. When distribution fails, it causes such a tumble effect, but it affects regionally first and then branches out. And that's something that is hard because regionally,

28:29I think that's where we struggle with our food system. We're not that robust anywhere, any country. And I'm not just saying the United States, I'm saying everybody has got the same problem. Regionally, it's very hard to control supply chain, and then when you cross borders, it's even worse. So, this happened actually last year, and most people didn't recognize that it happened unless you went into your local Whole Foods or tried to order food off of Amazon, like Amazon Fresh, because it was there wasn't really anything in the freezer and there really wasn't anything in the bakery area, because most of the stuff that comes into the bakeries is frozen. Fun fact, if you didn't know that. It's not actually fresh.

29:11- So, and it's- Oh. Yeah, I know. Sorry. I'm here for all the horrible food things you don't want to know. I've also seen a lot of it manufactured, so I can tell you what's... Yeah. Anyways, but I will say that I think most people didn't really feel it because they just were like, "Well, I'll just go to a different store."

29:33And they grumbled about having to go to a different store, but otherwise they got what they needed and it didn't matter. But I saw a few people online that were complaining about it from, let's say, security community. Like, "I can't believe that this company didn't know this could happen, and then I can't get my mother's gluten-free birthday cake." And my first thought in my head was, "Wow, what a privileged person you are. Why don't you just go make your gluten-free cake or go somewhere else?"

29:56It's not that serious in that regard. But it did get people to wake up that even a company like Amazon and Whole Foods can be attacked, which is very silly because everybody gets attacked. And so- Yeah ... but the other problem is a lot of this food was frozen, thankfully, so it wasn't that it would have to be dumped or destroyed in any regard. So a lot of it could just be held back at the facilities. But imagine if this was fresh food, then we have a problem.

30:28And that becomes very complicated on how you're supposed to deal with it. And I know there's business continuity plans for that and things like that, but that's a huge risk because now you've got a food safety potential problem. And I know everybody's feeling this in the United States. We're very grateful we're now been blessed with no more cyclospora issues, and our food recalls seem to be okay at the moment.

30:50I don't think anybody wants any more potential concern about their food. And yeah. I still can't eat lettuce in a big chain restaurant. I'll eat a salad in a mom and pop restaurant, but not a big chain. I'm done. I'm done with lettuce, done with bagged salad mixes. No more. No más. No más. But- You can do greenhouse lettuce, David. You can do greenhouse lettuce. I could. It's one of the things I loved about the blueberry story is that all of those precious blueberries in China, billions of dollars worth, are grown in greenhouses, not even in soil, in coconut husks- Yeah ... with a fully automated watering system and lighting system and high-tech

31:42gardening, for sure. Yeah. So this was ransomware- Yes ... right? And this is a large multinational company with 53 distribution centers servicing- I think it's the second-largest in the country, I think. Yeah. Tens of thousands of retailers and military bases. They should have a risk management program, unlike the farmer in Switzerland.

32:19And so what are the key OT risk management takeaways here? - I think one of the big ones is when something happens in your food or agricultural environment or any industrial environment, once the compromise happens, can you verify that your product is safe? If you cannot, then it has to go. And I think that's the thing that scares me is someone's going to have to make that decision. Who makes that decision? How does it get made, and how do you determine it? Because you have to basically... You can't trust any of the data from the sensors that's coming off the lines then, or any type of distribution count. Your ERP system might be compromised. There's a

33:07lot of questions here, like can we believe the data we are seeing? So a lot of it has to be, can we convert over to analog processes immediately and then start counting by hand? And that's usually what ends up happening. I was speaking with, and just to get off this subject for one moment, I was speaking with the CEO of a very predominant fish company recently.

33:29They sell sushi-grade fish across the world, and they were hit with a ransomware attack. And he was telling me that it actually happened three times, and they were able to continue selling fish, but they did it all manually. His team and his people were what saved him. And it's a very large company, so the fact that they could do the dance of change really quickly and resilience was amazing.

33:52It can be done, but you have to be coordinated, practiced, and ready. And I think a lot of the times, especially in these larger organizations, they have such turnover of their staff that there's no way that they're going to probably be able to have- Right ... full preparedness. But I do think that this particular incident was handled fairly well because, number one, it didn't get messy in the news. That's always helpful. Two, it seems like they had it under control, where it was a couple days, then everything kind of going back to normal. But also, nobody got hurt, thankfully, that we're aware of, because it would have been filed, because they're publicly traded. We would have known.

34:32And there really wasn't a big deal. The brand image wasn't destroyed. Is everybody still shopping at Whole Foods? Everybody still shopping at Amazon? There's no problems. Yeah. So really, this ended up being just a blip. But the problem is, is what happens when these blips become more blip, blip, blip, blip, blip? And that's what's going to happen, and it has happened.

34:53Or what if they get hit again? Because historically, we all know that when you've been punched once, you're going to be punched again because- Yeah ... people hold. The blip drip. - Yeah. Yes. Blip drip. That sounds like a band name. Blip Drip. Yes. My spicy take on this is that we're still failing from a risk management perspective at analyzing the dependence of the OT side of the house on information technology systems. And I think most large enterprises would find the task impossible if they were asked to completely sever the network connectivity between IT and OT, or if they were asked to continue operating the OT estate without the IT estate. I think most organizations of any size today would fail because they haven't

36:07done a full analysis of the dependencies, and it's surprising, right? Yeah. And it's also really even more surprising is when... I don't know if anyone on this particular call who are listening later on has ever done an ERP install, but you have to do all that dependency work. You have to go through all of it, down to the silliest thing, like the printer in the closet that you never see come on except for once a quarter.

36:37All those dependencies have to be mapped. And if they haven't a modern ERP system, which most of these places do, you would assume at some point, David, they would have had at least a baseline to work from, right? Right. And to me, that baseline should have been every quarter looked at again or something, whatever the cadence would be.

37:00I did see a question that came up in the chat, would a loss event be measured perhaps with vendors moving their products to other suppliers? The problem is, is third-party contracts may not have allowed them to do that. They could have, depending on what would happen, or if there was a redundancy plan set into place for part of their business continuity. But even then, because they had a cyberattack, the third parties could have been like, "No, I'm not touching you. I'm not going near you," because they didn't want to be held liable- Yeah ... for any part of it.

37:36And that's unfortunately a side effect of business, especially in risk, is if you see something that's messy, you're not going to go over and step in it necessarily, right? Right. And I think that that is probably why they weren't really allowed to use additional suppliers on a third-party aspect. Now, that doesn't mean it didn't happen. I'm not 100% sure, but that would be my understanding is that they probably would have not.

38:01Yeah. Let's look at case number four, which is one that's going to be very familiar, and for those of you who've been with us all day, Matthias and Markus- from the UK. - Matthias and Markus talked about this in their session this morning. I think the Jaguar Land Rover ransomware incident made very loud sounds on the news earlier this year, and- I put my little blue sweater because we're talking about it. Yeah. Fantastic.

38:44Five weeks of stopped production. Mm-hmm. Um- They stopped it, though. They stopped- Yes. They stopped it. It wasn't the ransomware that stopped it. They stopped it. Well, same thing with UNFI. Correct. UNFI stopped rolling trucks. The ransomware didn't stop the trucks. UNFI did. Because they could not guarantee- The ransomware didn't stop production ... the safety of the workers. Yes. Yeah.

39:07And so, here again, we see the OT dependence on IT coming into play. And I think for me, there are... Oof. Yeah. There's a lot to unpack. There are a couple of... There's a lot to unpack here, and I think this case will be unpacked for years to come. Jaguar Land Rover- And politically, too. Someone will get their dissertation on this one.

39:42Yes. Oh, yes. You're right. You're right. That's a great idea, actually. - Fascinating case on multiple levels of abstraction, because JLR is owned by Tata, the Indian company. And Tata also owns, what's the other- Air India. Air India, and they have an IT outsourcing firm. Yeah. What's it called? They have a consulting arm. They have a - Yeah, Tata con- yeah, TCS. They also make cars, Tata cars. Yeah. Yeah. Vehicles.

40:21And JLR had outsourced their IT management to Tata Consultancy Services, TCS. Mm-hmm. So, and someone from TCS was in one of the Tata seats on JLR's board. Yep. So at the board level, this certainly has the appearance of conflict of interest. And I think that's, from a risk management perspective, that's a specter that should have been adjudicated early on with greater care than I think anything that I've read about it seems to indicate that it was.

41:14As Matthias pointed out this morning, the British government stepped in with a one and a half billion pound emergency loan to keep things going, and especially with respect to the thousands of suppliers that were dependent on JLR for revenue, and to keep those suppliers in business. So, this was an event that caused measurable harm to the UK economy.

41:56Yes, and the people that work around those and in those factories, because five weeks of stopped production- Yeah ... means five weeks of not working. Yeah. You look at- I mean, that's not paid vacation. That they just didn't work. Right. And- It's interesting too, David, because Tata bought Jaguar Land Rover from Ford in 2008, and they had it for a while, right? Obviously, what is it, 17 years, something like that? And it's interesting to me that now this is starting to happen.

42:30Didn't you do a risk management process of some sort with your merger and acquisition? I mean, I don't know if anybody survived those, but those are really messy too and uncomfortable. But you usually get down to skeletons in the closet and kicking doors open when that happens. Why wasn't there more- Yeah ... due diligence in that? And you could have your speculations on why it wasn't or what it was, but that was also years ago before they probably really digitally transformed over the last 17 years. So it's possible that- They kind of did it to themselves in a way. I'm not going to point fingers here, but it's definitely screaming from a risk

43:17management brain, there's just too many things that don't make sense. Yeah. So, what are we doing? I guess that's more my spicy take of maybe you guys have known better? Right. You know? Well, okay. Yeah. Look, I felt so much compassion and still feel a great deal of compassion for the harm that was done to them financially. 154,000 employees, UK citizens, are employed by Jaguar Land Rover or in the supply chain. And those are the people who were out of work.

44:01Those are the people who suffered most here, because 196 million pound loss to JLR is nothing. A 1.9 billion pound loss to the UK economy is measurable in GDP terms. And Bank of England attributed a decline in GDP for the quarter to this event. Now, keep that in mind. One company, one event, measurable impact on national economy.

44:47And the UK has critical national infrastructure, cybersecurity regulation. Yep. But JLR is not named as critical national infrastructure. So, the UK government, from a risk management perspective, parliament whiffed this, because they wrote legislation that doesn't even apply to a company that, if they're down for five weeks, has a measurable effect on the UK economy.

45:23That's a governance miss and a risk management risk at national scale. That's my spicy take. I mean, it's the same thing with JBS when that happened. When JBS's ransomware happened, which affected the United States, Canada, and Australia primarily, the United States couldn't price beef for one full day. That's how much it messed them up. And it's the same vibes to me.

45:50Absolutely the same vibes. And now they're also releasing, what, 4,000 employees are about to go from the company. They're just white-collar, not blue-collar, so they're not releasing the plant workers, but the office is being cleaned now, essentially. Mm-hmm. Which we all know after a certain period of a breach, they tend to make staffing changes. So now you're going to have more hardship on people because of this incident, legitimately. It's devastating when this stuff happens, because it affects the community, and that's really what you're getting at, David.

46:25Yeah. Is when these happen, it's an acute attack on the community. They deal with it first, whether it's a food safety incident, like at Boar's Head in Southern Virginia, or the Peanut Corporation of America. Feel free to look that up. It's really gross. Or any of the other situations that are happening around, whether it's food safety or it's a cyberattack. Everything is an acute problem community-wide, and then it blooms from there.

46:54We don't want it to bloom, but it usually does. Yeah. We don't want it to bloom. Yeah. And you're right, David, because Land Rover, Range Rover, those are standard British stereotype vehicles you see, right? Yeah. Every movie you watch, the bad guys are driving Range Rovers. They're usually black and they're usually tinted, right? We know this.

47:14The Queen even drove her Range Rover until she, rest her soul, passed. God rest her soul. Yes. I know. So it's part of British culture, and you would think that they would class this as a little bit differently. Yeah, but- I mean- ... not CNI. Yeah, it's strange to me because, again, anything that affects economy, should that be part of critical infrastructure? I mean, you could do a whole dissertation on that. Right. That is such an interesting... Actually, that is a super interesting topic. I would love to actually dig into that.

47:46So another spicy take on this was made by The New York Times. And a New York Times investigation reveals that there was no ransom demand in this ransomware attack. So, was it really ransomware? No. It was the encryption of data by a threat actor, but without a ransom demand, is it ransomware? Methinks not. And so, The New York Times- And the ransom, so yeah.

48:24Yeah. You can't call it ransomware. This was data encryption by a nefarious third party, right? I guess you just call it a cyber incident? Yeah. - I mean... So I think it's a misnomer to call this ransomware if The New York Times article is true, and New York Times does really thorough investigations, so I believe it's a trustworthy source.

48:49The New York Times article suggested that this was an attack by Russian-affiliated actors that were demonstrating the capability to arm a national economy as a form of attack. And so- The New York Times alleges- ... that before. ... that this was an attack on the British economy, not an attack on JLR, uh, that w- that was perpetrated through an attack. They were the, they were the avenue, not the target, right?

49:25Um- Okay ... very interesting- Long and the short of it- ... sort of risk management perspective ... they probably were just upset that they were helping Ukraine, and Russia wanted- Yeah ... to remind them who's in charge, just like how they- Yeah ... do the flyover still occasionally. Yeah. Yeah, no- Yeah ... I get it. I- Yeah. So silly. Like, it's- Yeah ... when you start to think about it from the petty level, you're like, "Why?" It's like walking up to someone on the playground when you were a kid and pushing them, right? Yeah. Like, "I don't like you." It, it 100%, 100% bully, bully tactic.

49:58Um- Yes ... let's look at case number five. We're, we're headed to the top of the hour very quickly here. Um, very recent, just a few months ago, more than 100 water utilities in the US were targeted in a campaign that, um, attacked internet-exposed programmable logic controllers, PLCs, programmable logic controllers. Um, and the attackers did a whole host of things, depending upon what those controllers had ac- what those controllers were controlling, um, with a very broad spectrum of outcomes. Um, I think, uh, um...

50:53Yeah. Well- I think we were disheartened by this 'cause we know a lot of people in the water sector. Um- Yes ... and we also know how hard they've been working and trying to get regulations and a voice, um, in different places. And they were warning that something like this was going to happen, and, and thankfully this ended up not being, um- Yeah ... super... I mean, it was awful, but it wasn't, you know, the worst, I guess is what I'll say. Um- Yeah ... and that, that made my heart hurt 'cause I love, I love my water sector people. I mean, I'm adjacent- Yeah ... to you guys. So, like, I, I feel for this. Um- Yeah ... and, uh, it could've been so much

51:32worse, but thankfully it wasn't. There are 153,000 water utilities in the United States, many of them small- Yeah ... and under-resourced and, you know, the, the, the guy responsible for cybersecurity is also the guy who mows the lawn on Wednesdays and answers, um, you know, customer calls on other days and, um, you know, maintains the, the shed housing the pump equipment and pump gear and, and, and, and, and is completely dependent for system upgrades on third parties, right? Yeah. Um, that's the picture of this sector, so it's no surprise that they have internet-connected stuff that shouldn't be. Like, so- Sure ... one spicy take on this would be to say, "Get your

52:33stuff off the internet," right? And that's a valid spicy take, but these are people like the farmer that don't know any better and are depending on third-party system integrators to come in and do this for them. So I think actually this raises a huge, um, liability risk for all of the third-party system integrators who had done work for these 100 utilities. Yeah.

53:04I wouldn't wanna be one of them right now. Yeah, they should be liable. To me, they should be liable. They should be liable. And will they be liable? We don't know. Well, I certainly hope that some of these water utilities are, um, filing suits, um, against their system integrators. Um, now, another spicy take here is that, you know, in Coweta, in Coweta County, Georgia, which is very near where I live here in Atlanta, um, the CEO of the water authority said, "Look, yeah, we had...

53:40They changed our passwords, they tried to turn valves, but we didn't report it because there were no incidents." And so, because they didn't lose water pressure, they didn't lose water service, they didn't contaminate the water, and that's what they're saying would constitute an incident, a water incident, not a cybersecurity incident. And so there's, like, there's a mis- Yeah, but wouldn't a cyber incident potentially cause a water incident? So- Yes, but there wasn't a water incident, so it's saying there's no in- there's, oh, there's no incident here 'cause- There- ... it's, it's kind of a, it's, it's a little bit of a weird dance. And, um,

54:28the oth- the other weird dance is concurrent with all of this in Clayton County, Georgia, which is, which is, you know, uh, part of the city of Atlanta where I live is in Clayton County. Um, there was the failure of a pump station at 1:00 a.m. because of, um, unusual activity on the PLC, and that led to, um, a, uh, reduction of pressure below the point that a boil water, um, notice, um, advisory was, was required for 300,000, uh, for a little more than 300,000 utility customers. That's a big one. That's a lot. Um, but Clayton County has not- ... publicly, has not yet publicly admitted that it was a cyber incident. But same pattern as all of these other utilities saw in the same timeline

55:31that all those other utilities saw it. So, I sure suspect that it was. Look- You know what's interesting, David? You just made me think when you were talking about that. I live in Northern Virginia, which is data center alley, legit. I can't throw a stone and not hit one. And there's a lot of reclaimed water going into these data centers from the utilities.

55:57Granted, they sell it, so obviously the water utilities around here are a little bit well off, if you will. But what's interesting is, what if someone's pissed off about whatever or wants to make a move on a data center, and they want to attack the water treatment facility that is supplying the reclaimed water to go through the data center to keep it cool?

56:19That's what I get worried about, because now you've got water issues potentially that could take out customers all over the place. You have safety issues like crazy from something like that. And on top of that, you're going to have major issues if a certain cloud gets taken down. Let's say it's connected to a hospital or at a school or whatever, anything that's dangerous or that is affecting life.

56:44What if it's the cloud center that connected to the traffic light system? I mean, it could be anything. So, when I start thinking about people poking and prodding on these water sector areas in various different places, I start thinking about the services that we are all become accustomed to in the invisible modern world we live in, where we have to have physical processes that are powering our modern digital world. And if that gets popped, we're in big trouble, like so many different ways.

57:17Yeah. And all of this goes back to my invisibility beef, right? Yeah. This is all covered in an invisibility cloak for all of us, except a few of us who are paying attention to what's happening in the water sector and have been for years. But as a society, we take all of this for granted. And for people in risk management who might be listening, I encourage you to consider water as part of your supply chain because you can't have your facilities open without it, and it's unlikely that you have an alternative supply.

58:07It's unlikely that you have a well of drinking water that you can just happen to turn on as a backup, like you might have backup generation power. It's very unlikely you have backup water sources. And so, this is a risk to all of us that is difficult to manage, but should be at least on our radar. And- I also think that reporting to... And I think reporting to, going back to your invisible bit, David, I think reporting, I really would like to see people talking more about strange events that happen in their corporations, right? And I realize that lawyers are probably cringing, and anybody who's a privacy lawyer on here might be cringing as well.

58:51Yes. I do apologize for your cringe. However, we need to start normalizing this because it is normal. It is normal- Yes ... to have to talk about this. It is also normal when a company has been through this and not to share best practices across. And the fact that you are not required by law to report unless you are a public entity under SEC guidelines- And- ... then we won't know. We won't know.

59:18And only then if it's material, if it passes the materiality- Correct ... threshold, right? Exactly. Yes. And so, I think, look, in the same way that after the US started having data breach disclosure laws, it looked like the US was the leading economy for data breaches around the world, but that was because we had disclosure laws, right? I think we need more disclosure laws. That's my personal opinion on this. Yeah. No, we do. We absolutely do. I actually was just talking to a reporter the other day that was saying, "I don't understand why we don't talk to each other."

59:54Yeah. And I just said, "Lawyers," immediately. Of course. He understood, but he's like, "Why don't we have more conversations that are outside of the pay-to-plays? Why don't we talk more- Yeah, backwards ... around things?" I said, "Well, we do talk at the bar." Yeah. "So we need the bar to go a little further." The bar where they serve drinks, not the bar where they- Yeah, not the bar- ... annoy lawyers ... where they have the little gavel. No, not that one. - So, we have two minutes left, and I see Astrid has joined. Hi, Astrid.

1:00:26So, if we look at what we measure and what happened, these cases are all over the map, which again points to invisibility, lack of reporting requirements, lack of disclosure requirements, inconsistency across the spectrum of the OT landscape for what we learn about, what we hear about, and what gets measured in an event.

1:00:57Yep. It's like the perfect slide. Yeah. And with that, Kristin, thank you for joining me- Well, thank you for having me, David ... for this spicy conversation. Nice talking about spicy things. - Yeah. - And I- Hey, can I ask one quick question on the transparency front? Absolutely, yeah. So, I live in Minnesota. We had 30 utilities that were knocked down as a result of this incident event you were talking about. And as a city of Minneapolis, Hennepin County was one of those. And so, I have been trying to get a response from anybody on what happened and what's going on to address this, right? And I cannot tell you the amount of frustration that I felt, the number of

1:01:47people I've reached out to, to try and get some kind of insight on this. So, I just want to second, and third, and fourth, and fifth, and sixth your notion that transparency on this would do us all a lot of good. So, appreciate you raising the issues. How do you learn if nobody talks to you about it? I mean, it's like childhood, right? Like, we learn by doing. Get on the bike, fall off it.

1:02:11You know what I mean? Like, you have to learn. And if you don't share that knowledge, to me, it's not helping the rest of the world. You're being selfish in a way. So, and I understand, again, lawyers and legal and all that other stuff, but we have to be able to talk to each other and share risks and best practices. I would like to have clean drinking water. I'm sure everybody else would.

1:02:34Yeah. Sorry, Kristin, didn't mean to talk over you. I'm done, David. Go for it. Andrew, I completely agree with you on the transparency front because most water utilities depend on third-party system integrators to install the kind of equipment that was internet-exposed in these 100 cases. I suspect that- Yeah ... if one did an analysis of the 30-something water utilities in your neck of the woods that were hit, you might find a common nexus, like a system integrator who had done work at all 30 of those on precisely these devices.

1:03:23And that's where I think liability should rest here, but we need more transparency, 100%. Not to get all legalistic, but as a citizen, I would want that kind of disclosure. Agreed. So, go to your water authority board meeting and ask some tough questions. Give them the business. Yeah. And with that spicy take, I stand down and yield to you and Astrid. Kristin, thank you.

1:03:55Andrew, take it away. Certainly.

0:06Astrid, how are you today? I am well. I'm feeling much better, thank you. How are you? That is good to hear. That is good to hear, indeed. Well, we had kind of an introduction to ERQI, then we went into enterprise, the evolution of enterprise risk management, and then we went down into AI governance, and then the world of GRC engineering, and then food security and OT-related security issues.

0:31And now we are sending back up, in my mind, to the world of board communications and interactions. And Astrid, I apologize. I was a little lazy in not drawing up bios for everyone, so if you wouldn't mind just talking a little bit about your background, and then I will set the stage for our discussion. Sure. So hi, everyone. My name is Astrid Yee-Sobraquès, 26 years in corporate America, in financial services and banking in particular, with fine establishments such as GE Capital, AIG, PricewaterhouseCoopers, and others.

1:08My career has been in enterprise risk management, all aspect of it, from modeling to stress testing to scenario analysis, to operational risk management as well with resolution planning, for example. And of course, increasingly, cybersecurity and information security and AI, as we move into that age. And it's my great pleasure to be here today and share some of my experience about risk with all of you. Thank you. So, I am excited for what one person called a let's get real conversation about how to contend with the board when you are approaching them, when things don't go exactly to plan.

1:58There are elements to being successful that I have learned from you, so thank you already, in the short time I've known you. But then discussing risk versus strategy versus concentration risk, and how do you assist people with making informed decisions? And so, I know that that is near and dear to your heart, and so that's kind of the basis for our conversation. So, as a kickoff, I'm just going to start down this path. Strategy and risk is the same conversation?

2:31Can you give us a concrete example of what that looks like when it goes wrong? Yeah. If there's another place to start, feel free. You know how I am. I'm just kind of - unique. Yeah. Yeah. So, I mean, that's a great place to start, Andrew. I actually think that the most important board conversation often doesn't happen at all.

2:52And why do I say this? I often hear board directors say, "We want to focus on strategy, not risk management. Risk management is something that we delegate to our risk management committee of the board." And every single time, I think to myself, "Do you realize that these are not separate things at all?" Right? - Serious. Rhetorical question evidently.

3:16So every strategic decision embeds a risk assumption, right? And so the board can either make that assumption consciously, or it can happen without the board realizing it. And so, what do I mean by that? And what I love to do is examine case studies to illustrate the points. If we think back on UnitedHealthcare and Change Healthcare, that sort of one acquiring the other in 2021 for roughly 13 billion dollars, that was one of the most scrutinized M&A deal in healthcare history.

3:57And they fought a massive antitrust battle to close it. Due diligence presumably was thorough. They did financial analysis, competitive analysis. They certainly had to scrutinize the regulatory landscape, and yet something was not thoroughly scrutinized. And what was that? It was Change Healthcare's security posture. So, I don't know if everybody's familiar with the details, so let me speak a little bit about that.

4:26Change Healthcare had a policy on the books about multi-factor authentication, that MFA should have been placed on all external-facing systems. But there was one server, a Citrix portal, that was unencrypted, and it was sitting out there, not compliant with that policy. And critically, the head of cybersecurity knew about that, and nothing was done about it.

4:50Now, you fast-forward to February 2024, and the ransomware attack was launched successfully. One might say it was a predictable consequence of a known gap that had not been addressed, and the rest is history. A risk cascade happened. Change Healthcare went down. Because they were handling healthcare payments nationally, the payment systems failed across the country.

5:15Hospitals couldn't process claims. Pharmacies could not fill prescriptions. Small providers started to fail, facing insolvency. And so UnitedHealth had to inject approximately 6 billion dollars in emergency funds just to stabilize things, right? Management was invited to testify in front of Congress. The company faced all manners of regulatory investigations.

5:43So, here's the question for that board. When they approved that 13 billion dollars acquisition, what risk appetite decision were they actually making? Right. Were they consciously saying, "We will accept the risk of integrating legacy infrastructure with known security gaps because the strategic value is worth it?" Yeah.

6:05Or did the decision just happen? Well, that's interesting. So the board, for example, thought they were buying a revenue asset, right? And that may have been the totality of the conversation. Just as a quick side note, I've been talking to the people in the work in mergers and acquisition. I've always been curious, why isn't there this significant effort, right, on doing due diligence around security posture? And the simple answer was, "That slows the deal down, so we don't want to do that." So anyway, just an interesting anecdote there.

6:40But to my point, the board thought they were buying a revenue asset, but they didn't realize as well, as you're pointing out, that they were inheriting a significant infrastructure liability and risk. How common do you think that is, where there's a split between what the board thinks it's deciding on and what they actually decided?

6:58So it's more common than people think or hope for. And I think the little bit of intel that you shared with us is actually quite revealing on that front. - So that was not unique to United Health, in other words, right? And perhaps it's helpful here to talk a little bit about risk appetite and how it works- Right ... for organizations, because I think there's a massive disconnect between intent and reality. Once a year, the board approves risk appetite in the form of a statement. It's a formal document, perhaps somewhat abstract and often disconnected from real decisions that we have to make on a daily basis. And then what?

7:40So every single day, real risk appetite decisions have to be made. The board doesn't see them and perhaps something like that happens. Your organization is using a single payment processor, say, right? And you're consolidating from 15 vendors down to three, and that's a big cost savings for the company. Procurement is pushing it, operation wants it, finance loves it, but what happens in the background?

8:12So risk should be saying, "If this vendor fails, we'll lose 40% of our payment capacity. If it goes down and within 48 hours or for 48 hours, we lose X in revenue. That's our tail exposure." Legal would be saying, "Well, a contract limits our liability. From a legal perspective, we're protecting." And compliance might be saying, "Well, they're meeting SLA requirements, audit checks pass. We're good." Nobody's lying from their perspective, but they're answering different questions.

8:45And the board is often not in the room when that conversation happens and when this gets resolved, quote marks. So it'll be oftentimes someone in finance and operations saying, "Okay, we need this cost savings to hit our margin targets. We move forward." That's it. Decision made. Okay? Mm-hmm. But here's the thing. That decision was a risk appetite decision. The organization just accepted to take on massive vendor concentration because the efficiency benefit was worth it.

9:21Mm. So the board approved the cost savings. Did they really explicitly approve the vendor concentration? I think not. Mm. And this happens often. M&A decisions that embed infrastructure risk, for example, UnitedHealth. You have technology investments that embed third-party dependencies very often. Vendor selections embed concentrations and regulatory risk as well.

9:50So the pattern is often the same, to not say always, right? Risk, legal, and compliance will answer different questions about the same decision, but these answers are not integrated. The board doesn't see the trade-off. It just gets told or informed, right, of the path that was chosen forward. And oftentimes, that's the cost-effective option, that one by default. That's not really governance. That's outsourcing the board's job to whichever function has the loudest voice. Yeah, it's interesting, because nobody's really escalating the kind of governance notion that there is a connection that needs to be made, right, between the reality of saying, "Look,

10:38strategically speaking, we're going to have X amount of savings as a result of this activity." But because that risk concentration doesn't get elevated, right, they remain as these kind of separate pools of discussion. And just curious, what's your opinion on the board's responsibility to dive into that level of detail versus the executive's responsibility to make those connections? Is it a shared responsibility?

11:04What's the guidance that you would provide if you were advising someone along those lines? The board provides oversight. They should have visibility into these things. It's often kicked down the ranks with the expectation of you guys working out together. Yeah. Yeah. As if it was a disagreement to be managed as opposed to being a risk management decision or risk appetite decision. And I think that's a mistake.

11:32So- So- Yeah? No, I was going to say, so the concentration is approved by default is what we're saying, ultimately, right? And through the path of least resistance, which many business decisions are made that way, as we well know. But, well, it brings me to this, though. You said, or maybe I should ask, so are we saying then that CFOs and COOs are saying, "I don't care about these risks," or, "Because they happen infrequently, I care less about them?" How does that actually play out? I have heard that said, yes.

12:10So- Can we generalize to every single CFO, COO? Are they that fair? I hope not. I think it's fair skepticism, especially in the environment that we're in, the climate that we're in with the administration, though. There is a pull away from the discipline that we spent 30 years building in risk management, and that's a disappointment. So, they're not wrong either, right? From a certain point of view.

12:39Sure. The probability is usually low of something really awry going on. But that's precisely where it gets expensive. And so when I hear CFOs and COOs say, "Well, it doesn't happen annually. We need efficiency now. Show me what it costs, and then I'll reconsider." Oftentimes, it's not going to get reconsidered anyway. And then it's big, something big happens, and everybody's looking at each other and thinking, "Hmm, okay."

13:06So, if we examine... Again, I like to get back to real business cases because that's when people kind of hit the- Yeah, please ... the light bulb moment. CrowdStrike in July 2024. Concentration was known here, right? CrowdStrike was a market leader, or is a market leader in endpoint detection and response. They're best in breed.

13:34Organization chose them for that reason. But when CrowdStrike pushed that faulty software update to 8.5 million systems globally in that fateful summer, what happened was Delta grounded 900 flights, hospitals shuttered operating rooms, banks couldn't process transactions, telco networks went down, and all that cost over 5 billion dollars in direct losses. So, organizations running CrowdStrike knew they were concentrated on CrowdStrike.

14:11They thought the odds were low, and maybe they were, but then what? Did they have a backup strategy? The question for the board would have been this, or is this, "You made a conscious choice to accept that vendor concentration, but did you ever ask, 'If CrowdStrike goes down, how fast can we recover? What's our backup plan?'" And I think most organizations didn't ask that question because they thought it wouldn't happen.

14:41Agreed. And I think you know this, and probably everybody in the room as well, but that is the biggest hurdle we face as risk managers when we bring numbers to executives in the C-suite or the board, is the, "I don't buy the number. I don't believe it." Right? So establishing that credibility and why it matters, I think is game-changing.

15:08If I could, one other quick anecdote. Back in my earlier life professionally, I worked at a security company, Symantec, and was involved in the rollout to a Fortune 20 company of 300,000 endpoints. And things were going fairly well until we worked on rolling this out to the executive building of this organization. And we, to use a phrase of old, blue screen of death about 400 executives at that organization.

15:43And the reality of why it occurred was not very too dissimilar to what happened with CrowdStrike. So, I share that because people are like, "Oh, this thing, CrowdStrike didn't see it coming," right? I'm a CrowdStrike advocate, by the way, but, "They couldn't have known this was going to happen." I'm like, "If you work in endpoint security, then you know that this is a significant risk."

16:03And I say that to you because it highlights your point, right? The single point of failure for every endpoint in your organization is significant. I remember very specifically talking to a CISO who said to me, "Look, I have three different endpoint security vendors. We're not buying any more of your Symantec products." And I was like, "That's silly. You have three consoles. You have all this management that you have to put up with." But really, it was a smart decision, and the way they broke it down was they had servers on one platform, endpoint on another platform, and then they had their most critical systems on yet another platform, right? So that no single vendor could take them down. And so, there are

16:41ways to think about how to address concentration risk and these technology issues. So, thanks for bringing that up, Astrid, and being patient with my side anecdotes. You're most welcome. So the math for this, right, for most people was probably low probability, right? And so, we're just going to accept it. I think one of the things that I've seen you write about and talk about is how sometimes acceptance happens in silence, right? It happens kind of in this void because it never gets brought up. And is there any way to solve for that? I mean, what can be done to help reduce these kinds of risks that are accepted in silence, right, or not raised? Is there anything we can be doing there specifically, do you think?

17:41Yes, you need to force the conversation, and do so in an environmentally friendly way. So, if I may, I'd like to, before I talk about the mechanics of doing that- Yeah, please ... I'd like to give some examples. So, as I mentioned earlier, the play for efficiency is not necessarily wrong, economically speaking, but the problem is that the question isn't asked, right?

18:11And so- The question is this, right? If concentration fails us, how fast can we unwind it? And I keep coming back to a mortgage servicer that I have dealt with not long ago. They were processing millions of dollars in monthly transactions for a bank, and that vendor got hit repeatedly with severe regulatory violations, the kinds that can shut you down. And certainly, the bank had to grapple with the eventual necessity or perspective of an exit.

18:52You can't move that volume of transactions that fast from a third party- No way, no how. Yes ... in-house when you've disbanded the capability, right? There's a reason you go to a third party. You don't have your manual process, you don't have a backup vendor, and now you're stuck managing a vendor that you cannot really trust, whose regulatory risk is contagious, and that he can't endure like that indefinitely. So, the cost of the exit was prohibitive, and that's a real problem. And the board at that time really didn't ask if we needed, when the decision was made to go with that vendor, if we needed to exit because they failed, because of regulatory violations and whatnot. What does that look like? Can we do it in 90

19:39days? Probably not. 180 days? What cost, right? And so if the answer is we don't know or we can't, and that's information the board is not aware of and not made aware of at the time, then what have they really decided at the time when they signed off on the 40% efficiency savings? Mm-hmm. Yeah? Yeah. I wager, I contend that most organizations don't have that information, and the decision to accept the concentration happens without a documented backup strategy or exit strategy, as I like to think of it. And that's where the governance failure sits. Governance failure is not to make a wrong decision.

20:24Right. It's to make a decision that was not fully informed, and I say fully, carefully, because obviously there's no such thing as perfect information. But so, these are questions that we should know to ask. Yes, certainly so. And I think something you mentioned earlier around risk appetite comes into play here, right? I mean, there was a conference I was at not long ago, and this was all large financial services organizations, and there was a session on third-party risk. And I said, "Can anybody raise their hand who has a risk appetite statement for when they decide that the risk with a particular vendor is too high?"

21:03And one of 30 people, right? And then I asked, "Okay, now again, how many of you have thought through and who the alternate supplier would be? Like, for these major ones, do you have an alternate supplier, and do you know what it would take to make that transition?" To your point, Astrid, because the time that it can take, depending on the criticality of the function, right, as we've seen play out in some of the scenarios mentioned today, can be tremendous, right? So, yeah, please.

21:35So just to circle back to the question that you were asking, how do we change it? Yeah, yeah. And I was saying we need to force the conversation. I'm going to give you an example that dwells on risk, legal, and compliance, but you could easily extend it to CISO or CIO. Mm-hmm. So, my answer is not about adding more people or committees, as some organizations like to do sometimes. You don't need to do that to make the integration happen.

22:11You do it at the moment that the decision is made. So, as the first one, right, you have to identify the concentration decisions early. So when operations and procurement brings forward a vendor consolidation or concentration decision, the board needs to know it's a concentration decision as well as maybe an efficiency one.

22:31And risk management should be explicit to say, "This decision moves us to 40% concentration with this vendor, making the 40% up." That's the trigger, right? We set a threshold. Mm-hmm. As a second step, then we need to force the alignment between risk, legal, and compliance in the conversation. Before the board approves that cost savings, the three functions need to answer questions. So risk management should say or ask, "What is our tail exposure? If this vendor fails for 48 hours, 72 hours, what could recovery look like?"

23:07Legal should be asking, "What's our liability exposure under the contract? What happens if they violated a regulation? Could this come over to us?" The answer is not no, by the way. Compliance should be asking, "What are the regulatory dependencies? If they go down, are we in violation?" And sometimes, and oftentimes, the answer is going to be yes. At least in financial services, that tends to be the case. That conversation is not intended to produce an agreement. It's intended to produce clarity so that we know when we get in front of the board that a 48-hour outage is going to cost us 40 million dollars in lost revenue plus reputational damage,

23:52that the contract limits our recovery to direct cost only, so we're not going to recover anything on lost revenue, certainly not reputational damage. Compliance will say, "Yes, we miss our SLA obligations to customers within 24 hours," which is bad. And that's information that the board needs when they make the decision, not abstract risk appetite terms, but concrete business impact terms.

24:20And then this is step three. You need to document the exit strategy or the backup strategy, as the case may be. So, at the same time as the board approves the concentration, they need to approve the documented backup or exit strategy. It's not a theoretical conversation, something specific. If vendor X fails, here is how we exit, here's how we back up. We have a secondary processing standing by. It costs X.

24:45We have a manual process that can handle a certain percentage of the volume of the transactions, or we have a relationship with an alternative vendor that can take 40% or 50% of our volume for X number of days, right? And the total time to fully exit or back up is 10 days at a cost of Y. And that becomes a part of the risk appetite conversation. Specific, measurable.

25:14Now the board can make a decision. Is the 40% cost savings worth the concentration risk, provided we can exit in 90 days if we need to? That's risk management, and that's a governance decision. And then because we like to do things well, there's a fourth step, which is to monitor and update, right? But of course. But of course. Is your exit strategy still valid 12 months from now, 24 months from now? Have vendors changed? Have strategies changed, right? Have we tested the exit plan? That sort of thing.

25:46Sure. So, that's how we give the board visibility. And we don't need to be perfect. We don't need to eliminate every concentration risk. We need to be conscious about it, and we need to make sure we know what to do in a way that's actionable. Yeah, we were tossing around the word resilience earlier, right? And to me, this is one of the areas where that term really applies, but people do not necessarily think through it effectively.

26:17And I see it at the operational level, and you work much more closely- Yeah ... with boards and executives, and so clearly it's a problem up and down the ladder, so to speak, so. So for me, resilience is one of these words that's very misunderstood. It's much more than what our tech and disaster recovery partners do. It's organizational to begin with, and starting with risk appetite.

26:45Think playbook. - Think playbook. I like that. So we talked about the challenge. You were just talking about how do we fix this, right? Some of the steps that can be taken. Is there anything that you would like to see change at a macro level, right? We were talking kind of within the company, right? Is this something that you think regulation should address by any chance, or is there another answer here other than really making sure that we're getting good governance from the board and good upward-facing information?

27:27Thank you for this macrosystemic question. I love it. It's very near and dear to my heart. And of course, as risk managers, CISOs, information security, cyber people, we want to do the right thing internally. And I think we've given some pointers today on how to do that. Is it easy? No. Are you going to win every time? Probably not.

28:01But you need to continue having those conversations, raising the issues, make sure your documentation is sound and thorough. Legal might battle you on it, but one day we'll need to revisit why decisions were made, right? So, documentation is your friend, and it's certainly not an enemy of the good of a company, no matter what your legal colleagues might want to make of it.

28:29Unfortunately, it does happen that at times, companies are faced with circumstances that are less than ideal, where wrongdoing was more pervasive than we might have liked, and people get found out. And when they do get found out, scandals- ... are discussed, right? Are discussed out there. And investigations occur. Regulators have to step in, members of the public express shock and whatnot and whatnot.

29:08And I think all of these are very valid and important components of how we keep each other, for lack of a better term, accountable. But they're not the first line of defense. We are first line of defense inside the company in doing our jobs right, right? When everything else has failed, then you have your customers, your clients, your clients. You're looking at one of your suppliers undergoing going through a scandal, something that should have been avoided, and wrongdoing is being discussed or demonstrated. Well, I think that if customers walked away, that would send a strong signal to companies to up their games as well, I think, in terms of risk management discipline.

29:58Regulatory intervention is needed because they have the rule of law and the enforcement capability behind them that sometimes, unfortunately, risk or risk-adjacent functions, information security and whatnot, are not empowered to have, even though you should. Sure. The reality is it doesn't always happen that way. And then when there's obviously lawsuits, and that's the ultimate sort of thing, and it- It's important, but it's sometimes also making decisions in a way that I think is not the best from a risk management perspective. It's making decisions and then creating precedence that we have to live by as opposed to doing things perhaps a more

30:42effective way and efficient way through the risk lens, if we had a choice. So, it's really a stratum of things. Sure. It's a tiered kind of element, no question about it. It's a tiered approach that I think enforce general accountability, and that's something that's a little weak at the moment. Though when we think about... I don't know if you guys had a chance to look at Silicon Valley Bank. It's the most recent trial that I'm following with a keen eye. There's a number of different lawsuits, so it's a little bit complicated to keep your bearings. Investors are suing, you've got shareholders suing, and you have the FDIC suing. Those are looking at

31:27the same problem from different perspectives, so one outcome does not necessarily predetermine the others. But it's interesting. Executives knew of weaknesses in risk management process, and yet they approved a dividend to be paid to mother company, which boggles my mind personally. Mine as well. Management is being sued as well as board of directors, so your fiduciary duty as executives and as board of directors means something.

32:09Even if everybody's not sued left and right every day, it does happen, and they can go after you also on a personal basis. So, this notion of the corporate veil, I think, has been very convenient to protect certain actors from due accountability. That's perhaps an area to look more into from a regulatory and legal standpoint. How can we actually hold certain executives accountable and not just sue the company?

32:46Because I suspect that if that were to be the case, then people would be a lot more forceful and willful to look at certain type information instead of turning a blind eye. Interestingly, some years ago, I forget exactly, maybe 15-ish, might be a little bit more, might be a little bit less, in the UK, the PRA was looking at something like that. Holding, for example, the chief risk officer accountable for poor risk management decisions. I remember being elated at the time, but the market response was totally on the other end of the spectrum. People didn't want to be in those roles because they thought that they would be...

33:27They didn't have the authority to manage the risk of the organizations- Mm-hmm ... but we're going to bear all the downside, right? Sure. And that speaks a lot to the dynamics that we have as executives among each other, and that's concerning, and that needs to be resolved. Now, the rule of law cannot solve everything.

33:50A lot of that has to do with our own leadership and our own ability to influence and persuade and bring good information to folks. But that is very interesting. If you're sitting in a C spot and you're not willing to be accountable for your remit, then I wonder what else. Yeah. This notion of due care, right, and also due diligence kind of on a different track. But the notion of that and what people... or excuse me, how people perceive their responsibility with respect to that, and how they perceive it with respect to that in light of the protections they know they have. Yeah.

34:38Whether that's D&O coverage, right, or whatever the case might be, right? When you say the veil, is that kind of what you're alluding to? It's called principal agent, right? So are you acting in your own best benefit or you're acting in the best benefit of the corporations that you represent? So, the corporate veil is the identity of the company, the organization. It's a legal person in and of itself. You as an executive are an agent. So you can sue the company, but can you sue its agents?

35:14And the corporate veil is designed in a way to make that very difficult. Now, I would like to add something on that- Please ... because it's interesting. I know we have people in the audience from Europe or outside of the US at any rate, and that's an interesting thing to reflect on. I'm from Europe initially. I've been here over 25 years, but I still run into this notion of agency. Mm.

35:40When you are sitting in a position... I go straight to the question that you were just asking, by the way. When you're in a role, do you feel vested with that authority as a person- Mm ... or as an agent of the company that you represent? In other words, if you knew a decision was wrong, would you still be able to make it because you are only an agent of the organization and the organization wants to pursue a certain path?

36:10Or would you feel obligated? Mm. And that's, in my view, where ethics reside. There's a huge difference between ethics, what's legal and what's ethical to do. That notion of agency, and that touches on principal agent and, to a certain degree, the corporate veil as well. I know it's very difficult for me to make a decision that I cannot align with.

36:39... as a person. Sure. Yeah. I recently was talking to an old college classmate of mine, and we were talking about an ethics class that we took, and I say this proudly, several decades ago. And we were debating whether, what's the status of ethics as it relates to decision-making in corporations at the most senior levels?

37:07And have we seen ethics been shrinking or growing in terms of how the decisions are making? Our joint impression was that we don't see ethics being applied as frequently or in as a comprehensive manner by an individual. And we didn't speak about agency, so thank you for calling that out. That's really a very critical kind of layer to the discussion, right? And so, just a simple question for you then, Astrid, right? How do we improve so that we make more ethically based decisions? Just a little simple, easy one there, just a softball. Hire the right people in the right jobs.

37:49To a simple question comes a very perfect answer. It starts from the bottom up, really. Hire good people and promote good people. This is how culture is made. And then for every cover-up, so to speak, that happens at a company, ethics is diminished by the same amount. So every single decision that we make at every layer of the organization matters to creating, developing, nurturing, fostering, or devolving the culture of the organization. Culture should be one of your most precious assets. And the ability to speak up and speak truth to power, I mean, respectfully, with good information, but we're not hiding things. We should be able to debate issues publicly, openly,

38:50without fear. That is a good sort of measurement for how healthy your culture is. Sure. And I worry in the current climate because I see that take a nosedive in a number of places. That's a great deal of concern. But it shouldn't be hard. It's the most natural thing in the world. And somewhere at some point, someone decided it was okay to lie. It was easier to lie than to speak truth to somebody. So here's another- Please ... kind of two things.

39:33One, another item of reflection for folks. Is it easier for you to lie to a person or to actually speak the truth? And if you're the recipient of that, how do you feel if you find out the person lied to you and you thought you had a good relationship with that person? Do you think the relationship has been diminished for it, or is it someone that you're going to keep doing business with and want to engage with?

39:59I wager the latter. Mm-hmm. And so my premise, and I really, really think it's true, at least in well-governed, healthy environments, relationships withstand uncomfortable truth. Mm. A no is a very healthy thing and will not damage the relationship if the relationship is good and healthy. Mm. There's another lawsuit that I wanted to- Please ... highlight because it's interesting.

40:30And it touches on what David and Kristin were talking about when I just joined. It's the Citizens Frost lawsuits. So these two companies were also impacted by a third-party breach. The third-party vendor reported the breach. And lo and behold, what happened? Citizens and Frost were sued by the impacted parties, not the vendor. Mm.

41:02So Citizens and Frost said, "We didn't suffer the breach. Our vendor did. Our perimeter was not breached." Well, that's completely besides the point, because you, as an organization, are accountable even for your third-party breaches. The third parties should be operating with the same level of risk management, discipline, and diligence as you.

41:29And your responsibility to the sensitive data that was breached about your customers does not stop at your perimeter. It continues, it travels with it. Your customers entered a relationship with you, not with the third party. Mm. So all the frameworks that we have around data governance and stewardship, they say the right thing. The reality is everybody's trying to not make it so and have the third party bear the brunt. I think that's going to change, hopefully, fingers crossed, this month, with new regulations.

42:19You don't get to... Right? This is fiduciary duty at the board level. You don't get to say, "We have a contract. We signed a contract with a third party. They had a problem, not my problem, and people were notified." The problem lives on with the breached parties. Did you do everything that you could in your power to prevent that?

42:44Jury's still out. You know, it's interesting in the security world, for a long time, you know, they would talk about the firewall was the perimeter. Yep. And now it's moved into the identity is the perimeter, and with AI agents that have non-human identities, we have yet another perimeter. But it's interesting because when I hear you say those words, what kind of pops into my brain is, yes, those are technical perimeters, but the perimeter of ownership and accountability, which is really what I think you're speaking to, does not transfer over, right? And I just sometimes wonder where that gets lost, where that message gets lost, right? Like, in terms of

43:33ownership of that from a governance perspective. I don't think it gets lost. I think it's very willful. Oh, okay. I was going to say, did it get buried or was it lost? - No. Doing the right thing is complicated. I am not going to lie. It's hard. Yeah. Right? There's a lot of moving parts. It's a way of managing legal exposure. Mm. That's it.

43:58And we often comes back to that, hence my cryptic comment earlier about- - ... you know, our legal colleagues. But a lot of it comes from that in more capacities than one. And so we have to continue advocating for doing the right thing. Yes, it's hard. It's complex, many moving parts, but it can be done with the right mindset. I think you're right.

44:24And if only on a tiered basis, right? I mean, perhaps you can't do that for every single third-party relationship, but the big ones certainly should. Sure. Sure, yeah. Proactive management, right? I mean, that's part of the, rather than the annual assessment, right? That proactive engagement, right, I think is- And based on- ...

44:44Yeah, and based on your data classification, not a vendor questionnaire. Yeah. So I want to go back to culture just for a second, and then we'll go back on track. Because this is something that we talked about at one of our ERQI co-founders meetings, which was because we are the Enterprise Risk Quantification Institute, we're always debating what should be quantified and what shouldn't be, and what's the relative merits of going either path, right? So culture is one of those areas that we talked about probably two quarters ago, right? Should we be focusing some work product, work effort around measuring culture, and what would that look like, and

45:27what would the impact be? So it was very back and forth, by the way. Not going to disclose the results of it. But if I were to pose that question to you, should we be trying to measure culture, and would that have any impact on the topics that we're speaking to, do you think? Any thoughts on that? I know it's a broad question.

45:45What do you mean would that impact on the topics that- Well, if you measured culture and you said these are, for example, our six core corporate values, right? And you decided we're going to use some form of survey and activity measurement to determine whether an individual and/or a group or business unit, right, is unaligned with our values, therefore kind of aligning to our culture, right? Like, if you did that, A, was it feasible, and then B, could you then use that to empower conversations to drive accountability perhaps? I love that idea.

46:24Cool. I'm trying to remember. I wonder if we didn't used to do that 30 years ago. Oh, wow. Or at least when we hired people, there was a whole section. You know, some companies had assessment centers, right? And you were- Sure. Yeah, yeah, yeah ... sort of giving case studies, trying to suss out how people were thinking about things and whether they would be behaving ethically, or according to your values, whatever your values were.

46:55I am loving that idea. Yeah. There is a group that's focused on that, and I will share that out with the world, as it were, our world here, here shortly. Because it's an interesting concept, for sure. I'm sorry to go down that path, though, because I just wanted to get kind of your reaction to that, because culture is an interesting one. I'm loving it.

47:19I'm actually thinking you could be doing it also as part of a risk assessment or an audit. When you go and audit somebody or assess somebody and they start saying things or withholding information and whatnot, certainly at a minimum, a conversation needs to happen. I've actually observed one such instance not too long ago where executives wanted to withhold information from audits because they thought audit was overreaching.

47:49I didn't fully understand why they wanted to withhold information because it was available. - What are you trying to teach audit? - What's the message here? And audit got really upset and actually said, "You guys are displaying really poor controls mindset." And it was spot on. It was spot on. It was exactly right. And then the information was provided, and it turned out to be a no issue. It was helping things along. So, the reactions that people have is often telling about your mindset, and there's something to be said there.

48:32I'm loving the idea, Andrew. I think that's something to- So if we go back to our initial premise here- You know, how do we effectively communicate with the board? When things don't go well, what do we do? What I am hearing, when extrapolating from many of the wonderful messages you shared with us, that this is not a process change, right?

48:53It's about a governance mindset change. Yep. And the board actually has to know what they're deciding, right? Yep. And are there any kind of final thoughts around that, where as an organization focused on the practitioners, maybe a practitioner-level suggestion or two that you might have along those lines? So, some boards might want to be told everything is fine, and they might want to focus on strategy, thinking risk is not a part of it. You're going to have to help them see it differently, and there's a way to do it, and we discussed what that was.

49:32Because part of your job is to surface all this information. They don't want to discover in the middle of a major discussion that we have a problem. You know, risk disagrees with legal, with compliance. We didn't do due diligence. It should have been priced into the deal, right? I mean, there's no way this is a good answer. So, they may not want to know certain things, but they need to know it. So find a way to raise it. This is what governance is, and it changes things. So, first of all, when a major decision comes to the board, the board should ask explicitly about the risks that they are taking on as an organization, not after the fact, before

50:18the decision. That's when the board can influence it. Your job is to make available information that helps inform that decision. You're not fighting with people. You're not disagreeing because you're disagreeable. You're a professional. Okay? So you're making the information available. Second, risk, legal, and compliance, maybe CISO, CIO, whoever else, third-party risk management, vendor management, should be integrated into the actual decisions, not disconnected from annual meetings.

50:51The conversation needs to happen when the decision is being made. That's when we surface disagreements. That's when the board needs to see them. That's not dysfunction. It is not dysfunction. And that's governance, and that speaks to culture, Andrew. When people are uncomfortable with this type of conversation, culture is not strong. Mm-hmm.

51:10And third, if the board was to approve something that includes concentration risk, say, because we've been talking about that today, because efficiency is worth it, document it. Document the risk, document the backup plan, document the exit strategy, document the conscious choice. When UnitedHealth or CrowdStrike, or even the mortgage servicer that I talked about earlier, went wrong, the board needed to be able to say, "We made decision with full information.

51:46This is what we accepted, and this is what we did about it." That's the difference between we didn't know and we knew and we decided. That's duty of care, and it's informed accountability. Making mistakes is okay. I know it's a bad word in today's world. - And that's part of the problem. Making a bad decision is okay so long as you made the best decisions that you could, that you thought you could make based on the information available to you at the time.

52:15The board of the job - - ... the job of the board... Sorry. I knew what you meant. The job of the board is not to eliminate the risk, or even the executives. We can't. It's not possible. There's no such thing as risk zero. The job is to make conscious decisions about the risks that we take on. We make them visible, we make it deliberately, we document, and that's how we move from implied risk appetite to real, true, effective governance.

52:49Well, that was fantastic. Thank you for those thoughts, and thank you for spending an hour of your time. At a personal level, I want to thank you for everything that you've taught me since we've known each other. So, very grateful for all of that as well. We've got a few extra minutes, so I had one question for you. You mentioned SVB, which is an interesting case on a lot of levels.

53:15Is there anything else that as you've been studying that, that you found amazing, astonishing, shocking? Anything that, just a couple, maybe one or two other takeaways as you've been taking a look at what's happening there? Or a lesson learned, if there is one that's appropriate. - - I knew some things before it all blew up, and then it all made sense, and so I'm trying to... - The chief risk officer spot was vacant for several months- Mm-hmm ...

53:56before the bank went bankrupt, though the signs were there long before she was gone. She was sued by the FDIC. And the defense was, "Well, I was not even in the seat at the time that things happened." I thought that was a really, really fascinating response. Mm-hmm. Your responsibility does not extinguish just because you're not in the job anymore. You still have to answer for what you did or didn't do when you were there. Now, I'm sure she was in a tough spot.

54:40There were some disclosures in the financial statements of the company that said that she- ... was given an NDA. - And that also says to me a lot about what the executives then confessed later on in front of- Mm-hmm ... the judge for one trial, which is not the main- Sure ... the big one. Sure. They knew. They knew they had deficiencies, and they made decisions anyway. Mm.

55:18And that, again, I'm speaking from the perspective of someone for whom ethics and accountability are not just words, that boggles my mind. Mm. I have read a lot of very good books and heard a lot of talks on the topic of corporate scandals. I recommend one, by the way. Please. "The Dark Pattern" by Guido Palazzo on the psychology of corporate scandals and how is it that nobody spoke up? If you want to understand a little bit more about that, that's a really good one. There's many others.

55:59But I still run into it. Like, how do you... And there's another book, which is not a corporate book, it's a novel. It was from last century. A player, like a gambler, right? Mm-hmm. And I cannot help but want... And I often think about that. Did these guys suffer from the gambler's syndrome where they went- Mm ... double down? They knew they were in deep. - You know? I had a blackjack flash there for a second to double down, so. Yeah. Fall on my sword- Right, yes ... or double down and get lucky. I often wonder, and obviously none of us will ever know what that is, but that surprises me a great deal. I think that, yeah. I also think as a society, we blow the whistle a little bit late on these things, right? Because

57:01when you look back 30 years again, think about Enron, Washington Mutual, right? Wells Fargo, IndyMac, SVB. In every case, the trigger was the same. There was documented knowledge, a deliberate choice was made to look away and cover up. Mm. And harm was done to someone who's protected by regulatory commitments, right? So SVB had 31 open supervisory findings the time it went bust. Wow. It's triple what the peers had.

57:44It breached its own interest limits on and off since 2017. Management changed modeling assumptions in 2022 to make the breach disappear. Oof. That's brutal. And then you go bust in December 2022. You fail your liquidity stress test in December 2022. The board approves that 300 million dividend to the parents. I don't...

58:14It's . Well, I'm grateful that you shared those learnings with me, although it makes me unhappy. But that is the world that we live in, so... So, because we're talking about here, fiduciary care- Yeah ... and I heard also from other people tell me some board members don't care because they've never been sued. Well, let's look at this, right? Historically, insurers have paid and executives have moved on.

58:42So for example, Washington Mutual, they settled for 64 million dollars. Only just about 400,000 came from personal assets. Okay. But with SVB's D&O policy, that's 210 million dollars. It's eroding, so there's nothing left to cover you as an executive director. Sure. So, and civil suits can still come. You're not always going to be covered by your D&O.

59:13People can- Sure, sure, sure ... civil damages without regulatory permission to do that. You can't resign your way out of that. - Okay. So, the duty runs with the tenure, and just for some reason that lesson's not been learned yet. I'm going to keep hoping, but... Please do. Please do. And Astrid, I hate to cut you short here- ... but we need to move on to our next session. So, thank you very much, Astrid, for your time and as- Thank you ... always, your thoughtful insights.

59:45Super grateful to have you aboard, and thank you so much for your time. Thank you for having me. Bye. Cheers. Bye-bye.

0:07All right then. We are onto our last session of the day. So Dave and Elimu, I am promoting you to panelists so that you can participate in this discussion. So Elimu, do not deny my request again, if you wouldn't. Excellent. So these two fine gentlemen will be joining. As a quick kind of intro into our next session, I would like to admit that I am the son of an attorney, and so as such, I have both love and hate for the profession.

0:51I have love and hate for the profession because of the wonderful TV shows that I watch where attorneys always look like they're bad people, but I think that's unfair. I think that's just unfair. I'm just going to come out and say it. I have love for attorneys because these two fantastic gentlemen have made me believers that you can have an excellent legal mind and also have an amazing security, compliance, governance, privacy mind as well.

1:23So, with that strange little introduction, I am thrilled to introduce two longstanding associates of mine, if I could, Dave and Elimu. And I will let you introduce yourselves, if that's okay. Dave, I'll start with you because you're closer, and then I will let you have at it. And thank you both for joining, and this is going to be a lot of fun, and I hope you say something so that I can jump in and ask an obnoxious question. Okay, very good. Let's move it along then. Mr. Navetta, to you, sir.

1:59Oh, you're on mute, my friend. Excellent. There you go. Hi, everyone. Thanks for having us here today. Yes, we are lawyers, and Andrew, please don't ruin our reputation by saying we're good guys or something like that. - I take it back. Please. We need to strike fear into the hearts of our clients. We're glad to be here today. We are going to be speaking about the issue of risk from a legal perspective, and as we get into it, I think hopefully you'll understand that a lot of what we do around risk is more intuitive, we'll say, as opposed to quantitative, which we think may be not the best situation. And we're looking forward to, after this presentation, collaborating with a lot of the great minds that we've

2:53seen here today on how to better understand this risk in a more quantitative way. So, I've been doing this for quite a long time. I'm a data security privacy lawyer advising clients, who are usually companies, on data security and privacy risks, all the way from sort of the tactical level up through enterprise-related risk. So, that's my background. Elimu?

3:17Yes. Hi, everyone. Elimu Kajunju. I'm very happy to be here, and I have to say, I've been demoted and promoted today. I think earlier today I was demoted. The system demoted me, and I was a little shocked that I was demoted, but then, voila, Andrew promoted me to panelist. So, promotion is a tricky word, but anyway, we'll cover that later.

3:54I've been doing privacy and security for a pretty long time myself. I was a technologist before I went to law school, so in many ways, law is my second career. But even that being said, I've been doing that for at least 20 years. So, and of course, like everyone else, has adopted any and every new technology that has become important, whether it's previously cloud or now AI and so on. So, Dave and I are happy to lead this conversation, and looking forward to it.

4:48With that, I'm going to try to share my screen here to give a little bit of a background presentation. Elimu, can you see that all right? Still blank. Oh, there it is. Yep, I see it now. Okay, great. So we just covered basically the introduction. Let's get into the conversation. So, as mentioned, our goal here today is to try to give you a sense of how lawyers look at risk in a variety of contexts.

5:21To prove our bonafides, we want to briefly talk about Judge Learned Hand. In this case, we have Mr. Hand, who's acting as Judge Learned Hand, giving us the hand, saying, "Talk to the hand," because he knows that lawyers, while we have this formula, this famous formula that Judge Learned Hand created or came up with, probably didn't come up with it, but he started using it in court, the reality is lawyers are usually- ... not as scientific about risk, right?

5:56So, the famous cases that came out around this back in the 20th century and earlier, really were trying to answer the question of when a company has a certain amount of liability, when they have to take certain actions, basically. So, that formula, basically B greater than P or L, means P times L, means that there's some sort of duty legally to take some sort of steps in a given situation. So, B equals the burden of precaution or protection, P, probability, times the loss.

6:35And what the courts were doing in certain cases was trying to say, "Well, who is responsible for this? Should someone have done something here from a negligence point of view to stop the alleged harm from happening?" And the court basically said, "If the cost of doing so is less than the probability times the loss, then there is an obligation, a duty, and liability can accrue." Right? And so, on some level, that formula, even if not stated in the kind of mathematical way, is everywhere in the law. It actually really encapsulates the concept of reasonableness, right?

7:15Whether you've undertaken and actually satisfied a reasonable duty of care to undertake anything. Anything from slip and falls, to securing your systems, to handling personal information properly. That formula, again, even if not in a mathematical way, is very much embedded in the legal world these days. Elimu, anything to add to that before we get to kind of more detail? Yes. So, I love this formula mostly because it's... Again, depending on where you sit on a particular issue, you think of the formula as relatively simple. But what I have found, and even in some of the presentations today, difficulty is often the probability.

8:21Determining what the probability is in that formula can be very difficult. And because without it, it's really even hard to determine whether the burden of precaution is less, right? Because sometimes the loss calculation is easier to do than the probability. And Dave will talk about some of the numbers, some of the calculations within the legal space later today, but just wanted to tee that up.

9:01Although, I will say- Mm-hmm ... the loss itself is often difficult too, because, well, I would say it's the lack of data or data not having yet been fully realized or brought together on losses when it comes to legal-related losses. So, we'll get into that more towards the end of the conversation today. But the next thing we want to talk about is sort of how we give day-to-day tactical advice, because almost every day of the week, Elimu and I, in the privacy and security legal realm, are having to sit down. And again, whether we're putting it on a mathematical equation or not, we are having to sit down with our clients and talk about risk and explain to them

9:46what their risk is and help them make decisions. And we're often doing this from our experience or from our gut in many ways. And so, we want to talk about what that looks like to give you a sense of how we do it, and also, again, thinking about what would be better for us, what information could we have or need to actually help our clients make better decisions, even at this more tactical level. So, Elimu, do you want to start off here?

10:18Yes. So, I think the topic of risk, legal risk overall, is colored by timing. And here's what I mean. So, lawyers come with certain skill sets, certain views, certain ways of thinking through risk. And those risks show up every day, right? Show up every day in the course of a business. And the introduction of legal risk within the context of everyday business risk sometimes looks really different than when it comes in relative to a particular issue, particular crisis. So, obviously, a common area where a lawyer is needed is in the situation of a data breach.

11:47And I'm sure most, if not all of you, have- ... either been part of one or been somewhat involved or are aware of incidents kind of within your organizations. And there are a lot of issues in the context of advising on risk in a breach that make it difficult in a way, right? One is evidence. So, during this time, there are some things you know, some things you know you don't know, and then there are things that you don't even know that you don't know yet, right?

12:48So, whether you have evidence that something has happened or that there's no evidence that something didn't happen, there's a lot of judgment call there that we are asked to navigate. The concept or pay or not to pay, in many ways, is another very much risk-based decision. There are risks to paying, there are risks to not paying, and there are some those risks that are very known, and some are suspected but not known.

13:38You could pay and still not get what you're paying for. And you can pay and face the same penalties as if you didn't pay. So, again, it's fraught with opportunities to second-guess oneself. But part of the lawyer's job is to help an organization think through what is known and not known, and what are the risks related to any of those. Then I'll jump quickly, go through the rest. Materiality assessment- Let me look. Go ahead.

14:33Can I elaborate on a couple of these? Sure. So, the first one in the actual data breach context, we often do these investigations with forensic investigators, and we are aware that data has left the building to some degree, but we don't have the visibility to either say how much data left the building or what data it was, right?

14:54And when they're talking about a data breach, the usual notification obligation is some sort of knowledge of an unauthorized acquisition, right? And so, almost every breach I've worked on, we have this inflection point where we say, "Well, they could have taken everything. We don't know." We have evidence of that there was some data taken, but we don't know exactly what it was.

15:20We can't see it being taken, so we don't have knowledge yet that it was taken. So we could assume they are on the system. We don't have evidence that they necessarily took everything off. We could assume that we haven't discovered a data breach, and therefore, we don't have to notify people, right? Or we can go the other direction and say, "Well, hey, we have a little bit of evidence that something left, or maybe there was nothing stopping the threat actor from taking data, so we have to assume everything left," right? I just had a data breach where we were talking about 44 terabytes of data, which we couldn't prove or disprove had left the building,

16:03but there was nothing stopping it from leaving the building. So, then we go to the advice of, okay, so from a risk perspective, what does that mean? So, this case I'm working on involving a nation state actor, this client, this particular client said, "There's no way we're going to be looking at 44 terabytes of data, trying to figure out what that is, alarming all of our customers, going out to the world and causing maybe PR disaster when we're not even sure that this data was taken." Right?

16:39That's one way to look at it. And I say to them, "That's fine, but you have to understand there's risk in not doing this too, because in six months or three months, that data, it may be discovered, is released by a threat actor, or somehow it's found out that the data was taken from you and you didn't notify anyone." So, in that case, your downside damages might be much worse than just notifying now, right? Because now, not only have you had a data breach, but you also took six months to talk about it. So now, these are all very difficult to put numbers around that type of analysis, but that is the type of risk analysis that comes up in this context.

17:27To pay or not pay a ransom. Another example, Elimu gave a good example of you're not getting what you pay for. Sometimes you get double extorted, right? They come back in and they do it again. They breach you again and ask for a second payment. There's also the concept of when you're doing a ransomware attack where there's downtime, you're basically trying to figure out, "Hey, if we pay the ransom, how quickly will we get the decryption keys back?" How quickly can we recover our systems and operations? How many days are we going to be down and how much money are we going to lose each day?

18:04And if we pay the ransom effectively, can we get back up and running much more quickly as opposed to trying to do it ourselves without talking to the ransomware attacker, trying to get backup from backups, trying to do things that will get the systems going but could take three weeks or a month or much longer than just paying the ransom?

18:27I often get into these data breaches where it's a CEO-type person and they say, "We'll never pay the ransom. We'll never pay it." And then we find out that they don't have backups and they're going to be down for three months and not be able to service their customers, who, by the way, are aware that they're down and they're losing 5 million dollars a day.

18:49That CEO often has a change of heart in terms of whether they want to take the risk of paying the ransom. So, there, we're trying to actually calculate and really get into brass tacks around what money are you losing, what customers are you losing if you don't pay the ransom? Can we alleviate that by paying the ransom, even if we don't want to pay that ransom? Those are the types of risk decisions and how we actually frame it for our clients.

19:21So, Elimu? Yeah. No, that's a good addition. And the scenario that you said earlier where a client potentially lost 44 terabytes of data, I don't want to say that scenario necessarily is common, but it does highlight one important risk factor is time, right? So, could one get more clarity around what they actually lost by spending more time investigating?

20:14And sometimes putting in more time and delaying can be helpful, but then if you put in more time and you just put in more time and you actually didn't get more information, right, then you just burned a lot of time. In some ways, you've burned a lot of goodwill along the way. So, yeah. No, these are matters that are never sort of straightforward.

20:49Another example of how we provide risk advices in the privacy realm around tracking technology and litigation. So, right now, over the last three or four years, there have been about 4,000 class action lawsuits alleging that when you visit a website that a wiretapping violation, California's law, California Invasion of Privacy Act, and the federal ECPA wiretap law have statutory penalties. And what plaintiffs allege is that unless a visitor provides consent to the website owner, if their data is transferred, it is a violation of wiretapping law. The problem is you don't have to prove any kind of damages for that particular case to go forward. So, if you have a million customers who visit your site and every

21:44one of them had their data sent to Meta, the claim could be worth 5,000 dollars times a million, which I think is up... I'm not even sure how much that is. A lot. 50 million, 500 million, a big number. And what has been happening is plaintiffs have gone out and they scan websites and they look for trackers from Google or Meta or TikTok. They find them, and then if there's not a consent management process in place, they go after the company with a demand letter.

22:17Usually, they start off pretty low. You pay 30,000, 50,000, 100,000 dollars and we won't sue you. And many companies do the math and say, "Well, I'm not going to face 500 million dollars in penalties here. I'd rather pay the 30,000 dollars and have them go away." Right? And then that's when we usually get the call as the lawyers when this occurs. Now, there have been lawsuits where they've gone all the way to the end of the jury trial. In fact, one of them involved Meta, where I think they have tens of millions of potential violations that they're going to be facing at 5,000 dollars a pop, right?

23:00So a lot of these companies want to fix this. They don't want to be targets. And usually, it's the lawyers who are calling me because I'm the lawyer on this end, and they're saying, "Well, how do we fix this?" Right? And I say, "Okay, well, you can fix it by removing all of the trackers you have, or you can put a consent banner in and make it so that people actually consent to these trackers."

23:22So that conversation usually goes pretty well with the lawyers. They're like, "Oh, yeah. Let's just quickly snap our fingers and get this fixed. Let's just remove everything." And I quickly have to say, "Well, we should probably talk to your marketing team first because there is a risk associated with actually removing or adding a consent banner to the site because they may lose their revenue stream or they may lose their leads or their marketing efforts." Right? So suddenly, it's not just a legal question. There are multiple stakeholders, and they all want to address the risk from their point of view. And so that's another challenge that we have as lawyers

24:04is there's not just a single client, a unitary client. We're having to sit down and balance the risk of the legal and litigation environment versus potentially a business impact that's caused in this context by actually removing these trackers, right? And so, then we have to sit down, and this is actually a recent case I had, where the marketing team is going head-to-head with the legal team, and in this one case, it's an insurance company. The marketing team's claiming that if we put a consent banner in, it's going to cost 30 to 40 million dollars a year in losses, right? And so, what our client did was had us go and try to figure out exactly how much

24:47litigation would yield, right? And so, as Andrew points out, I think that's 5 billion dollars for the example I gave of potential risk. But then I have to say, "Well, what's the reality?" No one's been hit with a 5-billion-dollar claim yet. What is the actual risk? And this is where it gets much more difficult. We have to kind of go out to case law and look at the litigation. All the data's not in all one place, and we're trying to go against a 30 to 40 million dollar loss to argue that the risk of the legal issue is worse, or maybe it's not worse.

25:23But those two data points are what we're trying to bring to the equation so that ultimately the business team can mediate between the marketing team and the lawyers to determine what their risk tolerance is and what they want to do, right? And I would say very much so, this is not yet a scientific formula, and we are sort of putting our finger in the wind a little bit when it comes to actually analyzing and advising on this. And it can be a very, when they actually try to tell you to put numbers to it, frustrating process for the actual client for the reasons that Elimu mentioned before with our formula. The probability of getting sued and actually getting hit

26:06with one of these major, major fines is difficult to predict, and what the actual impact is, is also difficult to predict. I have some clients who want to avoid litigation at all costs. They favor that in terms of their risk tolerance calculations, even if it hurts marketing. I have other clients that go completely the other direction, and some of these clients have received three or four, five demand letters and paid off the troll demand, the parking ticket, and continue to have their trackers work unencumbered.

26:41So that's how we have to sort of advise our clients on these particular types of issues. Yeah. So myself, I've had a few examples sort of similar to Dave, where the marketing team... In fact, I had a situation where the CEO and a legal team approved a lot of changes to a site, and the marketing team about three weeks later yelled and screamed, "Hey, we've lost visibility to clients. We lost visibility to leads as a result." And so now, one of the topics on this issue that I think is relative to the loss is, if you think about if everyone is in the same boat, I mean, so many of these clients here are, particularly for CIPA, referring to their California activities.

28:06At some point, once every California company is in the same boat, then I think it's hard to state that the damage is this high. I mean, because you would think, "Okay, are they going somewhere else? Are they going to another California-affiliated organization or company that's selling in California?" Right? So, there will be a point where that argument doesn't work, but I think we're still not there yet.

28:48Great. So that should give you a flavor of how we look at risk tactically. The other thing we're asked to do is to help boards and higher risk-related individuals within companies understand more systemic risks, more enterprise risks. And so, Elimu, maybe walk us through how that works in terms of our role and how- Yeah ... we help manage that. Yeah. So, what I find here, and I think this is true both in the context of an external lawyer like Dave and I, and/or like a general counsel within an organization.

29:32So, once you're involved at the enterprise strategic level where you have visibility of every potential acquisition, every major expense, every area that you're choosing not to spend, and you're able to see things holistically, it does put you in a unique place because of the legal skill set that we bring to the table, and you're working with- You know, with business leaders, financial leaders, other types of risk leaders, and all of you are trying to work to manage risk within an organization. So, it is an opportunity for one to also look at other disciplines while looking at the legal lens.

30:44So, you're looking at projects that may be coming in. So, I was attending a planning meeting for a client, an annual planning meeting, and they're helping them think through legal issues. They were going to create some new products, which for those in healthcare, it has some significant anti-kickback risk. And so I mentioned, "Hey, look, this is an area, this product looks like it's been socialized with potential clients. This could be a boon for the company, but we need to really be careful how we do this." We're not really telling them, "Hey, you cannot launch this product because you have anti-kickback risk."

31:48We're like, "Well, this product does have higher than normal anti-kickback risk, so we need to make sure we're building it in a way that minimizes, reduces, maybe even eliminates the risk, depending on the configuration of the product." So, it's really trying to be a business partner while making sure the room, so to speak, is wide open on the legal risk associated with certain actions or certain inactions.

32:35Yeah. I think we go back to what we were talking about before, right? The concepts that we're advising on in this context are, for example, in the CISO context, if there's a data breach or if there are multiple data breaches, what is the actual impact to the company so that the CISO can potentially get resources, whether it be additional security measures or additional people, or even maturing the processes generally.

33:06We're coming in and being asked to provide some ammunition to be able to justify further resources being put to the issue. Another case I've been working on where this actually bore fruit was a case involving a company that does a lot of defense contract work, and they have confidential unclassified information as a result of that, which is a highly regulated type of government-related information.

33:37And it's a big sprawling company, and on some level, at a certain point, that data was sort of kind of everywhere on their system, right? It was a bunch of acquisitions that had their own way of storing it. Other times it was just residing in sort of more publicly available places on their network. And there was a push at some point that the CISO wanted to engage in to actually segregate that information and put it into a more secure, limited environment.

34:09And it was a large battle. It was going to cost a lot of money, and management really wasn't seeing necessarily where that benefit would come. The benefit, of course, comes in the form of avoiding having to go out to your government customers and explain to them that their data has been breached, potentially losing contracts and other really bad things.

34:36But the problem is, it's hard for anyone, and lawyers especially, to really handicap that and put the probability on there to actually then calculate what that loss would look like. There's not that much data that's available to actually give you that information. And so as lawyers, we kind of come in sometimes with the worst-case scenarios, right? That's an approach. But I will say that approach, that narrative often is not really respected, I would say, right?

35:10They want a little bit more about the actual chances. It's very easy to discount the sky is falling, right? Now, there is data out there on some of these types of issues. A lot of the data I've seen on the security side, though, relates to the probability of a breach happening and the costs associated with responding to it, not always taking it to the next step of the business impact, let alone the legal impact, which of course is its own type of business impact.

35:40In this case, though, they were able to eventually, with the help of lawyers, convince their management to actually segregate that CUI environment. And then the benefit, I guess, the good thing, although it was a really bad thing too, was that they got completely owned, again, by nation state actors. And it was a situation similar to the one I mentioned earlier where we couldn't see what those state actors did because they were very good about covering their tracks. They were on for two years.

36:17The good news, though, is because of that segregation, all of that data was completely air-gapped for more or less, and therefore, the threat actors, and we could prove it, weren't able to get to it, right? And so, now the cost of that particular movement of that data to that data center and segregating it, the value of that was millions, maybe billions of dollars for this particular company, right? And so, it was a win except, of course, they got breached, but it would have been a very much, much, much worse situation if that data still resided on that network, right? And so, that's where you get to tell the Monday morning quarterback story where everything worked out fine.

37:05Oftentimes, though, the CISO and the lawyers are not successful in convincing the board or management to put them dollars up in that preventative fashion. So, again, if there's a way to really quantify that a little more carefully from the legal perspective, I think that would be really well received and much more useful than just sort of off the cuff, "Hey, this is my experience," type advice.

37:34Yeah. So, to add to that, I just want to talk briefly about the concept of reasonable security. It's intentionally vague, but it is designed to change with the times. And part of our role is to help our clients understand what reasonable security should mean to them. So, if you're a large retailer, what's required, what's expected of you would be more analogous as to what your peers have, right? So, if there are known risks, known issues, known security control that should be in place if you are a Target or Publix or Walmart. And another, if I'll pick on Kroger, if you're Kroger, you cannot get away with not doing the things that your peers are doing because

39:14you appear unreasonable because you're essentially an anomaly relative to your peer group, right? So, however, the corner store may not have to have the same security as Walmart or Target. So, even if they happen to be selling the same thing and have some of the same profile, they collect credit cards, they collect cash, they collect checks, they sell health products or whatever that might be.

40:06Great. So, where does this leave us? I think it leaves us in a place where we are trying to find the data. I think especially now with AI creating new tools and capabilities, there's more of an ability to actually understand some of the risks that we've talked about based on data and based on analytics. So, I'm going to show you some of the things that we've been working on here.

40:34I'm going to stop the share here. Okay. So, the example that we laid out earlier, hopefully that comes up. Can you see that, Elimu? Yep, I do now. Okay. So, I provided an example of around the tracking technology issue, right? And so, the challenge I had in that one case was to try to come up with some sort of risk rating, some sort of impact number that I could put in front of a client to tell them what their actual risk was. What we've done at my firm is we have downloaded about 16,000 cases from 2015 and 2026 related to data security, privacy, or AI litigation.

41:29And so, this is the output from that. And what we're trying to do with this tool is both the tactical level, at the tactical level and the strategic level, right? So, we see all the cases that were filed. We can see all the basic metrics associated with those cases. But what we can also do is we can figure out where these things are being filed, where does the risk exist, how quickly are these things being filed? As you can see earlier, we talked about the California law. 3,000 of these cases were filed in California, right? We know that's a very dangerous jurisdiction.

42:06That's not that big of a deal to know that, but we also can look at firms. We can look at the Pacific Trial Lawyers. We can understand how they act, how many days they take to actually settle. We can look at the defense firms, who's active in this space. We can look at who's filing on a volume basis and who are they teaming up with.

42:28All of this information can be extremely valuable because we can then tailor our tactical defense against these firms in particular. But even more important, we can actually tell our client what the track record of these firms is, right? We can say, "These guys always settle." Before having all this data, the approach for most lawyers was to go to their colleagues and say, "Hey, have you ever been against the Pacific Trial Lawyers? How do they act?" And someone would say, "Well, we've seen them three times, and here's what they did in those three times."

43:01Now, we have the ability to actually see every one of their 74 cases, analyze each of their 14 settlements, including the amount of the settlements, understand how long they're going to keep you in court. This starts to move the needle in terms of that tactical advice that we were talking about. We can see how deep the litigation goes, right? Because the depth of litigation actually equates to more leverage and equates to a situation where if a plaintiff gets past a certain gate, a motion to dismiss, suddenly the risk of that case increases significantly when it comes to thinking about settlements, right? We can actually figure out exactly what we're looking at in terms of

43:46the disposition. So, how do the courts actually settle the cases? Are they active? Are they dismissed without prejudice? And sometimes you can win the case, right? You can actually get out on a motion to dismiss. How frequently does that happen? How quickly and how frequently does it go to arbitration? All of these data points are extremely important on the tactical level when you're thinking about actually defending these matters.

44:10Settlement timing, how quickly and how frequently are these things settling? How many times are they settling as classes versus individual settlements? And then settlement structure, et cetera. We get actual numbers here at the end of the day to be able to figure out what the risks are, what the median and average settlement amounts are, what the structure of the settlements look like. A lot of these settlements actually have costs associated with the injunctive relief associated with the settlements.

44:41So now we start to get to a much clearer place that also gives us not just the overview of kind of the tactics and the practices of the judge, of the plaintiff's lawyers, of the settlement amounts, but also gives us a bigger picture, a portfolio-type approach, right? So, if you're a company getting sued all the time, some of this data is going to help you understand what you need to do to mitigate your risk. So, our hope is to be able to take this data and advise boards or advise CISOs as to the things they need to do, or privacy professionals, in order to reduce the risk in these cases. We can start to data mine this for practices that actually are more likely to result in a lawsuit, or types

45:27of data, I'll show you that we have the same thing for data breach litigation, the types of data that actually cause more harms. I'll show you here, we have class size. So, we can understand the class sizes and distributions across class sizes. So, what we do here with this data is, I have a client recently who got hit with a data breach, and we were trying to figure out, okay, well, what is the median settlement amount for a breach involving 10 to 50,000 records? If it's 2,000 records that are breached, what's our risk? All of that comes into play, as we were talking earlier, when you're still trying to figure out what happened in the breach.

46:11But very quickly, you want to know, is this a big breach that's going to hit us very hard, or is this a little breach? And assuming whatever size it is, what is the actual downside? How much do we want to spend in money and time investigating this to actually hopefully get our exposure down? Allegations and outcomes. What is being actually alleged to have been breached?

46:33Social Security numbers and government IDs, the median is about 2.06 million as opposed to medical information, where it's 427,000, right? These numbers start to really make sense when it comes to actually managing these cases, as well as actually taking it back to the bigger picture and doing what Elimu was saying in these board meetings, where we can go and say, "Listen, if you take these steps, if you segregate this information, if you put these controls in place, if you have an incident response plan to be able to respond quickly, we can show you how that reduces your legal risk. And here's the things we need to do to reduce that further, and here's the resources we need to do it."

47:16So this is the beginning of that process that we're trying to engage with the data itself to be able to use it at a tactical level as well as a higher level in a strategic fashion. Elimu, any comments? I have one more thing to show, but I want to hear more from Elimu because I'd be curious to know how you would think you would use this in a real-life scenario. Yeah, well, actually, I had a question for you.

47:43- Okay. My question is, so let's say on the breach side, what data point would you say tends to drive the most decisions in terms of, tend to influence business leaders in terms of what to do next and how to act? In my experience- Yeah ... it goes to what you would think it would be, right? It's how is it going to impact our customers, right? At the end of the day, they're thinking about the revenue stream, right? And so that- On some level, the legal risk is there.

48:24It's usually viewed as a little more manageable. It's the outcome to the customers that really makes a difference. So if it's a ransomware attack and you're down and you can't provide services, that's one way. If you've done something so atrocious with customer data that they're bolting, that's another factor. Now, those are very difficult factors sometimes to figure out, right?

48:48I think if you're an e-commerce site and you know that for every hour you're down, you're losing 10,000 dollars or a million dollars, that's one thing. But to know how a customer's going to react and whether they're going to take their business elsewhere in the face of a breach, much more difficult to quantify. But I think that's usually what drives more decisions than less.

49:17I know we're getting towards time here. So I've also done this for AG work, privacy and data security AG action, so the regulatory realm. And again, stepping back, when privacy lawyers and data security lawyers think about risks, they're thinking about what does the legislative world look like? What new laws are coming out to actually legislate AI or data security or privacy? Then they're thinking about, "Okay, well, what are the regulators doing? What are they enforcing?

49:48What do their settlements look like?" And the third poll is litigation, right? So what are the litigators doing? What actions are out there being pursued? How are they being settled? And so those are the big picture items that we look at, and this is an attempt to break it down into something more digestible in those realms. But if you understand the privacy-related litigation risk, the AG and regulatory enforcement privacy risk, and understand sort of what's coming down the pike, then you start to get a better, more fulsome picture of what risk is, and then you can advise your clients better.

50:27The next step in this is trying to be predictive about it. So this is what I call PEPI, the Privacy Enforcement Pressure Index, and it's taken a lot of the data we have gathered from the state AGs and their enforcement process for the last five years, which is actually difficult to find. And we asked the question, when do AGs enforce and why do they enforce, right? And so we've taken the data and we've sort of said, "Okay, well, what are our theories," right? One theory I had was AGs enforce when the legislature is trying to pass more privacy laws, right?

51:06That was one of my theories. Another one was exogenic events, like some sort of big data breach or Cambridge Analytica happens, and we should see a spike in enforcement after that because now it's out in the public consciousness, right? I also thought maybe it depends on the political party, right? That could be another factor.

51:29So we went through and actually took that data, and we came up with probably two factors that are the most indicative. And again, they're probably not predictive, but they're correlative to increased enforcement. And the PEPI index goes one to 100, attempts to figure out if you get to a certain level, whether enforcement is going to uptick over a certain timeframe when you've reached that level, right? And so the two factors that have been the biggest factors are sentiment is probably the biggest one. And sentiment is actually controlled by a couple things.

52:12One thing is those exogenic events. When the Cambridge Analytica happens, you see people searching in Google Trends for privacy violations, or "my privacy," or "I want to opt out of sales." Or we also see spikes on state websites for the AG actions where they report on additional complaints that they're getting, right? So there's also surveys and polls that are out there about privacy. So what we've taken is we've looked at those sentiment signals, and we've been able to track and identify where sentiment against privacy or AI issues was very high in Google Trends, for example, and we saw spikes or increases in enforcement activity on a lagging basis when those sentiments

53:02increased to a certain level, right? The other factor that we see is the institutional aspect of privacy. So 2018 was California's first privacy law major in the US. They passed the law, but they didn't really have an enforcement mechanism in place. Now California has, I think, a couple dozen regulators focused on privacy. They have budget. They've gotten some big settlements, what they pulled back into the California regulatory scheme. So suddenly, the institutional maturity of the regulators, and maybe even some competition between regulators and some collaboration between regulators, is increasing the regulatory risk associated with data security and privacy and AI. So this is

53:51very much a beta, but the idea is to be able to be a little more anticipatory when it comes to these types of risks. I'll just show you, I have this concept of the boiling point, right? Where if it reaches a certain level of certain topic, it suggests, again, that there's going to be more enforcement in a given time frame because that topic, the sentiment associated with the actual topic and other signals are saying to us that, "Hey, this is something now that's on people's radar. It's soon to be on the AG's enforcement radar," right? So AI companion and chatbot safety over the last quarter moved up into close to the boiling point realm, right, where

54:34things are going to start getting interesting. AI training, another one. Deepfakes, a big jump here. And some of these other ones, you're starting to see little jumps and hops in terms of the risk posed by those types of activities. So again, I'm not saying this is predictive. I don't have enough data necessarily, but I think the idea of it is very interesting and intriguing for more strategic advice, for even the tactical-based advice where you're trying to tell someone, "Hey, if you're doing chatbots now, we have to be much more careful about how we're rolling those out when it comes to the legal issues, because enforcement looks like it's getting an

55:12uptick relatively soon." So this is the future, and I think lawyers need these tools more than just their intuition, their experience. The more we have them, the better we'll be able to advise our clients ultimately. Wow. So. Wow. That's all we got for today. I don't know if we have questions anywhere, but... I have 13 questions across seven categories.

55:45We may have to map that out a little bit. No, I literally did write down a bunch. Did you prepare a graph? So first and foremost, let me thank you, Elimu and Dave, for joining us today. That session was fantastic, and it really kind of rounds out risk perspectives. There literally are 13 things I wrote down that I'm going to ask you guys to respond to, not right now, but there are just some really critical points.

56:15And I'll just mention one, right? When folks do risk quantification exercises, one of the things they do is they'll look at what is the potential for a fine, right? Or there to be a legal case brought, and what is the amount of that potential loss resulting from that case? What would the payout be? What is really just kind of in its infancy stage from where I sit at least is like, okay, the fact that it might occur at that number does not take into consideration the likelihood occurring to you as an organization.

56:49And Elimu, you just made an earlier comment about kind of being one of many people in California, right? And so there might be a, you have to look at it through that lens, right? That you are part of this population. And Dave, you really kind of hammered that home with that amazing set of data that you just showed us. So thanks for sharing that. That was super insightful and helpful.

57:10So with that, I could not say that I could not be any happier with the selections that I made to the legal risk team at the Enterprise Risk Quantification Institute. You both did a phenomenal job, and I'm grateful to you both. Mr. White, any comments to our two fine friends here? No. As Andrew and I were chatting off to the side while you guys were talking just in awe of this session, it was fantastic. Dave, Elimu, thank you so much for sharing your knowledge and insights with us.

57:54And Dave, thanks for sharing that incredible analysis. I really want to spend hours with you talking through that, but I probably couldn't afford your bill. So... Don't drop your rates, Dave. Just telling you, man. I am a bad guy, so... But no, I mean- You're a what? A bad guy. No, you're the worst, man. You are the absolute worst. That's why I know your rate is really high, because you deserve it. Yeah. Well, we want to collaborate because I think there's something here that has not yet been tapped into in the legal realm, and the time is now, really, for this type of analysis.

58:39And one final thought. Sorry, I forgot to mention this. The privacy angle is not one that definitely gets enough consideration, I think, in the enterprise risk space, certainly not in the cyber risk space. So thanks for helping to illuminate that particular risk area, right, and the significance of it and how you guys help provide guidance around it. That was very informational. So, with that, I think we're going to move to wrap up.

59:08One more thing. What? Dave, when you were talking about the client with the CUI, I couldn't stop myself but thinking a little cooey here, a little cooey there. Nope. Here a cooey, there a cooey. I don't know where we're going with that. I'm not sure. So back to wrap up. We have another wonderful day on agenda tomorrow.

59:33We have eight more sessions starting at 8:00 a.m. with Caroline Wong talking about how to communicate effectively. Some session called Tapestry with some guy named Sandy Shay, and then two really smart people, Jack Jones and Dr. Bob Mark. We will be talking about the results of our ontology survey executed by our good friend Marco Notini and what that means, especially in light of AI.

1:00:03We'll be talking about model risk, a key topic, which was raised a couple times today. And then, Dave, you can follow up on the last four, and then I'm going to break into my toast, and we can call it a day. Fantastic. So, we're going to be talking about the move from cyber risk quantification to enterprise risk quantification in the session at 1 o'clock with Lisa, James, and Johnny. They've been working on this from different perspectives, and I think that'll be a very interesting discussion.

1:00:36A unified data model with Harshi and Edwin, and then CRQ operating models and the integration of third-party risk management with Maxime and Bob. And finally, the debate, quant versus qual risk management or risk analysis. We have four incredibly knowledgeable folks who will be debating that topic at 4 o'clock, and that's how we round out the two-day session. So, please make plans to join us tomorrow, and thank you for joining us today. Those of you who are still with us, thank you for hanging in for a long time. Dave, Elimu, thank you again. Andrew, the toast.

1:01:26Yes. So, I am half Irish, half Italian, so I'm going to call on my Irish side, and the toast is, may the road rise to meet you. May your probability and impact be low. Excuse me, may your probability be low. Well, maybe probability and impact be low. And may the only thing that exceeds your risk appetite be your bar tab. Sláinte.

1:01:49Sláinte. See everyone tomorrow. Be well. Be well. Thanks again, Elimu and Dave. Take care. Thank you, guys. You crushed it. See you in the morning, my friend. All righty then. Bye for now. Hey, one quick question. You had some Amazon links. I was looking at an Amazon page because I was trying to do that for a couple things tomorrow, and I didn't see a way to do that. Is there a simple way to do that? Did you- Well, there's not a simple way to do it. Okay.

1:02:36Because if you just search for the book and then grab the link from the URL, you get all of the tracking information- Yeah, yeah, yeah ... for how you arrived at that book. Yeah. But if you find the question mark- Yeah ... in the URL and just delete everything to the question mark and everything to the right, then you get a URL that's compact enough to share. It doesn't take up three pages.

1:03:08Yeah, you get a URL that's compact as opposed to being CVS receipt-sized. Yeah. For those of us in the US. So, you will be on tomorrow to kick off the event technologically. Absolutely. Yeah, I'll be here with you in the morning at 8:45 to get things jumpstarted. Okay? All right. Until tomorrow. Sleep well, my friend. Bye-bye. Good night.

0:06a little bit personal, because I think it relates to our topic, which is that- Please ... when I was a teenager, my dad said to me, "Caroline, what do you want to study when you go to college?" And I said, "Oh, I love dance. I'd love to study dance, and I think psychology is very interesting." And my Chinese immigrant father said to me, "Caroline, you're going to study engineering, and you're going to attend the most competitive program you can get accepted to."

0:29- And so I studied electrical engineering and computer science at UC Berkeley, and it was not my thing. It really, truly wasn't. I learned a lot about critical thinking. I learned a lot about problem-solving. There was this one electrical engineering lab, and I, of course, become friends with the one other person in the class who also doesn't really know what's going on.

0:53It's a group project, and so we know that when we pick our third, we have to pick someone who knows how to do the freaking experiment. - And so Cole and I go, and we find Sam. Sam knows exactly what he's doing. And the way it works, we're 19 years old, and Cole is fetching the supplies, and Sam is doing the lab, and I'm writing the report. And at the time, I feel so much shame that I'm not the one of us contributing in the way that I really know, and I'm a master of how to conduct the lab. And throughout my career, I've realized to be the person who writes a great report is actually a super important role. And I don't know, while I couldn't have done that lab effectively without Sam and Cole's help, I

1:39don't know that they would have been able to write the report as effectively without my help. And so at the end of the day, who's making these risk decisions? Humans. And so who do we have to learn how to communicate effectively to? Humans. Thanks for- Now ... indulging me. For now. For now. - I mean, now it's all about pleasing the AI overlords, right? And I think we just have to social engineer them accordingly. Like, how do you sweet talk a savant five-year-old? Maybe it's with candy. We have to figure out what is the- - ... digital equivalent of bribing AI? And then- - ... that'll be our ticket in.

2:23I was just bribing my granddaughter last night, not with candy, with baked goods, so that went really good- Boom ... for her. So thank you. Yeah. Yep. Very good. So, let's go back to this concept, right, of communication. And before we launch into kind of specifically around the board, one of the things that's kind of interesting that I've experienced is when, to your point, right, you created the lab, right?

2:47And so you've got that work. And then in an academic setting, you have your fellow teammates where there's critical communication, right? And then you have the people that you're actually presenting to. In the corporate world, right, we have multiple audiences that we sometimes need to take our core findings, right, and then message it to the appropriate audience.

3:07And that, I do believe, is a superpower, by the way. So, are there any quick thoughts that you have on that, on how you can be most effective in addressing multiple audiences? How do you put yourself in a headspace to do that well, perhaps, is a better question, Caroline. I think for me, the most important question is really curiosity.

3:26Mm-hmm. And maybe the second important is actually empathy. I don't know that we as risk management professionals talk about empathy ever, but here's where I'm going with that. I think that if we are seeking for someone to buy into our idea, then ideally, we're able to identify some common ground. And at the end of the day, I want to reduce risk. The person across the table or on the Zoom meeting for me also wants to reduce risk. And so that's where the common ground lies. Yeah. And if I can approach a conversation with curiosity and empathy, then I can basically say to that person, "Hey..."

4:04And at this stage in my life and my career, I might go so far as to be extremely straightforward with it and say, "Look, we come from different perspectives. I'm an expert in risk management. You're an expert in whatever it is that you're an expert in. And what I want to do is I really want to find some common ground."

4:21Mm-hmm. "Because I know that both of us, whatever it is, want to protect the company, want to reduce the risk of a breach, want to..." And define that on a high level and really kind of narrow in on what is the common goal. So yeah, curiosity and empathy for the win. I love that. One of the things that we talked a little bit about yesterday in the session with Astrid Yee-Sobraquès was trust.

4:49And just before, again, sorry, I'm going a little bit off-script on you. I apologize. But can you just- Go wherever you want, Andrew. I'm here for it. - As long as I get to go there with you, I'm here for it. We can go literally anywhere. - It's a bad habit of mine. - Good habit. But trust, right? I mean, empathy, curiosity, totally get that. I can see how empathy could lead to communicating in a way, right, that can develop trust. But just a couple thoughts perhaps on how do you develop trust, especially now turn back to our initial path, right, when you're talking to an audit committee, right, or a senior executive or a board member?

5:29You know how I don't develop trust- Perfect ... is I tell you that I'm going to show up to this session, and then I don't show up. Or I tell you that I'm going to show up, and then I'm five minutes late. Or I share with you some data that is obviously incorrect. Mm-hmm. I think there are these basic... And it is different, I think, when we're talking about trust between humans and- Actually, yesterday on the panel, I was talking about this concept of when we're thinking about AI agents and their autonomy and their authority, maybe we should consider shifting our perspective on, do I trust this agent to how much confidence do I have that this agent is going to perform task A

6:22according to my expectations? Now, I think that for now, when we think about audiences and stakeholders, we are thinking about humans. Sure. And so I think that concept of trust actually really is important. And I think the most bottom line important thing about trust is we do what we say and we say what we do. And if we don't do that, then it's a lot harder for people to trust us.

6:52Awesome. I'm going to ask another kind of broad-based question. Part of the dialogue that we talked about in the synopsis for today, right, was specifically around communicating with the board, right? And I think for that matter, we can talk about senior executives, although they have slightly different narratives, I think you could argue, when you're communicating with them. But you have 20 minutes with a board, right? I mean, and which was 20, it probably got compressed down to 10, right?

7:23Let's just start there, right? Like, how does Caroline Wong approach that type of interaction and meeting? What's going through your mind that helps you to be successful in that kind of situation? For me, if I have 20 minutes, which is actually going to be 10, and I think that's actually a really important assumption, Andrew, to point out, which is that we get frustrated when we... And actually, it comes back to trust. We get frustrated when we feel like we are promised 20 minutes with this group- Mm-hmm ... and then maybe we prepare 30 minutes of material, and then it's actually 10. And then we're like, "Ah, what do we do?"

8:02My son is at an age where he's fascinated by how many seconds are in this period of time. So I'm like, "Okay, how many seconds are in 10 minutes?" Sixty seconds, 10 minutes, 600 seconds. Ideally, when I'm speaking in those 10 minutes, I want the person on the receiving end to understand what I'm talking about. Mm-hmm. And if they don't, then that is wasted time.

8:33I could be bringing the most sophisticated, the most amazing, the most detailed analysis, but if I'm talking about it and the person I'm speaking to doesn't understand what I'm saying, to me, that is also actually not building trust. Right. And sometimes it's as simple as checking in and saying, "Does that make sense? Are we on- Right ... the same page here?"

9:00There's a thing that I think really talented cybersecurity and risk management professionals say sometimes, and it's a pet peeve of mine, because they'll say, "Oh, I'm going to go present to the board. Oh, I'm going to go present to the executive leadership team. I've got to dumb this down." Mm-hmm. And I hate that, actually.

9:19Yeah. And the reason is just because it's not about dumb or not dumb. It's about, I'm an expert in my area, that person's an expert in their area. Right. And I need to be able to communicate with non-experts what it is I do if the value of what I provide is going to be understood. Mm-hmm. And so for these folks, I don't think about it like dummy it down. I think about it like, my expertise is A, their expertise is B.

9:57How can I approach the conversation such that they can understand what it is that I'm trying to talk about, and I can sort of effectively lay out, what am I trying to accomplish here? Sure. And how might that align with what you're trying to accomplish, or how might it not? Sure. And if there's a difference in our opinions, then let's figure out how to define that difference, because ultimately it's probably about making a decision. Sure.

10:23And that decision oftentimes comes to investment, money. Like, how much money are you going to give me to reduce this risk? Excellent. Let me ask you this question now. So as you were talking about that, my mind went to this notion of translation, right? So you have a core set of messages you want to communicate. To your point, everybody has their own subject matter expertise, and depending on which level we were talking about there, right? Like, you might have people who are looking at things from, is my organization going to meet its quarterly goals from a financial perspective, right? So translating it into something like that is one path, right?

11:10And I'm using this term translating loosely. But do you think of that as translation when you think of making your message most applicable and most digestible to multiple audiences? Or is there a different way, a better way of thinking about that? I do, and I think that's a really useful way to think about it. If I'm speaking English and you're speaking Portuguese- - ... we're going to have trouble getting on the same page, right? And so similar thing. And I think there's a mistake that well-intended folks make that I want to point out, which is simply sometimes we're like, "Oh, the person on the other side of this table or on the other end of this Zoom

11:51call, what they care about is money." Mm-hmm. "So I'm going to talk about dollars." And that's- ... fine if we, as cybersecurity, or we as risk management professionals, really and truly understand the numbers. Because I'll tell you what, the people at any organization who think about things in terms of dollars, they're not hand-wavy about dollars. - They really- They're precise.

12:22They are. And so we get in there and we're like, "Oh, I think the probability of whatever happening and the impact, and that's going to be 50 million dollars." And they're just like, "What? No." And what happens there is, I'm an expert in A, they're an expert in B. If I pretend to be an expert in B, they are going to see immediately that I am not. Right, right. And that is going to be a problem. That's actually going to erode trust.

12:56I think a lot of times, sometimes we get annoyed by buzzwords or marketing hype, you know? Sure. And we as information security and risk management professionals, if we don't actually know how the organization makes money, and if we don't know that well, if we don't understand the go-to-market engine of an organization, I'm using a for-profit organization as an example, then we're just going to come off like kindergartners talking to college-level professors about a topic, and they're going to be like, "No." And that is not great for trust. So it's okay that we are not experts in what they are experts in. And it's important to acknowledge that, but we shouldn't pretend

13:44that we are experts in what they are experts in. Again, this comes back to curiosity and empathy, and I'm actually going to go ahead and add respect. Right on. Oh, awesome. Yeah, totally case. I think one of the things I think when anyone in our realm is doing quantification work, one of the key things I think that might empower some of the talking points that you're making is the following, right? So, I talk about assumptions, right? If you are presenting some very specific data, a specific range of impact, specific range of probability, what are the assumptions that you used to build that out? And that then helps with kind of a secondary but related

14:26concept of defensibility, right? I don't really love that term, to be honest, because it's not overly positive, so I got to figure that one out. But that's a conversation for a different day. But you know what I mean? So, you have to be able to quickly and readily communicate how it was that you came about to this information that you're presenting. And I don't know if that kind of bleeds into kind of the way that you're thinking about this as well, or not. I think that's very aligned.

14:54And I think that I want to bring up an important concept, which is precision. - Please do. I think it's important when we're projecting these things and explaining how we got to the numbers, A, for the explanation to be sufficiently straightforward that the person on the receiving end can be like, "Yeah, that makes sense," even if they don't understand all the details. But if you're explaining it and they're like, "I don't get it. That doesn't make sense," then you're asking them to take a leap of faith with you, and they may do that if they trust you already. But if they don't- Right ... maybe not. And then there's this thing where we're like, "Oh,

15:37whatever's going to happen, and it's going to cost 50 million dollars." And I'd almost rather we say 50 million dollars than we say 50 million dollars, 469 thousand- False precision ... whatever it is, right? Yeah. If we get too precise about something and there's not a reason for that precision, then in my opinion, that further degrades our trustworthiness.

16:02So I would say to folks, try and kind of keep your precision and your accuracy in the same general ballpark so that you're not implying with a precision that you kind of know more than you do. Because I think that's another thing that erodes trust. I think that is really, really critical, so I'm going to underline and bold that, right? Because to the extent that you have, as an individual, limited interaction with an audience, it's important to be confident. It's important to frame what you're going to discuss in a way that, as we talked about a few minutes ago, is something that can be understood by the audience that you're speaking to.

16:46But that false precision element is really critical. Just speaking for some of the situations I've sat through, where an individual wanted to present a single number as a potential estimated loss, because they wanted to give one number because it's easier to understand and digest. That's a trap that I see sometimes people fall into, because they really want to have that singular answer. And in the world of risk, because we're dealing with uncertainty, that really isn't kind of ideal to try in an ideal manner in which to try and communicate. So, consider that bolded and underlined.

17:22I love it. And I actually wonder to what extent sort of being in this AI era helps us out as risk management professionals. Mm-hmm. Because we've shifted from deterministic to non-deterministic, and risk management is non-deterministic. Right. And so actually, if the whole world can kind of get on board with there's not a singular right correct answer, actually, it's a range. There's possibilities, there's probabilities.

17:52Then folks are actually thinking more along the lines of how we've always been thinking in risk management. So yeah, love that. Don't present a number, present a range, explain your assumptions. And because we're data people, right? We love to do analysis on the risk quantification side, right? We do. We often have perhaps an enormous amount of things that we could present. And I'll give you just a specific example as a talking point. But the reality of it is, people that are working in risk quantification are doing risk scenario analysis on a continuous basis. And at any one time, depending on the size of the organization, they might have just a simple number of five risk scenarios. In larger organizations, they

18:34might have literally hundreds, right? And in some cases, then they have a top 20. And so there is this kind of desire, because they work so hard, right, to put together this top 20 to present that up. But sometimes that really can work against you, I would suggest. Yeah. Sometimes it's just too much. I think it's really important going into the conversation to understand, if you could wave a magic wand, what would be your ideal outcome? Right.

19:05I think sometimes it's like, "Wow, you're brilliant. Here's 20 million dollars to go and reduce that risk." Are we going to get that? I don't know. But to really focus in on, what do I need this person to understand? What decision do I need to help this person make? Mm-hmm. And if it's helpful to be like, "Here's my top 20. Here's my 300 things."

19:31I think it's often that... I remember, I've been in organizations where you get 10 minutes and you've got 300 slides. That is not going to work. Right? And it can be frustrating. And that's not to say don't have backup slides. That's not to say don't have slides in your appendix that if somebody decides to double-click on a particular topic, you can just go there and say, "Oh, you know what? Actually, here's more about that."

20:00But I think there's a lot to be said about understanding that 10 minutes is 600 seconds, and how are you going to spend that 600 seconds in a really, really valuable way? Wow, 600 seconds. I love that framing. I mean, really, 10 minutes seems like a short period of time, but when you break it down into seconds, all of a sudden you realize that almost the significance of every phrase that you utter, right, and how being thoughtful about that really is going to help increase your impact to your desired audience. I think when we talk about this notion of communicating to, and I'll focus on senior executives first, right, framing things appropriately,

20:44right? So, maybe a word or two, if you could, and we'll just pick out two of those audience members. So you're presenting to the CFO versus the CEO. So, same conversation, slightly different. How would you approach that? And let's just say it's not a meeting, it's a one-on-one with them, right? Any thoughts on framing those conversations effectively?

21:06Yeah. So I think that if we're talking about a public company, there is an easy button, which is you go to the investor relations part of the website and you study everything, and you make sure that you understand what's going on. I mean, again, my particular background happens to be in a commercial, sort of for-profit sector, so I'm less sort of nuanced. This is actually, here's a good demonstration perhaps, which is to say, I'm not going to pretend I'm an academic.

21:38I'm not going to pretend I understand nonprofit. I'm not going to pretend I understand government, because I don't. And so I'm providing this assumption, like, okay, I'm most familiar with for-profit tech companies. And in a for-profit tech company, you really got to understand, how do they make money? Right. And on any given year, in any given time period, in the year 2026, what are the targets?

22:04How are we doing against those targets? That's just, in my opinion, supremely important to go into that conversation with. And I think that applies equally for CEO and CFO. Now, so here's a funny thing that I've noticed. Sometimes, cybersecurity and risk management professionals, we get so into our fancy algorithms and our vulnerabilities and all of this really detailed technical stuff that nobody else has even any idea what we're talking about. And then we're insulted when they don't know what we're talking about. And we spend so much time on those things. And I've noticed the CEO and the CFO of a company, the CEO in particular, they have a responsibility

22:56to explain to the employees what's going on. And they do this in an all-hands meeting. How many of the folks watching this right now love company all-hands meetings or even attend company all-hands meetings or pay attention to company all-hands meetings? Versus how many of us are often multitasking and completely not paying attention?

23:21That, in my opinion, is the equivalent of if I'm presenting to the CEO or the CFO and they're multitasking while I'm giving my presentation. There's information out there that they've communicated, and have we kind of done our homework and learned about it? Yeah, excellent point. It's interesting, when you talk about framing, we talked about language and making sure our language, right, is most digestible by that particular audience. That whole kind of mindset is something I feel like you kind of grow into over time. And so the more experience you have with that, the better.

24:00One of the things I wanted to ask you to comment on was something that I heard recently at a National Association of Corporate Directors meeting. You know, I used to go to cybersecurity events. Now I go to NACD events. I guess I'm now an adult officially. I love it. I love it. You want to be with the folks who are telling the CEO what to do. - And I love that. That's awesome. It's interesting.

24:26They talk about the first time that you're presenting your information, right, to a C-level audience or the board, right, should not be in that meeting, right? You should be doing work to kind of create your consensus amongst the people that will be there. And I thought, "Wow, that's a really simple but important point," right? If the first time somebody hears from you, you're crammed into that 10-minute, 600-second kind of window, right? That's a little problematic. Any thoughts along those lines? I think that this is an extremely good point, and I think it's often overlooked.

25:02Sometimes it may be the result of us procrastinating. I know that I don't have a chance to socialize my information with people if I'm kind of up until 2:00 a.m. my local time the previous night, finishing it up. But yeah, ideally we're thinking in addition to that 600 seconds that I get live with that audience, how much of a heads-up do I get?

25:28Sometimes you get pulled into a meeting and you have no heads-up. But a lot of times you get two weeks heads-up, or you kind of know what's going to happen. Sometimes these meetings happen on a quarterly or an annual cadence, in which case you can actually plan. And you can just, okay, a week out, ideally a week out, you've got your material prepared and you're sharing it with everyone who's going to receive it in that meeting. And you're saying to them, "Here's an executive summary. Here's the material I'm going to prepare. Here's what I need you to think about." Now, they may or may not read it.

26:04If you can get five minutes with them prior and just say, "Hey, here's what I'm thinking about going in on." Ideally, you know every single person in that room. Mm-hmm. And ideally, you also know exactly how they're going to respond. You really have the meeting before the meeting. Right. You usually share the information, get the response, and then the meeting itself, it's almost like, again, when I was a younger person, I still love dancing. Okay, love dance.

26:37- Me too. And so I have this thing about, okay, there's rehearsals and there's dress rehearsals, and then there's the performance. Mm. You got to have rehearsals and dress rehearsals. Mm. And you have them a week in advance. Maybe you even have them a month in advance, depending on what you're talking about. So, we have a lot of really good questions pouring in. I'm just going to reinforce and encourage people to continue to ask questions. We're going to continue on our path for another 10, 15 minutes or so, and then we'll turn to Q&A. So we're not ignoring you, just to be clear.

27:12But there were some things that I wanted to make sure that we could hear from Caroline Wong in particular. And I didn't get all the way through this thought on my last time I asked you about this, but that notion of going from, "Here's our top 20 scenarios. Here's one slide on each one," right? There's this notion of self-editing, right? Which means, I need to make sure that I'm focusing my message, right? And so you've already commented on self-editing, if you will, to a certain extent. Any kind of final thoughts there before we move on?

27:45You know what is so cool about being in the year 2026? - This is one of those things that ChatGPT can just help us out with. Now, we want to be careful about what sorts of data we're putting into public models, yada, yada, yada. But I can pull up your LinkedIn profile and I can say, "You know what? Prepare me a briefing on Andrew Shea."

28:15Tell me, if I'm going into a meeting with Andrew and I need to present points one, two, and three, and I'm trying to achieve this outcome, how should I approach it with Andrew? Give me some ideas. - You can even kind of pretend, you can say to ChatGPT, you can say to Claude, "Pretend you're Andrew." I'm going to run this version. Maybe it's an anonymized, desensitized version. I'm going to run this version of my presentation with you. What questions is Andrew likely to ask me?

28:48And so there's this way that we actually just mostly didn't have access to five or 10 years ago, where today we can actually practice. Mm. And we can use ChatGPT, we can use Claude, we can pick your AI of choice. Sure, sure. And for a $20 a month subscription, I'm not talking about crazy use of models or anything, but actually, AI is super good at this kind of thing.

29:12So I do encourage folks to consider running those scenarios with the assistance of AI in order to practice. Yeah, and you're right, right? You can say, "This is the audience," right? "This is the kind of audience that I'm trying to communicate this with," right? And you can get some kind of interesting talking points. I do want to go back to one other thing that you just said a little bit ago, though, and I want to bold that and underline that, right, which is understanding the organization, right, from a high-level business objective and strategy perspective and being able to lay your message in, right? That's really important. And if you're at a public company, right, one of the things I talk

29:48to people about is read the 10-K, right? Boom. - Yeah. Seems like a simple thing, right? But because some people aren't- People are like, "What's a 10-K?" ... comfortable with the format. They start reading it, they're like, "I don't know any of these words." Maybe it's time to learn the words, right? That is arguably respect, and it's certainly a savvy approach. And if you don't know, then you can go... There's so many learning opportunities. And here's the other thing, in today's AI era, you don't even have to read the 10-K yourself.

30:17Yeah, you can ask for somebody on your- You can just like grab it- ... career, yeah ... throw it into ChatGPT , and be like, "Tell me about this 10-K," right? So there's honestly shortcuts these days that were not available to us 10 years ago that we can take advantage of. Absolutely. And I think along those lines, right, you mentioned this earlier when we were talking a little bit about how you're positioning the results of all of your hard work. But it's different to say, for example, I would offer your thoughts on this, right? It's different to say, "We are going to reduce the risk to this new customer application by X percent if we invest," versus, "I understand that the

30:56revenue goal for this new application is X," right? And so that's kind of opportunity versus opportunity, making sure opportunity and what your business objectives are driving, right, is important. I can go down the market after. Yeah. David, I think you're off mute. Sorry. It's all good. It's all right. Simple mistake. Sorry. Let me go back and just repeat that one more time just for clarity, because I got lost in the chatter.

31:23But specifically, right, it's different when you say, as a risk quantification person, right? Like, "This is the risk, this is the mitigations that we recommend, and this is the cost to them, and this is how it reduces ideally, right, impact and/or frequency or probability." Right? So that's great, but if you frame it in terms of the opportunity, right, the focus of the organization, which is, "We built this application because we're trying to drive 70, 700 million dollars," depending on the size of your organization, right? So that framing, I think, becomes really important. Thoughts on that?

31:58Absolutely. And I think that at a high level, it's important to understand, is this business doing well or not so much? And the concept that I think we can really zero in on is, what impact does company performance have on risk tolerance today? Yeah. Right, right. Because maybe if the company is doing wildly well, then there's also a greater risk tolerance. Maybe if the company is not doing super well, maybe there's a lesser risk tolerance. And that is a really important piece of context to have going into one of these conversations. Right on.

32:46Accounting for the realities of the business is kind of the point that you're making there, right? And making sure that your comments are taking that into consideration. I think one of the... I'm going to go over to the hard ones now. Let's do this. - So, one of the things, and this goes to one of the questions in Q&A, by the way, but is when you're talking to people who have been staring at a heat map for 20 plus years as the primary visualization of risk, right? And this is not really meant to intend to slam the heat map. Feel free to, by the way.

33:23That's fine by me. But people are looking at this very simple expression of risk, right? And we, on the quantitative side, are like, "Ooh," right? That's not really a great way to visualize, and it's inaccurate in terms of communicating risk. But it's still a huge challenge, right? So it's a huge challenge to get people to think from that qualitative approach to a quantitative approach. So hardest question I could possibly ask you, you're welcome.

33:47How do you help people with that mind shift, right? Any thoughts on that? So I think that presentation of information, the options exist on a spectrum, right? It's not either here's my entire analysis, or I have a heat map, or traffic lights. There's degrees in between. And I think that we, as risk management professionals, have an opportunity to think about zooming out and zooming in. Oh, nice. Yeah.

34:23And being able to do that sort of... It's not so much on the fly as it is having thought about it. And kind of zooming in or out to the place where our stakeholder sees things. Sure. Because again, we've just got to communicate it to that person. In an ideal world, you have fully quantitative on one end of the spectrum and fully qualitative on the other end. And maybe in practice, you understand both of those, and you can also speak to one that's here and one that's here. Sure.

35:09That, I think, can be extremely empowering. And I think to be able to speak along that spectrum of qualitative and quantitative, ideally, they also connect to each other. And this can be very hard to do. I just want to really acknowledge that this is so much easier said than done. But if you can sort of masterfully move between qualitative and quantitative and have it still tie together, that, I think, can be extremely helpful.

35:48Yeah, it's interesting. And a couple thoughts on that for you to comment on, but the first one is, because you're moving from qualitative to quantitative, right, the underlying model and approach you're using is different. And I would argue that sometimes we fail to help communicate effectively that this is a different risk model, and here's why we're using it. Any thoughts on that?

36:10Yeah, I think part of it is like- When you're doing math homework and the teacher's like, "Okay, show me your work." You know? And I think sometimes we want to be able to present the final answer and also show your work. There's another way of thinking about it, which is for the audience that I'm presenting to, what is that person's almost like criteria for making whatever decision it is that I need them to make?

36:45Right. And that is going to determine, or at least influence, the level of detail at which I'm explaining it. You know? I think that for many of us, it would be ideal, but it may also be uncommon for my audience to trust and respect me so much because I've built rapport with them over years. I've been doing what I've said I'm going to do. I say what I'm going to do, I do what I'm going to say, that they're just like, "Oh, like whatever Caroline's recommendation is, we're just going to go with that." Right? That's not super lucky. Sometimes it happens. But who's the person on the other end of them, and how do they think about these things?

37:34What are the criteria that make sense and matter to them? Right, right. How can I try and predict that, and how can I also present my information in a format where it's going to address the questions that they have? And I think you bring up an interesting point by inference there almost, but which Stefan Hunziker yesterday mentioned this, and we live in a world of uncertainty, right? We do analysis. We create models around trying to structure and understand uncertainty and reduce uncertainty.

38:10But part of doing that effectively, and I would argue that helps to build credibility and trust, has to acknowledge the fact, right? Let's acknowledge the fact that we're living in this world of uncertainty, right? And so, let's put that out there and be like, "Okay, this is something that you need to understand about this world that we're going to talk to you about." Can you comment on that?

38:28Yeah. So, I've had the opportunity to be alongside CISOs or supporting CISOs in conversations to executive leadership teams, to boards of directors. More recently, given that I'm at a startup right now- - ... I've had an opportunity to talk to venture capitalists. And it's another- Ooh, lucky you. Yeah, it's super interesting.

38:55I just keep learning about things that... I just love to learn, right? I just love to learn. I feel so lucky that I've been able to be in the room for these venture capital meetings, and it's kind of like I've got to figure out how to communicate with this audience in a way that's going to check their boxes. Mm-hmm. And we can know what those boxes are ahead of time, and we can prepare that way.

39:28I've been in the role of startup pitching a VC. I've also been in the role of sort of subject matter expert who's being consulted by a VC during a diligence process. And even in that latter scenario, somebody will ask me for my opinion, and I'll give my opinion. - And I'll say, "You know what? This is what I think is going to happen in nine or 18 months." But sometimes I'll actually just acknowledge, truly, I have no ability to predict the future, and neither do you.

40:00This is my opinion that I've developed after however many years of experience and all these different things. But let's just go ahead and acknowledge briefly that none of us can predict the future, even though we would really love to. So, along the veins of difficult questions, I am thoroughly excited to share this one with you. Let's do it.

40:24Any tips... Thank you, Keith McLaren. "Any tips presenting quantified risk to leadership where a decision should be made, but the enterprise risk tolerance is expressed qualitatively? We have a high level of risk and a low level of probability." That is kind of what we were just speaking to in that whole kind of heat map discussion that we were having.

40:47But I guess maybe kind of alter that a little bit and say there's this notion of when you're talking to an individual, understanding the decisions that they're trying to make and how what you're providing should help them to do that. There's also a school of thought that says if you're approaching somebody at a senior level aboard, you should have the question that you want them to be thinking about already in mind, right? And so you're presenting them with information to help make the decision rather than ask the question. So, not sure there's a very specific question there, but how do you approach these kinds of situations where you might, on the one hand, right, want to inform them about a

41:30decision you're asking them to make versus giving them a question, or planting it successfully maybe is a better way to think of it. Any tips on that front? I think that this is a scenario where the pre-meeting, the pre-discussion- Mm-hmm ... having the conversation before the live conversation can make so much of a difference. Because sometimes it's actually unreasonable to think that we could actually effectively communicate this thing in 600 seconds.

41:59Maybe this stuff actually takes a little bit for a person to think over. And ideally, a week before, two weeks before, it's really clear to them. If I'm presenting to you, "Hey, Andrew, I really want your decision on-" ... ABC. You could even go so far as to say, "Hey, Andrew, in a couple of weeks we're going to have this meeting, and I really want a decision from you.

42:27And what would it take for your decision to be yes?" - Right. That's a tool. No, right. Yeah, no. We get to ask that question. There's nothing wrong with asking that question in advance. And the answer might be, "I don't know." Right. And that's okay. Right. But it's still worth... And if the answer is, "I don't know," we have an opportunity to say, "Here's how I would think about it if I were in your shoes."

42:59Sure. Maybe. - There is also, I think that something that I've really acknowledged, and part of this is because I've been in a chief of staff role myself. Whoever the executive is that you're having this conversation with, that person is likely supported by folks on their team, whether that is a chief of staff, an executive assistant, maybe some direct reports.

43:33Those are all also really important stakeholders, because a lot of times, and I think about when I've been in higher level leadership roles, I recognize that I'm not as close to the work as some of my team members are. Mm-hmm. And so, naturally, I'll go and I'll talk to my team member who's closer to whatever it is we're talking about, and I'll want to understand their opinion.

43:57Sure, sure. And so, if that person has already bought in, or on the flip side, if that person is highly skeptical, that's going to influence what I think about it. And so I would say, to the extent that it's possible, take advantage of any conversations that you could possibly have with a person's chief of staff, executive assistant, direct report, other direct report. Consider sort of that constellation of people that they already trust and who know how they think.

44:35And to the extent that you can also build those relationships and have some of those pre-conversations, "Hey, Andrew, I know that you work for so-and-so. I'd really like to just ask your opinion on how you think they would respond to this scenario. Do you have any advice for me?" We can be straightforward with things, too. "Do you have any advice for me?"

44:59And we can just be honest, and honestly, a little vulnerable. I think that one of the things that I think gets in our own way sometimes is we want to have all the answers, and we just will never have all the answers. And sometimes it's okay to just acknowledge we don't have all the answers. Exactly. And just to be straightforward about that. No, good point.

45:22And just be like, "Hey, I'm trying to figure out how to really effectively communicate this point. Do you have any advice for me?" I think that you made a really critical point earlier when you were talking about the use of AI, because I think one of the things that I hear people talk about, right, is lack of access to these people, right? We've been talking about trying to have pre-meetings with people, and what I found in many cases is that people don't even ask for those meetings or know that it's okay to ask for those meetings. But we can't always get access. And again, I think this is where your comments about AI really are significant, right? There is,

45:57in the public domain now, right, a lot of information, right, about this person's perspective, whether it's on LinkedIn or articles they've written or presentations they've given. And so you can start to build, I think, maybe an effective profile on how they might consider it, right? It's not the end all be all, but helps to address that question of, "I just don't even have access to these people." Right?

46:16So, okay. So, along the lines of difficult questions, we will move on to this one, which is the greatest fear, I think, of anybody working in the quantification field is that you present your results, and let's assume you've done a nice job of framing, and somebody just challenges them straight away, right? "Those numbers are wrong.

46:39Can't possibly be right. I wish you would have consulted with me first before..." The range of things that people who work in the quantification realm get that kind of fit into that kind of spectrum of, we'll call it non-positive responses, is interesting. And so when you're faced with that, sometimes you might want to be defensive, but that's not always the best approach, I would offer. Thoughts? Yeah, I think there's a couple of different ways to handle this.

47:10One way is to say, "Look, I think there's been a disconnect." And if you only have 60 seconds left, then you say, "Can we connect offline afterwards whenever you get a chance? And then we can bring that back to this group." Another one is actually to approach it with curiosity and empathy and say, "Explain to me why you see it that way." Mm-hmm. Like, "Why?" Mm-hmm.

47:36And maybe they're presenting some totally different information source. Maybe their source of truth is different. But that's an opportunity to gather information, like, "Why do you think that way?" - "Help me understand." So I think those are two potentially useful techniques. One, say, "Let's deep dive offline." Because I do think that that type of discussion, it's often helpful just to be kind of in a one-on-one private session with that individual who's kind of throwing up these huge objections.

48:07Otherwise, particularly in front of everyone else, "Explain to me how you came to that conclusion. Why is it? What other evidence do you have?" Because it's also okay to acknowledge that I value- X source of information, and they value Y source of information, and they might conflict. And that's, again, another important thing to understand.

48:32I think one of the craziest dynamics that I continue to see that always shocks me, and now it doesn't anymore, but shocked me originally, right, is you're doing some risk scenario work, right? You're explaining to the key stakeholders, who in this case I'm going to define as being actually the owner of the risk, right? So you're in a meeting to them explaining to them the results of your exercise, right? And they turn to you and look to you and say, "Great, what's your recommendation on what I should do? Should I accept this risk, or do we need to spend this money?" Like, that's a very challenging position to be put in, right? Because in theory at least, right, our role is to advise on risk, not

49:15make a recommendation to that business owner per se, but that's a gray area, I would argue, right? And so, along the lines of challenging questions, I think that's a good one to end on. How do you respond and be effective in that kind of scenario? I think it is important for us to go into these conversations with a recommendation. We should have an opinion, right? And this is an area where that person is an expert in whatever that person's an expert in.

49:51I'm a risk management expert. I'm a cybersecurity expert. It is reasonable, like even if the roles and responsibilities are that person is supposed to decide if they're going to accept the risk or not, I should actually be coming to the table with an opinion. And ideally, that opinion is backed by both quantitative as well as qualitative measures. Excellent.

50:12Well, we are in wrap-up mode. So, we covered a wide range of things, and thank you so much. The curiosity and empathy thing really stuck with me in particular, right, like as a mental space to be operating from. I think the empathy piece in particular, right, forces your mind sometimes, right, to operate at a different frequency, right?

50:35And so, love that. Any final thoughts that you want to share with the class, as it were, and around how to communicate risk effectively for decision-making, just broadly? I do have a final note that I want to say, and it's on the topic of anxiety. Oh, boy. Please. Because these conversations, it's totally normal to get really anxious. And I think one of the things that I've kind of thought a lot about over the past years is, what's in my control and what's not in my control? Mm.

51:13I don't have any control over whether my important meeting that I've been preparing for for a month is going to get interrupted or not. I don't have any control on if I thought it was going to be 20 minutes and I actually get 10 minutes. I don't have any control on if somebody is not going to be kind that day. Those are things that it's a waste of time if I worry about those things.

51:36Sure. What can I control? I get to control the research that I do. I get to control how I communicate my assumptions, et cetera. And I see that we have Jack Jones and Dr. Bob Mark coming on, so we're off to another- - ... very exciting day. I got to say- Yes, please ... Jack Jones and I were on an RSA panel, I think it was like 2009 timeframe, and we had a line out the door. Jack, do you remember this? This was so much fun. We had a line out the door. There was standing room only, and then they asked us to do an encore of our session. And that was just one of the funnest days of my entire professional career. I'll never forget it.

52:19Caroline, thank you so much for your time and your insights, as always. There are some questions in Q&A if you have time. Feel free to answer those. If you don't, no worries. We can take that offline. So, thank you so much. Very grateful for your time, as always. Great to see you. Thanks, everyone. Have a great day.

0:07Well, well, well. Who do I have here? Let's see. Let's see, a doctor. There's a doctor here, a Dr. Bob Mark and a Jack Jones. Wow. Okay. Good to be here. Were you guys on the agenda? I'm not sure. Oh, yeah, I know you were. You were. My bad. Forgive me. I thought it was Thursday, but all of a sudden I was reading my- - ... glad to be here.

0:33Well, I mentioned in my prior session, right, that one of the joys of being in this position, right, is being able to interact with people that you have such a high, high level of respect for, and maybe they've been formative in the work that you've done. And so Caroline was early in my career, we launched and was all about security metrics. And so somebody that was working in the security field, right, like how to create a metrics presentation, right? That was very formative for me.

1:04I am thrilled to be speaking with these two fine gentlemen today because they also have had that impact on me. So, by way of introduction, as I was trying to figure out how to communicate on behalf of a CISO, how to get or add budget, I found this weird thing called the Open Fair Standard, and it was talking about susceptibilities and threats and, I don't know, all sorts of frequency stuff.

1:32And I looked at the author, or authors, and one of them was this gentleman named Jack Jones, who had started an institute, oh, by the way, to study and focus on this with some other people. And the amount that I've learned starting back 15 years ago from this gentleman has really influenced me at a personal level. So I want to thank you, Jack, for all the work that you've done.

2:00I've only known Dr. Bob for about a year. But the amount that I've learned in that year is just insane, and it has really been helping me to take the world of risk quantification and tie it into how does a chief risk officer think about things? How does a CFO think about things? What is the language they speak? How do they analyze stuff?

2:23And so thank you to two more of my heroes that I have been able to interact with, and thank you for your time today. I gave you each my Andrew Shea version of an introduction, but if there's anything else that you'd like to say about yourself, I am thrilled to have it. So Dr. Bob, I'll start with you. What else should people know that don't know who Dr. Bob Mark is before we launch into this? And it can just be your favorite color if you want.

2:51San Francisco 49er football fan. - I wear San Francisco 49ers socks on the day of the football game. Commitment. So you're about commitment is what you're saying. All commitment, yeah. - I'm a Warrior fan, but maybe not so good year this year, so. Well, I'm going to jump in and be like, "The Essentials of Risk Management" has been transformative for me, which is a book that you authored some time ago, I believe. Is that correct, Dr. Bob? Three years ago.

3:252023. 2023, right. It would be, but it's the fourth book that's out. So that's three books preceding it on risk management. And then there was some work you did with UCLA, I believe, as well. Is that true? Started the Master of Financial Engineering program at UCLA, which is a degree in which you get exposed to the financial industry, learn the math, learn the banking, and all sorts of other things. Now, what's being introduced there is artificial intelligence and all sorts of other things. And having learned cyber from both you and Jack, and been involved with FAIR and FAIR-CAM, someday we'll have an integrated course in there that is a part of, and some of it we'll talk about today-

4:16Very much ... which will relate to how to set up systems which respect the kind of things that we're going to about to talk about today. So Jack also wrote one of my favorite books. It's not a science fiction, by the way, which is my core genre. So when I'm not reading science fiction, I'm trying to explore the world of quantification, and then how to communicate that in financial terms.

4:38And so, I think most people probably know, Jack, who you are. But if there's anything in particular, like you're like, "Hey, I'm Jack Jones. This is my thing," any kind of comments along those lines you want to make? No, not really. Okay, cool. Let's move right into things then, shall we? Topic number one, establishing... And sorry, let me back up for a second. Tapestry, right?

5:07Tapestry. I mentioned yesterday in my opening remarks the origins of the Enterprise Risk Quantification Institute, which came from a series of webinars that were done around NIST IR 8286. IR, by the way, standing for inter-agency documents, so not quite a standard. But a series that NIST put out a while ago, right, that was focused on merging cyber and enterprise risk.

5:34And what a surprise, my two favorite speakers from that webinar series were one Dr. Bob Mark and one Dr. Jack Jones. Another gentleman, Keyaan Williams, joined us. And as we were talking about the challenge of merging these things, we talked about the reality, right, of we have governance requirements that we need to meet, right, and kind of governance standards, if you will. We have cybersecurity and standards and frameworks.

5:59Keyaan Williams, thank you for chiming in, my friend. So Keyaan Williams termed this phrase in the webinar series of, "It's a weaving." And if you go back and watch one of those, you'll see me just get totally caught up on the weaving thing and saying it six or seven times. But the notion of creating a tapestry, right, where we're interlacing, right, these elements, right, was what Tapestry was founded on.

6:25And so that's my perspective on Tapestry and its origins. Jack, I'm going to turn to you and ask you to comment on the origins of the Tapestry concept from your perspective, because it could be totally different. Could be, but isn't. I don't know. Yeah, I think Tapestry is a nice descriptive term for it, because it is bringing together, synthesizing these different but related elements in a way that I think helps to close some gaps and maybe identify others that therefore need to be closed.

7:08But it also provides an opportunity for us as professionals and practitioners to get a broader perspective. The parts of the tapestry that maybe we're less familiar with, it gives us an opportunity to understand it in context- Mm-hmm ... and see where those relationships are, and then understand things better as a result.

7:33Sure. And I think that the kind of things that we talk about that we were weaving back in that conversation, we were talking about governance, risk, compliance, and then financial analysis, right, as kind of being kind of the four key pillars, if you will. Dr. Bob, your thoughts on the origin of Tapestry. And we should maybe put this into a little bit of context, right, against one of the kind of key things that we're trying to solve for, which is establishing risk appetites across an enterprise, right? I mean, all of that work, that whole notion of having this cool Tapestry concept, right, ultimately has outputs, outcomes that we're trying to

8:07influence or create. And so, your thoughts there, Dr. Bob? I think maybe it's good when we talk about NIST 8286. As you know, there are parts A, B, C, and D. Mm-hmm. And we begin with part A with risk appetite. So it may be good for Jack to say a few words about risk appetite, and then I'll follow on with some comments.

8:30Great. Sure. So risk appetite is, at least in the cyber world, one of those terms that we toss about. But operationally, it seems to carry no weight, virtually no weight, right? It's not driving decisions. It isn't used explicitly very often. And even when it is, I would argue that it's used ineffectively. The definition of how we define risk appetite for an organization is typically very offhand and largely ambiguous, and therefore, not nearly as meaningful as it could or should be. Because risk appetite provides an important threshold for decision-making, right?

9:27We can measure risk all day long, and the measurement process can be enlightening. The results can be eye-opening. But in terms of what we do with those results, the value of the risk measurements is much greater if we have a well-defined threshold to compare it against, to say, "How much do we care?" We see from this analysis how much loss exposure this scenario or set of scenarios has.

10:07How much do we care? You know, we might have a subjective, it feels good, it feels bad, but from an organization perspective and a decision-making perspective, you really need some sort of more tangible threshold for comparison so that you can make choices, and potentially defend those choices. Sure. Dr. Bob? Okay, let me pick up on the comments that Jack made, and let me try to give the perspective of a chief risk officer, if I can. Please. And layer in a couple of other things.

10:52So, real-world example, how we set risk appetite was if you picture a matrix, and running down the rows were all the businesses, business A, B, C, D, E, and so on. And running across the column were all the risks. Now, the risks can get very granular, but let's say you have market risk, credit risk, operational risk. Cyber risk is an operational risk. Model risk is an operational risk. Business risk, reputational risk, and strategic risk. So, risks running across the columns, the business running down the rows. In that matrix, you set the risk appetite. You put limits in that matrix.

11:33So, that matrix describes how much that business can take on that risk. Now, if you go across, if you take a particular business and run across the row, you have a limit for how much risk that business can take on. And that limit is not the sum of the individual limits, it's a smaller number to allow for portfolio effects.

11:56And running down the columns for an individual risk, what you have is, again, you have a number on the bottom which tells you how much of that type of risk you're allowed to take across the business. Now, if you sum up all the rows or sum up all the columns, you have kind of a limit for how much risk that the organization wants to take on. Now, this matrix, very serious.

12:24The sum of all those risks is a risk that the bank takes on, with limits on it. That might be discussed at the board. The board doesn't get into the granular details of that. Now, you have a couple of other things in that risk appetite matrix because there's a driver of how much expected loss you can take. So, same thing, same matrix, same filling out all the spots, and then there's also a place for capital as well.

12:55And so you have very complicated matrix, and then separately from that, but connected to it, you have risk-adjusted returns that you need to get in terms of achieving the kind of objectives in the risk appetite matrix. From Jack's perspective, this would be in the decision support control part of FAIR-CAM. So, now what would happen in this matrix, each, let's say for example, and it was very serious because let's say every morning for the market risk piece, on the trading side, we would meet 7:30 in the morning. Every morning, every day, there would be opportunities in that meeting for the part of the trading room where they're separating foreign exchange,

13:45commodities, equities, fixed income. If you look at the risks, maybe one business unit wants to take on more risk than their limit allows, but another business unit would have room, so we quickly do a swap. Now, all this would be automated, but it'd be very serious. And you couldn't go over a limit. If the market volatility went up, you may jump over a limit, that kind of thing, but you're not allowed to go over a limit. If you go over a limit, you could be fired for going over a limit. That's how serious it is, because if you willingly go over a limit, you have some difficulty, and that was written into the policy. So, picture this matrix that also was connected to

14:31your risk-adjusted returns. And I might just say a few words about risk-adjusted returns. You wanted to- Yes. You want to put up a slide, Andrew, on that? Your slide, and I'll try to talk, do my best to describe it. Is this the one? That's the one, yeah. Cool. So, I'll watch the clock here, but so Andrew was kind enough to put together these slides for Jack and me, and you might look at this first bullet point.

15:01RAROC equals return, call it net return, minus the expected loss, minus the control cost, divided by economic capital. Now, economic capital is different than regulatory capital. Regulatory capital tells you what regulators want you to hold. Economic capital is the real risk. So, I'll try to use numbers here. Let's say your net return is 15 dollars.

15:30And you can call it 15 million if you want. Now, I have an expected loss in running this business or this deal, and let's say my expected loss is seven. And then I have to subtract off my control cost, which is three. I'm putting control cost because I'm going to come back to FAIR-CAM. So my numerator is 15 minus seven minus three, which is now going to be divided by economic capital. Now, I'm going to throw out a number. Let's say the economic capital is 25. Now, what is economic capital? It's the difference between some percentile, like 99.5%, we'll come to that later, and some expected loss. But let's say that number, I do that ratio, and it's 20%. Now, the important thing about RAROC,

16:25it's not an academic idea. It's a serious idea, because if you're sitting in the bank or you're sitting in the business, you have to beat a hurdle rate. So a hurdle rate is a benchmark. The way you set the hurdle rate is a very formal process. Theoretically or analytically, it's driven by something called the capital asset pricing model, but it's got academic integrity.

16:53Now, so let's go to what this is all about. Let's say, for example, you say, "I want to spend more on my control cost. I want to spend more because I think if I spend more, I can reduce my expected losses and reduce my economic capital." So let's say I do that. I take that number which I had spending $3 million, now I pump it up to 6 million.

17:20And I lower, because I've got better controls, I lower my expected loss to $4. So now the math is 15 minus 4 minus 6, which is now divided by economic capital, and economic capital, I've cut the tail to 10. Now my new RAROC is 50%. So by spending more on what I want for my controls, I'm able to adjust my risk-adjusted return on capital, exceed my hurdle rate.

17:56And if you exceed your hurdle rate by a certain amount, you get a bigger bonus. I like the bonus part. Like the bonus. I'd like to sign up for the bonus if I could. And I'm just going to pause you there, Dr. Bob, because something jumped into my mind from yet another reference to the National Association of Corporate Directors. But I was at a meeting there, and I was hearing a CEO of a company called, well, I shouldn't name the name because Chatham House Rule applies, but for a large healthcare organization. And he was talking about his organization in terms of assets, right? I mean, it wasn't business divisions, it was assets. And so in my mind, I made this kind of connection back to conversations you and I have had about

18:38the evaluation, right, of how RAROC can impact company, product, or service, right? One of the key findings for me, if you will, we talk about this tapestry concept was looking at risk scenarios, right? Identifying, making, and looking at risk scenarios, and then looking at the controls that are in place, and understanding whether or not they're being effective so that we can do appropriate kind of risk quantification. And then using some measure of control, effectiveness, and analytics, right, as a means by which to bridge the gap between here's the scenario, here's the output, here's the controls that I'm recommending. Now I want to use some type

19:23of methodology, right, to evaluate these controls, right? And where my mind went on this over a year ago was, oh, RAROC, right? Like, we can use RAROC, and I know that you constantly remind me that there are other ways, other measures in the financial risk analysis world, but I've kind of glommed onto that. And so my point is this, right?

19:42Coming out of the risk scenario analysis, right, we are always looking at things like, I don't know, controls and control analytics. And I wonder if anybody on this panel has done any thinking around control analytics. Let me go, Jack, is that something you've ever thought about? Analytics? Yeah, control analytics, right? I mean- No, it's completely unfamiliar to me.

20:07- No, I mean, for those who aren't familiar, I created a model called FAIR-CAM, or the FAIR Controls Analytics Model, a number of years ago, and it's now an open standard that attempts to define how controls affect risk, both individually and as a complex system. And the simplest way to think about it is, if you think about sort of the control libraries that organizations have, the list of controls that they implement, you can think of that as an equivalent to anatomy in medicine.

20:49Whereas FAIR-CAM, my controls analytics model, is intended to be the equivalent of physiology, defining how these things, again, how they affect risk both individually and as a complex system. And that's, as far as I'm aware, it's unique in that regard and really closes a very important gap in terms of really understanding and measuring, empirically measuring the efficacy of controls, especially over time. And so that's what that's about.

21:27But one thing before we go further down this path, and it's related, is when it comes to having a well-defined risk appetite, when you have, say, a new finding, audit finding, or some control deficiency that's been identified, if you have well-defined loss event scenarios and risk appetites associated with them and such, you have the context then for understanding how much this control deficiency matters, right? If we fix this, how much do we...

22:06If we don't fix it, how much more risk do we have than we thought we had before we knew that this control was deficient? If we fix it, does that bring us back under? If we've exceeded our appetite, does that bring us back under, right? So- Yeah, I just wanted to tie that into the risk appetite discussion explicitly, that that appetite is important in this respect, too, for giving context to deficiencies. Because if I have several audit findings that on the surface look significant, but really don't move the needle in terms of where we stand relative to our appetite, then I don't care what my subjective feelings about the findings are.

22:55They aren't going to be a priority, or they certainly shouldn't be. So, I just wanted to tie that in. But- No, I appreciate that. I think it goes down to a topic that's near and dear to my heart, which is control effectiveness. Mm-hmm. And I challenge everyone that is listening to help me with this. So, when I first ran into this notion of FAIR-CAM and control analytics, I went and did some research around one of the key topics that you talk about, Jack, in this realm, which is control effectiveness. And I was like, "What other standards, frameworks are there out there for control effectiveness?"

23:34And everything that I found, and granted, I am cyber in origin, right? So, bear that in mind when I make this comment, always pointed to control maturity, right? And control maturity and control effectiveness, not the same thing. Right. So, if you could comment on that kind of your thoughts on effectiveness, right? And why that's so critical. And if you want to throw in a comment about maturity, I'm not going to hate you.

24:02But to be fair, right, this is really helping you set the tone for why understanding effectiveness, both for a single control and in aggregate is important, if you wouldn't mind, Jack. Sure, sure. So, control effectiveness is not a single measure. You don't directly measure control effectiveness. It is a function of several parameters, right? Sort of the inherent or intended effectiveness of a control, but also how much coverage the control has over the relevant parts of the risk landscape and how often the control goes into a variance condition. It becomes degraded in some fashion. And when it does, how long does it stay there, right? And those are

24:49frequency and time values that are critically important. And in fact, in the modeling and simulations I've done, those are key parameters, right? And if we get to the point of talking about KRIs or KPIs, variance frequency and variance duration and coverage are all KRIs and, or KPIs, depending on how you want to apply them. But- - ... so efficacy is not something we measure once and then it's good, right? And we certainly don't understand efficacy by checking a box and saying, "Yeah, we have that."

25:32Right. Right? No, for sure. Tells us almost nothing. And more often than not, leads us to inappropriate conclusions. Sure. But and the nice thing about these more specific parameters is they have well-defined relationships in this functional model, FAIR-CAM, that allows us to do some very effective mathematical operations to do the sorts of measurements and comparisons and whatnot that we need to do. And it also, and this is critical, very often remediation isn't, "Well, we need a stronger control. Let's go spend more money on a new control," right? A new version of whatever.

26:24Very often it's, the problem is a lack of coverage, or the problem is the darn thing keeps breaking, and there are very specific reasons for why it keeps breaking. So, our actions can be far better focused and more effective in themselves so we can be operationally more efficient. Sure. And just have fundamentally better understanding of what's going on, what's breaking, why it's breaking, those sorts of things.

26:59Excellent. So, control effectiveness, Dr. Bob. I think you might have a thought or two on this, perhaps. I might. Just one other thing. When we talk about effectiveness, and you saw in the stylized RAROC example, and when you saw the risk-adjusted return, that's efficiency. Mm. So, you're tying the two thoughts together. I am spending more on controls in that example, and I am getting a better risk-adjusted return.

27:34So, I'm spending my money wiser to produce a result that gets my business moving in a direction that I want to get into. So, lots of interesting language around that. So, let's maybe step back a little bit, and when I first saw... Yeah, this is a good one. You can leave this one up for the moment. When I first learned about FAIR and I saw a loss event frequency and then loss mitigation, and then if you drill down a level, as you know, when you see threat event frequency and vulnerability, and I was trying to understand what you do when you drill down, the word vulnerability began to mean a lot more to me as I began to understand. That's where

28:22I see the effectiveness coming in. So, imagine for the moment that I'm looking at, I have got two controls. And I'm staying at the preventative layer, and the two controls are trying to reduce my risk. Each one of them, each control has a certain effectiveness described by, I give it a distribution, and I give it, let's say, a beta-PERT distribution. And the beta-PERT distribution, as you know, I think you have a slide there that you wanted us to use? Yeah, sure. I'll bring that up. Go ahead, Jack. I mean, Bob. So, with that distribution, as you know, you can characterize it by some minimum, some maximum, and some mode. So, let's call that the vulnerability minimum. There's a

29:15vulnerability maximum, and there's a vulnerability mode. And so, when I think of all, there's effectiveness, and then if I take the flip side of effectiveness, that's where you have your vulnerability discussion. Now, with the two controls that I've got in place, each one of those controls, let's say one control has an effectiveness of 80% in Jack's terms. So, there's a 20%, it's acceptable at a 20% level, let's say. And another control has an effectiveness, let's say, of 50%.

29:57And so the vulnerability also there is 50%. So, I've got two controls. Now, if I want to look at the expected effectiveness between the two, which is important because I got two controls, I ask myself, "What does my system look like?" If any one of those controls work, let's say I'm good. So both have to fail. So what I'm going to do, my mathematics here, is I'm going to take this control one, compute vulnerability, 100 minus its effectiveness, control two, 100 minus its effectiveness, multiply them out, and especially if I'm doing both of them on an expected level, I get an expected effectiveness in the end.

30:45Now, with that expected effectiveness at the end, now I got something really nice. Because I could take the threat event frequency, expected of those, the expected effectiveness, and multiply it by the effect of loss mitigation, and then I have my average loss expectancy. That's a very nice result to get. And when I run my Monte Carlo simulation around that, that's where I can get my 99% level, whatever level, and subtract it off against my ALE. So, it's a very complicated but a very formal system which I can embrace, because now I can use it not only for cyber, but I can use it across all my risk. There's nothing that I've said that limits it to cyber.

31:37And then what I could do, from a control point of view, I could say, "You know, that control that I've got, which has 50% effectiveness, the way I've described it, I could do better than that." And I want to sort of spend more money or do something else, and I want to raise that effectiveness. So if I'm raising that effectiveness, I want to spend more, let's say, or do something to raise that effectiveness, I could do that same calculation again and increase my overall expected effectiveness in a way that I can price out the value of what I'm making on that spend.

32:21Without this a bit... Now, if you go back to that diagram, the one that shows threat event frequency and vulnerability, I think the architecture of this is very nice. And when I first looked at it, it took me a little while to understand this threat event frequency and vulnerability and how they work with loss event frequency. I guess if you have the data, you run with loss of event frequency, you don't need to drill down. But then when I thought about drilling down, I said, "Wait a minute, from an effectiveness definition, it fits very nicely into this framework." Obviously, you can drill down some more. So when I think about effectiveness, I can relate it to RAROC, risk-adjusted return,

33:02and I could relate it to something, that matrix that I told you about, that risk appetite matrix. If I spend more and I look at net risk, my net risk has limits on it. So this ability to be able to use my controls systematically across my organization in the same framework or the same organizational way of thinking about it is a very important part for risk management, and more than just cyber. And that's a very interesting conversation to have. I just want to highlight this if I... Go ahead, Doug. Please, Jack.

33:38Yeah. I was just going to expand on or elaborate on what Bob said about the agnostic nature of both FAIR and the controls analytics model. They can be applied to any form of risk, and even though they were born in the cybersecurity space. And some of the nomenclature around them sort of leans into the cyber side of things, but the models themselves are agnostic and have been well used in other forms of risk. So I wanted to point that out. And the other thing I wanted to point out as well is, when you're looking at the efficacy of controls and especially combined efficacies, you always want to keep in mind the potential for correlated failures and those sorts of

34:31things, right? Because the control landscape is a complex system. There are a lot of dependencies and relationships there. And having a clearly defined analytic model goes a long way to identifying where those potential joint levers for failure might exist, and allow you to better estimate correlations and hypothetically measure correlations over time, and those sorts of things. So, I just wanted to throw that in as well, that sort of physiological nature of the control analytic model is really important in that respect also.

35:17You know what's interesting, as you say that, Jack, I'm brought back to yesterday. I was talking to Ayoub Fandi, right? He's one of the originators of the GRC engineering concept, and one of their prime tenets is we can't do effective control analysis if we're measuring something once a quarter and saying whether the control exists or not, right? And so, that notion of this kind of continuous control monitoring, whether it's cyber or some other operational risk, right? That becomes kind of a key here, right? To kind of provide the data perhaps, right? So this model can then function, this whole notion of tapestry. Any quick comments on that, Mr. Jones?

35:59You're 100% correct. I mean, again- Again? Again, yeah. More than once today, which is we should notify the press. So, now I've lost my train of thought. Oh, darn it. Continuous control monitoring and significance for powering FAIR-CAM. Yeah. So, we have, in terms of data, again, especially in the cyber space, a lot of the telemetry we have is control-related telemetry.

36:38But in order to make good use of that, we have to have some sort of model to interpret that data through, right? So there, again, having an analytic model is really useful. And then, I may be jumping ahead a little bit, but- Please do ... when it comes to AI, and the speed at which that landscape changes, being able to automate the monitoring of the many controls we can, should have in place for AI, having a strong model for understanding what matters and where a thing stands and what's changing and how much those changes matter, I think is going to be really important.

37:30So you bring up a really critical notion here, right? So, for those of you not coming from the cyber sector, right, the FAIR standard might be something, the open FAIR standard might be something that's new to you. For most of the other folks, this is something that you know well. It's a standard, it's a model. So let's turn to our conversation around model and model risk and backtesting and variance analysis, three very kind of key concepts here.

38:00You mentioned it a little already, Jack. You talked a little bit about variance analysis. And I think one of the things that always impacted me was how you talked about it by looking at it over time, right? And why that's so important. Can you comment on that, sir? Yeah. Well, controls are not static things. They change over time.

38:24Either intrinsically they change, or their efficacy can change extrinsically when the threat landscape changes, right? So, being able to understand that is- Essential, isn't it, in some respects, would you say? Yeah, absolutely. Because, I mean, at some point we want to be able to test our model, right? And so- Well, that's the other thing too. When we have a strong analytic model, right, we apply a model, let's say a model we believe is strong, or we hope is strong, we apply it over time and then we're able to backtest it.

39:10In the absence of a reasonably effective control analytics model, we can't do that sort of backtesting, at least I would submit, not and understand where it's failing. I mean, we can look at our previous risk forecasts and say, "Well, out of these however many forecasts, how closely do our forecasts match what's actually transpired over the past period of time?" But let's say that our forecasts didn't always work out the way they thought they did, right?

39:48A big part of that can easily be the controls landscape. And without a model for evaluating the controls landscape, I think we're hamstrung in terms of really understanding why things didn't turn out the way they did. And, of course, also in terms of the controls model, if the backtesting shows that our forecasts were not what we expected them to be- - ... and we turn to the controls model, we might very well then find that the controls model itself needs adjustment, right? So, I think one of the biggest- It's all woven together, isn't it? Like a, what's the word I'm thinking of? Oh, like a tapestry.

40:37Tapestry, yeah. - Dr. Bob. In one of our conversations, you noted that it's in your world, right, quantitative models, right, are formally back-tested, right? Like, that's part of the formal process, if you will. Can you share some of what that means or the experiences you've had with doing that back-testing and why that's important? Yeah, good point. I just want to make a few comments.

41:07Please. First of all, when we talk about the formal back-testing, and I'll give you a couple of examples. Every... Screen looks a little blurry. Every model that you use, let's say in a financial institution or where you have a chief risk officer, which by the way, chief risk officers are now in utilities, airlines, and so on and so forth. So, we're beginning to see a lot more formalization. But when you have, in this case, when somebody proposes a model, a model that is going to be used to calculate risk, and they put together the analytics, the first rule of thumb is somebody has to independently vet it. So, person A develops a model, person B has to independently vet it. And they're not

41:59allowed to really look at the derivation of the first model. Mm-hmm. They're supposed to really do it truly independent and then see if the results are the same. And that's a hurdle in itself. The second thing is for every model that's being used, you have to put together a vetting book, and it's got a table of content. Where'd you get the data from? What is the academic theory? Why the model you're using is the right one?

42:29Et cetera. And then including in it, have you back-tested it? What happens with it when the market goes into stress? Does the model maybe not work? So, if we want to make it broadly, I think there are two issues with model risk, and two big buckets, I would say. One is the kind of thing that Jack was talking about, where you have model error. The other is model implementation. Model error would be where I select a distribution. I think it's beta pert, but it's not. It's really log-normal. I got the wrong distribution. That's, no, I want to make sure I have the right distribution. The other thing is, assuming a model is so-called stationary, but it's dynamic model, it keeps on changing on you. Something happens, maybe

43:19there are jumps or outlier points because there's something happened that jumps, and the model no longer applies. Where does it break in a stress market? That's a model error. And then the second bucket is maybe it's implemented wrong. Maybe the code that you wrote didn't quite express what you're supposed to be writing. That's possible. Maybe somebody committed fraud. Maybe somebody got into... And with AI, I listened to several of the presentations, one on risk appetite, one on AI, one on legal risk.

43:56Very interesting. So, with AI now, with AI, the ability to get in and break the code, get in there and do some dastardly things. - By the way, two types of AI. AI large language models and AI itself. Like, AI would be anomaly detection routines, which have nothing to do with large language models, right? I'm looking for some sort of amusing and artificial intelligence technique to find outliers. So, lots of reasons why models go wrong. And so, if you think of these vetting books, the regulators would come in, like the Fed, the FDIC, and the OCC in a bank. They'd say, "Show me your vetting books."

44:44And they'd pick a couple out, and they see it would have all the pieces. The rating agents used to come in, like Standard & Poor's, Moody's used to come in, and in the dialogue, we would show them the vetting books. And you might not be aware, when Standard & Poor's makes a rating of an entity, not only do they look at, let's say, certain fundamental ratios, what is this EBITDA divided by interest owed, cash coverage ratios. They also look at the end, what is the quality of the risk management that's taking place in the organization? So, let's say they give you a rating of A+ as an entity. If they don't like your risk management, they'll lower you down a notch or two, maybe to A-

45:31Hmm. If they like you, they may... And there's a formal process that I did some work with S&P that's very interesting. They would like, I think, what we're talking about here today in terms of a lot of the topics that were discussed yesterday and today. Let me give you just a quick example. Please do. From cyber risk, in terms of a back-testing, I could do the same thing for credit risk. It's interesting. Let's imagine for the moment I'm sitting in the trading room, and I'm saying that there's a 1% chance I could lose 10 million a day. It's more like 100 million, but let's say 10. There's a 1% chance I could lose more than 10 million. Now, dynamic, it changes

46:15every day. It's not the same number every day. Volatility goes up, volatility goes down. People put on more positions. Now, so if you're setting yourself up at a 99% confidence, now there are 250 trading days in the year. DeFi, decentralized finance is 365 days, but let's say there were 300 days in a year. So, if you've got a good model, that means in one year, 300 days, only three will exceed- 10 million, right? That's the mathematics of this, right? If there's a 1% chance that you're going to be bigger than 10 million dollars of loss any given day, in one year, you can expect three.

46:58So, the regulators give you like a green zone. You're allowed four exceptions. That's it. If you get more than four, you get into what they call a yellow zone, and a yellow zone is between five and 10. And if you got more exceptions, what I described, they ratchet up your capital. And over 10 in the year, you're red. They would send something to the board, gets very messy. So we kept track of how many exceptions we had. And if one a quarter was okay, but if we had two or three that quarter, we would tell a regulator right away. So it's a kind of a back test that people take serious. Now, there is same back testing for credit and same back testing for

47:48several other things. And from a fair point of view or a FAIR-CAM point of view, that's where the variance dynamic comes into place. Variance dynamic is looking for the drift, right? Maybe drift in efficiency, maybe drift in the way my models are operating. What's interesting, by the way shamelessly in the book- - ... in the risk book, if you look at the forward, the forward was written by Myron Scholes, the Nobel Prize winner. He talks about this, very interesting.

48:26And what he says in the book, "You got to have the academics right, and the practical piece has to be right too." Don't kill yourself with very sophisticated mathematics that nobody understands. Don't make it too simple, but make it parsimonious so that it works. But just make sure that the academics and the practical side come together.

48:50And the practitioners don't appreciate the academics, the academics don't appreciate the practitioners, all of that. But very, very interesting discipline when it comes to model risk. And it does relate to the... I'll just say one other thing, Dan. Risk appetite. In this world, risk appetite is not just something you look at and don't pay attention to.

49:13If you do, you don't have a risk system. It's a good test. If you're not paying attention to it, you don't have a good risk system. It's a very simple test, right? A good one. But all these pieces, tapestry, they come together. Yeah. Sure. Yeah, no, absolutely. So I'll stop here. Yeah. Yeah. I want to go back for a second to something that Jack mentioned, because I think it's really critical here, right?

49:37So, being able to use whatever model that you decide on, being able to use it across multiple risk disciplines as appropriate, I'm going to say that again, as appropriate, right, is important, right? So you have some consistency. We were talking the other day, Dr. Bob, about climate-related risks, right? And so, I know that you had some thoughts about how the FAIR model, right, could be applied to climate risk potentially, or something along those lines.

50:12I think you're right. Maybe Jack might want to say a few words about that upfront. Yeah. We'll let Jack speak. Yeah, go ahead, Jack. I'll be brief because I think Bob has more useful things to say about it than I do. This is not scripted, by the way, if you just thought it was. So, at the end of the day, if we're going to measure risk, what we're measuring is loss exposure, expected frequency and magnitude of loss for loss event scenarios. And if we can enumerate one or more loss event scenarios in any risk domain, including climate, then we're perfectly positioned to measure it if we have a model that's suitable for that. And then one of the nice things about FAIR and FAIR-CAM is they're based on first

51:07principles, which is why they're agnostic and why they've been so stable over time. And if we have specific climate-related loss event scenarios, then we can do these kinds of analyses and make better decisions. And I'll stop there and let Bob run with it because I think he has more smarter things to say than I do. No, that's interesting.

51:33Time will tell, Jack. Yeah. So Jack comes up with all these good ideas like applying FAIR-CAM and FAIR to climate risk. Very interesting insight. Now, it turns out, because that they have there's a formal approach to climate risk by something called TCFD. There was a task force on climate-related disclosures. Now, that task force was floating around, and in the way of background, they said, "We got to do something here."

52:09And they said four things. You got to have good governance, right? If this climate risk is important, where are you going to discuss it? You discuss it at the board? Do you discuss it at the management committee? Where are you going to discuss it? You have to have a strategy. What are you going to do? How are you going to change how you're operating? What are you going to do differently? That's the second thing. The third thing, how are you going to manage the risk? How are you going to measure the risk? That's the third thing.

52:33And the fourth thing was, what is benchmarks are you going to have? This is formal. And so this became almost a mandatory. And you might see, if you look at a bunch of annual reports, you look at 10-Ks- And you see in annual report, you'll see a whole separate publication on TCFD. It's very interesting, and they talk about all these things. Now, it turns out also, connected with that, FEMA, and this is the interesting part, FEMA has a database, ironically, of 18 hazards. Wind, rain, tornadoes, hurricanes, and all these things.

53:16And what they do in this database, they break it down to impact on three things, properties, agriculture, and people. So, what damage to those? Why they picked those three? They could have picked more, but they picked those three. And they have historical data. They have what is the frequency of these events and what is the magnitude of the pain? So, they take loss event frequency, the equivalent of, they don't call it that, right? Loss magnitude, the percentage, they multiply it by some exposure they've got, and they calculate for each one of those categories, property, building, agriculture. They add it up. It's an expected value calculation. They don't

54:07calculate 99% or anything. And so they do this for each census tract. So picture this. So they run it for each census, and the US is broken up into many census tracts. They add it across all the census tracts, and they have a climate index. It's very interesting. And then they allow you to put controls against it to reduce that risk. So, I'll give you one example, a very simple example. And if you have a mortgage, and the mortgage is sitting in a fire zone, you're going to raise your probability default over not, right? That's your frequency. And if you're in a fire zone and your house burns down, that's going to hurt, right? That's your loss given default. That would not be an ideal outcome. No, I

55:00would agree with you on that one. That would not be an ideal. And by the way, same thing with a tornado or hurricane where I am, earthquake. So, what's beautiful, perfect application for FAIR-CAM. Data's there. Controls here are very important. They want to see controls that reduce it, and it has nothing to do with cyber. So what's beautiful about it, Jack calls it first principles, I think everything fits FAIR-CAM.

55:26So, it's a very interesting set of dynamics because you have a whole series of sustainability officers now who are taking under their umbrella climate risk and having to deal with it. And it's a different chief sustainability officer might not know much about risk management, but they embrace it. Sure. Because it's part of their... And they don't have big staffs.

55:56But- Well, two things have occurred to me, Dr. Bob. Number one is discussing Tapestry, talking about models and control effectiveness through the lens of you two fine gentlemen, right, could occupy, I think, an eight-hour day rather than a one-hour session. And so I'm recognizing that to call myself out for not moving along through our proposed agenda as swiftly as possible. But I still believe, right, that we have captured kind of the core concepts around Tapestry and some of the core elements. As we're coming up to the end of the hour, I'm going to pivot, as somebody put into the comments, and pivot back to Tapestry, right, and where you see Tapestry, how you see Tapestry and you're

56:46thinking about as you go forward. Jack, and I'll turn to you first, and I have this mental picture of the reality of somebody that thinks about control analytics, not as I created this one analytics model, and that's the end of that discussion. There's probably more that you're thinking about as you go down that path. Is that true?

57:11Oh, certainly. I mean, we're just scratching the surface. This is an early work, I think. Even as good as I'd like to think it is, there's undoubtedly we'll find ways to improve it and innovative ways to apply it that we haven't thought of yet. So it's, yeah, still a work in progress. And again, Tapestry is sort of this binding cloth or whatever you want to call it, this glue that brings together these different really important pieces of the risk management puzzle, I think is a great opportunity for us to broaden our thinking and broaden our application of pieces, parts, perhaps like FAIR-CAM in ways we hadn't thought of before.

58:14And I'm going to use that to pose a challenge, a challenge to everybody that's online here who registered that will watch us in the future. I think that applying as many potential brains to this challenge, right, of where do we go with control analytics, and then how do we use that to inform- existing financial risk analysis models, right? Like, I think that's something that as an institute, ERQI will continue to focus on. And I challenge everybody that's on this call to help push that forward, because I think that ultimately will make a significant difference in evolving internal enterprise risk quantification, if I could be so bold.

58:56Agree, Mr. Jones? Agreed. Excellent. Dr. Bob, so many questions I could ask you right now based on a lot of the content you provided, but I'm going to have to force you to go into summary mode, good and kind sir, and leave us with deep, reflective thoughts of Dr. Bob Mark on the topic of Tapestry. Well, first of all, let me say that, and I'm listening to some of the presentations yesterday and not yet today, but listening, I got a lot out of those presentations, and there's a lot of wisdom that's embedded in those presentations. I say it that way because I like the idea, and this relates to Tapestry. You have different communities.

59:41You have the cyber community. You have the traditional finance risk management community. You also have the decentralized finance community. And somehow they don't come together. They stay in their little, their silos. They meet a lot, like in the global traditional finance community, there's two or three conferences every week. I would say one a day, somewhere on the planet.

1:00:07And yet, that community is not familiar, in the main, with cyber risk. And there's a lot of wisdom in the cyber risk community. There's a lot of wisdom about what can go wrong with AI. A lot of wisdom in terms of, from a model risk perspective, if I am using AI to help me manage risk, I have some issues there. What's my intent? What about the autonomy of what I want to give those? A lot of details.

1:00:38And so while traditional financial risk managers are very sophisticated over 25, 30 years, let's say, in the making, I think learning from each other and learning from each other's expertise, that's part of that tapestry. I think it's very important. I know I've learned a lot in the last year. Isn't that interesting, huh? A lot. Yeah, absolutely.

1:01:00And all of that coming together, the knowledge, the ability to share information, the ability to be able to, step by step, do things slowly but get there at the right pace. Because if you go too quickly, you kill yourself. If you go too slowly, you're sort of falling behind. So I think my definition of Tapestry, I want to throw in on the human side- Mm-hmm ...

1:01:25and see how all the pieces come together. I think that part's very important about Tapestry. Yeah. Excellent. Well, thank you both, gentlemen, for your time, your wisdom, and your thoughtfulness, and occasionally laughing at my quasi-humorous attempts at comedy. So appreciate all of that as always. I do want to make a quick note before we step over to the next session, that there are a couple different things that we're working on from a Tapestry perspective as kind of next steps. One of them is actually using Tapestry to evaluate risk in a home loan origination, home loan mortgage providing scenario. So we'll actually have a use case to demonstrate how Tapestry

1:02:10gets used. And we're going to complete that sometime in 2026 with any luck. So we'll be able to show people how you can apply Tapestry to both looking at risk for an agentic AI-based application, both at a overall application level as well as at the agent level. And I will just leave that teaser there. And thank you again, gentlemen, for your time.

1:02:34And if you want to stick around and answer anything in the Q&A, feel free. Otherwise, I will look forward to talking to you both soon. Just one last thing. Yeah. Oh, yeah. Put it out there. Put it out there. Yeah. Listen, a lot of the stuff that I mentioned today is in this little book. Yes, I put that in the chat just so you know, with the link to Amazon, good and kind sir, so. And as I said, I welcome conversations and communication because I learn a lot from that communication.

1:03:02Beautiful. And so I am very open to any kind of exchange of ideas. How's that? And I can validate that that's true because he's been willing to speak to me. All right, gentlemen, thank you again for your time, and let's roll on to our next session. Yeah.

0:07So I welcome to the stage one Marco Nutini and one... Who's that other guy? Oh, Graeme. Yeah, that guy. Graeme, are you joining us? Yes? No? Maybe? Let's see. Where is he? Where is he hiding? Well, Marco, while I- He was here, and he was a panelist, and he has disappeared. So- Okay ... I suspect he got inadvertently disconnected, and- Okay ... will be back shortly.

0:48Cool. In the meantime, why don't you and Marco, I'll keep an eye out for him if he shows up as an attendee. Got it. I got him in. I got you. Got you. You guys get started. Yep. Marco Nutini, I just must say, sir, how are you? Fine. Can you hear me well? Yes. I want to share with the crowd that you have one of my favorite domains that you use, which is, what is the name of your domain that you use?

1:16The sleek. Risk Leap, and then there's another one, Loopnut, is it? Loopnut's my consulting business, yes. Okay. Loopnut. So Loopnut. Just for some reason, that speaks to my heart, Marco. I'm not sure exactly why. Well, Loopnut, it's an English word, so that's why. Brazilians- All right. That was my favorite comment of the summit so far, Marco. Brazilians feel sophisticated when they use English. - Graeme Keith, I can see you in my panelist list. I can't see you, though, because your camera is off.

1:53Yeah. Can you hear me? Yeah. Excellent. Yeah, camera, working on that. No worries. So, but let's talk about the session. And I will just give some overarching remarks, and then, Marco and Graeme, I'll ask you to comment on the opening remarks, and then we'll move on to the full discussion. So- Awesome ... one of the things that I have learned a tremendous amount this year is about this concept of ontology and why it's so critical. And thrilled and excited to have two people who are experts in the area of ontology with us today, Marco and Graeme. And so one of the things when we were starting the institute, we were talking about it would be great to do some

2:41research and some surveys around the use of ontology and taxonomy, really, to a certain extent as well, since we're plagued, right, in some cases by misuse, what some people would call misuse of the terms. But really, that's really not the point, but it's how are we applying these concepts, right, to solve these problems in a consistent and unified manner? And so Marco was kind enough to do some initial surveys which were very interesting, some of the results, in terms of like, how are we defining risk and other kinds of elements there. And so, that was the initial research, and Marco has taken that completely down a path of looking at this with respect to AI

3:25and AI-ready risk networks. So, that's kind of the context, if you will, for our discussion. I am lazy, so Marco, would you introduce yourself, though? And then Graeme, feel free to introduce yourself as well, please. So... Okay. So, well, I am Brazilian. Okay, so you're going to notice that I have a little bit of accent. I try to imitate Graeme because I think British is like a 007 kind of deal. Right? But I can't. I have this Italian-Portuguese nature in myself, in my DNA.

3:59And as you can see by my beard, I'm pretty veteran, so I have 50 years of engineering now and more than 25 years in risk management. In Brazil, most of my clients are in Brazil and Portugal. Okay. And I'm specializing these days or going deep into the use of AI and knowledge graphs and risk management. Excellent. Graeme? Yeah. Sorry, we're going to have to do without a picture for a little bit. I'll try and get that- That's fine, man ... fixed- No worries. That's fine ... when Marco's doing his thing.

4:36Actually, the reason is obviously that I'm just not as handsome as Marco, and I just didn't want to- ... show it up there. I may have the 007 accent. Although if I have a 007 accent, it's obviously a Roger Moore accent, which is nowhere near as cool as actually looking like Sean Connery, which Marco very clearly does. So I'll just speak with that accent and we'll let Marco do the Sean Connery look. That's great.

5:01I wish I was. - Okay. So yeah, Graeme Keith is my name. I'm an independent advisor, work with risk quantification, all sorts of things. Very interested in this whole ontology piece and, yeah, very excited about the work that Marco's been doing, both in terms of the survey, but also more generally in terms of using graph theoretical approaches, particularly with that emphasis on getting the ontology straight in order that we can do something useful with AI. I think we see a lot of AI usage in risk management at the moment. I would say most of it's pretty horrible. And I think what Marco's doing here is really the first essential steps to having something that is

5:49solid, defensible, and immensely value-adding when we finally get all of those pieces together. So very excited about this work and very excited about this presentation. Excellent. Okay. Marco, I'm going to let you lead from here, my friend, if that's okay. Okay. Yes. Let me share my screen here. Can you see it? Yes. It's coming up. So one second.

6:20There we are. Yes. You are screen sharing. Yes. Okay. So we're going to talk about risk networks, which is kind of the same philosophy as tapestry, because what we're trying to achieve is going from static characterization of risk to a networked characterization, where you have risk not only as the main entity, but also decisions, assumptions, objectives, and other entities.

6:51So depending on what you're doing, if you're analyzing a specific decision or if you're looking at a systematic decision or an ad hoc decision for a special purpose, basically the decision is telling what type of risk assessment you have to do, what type of indicators you have to look, and other information. Risk is not the center of the universe.

7:20Decisions are the center of business. So that's what we're going to talk about. Until recently, until before COVID, let's say, more or less, we can say that was very hard to diagram processes and risk inside processes. Many people attempted to have a graph depiction of risk and decisions and assets and all types of objects and artifacts. But the point is that artificial intelligence brings to us an enormous window of opportunity because now you can have digital twins of processes and digital twins of decision processes, which is what we are more interested from a risk management perspective.

8:18We have a physical process. I think everybody knows the notion of digital twins. I'm going to go very fast here. The physical space and the virtual space where decisions are being made. So you can have decision here as information with a human in the loop or information directly to action. Depends on which level you are. Of course, if you are in a very operational level, this can be automated. If you are in a top-level decision, of course, the decision is going to be made by human. But the system is the same. You have a cycle where the data comes from the physical world to the virtual space here.

9:07You have a representation of risk and other uncertainties and measurements and data from the machinery here, let's say. And then you pass information to the physical asset, automated directly or not directly. Okay, today we are used to looking at matrices. They are static. They are relational databases. Relational databases, Excel and spreadsheets, and I think virtually all GRC software that I know use relational databases. So we are used to see risks listed one by one in isolated rules. And we tend to look at it qualitatively. I would say maybe almost 100% of companies still use it because it's what regulators want to see.

10:13And risk management becomes a bolted-on type of activity, not built in in the business process. And it's a calendar-driven activity. So we want to change this, and it's not trivial because if you want to really take the opportunity, this is going to be live. This is going to be continuous, like you talked about in the previous session. So you need a structure that is systemic. It represents a system, not a static table, which we call in general a knowledge graph or a risk network, specifically in our field, but it's a knowledge graph from a technical perspective.

11:14The focus has to become more quantitative, or the scores that you use must be mathematically sound so that you can use them in an automated fashion. If we could keep doing ordinal systems, we're not going to be able to use them in an automated scenario. Risk has to be integrated in the cycle from decision to action. So risk informs decision, decision informs action, action goes back to assumptions, and risk gets changed again because the process is also changing. So everything is kind of in a dynamic system.

12:04And you get the ability, and maybe this is the most important opportunity, you have the ability to be event-triggered. So if you have an incident or event or a deviation from policy, depending on the situation, you can escalate automatically. You don't need all the rituals and all the liturgy that we have today with meetings and committees. You tell whoever needs to know right away having such a system. So it can be demonstrated with an example that's pretty much known by everybody, which is the credit management system. You have risk management basically happens here in a more advanced level where you have simulations here. But it also happens in

13:07the control and measurement phases during the process. So risk management is not only the final quantification or the final exposure assessment. It happens here as well during the process. And you have- And you have three levels, actually. Three levels of decisions. They are connected, and this becomes a live system. It's already there in any credit management system, but it's not mapped. It happens spontaneously.

13:44Things are connected. They are, but timing is not adequate. Information gets broken. It doesn't arrive at the right time. So imagine that you can inform these three decisions with information that's timely and reliable, not from a completely 100% mathematical perspective, but from how it was assessed being inside the criteria, within the criteria, so that you can look at the uncertain and discuss the uncertain at the right time, at the right point. Okay? So basically, in credit management, for example, you have the decision to give or not credit to someone.

14:30It's an operational decision. It happens within policies and guardrails. Then you have a higher level decision, which is kind of managerial, where you change the criteria, you tweak the decision system. And then you have a higher level where you deal with policy and you deal with strategy. Imagine that you can tweak the credit policy by looking at performance with risk at the same time with reliable information. That seldom happens in the real world, even in advanced sets as banks, for example. Okay?

15:16Information is always untimely, broken, not reliable. So you need to connect also risk to performance. You can't really judge risk or assess risk without performance being together and without understanding strategy. You really can't. So this part here, which is the quantification part, already happens in credit institutions, in any type of company that has something to be received from someone. And then you have here your limits and thresholds. You have assumptions that are fed to the simulation. So this is the model that really runs the system from a broad perspective. But you also have to keep client score. You have to monitor payments. This is

16:26as important as this because this feeds this. So what is the ontology here? Ontology is the deliberate mapping of the entities. I'm saying this is a decision, and a decision must update the credit simulation. And I'm saying delinquency rate is a risk indicator. I'm giving it a label in a template. So people, when they look at this, they can analyze and say, "Okay, this is how we call in our company."

17:04And yes, this is a control. Monitoring client payments, of course, is an important control. It's part of the receivables management. So it's not the salesperson, it's the financial person that's going to look at the client payments, and this is going to influence this indicator at the right time to inform this, and then you're going to follow the cycle. So ontology is the template. You can use the same template for other risk scenarios, not only credit. And then you can have a standardization of what terms and relationships mean. And taxonomy is saying, "Okay, we have credit risk, and then we have financial risk, then we have strategic risk," and so on. This is taxonomy. This

17:58is the hierarchy, right? So you have executive decision, technical decision, operational decision. This is our taxonomy for decisions. Okay. Ontology is the taxonomy plus the relationship. So we say risk indicator informs decision. So if you don't agree with that, then my ontology here, it doesn't suit you. You're going to have to think about your ontology. Okay? We're not going to defend here a specific ontology. We're going to say you need one for each use case, and you better have a standard because you're going to have a mess. Now, if you don't want to map and use graphs, you want to stay the same and not use artificial intelligence, it's up to the

18:49organization, of course, but you're missing a huge opportunity, and I think this is going to be a tsunami in a few years. If you start using natural language with a model, a large language model, suppose you have this old graph and everything set up, and then you try to automate credit decision. Okay? So suppose you ask, "Can we approve more credit? Delinquency is low. What do you think?" So you have questions that you're going to ask, right, to the model, and the model is going to, "What's it talking about? What's the policy?"

19:30Which criteria should I apply? I don't know the assumptions. What does he mean by metric? Which portfolio are we talking about? So inside each question, there is a universe of information that has to be where the model has to be trained in. And this is where the ontology comes. How do you train a model in that use case, in that specific workflow without proper terminology and proper relationships? It's virtually impossible.

20:09If you don't do this, what is going to happen? A big mess. Things are going to get clunky. Mistakes are going to be done. People are going to say, "The risk people in our company don't know what they're talking about. They use different semantics in no places. They didn't do their homework of standardization." And I can tell you, it's a big mess. So today, any agent, any AI agent, has data access. So it's very easy to do. Even an old man like me can do that. You can connect, you can map the agent to a point where the data is, okay? A lake or a warehouse.

20:59But with semantic control, the agent goes the right path and understands the meaning of what you're looking for. So it follows a specific path. This is semantic control, right? Because you're using natural language, of course. If you don't want to use natural language, you don't need large language models. You already have data managers that can look for data. For you, it takes what? A week, one month? It doesn't come what you're expecting. So what you're proposing, that an executive can sit and, using natural language, ask the agent to look for data and correlate types of data.

21:53We are famous. Risk management field, our community is famous for confusing semantics. I'm used to be criticized by people from other areas when you teach, when you give a training, and et cetera. People say, "How can you survive this jungle of things that mean the same thing but don't mean the same thing?" Okay? Yeah, I don't know. We go by... We are humans. We are used to language, to the confusing language.

22:30I know that there are words in English that are the same word, have two different meanings, okay? I know that if you say jaguar, it can be a car, it can be an animal, okay? So large language models have a basic training, but when you go in any specific domain like risk management, they frequently get lost and they don't understand exactly what you're meaning.

22:58You may have had this experience, right? So a risk can be a source. Sometimes we talk about volatility as a risk, or volatility is a source of risk, right? We say it's a condition, like a control deficiency is a risk. Say, well, invoices are not being signed properly. This is a risk. No, this is a control deficiency, right?

23:23No, it's a risk. Okay, it's terminology, semantics, okay? It can be an event, it can be an effect. Oh, risk is a probability. COSO says that risk is a probability, right? No, COSO said it's a possibility. Then the third person say, "No, it's a plausibility." Oh, come on. Watch the word, right? So imagine that you are a large language model in this jungle, okay?

23:50And then you have not only the word risk, you have issue, right? Oh, issue is a risk that has manifested. Who told you that? Well, everybody does that. But where was that written? I don't agree with that, okay? Threat is a risk. No, it's a special kind of risk. Threat is threat. Oh, I saw in FAIR. They have risk, then they have threat. They are two different things. Oh, but I don't agree with that. Okay.

24:17So we live with that disagreement, okay? Because we are humans. Even standards. I mean, these guys are rivals, right? COSO and ISO, they are not friends. They want to take the world, and they don't take anything. They are just a piece of paper, right? So ISO 31000 say risk is defect. COSO say risk is the possibility. Marco Nutini says, "Well, let's bind those two together because risk is the possibility of an effect." Okay?

24:53Who am I? I'm nothing, okay? I can do this for my work, not for the world, okay? Logicians that analyze this, and I've been trying this with large language models, think as a logician, okay? How would you see this and say, "I don't understand that because if it's an effect but we can express probabilistically, why don't we use both words?" Okay?

25:19And why use the word event every time? Both standards use the word event. What about a continuous loss? It is a risk? It's a death by 1,000 knives, right? And what about variation, normal variation? Is this a risk, or is just another type of uncertainty that's not a risk? We don't know. Everybody has their own definition, okay? So we said, "Okay, let's do with ERQI's vetting and supervision, let's do a survey."

25:59Okay? Let's do waves so that people don't feel too bored filling surveys. We are doing this as kind of slowing, using a few questions only, and this is still open, okay? It's in LinkedIn. And we launched already three waves. Sorry, we are in the third wave now. These are pretty much settled, I think. Andrew and Graeme were the two vectors or supervisors of my work, right?

26:42I don't know if I'm supervisable, Marco, but I did provide some minimal input. - You were my guru and guide. And Graeme, well, I'm not going to talk about Graeme. I don't talk about religion, right? He's God. And this is the first one. The first question of the first wave was, how do you see risk relative to uncertainty? Why relative? Because ontology is not only about the word and the definitions, about relationships. So I'm going to map a decision workflow. I want to have uncertainty and risk. How do I relate them?

27:26So I asked that, so people said, "Okay, uncertainty causes risk." All right? It's larger than risk, it's more abstract. There are many comments. It's very, very nice. But basically, uncertainty causes risk. That was the majority of votes. And that follows ISO 31000 definition. That's maybe the most accepted, okay? Some people said they are separate entities, but they are correlated, okay, which is different from uncertainty causes risk. Other people said Knight's definition, the Knightian definition from 1920.

28:08Risk is a quantifiable property of uncertainty, which is a nice take as well, okay? If you think you have an uncertainty, risk is what you can measure, you can assess. Okay? Others didn't agree with neither, and some people said they are synonyms. So risk and uncertain, for me, this is a very honest and personal take that everybody, I think, had. Okay? So the problem is not the differences in definition. The problem is the conceptual model. People are using different conceptual models using same words. That's what's happening in our field, okay? Same thing happened with risk appetite, which is a famous discussable word, right, in our field. COSO created this, right?

29:02It doesn't appear in ISO 31000. So I said, "Is this being used?" Actually, it's very used. It's almost universally used in companies, and most companies agree with the COSO definition, 41%. Majority said it's a broad statement, meaning a type of policy or some kind of higher-level statement. And others said, "No, risk appetite is the limits and thresholds and tolerance," which is one I would choose, for example. Okay?

29:39No, it's a decision criterion. It's a decision criterion. 18% said, "We don't use it. We don't want to mess with that." So the problem that we came out is not the ontology. We cannot propose an ontology. I don't think ERQI has the mission to doing this, and we don't want to do that. I think Andrew is going to talk a little bit about that. We don't want that. Ontology is rich use case. It's very specific.

30:12In an organization, I think would be advisable to keep it more standard as possible, but you're going to have use cases in specific domains. Like cyber, you're going to have some ontological perspectives that are different from supply chain or from credit management, okay? And don't expect large language models to be as good as us to understand language difference and idiomatic expressions and so on, okay? It's going to inherit ambiguity, and you have to act on it.

30:51So, advice from us, normalize the semantics before you automate. You're going to put yourself in a deep mess if you don't do this. Convene a workshop or a team in your organization of different areas, different languages, and try to come up with some normalization, basic normalization. Don't automate ambiguity. We have ambiguity. Human beings are ambiguous in language. So choose, specify, test.

31:28Start with one decision hotspot. For example, credit management. Oh, no, we would like to automate our inventory system. There is a risk there. We want to automate some things there, okay? We have to place an early warning system in the inventory system. Okay, go there. Decision hotspot, map it, model, try the ontology. And from there is going to come up what would be your main ontology for the company, which may be very succinct, very small compared to the use cases. Use cases have a more specific ontology, okay? And then you go from there.

32:12I don't dream of mapping a whole organization, okay? I dream of having the most important decisions, the critical ones mapped, which is different, right? But I see that there is a decision, and Andrew, Jack Jones, and Dr. Bob Mark, they talked about in the former session, there is one decision that is mappable, and that's important, which is the capital location decision, right?

32:42So that's mapped as well. It's a high-level decision that have its own system around. So, just to make sure we understand what we're talking about, ontology is not only the vocabulary, taxonomy, and thesaurus. It's also the relationships, so you enter with relationships. And knowledge graph is the production aspect of it. Knowledge graph is what goes into production.

33:10It trains the large language model, and that's what the LLM uses in the production. So ontology is it's before that. It's a backend. What we're saying here, let's move from the old way to the new way. The new way risk is inside within the business cycle. It's embedded in the business cycle. Whether it's systematic or ad hoc, it's embedded.

33:41So first step, choose your decision's hotspot and define ontology. Keep going. The survey is open. You're invited to disagree with everybody. Because it's really fun to see all the perspectives. - Thank you, Marco. Appreciate that, my friend. I think this session for me is particularly interesting because the notion of why I initially supported the concept of doing this survey around ontology, right, was in my mind, I was like, "We can come up with a unified ontology that everybody uses." And oh my goodness, that was super naive, and I will even be self-deprecating and say, marginally stupid. So I have learned tremendously from the both of you on this. And so,

34:41I just kind of doubling down on one of your points, Marco, right? Like, the reality of it is that you need to create an ontology and taxonomy within your organization that everybody's on the same page with. If you don't do that, then there are significant challenges as ambiguous human beings that we are, right? And so- Definitely ... I just wanted to double down on that point because for me, obviously, it's been a journey. But I think it's a critical one, and I think that a lot of people in the world of risk quantification that I interact with struggle sometimes with trying to communicate things when they're not even using concepts, taxonomy, relationship

35:18definitions that are similar to the people that they're trying to engage with. And so kudos to you for the work that you've done on that to help surface that as really kind of a critical step forward. And with that, I'm going to say, hey, Graeme. Good to see you, my friend. When we chatted about this session, we wanted to make sure Marco had time to kind of take his dialogue into the place that he did, right? Combining this discussion of ontology and taxonomy with the world as it was and the world that we're moving into, right? And so, I'm going to just kind of open it up to you two gentlemen, right? I'll chime in as relevant, but I'd rather hear you two kind of continue this dialogue. And Graeme, we

36:05talked a little about, like, practically speaking, how do you use ontologies, right, in your work and how to help your clients and so forth, so... Yeah. I mean, there's several levels to it, right? So, what you were saying there, and Andrew, I think you shouldn't be too hard on yourself for thinking that you might be able to come up with a consistent ontology because you're mostly working in cyber risk quantification. Cyber risk quantification has its language. The whole FAIR methodology, and there's a certain consistency about the way that that's being written about and talked about, and that's great.

36:44My kind of background is broader. I've done a lot of other kinds of risks, and also consulting independently, Marco's probably very much the same situation. We work on a lot of different kind of companies. And you realize that the only thing that all these companies agree about in terms of defining things is that all the other companies are wrong about the way that they define these things. So people are- - ... it's incredibly heterogeneous, the way people define terms like risk, risk appetite.

37:17But it's also quite dogmatic. I mean, people are convinced, so they'll talk about risk, and they'll talk about it in a way that just really doesn't brook any kind of argument about what they mean by it as they're talking about it. And I think one of the just really powerful, just right off the bat, one of the really powerful things about the work that Marco's done with the surveys is just how that is not the case.

37:40It is remarkably diverse the way people talk about things. And Marco was in on one of the kind of classic definitions there, risks. I mean, the number of companies I've come into and we've talked about risk for a while and had this sort of slight discomfort thinking, "We're not talking about the same things." And you look at the risk register and you realize the risk register is full of- Loss events, things that have happened, or they're full of issues, stuff that people are worried about, or they're full of control failures or vulnerabilities or various other things, none of which I would call risks. Now, that's not to say that they're wrong in calling them risks,

38:10but that disconnect is incredibly important because it means that the conversation we just had for the last 45 minutes is actually a bit of a waste because everything I've been talking about is forward-looking uncertainties about the future. And this matters, and it matters enormously. It matters for someone like me. When I go into a company, I'm very careful to try and figure out what it is they mean by all these terms they use.

38:32But when you start bringing AI into this picture, and large language models in particular, it's a huge vulnerability, right? Because you've got... if you take that risk example, you've got risks as uncertainties, forward-looking uncertainties, events that might happen, variables that are somehow impacting your objectives.

38:51Taking for granted that it's impacting objectives, because otherwise, why would you be talking about them? So that's one thing you have. So that's forward-looking. Then you have loss events, stuff that's happened. That's kind of the diametric opposite. And then there's an awful lot about, because people, when they talk about risk management, what they're really talking about is issues management or they're talking about control frameworks and things like that.

39:13Now, if you have a system and you're using your LLM to try to help you to make risk-based decisions, then you have a decision that is based on a risk. So you'll have some sort of criteria or some sort of... you want the decision to be based on an assessment of the risk. But if risk means three very different things in the way that that model has been trained on the data, on the immediate data that you've provided to it about the company, about the decisions you're making, then effectively you're going to end up with three different decisions, and it's a complete roll of the dice which one it picks up if you have that ambiguity about the way that you're discussing risk.

39:50So from a kind of practical point of view, this is incredibly important. It's important even before you get to the AI, just having people talk to each other and understand each other. And a lot of the work I do with companies when we're looking at sort of reviewing enterprise risk management programs is exactly trying to get some sort of, if not agreement, because often these things, the cyber risk community has its ontology, finance has its ontology, but at least being able to generate the thesaurus. I really like that, Marco, the thesaurus at the end.

40:22Being able to map these concepts into each other is incredibly important. - It's an interesting notion, if I could, Graeme, that you point out, right? Which is, there is agreement on taxonomy and then a softer version of that, to a certain extent, as alignment, right? And even if you can't match on a specific definition for a term, but if you have alignment, right- Yeah ... at more of a directional level, that's probably too broad, but maybe that's the key. Because agreement on terms is not always an ideal endgame.

40:56Yeah, I don't even agree with myself. I mean- - ... I usually agree. I usually take the ISO 31000. I find that quite a nice starting point because I'm mostly working with quantitative risk. So if you have risk as an uncertainty that affects objectives, basically it's a random variable in my model. So I just identify risk with random variables. It's very broad, it's very flexible, it's very powerful. It covers most of the situations I want to work with. But I do a lot of work where I'm only dealing with operational risk. And operational risk, it's stuff that happens. It's an event that occurs and incurs a loss. So it's a subset of that broader ISO 31000. It's downside, it's negative,

41:33and it's contingent on the occurrence of event, and it's incurring a consequence that is additive. So a loss or loss of life or something like that, things that I can add up. So I've taken that broad ISO 31000 and boiled it down to something very specific. And I basically used the math to do that, and that's why I think the ontology and quantification very, very sort of sit very close hand in hand. Because to, I think probably to a greater extent than Marco does it, I want to use the math to define the ontology. I think Marco wants to use the ontology to define the math, and I think we have a slightly different approach because we're doing slightly different things in that space.

42:11So I don't agree with myself. I mean, sometimes I'm sitting there going, "Yeah, risk, and it's an uncertainty that's affecting objectives," and sometimes I mean something very specific. But if I'm doing that, then I'm very careful to say, "This is what I mean by risk for the coming whatever paragraph or meeting or whatever it is we're going to."

42:26And I think really that's the takeaway from Marco's is, as you rightly say, Andrew, to your point, we can't agree on an ontology, but we can agree that we have to agree what we mean when we're talking about it. It's more of a mapping exercise than a homogenization exercise. Marco, thoughts? Yeah, I agree completely from what he said, that he comes from math to ontology. I come from ontology to math.

42:55That's true. And also I agree very much with the point that he's making, that I don't agree with myself sometimes. That's not the point. The point is, your own ontology changes according to the situation. So as a consultant, you get used, and we three of us are consultants, we go to a customer, we adapt to their taxonomies and vocabulary. We try to correct, adjust.

43:30So what we're doing, we're using our former conceptions to their terminologies and semantics and try to come up with an ontology that works for that decision. Okay? The problem is, it's difficult, still difficult to find a good customer that says, "Okay, I want to look the world from the decision standpoint." Mm-hmm. Okay?

43:59In Brazil, I work a lot with companies that are still trying to improve the risk register. So I say, "Okay, I'm going to improve this risk register, but I have to fix the ontology, okay? Because then I'm going to classify things different, and you're going to have a column here that's going, an extra column here so that we can use the data better."

44:24In the end, what you're doing is data management, okay? That's the point. And data management is supposed to attend or to go to the decision. What decision are you doing, okay? I'm trying to option A, B, and C. I'm trying to choose from those three. Oh, okay, it's an optionality discussion, okay? So what's the data that you need for that?

44:51Or data, I don't know what's the right- Data. Data or not. Okay, what's the data that... Doesn't matter. What do you need at this point in time, right, where the decision is going to be made? So, today, you're going to scramble and get what you want, and I want a world where this is easier to do and you just give a large language model the graph of the situation, and it traverses it and go look for good data. That's it.

45:27I think risk management is basically providing data with expert interpretation, okay? So data by themselves, they are not enough. You need interpretation. So that's what risk management is. You say, "Okay, for this decision, you have this uncertainty. It looks like this, okay? Or it looks like this. I don't know, okay?"

45:51And I give to the decision-maker what's enough, right? So I don't give it more sophisticated or too simple. I give it what's enough for the decision-maker, okay? And I can use artificial intelligence, first, to speed it up, the process, to speed the process up and make it viable to get information in time. And artificial intelligence is going to be... I can't imagine 10 years if it's already doing what it is, okay? It gives you the insights, it gives you ways of seeing things that you didn't.

46:28It looks for patterns. If you give a proper graph, okay, they call it graph RAG, retrieval augmentation, okay? It goes where it has to go because it understands the meaning of what you're doing. So it's not good prompting. It's giving the map, okay? The treasure map. You say, "Okay, I have this decision. I need this data.

46:56Go for, go for. Bring it, okay? And this is the map." Okay? It uses the map, okay? So that's what we're trying to do. Ontology is the template for the map, because if you don't understand what you have to do, then you're lost, okay? So you can do this as an ad hoc situation, or you can do it in an automated situation, in a day-to-day, okay? If you need an early warning system, okay? Or I need to know when a control in cyber was broken, was not done, was not performed, okay? I need to know when certain passwords were used.

47:37And I don't want them to bring this to the next month's meeting. I want now. I want to know now in my cell phone, in my mobile, okay? That's what we want to assemble, okay? So ontology is like a backend need at this point now. Yeah. You know, I love the... Go ahead, Graeme. I didn't cut you off. Go ahead. No, I was just going to follow up on that. So we've all sat there with AI and we've all pushed the limit of the window, right? So you're pumping in more and more information, and at some point you realize that the AI's kind of lost it, and it's lost some of the stuff that it handed in a while ago, and it's not tracking everything, and it's not all there. And we've all had that experience.

48:22And yeah, you can make bigger models, but at some point, and you can make that window bigger, but at some point, you run into sort of theoretical limitations with the way that that technology works. Because what it's trying to do is, it's almost like ringing a bell. You say something and then it hits some resonant frequencies, and then those resonances sort of start to appear, and it's incredible. And we've all sat there and said, "Wow, this is absolutely incredible. We're all going to be unemployed in a year." And then something happens and you're like, "Yeah, well, maybe not." And what happens is it starts hitting the wrong resonances, or these resonances start overlapping, or

48:59what very often happens with me is that it rubber bands back to its basic training. So I've kind of led it along the way. I've taught it about the virtues of quantification, how quantification is so much better than maps. And then suddenly it's just gone, "Yeah, no, boing," and it's gone back to what it's read broadly across the net. So what you have to do is you have to fill that. You have a limited amount of space to kind of guide it and to sort of bring out those resonances. And what the graph does is it provides structures to do that, that focuses you in on exactly the things that are important for the decision that you're trying to make. So a way of thinking about it is

49:40that it's a way of making that context window as massively efficient as possible by forcing it into a form that absolutely informs what it is you're trying to achieve. And I'd say maybe, again, just sort of building on what Marco was saying there, yeah, you've got the data, yeah, you've got the decision, and you've also got objectives.

50:03And a lot of what I've been doing before AI is I've been saying, "Okay- I've got what I want to achieve. I've got the levers that I can pull on that will then propagate out through some kind of causal network and influence the objectives that I'm trying to achieve. And what I need is a model for what sits in the middle that allows me to understand how my data relates to the things that lie on the causal pathway between my decisions and my objectives. And what Marco's graph does is it is that model, and it is the right way to generate that model in an AI context.

50:41It's also the only way to do it because AI is semantic, it's not quantitative, and so far at least, it's relational, it's not causal. But risk management is quantitative and causal. It's quantitative because you, at some point, want to spend some money. That's the decision that you're going to support. You're looking at investment, maybe even divestment, be one of that kind of cost-benefit component. And even if you're not doing that, even if all you're doing is prioritizing and saying, "This is what we should be spending our attention on, this is what we should be spending money," if you're prioritizing, you're entailing a quantitative relationship between the things that you're prioritizing. So risk

51:15management is essentially quantitative. It's completely inescapable. And if you're not doing it quantitatively, and I know I'm preaching to the choir here, but if you're not doing it quantitatively, you are doing it quantitatively, you're just not doing it very well quantitatively. You're actually not actually doing the quantification work. But the other thing with risk management, it has to be causal, because it's not enough to know relationship. You have to know that when I pull on that lever, you have to understand how it propagates through that model. What the graph does and what Marco's ontology does, built for that pur-- when it's built for that purpose,

51:44is it allows you to build an AI-generated model that can be quantitative because you're fixing the ontology, you're fixing the things in the model, which means that you can also fix the mathematical relationship between the things in the model. So you can make it quantitative and you can make it causal, because again, you're fixing the things that are, and you're fixing the relationships between the things that are.

52:07So it's a necessary condition to be able to use AI, but I think it will also be sufficient to use AI because if you do it properly, you'll be able to imbue it with the principles that it needs, namely that it needs to be quantitative and causal. Well said. Your English is awesome. - And you're a very smart man. I'd like to ask a question from- I love your comment.

52:34I'd like to ask a question from the Q&A here, since one of our credos here at ERQI, right, is practitioner-led, and so as I think this is a very practitioner-centric question. So question from Sebastian Hoffman is, "After identifying inconsistent use of terms in the context of operational risk in organizations, what is your approach to surface it, and what are your steps in moving into the direction on harmonization?" And I think you've both spoken to that last piece a little bit, but I'll ask for some guidance to what I think is a good practitioner question.

53:12We're both being excruciatingly polite and letting the other one go first. - Well, I would surface it maybe with an internal survey or a workshop, something like that, where you can bring the discussions alive within the company. And then discuss the divergence, like we're doing in a broader spectrum here. I would do the same thing inside an organization if I was a CRO, for example. And I think that's- Yeah ... I think that's great. I think that, to me, one of the things that's inferred there, Marco, right, is like, don't have it just be your voice, right? Take the information- Exactly ... take the conversations and summarize- Exactly ... so you have a picture of the challenge. So it's not

53:56you as the practitioner only speaking, right? You're using the voices of the other folks in your organization. Exactly. And that's difficult because we CROs, I was CRO, we are very proud of our achievements and our knowledge of things, and we don't want to change our perspective. That's the problem. So we got very stiff and very, "I am the owner of the truth." You know? So, "I am the source of the truth." And that's a big mistake that you do, we do. Okay. Graeme, thoughts?

54:30No, absolutely follow up on that. I think the issue there is really to ask people to explain what they mean by their terms, and accept that they can call these things what they want to call these things. We just have to make sure that we're agreeing on what it does. I will say, in the more... So my work sort of covers a spectrum from people who aren't using quantification at all and don't want to use quantifica- Well, they do want to use it, otherwise they wouldn't be talking to me, but they haven't used any quantification and maybe don't have much of a background in it. But they're seeing the limitations of the methods they're using. And it goes from that all the way through to people who are really quite

55:04sophisticated already in the way that they're doing quantification, and we're just talking about embedding it in organizations or improving it or reviewing or whatever. And I think my response to that question depends where I am on that spectrum. If I'm anywhere over in the more quantitative end of things, just writing down the equations for things helps enormously in defining things in fairly unambiguous terms. You can't think of risk as an issue, as an open issue or a vulnerability or a control failure, and then ask what its probability is, or its loss distribution. I mean, the way that you structure the mathematics absolutely entails the definitions of

55:44those things. Of course. So I think you see that often in ways that ontologies evolve, and you see this a little bit in the FAIR ontology. The way it's presented, when it's presented, is it's presented as if it's a piece of sort of logical philosophy and the math follows. But I think everyone who reads it knows that secretly the math was written down first and then someone described it and tried to have it as an ontology.

56:06But I think that's fair. I mean, I think that's... And that's also why I'm so keen on letting the mathematical relations define the ontology and not the other way around. Although I think if you do that, it's not going to be... I'm not s- I think you have two problems here. I'm just an eye on time, but I want the math to define the ontology because when I've done the graph RAG, I want what is coming out of that to be the model, right? And if I let my math- The back office ... define the model, that's what happens, right?

56:34I just don't think that works. I think if you want the AI to be able to assign to your ontology, it has to be much closer to natural language usage, and there's a tension there that I think is a lot of the challenge that we're facing at the moment. Yeah. Marco, any final thoughts? Well, math and ontology go very well together, and I think mathematics is one of the fields where ontology has to be very precise. Excellent.

56:59Absolutely. I 100% agree. Yeah. So this is the lightning round, so you have to limit your responses to a 30-second clip. So, we talked a lot about risk registers. In your ideal world, what replaces the risk register going forward? Marco, you're first. Knowledge graph. Graeme? Yeah, I can't top that. I mean, that's absolutely the way forward. You can write it out in a list and call it a register, but those relations are critical.

57:31Thank you so much, gentlemen, for a wonderful session. Appreciate both your time, and I would just ask that everybody continue to participate in the work that Marco's doing on the survey front and research front. And Graeme, thank you as always for your time, sir. And with that, I am going to step out of the way. Thank you very much for the opportunity. Thank you. Thank you, Marco.

0:06Graeme, stick around. We're going to watch a video now of you and Laura Voicu. Ciao, Marco. Marco, I'm going to move you back to attendees. Oh, he left. Okay. So, Graeme, can you just say a very brief introduction of this video? We've had several forward references to this session because this is a session on model risk, and we're about to watch a video with you and Laura Voicu quickly. What are we going to see?

0:47Okay. So, I think I say this in the video as well, and I've said it online, and I'll say it again. I think Laura has written a paper, Laura Voicu. She's based in Zurich, cyber risk quantification expert, a founding member of ERQI, and chief data science officer, I believe. She wrote a paper a couple of months ago. I had the enormous good fortune to review this for ERQI.

1:14And I really don't, I'm not exaggerating, I think this is one of the most important pieces of writing in risk quantification that I've read in a very, very long time. I think it's enormously important. Ostensibly, it's about model validation. And basically what she's done is she's taken, and she'll talk about this in the video, she's taken a lot of the sort of guidance that's been developed around validating models in a banking context, and she's applied that to cyber risk quantification.

1:37And I think the way that she's done it is incredibly intelligent, and we'll see that through the course of the interview. I think it's important in terms of verification and validation of cyber risk models, but I actually think the scope of this is much broader. I think everything she says can be equally applied to just about every kind of risk quantification that we're talking about. It's outside of the sort of classic financial credit risk, market risk sort of space. All the places where we're quantifying risks kind of from scratch. We're not in the middle of some sort of established model. So I think it's very much applicable outside of cyber risk. It's written for cyber risk, but I think it's

2:14very much applicable outside of that. But I actually think the other thing that's important about it is that if you are building a model, or even if you're buying somebody else's model and thinking about using it, this is actually the starting point as well as the finishing point. We tend to think of validation as the last thing you do, but I actually think in many respects, if you're building a model, this is one of the first things you should do, is to read this paper, because it sets the benchmark. It tells you what it is that you need to deliver, and I think it does that in a very intelligent and reflective way. So let's let Laura speak for herself, and we can take it from

2:46there. Oh, look, I'm wearing exactly the same clothes for the interview that I am now. I have changed in the meantime. Okay, here we are. Go. Hi. Hello, everybody. Welcome to this session in the ERQI Summit. My name is Graeme Keith. I'm a fellow of the ERQI and an independent consultant advising companies broadly on the use of analytical and quantitative methods in risk management.

3:16Delighted to have with me here Laura Voicu, who's a co-founder of the ERQI and chief data science officer. We're going to be discussing Laura's recent paper, "Model Risk Testing and Analysis," which is available in the work product section on the ERQI homepage. Laura, can you just kick us off and give us a very brief overview of what the report contains, what it does? Right.

3:40So, as the title implies, it focuses on model risk testing and validation. And by that, I mean that it tries to answer a couple of questions related to how much can we trust a model's output or the decision that it informs, right? So it looks at whether the model's assumptions and structure are reasonable for what you're intending to use it for.

4:07If the implementation is correct, how sensitive are the outcomes to data limitations, right? This is all applied to cyber risk quantification, and cyber risk has its own challenges, data limitation being one of them, right? But also to parameter uncertainty, different alternative modeling choices, right? In cyber risk, but generally speaking, in risk quantification, also enterprise risk, we use these models to transform, confirm, convert the uncertainty into numbers that we use to drive decisions, risk appetite and insurance, control investment. And so if the model is wrong, then your decision is wrong, and this is something that we need to address.

5:00Okay. So it sounds a little bit like you've taken some of the model validation methodology that we use in banking, the sort of new Basel stuff, SR 11-7 and things like that, and applied it to cyber risk quantification. Would that be a fair characterization? Yes, that is correct. So I took selectively- Yeah ... from banking model risk management approaches that have been existing for a while.

5:26Banking learned in 2008 more or less how to do this properly, and in cyber we have not yet, and that was the inspiration, correct. Right. So that's kind of my next question. I mean, cyber risk quantification has been around since, I think Jack Jones says in the start of the FAIR Handbook that he started working on this in 2001. So at least 25 years we're thinking about just FAIR.

5:52It's a bit late, isn't it? I mean, how did we get by for such a long time without this? Don't get me wrong, I'm absolutely thrilled that this has landed. But- Yeah. So, I mean, how do we get away with it for so long without having something like this? And what drove you to address this now? You know, to your fair question, right? Maybe it's a bit late for this. You know, better late than never, I think. Yeah. Right?

6:21And what drove me to this, I think you're correct. FAIR has been the de facto standard for cyber risk quantification for a very long time. And I think adoption sort of ran ahead of validation and scrutiny, right? And in early beginnings or even in my case, when I first started using FAIR, it was more of a way of thinking, a way of decomposing the problem, of formulating a good scenario and trying to identify the components that drive the risk.

6:57But today, it's become a bit more mainstream, I think. And these numbers or the results of a FAIR analysis, for example like I said, they're being used to make decisions that matter consequential decisions like insurance a number for the risk appetite that's put on the board, you know control investment decisions. And so these are consequential decisions. And in every one of them, if the model is wrong, you won't see it until you have a loss that shows you the gap. And by that time, the decision has already been made and it's too late, right? Okay. So I think this is definitely a good time to start. Absolutely. I think you tell a very coherent story. I think,

7:51and certainly if you talk to Jack Jones about that process and the thought process, I think you describe it very well. It's a way of thinking about it. It's a way of breaking down the problem. It's more of a sort of frame than it is a sort of regulated step-by-step approach in the way that you have in the banking world.

8:06And yet, we're almost using the results of that sort of fairly ad hoc, rough and ready approach to putting a model together as if they were sort of highly regulated in the way that they are in banking. And yet banking has these very, very strict and very sort of comprehensive rules about how you validate models, and we in cyber risk quantification don't. So, huge gap that I think you have filled magnificently. Just to kind of sort of kick us off and get us on the right page, when cyber risk goes, cyber risk quantification rather goes wrong, what goes wrong? What's the most common way that a cyber risk model fails?

8:50I think perhaps the most visible one is like the false precision- Right ... that implies. I think it's not necessarily that the model is being like wildly wrong, right? If you're using FAIR, FAIR is an open model, like an open standard. If it's well implemented, then you fairly know what the model should do. But the way the results can sometimes be presented, it can be done with a precision that the inputs don't support due to lack of data, for example, to calibrate the models properly. Yeah.

9:32Yeah, I think- And so I think that's the most visible one, right? Again, makes a lot of sense and goes back a little bit to what we were saying just a second ago about how we've almost sort of borrowed this methodology from the world of financial risk, where you have huge amounts of very carefully curated data. You have a whole machinery that's built just to generate the data that is being used there.

9:54Correct. And then we use that to make decisions in a very particular way. And it's almost like we've borrowed that decision methodology, but we don't have the machinery that really sort of warrants the decisions we're making on it. That's very interesting. I'm not going to lie, and cards on the table, I'm a huge fan of this work. I think this is one of the best pieces of risk management guidance I've read for a very, very long time. I took it down to my local café one morning, had a very, very happy morning sitting there reading it very happily, just marking off saying, "Oh, this is brilliant. This is brilliant. It's brilliant." I think it's absolutely great.

10:24One of the things I really loved about it which I think is really, really critical and follows on from this notion of false precision, you're very explicit that really what matters about the model is the decision that it's supporting. And really the test of the model is against the decision that it's supporting. You say that the real test is whether plausible model uncertainty would change the decision you're making. And I really, really like this because what it allows you to do is look at a model and go, "Okay, maybe that model wasn't as good as we said it was, and it isn't able to support these decisions that we said it should, but it can still do good things for us." Right.

11:03"We can still do things with it." So it allows you to sort of reframe the question in a way. And then what your paper does is it tells you how to sort of validate against the question that you are then answering. So it gives you a degree of freedom, which is not okay. When models aren't good enough, you can either make the model better or you can change the decision that the model's trying to support. Correct.

11:22And that latter thing gives you an extra degree of freedom that allows you to do models in a more realistic way. And I love that. But can you walk me through it? Can you walk me through how you do that in the paper? Right. So I think like the decision impact test right, the one that you first mentioned like for any model, I think we need to ask a question, one question. And that is if the plausible model uncertainty will change the decision that the model it supports, right?

11:55And- What I would do there is run the model, for example, under two or three alternative specifications that are credible for that scenario or in that decision, right? Like a different severity assumption, a different frequency assumption, a different severity distribution, different expert inputs, different data sources as an input. If every version points to the same action, right, buy the 10 million limit or fund the MFA rollout, then the model is robust enough for that decision no matter what version is right.

12:33And you don't need. If the versions point to different actions, then that uncertainty analysis is the decision itself because you're choosing which assumptions to believe, because they have a completely different outcome or a completely different impact on your decision. And I think that's also a decision that a conversation that the decision-maker needs to be a part in, because a part of, right, needs to be in that because they're the ones making that decision and they need to understand what assumptions they choose to believe, right? Yes. Okay. I think, so I spend a lot of time reviewing various models. Some of those are cyber risk models.

13:17And very often, you end up in a situation where you think, "Okay, this model's probably okay directionally and maybe comparatively." Mm-hmm. But those absolute numbers are a nonsense. Yeah. Can you talk us through, again, from the perspective of validating the model, how you can frame that to be able to say, "Okay, I don't actually trust these numbers themselves, but I trust the sort of the direction they're pointing or their relative magnitude."

13:56And sort of unpack a little bit what sort of decisions we can... I mean, but how can we use a model like that? How is a model like that still useful to us? Right. So I think that when a model is unreliable for absolute numbers, you can still use it to compare rather than predict, like you said, right? For example, if I'm ranking control investments, a lot of what's wrong with the model, right, under-reporting in my calibration data, a severity distribution that's maybe off, that hits every option equally, right? And it cancels in comparison. I'm not talking about an absolutely right, wrong implementation of a model, right? A good implementation of a model that maybe lacks in calibration data, in

14:39several assumptions, then that would hit every option equally, right? So ranking-wise, that would still be correct- Yeah ... even when the numbers aren't, right? Okay. And I think that works when you're talking about model-wide biases, right? Yeah. Things that hit all factors in a model equally. But that's really nice. And I think, I mean, a classic example of this, I think, is covariance. I mean, there's very, very few cyber risk quantification models that make a very serious bash at including covariance in the models. Understandably, because it's difficult. I mean, just the bookkeeping of it is difficult.

15:15Actually, it's really the bookkeeping that's difficult. The math isn't that hard, but the bookkeeping is. And then I guess what you can do is you can say, "Okay, well, look, we think that yes, the covariance is going to have an effect on our VaR to CVaR or whatever it is, but we think that it's going to have a similar effect, of course, all of the things that we're looking at." And when you're making decisions comparatively, you're looking at the difference between two numbers. And the hope is that when you take the difference of those two numbers, the error being directionally an order of magnitude more or less the same will cancel out in the difference.

15:45Correct. And I think what that does, and again, this is something that I think comes out very nicely in the paper, is it says what it allows you to do is to have a conversation about what those assumptions are and to explicate those assumptions. So, for example, okay, the effects of this thing that we're neglecting, we believe to be the same in both cases. And then, as you say, you present it to the decision-maker and you say, "Okay, this is the basis on which you're making that decision."

16:09Something else I really liked about the paper is you classify models by the decision they inform. And I love this decision centricity. And that I think is incredibly important because I think we spend a lot of time worrying about how complicated models are, and then we scale our validation to how hard it is to validate rather than what we're doing with it.

16:35Can you just talk us through that? Why we do that and how that works? Yeah. So I think the thing that was going through my mind at the time is that rigor and validation should follow the consequence or the importance of that decision. And I think complexity is a very, very bad proxy for consequence, right? Complexity is a terrible proxy because you can have a single spreadsheet, right, where an analyst estimates a number that the CEO puts on the board risk appetite segment. That's a very consequential model, right?

17:11It informs a material financial commitment. And on the other hand side, you can have a sophisticated Bayesian vulnerability ranking engine that decides which patches go first, which is important, but it does not inform a material financial commitment. And so if you classify by complexity, you spend a lot of time on validating the engine and let the spreadsheet go away, wave through, which is exactly backwards in terms of what kind of decisions they support, right? Yeah. That makes a lot of sense.

17:46Yeah, I like that approach a lot. I think also, interestingly, I mean, put that as a question. I'm almost thinking there's a sort of inverse relationship between how complicated the models are and the importance of the decisions, because I think the important decisions, I mean, we're talking sort of company-level strategic enterprise decisions, they're taken over a longer timescale. Go on.

18:10They tend to have a lot more moving parts, a lot more variables, a lot more structural instability. And you're a lot less able to sort of look at what's happened in the past and use that as a guideline to the sort of volatility that you expect in the future. And what unfortunately tends to happen is that people would go, "Well, it's too hard to model, so we wait. We'll just go with my gut because that's going to be right."

18:34And you see that a lot. You end up with these very, not even simple, they're not even simple models. What they are is just sort of formalized gut. And I think what your paper does and this isn't going to be a question, this is just going to be me fanboying again. But I think what your paper does is it says, "Look, we accept the complexity. We accept that had difficult problems. We also build the model to suit the problem that we're solving in the context that we're solving." So what it allows you to do is to say, "Okay, look, it's okay to have a simple model, but we just need to make sure that we treat it in the right way and validate things in the right way."

19:08Okay. Sure. I talked about sort of financial risk and the machinery that generates the data and all the rest of it. And we sort of lack that a little bit in the cyber risk quantification world. It's not the only challenge with cyber risk quantification. Maybe we can just sort of talk through a little bit the uniqueness of cyber risk quantification versus some of our cousins in other disciplines.

19:38What makes cyber loss data worse than the data an actuary is used to, for example? I think in my opinion is that in cyber, everything that an actuary takes for granted is missing almost all at once. Yeah. Volume. Yeah. Because you have hundreds to low thousands of actually confirmed loss events in the last 10 years or so.

20:08Whereas in finance, like you mentioned before, right, we have decades of very, very dense financial data and machinery that produces exactly this data. Then I think there's a question of observations and conflating observations, incidents, material losses, right? Not every incident produces an observable loss or a material loss. You have quietly paid ransoms, you have contained breaches, you have things like business email compromise that are sort of absorbed as the cost of doing business, right, nowadays, and they never reach any database.

20:50You have mandatory notifications, but these are very, very much dependent on the jurisdiction and on the threshold in that respective jurisdiction. So these all different separate data sources have very different observable observation mechanisms, right? And so you cannot just simply combine them and think you have more data than you actually have.

21:14You have a lot of censoring, I think, in cyber, right? Yeah. The richest form of data is insurance claims. Yeah. And they're sort of left-censored below the retention and- Yeah ... they're right truncated at the policy limit. And also, I think a question of definition, for example, what counts as a cyber incident drifts, right?

21:37Yeah. In time, as new attack methods appear, as the threat landscape changes and evolves. Yeah. So, yeah. Right. None of these, I think, are unique to cyber, but I think that having the combination of all of them together makes it a bit harder or more challenging to work in- Yeah, definitely ... cyber data. I was also earlier talking about the issue of scale. When you come up into a larger scale, you're looking over longer timescales, you're less able to use history as a sort of historic volatility as a guide to future uncertainty.

22:15Right. But actually, that's 100 times worse in sort of cyber space because the world is changing so fast. So you don't- Correct ... even have to come up with that higher scale in order to do that. Can you talk through that a little bit about, is historical volatility any kind of guide for future uncertainty in cyber risk quantification?

22:37I think it is informative, but probably not in the way it is used in other fields, right? Not as a proxy for or a prior, if you want, in a Bayesian sense. Because the cyber threat landscape is changing way too fast, right? If you think of ransomware, right, ransomware as a service professionalized around 2019, 2020. And by 2024, you had exfiltration-only extortion that was a significant share of the incidents. And so that changes the frequency, the severity, the characteristics of the attacks, and the shape of the loss, because you cannot compare to things that were a while ago, right? Business email compromise was being reported as wire fraud

23:29years back. And so I think a model that's validated against, let's say, 2020 or 2023, it's maybe validated against a world that is slowly disappearing, right? Yeah. It no longer exists. So that whole issue of how much data you have, how many data you have, that's massively amplified by the fact that we have maybe 15 or 20 years of data relative to banking that has probably 20 or 30 years of data in a sort of similar sort of context that's digitized suitably well.

24:06But actually, we can only use a few years of those data. We can't use the full 15 and 20 years because data from 2015 or certainly not 2005 is just not going to be interesting to us anymore. That's very interesting. Back to one of my bugbears, which is the covariance piece. Mm-hmm. Again, as I said earlier, and as we've talked about before, most models are assuming some kind of independence between events.

24:33How wrong is that, and does it matter, and what can you do about it? I think it's very wrong. You're right. Perhaps probably most all of the models I've seen out there do assume independence, and I think that matters very much. It matters probably where the money is, to be fair. But if you think of things like Log4j or MOVEit or shared cloud provider outage or coordinated campaigns, these are things that are the opposite of independent events.

25:10And generally, cyber losses tend to cluster through common vulnerabilities and shared vendors, right? And I think it's something that I'm studying at the moment, but there is some evidence of very interesting dynamics of where successful attacks raise the probability of the next one. Yeah. And so if you aggregate scenarios under the assumption of independence, then your aggregate tail will be understated by a factor of two or more, right? Right.

25:46When every individual scenario is... Yeah. Yeah, and this is almost worse than... And this isn't linear, right? This isn't just a linear covariance problem. This is self-reinforcing. And yeah, and your tail is going to be horrible as a prediction. And that's horrible because certainly if you're thinking in insurance terms, that's where the money is. Right.

26:12And also, if we're thinking... Yeah, I guess the left censoring isn't hurting you here, but the fact that you don't report beyond your policy limit is going to be a problem here. So you- Right ... don't have a huge amount of data in this space either. Right. And also, the data you do have in this space is going to be very specific to the companies that were exposed to these losses. So you've got a scaling issue there as well. I mean, one thing- Correct ... is you can look at some gigantic American bank that had all sorts of problems in this world, and then if you're some little local state bank, then maybe you don't have quite the same exposure. So

26:42you have to take that into account as well. Right. It's not representative, right? The few data points that are there may not be representative to your own context. Absolutely. Absolutely. I mean, they won't be. I mean, they almost necessarily won't be, and you have to do something about that. So what do you do about it? I mean, if you're sat there and you're trying to size an insurance program off a prediction like this, what do you say to that person? What do you say to the person that at the end of the day has to come up with a price for that premium?

27:13All right. It's a very- No pressure. Just putting you on the spot a little bit. No, no. I'm loving this question. Just went on and on and on about how incredibly difficult it was and then said, "All right, now how do we fix it?" Right. Well, I think what I would say is that the tail is where the decision is, right, and where the data isn't. So, we need to treat the tail estimates maybe as its own risk problem, model risk problem, right? So, we can report percentiles like P95 or P99 with sensitivity bands, right, showing how they move when we do alternative tail specifications, right? You can use...

27:57Because the body of the distribution is fine, right? It will stay fine, but it's the tail where we will diverge with different distributions. We need to understand how many extreme observations support that tail, right? Usually there's very, very few in the tail. I think, and correct me if I'm wrong there, probably that statistical convention says somewhere between 15 to 20. I think probably most cyber datasets have far fewer, right? And I think this is a limitation that needs to be stated, right?

28:35Mm-hmm. And then I think sanity check against extremes, right? Yeah. We know things like Equifax, right? The most famous major incident, right? How much that cost, and if you're a comparable organization and your tail shows those distribution or your statistics show you something that's a 10th of that, then something's wrong with your tail because it's not Equifax, right?

29:04Yeah. Yeah. Okay. Okay. I mean, we have these conversations, and it's very easy to just sort of pick holes in models and say, "Oh, we don't have this." Right. "We don't have that, and we don't have the data," and all the rest of it. Do you worry that... You've been in a position, people have done a lot of work, they've built up their cyber risk quantification program, they've got some decisions in there, and then you come along with your excellent paper, and they read it and they say, "Oh, damn. This isn't very good, is it? Yeah, we've been making all these grandiose statements that are not at all warranted by the quality of the model or the quality of the data."

29:45Are you not worried that they'll now just turn around and go, "Oh, do you know what? This is too hard. We're just going to kind of... Yeah, let's just go with the gut because we might as well because it's cheaper and we can't really model it, so what are we going to do?" Is that not a risk with bringing this into play at this stage?

30:03I certainly hope that it is not and remain positive that this is not the case. I think the paper was not meant as an argument against quantification by any means, right? Not at all. It's quite the opposite. And I do hope that the paper makes it explicitly. If not, I'm willing to go on camera again and state that. I think that for most organizations, I think if you have an unvalidated FAIR analysis or a loss distribution, that is still a large improvement, right, over the status quo of heat maps or- Yeah ... your peer network recommendation, peer benchmarks, vendor recommendations, and things like that.

30:45And so the goal of model risk testing is simply to make the models more trustworthy, and it's not to set a bar so high that nobody can reach it, and now we're back to heat maps, right? And there's three different levels, right, of assurance mentioned in the paper. And then level three, which is sort of the lowest, simply requires documented assumptions and documented known limitations, right?

31:14Which is something that costs an afternoon, and it can be done by anybody running CRQ program or a FAIR program, right? It doesn't require the whole apparatus of model risk management as we know it in banking. I think the purpose is to improve decisions relative to how we have been doing that, and documenting assumptions and known limitations is a great starting point. Yeah. I think that's a very strong answer, and I think it brings us back to what I was praising earlier about this and what I like so much about the paper is that it very much not only allows but encourages you to scale the decision and to frame the decision in a way that the model can

32:06support. And I think that's very powerful. I think it's a paper on model... You don't call it validation, do you? You call it... What is it you call it? How does that work? Testing, model risk testing and analysis. Yeah, model risk testing as opposed to validation. Yeah. Validation sounds like a rubber stamp- Rubber stamp, yeah ... that you put on things, right?

32:25Yeah. Okay. Like kind of... Yeah. Yeah. Yeah. Okay. So, I mean, it's a paper on model testing for cyber risk quantification. Right. And it is absolutely that. I would say, and I would say to everybody listening now, if you're going to build a cyber risk quantification model, you should read this first because it tells you how to negotiate the trade-off between the way that you frame the decision and the quality of the model that you need and the quality of the data you need. And I think that's incredibly powerful. It's also the benchmark that your model should be held up to when you finish building it, and it's a very good idea to know where the

33:01finish line is before you start that process that takes you there. I would also argue that the principles that are put out in this apply equally well to all manner of risk quantification, not just cyber risk. So, I mean, if you're interested, it's broader than cyber, and we are, after all, the Enterprise Risk Quantification Institute- Right ... not just the Cyber Risk Quantification Institute.

33:22Then read this paper because... And read this paper before you build models because it's an absolutely outstanding guidance in that sense. You have these four pillars, conceptual soundness, implementation, plausibility, uncertainty. Which ones do people skip, and which are the most important? I would have to say that the thing that I'm seeing being skipped more often is perhaps the implementation verification part of the whole framework, right?

33:56Yeah. Does the code do what the design says that it's supposed to do, right? Because people assume that a tool will handle it, right? And so they never look at rerunning the simulation with different seed and checking if it's stable, if it's reproducible. Nobody checks that the censoring adjustment is actually in the likelihood function rather than in the methodology document, right, and things like that. And I think the one that's...

34:30Yeah, that would be it. And the ones that are more important, I think the uncertainty and the sensitivity, right? Because these are probably the ones that are more- Yeah ... we can afford, right? Yeah. Yeah. And that goes back to your point earlier about how you check whether the model is robust against the decision, which is essentially a kind of sensitivity analysis, changing the parameters- Right ... saying, "How wrong can I be in these parameters?" And given within the range of how wrong I can be, is that changing the decision?

35:02And if it isn't, then okay. And if it is, then we need to do something about it. Okay. Interesting. You talk about validation and testing, which I think is a very, very, no pun intended, valid point. - You know how these kind of guidelines play out. And I think this is an outstanding document as a guideline because I think it tells you conceptually how to think about modeling and how to think about how a model will support decisions.

35:33But if you put it out there, if we sort of rubber stamp ERQI and say, "This is what CRQ has to live up to," which don't get me wrong, I would love to do, and we'll come back to that later. But if we do that, we know how this plays out. What happens is that you end up with a sort of list of kind of... It becomes a checklist. It becomes a bit of a compliance. "Oh, we've done this, we've done this. We've kind of satisfied the requirements." And then we have some kind of consultancy that comes in and checks it and go, "Yeah, you've satisfied the requirements." No one's really thinking hard about it. It becomes a compliance exercise. How do we stop that happening?

36:09Right. I mean, the danger of this becoming a compliance exercise, I can see that, right? It's a valid point. And I think we need to keep asking, right, what specific decision did model risk testing change, right, in itself? The purpose- With this, it's not necessarily to generate documentations and never do something about it.

36:42It's to find those assumptions that are important and have never been written down that are moving the needle without you knowing it, and give the decision-makers something, what they need to act differently other than they one would have. So, if the answer to what changed is nothing when you do this, either the models are good, and so it's good, then you know, or the findings aren't reaching the people that need them. So, that's a communication failure. It's not a validation failure.

37:21Yeah. And so the idea is not, we completed the checks and now it's done. What happens after? Did we do something? If the answer is no, well, either we did a great job, hey, pat on the back, our models are good, or we have a communication problem. And so that's... But ideally, it should change something- Okay ... every time we do it. Yeah. Okay. Interesting.

37:52Yeah. Okay. No, that's again, nice answer. We have been talking, I think so far, at least I've been having in my mind, the people I work with a lot, and I know the people you work with a lot, who are people who are sitting in companies building cyber risk quantification for their own purposes. But we have a lot of, maybe not that many, but there are a number of players in the market selling cyber risk quantification software.

38:18And so in that sense, the model it's kind of out of our hands. We buy the model in. You say in the paper, "A model that cannot be examined cannot be validated." And that feels like a not so very hidden punch in the gut to cyber risk quantification platforms. Is it? Well, I think not directly to cyber risk quantification platforms or vendor per se, but it is one aimed at opacity of certain commercial platforms. I think probably some of them or many of them are well-built with named data sources and written methodology and a change log that shows history version of that.

39:07Then they should be trusted over internal spreadsheets. But I think that when people are looking at a platform and hear the word proprietary or things like that, that's a little bit the answer to all methodological questions out there. Yeah. And I don't think in CRQ that the market has sort of taken a stance against that yet.

39:38No. So, I guess the classics are you ask what the basis of a model is, and then you get the answer, "Oh, but that's a secret." Correct. "That's proprietary. We can't share that because then you'll go and build something else." And I guess if that is your answer, then you have to be able to generate a dataset that validates the methodology. And as we've discussed at some length, that dataset just doesn't exist. So I think that is a challenge. I think the other thing that you hear a lot is the AI deals with it. Right.

40:16And I guess, again, that's a little bit the same thing. Okay, fair, but then you have to... And I guess that's the thing. I guess if when you're hiding the model and you're hiding the assumptions behind it, then there's a substantially order of magnitude greater burden of evidence on you to be able to- Right ... demonstrate that that does what you claim that it does.

40:38If I'm that person I was talking about earlier who's trying to price their insurance premiums, and I'm doing this with shop-bought CRQ software, what should I be asking the vendor? How do I manage that conversation? Right. So, as is a companion to the paper, there's a freely available checklist with a full documented 24 sort of questions that can be asked.

41:09But I think only like three of them perhaps are the most relevant ones. And the first one is, can you explain at the conceptual level how telemetry inputs become or how your inputs become loss estimates? You don't have to show me your code. You don't have to show me your model weights or your model internals, but like the logical chain. That is not something that should be proprietary or opaque, right?

41:44And number two is, can an independent analyst verify that the outputs move into the expected direction and by a sensible order of magnitude when the inputs change? If I'm expecting full reproducibility may not be proper, may not be possible for a proprietary model, but directionally. When I change the inputs by a certain order of magnitudes, do the outputs move accordingly?

42:23And the third one is uncertainty bounds, not just single point estimates. I think those three are, for me, perhaps the minimum for a model to be examinable at all, right? In cyber, like I said, for example, we have FAIR, or this is the de facto standard of that. And so any analyst with the same inputs should be able to run a pen and paper, right, analysis and come up with an annualized loss expectancy or several statistics that should be, right, what the tool outputs under the same conditions. Because if not, right, then there are assumptions baked into the model that you're not aware of and you cannot reproduce.

43:15That's very interesting. You mentioned a free companion paper. Can you unpack that a little bit for us? Right. So there's a couple of short papers, free companion papers, that are available on demand or through the Enterprise Risk Quantification Institute. One of them is the aforementioned vendor checklist. The other one is like a minimum documentation template, right, for people building and maintaining models in-house.

43:56There's a practitioner's reference on value-at-risk, conditional value-at-risk, right, guidance. These are freely available. And there's two more detailed validation catalogs, one specific for FAIR and the other one for more generic, like frequency severity models that are available on request. Yeah. Okay. We'll come back to the vendor checklist, because I think that's extremely interesting, very relevant for a lot of people.

44:25I just wanted to take the opportunity here to plug the VaR-CVaR paper, because that's something that we circle around a lot in this field. And I think you've written an absolutely magnificent account of the difference between those two metrics and why you should have both, both in the paper itself and also in the appendix. So, I will plug that shamelessly at this point.

44:48And also the companion pieces on frequency, severity, and FAIR. The vendor piece, I mean, really what we should do is we should send that vendor piece to every CRQ vendor so they have it and they're ready for it. And then we should really kind of evangelize that this is available, and anybody who's thinking about buying the software should be either sending the questionnaire to the vendors or asking the vendor for their answers to that questionnaire. And I think we will absolutely be encouraging the Enterprise Risk Quantification Institute to be promoting this checklist as a tool for people to be able to sort of sort the wheat from the chaff a little bit

45:29in that market. What would a good answer look like? I mean, obviously, you have 24 questions, so you can't go through all of them. But broadly speaking, what do you want to see from your vendor? What do you think? Yeah, what does that look like? What does a good vendor answer look like to your checklist? Right. Like I said, I'm not expecting vendors to go in detail on the actual code or the implementation details hidden behind that.

46:01But what I would expect a good answer to look like is, right, like our frequency distribution is a Poisson process or negative binomial calibrated with data coming from this database, like named data sources, named distribution families, named assumptions that go into the model, right? A history would be nice, like a change log, a version of- Yeah ... control of things that get updated in the platform, right, and the implications that they have on previous analysis and previous outputs, right?

46:43Okay. That would be a good thing to see. Let's say you're sat in a demo, and they're showing you the numbers, and this is your loss curve and all the rest of it. I mean, they must hate you. If you're working for some company and they're demonstrating the software and you're sat in the room there, and they must really hate you.

47:04But what would you ask? I mean, what would you ask them to show you? I mean, is there some way you can sort of demonstrate the sort of robustness or at least the directional sort of fidelity of the model, just with some simple testing that you would expect them to be able to perform in a live demo? If I'm really mean and sitting in a demo, I think I would probably move an input and ask them to tell me which way the output should move before clicking.

47:36Are there obvious... I mean, I guess there's other obvious sort of scaling things. So you like maybe double an input and then you expect to be able to track the scaling in the output, that sort of thing? Are there things in that? Yeah. I mean, it would depend on the actual model- Of course, yeah ... that they use behind. But- Yeah ... for example, for FAIR, and if you're doing things, right, with pen and paper sometimes to double-check if an implementation works, then some of these calculations, right, should be done. Yeah.

48:03And you can use numbers that are easy to multiply, and ideally, that would be... Yeah. That's the kind of evil thing that I get Sunday afternoons to pass by with is making up evil tests for the CRQ demos. Right. I mean, you've been in a few demos, I know. I'm sorry, I'm just being a bit evil here. I'm picking on these poor CRQ vendors.

48:25But what do they say? I mean, what's the deflection that you kind of get back the most? Or the excuse or- Like, generally speaking, you mean? Yeah. Yeah. Right. We have the largest data set in the industry. Oh, that's a good one, yeah. That's a good one? Yeah. Beyond the AI handles that- Yeah ... that as well. We can show you in a deeper technical session.

48:55Oh, that's a classic. Yeah. And then there's some poor guy who's been slaving away on this model for years in some backroom somewhere, who suddenly rolls out in front of some very critical customer. Yeah, no, that's terrible. We're getting a little bit tight on time now, so I just want to sort of to round things out a little bit.

49:18Couple of questions just to sort of go back to that person who sat there and maybe for the first time is sort of looking a little bit at the model and maybe feeling a bit cheated. I mean, maybe thinking, "There's a lot of really good people going on about how great these models are and what you can use them for, and now I'm looking at it and I'm thinking, following the logic," and it's very kind of clearly and accessibly articulated, the logic in the paper, and sitting there saying, "Yeah, maybe this isn't doing what it needs to be doing."

49:53Maybe it's just directionally correct. Right, yeah, maybe it's just directionally correct. Yeah. So, what do you say to that person? I mean, give them some comfort. And maybe sort of give them some comfort and maybe give them a thing to do. Where do they start? Where do they start sort of addressing maybe those issues that have been made clear for them?

50:12Right. So, I think I'd say for the models that actually informs real money, right, the insurance limit, the board number, and so on, the comfort there would be start by writing the model card, right? The purpose, the assumptions that matter, the known limitations, and the conditions of use. Like, the conditions, like scope boundary.

50:40Under which conditions should that model be used or not, right? And so that would be a first step. Then put like a band around the headline number. It can be a qualitative one, right? Like, "This has strong empirical grounding, this has limited data, this is mostly expert judgment," right? It doesn't have to be like a fully uncertainty band. So that anybody reading that can understand what kind of number they're looking at, right?

51:12And then write down two or three things, right, that would make you recalibrate. Is it a shift in the threat landscape? Is it a material acquisition? Data older than X years? Right? I think that's it, right? It doesn't need a validation function or so. Just the willingness to write down what you know- Yeah ... and hasn't been said yet. I think that's- Okay. Excellent. Okay. And then just to kind of round us off, where do we go from here? What's happening next? So the paper's available, ERQI, you go into the work products and I think probably look for your name or the model risk testing.

52:00And then the companion papers, how do people go about getting hold of those? Yeah, so we need to figure that out through the ERQI or directly by contacting me. But they are available and most of them, like I said, are already free. The vendor checklist, the practitioner's reference, and others available on request. So that's one direction, getting those documents. And people can get hold of you. So if you go into the ERQI webpage and look at the co-founders, because you're a co-founder of ERQI- Correct ... scroll down and find you.

52:40That's my LinkedIn profile, yeah. There's a LinkedIn link there. They can send you a message on LinkedIn. Fantastic. Excellent. I read them all and answer all that are not AI bots. Yeah. No, that's fair. Yeah. Okay. So write the message yourself. Don't get Claude to write it for you. Yeah, great. Right. Okay, super. Thank you very much indeed, Laura. That was a wonderful session. Very much enjoyed that. Always enjoy talking to you. Always enjoy reading your material.

53:07Same here. I say to everyone watching this- Same ... follow Laura on LinkedIn because everything she writes is worth reading closely. And download this paper and read it because it really is, it's much more important than just testing. And just testing, testing is obviously very important and we haven't done it for 25 years, so we really should get started now. But I think actually the scope of it is much, much broader. It's broader than just cyber. I think the principles are so sort of fundamental that they can be applied to any kind of risk quantification.

53:35And it's much broader than model testing because it really does tell you how to think about going about building a model. So thank you very much, Laura, and thank you very much to everyone. Thank you. Thank you very much, Graeme. I appreciate it. Bye now. Bye. Bye-bye. Fantastic. Oh my gosh. I am now such a fanboy of you both.

54:04Graeme, that was phenomenal. Thank you so much for doing that. I have so many questions. And for the audience, note that Andrew Shea posted in chat that we will publish the additional papers that Laura mentioned very shortly at ERQI. So they will be available in the same place. I did drop in the chat a link directly to Laura's paper, so that's where you can get it right now.

54:50Yeah. With that, I want to see the list of 24 questions. Have you seen that list? Oh, yes. Oh, yes. It's great. It's really super, and I really do think we should be... I mean, these are questions that if you're selling cyber risk quantification software, you really ought to have the answers to these questions. Don't think it's charged. - And so, I'm a big fan of the idea of really sort of trying to promote this as a sort of benchmark or as a sort of standard of acceptability for people. And I think the vendors that can answer all of those questions will be in a very strong position, as they ought to be. And the ones that can't, I think, are either going to have to look to themselves and say, "Okay, what is it

55:43we're actually offering here?" Or they... And what I hope is that, of course, they'll look at them and say, "No, actually that's a really good point. We should start doing that and we should really start getting our heads around that and understanding that." So, I'm really excited about that, the appendix there. Not as excited as I am about the paper. The paper is great. And I appreciate your fanboying, of course, but I really want to hand that on to Laura because that paper is really something quite special. Normally, when I review stuff, I mark down the things I disagree with or the things that I particularly like. And I stopped doing that after about three

56:21pages because all I was doing was just, I'm marking every paragraph going, "Oh, this is really good. Oh, yeah, this is really good. This is really good." I'm just like, "I don't need to do this anymore. The whole thing is that good." It's a great paper. It's well worth reading. Fantastic. I will admit that I haven't read it yet, but I will shortly, and I cannot wait to see the additional documents.

56:40Andrew, welcome to the discussion. Yeah, sorry, I just popped on because I wanted to get Graeme's take on this, which is within the presentation and in their initial comments here, we've been focusing on this as applicable for cyber risk quantification platforms. Would you say it's equally applicable for enterprise risk quantification platforms?

57:01Yeah, absolutely. So I think the qualification here is that, I think once you're outside of those kind of established modeling traditions, right? So, she's borrowed a lot. She's borrowed heavily from a lot of the sort of approach and the thinking around the way that we model, sorry, that we validate models in banking. And I wouldn't then take this paper and then reapply it to banking. And one of the things I think is really brilliant about what she's done is that anyone could take those Basel papers and say, "Okay, well, let's apply these modeling validation principles to non-financial risk modeling." But actually, those worlds are very, very different.

57:48And we touched a little bit on this in the interview, the amount of data, the quality of data. And that's part of it, but it's not the whole story. I think a lot of it also has to do with the context in which you're asking questions. So, I'm actually sat in a bank here, which is why I'm not sat at home in my normal place with the Lego flowers and the books in the background. And the questions that they are asking when they're modeling their credit risk or their liquidity or whatever it is they're looking at, everybody knows what the questions are. Everybody knows what the metrics mean and how the metrics are related to the questions they're trying to answer. And

58:28there's also a fairly deep understanding about the way that it's driving the decision-making going on through the organization. The second you get out of those established modeling traditions, that disappears. And I actually think that a lot of the issues that people face when they're building models in the wild, as it were, where you don't have the sort of extremely well-established... If there's not a PhD program in the kind of modeling that you're doing, then you're kind of a little bit more on your own. You're kind of a little bit more making it up as you go along. And that context and identifying the decision, identifying the relationship between decision and

59:00objectives, we were a little bit in on this with Marco earlier, really figuring out what the decision is, how data pertains to the decision, all of that sort of framing becomes incredibly important. And I think what Laura's done so successfully in that paper is not just... Because I think if you just bring it out of banking and go, "Well, let's apply to cyber," as you just said, they're going, "Well, we can't do anything." And she's turned the question around. She's not said...

59:27The classic thing when you're trying to sell quantification to people who haven't done quantification before is they'll go, "We don't have the data for this." And that's the wrong question. The question isn't, do you have the data for whatever it is you think you should be doing? The question is, what can I do with the data that I have?

59:40And then there's another question which is, is there more data I can get that will allow me to do more? But the first question you asked is, what can I do with the data you have? And that's very much the essence of the way that Laura has presented this. I've not answered your question at all, have I, Andrew? Well, I have a bit. It's absolutely applicable outside of cyber risk, and it's really for that kind of modeling in the wild.

1:00:01So it's for everywhere where you don't have these sort of very established modeling principles, which I think, to be honest, is everywhere outside of very well-established financial risk modeling traditions. Andrew, are you satisfied with that answer? Was your question... Andrew has gone quiet. Unusual. I'll give that a 10 out of 10, please.

1:00:26That's a 10 out of 10. Unusually quiet. So we were scoring that appropriately. Thank you. Wait, we should have number cards like at the Olympics, right? The old Olympics. Graeme, thank you so much for spending two hours with us today and for pre-recording that fantastic interview. You're a fantastic interviewer and incredibly knowledgeable.

1:00:55So thank you. I look forward to our next engagement. Absolutely. Likewise, and thank you very much. It's been a real pleasure. Both presentations have been a lot of fun. Very much enjoyed that. Super. Well, thank you. Thank you. All right. Bye now.

0:06Well, the next set of panelists. Jonny. That feels like an appropriate time to turn my video on. I feel like I was sat there waiting- Perfect ... waiting before. Perfect. It's great to see you on my screen. James, hello. Lisa. Hi, guys. Thank you for joining. I apologize for not having the ERQ mine back, and I just got out of a walk through for Haisha, so... Got to get on brand, Lisa. Come on.

0:42I know. Just so that... Well, yours is backwards for me. Yeah. Just so naturally- Is it? Is mine backwards? ... it's ERQ mine. Yeah. Yeah. - I guess I'll fix that then, won't I? - Yeah. We're communicationally- Hi, QRE. Yeah, it's- Is that one fixed? It's- Is that better? Perfect. Yes. There we go. Apologies. All right. - Okay. Well, so, I'm sorry, this is going to be a rough transition for me because I was completely enthralled by that video interview with Graeme and Laura. So, let's change context. Switch and enthrall. No, no. So this is an interactive discussion on enterprise risk quantification, and our panelists are three risk experts with extraordinary

1:49accomplishments, but very differing roles and viewpoints. So, I'd like to start by having each of you take a minute to introduce yourself. How did you come to be doing this? Why are you engaged with the institute, and where does risk quantification sit in your day job? So not a resume, just sort of those three things quickly, if you would. Lisa, let's start with you.

2:21I came into this, like, I'm going to give a wee resume, but it kind of explains how I came into this. I was brought into cyber by way of data science and data engineering. That's where the majority of my career aligned to, and the first task I was given is to create a risk dashboard. So it's been kind of a passion of mine from the get-go as soon as I got over into where I'm at.

2:49Well, that was at CVS Health, but now I'm at Health Catalyst, and I was hired specifically to build out cyber risk quantification using FAIR within my first year. And then the board loved it and wanted me to do it for all of enterprise risks. So that's how I came into this. Andrew and I, he reached out to me on LinkedIn in like end of last year, I think, Andrew, or towards the end of last year, and told me about this. And it was perfectly aligned with what my challenge was professionally, that I had to take what I've done for CRQ, expand it out to the full enterprise. So as I went on that journey, I documented my own journey, and that kind of became the

3:33first white paper that I published. Fantastic. Fantastic. Lisa, thank you, and thank you for being involved with ERQI. Jonny, it sounds like you and Lisa are on very similar- Albeit I think I'm a little bit further behind Lisa on her journey, and she's been kind enough to share some of her experiences and help me on our own journey. But I come from quite similar sort of starting points.

3:59CRQ was very much where I began when it came to risk quantification. And when I started in CRQ as a result of going to some board approvals in my prior role and having a lot of success from the most fundamental and basic quantification on what we could avoid as a result of investing in some of the programs that we were looking to run.

4:23Like, really rudimentary. No models involved, just a very simple bar chart of the cost of the program we were looking to run and how much we think it would save over a period of 10 years. So, something very fundamental and very basic and very simple, but it kind of opened my eyes to the benefits of CRQ as a means of communicating risk to the business and a means of sort of supporting business cases when you're looking to run an inherently sort of black box or something that can be quite a black box program within an enterprise. And that, for me, when I took those lessons into my current role as CISO at a travel and hospitality business, had a lot of success and a lot

5:02of buy-in running a CRQ, internal sort of CRQ approach here. And again, similarly to Lisa, unfortunately, I shouted too much and spoke up too much about risk quantification and why we should do it and why I do it in cyber. And they went, "Oh, well, tell you what then, if you know so much about risk, Jonny, why don't you bloody well do it for the rest of the enterprise?" And I find myself with the enviable task of scaling CRQ to the enterprise and taking an ERQ journey. And that's very much how we've come to be here. And David and I have obviously had some fabulous interactions and discussions with you in the past, and very grateful for you inviting me to come join as a co-founder of ERQI. And it's been

5:48such a mutually, well, I hope mutually. It's certainly been beneficial to me to be a member of it and the opportunity to learn from the people and other co-founders that are part of ERQI. But I've definitely been very in step with the journey that I've been taking the business that I work for on. And I, for the benefit of the audience, I have had an inside-the-tent tour of Jonny's risk quantification program, And it's downright impressive. What, Jonny, what you have done is, you're so far ahead of many people who are attempting to institutionalize a cyber risk quantification. So, I trust that you'll do very well with this journey expansion to enterprise risk.

6:40James? Yeah, no, excellent. Thank you for the invite to be on this today. So my entry point into CRQ was about 10 years ago when someone gave me, they gifted me the the green book, the "How to Measure Anything in Cyber Risk" book. And I thought they didn't like me, actually, when they gifted me this when I first opened it. But little did I know that it really changed the trajectory of my career. I was sort of so Enthused by it. I thought, "This is addressing so many of the challenges that I had seen in the earlier stages of my career working in cyber risk." I'm a consultant. I work with all sorts of different companies, And I thought, you know, this presents a lot of the solutions.

7:25So, At the same time, coincidentally a large insurance client happened to be asking a question about applying more of a threat-led statistical approach to investment prioritization. So we built a spreadsheet, we built a first model, And and sort of the rest is history, as they say. Day-to-day now similar to you, David you know, we compare notes.

7:53I lead a vendor. listening to the previous couple of hours and what Graeme and Laura have had to say, you know, I completely echo what what Graeme said about Laura's work paper there and the standard that you know, we should be holding some of the analysis and some of the vendors to. And we try our best with, with the company I represent, and I know, David, you do as well. But you know, day-to-day now, I sit across a number of our client engagements trying to make cyber risk quantification as practical as possible, and that's kind of really what led me to, I think, and what, perhaps what we initially sort of bonded over, David, was when you invited me to be a founding member of,

8:38of this institute, Was about trying to make risk quantification more operationalizable. Is that a word? but you know, thinking not just about the science and the math, trying to make that defendable, but also how to embed it into broader enterprise risk practice, how to win hearts and minds, And and some of the softer challenges around it, which I've come to realize are the hard part.

9:06I thought they were the easy part initially, but I think they're the hard part. Yeah, that's been a very strong theme over these two days, and Caroline Wong keeps bringing it up of the soft skills around risk quantification being so key to success. She has, for those of you who may have missed that session, we are recording everything and the recordings will be available.

9:30But storytelling was a key element of her comments yesterday and again this morning. I have placed in the, meeting chat, the webinar chat links to follow the four of us on LinkedIn. the, you know, I'm... James is a very fierce competitor of mine, and you know, we go head-to-head with James more often than any other vendor, In our competitive Work. And But I have a very deep respect for James and for the product that he represents. And you know, we've become friends since meeting at a conference last year where we both spoke, and I'm lucky to lucky to... I think I met Jonny in a similar way. I haven't met, yet met Lisa in person, but that will happen soon. - Just you wait.

10:38Yes. - Sounds like a threat that, David. I didn't mean it that way. I mean, you know, I will find myself in Florida at some point, and it'll just have to happen. So with that, let's start with some definitions. How do we, how do we define enterprise risk quantification? Lisa, do you mind taking a stab at that? Yeah. You know what I've found? If you put the definition too narrow, you're gonna have different risk category owners, as we kind of call them across, my org, that kind of push back. So I do it very loosely as something's gonna go wrong, when it does, how much it's gonna cost us, and being able to report that in a dollar range. Simple as that. Okay.

11:31And then I'm able to apply that across the entire org. Does it include kind of all hazards operational risk as well as financial risk, market risk, credit risk, all of those sort of More CFO-leaning subjects? Yes. Yes. Okay. All right. Jonny, James, any agreement, disagreement with that definition or elaboration on that?

11:59Yeah, absolutely. I'm sure they've got a better one. - Yeah, completely disagree. Let's get this now. I think you got to keep... Like, keeping it loose is exactly sort of the way I approach it here. And I was trying to think of something like pithy and like a bit like more thought-provoking around it. But for me, it's like that financial loss is a big part of it. But thinking probabilistically and thinking statistically and trying to sort of take the business on a journey around that, and not just thinking like that, but communicating like that as well is a crucial part of it. And it's a very wooly definition. I wouldn't really call it definition, but it's

12:35certainly sort of a mantra that I try and sort of communicate as part of the program of adoption that we're going on with enterprise risk quantification. James. I think I'd agree with- Coming out of the top with a big disagreement. No, not at all. No. Perhaps I'll just describe a characteristic of what I think what it is, and that's a consistent way of bringing very different, inconsistent things onto the same level playing field.

13:06And one of the, I guess, the first steps with any kind of risk analysis, at least I'm a big advocate for this, is to think about scenarios. And- Mm ... I mean, personally, I really enjoy coming up with those, right? Thinking practically about how things can manifest, and then trying to put structure around the key drivers and the assumptions and the sort of unifying process that happens and the way that we can do that across different risk classes.

13:44I think that's a key characteristic. So are we in agreement, panelists, that a scenario basis is also the right basis for enterprise risk quantification? Is that- Yeah. Absolutely. Am I thinking about that right? No, I think so. I think the characteristics that James sort of describes there are a big part of it. I also like that we've all sort of very expertly not given any sort of clear definition as to ERQ and- Yeah ... quite deliberately not given any clear definition as to it. And I think that's, as practitioners, certainly, and Lisa, I'm sure you'll agree with me on this one particularly, sort of keeping that reasonably loose internally is quite good as well. But

14:27I don't think that extends to something that I think Marco sort of raised brilliantly earlier, is the clarity of the taxonomy that operates within that broader definition and within that broader system that you're deploying on that program that you're running. And I think what James just said there about creating a level playing field and using scenarios to start to articulate things through a consistent methodology and sort of put things through a consistent methodology is the reason we do it, because you're never going to unify such disparate areas of risk specialisms otherwise. So the scenario, I think, is a key part of that framework.

15:08I'm going to admit that when you and Lisa, Jonny, rallied around this idea of keeping it loose, at first I did hear that as a little bit of a cop-out. But no, I think- Did I? - However, I'm going to strongly agree with you on that, because what I think is quantification takes some effort. It takes some effort to put together the story of the risk that we're concerned about in the scenario, and then to really and meaningfully analyze that using quantification techniques. And it's not something that we want to do with anything the enterprise identifies as a risk, but it's something we absolutely want to do with risk categories that are driving losses in peers in our sector and

16:21could materially affect our organization. We do a lot of work with electric utilities here in the US, and for years, they were laser-focused on cyber, cyber. But more recently, wildfire has jumped to the top of their risk concerns. And so I see a lot of modeling efforts on wildfire. And I think more recently, in the last 18 months, there's been a lot of attention on policy changes. And I've seen some large organizations modeling the potential effect of various policy changes that could occur that would affect the equipment they're allowed to buy and deploy and so forth. So, I like that sort of keeping it loose allows you to focus on the things that matter in the moment, because the landscape is dynamic. We have

17:35to be, I think, dynamic as well. So not a cop-out. It's purposeful, Lisa. Thank you. I think I do get more into the weeds when I get into the specific areas of risk and have a more defined definition, but it's always based on that very high level. Something's going to go wrong. When it does, there's going to be a cost associated, and we want to quantify that.

17:57So, what do you think is happening? Well, Jonny, I'm going to start with you because you got the edict to take this brilliance you've applied to cyber risk and expand it to the universe of enterprise risk. Yeah. What's occurring in the business landscape that's driving this evolution of cyber and enterprise risk quantification?

18:25Can I say me? Is it me driving it in the business? I think sort of the appetite for it and the mandate for it is a moving target a lot of the time. So, I don't think there's been a linear sort of progression towards quantification and a linear sort of progression of the business wanting more quantification. For us, it's actually a question of we want to do more and establish and mature a risk function full stop. We're not a global organization in the context of some of the businesses that are part of the ERQI.

19:04We're not small by any stretch of the imagination, and we're certainly large enough to justify a sort of dedicated risk function. But we've been a high-growth PE-backed firm for many years now. And as is always the way when you have a lot of rapid growth, you feel a few growing pains, and the sort of the compliance risk and governance pieces is sometimes an afterthought as part of that. And the commercial- Yeah ... growth is the forefront, which it should be. And so for me, it's like there's been, in the past year, there's just been increasing appetite for risk.

19:36And I think where that has intersected with risk quantification has been me, I don't want to say ahead of the curve, but me having already established quite a well-regarded and well-received cyber risk function in the business that sort of took away some of the cloak and dagger that was historically associated with cyber in the business, and at least portrayed it and started to communicate it in a way that the business understood and that the business felt that they could follow and sort of see what I was trying to move us towards, see why I was trying to justify investments.

20:12And I think that's where in my business explicitly, we came to this point of the business having the appetite and the maturity and being in a position ready to grow and expand the risk function at the same time as me having built up a reasonable pot of credibility with the executive and being asked to then take this on and deliver it in the way that we had done with cyber risk quantification. So, it was kind of like a combination of us feeling ready to be more mature generally in risk, but also having had good experiences and good buy-in from a more dedicated and specialized cyber risk function. And Lisa, is that dynamic similar to what happened in your organization, or was there

20:59a driver from the outside? Well, initial driver was the board. Our board got- Okay ... the cyber risk quantification- You did say that, yeah ... and said everybody else. But on top of that, what I learned as I was doing this that was also help driving it, the interconnection of different risk category areas on like a cyber risk could lead to an operational fallout, which can lead to a market decline, which can lead to customer. There's so many things that if we're doing them siloed and we're doing the report out different ways across the organization, we're either going to aggregate that up in a completely chaotic fashion if we're even able to aggregate it. If we're doing qualitative,

21:46you can't really do orange plus orange equals red. Yeah. But also those- Well- ... one driver for one risk can kind of- I know color theorists out there are disagreeing with you right now. Wait, who? But I think that's what really drives it to kind of push it forward as I hit challenges and stuff. I saw that and the need for it. Because the first time I reached out to everybody and asking them to report their risk, everybody gave me back something that was technically a cyber risk because everybody was just thinking about the losses that cyber are going to incur. But being able to twist that over to what's the strategy of the organization and what

22:28can stop that from happening and kind of push that down out to everybody. That's a very interesting sort of mind shift from cyber. James, are you seeing market forces that are driving interest in enterprise risk quantification or the ability to aggregate cyber up with other categories of risk? Routinely, I would say. Obviously, my day-to-day is in cyber risk quantification, but a very natural question that evolves from our engagement is, how about taking this further, and how can we start to broaden our horizons there?

23:15I think what's really interesting for me is that cyber risk quantification, I think quantification in general, is implicated in many things. The requirement is not explicit. So let me give you a few examples. If we take, I guess look at this year, there's been a whole number of different events. Take Mythos, that creates a reaction in the boardroom, and often then trying to provide an objective view on what that means for a company.

23:50Quantification's a very good answer, right? It takes a complex problem, allows us to structure the components of that problem and give a well-considered answer with- ... assumptions that can be challenged and debated. And that, as a principle can be applied to so many different, different things. So that's, that tends to be what I see as the driver for CRQ or ERQ whether it's, whether, whether you're lucky enough to have a board that asks for it explicitly or, you know, where a practitioner in a company needs to be bold and try and drive it, you know, drive it forward and suggest, "Actually, this can solve a current pain point."

24:42I think this would be a great time to take a question from the audience. And Keith McLaren has asked asking for a friend, what if you think, what if you think the enterprise could benefit by adopting quantification techniques from cyber, but they're resistant? Do you have any tips for getting them to change their minds? So this is a grassroots, like, how... Do you have any suggestions for, for Keith's friend about how to, Win a grassroots effort to promote enterprise risk quantification?

25:27Many. I- I'll let Lisa go first. Yeah. But, you know, like, it's a great question. I was gonna say, if you can show... Because the real push to, I think, just analyze risk and report out risk is to support decisions. So if you look at different areas of the organization, if they haven't taken the jump to quantification, ask them what they do to support the major decisions that they need to make, whether it be how we're aligning our current strategy to our overall corporate strategy and what can go wrong there. Like, if they don't have a decision support from that risk assessment or risk aggregation or anything that they're doing, then they're really just checking a box to probably pass an audit or to just say,

26:14you know, "We did our yearly assessment." Mm-hmm. I've never seen that. I've never seen anybody just check the box on risk management. I know. I can't- Who would do that? Yeah. Yeah. You know, yeah, what a thing. - Yeah, so being able to... Like, I'm gonna sort of, like, go back to Caroline Wong on this. You know, it's like the, it's the narrative that you can sort of craft around it. It's like you gotta be laser focused on sort of what are the benefits.

26:38You gotta have that, like, you gotta evangelize it in the business in whatever forum will accept you evangelizing it. If you can get in to the exec and get the exec on board first and foremost, then great. But, like, You know, beyond just sort of, like, you know, the... I mean, I imagine most people attending this webinar, and I certainly know everybody who is on the panel of this webinar is, has already bought into, to some degree, to the benefits of enterprise risk quantification, of risk quantification. You know, taking people on that journey is one thing and being able to sort of articulate that and have the narrative, but you've also gotta, you gotta work out what your spheres of influence

27:16are gonna be. If you wanna sort of, like, take, say, "Right, look at how good we're doing CRQ," and there... You wanna, you wanna map out who the important people are in, on the risk management side of it, the broader enterprise risk function, in the executive, senior leaders throughout the business, because these are all crucial people for taking on this journey. And you need to have, you know... I've always had a rule which is like, if I'm going to a committee or an exec board looking for a mandate or looking for a decision, m- whether it's to sort of approve a risk quantification program or broaden a risk quantification program, I've already lost the decision because that decision gets made long before you,

27:55you actually sat in that committee room. And frankly, if you haven't sort of mapped out the relationships that you need to, the... and the people that you need to win over, the people that are gonna be your supporters, the people that are gonna be the detractors of what you want to do, if you don't fundamentally understand where you're positioned within that, it's... I mean, it sounds sort of so awfully political, but it's... if you're trying to execute change, if you're trying to sort of build a mandate for change within the business where there's potential resistance, I think having a good understanding of that landscape, of the people that you're gonna be working with that is as crucial as the

28:30clarity of the narrative that you're gonna deliver around it. This goes right back to the morning session with Caroline. Thanks, Jonny, for, for mentioning that. It really does. Like, what she said about how to influence a board was brilliant. I think James, if you Suppose you're in a position that, where Jonny found himself and Lisa found herself, what, what recommendations would you offer for someone who is making that move from the CRQ lens to an ERQ lens? And I'm gonna give everybody a stab at this, but, I'll start with you, James.

29:20So just to comment on the, just the previous one, if I may. Just the only thing- Absolutely, yeah. The only thing I would add is, and sort of building on Jonny's point in particular, is find friends. Right? So, you know there's a degree, I think, of an... And this links to sort of an empathy point as well. So understanding the way people look at the world and their role and the language.

29:49you know, a really simple example of that is sometimes if you include the phrase Monte Carlo simulation in a report, it's immediately just switch-off territory. so maybe, again, you're lucky enough to have a committee where people are very familiar with- You know, language like distribution, Monte Carlo simulation, and more technical terms.

30:11But in my experience, more often than not, that causes a bit of an allergic reaction. So, actually being empathetic to the people in the room, and maybe you can talk about quantification without talking about quantification, right? Sell the benefits, not the method. And yeah, and then the find friends point, if you've got capital adequacy teams, they're often good friends, right? They're thinking about this problem in all the same sort of ways. They're making assumptions, and you can help each other as well. There's actually so many benefits that we often find with our customers when you start saying, "Let's connect with broader stakeholder groups." So, finding friends and advocates

30:58and comparing sort of notes, I think is a really great first step. And there will be some within your organization, regardless of sector. And sorry, I've now completely forgotten your actual question. So, how do you get started? How does one move from the CRQ lens to an ERQ lens? What recommendations would you have for somebody who's on that journey?

31:27Oh, God. That's a tough question to answer, because it's so specific to every organization and the role that you have. It might not be within your remit to influence broader enterprise risk- Yeah ... frameworks or decisions. A lot of the practitioners that run the CRQ capability within the customers we work with wouldn't necessarily, A, have the remit, or B, the capacity or time. So, there's a theoretical answer I could perhaps give, but there's probably a practical set of constraints.

32:05I think if you're looking to expand, the same philosophy that I think all of us would agree on for CRQ applies. So start small, right? Find a source of pain and solve it. And to my last point, that doesn't necessarily mean to say you need to go into a deep dive about quantitative lingo and methodology. But try and find a problem that you're convinced could be done better. I had a fantastic presentation from a global retailer recently, and they talked about how they evolved their CRQ capability into a decision science capability and expanded it to talent risk.

32:58The talent team came to them actually and said, "You're doing some really cool stuff on supporting decisions with quantitative techniques in cyber. We have some issues with talent and turnover, and we would love a predictive model to identify where we're potentially at risk of losing people across the globe for various reasons."

33:24And they applied it, and it worked very well. They solved, perhaps in this case, not a simple question, but they solved a pain point for someone else. And then it grew arms and legs from there. Is that how you made the move, Lisa, by starting small and focusing on an initial pain point? Or what did you learn? I mean, you've made this your- Yeah.

33:50Yeah. You've done this. I made the move. I started with what I knew. So anybody that knows me knows I am a huge proponent for FAIR. Like, to me, the first time I saw Jack Jones's bald tire thing, I was just sold. And it aligns best to the data-driven mindset that I have. So I took what I had done for CRQ, used the same model, and when I had points that didn't quite necessarily align, I kind of took a step back and I thought, "Why does that align there?" It's not like the FAIR model was built on its own only for CRQ. It was built using other models across the industry. So we got to get back to that. Like, how does that align there? Why does it align there? I kind of call it the

34:42act like a two-year-old and be a Debbie Downer, because I kind of ask why everywhere. I don't know if you've been around a lot of two-year-olds, but constantly it's why, and you give an answer, and it's why again. And just keep going until you get to the, "Okay, now it fits because I've taken enough step back." And then constantly thinking what can go wrong. Like, that's a horrible mindset to have, but once you get into ERM, you're thinking that across the entire board of the company.

35:11And I think the third thing that you really need to do is understand the strategy of your organization. A lot of times we look at what's our quarterly strategy, what's our own team strategy. All of those are built off of the core strategies of your organization, and those don't really change. How we do our yearly, quarterly team-level strategies align to that over time, but that's always there. And start with what are the five things that'll stop us from being in business and stop us from reaching our core strategy? And then you can kind of just trickle it down and model it up.

35:48Sounds simple, but - Dead easy, yeah. Yeah, just do that. Go on. So you're saying it was easy for you, Jonny? - No, not at all. I just think Lisa articulated so brilliantly that I listen to it and I go, "Yeah, when you put it like that, yeah, it's-" Sounds really straightforward. It's like, what is it? The best-laid plans don't survive contact with the enemy, I suppose is my experience of it. And I found the shift... So we went from CRQ before I got given the enterprise mandate, I got drafted into a couple of other areas of the business, like fraud, so like financial fraud. We got asked to sort of do a bit of a quantitative exercise in that space. Then we tried to do broader

36:33tech as a bit of a quantitative exercise. So we had some disparate, disconnected, all reporting into the broader ERM function, and then being given a quantitative overlay was different, same model, same approach, but different quantitative registers that we were working with. And then when we got the... I think my first experience and the first thing I had to get comfortable with in myself, certainly when going, being parachuted into these other areas of specialisms, but at least very adjacent to what I did, and then going from that. So right now, now you're going to be dealing with health and safety risk, and you're going to be dealing with aspects of financial risk as well. It was, okay, I'm out of my

37:20comfort zone here. And I think the comfortability with going from where in CRQ you're very much the SME. I knew where the data was. I knew what data I wanted to work with. I knew what data I didn't want to work with. I'd been working in SecOps for many years. I had a great understanding of just vulnerabilities management as a practice. I knew all of the controls inside out. I knew all of the regulations inside out. For me, the learning piece was actually the quantitative methodologies themselves.

37:53Whereas now it was like my specialism is the quantitative methodology, and I have to go into areas that in many ways completely alien to me. So it was just being comfortable going from SME who is driving and knows the assumptions and working with the assumptions, to actually then trying to bring other SMEs into that quantitative, easy for me to say, quantitative methodology approach, and try and bring them on that journey as well. Your role and your responsibilities fundamentally change when you go from CRQ specialist to ERQ or CRO in that capacity.

38:33Which principles and practices have you found readily transfer across risk types? I mean, certainly, in the operational risk space, if you can quantify and start to give confidence ranges on loss in cyber, a lot of those types of loss and those loss categories are applicable in other areas of business. So, if you can talk to reputational impact and how to sort of turn reputational impact into sort of a range of potential financial loss and what that might look like for you in that sense, that applies to a lot of risks that an enterprise will track in different areas. There's a lot of reputational impact in health and safety issues that might arise. And so, actually that, in terms of helping people think about the

39:19loss impact in financial terms, is something that is quite transferrable. It's like the route into it and the likelihood where you don't know what the data sources are, where it becomes a bit trickier. But even with the loss piece, even if you don't have the full knowledge of the controls that might exist in a specific area and how well-defined controls are, because actually in cyber, we define our controls quite well, and there are a number of different frameworks that help define different control, just names, just an inventory of controls that doesn't exist in a lot of other areas. But you can still sort of map actions, and you can map those controls into

39:55a confidence on reduction of certain risk scenarios that you agree. So you can start to sort of bring yourself forward to sort of inherent and residual risk in that respect. So I think, understanding control mapping has been a huge thing that is... I think that is as relevant regardless of the area. Certainly operational risk is relevant. But also understanding that the loss is fundamentally going to be defined through similar categories, as opposed to it being something completely novel in that space. So those were a couple of the pieces that I thought were quite consistent across it.

40:33Lisa, James, have you found similar, or what are your thoughts on that? I have gotten to the point that almost everything that I've done for CRQ, I've been able to align across the entire organization. Again, with that whole step back, ask why, kind of bring it to a higher level, and kind of keeping that loosey-goosey kind of definition. Because if you go out to operational risk and you ask them what their asset is, they're not going to understand what that is. However, what do they care about? How do they make money for the business? How do they lose money for the business? And kind of do that kind of a conversation with them.

41:16I don't know how many of you remember the old recalibration workshops and that whole process within FAIR. Aligning a full recalibration workshop on things that have been identified with the control or the risk owner and helping to kind of guide them through, you don't really need a control in place, but what processes stop this from happening? What processes prevent this from happening? Once it happens, what processes do you have in place that reduces that amount of loss? I mean, all those kind of terminology, as long as you don't get too definitive into the whole CRQ, because we've gotten really good at defining down to a very low level. Other areas are going to be kind of like, "I don't even know." And you

41:58just kind of got to lead that conversation and get them to- I think that's a good point. Yeah, like, because you go down the rabbit... In CRQ, you just, you go down the rabbit hole, you go down into detail. You have to almost stop yourself when you come into an ERQ point and go into that level of detail, you know, And going down the rabbit hole of trying to define things so clearly. You know, and again, it's not a... I, you know, I know we sort of joked about it at the start of it, but like, sort of, you know, good versus perfect is very much sort of the world that you- Yeah ... you have to be comfortable with in...

42:28when you go from CRQ. And I mean, in CRQ, it's good, not perfect always anyway, you know. You know, all models are wrong, some more useful than others. I'm sure that's been said at some point, you know, already so far dur- during this D- you know, during the- Yeah ... the conference for... It's interesting that Laura didn't say that, but yes.

42:49Yeah. Well, you know, and simplicity is key. - You know, it is absolutely key because, you know, you're dealing with people that aren't like... Certainly, unless you've got a team of, like, ready-made risk analysts who are statistically trained and quanti- quantitatively ready that... and you've got, you know, a whole army of them to go and quantify other aspects of business. You're gonna be relying on SMEs that aren't... this isn't their native language. This isn't their, like, bread and butter. You've got to take them on a journey, and to keep that then simple, robust but simple, you know, with, you know, clear rigor around assumptions, clear rigor around the data that you work with. But the simplicity of

43:28the questions that you ask them and the way that you want them to interface with the risk team and what you're doing to quantify and triage those risks and appropriately put a bit of, like, rigor around it in the background, you know, that's the only way you scale it to an enterprise. It's the only way you scale it to an enterprise. Okay. Can we I'd I read a lot of what James writes on LinkedIn, not because- And everyone in this space definitely should read a lot of what James- everybody should. Yeah. Absolutely. Because it's all... Not, not just because he's a competitor and I like to know how he's thinking, but more importantly because it's really good stuff. And

44:13usually I read it and I think, "I wish I'd written that." But, James, you've written that risk appetite is something that's often written down and rarely operationalized. As we think about, as we think about the sort of enterprise risk quantification space, have, have you also found that to be the case as you sort of work up the chain to the enterprise, that the appetite, tolerance, and other thresholds are not really operationalized? Or have you found it, them to be more strongly in place in other dimensions or other risk areas?

45:02So I think I think risk appetite, plain and simple, is really hard. I've, you know, must be over a hundred customers now over the last 10 years, you know, and I've... I don't think I've seen anyone completely nail this across every single enterprise risk. obviously there is a history with financial risks being expressed more quantitatively by origin, And therefore having some degree of quantitative risk appetite limit.

45:42it's grown up with it. It's natural. In non-financial risk territory is where, obviously as a practitioner of cyber risk, is where I spend most of sort of my time. And invariably, the starting point... So five, 10 years ago, I always used... I used to see it a lot. We have zero appetite for cyber risk. And somewhat flippantly, you know, I would say, "Well, let's pack up shop and go home then," right? We must accept we have some- - ... some appetite for losses due to cyber, In the pursuit of business objectives. And we must also accept that that is dynamic as well as we, I don't know, acquire a new business, we enter into a new market, we, Undergo massive technology change, and we move to the cloud. There's... Risk

46:35appetite is a living, breathing thing, whether we are explicit and conscious about that or not. And I think that dynamism can make it, can make it difficult- Mm-hmm ... actually. And then coupled with the fact that we have deeply often deeply technical cyber risk experts very good at technical know-how and understanding, and then have to translate that to a boardroom where formal risk appetite-related decisions are being made aligned to a broader enterprise risk framework, often where risk appetite measures are also tied to political drivers, like, and remuneration-based drivers. There's a big political set of forces there as well about what you introduce to a boardroom in

47:21terms of a formal limit. So there's inertia to contend with. Mm-hmm. And I sort of say the zero risk appetite thing somewhat flippantly because I do see that a hell of a lot less now. In fact, I haven't seen that for a long time. But still what I see is me- metrics, you know, patching-related metrics, security training and awareness, phishing failures, You know, and it's usually a list of 10 to 20 with some limits and those are tracked. You know, I think as s- cyber risk practitioners and people who work in cyber risk quantification, we can say that...

48:02That kind of oversimplifies it and is a bit reductive in a way, and actually can lead to the wrong conclusions about whether a business is in or out of appetite. Yeah. And so, ideally, we might move to a quantitative risk appetite curve, which then we can compare and contrast with the outputs of something like a Monte Carlo simulation.

48:26However, we come back then to the same old problems of, well, will the committee, the senior committee that's viewing that, accept it, right? Will they deem that they're mature enough to have that conversation? Can you win the hearts and minds around it? So then, is there a middle ground? And often, I do end up in this space a lot with customers, where we take the metric-based approach and then there is a subjective assessment by first line, approved by second line over the final risk appetite position. And that final risk appetite position is informed by supporting management information, and that management information might include the results of a

49:07quantitative analysis. So again, I wish there was a silver bullet answer to this, and I'd be very interested to hear what Lisa and Jonny have to say. But in my experience, there isn't one. And it takes often every ounce of sort of consulting expertise that we have to try and navigate it on a case-by-case basis within a customer.

49:31I've got a silver bullet. It's great. We've solved this here, which is what no sort of risk practitioner has ever said with regards to risk appetite. I mean, risk appetite has been like such a... I remember one of the ways I've tried to sort of make it a more tolerable exercise and a less tricky exercise is we've, again, we've kind of like discerned risk appetite from risk tolerance and a tolerance level that we've got.

50:06So for whenever I was talking on this from a CRQ perspective, I was talking about, "Okay, what's our tolerance for this?" And that was very driven by the outputs of our Monte Carlo simulations of the model that we were working with. And okay, and I'd go into conversations with the exec and I'd have the CEO, CFO, and chief commercial officer, and I'd say, "Okay, what probability of a loss exceeding X amount are we comfortable with?" And we'd kind of like rattle through the different bandings, and that was how we set the tolerance for cyber risk quantification. But that's going to be tricky for us, so we need to now do that for all the other domains of risk that

50:43we're looking at. And we're going to take that tolerance approach and keep it separate from the appetite approach. But I remember when they asked me to sort of do enterprise risk quantification, I was like, "Right, we're going to get a really clear..." Because one of the things that I don't think has existed well in our business is that appetite statement. Mm-hmm.

50:57And actually getting them nailed onto a... Getting, as you touched on it yourself, James, like getting the exec to sign off an appetite statement that applies not just to cyber risk, but to just risk in its entirety as in its approach. Getting that into pounds and pence, I didn't think was going to be a viable exercise. You start people looking over their shoulder a little bit too much if you start pushing that. But we were able to get them to agree to a statement of appetite, a sort of a general statement of appetite of how we would approach risk at our business. And I think that's carried good narrative power, and it's helped with buy-in to the program as we've proliferated that program

51:37through the business. And it's not a quantified statement, it's a very qualitative statement around risk and what the exec are comfortable with. But they were able to sign that off, and it's helped feed through to tolerances and how we define and we work with tolerances. So they are quantified. So, it's by no means a silver bullet, but it's definitely helped us in the way that we've communicated risk internally, just by saying that the appetite is the North Star. That's the qualitative, purpose-driven statement that the exec have signed off. For each domain that we now will quantify, we'll quantify and we'll come up with clear tolerances so that we can understand when

52:15we're breaching those tolerances and escalate them accordingly. The lower down the chain you get, you stop talking about tolerances and you start talking about KRIs and control- Mm-hmm ... efficiency metrics that you want to work with. But for me, the biggest sort of buy-in that I got from the exec was separating tolerance from appetite as a definition within the business.

52:40Lisa. For me, I never got to the point of getting that appetite qualitative, quantitative from the powers that be. So that's kind of the reason I went in. My paper is about a survivability model. So instead, I inform the business of, "These are our top risks. We'd cease to exist at this level." And then all of the bottom tier three risks, I call them bottom level risk, and then the drivers map up and have a portion of that and the probability of it happening over time. So that I'm informing them when it's getting close to survivability based off of liquidity or different financial aspects. That's the first phase that we're going. I report out ERM

53:31end of October to the board. Next phase will be, "Okay, so this is when we cease to exist. When are we going to get uncomfortable?" And that's going to help drive that conversation. But I needed to present them with something that gave them like the, "Oh, this is when it's really bad, but we don't want to get here. Maybe stay here," to kind of just start that conversation, because it was something I was getting pushback on.

53:54Mm-hmm. That's such a great point, and reframing it like that. Yeah. And I've seen that work as well. What would cause such a shock that it challenges our very existence? Or the slightly downgraded version of that question, what would affect this year's results materially? Those are two really great questions to have a discussion around, again, without even mentioning the phrase appetite. It's a reframe of something that I think is quite tricky. I think it straddles the intersection of risk and resilience really well, as well. Yeah. It was a very interesting thread yesterday in Matthias' presentation on the research he's done around risk in his company, or not in his company, but research he's done

54:45from the perch of his company around risk in publicly traded companies. That was a really interesting bit of that sort of material shock kind of distinction that he made there. One quick question from the audience. How do you approach the issue of your risk owners, or whatever you call them now, having to take responsibility of their risk, something they might not want to do?

55:16Well, somebody has to own it, and that's usually driven by somebody above them saying they own it. And it's not really responsibility, if you think about it. It's acknowledgment and a risk response. Here's what the data says. I'm not going to dictate to them that they have to mitigate this. If they want to accept it and they've got that power of be to do, there's no real...

55:46I don't know. Ownership doesn't mean responsibility. I'm still the one driving the conversations to build the risk statements, to build the how everything aligns, how we do the recalibration, the loss scenarios, and all of that. But as far as accountability, I just said it based off of what their bosses said. Got it. There's got to be somebody. If nobody's accountable or if everybody's accountable, nobody's accountable. You've got to have somebody to make that decision. And it really wasn't a problem where I was at. It was kind of already aligned.

56:24There might be some confusion as to what a risk response is, so kind of being candid and open about that conversation. Like, "I'm not dictating to you. I'm giving you data-driven for you to respond, and your response is not going to be reported up." I think that, yeah, I think there's definitely a role for empathetic education- Yes ...

56:52in the scenario painted by the audience member. And sorry, I marked the question as open and it disappeared to me, so thank you for the question. Let's do a final rapid round. Last question. God. One sentence each. Somebody watching this goes back to their desk on Monday and wants to improve their risk practice. What should they do?

57:21One key takeaway. Well, I love how every other question we've been jumping in straight and away, and on this one, we're waiting for you to- We're like, "Huh?" ... to nominate. I'm telling you, in prep for this, I've written probably a hundred different sentences down. But instead, I looked back at where I failed at doing this in another company versus why I was successful. And the key factor is having stakeholder engagement and having a stakeholder who is above you who wants to drive this and aligning with them. Because you could write it all out, you can deploy a full cyber risk quantification program.

58:02If the powers that be don't like it, don't want it's not going to go anywhere. So finding those buddies, those partners that are like-minded and want to mature risk management program, getting buy-in, and getting Jack Jones' book if you're doing . Mondays, everyone read the green book. Is that the- as well? I think that I'm just going to say relationships. Build relationships.

58:29Getting anything done in any business, whether it's risk, whether it's any other change that you want to try and instigate, you've got to build relationships. So, that'd be the number one thing to focus on, if I say make it better on Monday. James. I'll try and come up with something novel. So, within the bounds of what's safe to use AI for, I'll just caveat my response.

58:55Take a decision in concept that your organization's perhaps making qualitatively, and ask AI how you could do it quantitatively and break it down and start to challenge it. And again, don't put any- Yeah, be careful of that because AI thinks they know everything. It's going to come back with this wonderful path. Yeah. But a starting point perhaps to think about a problem in a quantitative way, and of course, yeah, fact-check it and whatnot. But- So- ... I think a practical step.

59:31I'm going to answer that question too because of very strong points that Lisa made earlier about understanding strategy and what could happen that knocks you off strategy. That was such, I thought, very sound. That's a really good sound bite. Great sentence. Make sure you understand strategy, dwell on strategy. Mr. Shea, welcome back to the table, my friend. How are you?

1:00:05Oh, you're muted. He's muted. That's how you are, muted. Wow, that's a new one. Self-muting, I was muted, I will be muted. I am all of those things. I'm well, thank you, and thanks to this fantastic panel for all of their efforts, both in the work product creation as well as today. That was fantastic, so thank you. Yeah. Thank you. And Jonny, I think a case study on how you've championed and gotten traction on risk appetite and risk tolerance in your organization would be a very valuable work product to have out there, if that's something that you'd consider doing.

1:00:50Because I've seen- Sure. Need to get the first one over the line first, though, like I said. I've seen it. We're still in draft. Yeah. I'm going to ping that reviewer that you're waiting for and see what he's been up to. Okay. Thank you all. Of course. Andrew, I see Harshit in the attendees. I'm going to try to promote him. There he is. You got him.

1:01:19And- Are you going to un-promote us if we just... I will demote you, yes, momentarily. I don't see Edwin. Either do I. I just pinged him, though, so he will join hopefully at some point. Okay. Well, I leave you with Harshit. I'm going to disappear myself momentarily. I'll be back in just a minute. Harshit, great to see you.

0:06There he is, the one, the only, the GRC guru, Harshit Chandel. Hello, my friend. How are you? Hi, Andrew. Hi, David. Hello, everyone. I'm just going to throw this out there because the world of enterprise risk quantification is just magnificently interesting. But there is maybe one other thing that's equally as interesting, and I say that tongue-in-cheek just to be clear, and that is our own personal lives and our own families. And I want to publicly congratulate our presenter, Mr. Harshit Chandel, on his recent addition to his family. And so, congratulations again, sir.

0:52Thank you, Andrew. Well, while we wait for Edwin to join us, or Mr. Ed Covert, let us just go ahead and get started, Harshit, if that's okay. Yeah. And you know me, I'm super shy and introverted, so I'll try and do my best to carry the conversation. And lo and behold, speak of the man, the myth, the legend, there he is. And it's what? It's fourth and that long? Is that what that was? Yeah, about that long, yeah.

1:21Well, cool. We're just doing intros. So, Harshit, go ahead and introduce yourself to the group here, and then, Ed, you will follow, and then I will- How are you doing? ... do my best to be quiet. Hey, David, you're still on, my friend. Your video, audio, sorry, David. Okay, now you're off. Cool. Harshit, go ahead, my friend. Thank you. Thank you, Andrew. Hi, Edwin.

1:51So I'm Harshit Chandel. I have worked in cybersecurity domain for the last 18 years, being part of building GRC functions and managing cybersecurity operations as well. And my last role was head of GRC at one of the fintechs here in Canada. And after that, I am doing my individual practice building as of now. And I'm just going to add to that, again, Harshit has a really wonderfully in-depth knowledge of the space of GRC, both as a function, as well as, per our conversation today, architecture as it relates to the bigger picture.

2:34Ed Covert, hi. Hi. - Go ahead and introduce yourself, my friend. So my name is Ed Covert, as Andrew has pointed out. I am the director of enterprise security architecture and strategy at Marvell Technology. We are a semiconductor manufacturer. But my interest today, my goal with this conversation is really around the larger practice of enterprise security architecture and how it relates specifically to GRC.

3:05I've got about 30 years now of cyber experience, which makes me sound really, really old. But this is a passionate topic of mine. That and risk quantification are the two big things that I care about anymore. You know, you don't sound old, Ed. You sound wise. So let's just- Well, you're a generous human being ... let's just kind of reframe that, so...

3:27You're a generous, generous man, and I appreciate that about you. All right, gentlemen, I'm going to hand it over to you for now, and I will rejoin you towards the end of the conversation. Sounds great. Thank you. Thank you, Andrew. So today, we'll primarily talk about the GRC reference architecture. It's primarily a concept which I built over the period of time on building GRC functions over and over again and working in the GRC function.

4:01The primary reason, the primary motivation was GRC as a function in itself is very structured if you look at it, right? It very much aligns with the reference architectures which we use for various other cybersecurity operations, et cetera. Now, if we actually look at it, GRC as a function is a combination of business layer, data layer, application layer, infrastructure, and which is supported by people. So what does that mean?

4:40What it means is basically, cybersecurity is, as a function, primarily supports the business. It drives the secure operations of business, and the whole function, and it works on the core mission and objective of the organization where the organization wants to drive, and then you build the security around those core objectives. So, if we look at the GRC, what is GRC? GRC as a function is primarily responsible to manage the risk for the organization, managing the risk of technology, managing third-party risk, managing cybersecurity risk. And it is primarily an extension, in a lot of cases, an extension to the ERM function, which is enterprise risk management.

5:38Now, since it's driving those mandate, it looks at the core mission and vision. I'll probably go to the... probably talk about the business layer. So, it basically looks at the mission and vision, the business objectives, and deriving the scope and help derive the scope and context. What does that mean is- What is the scope of your cybersecurity operations? What are the peripheries? What are the perimeter? What are the business object functions, et cetera, which needs to be covered?

6:17So all that combine to build the business direction in which the cybersecurity as a function need to be optimized and worked towards. In order to do that, we follow a industry-aligned approach, which we primarily call frameworks, the industry-aligned frameworks such as NIST CSF or ISO 27001. So we take the program frameworks to derive the overall program, and then we go into looking at the controls frameworks to identify and build those specific controls which are supposed to be implemented to manage the cybersecurity as a function.

7:07So that primarily covers the business layer which drives the direction, the overall direction. The way we have tried to organize it is one of... This is an industry-known concept of 5W and H as to why, who, where, what, when, and how, right? So why is primarily what is the mission and vision and business objective of that specific layer or overall GRC as a function? Who owns the roles, responsibility, and who are accountable for the cross-function teams? Where is like, what are the key driving factors?

7:54What is how, what are those core components we are leveraging? Because frameworks, policies primarily go ahead and derive, give the direction to GRC as well as the overall cybersecurity as a function. When is various instances. This primarily correlate with when we are managing and how we are measuring our control operating effectiveness. And how are we first...

8:27How is basically we look at the business mandate, then based on the business mandate, we build the whole program, and the whole program is... And to manage risk at the end of the day, what are we doing? We are collecting various data elements from various sources. It can be protect control, it can be identify control, it can be detect control. And we are correlating and analyzing those various indicators to come to a conclusion of where our risk appetite is lies. And how we basically do it is, most of the time, we leverage some or the other kind of application, which we primarily call GRC application. For example, you would have a GRC tooling.

9:23It can be a few names like Archer, the ServiceNow, OneTrust, et cetera. You would leverage a GRC ecosystem to manage this, these complete workflows. And workflows in turn basically are the ones which generate data, which is synthesized and analyzed in these applications. And all these applications are eventually hosted on an infrastructure layer, which is either managed by the vendor or the organization.

9:56So- So, Harshit, real quick, let's back up for... I want to add some context, a couple things you just brought up. This business layer, right? This is, in my view, the foundation to everything else, right? We exist, as you pointed out, we exist as a function, a cybersecurity function, of which GRC is a part, to serve the business, right? There's a legitimate business need for us to do something. It's not just that, as I tell my staff, we're not just doing this because we like it. We're not doing it because we like to lock things down or put firewall rules in. We're doing it because there's a legitimate business need.

10:31And that business layer, as you called it in your framework here, is that need. It is the objectives of the business, the goals, the processes that the business follows. It is the locations where the business operates and time dependencies that the business has to meet its objectives and to do its things. Plus, to layer on top of that, all the regulatory controls that are required to operate, depending on where the business lives. For example, Marvell is a global business, right? So we have California requirements, US requirements, European requirements, Asian requirements. All the places that we operate, we have to layer those things on top of it, and we layer the strategy. What is the business

11:22trying to do over the next five to 10 years? And then your other point, I want to really get into this, is this idea of risk. In our world, particularly in the risk quantification sphere, risk is a very specific thing. And put it in fair terms, risk is the probability of an event causing some financial loss, some loss event, right?

11:49So when you're talking about risk, this reference architecture can help you achieve that and put constraints around or put context around why we do this. So I just wanted to throw that out there and sort of add some color commentary. Yeah. No, rightly pointed out. So when we talk about risk quantification, we primarily focus on the financial losses, right? But at the end of the day, what is risk? Risk is primarily a function of the probability. It's basically, what is the likelihood of occurrence, right? What would be the probable impact?

12:29And then we look at the control implementation, the operating effectiveness, which reflects on the extent of the vulnerability because of which this threat can exploit that vulnerability and then there can be a potential loss, right? It's the likelihood of occurrence, which we in turn call is as the risk to the organization.

12:55Correct. Right. Now, how we come up to what is the risk? We look at, there are various factors we look at. One, we collect data from various sources, right? What is that data? So for example, we look at... I'm going a little too tactical right now, but we look at what is the asset, the criticality of the asset. And based on the criticality of the asset, what is the business relevance within the organization function? Based on that, we decide what are the controls which are applicable. So first, we would go ahead and evaluate the inherent risk.

13:40If there is no control, what would be the potential risk of compromise of this specific asset? Then we start building controls. So control can be, if we follow the defense depth approach, or it can be identity and access management control. It can be a data protection control. It can be you are doing event logging, et cetera. So every control in its state of existence is generating some or the other kind of data.

14:17That data eventually comes and that data tells us that what is the operating effectiveness of the control, whether the control is actually achieving the objective because of which it was set into place, right? If you look at the data layer, that is what it is, right? To get to these controls, if I step back, go back and talking about the overall framework approach, we take in the CSF.

14:48We define that based on the CSF, we go ahead and define our domains, control objectives, different controls, et cetera, and those gets implemented. So I think that's where... So as you rightly said, the business layer set the context, but one of the most critical layer is the data layer. That's where we are collecting and synthesizing and analyzing. And how that happens, it happens in various formats through control attestation. It can happen to third-party assessment. It can happen through vulnerability management, et cetera.

15:28And when we build matrices, so first we look at the key performance indicators, which is called KPIs, of the operating effectiveness of those controls. And based on how those controls are performing, what those KPIs look like, and we collectively build those matrices around it, and how that collectively looks like eventually goes ahead and reflect on the extent of the risk the organization have. Where, Harshit, in this model for our audience, where do the metrics live? Do they live in the data layer itself, or they sit outside of it and receive as inputs the data?

16:12So matrices is something which is at different layers within the organization. There can be a tactical matrix, there can be a executive-level matrix, there can be a board-level matrix. So it sits at all the layers. But so for example, when we are working in the data layer, that means we are very tactical in nature. These are operations teams who are performing control attestations, who are working with the cybersecurity operations to identify how the controls are being performing. So they build tactical KPIs and KRIs those matrices. But when we look at the business layer, we may be looking at those five or six or eight matrices, the key matrices which are

17:07being presented as a part of a board report, right? Then application layer. So first, in the data layer, we build our master data, we build our framework, we build our control libraries, we build our what are the evidences, we build our methodologies to measure these control effectiveness, et cetera. And then we start collecting, and we build those workflows. We build those tech configurations which will be implemented in the application to achieve the core objective of these workflows, et cetera.

17:46And of course, dashboard and reporting is also there. And when we reach the application layer, right, where whatever was being built in the data layer, right, all that analytics is then we leverage an application to optimize and structurally manage those aspects, right? And every- ... tool or a technology, again, have its own matrices, which is being managed by the operations team. So I think matrices is something that sits at every layer. It all depends upon who is going to consume this matrix.

18:26Mm-hmm. And that is how the extent and the depth of information which is shared from that matrix is tweaked, is being formulated. Gotcha. Thank you. Right. So, yeah, I mean, we were talking about the business layer. This sets the direction. Data layer is where all the data is generated, all the analytics. So this data layer becomes your input to the GRC engineering. So we build the logic, we build the data, we synthesize it, we analyze it, and then that is being fed into the application to structurally optimize the whole function, right? Then this is where your GRC tools and technology comes into picture, and then we basically have the infrastructure layer on which the GRC technology sits in. And

19:29people there, I've tried to... This is something which is debatable, but I've tried to put it across all the layers. For example, because within the organization, different level people in different functions are consumers of the information which is being generated. So, even, this is just a way or a structure to optimize and give a structure to how a GRC function should look like. So for example, when a person is taking the role of head of GRC, how does the thinking process should look like? Because if we look at in a very different terminology, GRC is a service provider to the organization, right? They provide the risk assessments, et cetera, the matrices generated. All are,

20:36in a way, something they consume as an input. They synthesize that information and then go ahead and tell the organization that, "You know what? This looks like be the risk level of the organization because of these, these, these, these reasons." Right? Gotcha. So let me ask you a question then about this, because this is a very structured approach.

21:01Can you integrate this into existing frameworks? For example, let's say I'm building out an enterprise security architecture that's focused on SABSA, right, the SABSA model, or I'm taking the TOGAF architectural framework out and applying a security lens to that, or even something like perhaps if you're in the government, DOD space and DoDAF or something along those lines.

21:28Can you integrate with this with a larger enterprise security architecture framework? And if so, are there pitfalls that we should be aware of and things of that nature? You could talk a little bit about that, it'd be great. So in principle, yes. Mm-hmm. But the objective of SABSA and TOGAF is a bit different than what this GRC reference architecture talks about. It very well aligns to your NIST approach or ISO approach. And in principle, it does align with the structured, the industry-aligned standard of architecture frameworks like SABSA.

22:07But if you say, "Is there a like-to-like match?" I don't think so, because those architectural frameworks work on those core principles of how this should be, how various things should be, and it does, in principle, align with that. Gotcha. Okay. Andrew, do we want to open it up to questions in the audience, or do you have specific questions you wanted to ask us?

22:40Did we lose Andrew? David, welcome. And I'll jump in since I took a brief break to deal with an issue at work, but I'm back now. Thank you for a great presentation. And I don't see any questions in the Q&A interface. That's how we've been handling questions. Okay. So, I guess, what's next, Harshit? What's next? So, yeah. That's my question.

23:27Yeah, so probably, I would want to make it more conversational and discuss around, say, for example, even, you have to implement. How can you leverage or utilize this reference architecture to optimize what you're doing in your organization today? Yeah, for us, we're a maturing organization. So we've been around for a long time, but from a cyber standpoint, I think we're still probably, like most organizations, are maturing our processes. My role here is obviously to define the security architecture writ large for the enterprise.

24:10And so we're using a SABSA model for that, is what we decided to move forward on. GRC is a function, a sister function to us, to my organization, so we interface with them quite a bit. Part of my team does security architecture reviews for every application that gets the processes Marvell data. And those findings become- ... inputs into the GRC process, right? So they get logged as in the risk register.

24:36Now, again, being a member of the Enterprise Risk Quantification Institute, I have a very specific definition of risk. And so, I think we use that term loosely at times. But we're trying to integrate, so we're driving everything from a business lens. It's not what threats are out there. It's not what vulnerabilities or what the latest and greatest CVE counts. For us, it is very much what is the business trying to achieve, and then how do we shape the cyber program to enable that to happen?

25:15So at the end of the day, as we both said now, we serve a business purpose. We're not just doing this because it's a good time, although it is a good time. Is that funny, Andrew? Well, I think of it as a good time. My apologies. Zoom is getting a little confused, and I couldn't find my way back into the meeting, so thanks for jumping in.

25:35We're glad you're here. We're glad you're here. Yeah, I think from a discussion perspective, right? I want to go back to Ed, some of the comments that you made about the drivers, right? Mm-hmm. And that being kind of from the business side. And in the world of risk quantification, we're often talking about risk scenarios and the criticality of defining risk scenarios so that we can provide input to inform decisions. And it's interesting to me to think about, okay, here is a question, right, that I have received from a chief information security officer, right? "Hey, does this security event impact us? Are we ready to prevent this from occurring?"

26:30And that could have been just as easily a chief risk officer saying, "We have this operational risk." So how do we take that question and think about this GRC architecture in light of trying to answer it, right? And Harshit, I'll just comment. I'll make this quick comment, right? The data layer that you talk about, right, really has to enable and empower our efforts in order to answer that question, right? But is there any way that we would alter how we think about this architecture based on those types of questions we're receiving?

27:01So- Is that for me or Harshit? Everybody. Harshit, go ahead. Everybody. So primarily, from quantification perspective, as you said, we build on risk scenarios, right? The whole concept is, so you take a risk scenario and then you start getting into evaluating various scenarios based on which how this risk can be materialized, right?

27:29In doing that process, first of all, you are looking at those driving factors from if this risk happens, what are the business objective or my regulatory impact or business impact, financial impact, et cetera, can happen. So that's the first evaluation which happens thinking from the business layer perspective. And then when we talk about the risk scenarios, we look at different situations, et cetera.

27:59And that is where we go ahead and look at those, what are the controls which are implemented which will prevent this risk scenario to happen? Now, looking at that, that is where the data layer comes in. Say, for example, a person can take this file from the internal ecosystem out on his personal laptop or Gmail, right? This can be a factor because of which XYZ risk can materialize. So now in the data layer, we'll go ahead and look at what are the DLP policy efficiency. When was the last DLP policy efficiency being measured? Whether my policies are working fine or not. Are we leveraging those test cases, et cetera?

28:48Or we do not have a credit card policy in our DLP, right? That can be a finding in itself, right? So we basically look at the trending of the control effectiveness over a period of time, how effectively this control has been functioning, which will prevent my risk scenario to occur, or it will reduce the impact. So for example, even if this person has taken out the data, there are compensating controls, or there are additional controls that there can be remote wipe the moment my DLP is going to trigger an alert, et cetera, et cetera, that this data has been taken out of the organization, et cetera. I got you.

29:39Yeah, I would throw in there that- Yeah ... I view the GRC function as the keeper of the scenario, so to speak. Yeah. Right? And it's that data layer in the reference model that you described that has all the necessary information to enable the risk quantification world, right? So they're keeping a list of what assets that we care about. They're keeping a list of the value of the data.

30:06They're keeping a list of the scenarios and how they're derived, and on the probability side versus the loss magnitude side. All that information is funneled into them from various and sundry sources that enable the risk team, the GRC team, if you will, to do its work, to actually derive the scenarios that we use to enable the business to function.

30:35Because if you can't derive the scenario properly, then business either doesn't have the data or they're working off of faulty data. And it's just as dangerous as not having the data. Worse, bad data is just as much of an impediment as anything else. And I don't want to be that business guy on this session, but I'm going to go down that path just a little bit farther because- Please ... there were a couple things.

31:03There were a couple comments that you both made that I thought made it worthy to bring this up. So, one of the things we were talking about, I was talking to earlier about Caroline, was understanding the business, right? And so we talked about if you're a public company, you have an annual report, right? Mm-hmm. If you're a private company, you may not have access to an annual report because it may not be shared with you, so there's a bigger challenge there. But fundamentally, right, the notion, right, that there are business objectives, right, and business descriptions that are helpful to folks that live in the GRC space. And I'll give you a specific example, right? So,

31:43when you look at a 10-K, it may, for example, say, "These are the top four objectives that we have for revenue growth in the next year." And it may indicate that we are going to be doing business in a new geography and/or a new country, which then may have its own compliance, regulatory, data security, and privacy requirements, right? And so, making sure that those get incorporated into, as a kind of driver into the model, seems to me to be an important point that I think both of you were alluding to earlier. So I'll just ask you to comment on whether I'm insane or moderately intelligent. I think both things can be true- - ... for the record.

32:25But yes, risk is a living, breathing thing, right? And understanding it requires constant updates and incorporating new information and new concepts in. This is the problem with enterprise security architecture in general, is it tends to get built and then put up on the shelf, and then not touched again until, oh, the risk team said, "We've got a compliance requirement to update our ESA."

32:53That is not how you want to manage risk. It's certainly not how you want to manage cyber, and it's certainly not how you would ever build a business plan and then put it on the shelf. So it needs to constantly be updated. It needs to be fed and kept and cared for, like a living, breathing thing. So that's the point that I think I would drive home, is that you, regardless of what the new information is or where it's coming from, if it's relevant, it needs to be incorporated and in a timely manner.

33:20Yeah. And the way, Andrew, you said, the business is moving into a new country. For example, you miss taking into consideration the key regulatory requirements which allow you to operate in the country, right? And that is why your operations are delayed. Your operations are delayed, you cannot be functional, your revenues will definitely get hit, right?

33:46Or looking at another very tactical example of the key application which supports the business was not being attested or the KPIs are not being met, and which leads to a breakdown in the key season of business. Your operations are hard, right? So having this reference architecture actually helps the function to structurally think and make sure they don't miss those key aspects.

34:20So a little tactical side of how this basically helps. So, the six-dimension framework, the who, what, when, where, why, right? I love that framing, Harshit. The one that I think probably gets the least visibility sometimes is the when element, right, or the time element. For people who are GRC practitioners, right, or risk practitioners, right, how do you think about the when component from the framework in a little more detail, if you don't mind?

34:58Because the time element is very important, and it gets lost sometimes in the discussions around risk, right? The time to impact, the time to recover. There are all these elements from a time perspective, if you will. Right. From time perspective, there are a couple of things. One, we basically always take into consideration the RPOs and the RTOs, the recovery time objective, recovery point objectives, et cetera. Two, those are key elements to take into consideration while defining the criticality of any specific business function or asset, et cetera, right? To which we primarily help us to understand the extent of criticality and the extent of attention this

35:45process or asset needs to be given. The second time aspect is while defining our control library, most of the times we take into consideration how often a specific control need to be monitored. It can be regular, it can be daily, it can be weekly, quarterly, monthly, annually, or whatever, right? And that is something which very diligently need to be monitored and make sure those timings of making sure we are monitoring these controls, operating effectiveness are being taken into consideration. And that is, again, one of the critical part of the data layer, right? So those are two different views of how the time is being taken into consideration.

36:37Ed, would you like to add something? Well, I just think there's- Timing, Andrew, is so critical. And it's not just... I mean, yes, there's RTOs and RTPS. There's all the things that the controls that we measure and monitor over time, but also things like, when does a regulation kick in? Right? When is the adverse effect of not doing something kick in? For example, SEC requirements, right? Your disclosure for cyber incidents, material cyber incidents, you have four days to disclose something after you've determined material to your organization.

37:12How about the timing of sequencing of steps in a process, right? If you know it's going to take four days between each step because of outside parties or things of that nature, that needs to be factored into your risk model. Business requirements have timing into them. For instance, are you a net 30 on payment? Are you net 15? Are you net 45? All those things become relevant risk factors that you need to consider as you're building out your risk program.

37:46Yeah, it's interesting, Ed. I read something recently along the lines, it was talking about resilience, and it started talking about RTOs, right? And then there was kind of a branch of the discussion that went into the direction of that when you're looking at resilience and you're looking at the controls that make up resilience, in this case, I'm specifically talking about the ability to recover, right?

38:12And so just to make it more specific and more helpful, let's say you're recovering from a ransomware event where there is a lockdown on certain elements of your operations. There was an interesting element of the timing that you kind of were just speaking to that's relevant here, which is, if these steps aren't taken in this manner when you're trying to recover, you just delayed your recovery window by from 72 hours maybe to 72 days, right?

38:38Because there is a necessity for the definition of that. And it occurred to me as I was reading that and as you guys were speaking, Harshit, right, that having a well-defined architecture, right, helps, can be a very helpful guide to ensure that those steps were taken in the appropriate process. But so, thoughts? Well, first off, resiliency is the new black. I don't care what anybody says. - It's going to just make us all look great and be thin on camera.

39:07We don't, and I think NIST has not done a great job with this as well. If you go look at the cyber framework, right, the cybersecurity framework they put out and all the controls, how many are in prevention and detection versus how many are in recover? And it's just, we as a function, cyber function, right, the core thing of what we do is confidentiality, integrity, and availability. It's foundational to cyber. We've sort of given the A, the accountability, or the availability rather, over to another organization. We sort of gave it to IT and just said, "You guys deal with it," to our detriment, in my mind. So resiliency is the thing that is going to keep us

39:58as a going concern. It's going to keep us as a business. Because we've said it for years, it's not a matter of if, it's a matter of when, right? When the attack happens, when the breakdown occurs. If we don't have the ability to recover in the face of, in the words of Richard Hale, the face of a persistent and determined adversary, then we've lost the battle at this point. So having that ability to recover and having a risk function that enables that to happen and is thought through that process, which I think, Harshit, your reference architecture talks to or gives the ability to at least have that conversation, I think is still foundational to cyber. It is a core function of what we do, and we

40:49need to be doing a better job of it. To your point, Andrew, if you've got an RPO of two hours, but yet three of your systems that you managed aren't being backed up except once every four days, you're not going to meet that RPO. And unless you know that, then your timing issue, we were just talking about all those things kick into play. You're out for five days, essentially. You're not going to get those systems back because you don't have that much data. Yeah. Backup is such a foundational but key example of how a structural approach can support the resiliency aspect of an organization.

41:38So let's pull on that thread for a second. This is kind of an Andrew personal bugaboo. So for everyone listening, please put that into context as you hear me say these things. It's not an institute position. The primary response that I see to we need to review our ability to recover, right? The number one, and I would say by far from where I sit, the most kind of common activity is the tabletop simulation. Mm-hmm. So I get that that's important for getting people aligned on the same page, but to the point that you just made, I mean, it's not an actual test, right, of recovery.

42:22And how do we address that? I mean, if I'm wrong, if you disagree with me, please do. But how do we move from tabletop exercise where we're talking about how it should recover to actually testing it effectively? Is digital twinning the only answer out there? And do you believe in that concept, by the way? So anyway. So I'm a big fan, and it's just not practical. I get it. I know it up front.

42:49Not practical for most organizations in the chaos monkey theory. ... of this. Ah. Are you familiar with Chaos Monkey? I am not. I understand- Okay ... with avid intent. So Netflix does this, according to press reports. They have built such a resilient system that they have developed a program where they will literally just turn things off.

43:10They have people they pay to turn systems off to see how their recovery function works and how well it works. And they do it all the time, and you don't notice it because they've built such resilient systems. Wow. Right? That is obviously not practical for everyone, but that is the approach, the thought process. And I agree, tabletops are vital, if for nothing more than they get certain key parts of the organization thinking through the process. And then you have to take it to the next step. Then you need to take it to actually practicing some of this stuff, not just talking, sitting around a table and discussing it. You need to actually walk through, maybe on a Saturday when traffic's light, or you're not in the

43:54middle of a major upgrade or something, and turn something off and see what happens, and walk through the process of what would happen. And you do that repeatedly because you fight like you train, train like you fight, is what we used to say in the service. So, you need to test it, and actually test and not just talk about it. That would be my two cents. Harshit, your thoughts? Yeah. I think I totally agree that...

44:18So tabletop is a great exercise to do, right? You test your workflows, make sure people are available, et cetera. But the technology ecosystem, which is leveraged for these recoveries, in a lot of scenarios, a lot of the organization are dealing with things like obsolescence. And- Mm-hmm ... I think this is one of the common problems at a lot of organization. Not everybody have resilient infrastructure like Netflix.

44:52But you're talking about a great tabletop exercise, but on the other hand, you are dealing with the technology obsolescence and heavy dependency on one single vendor, et cetera. So, I think tabletops are great, but we once planned based on calendar, but we actually need to turn off the switch and see what happens then, right? So, yeah, that's- The other way you can look at it is, instead of taking a system offline, take somebody critical to that system offline.

45:32Pretend they're not available. Pay that vendors for not getting picked up and then see what happens. There's lots of different ways to test this process, but the point is test it. Test it, test it, test it. That's a really cool angle. And I remember a lunch that I had, it was about a year and a half ago, and it was with the CIO of a utility company here in Minnesota. And I was trying to impress upon him the criticality of moving into a risk quantification mindset. And super nice, polite gentleman kind of gave me that polite smile.

46:08And then I said, "What do you think of as your biggest risk?" Not a question I love to ask, but I was kind of at wit's end on how to drive the conversation forward. And he said, "It's people." He's like, "The single point of failure challenge that I have with the people," or to your, Harshit, from your architecture perspective, to that people layer, right?

46:28So you're saying, Ed, take that person offline, right? And then see what happens. I'm just thinking about how here is the CIO, right, of this large organization, right? And that's his single biggest challenge, so. And I'm not, for the record, not advocating taking somebody else officially offline. I'm just- - ... make sure they can't answer questions, right?

46:48Invite them to the room, to the meeting, but don't let them talk. Yeah. Be it the CIO, or be it the system admin, or be it the CEO. Make them watch the process that occurs when they're not available to answer questions. You'll figure out who your single points of failure are real, real quick. Yeah. Network ports to be opened for communication, then your network ports are just not there. Now what are you going to do?

47:11So from a Q&A perspective, one of the things that I was excited to just kind of raise, because people, I think, could look at it and be like, "Well, these two people don't see things the same way." And I'm going to argue that you actually do see things the same way, but from a different lens, right? And what I'm talking about is the conversation that I had with Ayub Fandi yesterday, right, who comes to us from this GRC engineering mindset, right? Which is, in his world, right, there's thing, the policies of code concept is really important, right? That GRC folks need to be more technical in order so that they can be more effective in their role, right? He does Python scripting. I'm not sure that

47:53that's something that I would actually say has to be a requirement for GRC analysts, but I get his point of view, right? Which is, look, we have limited resources in the GRC space, and so the more that we can do to gather the data, going back to your data layer, Harshit, right, to gather that data in a more frequent and meaningful manner is a positive thing.

48:15On the other hand, we have the world of architecture, right, where we're trying to create structure so that we can make sure that the way that we build things will support the business objectives that we talked about earlier. So Harshit, give me your mindset as this very wonderful GRC architect, how you look at that whole GRC engineering movement.

48:32So technology is as good as the data which is being fed into the technology. It will function depending upon the quality of data, right? And as we have been talking again and again, that we collect a lot of data. We collect a lot of indicators. If those indicators are not meaning, they don't- ... join together to give you that meaning, then probably it's the GRC engineering or the technology part is not being very fruitful, right?

49:14I think having tons of risk acceptance, nothing happening on that, that sits in your GRC ecosystem, that sits in your technology, but don't look at it. If you're having thousands and thousands of vulnerabilities still waiting to be addressed is a common scenario, which is seen across. Apart from that, your risk attestations, whether someone is actually looking at it, I mean, it can be as simple as the service which I'm taking from my vendor, was that part of the SOC attest, SOC report? There are times when people don't even see that, right? Sure.

50:01It happens. So what I'm trying to get at is we need to understand and see what is the quality of data. Policy as a code is great. I am leveraging OpenAI and other LLMs to build automations, et cetera, but the point is, are we feeding in the right data? If we have the right data, then engineering does magic, right? It will give you everything very fast, very optimized with a limited resource requirement, et cetera. But if the business mandate is not being taken care of, if we have not taken care of regulatory aspects or various other things, if directionally it's not accurate and the data is not being built appropriately, then yes, GRC engineering is helpful, but

50:57it goes hand in hand. Sure. One cannot give you the outcome or the results you're looking for without each other, right? And of course, needless to say, if somebody writes a wrong Python script and your KPI is not being calculated appropriately, then that's also a problem, right? That's also an issue. So, Ed, what do you say? I think what he's getting to about the technical nature of it, not Harshit, the gentleman from yesterday, is it's really almost a, I hate to say it, but a cry for help, right? It's a recognition of the fact that he is not getting the tooling support that he needs to do his job. And so he's having to basically create his own. He's rolling his own GRC platform.

51:46I'm not a huge fan of that. I get the impulse. I think there's plenty of open source solutions out there. And I don't think you need a massive platform to do GRC. I think you need an understanding of what are the requirements you meet from a compliance standpoint, how are you managing your pro standpoint, and then how are you thinking about risk?

52:09Yeah. Right? And it could be as simple as a spreadsheet. Got it. But as you grow up and you get more involved in the, or the organization grows up, I should say, then it will change over time to meet the needs. But I don't think you have to start out with something massive. I think you need to pick a spot, put a line in the sand and say, "This is where I'm going to start from," and then build out from there. Have a sense, have a vision of where you want to go.

52:37Things like Harshit's reference architecture are a great way to get started. But I think at the end of the day, you just need to start. You just need to do it. And one more thing I would like to add is- Please ... the tooling, the engineering, the immediate functionality is great, but you need to see the sustainability of it, right? If it does not work the way it works today after two years, probably it was not the best use of time and resources.

53:11Look at that. Cool. Look at that. So to wrap up, I'll ask for a couple comments here, but I wanted to share something with everyone that Harshit and I worked on, which was taking the concept of a GRC reference architecture and putting it into a knowledge graph. And as you can see over here, we've got the who, what, where, when, and why that you so wonderfully talked about. We've got the layers identified. And so, Harshit, the reason that I like this work that we did together, right, is it helps to take and provide kind of a little bit more different, more interesting visualization, right, of your architecture work. And I'm just going to tease that like that and then come back and say,

53:55for anybody that's interested in knowledge graphs and how it pertains to GRC architecture, please feel free to reach out to Harshit directly, and he can share that with you. We'll publish it ultimately in the ERQI Institute. But in the short term, if you're interested in that visualization and learning more about that work, I'll point you directly to Harshit. And with that, I will move to wrap-up time. So, Ed, I'm going to make you go first. Fair.

54:23Blind us with your brilliance on the necessity of GRC as it relates to risk quantification or vice versa. - Dazzle you- Or both ... dazzle you with my BS, right? As the saying goes. I think there's a direct line linkage between GRC as a function and enterprise security architecture. The enterprise security architecture is designed to help answer the question of why. Not do you need this control, not where does this control live? It's why do you think you need this control? What business purpose does it serve at the end of the day?

55:01I think there's a direct linkage between that and the question involved with GRC, which is, what risks do we have? Well, if you can answer the risks, then you get to the why. You get to the business why. So that's where I think they relate. Cool. Harshit, you get the final word, my friend. Yeah. So, in my opinion, GRC basically is the reflection of what are we doing to secure the organization. And GRC reference architecture is a structured way of thought process, how to organize that effort to get the maximum productive outcome and the realistic view. So I think that's my view. Awesome. Well, thank you, gentlemen, very much for spending some of your

55:53precious cycles with us today. Harshit, thank you for all the work that you put on the architecture. And just as a note, we'll be publishing that document and presentation, or some combination thereof, here shortly on the ERQI website. So, please be aware of that. And Ed Covert, always a pleasure to see you, my friend, and thank you for your input. So- It's been fun. I appreciate it. Thank you.

56:19All right, gentlemen. Take care and have a great day. You too. Thank you. Thank you. Bye.

0:06All righty. So, we are welcoming to our next session. Yes, Mr. White. Hi. I am working to get Bob in here for you. There he is. Okay. All right. Have at it, my friend. Excellent, excellent, excellent, everyone. Let's see here. Nope. Let's see. Mr. Maley. Good afternoon. How are you, sir? I'm excellent. How about yourself? I am excellent. And Julien, are you with us, my friend? I'm with you and happy to be here with you.

0:43Excellent, excellent. Well, I have to tell you two, this is a session that I have been very excited about. It will come to as no surprise to either of you that the intersection of third-party risk management and risk quantification is a very near and dear place to my heart. And so, having you two represent organizations that are at the tip of the spear, I would argue, in terms of doing that work is very exciting for me.

1:21And so, I put together some questions for us, but before we move on to that, introductions are in order. And so, let's see. We'll go with first letter of first name. So Bob Maley, you get to go first. Always. I love how you put TPRM at the end of the day. It's always the bastard stepchild. - But, that's all good. I'm the CSO for Black Kite.

1:48I've been in the business a long time. Prior to this, I built a global third-party risk management program for PayPal. I was the first CISO for the Commonwealth of Pennsylvania, and if I go back far enough, when I was three years old, I became a law enforcement officer. So... - I know that fancy golden badge that sticks right on the T-shirt that you speak of. Oh, yeah. Yeah.

2:16Julien. Yes, thank you. So happy to be here with you. So late, early evening for me because I'm based in Paris, France. And basically, I run the sales organization and the customer success team at Citadel from France again. And I've been doing cyber, I mean, all my career. I started as an engineer, and then I moved on various topics.

2:48And I entered that risk quantification space like five years ago. So I won't tell myself I'm an expert in a... I don't have 15 years of quantification behind me, but I really dug the topic, and for the last five years, it was a hell of a ride. Well, I love these kind of sessions we have where we have kind of global representation, right? Because one of the things that I've learned since working as part of the group to get this off the ground, right, was the nuances and the kind of interesting kind of perspectives that people have, say, from the US versus the EU or France in particular, Julien. So, thanks for joining us, because I think just in and of that, there's significant value.

3:32So I'm going to start off, Bob, because when I first met you several years ago, you were handing me a book on something that I was like, "This sounds like it's straight out of Star Wars," but it was called OODA, O-O-D-A. Yeah, if I'm not on a panel or a webinar and I don't talk about OODA, it's an AI avatar. It's not me. - Well, as a champion, however, I would suggest that you are, maybe you can just talk about how you apply that type of thinking into this intersection. I mean, just here to begin with, right, just define it, but like, how does that then play into how you look at this intersection of these two critical areas?

4:15Well, first, to simplify it, everybody thinks OODA is a loop because it's called OODA loop. - So, go figure. But it's not. It's actually a strategic decisioning process. And the four things are observe, orient, decide, and act. And it's the execution of that process. And this whole world of third-party risk management, I think, and CRQ specifically, is in the orientation phase. So, the observations or the collection of the data, all the things we do during the assessment process, the continuous monitoring and all that, and then the orientation phase is the key. And I have a presentation on that I do all the time, and what happens in the orientation phase? Everybody thinks, "Okay, you observe, you

5:06orient, you make a decision." Well, no. Because that orientation phase, you might say, "Well, we don't have the right information. We don't have enough information." You go back, you observe, you collect more. I've built an entire CRQ model in Claude that's based on it. Works very well. Wow, I didn't know about the Claude thing. That's pretty cool. I feel like I got a hot breaking story on that one, Bob.

5:36Well, I've got a white paper to work on with you. Okay. Because it's based on the GitHub files that Jack Jones has made public. Oh. The FAIR-CAM GitHub files. And- Cool ... first tried it out, ChatGPT, and it worked okay. Moved it to Gemini, eh. When I tried it in Claude, it just was the sweet spot with the ability to do research and analysis, to put guardrails in, to add libraries of information. I mean, Claude is where it landed. I've been building it for about nine months for first-party CRQ as the CISO.

6:17So I'm ready to actually, I've got a draft white paper I want to put together with you and on how anybody can implement it, because you don't have to go to a vendor to buy it. It's the best thing. No vendor involved. - Well, as we have a panel of vendors, I'm going to acknowledge your comment. - Well, I'm a vendor too.

6:38I know. I said it's a panel of vendors, I said. All right, now take the OODA not loop and talk about how the relevance of that as it pertains to determining whether, and I should put this out there, whether we should intersect third-party risk management and cyber risk quantification. Well, we absolutely should. I mean, you look at the history of TPRM. So, I got third party as a profession when I went to PayPal. That was 14 or 15 years ago.

7:10And I retired from PayPal hoping never to have to do any of this again. And I got sucked back into a startup because of my TPRM expertise and my confidence that using something like FAIR in TPRM would elevate the art, elevate the programs. And because, yeah, and again, I'm disclosing, I sit on Shared Assessments Risk Committee- Oh, boy ... on their advisory board.

7:44And I do sell T-shirts that say, "Kill the questionnaire." And Andrew Moyad, the CEO there, he knows about it. Actually, he's my co-sponsor of the website. But yeah, TPRM is broken, and I think CRQ is one of the ways it can be fixed. Julien, you've been sitting there drinking in all of this lovely commentary. And whether you want to talk about it strictly from a Julien perspective and/or from a C2 Lead-wide perspective- Mm-hmm ... I was personally thrilled to see when the third-party risk management component, I'm not necessarily saying you released that part, maybe it was Andrew became aware of it, but to see you integrate those pieces. What's the thinking behind

8:30that from where you sit? - From where we start, I mean, cyber risk quantification on first party, you can't ignore third party. I mean, it's in everybody's mind. And at the end of the day, when you look at third-party risk management as a way to get access to you as a corporate, it's part of your risk. You need to understand how you are exposed through your supply chain. So you cannot ignore them anymore. And the way we looked at third-party risk management when we start just digging into it was, indeed, I agree with Bob, it was broken. It was a bunch of awful questionnaires. And now all filled by AI, or copy-paste from last year, or, I mean, it does not make sense. And you cannot

9:19make a decision on this. And we believe indeed that cyber risk quantification will create a language that business owners will understand. Because at the end of the day, the guy who needs to make a decision about a third party is the guy who owns the process which rely on the supplier. It's not the CISO. The CISO can assess, I mean, threshold and numbers and stuff like that. But at the end of the day, the guy who need to make a decision, should I keep this vendor in my portfolio or not, is the business owner. And the business owner will never understand cyber. They will understand money. Mm-hmm. Right? So we believe cyber risk quantification applied to third party will serve the CISO

10:01because it's part of their risk capacity, but will serve also the procurement and all the business owners that use the suppliers. Yeah, I love that you point out that financial element, right? And one of the tenets here at the institute, right, is making sure the outcomes of the analysis work that we do, where appropriate, right, is put into some type of financial form.

10:24Because, as we all know, that makes the world go round. I'm going to go, there's just a lot of ways to talk about this kind of interesting challenge. So I'm going to go back to, for a second, right, to kind of a problem statement for you both to comment on, right? So, Julien, as you just pointed out, right, when we do first-party risk, and Bob, you alluded to this as well, but we do first-party risk and we develop a risk scenario, right? And we're saying this is the asset or service or product that could be impacted by it, or revenue stream for that matter, if we're thinking from a more enterprise risk standpoint.

11:02You know what? The reality of it is the delivery of that product or service, right, or revenue stream definitely is reliant on some third parties who are part of your IT infrastructure, right? Or your operations infrastructure, or your human infrastructure in the case of people that are outsourcing business functions to third parties, right? So there's this natural kind of dilemma where we're talking about first-party risk, but the traditional approaches don't tell you how to use and put those third parties and their risk into your formula. So, to me, that's always been a gap that really needs to be addressed. And again, kudos to both your organizations for trying to help solve this. But Bob, am I

11:44being nuts or marginally sane? And somebody said both can be true earlier, so you can't- Well, yeah, I heard that, and I wasn't going to disagree with them because I'm in that case as well. No, I learned a long time ago that... This goes back to my CISO days at the Commonwealth. And I didn't understand, I had no clue what CRQ was. I didn't know anything about that.

12:11But I did understand about consequences. And I had a request, this was an urgent request to approve a website to go online by Friday to register law enforcement officers for training. And okay, this came from the highest level. The commander of the organization that made it carries a gun. And it had to be done, had to go live. They weren't asking for anything. And I took a quick look at it, my team looked at it, and a couple things. One, they were using social security number for login. And two, they were using an encryption algorithm that didn't follow CJIS.

12:54And I go, "Oh, well, okay, I don't have to disapprove it or approve it. I just have to write a note to have somebody acknowledge that they were going to violate a federal law and a regulation." And, "Ah, no problem. Give me a signed paper and you guys are good to go." And consequences. And they go, "Oh," and they did the right thing and built it correctly. So, that was a long time ago. And when I found FAIR, bingo. Consequences, business consequences, impact. Because business is all about the bottom line. Sure.

13:32That's what it is. And so, yeah, you're not nuts. And in third-party risk management, it's never been about that. It's been spend. The riskiest third parties are how much do we spend? It's never what's the real impact to the business. And so, for me, finding that Green Book, a sea change in how I started looking at things, and it just connected the dots to those things that I found from those impacts. Julien?

14:04So, fully agree with you, Bob. I mean, one of the key is to understand the, not the spending you have with the third party, but the business process that is related to this supplier and the associated losses, the impact for you as a company. Yeah. We see in some cases that you would like to focus on the resiliency of your suppliers. You don't care whether it will lateralize to you and you will suffer losses, but you want to focus on what's going to be the cost for them if they get breached for who they are.

14:39Because you have some kind of business process that relies on their existence, not on the fact that they are connected to you. So that's also a case that is very interesting to model. I mean, what is their threat landscape? What is their potential risk rating, which for who they are? And then you can also get some very interesting calculation and insight when you look at what is my threat landscape if those guys try to target my supplier- Right ... and then try to get back to me. So there are several scenario that could be evaluated. And at the end of the day, quantification, again, is a common language so that everybody can understand the impact. But again, that's

15:25what put you in a position to make a... Not you, but put you, the business, in a position to make a decision. And again- Yeah ... you need to set up the scene, set the framework of decision before, so that after the quantification, you ask for a sign-off. And that's the way it works. Yeah, there's a lot of facets to this, and I'm going to just drill down on something you said there, Julien, because I think it's really critical as we explore this topic further to put this out there, right? Which is, when you look at the risk that you as a first party, right, can be impacted of with respect to your third party, right?

16:04And we're talking about risk quantification, for me, it always leads back to the risk scenario, right? Yeah. How am I defining what the risk scenario is and how this business partner, right, or third party, or more supply chain provider, depending on your terminology, right? What are the impacts that can occur? One is if they have their own type of incident or event, then how would that impact me?

16:29Another is, to your point that you're both making, right, how does their existing risk posture, if I would, right, impact my first-party risk scenario? So, how you write the risk scenario is important and significant to kind of the outcome that you ultimately get. And then, Julien, to your point, right, ultimately, how we can inform our business partners, right, internally, right, in a significant manner. Mr. Maley, can you comment on the risk scenario front since you've been working heavily on this topic?

17:03If you wouldn't mind, your perspective on how we write risk scenarios or think about risk scenarios to make sure that we're considering all the facets of this interesting dynamic. Well, I think the limitation to the risk scenarios is the human mind. And it is what it is. So, what brought me to the company I'm in right now is actually FAIR. I got pulled out of retirement to do a consulting gig about for an investment in a company. And I said, "Oh man, what they're doing is really great, but it's no different than everybody else.

17:43But crap, man, there's a really ton of really good data. If you can figure out a way to take all that data and automate a couple scenarios for FAIR, that might be a cool thing." And it got done, but the challenge was scenarios. Because you're automating things like that, the scenarios are rigid. Data breach scenario, the first one. Really valuable at the time. This was 2019. We introduced it at FAIRCon.

18:12Really valuable, and there's been others since then, but they're still, they're static. And Jack, this goes back to Jack. Jack says FAIR is like the temperature. FAIR-CAM is like the blood workup. And valuable, but in a limited way. And today, I think that temperature, okay, it has appropriate use in- ... third-party risk management.

18:41I built my entire TPRM program using FAIR as essentially a triage tool, because you had too many vendors. And for me, impact is the triage tool, financial impact. But scenarios are changing. So having the ability to do scenarios on the fly for me really started earlier this year. AI. AI changed everything. Not from just using it, but from the scenarios.

19:16Yeah, it's like, okay, so yeah, we want to make everybody as productive as we can, so everybody can use AI. And everybody wants to connect their AI to everybody else's without any approvals and without any assessments. And I looked at that and it's like, how am I going to manage that? I don't have a huge team. How do you do that?

19:45Well, I think the standard way is, okay, check mark. We did an assessment of the company and we'll cross our fingers. I just saw a commercial about, what was it, Voya, planning your retirement. Come on, good retirement. Come on, no breach. And that's what prompted me to really look at FAIR-CAM and using Claude to be able to go in and help AI draft scenarios that I never had an inkling about.

20:21So yeah, the ability to do multiple scenarios, one of the most valuable things I found. Excellent. Julien, let me reframe the question just a little bit for you, sir. So, if we look at a first-party risk scenario, right? And we're saying, well, just for the purposes of conversation, let's say it's... because I've been using ransomware all day because it's stuck in my head. But so we have an asset, in this case, we'll call it the financial system, right, for an organization, right?

20:53Undergoes a ransomware attack from, let's just use our good friends at Clop as an example, right? And so they've come in and they have messed with our operations, right? They've encrypted our financial systems, right? And so, that puts us in a bad place from a potential revenue impact and compliance, regulatory, et cetera, right?

21:15So that's the risk scenario. Now, lo and behold, hey, that financial system actually is a SaaS application that lives in a third-party environment, right? How do we think about risk scenarios in kind of this day and age of interconnectedness, right, in a way that we have some information from them, right, be applied into our first-party risk in a meaningful way? No small challenge, clearly. Yeah. That's a big topic, but there is a way to see that. I mean, the way we do it is that we consider those third parties as assets that could be an entry point for an attack that we propagate internally and then trigger losses for you. Oh, okay. So when we simulate

22:04the threat actors' capabilities with a FAIR-CAM-like algorithm and we evaluate the potential susceptibility of having a breach- Mm-hmm ... we can start with a third party with the security posture they have, and you get it with questionnaires or with ratings or with whatever you have, whatever data you have. And then you see if it will succeed, and then you will see how it could propagate to your system. So in that case, the third parties, you can have multiple, are considered as entry points in the propagation that will lead to potential losses the deeper it gets into the IT system.

22:45The other way of seeing it for first-party risk is dependency and aggregation, but I think we will talk about it a bit later. Accumulation, I mean, concentration, all that kind of stuff, which is, I mean, heavily complex, but for mathematicians and for CRQ plans. I mean, applying FAIR on the portfolio of vendors is just great into the dependency. So that's another way of seeing it for first-party risk.

23:14Excellent. Yeah, we're going to put risk concentration aside for a minute because we're going to spend some time on that one. So Bob, now that I've given a specific risk scenario, is there anything else you'd like to add on how to combine it? And I'll give you one other kind of data point to consider, right? One of the things that's a challenge, right, when we have third parties is getting the right... excuse me, getting what I would call less attestation data and/or less questionnaire data and more actual empirical data about the controls, right? I would offer that it's standard approach, right? The industry has been, I'm just going to scan your external perimeter, right? And I'm going to use

23:52that as the sole data point, right, to determine, make determinations about somebody's profile. Now, I just want to be clear, right? I think that approach was fine when it first started years and years ago, and it still has a place today. But now, given the interconnectedness of it, here's the dilemma for me, if I could, right?

24:13I'm okay with attaching my business to your business, but I'm not going to give you information about my controls so that you can evaluate my risk. Those two things just seem to me to be completely different at odds. So anyway, just threw a bunch of stuff at you, Bob. I know that you have the capability to absorb that, though, and respond in a meaningful manner. That's always their problem. So technically, I can go into your environment, I can collect the information I need to add to that external data to make a reasonable decision. So it's not that it's impossible, but it's- Impossible to get a CISO to let you in, and it's impossible to let their attorneys

24:56allow it. I mean, because it creates all kind of liability. So yes, we could do that. I always get a kick out of, "But I want inside data." And it's like, "Well, live with it. You ain't getting it." It's not going to happen in my lifetime. There's got to be some middle ground though, Bob, right? But there is. I feel like summary data or something, right? Not even summary data. Is a way to get towards that goal. So if I can analyze your information security policies and I can get how you modify them, what you do throughout the year, and the exceptions that are connected to it, that gives me better data. But that's hard to get, too. People don't want to give that stuff up. So there's a lot of data. Now, you said about

25:43the outside data. Well, those are really good data points, but it's like fair. That's the temperature. That's the grade. And I agree with you, when grades first got introduced, they were amazing because, well, we didn't have anything else. That's right. But they do have a very limited, very limited usage today. Onboarding, if I'm looking at five vendors and they're the same for everything, a temperature might help me differentiate between them. Sure.

26:16It's valuable there. But from an ongoing risk perspective, I don't find it very valuable at all. But when you take those external data points and you connect it with other data, and I watched something get built around ransomware. It's four years old now. It's an algorithm that predated FAIR-CAM, but works like FAIR-CAM on the interrelationship of controls.

26:44And what research showed was that bad actors, their operating procedures, they always go after the same group of controls. It's about 25 to 30 controls. And if you can have data about those controls and you can have a good algorithm behind it, you can almost predict where ransomware is going to get hit. Now, I've watched it over the last four years, and as data... So what my research team does is they take, "Okay, well, let's look at all the ransomware that happened in the last 12 months. Let's look at what that algorithm showed for them prior to the ransomware incident." And the data has proven over four years that if you can see that algorithm, that you can stop it ahead of time. So it's that,

27:37I heard resilience or whatever. I call it fragilence. This is all fragile, but we need left of bang. Let's stop it before it happens. And I put this is in the realm of cyber risk quantification because it is a quantifiable method to do this. It has four years of data to... Because one of the earlier speakers said about evaluating your model, and that's what gets done. That model gets evaluated by real-world data over a year.

28:11So there are ways to apply CRQ, not just with FAIR-CAM or FAIR or other ways, but in effective prevention. I would rather prevent it and be my vendor's friend than have to deal with it after the fact. Because when it's right of bang, it's everybody's nightmare. So Julien, same question to you, and let me just kind of narrow it down if I could.

28:35Because I think I asked four questions in one, Bob, so thank you for doing a great job of responding to all those, sir. But Julien, if we're talking about this notion of how do we improve telemetry, right, from third parties so that we can look at our own risks, right? What are your thoughts on what's the path forward there? And maybe it's stuff that you're working on already, but- Yeah ... curious on both fronts.

29:00That's something that is to say it might be a bit different in Europe than in the US- Please ... based on what I'm listening now. We have now some project with large and many banks, thanks to the regulation, which is DORA. And we can now collect internal security policies from vendors, pen test results, internal BIA documents.

29:27We inject all those in an LLM AI to pre-fill questionnaires with much more questions. And then to use it to evaluate both the, indeed, the outside risk scan, but also the inside security, and run share with much more data of what's happening inside. So I know it's not that common because usually you can have indeed a screenshot of the footprint from the external and the scan or whatever.

29:55But we start to see some banks mainly that can request their vendors, the critical ones, to share with them internal security documents. We don't store them, but we parse those documents to extract the data we need to apply. We don't use FAIR-CAM. We have a preexisting also model that is simulating attack and defense. But to feed the model to make sure that we can extrapolate the right susceptibility of an image. So that's something that is...

30:25The scan is indeed one of the input. Mm-hmm. And that we know that we get much more precise once we get internal data. And I agree with you, Bob, it's very hard for a CISO to say, "Guys, let's come in and scan my network." No, that won't happen. Only if you have a regulation and if you are a critical supplier and stuff like this.

30:45Well, I knew about DORA, but I love it even more now, Julien. Yeah. The Dora shield, as you would, right? I mean, the regulation allows us to ask for this information, right? So, thank you very much. That was a wonderful insight. I appreciate that. Both of you have mentioned or alluded to this, so just changing topics for a minute.

31:12We'll go back to risk scenario creation, right? I suspect that both of you would agree with the following, right? Which is, it's important to use threat intel, right? And again, this could be true of anything outside of cyber. We're talking more cyber-specific at the moment. But using threat intel to understand actually how the threat or threat actor in our parlance, right, is going to potentially come at us so that we can be more effective, right, in defining and evaluating the controls that are most important, et cetera, et cetera. So is that a belief that you both share, that we need to continue to go down that path? Bob, I'll start with you.

31:52Yeah. The threat intel, I think, is the key change for this. So I think everybody should have access to the highest caliber threat intel they can get. And I don't want to recommend anybody, because there are their numbers. Google's pretty good. - Didn't recommend them. So we don't use them. Okay. I have a luxury that most CISOs don't have. I've got a research and threat intel team of my own that creates that threat intel data that's so valuable. But we're not the only ones.

32:32I mean, there's a lot of places to get it. Unless you have a team like that, I highly recommend finding somebody like Google or whoever, and get that threat intel embedded into your process. Because if you go, "Well, we have our own threat intel." I know I just said that, but how good is it? Have you actually compared it to somebody like Google?

32:59And try it, do it. And be honest with yourself, because good threat intel is the heart and soul in a proactive third-party risk management program, I think. Julien, I think Citalid may have something going on with threat intel. I don't know, man. Fill me in. Oh, the two founder of the company were two threat intel analysts.

33:24They created- Ah. Yeah. Okay, that's what it was. So they... I will... I mean, the thing is, cyber risk is a risk where there is an adversary. So if you don't know the adversary, you are missing half of the equation. Exactly. Yep. That's so much basic. I mean, if you don't know who may target your company and how they operate and how they are sending and how they have relationship with nation state and how they are relationship with the current geopolitical conflicts and whatsoever, how can you predict anything?

33:56When we started the company back in 2017, there was no threat intel on the market that were usable to feed a cyber risk quantification algorithm. Because getting signal is one thing. Getting signal that you can translate into numbers to feed statistical probabilities, that's another game. So we started the company by building our own threat intel team that is designed only to serve quantification.

34:24Okay, so that- Like I said, you have to find somebody that's good. - Somebody with experience that does it. Don't build your own. - So as a vendor, we did, but indeed, it makes a big difference. In the FAIR model, one of the main disadvantage we see when we talk with customers who tried it is that if you don't have the threat event frequency and the susceptibility that is feed by something that you can trust- Yeah ... how can you defend a number in front of your board? I mean, it changes so much the number at the end of the outcome of the model.

35:03It's so critical. So definitely, yeah- Life is good though, because you read your threat intel and you see that one threat actor is attacking another and... Yeah, it's good stuff. - So let me ask you as threat intel folk, right? For those folks that do not have the funding, right, to have their own threat intel team, is it reasonable and/or a good idea to look at what's happening within your industry and sector in terms of the types of attacks maybe that are publicly acknowledged, right? Or, for example, I can share with you, right, like I've certainly used Claude or ChatGPT to ask for top threat actors in a sector, and it comes back with responses, right, confidently, as AI always does. The accuracy of those

35:53results will vary, as we all know. But for those that don't have their own capability, right, what's your best guidance, right, in terms of being able to grab that information and from where to help them with their efforts? Can't afford a threat intel service. Just want to make sure that I've made that perfectly clear. So go out and subscribe to something called Focus Friday.

36:21Our threat intel publishes a significant amount of free intel on a lot of these things. I love our founders. They built a company based on giving back to the community, and they've done it since the beginning. It's one of the things that got me here, and that's one of the things they do. You don't even have to give an email address.

36:43You can just read it online or you can subscribe to it. I can tell you those subscriptions, they don't go into the CMO marketing. And it's separate, just like all the research that we publish, uh, you just download it. Uh, uh, we were, you know, we were able to convince our marketing folks that, no, don't put a paywall. Don't put a gate. Don't take anybody's email address because this is... the community needs this. So that's one resource. There's a lot of other good resources, um, you know, that, that, uh, CISA, I think, has a, a, a great subscription that you can go to. But again, those things take time and, and ingesting them, uh, you know. But if it's

37:23you're looking for free, th- those are some, some good ones. Julien, any thoughts? And we also publish some reports, so, uh, yeah, happy to share it with, um, every- everybody who wants it. I, I would say that you, you should also take a look at the, um, the, all the reports that are, um, produced by the insurance industry. Um, we, we have a, a dedicated practice for, for the insurers. Uh, we work quite closely with them, and they... the claims reports are quite interesting.

37:54It's, again, claims, it's after the breach, so you are looking in the mirror to try to guess what's gonna happen, so it's not perfect. But it give you some good intel on what is exactly the activity you see, the, the, the real claims, the, the real, uh, breaches that happen. Because when you look at threat intel, it may be a bit, um, overwhelming with, uh, uh, something that is threatening you. And, and so claims data is, is interesting in the, in the, in the, the fact that it's, it's real breaches, real costs, real losses for real customers, not only trends and, uh, and, uh, and fear and stuff like this. So I would, I would take a look at, at claims

38:34report. Yeah, but before you use any of that stuff, run it through Tony Martinoveg's, uh, nutritional label process. No, seriously. Um, I actually, uh, have baked that into my FAIR-CAM module in Claude, that everything that we consume, uh, goes through that first, 'cause that's- So Tony is coming up here shortly. So Tony, you may wanna have a licensing discussion with Bob, but that's none of my business. All right.

38:58Yeah, there's- Moving along. Yeah. It's, it's public. It, it's not in the platform as such. Bob is just joking, man. It's in the CISO's work, but I find it that valuable. - I, I, I, I hear you. Um, and you know my penchant for trying to be the class clown or comedian just never really ends, and end up getting coming to terms at the end of today, I feel like that part of me is... I'm trying to have champ it down ineffectively. So thanks for putting up with me, Bob. - No problem. Um, all right. Let's go to the concentration risk discussion, um, and to give this discussion, um, some direction, because there's a lot of el- there's a lot of facets to this as

39:38well, as we're talking about looking at third-party risk as it per- pertains to my first-party risk and risk scenarios. So there's lots of elements to this. So I'm gonna start out, um, by being, um... How should I say this? Um, a supporter but a cynic, right? So, um, and I'm just gonna give you a, a for instance, right, for which you debase question. Uh, about a year ago, I was presenting on third-party risk, um, for a group of financial service providers, um, and I asked them, um, "Hey, of, of your top providers, um, how many of these have you discussed internally, um, with whoever owns that re- business relationship, right, or the people involved with that, right? How many of you talked to those people about

40:27what type of financial impact would need to be surpassed in order for us to move to an alternative provider?" And there were 36 people in the room, and one hand went up, um, which I was surprised by, um, and not at the same time. Um, and so then I went on to ask, "Hey, um, how about, um, for your top 10 providers, however you determine them, right? Like, how many of those, um, have you, um, looked at and have backup? You already have an alternative provider identified, and you know the time and effort to move over to them."

41:07And the response was just about the same, right? Very limited. So, so that's the framing for my kind of, um, questions about how do you look at concentration risk? How do you talk about it both internally, right, and with clients and, and why it's so critical or not as critical maybe as people advertise? Uh, Julien, you wanna go first since I've been letting Bob go first all the time? I don't wanna be like that guy, so... - Um, when you, you want to identify concentration that, that way, definitely it's part of the scenario and how the scenario, uh, gets connected to the business value, uh, they are serving.

41:48Um, and, and that, to me, that cannot be automated. I mean, it has to be a discussion with the, the people who knows, uh, how the process is organized and, and is this vendor that critical. One proxy some customers use is i- indeed the spendings they have with some vendors. Yeah. Um, and it leads you to situation where the guy who is, uh, providing you with the coffee machine is more critical than the guy who is providing you with the, uh, uh, I don't know, the very critical invoicing system that is not that expensive, but if it breaks, you, you don't, don't get money.

42:23So that's, that's something you need to discuss with them. I don't believe it can be automated. Um, again, with the regulation, some regulations, it's mandatory to identify the business process that the supplier are serving, not only the spendings. And it helps a lot when you want to create a scenario and say, "Okay, that's, that's gonna be the real impact of this supplier getting breached." Um... Oh, Mr. Maley.

42:50Yes. That, that type of concentration risk, I don't have to deal with much. We're a small company. Um, but I- - How about on behalf of your... speaking on behalf of your customers, then? Well, it goes beyond your vendors, I think. To me, it's your vendor's vendors where the problems could be. I think we found that out, was it earlier this year that an AWS DNS configuration failed?

43:22I found out about it because my CEO couldn't get a bank code from his bank because guess what? The bank was the victim. And how do you actually understand your... I just saw it pop up in chat, your supply chain. And if you're just focused on your immediate concentration, your particular vendors, that's important, obviously.

43:45That's part of enterprise risk. But it's broader than that. It's knowing, well, if for some reason Claude decides to shut itself down, I can see how that affects me internally from where we're using Claude. But do I really know how that would affect all my vendors? Right, right. And I guess you call that cascading versus concentration.

44:17So that to me is something that would keep me up more at night. And actually, I know Julien was talking about the collection of all those artifacts. I'm doing the same thing, but I have a new thing I'm working on in my FAIR-CAM module in Claude that, can I realistically take all that kind of data that I have access to about a vendor, and can I then put it into Claude and have a scenario around what if there is an AI failure at a critical vendor of mine? So, again, that's brand new. I ran one scenario.

45:07I have a slide that shows what the results were. The results were extremely promising. So, you're going to be exploring that, because all the data that I use for it, I have automated access to. It's something that I can build an automated process in my little instance of Claude. So, yeah, there's so many connect. The supply chain is so interconnected that, how did it used to be?

45:40Well, put it in your contract with your vendors that they have to inform you of what their third parties that touch your data. Okay, data providence. But it's bigger than just data now. It's business interruption, and it's a business interruption in a large way in that extended network in the supply chain. Julien? If I may add on this something.

46:07There is another way of saying this, which is called accumulation. It's not risk concentration, it's not aggregation, it's called accumulation. That's what the reinsurance is doing, and it start with catastrophic scenario building, like earthquake, tsunami. I mean, how the risk is concentrate when you have a black swan event, something that happens one every 200 years, but that is breaking everything.

46:30And they are all afraid of the cataclysmic events in cyber. There's a lot of movie on that and a lot of fear. And it's an area of mathematics and statistic that is very, very coded and very specific. We did some project on that to apply FAIR at the scale of a country, at the scale of a portfolio, at the scale of a vertical, to be able to extrapolate the tail distribution of the risks.

46:59Really, the catastrophic scenario, the dependencies between all the actors. You need to take proxies. You cannot have all the data you need, and you will never get everything because it's third party, fourth party, cloud providers. Then it goes also to investigation team, CERT. I mean, if you get a massive event in a country, all the CSIRT will be working on the case, and you will... On some simulation we did, you don't have enough experts in the country to serve everything.

47:34I love this notion- So you should see- Sorry, go ahead, Julien. Forgive me. So it's a massive incident. You can have economic chain reaction. You can have propagation model which work like the plague, the virus. I mean, it's a full area of modeling that we are working on with the insurance industry. We don't see that right now in the enterprise.

48:01When we talk about accumulation within the enterprise, I believe it's a bit early. Start by just do triage on your third party and evaluate the critical ones. That can be the first step. But then that's something that will democratize over the next years, I guess. Love this notion of accumulation. It seems like it ends in T-I-O-N, so my brain should have connected aggregation, concentration with accumulation, because they all speak to the same realm in a certain extent, but from different perspectives. So that was very cool, Julien. Look forward to further- And to answer the question of- Yeah. Please, yes ... somebody about the port strike. Port

48:41strike is definitely an accumulation event. It's not a cyber event because there is no threat actor behind it, but it could have been. Right. And that's the kind of stuff we model because the insurers at the end of the day are the guy who are going to pay. So they want to know what a threat-led port strike may cost to them.

49:00Yeah. We've, um, and I'm not saying this to respond to either of you or anything that you've said, but I feel the need to do this at least once a day, and I forgot to earlier. But I do want to indicate to everybody that's participating and those that will watch these videos later on, the Open FAIR standard is something that a lot of the folks in the institute espouse to, but it is not the only approach, right? ERQI is a supporter of many approaches, the Open FAIR standard being one of them, and FAIR-CAM analytics certainly is something that we support. But anybody else's control analytics methodologies, right? Like, we are not selective to just FAIR. Sometimes I think

49:39based on here the conversation, it can be like, "Oh, these must be... this is a FAIR-only group," and that's just not the reality of who we are as a community. We support and promote all, everything that makes sense within the ERQI space. So, thank you for putting up with my commercial, gentlemen. So back to regularly scheduled programming. Okay, cool.

49:59Bob, was there something else you wanted to add on the tail of Julien's comments, or should I move on? Yeah, move on. Concentration, it's interesting, but it's not as fun as AI. Yeah, I hear you. I do want to make one final commentation, excuse me, comment about concentration risk. Wow, now I've really got the shuns on the mind.

50:22And the reason that I said I was a cynic about it was because what do you do? What can you actually do? So you've identified concentration risk. To your point, Bob, and this is a nice transition to the AI part of our discussion, are you going to demand that your vendor not use the same frontier model? Like, how is that going to work? And that's just not reasonable to assume that you can have that impact. So the question becomes, how do you use concentration risk, right, as a topic, right, effectively?

50:52Yeah. - Thanks, David, for the commentation. Appreciate that. So, having said that, let's move on to the AI portion of our discussion. Wait, mitigating control of sensitive bleeding, it is very hard to pronounce. CPAT, thanks for the comments, man, as well as Mr. Hitch, by the way. I do want to go back to one thing that CPAT, or Chris Pattison as he's known, made a comment about, because it's significant enough, I think, to mention, right? When we look at this notion of recovering, right, from an event, whatever it might be, whether it's cyber or operational, right, there is typically some work that's been done, depending on the size of the organization,

51:32right, around business impact analysis, right? Coming out of the kind of disaster recovery realm, if you will, or the business continuity realm, or the disaster recovery business continuity realm. You could probably shuffle those words around. But I think it's important to note, and I just maybe both of you can comment on how you see that information from a third party being useful or not, depending on how they respond to it, maybe. Bob, I'll start with you this time.

52:02So, when I occasionally get called in as a consult with one of our clients, and how to implement a program, and one of the first things I talk about is get their business impact analysis, because there's a lot of really good nuggets of data that'll be in there that can feed into FAIR, can feed into all your assessment.

52:27And sometimes I still get taken aback when they go, "What's a BIA?" Not a good sign, perhaps, in and of itself. Yeah, or procurement won't let me have that. So there's other problems. Mm-hmm. But yeah, I find if you can get them, I find it's a tremendous piece of information. Julien, thoughts? No, definitely the business impact analysis is key. Knowing your process to exactly be able to map which vendor is connected to which process, and then you can make decisions whether you will approve the risk via some cyber insurance. You can find sometimes some dedicated cyber insurance just to protect your revenue in case there is some kind of breach like this.

53:15But first of all, you need to identify exactly what it's going to be for you in terms of process and cost and losses and impact and direction and stuff like this. All right, I'm going to start the AI discussion with a specific question, and I'm sure that we're going to go down some paths given the seven or eight minutes we have left. But here is the question, right?

53:35Most organizations, especially those that are technology service providers, right, are using AI in some way, shape, or form today. If you, by any chance, had heard some of the discussion from our AI governance discussion yesterday, the primary recommendation was do an AI inventory, right? And I see that as a key concept for sure, no question asked.

53:59But the reality of it is that we're having to promote that as the most practical advice for the first step to take makes you wonder, when you're asking your third party, right, about risk, how much they actually even know. So there's an interesting challenge there. So the question, though, that was just framing, gentlemen. So the question is, what's the best way and the most important way to get information about AI usage from a third party? So that's a super easy question. Just kidding.

54:26Julien, and I'm afraid I'm going to have to ask you to start since I'm trying to bounce back and forth. So, what are your thoughts, sir? That's a tough one, because when you want to model AI, AI can be seen as something that will empower the threat actor. So this goes back to threat intel. That's another topic. Then AI can be a target of threat actors, and in that case, it exists. We can model the way AI would resist to some poisoning attacks or misuse. But to do that, you need to get data- ... from your customers or your suppliers, how do they protect their AI with MITRE ATT&CK, for instance?

55:11Sure. They don't have a clue. When you get to the corporate X, take away the Fortune 50, not the Fortune 500, but the Fortune 50, they may get some clues about how do they protect the AI, but the others, they just run after it. I mean, they use it and they don't know how to secure it. So as soon as you don't have any clue about how this AI stuff is secured, which controls do they have, it's going to be guesswork.

55:36Mm-hmm. It's going to be the worst case scenario, because you cannot take into the modeling the control that will mitigate the losses. So right now, I believe it's much guesswork. It's not very relevant, even if we all know that's something that may happen in the coming month, and hopefully, we will be able to get data that makes sense on the security level of AI that customers are using.

56:04But I think it's mandatory. Bob? Simple question should be a simple, straightforward answer. You have seven words. No clue. - No clue. As a CISO, my biggest challenge is in my own environment, to be able to understand, just get an AI inventory. Okay? I love when someone gives a compliance statement. Just all you need to do is get your AI inventory. Good luck.

56:40Unless you have certain tools in place, and there are tools that can assist with that. So that is a great place to start, having that AI inventory. But again, it's all those connectors. Claude's got a connector market that in my environment, guess what? It's not turned on. Somebody has to specifically ask for a connector, and it has to go through an assessment.

57:10And that's me. So if you ask me about AI governance, and if I'm your vendor, I have answers for you. We have an AI model card. We use a platform called Cranium AI that scans our AI repositories. That AI inventory, so to speak, in the platform, but then it's more than just the platform. It's everything that your company uses. So yes, it's hard enough doing it for yourself. Now we put that out on all the vendors, and the smaller the vendor, the harder it's going to be.

57:45Because how many of your vendors have turned on AI and never told you, other than a really cool marketing blurb? "Now with AI." It's like, what does that mean? But so we just go into... I assume that every single vendor has AI nowadays. I don't ask anymore, "Do you have AI?" I go, "What AI?" And don't send the NIST AI RMF framework questionnaire. Worst thing to do.

58:21There's a smaller set of questions you can ask to kind of start peeling back the onion. And there's a lot of practices in secure software development that go right over to, that merge with AI in companies. So, make sure you're including that in your analysis. But right now, I just don't have an answer. It is a very challenging thing to be able to solve.

58:46Yeah. I think it certainly is, and I'm going to put as a final thought on that, to be determined, or conversation to continue. So, I'm going to ask both of you to be willing participants in that discussion on behalf of the institute as we go forward, because I think it really is important. All right, final thoughts. Again, our topic today was the intersection of CRQ and third-party risk management. So I'm not going to frame this or give you any kind of narrowing. I'll just ask you for your final thought on, as a practitioner, what is some guidance you would give to a practitioner on thinking through this potential intersection? Bob, it's your turn to go first, my friend.

59:27Final thoughts. If you don't drink, start. - It's- I appreciate that and resemble that remark, Bob. Yeah. It's still, like you said, TBD. Just like I always say, tell your AI please and thank you, so when the AI overlords take over, they'll remember you and treat you well. But I don't really believe that, so go out and subscribe to my podcast, "Third Party."

59:56I'm the dumb one on it. There's two smart people with me. But we actually talked about, is AI bringing the end of the world? And no, it's not. Julien, final thought. Related to the CRQ and TPRM, I do believe it's going to be a game changer- Yeah ... as Bob mentioned, to do the triage for customers, and also then to understand the cost of a breach coming from a suppliers, because it's happening more and more. And executive boards, they cannot stand the CISO saying, "It's not me, it's my supplier. I didn't know it was that bad." They need to come with something that they understand, and quantification is going to make the difference, I guess.

1:00:45And I will leave the session with this final thought. I would suggest that one thing we start thinking about is, in right of a third party, how many of my top risk scenarios do they impact? Right? So if I have my top 10, is it one, two, seven, 10? How many of those, right? Because that's another kind of facet that we can use to help prioritize the importance of our vendors, depending on how many of the risk scenarios we impact.

1:01:10And with that, I will say thank you so very much. Julien, thanks for staying late, my friend. Wow. Extra bonus credit points for you, sir. Bob, thank you, my friend. Always a pleasure, and have a happy OODA day. As always. Thank you, guys. Over to you, Mr. White. Thanks, sir.

0:07Panelists, welcome. Hello, hello. Hi, everyone. The final session. I'm so looking forward to this. I know we've had a lot of forward references to the debate, and now we're at the debate. Every quantification practitioner has lost an argument to someone who just knows a risk is high, and every qualitative practitioner has watched a precise-looking number mislead a room. So, this debate puts both camps on stage to argue where each approach earns its place.

0:57I'm going to start by having the panelists introduce themselves. While they're doing that, I will post links to their LinkedIn pages. Please follow the panelists on LinkedIn, and check out Tony's book. There we go, Tony. I brought a prop. It hasn't been signed by you yet, but we'll make that happen at some point, I hope. And- Thank you, David. Appreciate that. Appreciate you buying it.

1:32Of course. Of course. What did you say, Tony? It's another chalupa? Yes, I can buy a chalupa if you buy - the book. - I know the feeling, having written a book myself. Yeah. Thank you. You can buy my book, or you can just give me a quarter. That would work just fine. So, panelists, by way of introduction, please share how you came to be doing this, why you're engaged with ERQI, and where quantification sits in your daily job function. We're not looking for a resume. Rapid fire sort of context, and I'll put LinkedIn. If people want to see your resume, they can look at your LinkedIn page.

2:20In Hollywood Squares from my screen, starting with Sriram. Good day, good day from Melbourne. How are we all doing today? Doing well. Thanks for having me on the panel, gentlemen. Pleasure to meet you, CPat, Tony, and David for hosting us. Adam, pleasure to meet you as well. So, my background's pretty much similar to a large part of how the ERQI came to be formed about. I have been in technology, cybersecurity for a very long time. I've been with the industry working on many aspects of defensive cybersecurity, but more importantly, I started looking at how do the works that we do typically influence the business risk? And the thing that kind of caught my attention the greatest was different people on the

3:05executives on the board have different appetites, and how they see that same risk can actually vary. Consequently, I needed to adapt how I articulate to these gentlemen and the people in the panel, which got me thinking about, what does really risk mean to these people and why do they perceive it differently? Which the dialogues and the conversations that happened apparently caught the attention of Mr. Andrew Shea, who very, very kindly invited me to be a part of this group, which I absolutely love, and extremely elite group that's a part of, and I'm learning so much from them every single day. And that's kind of how I got into this group. So, my focus is

3:45ERQI plays a very significant part and for me in my own decision-making, and I've actually made it a part of my own life. So, how do I use quantification to every decision that I make? How do I implicitly imbibe it into everything I do? That's kind of how I practice it. So, that's kind of going to be the driving force for my conversations in this panel today. Over to CPat.

4:07Thank you, Dr. Sriram. So, I got into this back in 2017. I was working with a large logistics provider that had the pleasure or the pain of having to deal with both WannaCry and NotPetya back to back. And when we returned to our budgeting sessions later that year, my friends in finance quickly said, "You got to get rid of these red, yellow, green charts.

4:30You lost 400 million dollars for the company, and we need to see this justified just like any other business case." So, that led me down the path of exploring some of the work that Jack Jones, Doug Hubbard, Rich Richard, and some of the other usual suspects in the space. But then I did leave that company shortly after and worked for a couple of... I left practitioner side, went back into more the vendor side, and actually working with a couple of the large providers of risk quantification tools. So, looking and focusing, the challenge was, how do you bring this into cultures and how do you actually get this started? And there were lots of failed implementations. So,

5:12as a field risk officer for those two organizations and those two vendors, continued to work with groups and refine the approach around this and bringing it into the different organizations. And then how I got into ERQI, similar. We started to realize that FAIR is a great method, but it's not the only method, and we needed to have a kind of a portfolio of different objectives. So, as Andrew brought ERQI to my attention kind of very early on, I might have been number four or five, I think, in the group, it was time to get something like this going. So, very happy to be involved in this and super excited. In my current day job, I am back at a large organization, so we do CDMO- ... pharmaceutical manufacturing

6:03and working on maturing the, you know, putting the m- my money, putting the money where my mouth is and actually following the, the practices that I espouse to, uh, different clients as, as I kind of traveled around with the vendors. Uh, and in the process of that, having to upgrade now with Mythos, uh, working on a new model, a trace model that, uh, hopefully should have published here soon for, uh, e- the ERQI team to, to review and discuss. So, super excited about this forum. You guys have done a great job the past two days.

6:31I'm looking forward to the debate. On to you, Mr. Tony. Thank you, Chris. Uh, really happy to be here. Um, I am very excited for this debate. When I saw the names that I would be debating, like, you know, all the, the co-panelists, I was thinking, "Okay, we gotta make this really interesting for the viewers," because I think I agree with every single one of you. Like, I know all of you very well. Um, but we'll, we'll do our best to make this a lively debate. Um, okay, so my name is Tony Martin-Vegue. I got started in risk quantification about 15 years ago when I worked at a bank, and I was... I worked alongside all the other risk analysts at the bank

7:12who reported on different lines of business. I worked with the liquidity risk person, foreign exchange risk, market risk, credit risk, all those folks. And guess how they reported risk? It was in numbers. And when they speak the language of business, they got what they wanted. And I spoke in high, medium, low, red, yellow, green, and I didn't get what I wanted. And that's when I discovered FAIR and Jack Jones and Doug Hubbard, and really the rest is history. Um, I-- And that's, you know, fast forward many years later, and that's exactly why I got involved in ERQI. Um, I love the community.

7:53I, I love the fact that it's vendor-neutral and model-neutral, that anybody from any background can come in and participate and, um, you know, just contribute and join the community. And probably most of all, I love the work products, just all the great research that ERQI is pumping out. It's, um, it's invaluable to my practice.

8:16And, uh, how I use risk quantification today, um, I'm very lucky that, um, I get to use it all day every day. Um, I used to work at Netflix where I built the quantitative risk practice out. I worked there for six years, and I left about, I guess it's about a year, about a year and a half now, uh, maybe a little bit less than a year and a half, and I do consulting. I have my own consulting firm where I do risk measurement and risk quantification and coaching and advisory and stuff like that.

8:45And just like, uh, just like Sriram, I try to, um, do risk quantification on my personal life too. I just did a risk assessment last week. Should I buy insurance for my water main? I have a water main out, out in front of my house. Should I buy insurance? And I did a risk quantification on that, um, a risk analysis, and it told me not to buy insurance.

9:09So I have, I have a data-driven, um, data-driven analysis. Um, I'm gonna hand it over to Adam. Yeah. Yeah, it's, uh... Thanks, Tony. It's great to be here and speaking with everybody. My name is Adam Lamantia. I'm at a company called Ostrich Cyber Risk. Uh, I actually used to be a consultant in a, at a healthcare research and best, best practice company, uh, when I was poached to join a little company called Risk Lens, who some folks may be familiar with. Uh, this was Jack Jones' organization. So I stepped into the risk quantification space working with Jack and our professional services team on training folk in risk quant best practices, um, how do we build out

9:56programs, how do we talk about this stuff. Um, and I will admit upfront, I'm a little bit biased towards the FAIR methodology 'cause I'm in that day in and day out, but I think that'll be good for the debate. And what really has always resonated with me when it comes to quantification is, you know, this idea of a best practice, right? If we're making decisions, um, not always, but a lot of the time that, that risk quantification perspective would be treated as a best practice in, in making better decisions. So, uh, I've been talking and working with Andrew for a number of years now.

10:31So when he spun up ERQI, I thought, "This is a no-brainer." Community's so important when it comes to quantification, right? I mean, the fact we're having a debate shows that there is not one true way or, or best way to do things. There are just practices that tend to be more effective. So here we are, uh, really excited to, to jump in here. And I guess day to day, um, at the organization, I work with organizations to train on this stuff, uh, implement programs and such.

10:59And I am working within a, a specific platform of Ostrich, so I do have that bias as well. Great. Thanks all of you for taking time to be here today. And, um, so let's, let's jump right in. And I'm, I'm eager for this to be a, a lively conversation. So, um, CPat, I'm gonna start with you. Are quantitative models always superior to qualitative assessments? W- why? Why not?

11:38So I'm a, I'm a big, uh, supporter, and I think it was in one of the talks yesterday, I, I threw this out, but it's this concept of there are many different models out there, so you need to use the, the right model or methodology for the right types of risks at the right time in your risk evaluation cycle. Uh, so this is where, unlike a lot of folks, I do not, you know, belabor the heat maps or even ordinal scales to a certain extent, right? If an organization...

12:08... has at least got to the maturity where they want to start putting some type of number on it. Most of us here can agree that that's not necessarily a mathematically sound number, but they're attempting to do it, right? So you can use this kind of very early on in your traditional risk management cycles where you're kind of trying to do an inventory or understanding to put broad lists out there, to have frontline team members do a simple one through five scoring. And what that's going to surface up for you are the things where you're probably going to have to apply a more rigorous model, but at least you're canvassing your entire operation, right?

12:45Now, I'm talking about very large operations. I'm used to dealing with companies of tens of thousands or 250,000 employees, lots of managers. The more insights I can get on that front line, and if getting them a very simple red, yellow, green type questionnaire with some ordinal scales helps me kind of focus where my radar sits is kind of where that fits, right? Qualitative models at the very early end of your risk for those risks that you're looking at in the very early phases of your annual risk management process, it's a great way to triage that stuff out. It's very simple. You don't have to have trained consultants. You don't have to do calibrated estimation, but you're going to

13:24get a landscape and understanding of what your enterprise at least starts to look like. Any counterpoints to that? I knew I would agree with Chris. Sorry, we're not totally Chris. I wouldn't necessarily say counter. But you get a lot of- Oh, I guess it's very- I think we have to be careful as the institute that I even see out online that like, "Oh, you've got it." And some of this was around yesterday, "Oh, it's a heat map." Heat map's just a visualization. That's like saying stack bar charts are bad, right? It's what you put on those axes. It's how you're measuring it.

14:03It's what you're actually trying to communicate. I think Laura got to this earlier. It's like, what are you actually trying to do here, right? And what is this model for, and where are you in the process? So that's where I don't disparage the qualitative models as much as some other people do, because at least, thank God they're doing something, right? How many organizations have we gone into, and there were discussions around that today, where like, they're doing nothing.

14:29So, if you can start them on a very simple heat map to get an understanding of just the basic layout of what you're dealing with, that's very easy, very good model to use. And yeah, it does have numbers. They're not great numbers, but it's better than absolutely nothing. Sriram? Yeah, so Jess, I guess I'm going to come at it at a slightly different angle. And my focus is for people who are really the consumers of risk management, what are we trying to deliver? We are trying to deliver a mechanism for them to help them make a decision that is more informed, that is more strategic, that is repeatable, that can be informed, and that is also something that stands scrutiny.

15:12So if you look at it from that angle, risk modeling kind of comes up with what is the level of uncertainty that I have to deal with? And we have to recognize, take cognizance of a certain thing here, which is ultimately it's the human mind that's going to make the decision. And human mind cannot deal with details when it has to make a quick decision.

15:36So you need abstraction that has to work with it, which is why when you look at the flight or fight response, it's not about how quick is the cheetah moving to come to me. Do I have to calculate the exact speed of 0.000 whatever miles per hour that it's running at me? It's like, is it coming to me or not? So it's a qualitative decision, because qualitative decision is essentially how the brain is wired.

16:00And that's why ultimately people land up going with qualitative because it's a more intuitive, it's actually literally built into our genetics as to how we decide. And there is a certain level of quantitative that is necessary, but that is more from a scientific rigor perspective, which can be built in. So any decision that has initial work in terms of if you don't understand something initially, a space that you really want to get into but you don't understand it, do I need to do this M&A? Do I need to acquire this company? Do I need this capability going forwards? Those are uncertain elements that you don't have any visibility of because you haven't done that before. You

16:39need a quantitative approach to first say yes or no, because that decision is driven by the part of the brain that only deals in abstractions. You don't want the numbers there to drive your decisions because the numbers are only going to justify how much or how effective do you want to go, and that's where the numbers add value.

17:01So numbers definitely play a role. Qualitative also plays a role, but it all depends on, again, coming back to CPat's point, is what is the objective? And again, you can have different models at different points in time depending on what you really want to achieve. The same organization can choose qualitative at one point, quantitative at another point. It's not wrong. It's purely because that's what the situation requires at a particular point in time, and it's essentially driven by exactly what the objectives are. But being able to quantify and qualify that, and then going back again, coming back as an engineer, a designer from the past, is what are your

17:39requirements that are driving that particular expectation? Being able to put literally those figures as to what my requirements are that are driving this particular expectation will underpin exactly which model you choose. Anyway, back to the panel. It sounds like we're converging toward an agreement on the panel that the question shouldn't be both/and, or shouldn't be either/or. The question should be where and when to use which.

18:09And I think I'm- So, well, let's talk about repeatability then, because one complaint about a qualitative assessment is that it can, shall we say, it can be moody, right? It can reflect mood more than reality sometimes. When does chasing a perfectly repeatable model create paralysis by analysis, and how do we get the right balance there?

18:47Tony, do you take a stab at that for us? I love that question because that's exactly where I think I'm going to start to diverge from the answers that we just heard. I would never run a Monte Carlo simulation for a 1,000-dollar decision. I'm going to use my gut. No, I don't think we need to do a risk analysis on this, or I would rather put my efforts into the ransomware risk assessment, something that's in our top risk list, rather than an asteroid strike, something that doesn't have a high probability around that. I don't need a quantitative risk analysis to tell me that a ransomware incident should be analyzed first before the asteroid strike. The problem that I have

19:39is formalizing some of the qualitative methodologies into our decision-making. And that really is the litmus test that I use personally is, is the method that you're using decision useful? And David, to your point, with qualitative or heat maps or red, yellow, green, high, medium, low, one, two, three, the answer itself can't be tested, compared, or added together.

20:10The quantitative answer might be wrong or less wrong, but at least there it can be tested and compared. You can open up the hood and you can look at the numbers underneath, and it can be challenged. And for me, that's probably the biggest attribute. That's the biggest reason why I'm a quantitative risk advocate. I ran this test at several different organizations. I took a very, very simple but very detailed risk scenario, and to date, I've asked about 60 people, "If you could rate this risk high, medium, or low." And it's just a standard data breach risk, and it always ends up being the same. About 30% of the people think it's low, 30% think that it's high, and 40% think that it's medium. And because of that, I

21:05ask them, "So why'd you rate it this way?" They're bringing in their own psychology, their own trauma from past incidents. They bring in their own experience. So when nobody agrees on a rating, what are we rating? So with qualitative risk, we're not actually rating the risk, we're rating the rater. We're rating how you feel about it. And that's why I think that I do use qualitative gut checks, gut feel when I start an analysis, but I don't think the methodology should be formalized in anything of any decision that has consequence in our organization.

21:46And I think just to chime in to Tony's point, what I would say is, it's a very valid point that he's just made, and I'm, again, I'm actually going back and forth on exactly where I land, but purely because the situation demands that, which is an organization is a living organism. So a person residing on the chair is a person on the table at the point, but remember that the person is going to move away in a couple of years and somebody else is going to come in. And how do they feel about that same decision? What is their risk appetite? What is their thing? So this decision has a life of its own once it's made, or once the situation comes to light,

22:25then it has a life of its own. So it has to live within the organization. So the person on the chair is on the day making the decision, but somebody else is going to have to take the fall for it sometime down the line, and how do they feel about it? These are going to be challenges where people have different levels of understanding about what that situation is. A person might be a domain expert. He may feel that a particular risk is medium and I can deal with it. It's not a problem. But tomorrow the founder goes away and there's a management consultant who comes and sits there. He feels differently because he's not a domain expert. He might feel that he needs to bring in some expert advice in order to

22:59handle that situation. So he will feel like, "I'm sorry, I don't understand that situation, so I think that's a high risk." So each person might feel differently, and being able to quantify the level of effort they want to put in to address that particular situation or a level of uncertainty that they want handled will depend on... And it has to live within the organization. Ultimately, that's where I would agree with Tony that you need some level of quantification because that's a living, breathing document that can be tested. Yes, it'll have to be updated with time in order to keep abreast of everything else that's happening, the geopolitical risks, the inflation, and all that stuff. But having

23:36said that, at least you have a baseline to work with and then says, "On this particular date and time, this is what we arrived at, and then we will actually build on from there." Thanks, Tony. I really appreciate that. Yeah. I think that's important, right? I mean, I like the phrasing, David, of this isn't quantitative or qualitative. It's how do we kind of intersperse both of those as necessary? And the way I typically talk to folks about that is very much in alignment with what Tony and everyone are saying here, which is, what are the pros and cons of each of these two methods, and how do those best support the decisions that we're making in a given

24:13moment, right? Qualitative is it's quick, it's easy, it's accessible. Leadership is going to be able to understand that very- ... quickly, right? This is a red risk. Okay, we know- Yeah ... that's something to focus on. Quantitative, on the other hand, right, it's more defensible, more reproducible over time if you have new analysts coming in.

24:33Um, and I think there is that more of a through line if this is a, a longer term decision, right? If it's something quick, you know, 1,000 bucks like Tony said, "Hey, we don't even necessarily need any analysis." But if we are doing something that is gonna be a cascading sequence of decisions, then having an analysis where we are documenting the assumptions being made and we have numbers that we can communicate and debate and, um, argue about as a team is really how you then feel good about that- Yeah ... in the long term. I, I think that's, that's well, well said, Adam.

25:11Um, and, and, and, you know- So I'm gonna, I'm gonna add one thing that- Go ahead, CPat. Yeah ... covers both Sriram and, uh, and Tony's, uh, kind of points they made. So that is exactly why I always have, when I, when I go into an organization, I start to set these things up to have a place for quantitative. Because likely most people know it's there, but it's on the continuum. It is only used for that early triage. When you start talking dollars, you have in your set of frameworks that w- as we move through my risk management framework and I start to get into, "I'm going to be putting certain mitigating controls," or, "I'm looking to do risk transfer against this,"

25:49you naturally then move into discussions of dollars and you're gonna have to switch methodology away from something strictly qualitative. If you don't have it anchored, then you do get the opportunity for somebody to come in after you've left or as the organization matures, and they don't see that continuum. They don't understand where these tools have their place. So if you leave them with, "It's okay to have these things, but you only use it here," and then you graduate as you go through, you know, just any risk management has those different processes of you're gonna triage and decide which ones you're gonna treat and how you're gonna treat it, and some you're gonna accept. You're gonna accept a lot of those green

26:26ones. We're just gonna move on. Like Tony said, it's like, let's not bother pulling out a pencil even, but move on. Right. So, so that's typically when I start to set up these frameworks, even, you know, previously consulting or working with my current organization. Where it fits, it has its place, but soon as we start talking money, soon as we start talking impact to the board, we do have to start to shift these, uh, any, uh, you know, different quantitative models that make sense for the organization. Yeah. I've, I've very effectively... And I, I, I love the use case that you shared earlier, CPat, of, of using qualitative on the front end of a,

27:04of a process to collect information, right? Um, I, I have used it as well to, um, uh, gather consensus from a group on where we're going to invest our modeling time. Like, which risks are we actually gonna, as you said, pull out the pencil for? Um, I think that's a great use case. We have a second question from the audience.

27:34"How do you reconcile the usefulness of qualitative methods against the idea that risk matrices are harmful and lead to poorer decisions?" I, I, I, I think we've... Well, it feels like we've answered this, but let's, let's- Which decision... Uh, we'll go back to the Laura session. Which decision are you trying to make? If, if my decision is I'm simply trying to get an inventory from my field members on- Yeah ... what frightens or scares them, I'll take that input all, all day 'cause it's gonna, it's going to be input into further downstream models. So that's- Yeah ... that's exactly where that fits.

28:06And if we, if we're talking about, say, a heat map or a risk matrix, um, we don't have to treat that as completely separate from a, a quantitative output, right? If we have frequency and magnitude for- It's just a, it's just a visualization. Yeah. Put number, put numbers, put dollar values on the, on the ma- on the thing and it's, you're fine.

28:23It's, it's so, it's so- It's like saying, "I hate pie, I hate pie charts." I'm gonna start a new T-shirt, "I hate pie charts." - I hate pie charts. They're misleading. They're misleading. I think, I think this one kind of goes... I think this one kind of goes to Tony's book as well, is heat maps were derived as a part of qualitative analysis. But if you really look at, if you really look at the sum and purpose of what that heat map is, it's actually for the scientific people in the community or who are attending the session, it's actually a logarithmic map, which is why numbers cannot be added as simply as that.

28:59It's, it's like adding 10 power minus 3 and 10 power minus 6 and then saying, "Oh, it's just 10 power minus 3 into 2," or whatever. That number is not gonna make sense. It's a logarithmic scale. Low means it's basically, you know, it's, it's a frequently occurring event. It's not something... It's well understood. I don't have to worry about it.

29:16But you label, but you label your axis with low. Why can't you label your axis with numbers? So, so the late David Vose and I did a- I wish, I wish. I wish. The late David Vose and I spent a lot of time working through this. Yeah. And it, it's just a visualization tool. He even, he even went as far as, I think, start to use gradients. So I, I think I wanna be sure what you just did there was you, you equated ordinal scales to a visualization tool. And so that's, that is the biggest broken thing, is if that visualization tool works and if your axes have the right, you know, data on them, it can be an extremely powerful tool to make that transition from the ordinal scale heat map

29:53to a risk-based- But a hurry question. Yeah. The, the challenge, CPat, is I agree with you. The only problem is ultimately the consumers of that information don't want the numbers there because their decision requires them to have simple values in there. So we are also driven by what our consumers want. Ultimately, this is a consumer-driven society.

30:14So if sometimes they say, "Oh, no, no, no, don't give me the numbers. It's confusing the whole thing. Simplify it for me. Give it to me in simple terms that I can use further down because I can use that to articulate," and it's easier for them to communicate visual colors. Ultimately, you think about it- And so you, and so you can't- ... how you're gonna represent information- You've been up the ra- you've been up the ranges and you still have a high, medium, low, and when they flip back and say, "What does that mean?" you can flip it right back to your, your mathematical scale.

30:38Yeah. Right. I mean, truly- Yes, right ... I think that, that is a big deal, right? There's a... These are two different questions or topics, right? The rigor of analysis doesn't have to equate to, um, the how, however boast our outputs look, right? We could have a very simple output for leadership or board members, whoever we're presenting to, and still have a very rigorous analysis behind it. And again, to CPat's point, whatever that visualization looks like doesn't have to take away from that rigor.

31:10What I hope is, I, I agree with all of you that a lot of our leadership, they're striving for something simple from us. And we walk into the room with a lot of numbers, a slide fold- filled with numbers, or even worse, we start talking about Bored Panda and ShinyHunters and multi-factor authentication. We start throwing out jargon. You see their eyes start to glaze over.

31:31What I try to do is when they ask for something simpler and simpler and simpler, instead of using colors or, or qualitative adjectives, high, medium, low, um, hot, medium, mild, I use language that they'll recognize from their MBA classes. So let's say return on investment or risk exposure, stuff like that. Very simple things, but using their language from the language of business. And I've found that people, their, the glassy eyes start to perk up when you say that we have a positive return on investment ratio with, um, with these security controls. I don't even say multi-factor authentication anymore. I just say security controls to prevent

32:16these types of adverse events. Yes. And when people challenge me to be simple, instead of defaulting to adjectives and colors, I try to meet them where they're at and use their language, language of business. So suppose for s- it's... Let, let's talk about the situation where, um, we've, you know, we've successfully made this transition into a, a quantitative presentation, we'll say at the, at, at, at the leadership level.

32:48Um, how do we prevent leaders from treating a false sense of precision in those models as, uh, a substitute for true risk awareness in uncertain markets? I love that question. Um, I think that false precision is a huge problem in our field, our industry. It's not just in quantitative risk. Um, I'll make the argument that red, yellow, green is false precision too.

33:19Um, I have a friend of mine that describes data breaches like California earthquakes. Um, I know Adam lives in California too, so he knows what I'm talking about. If you look on the USGS website, every week we have a lot of little ones, and then once every 30 years we have the big one. The same thing with unintended data disclosure, which is the, you know, the, the minor version of a huge data breach. You have a lot of little ones every month.

33:47You have somebody sent the wrong email to someone or somebody left some code open. That's an unintended data disclosure potentially. Um, coloring that red is false precision because it forgets about the small incidents and it might be undercounting that huge Equifax type one. Yeah. Um, in risk quantification, I do the same exact thing. I never present a single number. It's always a range that our typical outcome is this, this is what we're forecasting.

34:18The worst case scenario, don't lose track of that, it's that over here. It's this number. We treat them differently. One we would plan investments around, the other one is more resilient cyber insurance and cash reserves and stuff like that. Um, but we never wanna lose sight of the range or else you will lose your audience like that. Um, and I, I just think that the reporting things in red, yellow, green gives the same sense of false precision as well.

34:46Yeah. If, if it's part of the transition, you gotta remember as risk quant folks when we go into these meetings, if you just tell them you're gonna throw out 20 or 30 years of risk management practice that they've been using, especially the practitioners that are using those tools, they're gonna push back. They're gonna say, "We haven't had any problems with this before in the past. Why, why are you even doing this?" So I typically will say, "Hey, here's a way where we can get better resolution on the work you've already done," right? And you're migrating them into a cultural shift rather than calling their baby ugly because that's not gonna work,

35:20right? And, and even worse, if you're up against a, a big four consultant that's got the ears of your executive team, you're, you're not gonna make any progress. So you have to use this as a continuum, as a, as a maturity type model and, and moving forward. Tony, I do like your, uh, earthquake model, but I'm from Louisiana and, um, typically I, you know, let's go with a heat map that we all trust, the Scoville model. Like, if you have a hot pepper on a, on a high part of the Scoville model, I suggest you avoid that, s- some of them.

35:51Yeah. And then they're happier with the green one. So, so- - ... you know, these things do work with numbers and, you know, a heat map isn't necessarily a grid, right? It can be a sliding scale. So, so this is the thing again, if the visualizations work, if it helps get your executives focused, if they at least understand the soundness of the numbers and scenarios like Tony's providing, it's just a tool. And I think that's when we start to not understand how to use these tools to forward the conversations, to change the culture, we end up shooting ourselves in the foot. I, I remember way back in the early days of FAIR, uh, when I was working with the GRC platforms, people are like, "We're doing

36:30FAIR on everything." I'm like, "Whoa, why are you doing that?" It's like they were doing it, like, on their accepted risks. I'm like, "You just said you accepted the risk. Why are you doing that?" You know? "Well, we're going to do it on everything. That's what the CRO said to do." It's like, "Okay, have fun with that. It's not going to work."

36:45So... I love that. Chris, you mentioned- We have Schofield scales and earthquakes. We've got to figure out how to make that into an article here somehow. I think you just named the books that you and Tony are going to write together. - Yeah. From Schofield scales to- Chris, you mentioned walking into a room and calling someone's baby ugly.

37:06I've seen so many people do that and fail. Yeah. You never want to do that. And we all have to recognize, we're all part of ERQI, and the third word in that acronym is quantification. But we can't walk into these rooms and say that. It won't work. I've seen people do that, and it completely fails. But behind the scenes, like in my own mind, just because we've been doing it for 30 years doesn't mean it's right. For hundreds of years, bloodletting was an accepted medical treatment, and we don't do that anymore. I think that the risk matrix is the equivalent of bloodletting. It should not be used for any decision or consequence. It depends on- Just to take the conversation a little bit more-

37:47The board, the bloodletting may work. Just to take the conversation on a little more interesting note, just on the back of what you guys just discussed, is you don't want to go in and then challenge what they've been doing for so many years. But the question is, through quantification, can we uncover certain things that have not yet seen the light of day, and through that, make it more obvious that we are opening up to certain risks that they have been accepting without even recognizing it, and that might actually open up their thinking, possibly?

38:19So I learned this when I was in corporate strategy, right? And I learned from some of the masters on this. You ask a lot of questions, right? "Well, what does red mean to you? What did that impact?" So you just start to take them down the scenario building. You start teaching them to build scenarios without telling you're building scenarios, right? I've said this in a couple previous meetings.

38:43When I go out on the shop floor, do you think I say one thing about cyber or ransomware or whatever? Absolutely not. "Hey, when was the last time this line went down?" "Oh, it went down two months ago when Billy Bob kicked the plug out of the line and we didn't have the backup recoveries." Like, "That sucks. What did we lose?" "Oh, we lost about a million dollars an hour." "That's really terrible. What if I could tell you I could take all five of these lines down within 20 minutes if I got this USB stick plugged in here?" "What? You could do that?" "Oh, I absolutely could do that." So you have to have these discussions in terms of resilience and tying that back into. So when I do see

39:19embedded qualitative methods, "Hey, let's talk about why you think this is this color. What is behind that thinking?" And you start to elicit and change kind of their understanding on how to better understand their exposure. And that's the cultural part. And you're talking, Dr. Sriram, about a lot of the challenges just like cognitively. You have to help them along that journey.

39:45But if you go in and say, "These things are crap and we're going to do all this math," they're going to look at you like, "What? No, we've done this for 30 years and it's been fine. We haven't had a breach yet." Yeah, we've talked a lot about this cultural shift, and across dozens of organizations that I've helped implement programs at, that's probably the biggest reason that I see risk quantification programs fail, is a mismanagement of this cultural shift, right? Like, as we were just saying, you go in, you call the baby ugly versus a more consultative approach, coming back to the decisions being made. And frankly, why should these executives care, right?

40:23If it looks stupid. Yeah. How can you position it? It's like, "What do you mean? You've spent X millions of dollars with this big four consultant to do these matrices, and you're telling me they're completely useless?" "I can't say that. This was a good investment. We've been making great investments in this stuff." Yeah.

40:38"Let me show you how to mature that and make better decisions," right? Exactly. People are invested in this stuff, man. Yeah, it's a big deal. So I don't want to downplay that as we get technical in some of these questions. That's one of the first things you want to start thinking through is, how can I position this in a way that's going to be received well?

40:56It's a beautiful thing that you brought in CPat because you brought in the word resilience, and I love that because I think it's kind of the word of the year, word of the season at the moment, and it's very prominent, particularly because me coming from a critical infrastructures background here in Australia, I think it's absolutely everywhere. Everybody wants to understand what resilience means. But I will just take one equivalence relationship. So imagine that your organization is like a flight that's already taken air, or it's like a rocket ship that's already gone up, and you literally have to live on your own. You don't have any other support

41:31system. What can go wrong? How can it go wrong? And what happens? What are all your recovery mechanisms? How do you build it in? What's the level of acceptance? What do you accept? What do you not accept? What's good? What's not good? Being able to qualify that, that kind of brings the story back to, what is my organization capable of at any point in time? How many things can simultaneously go wrong? What can I deal with? What can I not deal with?

41:57I guess. Any thoughts on that, of course? Jump in there, Tony. Come on. I agree with everything. Everything Sriram just said. 100%. All right, David. This isn't much of a fight. Yeah, it's not much of a fight. I kind of want to talk about appropriate handling of the tail. And so suppose we are making that transition from- ... from qualitative methods to quantitative methods, and we're continuing to use the heat map as an output, not a decision tool, but more as like a report.

42:55How do we deal with large tails in that scenario? And how do we get boards familiar enough with large tails that we can make good decisions about those events that can be extreme? It's tough to do with the current heat map that we all recognize, and I want to separate two different things that we all look at. So, if all of you can imagine the three-by-three grid and you have the green, yellow, and the red, that actually does two different things. The first thing is it's a model, so you can plot your likelihood and your impact, and then you find where it lands, and then that's your risk. Ransomware risk is yellow or red.

43:45It's a model. It's a rudimentary one, but it is a model. The second thing it does, it's a visualization technique, and that's what we most often refer to as the heat map. Oftentimes, we conflate the two. The risk matrix and the heat map look exactly the same. They are the same. They do two different things. So when we're taking quantitative results, as you mentioned, David, and plotting them on the heat map, we do lose that tail unless you do special things to it.

44:12If you take a single point and you throw it on there, even though underneath the hood you have plenty of numbers and you have a range, you have to choose what part of the range you're going to plot. So, a lot of people pick the P50 or the P95, the 95th percentile of the Monte Carlo simulation, or maybe we're just going to pick the mean. We're going to throw it on there.

44:31That goes to your question earlier, David, about false precision. So we do have a lot of false precision with that. But I've seen people do creative things like show ranges on the heat map that span multiple cells. I've also seen people have a legend on the side. That was David's work. David was doing a lot of work in that space. David Vose did that.

44:57I've also seen people throw a legend on the side that says that the dot is the mean value and here's the full range. But you do lose that tail, unfortunately. So- Yeah ... if I was ever going to show a heat map as part of my visualization, and I do sometimes because it is the language of business, as we're all talking about, the de facto language of business, I will always supplement it with the ranges or maybe a loss exceedance curve on the second slide, something like that. I'll try my hardest.

45:26Yeah, I try to model it and bring it down to the annual expected loss numbers because I can get to a number from that perspective and kind of do similar to what Tony's saying, kind of this is the mean case and then this is the absolute worst case. So you can still put that in tables and/or charts by doing a vector-type view, which is what David was really exploring.

45:52Because then that way, if you say the worst case, and then they get all befuddled and confused about that. Say, "Well, that annual expected loss is not what you're going to lose next year." It's if you were going... And try to explain it in things that they'll understand. If you were going to self-insure, this is probably the amount of money you should be putting in the bank. And they still get confused sometimes. I say, "Do you pay for car insurance?" "Yes, I do." It's like, "Why do you pay for car insurance?" "Well, because I could have a bad wreck, right?"

46:18And so you could have a one in 20 year wreck where you and your family end up in the hospital, and thank God you have car insurance, but you're paying those guys 300, 400 bucks, maybe more in certain states, definitely in Louisiana. You're paying a certain number a month. So at least you can put it on a range, and now you're starting to rank, even if it's just a vertical heat map. You can say, "Hey, here's where we start to really need to focus on some of these expected losses." So again, trying to use mechanisms that executives and laypeople understand. And when I do the car thing, and then they're, "Well, what are controls?" Seatbelts and airbags, guys.

46:54Those are the things you invest in. You drive without a seatbelt now? You turn off your airbags when you drive? Don't think so. Well, we need to invest in some of those controls for our operations. So that cultural and trying to get people on the same level are typically the ways I go about trying to address this. Storytelling has been a strong theme today, and what you're talking about right now is storytelling. And so I just wanted to point that out because we started this morning storytelling, and we're ending the day talking about storytelling. Tony, go ahead. I cut you off.

47:30No, that wasn't me. No. Oh, I'm sorry. I thought you were about to say something. Adam, was it... Somebody. Yeah. So, I mean, storytelling's exactly it, right? I was going to use the phrase positioning, but they're synonyms, right? Yeah. And to me, that is the combination of the cultural shift happening and decisions being supported. That's what turns into storytelling, right?

47:54Yeah. That's where if we're talking about tails specifically, I mean, it's human nature to want to say, "What is this worst-case scenario, terrible thing that could happen to us?" And that's fine, right? We don't want to say that's the wrong way to approach things, but it comes back to, is the question or is the decision we're supporting, how do I prepare for a catastrophic event?

48:16Or is the decision something closer to what's the biggest impact to the organization over time, right? This is kind of going along with CPat's example there. So, yeah, I'm with you, David. I can tie it back to two topics that I heard yesterday in yesterday's conversation. One was the conversation regarding the Jaguar issue in the UK a few years ago, where the event itself has not been fully modeled and hadn't been understood.

48:46Because at that point in time, the event that happened was treated as a black swan event. And I think I have to put the word out there. Everybody's using this word. The- It's not like the event has never been understood or predicted, nobody really thought about it. It's like nobody thought that it was going to be consequential because until it happens, everybody thinks that it's never going to happen. But the thing is, people have to recognize it's within the realms of possibility. And as long as it's in your universal space, as far as probability space is concerned, then it is likely to happen. And it's not like, just like what CPat mentioned, the money that's been identified as possible annual loss is

49:24money that you have to keep separate anyway, because when you incur that loss, all that money will go away immediately in one shot. Exactly. And organizations' productivity is being lost little by little, but it's actually being collected elsewhere because somebody else is going to collect the kitty the moment that instant happens.

49:43Organizations don't recognize that. They just look at what these numbers are and it says, "Oh, the total ALE is only something like 10 million." It's like, "Yeah, I don't have to care about that because my bigger concerns is things, anything above 100 million." It's like- Yeah ... that's not what you should be really concerned about. Just because the product of probability and the loss is 10 million doesn't mean the actual loss is 10 million. It is 10 million in productivity you're losing annually over a period of 20 years, which collectively is going to yield much, much more than 100 million.

50:14And that's where I say, "This is your car insurance." Even when I do the presentation, "Remember, guys, this is your car insurance number at level sets." Then you can have that discussion. And this is exactly the conversation we should be having in the sense that organizations have to recognize all those so-called black swan events that they're talking about is, what are those weird possibilities that can actually bring down not just the organization? Now we have to talk about the branding, we have to talk about the organizational morale, the ethics. Everything is going to play a role in how the business operates the next day.

50:46So there are multiple dimensions, and we already talked about risks that are also multidimensional in their own form. Yeah. Let's- So yeah, sorry. There's a question in the Q&A that's related, Sriram, to this kind of black swan kind of events. Sure. John Benninghoff, John, thanks for joining us today, asks, "Are there limits to quantitative risk analysis, i.e., are there high impact risks that shouldn't be analyzed using numbers?"

51:17Hmm. I think the way I would approach that problem is, I wouldn't say that there is no event where quantitative doesn't play a role. I would just say there is probably scope for what level of decision. So it has to be driven by strategy. It has to be driven by what the organization wants to do at that point in time for that particular situation.

51:41What's your decision? Do you want to get into that space? Do you not want to get into the... If it's a simple binary decision, then perhaps a qualitative is sufficient at that point in time, provided it's backed up by data for further analysis and scrutiny for next level details at whatever point in time. But having said that, you don't necessarily not do one and do the other.

52:01So you always need to be able to do some of these activities purely because that level of analysis is required to understand a situation, and different people absorb that information differently, which is essentially how it's driven by... And again, it's driven- Yeah ... by the context, it's driven by strategy, it's driven by what the organization really wants to do at that point in time.

52:25I recently rewatched the movie "Erin Brockovich," and I think that that's a great movie, I think, to answer this question. PG&E in the movie, and it's a real-life story too here in California, they made a series of decisions based on numbers that they knowingly took shortcuts that resulted in a lot of people getting sick and dying. And I think that that's a question that every organization needs to ask themselves if they ever have human life or human safety at risk, that what's your tolerance for that? You can quantify the loss of human life. A lot of companies do, a lot of insurance companies do. It's going to be a certain number.

53:08But for me personally, if I was running an organization, that would be intolerable to me. So in that instance, I would never want to do a risk quantification on human life like that, or if I was in PG&E shoes in the Erin Brockovich story. Yeah. That would be something that's just beyond my tolerance, beyond my comfort level. So that's how I want to answer John's question, that there's just certain things that is beyond your organization's tolerance, that we're just not going to tolerate harming people in that way.

53:42But it is a reality of some risks that they can cause human harm up to and including loss of life. I, when- Just go hang out with some oil and gas people, and they'll tell you. Yeah. And when I have organizations sort of wrestling with those scenarios, I recommend that they model injuries, not loss of life, because injuries usually end up costing more anyway, and it's still uncomfortable, but it's more comfortable talking about injuries than it is death in my opinion. Yes, right.

54:27Andrew, you look like Carolyn Long. I think you got the wrong title on there. Just checking, buddy. Cool. Wow. Thanks for sharing, and I'm going to come back in a minute, perhaps named correctly. Bye. I could rename you. I could rename you. Stay there. Yeah. Yeah. Isn't it in "Fight Club," Edward Norton talks about the automobile industry and how they're putting numbers on death? That's unfortunately pretty close to- ...

54:56the way some of these things work. And I know Adam's been through this because I was through some Risk Lens sessions way back in the day. There were people who would stand up, they'd leave the room. Like, "You can't model human life." And they'd get up and leave the room, kind of to your point, Tony. It's a tough position to be in, but it's unfortunately, it's a reality of some of these businesses. You have to address it.

55:16That Fight Club scene you're talking about, he walks us through an expected value equation. Yeah. We should have- It's the same thing as a fair analysis. Yeah. Yeah. It's amazing. Yeah. Okay. Let's have- Fight Club and ERQI. You know what? Wouldn't put those together, but this is why we do this, man. That is some brilliant stuff, man. We talked about Louisiana peppers and earthquakes and God knows what else at this point. We haven't talked about the wildlife in Australia. That'll kill you like outright in about two seconds. Yeah. So- We've got everything from A to Z that can kill you, mate. Good to know.

55:53Let's have a quick round robin final question, because we don't have much time left. How about this? I want you to pick and say quickly your preferred visualization and the use case that you would select for that visualization. Like, pick a pair, use case and visualization. What's your pair? And- So I've got a custom one I'll bring into the institute, but it really lays out risk transfer, worst case, best case scenarios, and it just takes a scenario and it gets the executives thinking about kind of what's really going on here. And I also use it to start to set risk appetites. David, you and I have talked about this before. It was discussed some yesterday. It's like,

56:53"Hey, how far are you willing to dip into the corporate treasury after this insurance policy maxes out?" And then they're like, "Well," I said, "Half? All? None?" Right? All is bankruptcy. We talked about that yesterday. So I have some visualizations that I use. I'll have to go dig them up and bring those back. Oh, interesting. Yeah, I'd love to see that. Tony?

57:13I am going to choose the loss exceedance curve when I am presenting to anybody outside of security. Not security, but outside of security, because anybody who's ever taken a statistics class, an economics class, finance, they have their MBA, engineering, safety, hydrology, meteorology, anything, they are going to recognize the loss exceedance curve and know how to read it. Oh. You know, I was going to say loss exceedance curve, Tony, but we can pivot here for some variety. If I'm talking about cost-benefit analyses, I like the visualization of just a number, which is risk reduced per dollar spent, right? It's simple, it's clean. A metric. I like that.

57:54Anyone can understand that. There can be rigor behind it. And I'm pretty cheap, so I like this best value kind of number. Yeah. It's thrifty, Adam. You're thrifty. That's a- Can you plot that on a heat map? That's my question. Sriram. I think I'd probably go for a graph visualization, purely because I want to demonstrate what level of interconnection exists that people are not aware of when they make a particular decision. And I think that's the one thing that's actually come forth in a lot of my discussions is, sometimes people assume that it's one thing, but it has all these underlying things that they have never really explored, and they're accepting all the risks underlying that without recognizing

58:38the implicit association that's causing that particular relationship. And being able to unravel some of those topics can lead to very interesting conversations. I know I'm not part of this forum, but- So I changed my background, Sriram. I am also a huge fan of the graph, so. - So I have been experimenting with something I just wanted to share with this group in particular, but everybody, right? Like, loss exceedance curve would be my number one answer, but I've been trying to figure out how do we get time and velocity into the picture?

59:07So I'm looking at a 3D kind of model that I'll be putting out in the ERQI community. I have an idea for that. I have an idea for that. We should talk. Okay, very much so. Anyway, loss exceedance curve, but making it 3D visualization so that it can communicate velocity and time, although to a certain extent. Anyway. Lovely. All right. Lovely being with you on the panel. Thank you very much, David. It's been- Sriram ... fantastic, and I really enjoyed the conversation. Thank you.

59:38Thank you. Thank you, CPat. Thank you, Adam. Thank you, Tony. Absolutely. It's been great, guys. Way to kick it off. Thank you for having us. It's excellent. Pleasure meeting you all, gentlemen, and great to be on a panel again with you. Cheers. Thank you all. Thank you all. Thank you all. Thank you all. Thank you all.

1:00:03And then there were two. And then there were two. So, I'll just jump in and say thank you to everybody that presented, paneled, showed up as a registrant today. My final closing words on the matter are as follows. So number one, as a reason, if you have not already joined the Enterprise Risk Quantification Institute and you're interested and you love this content, just a reminder that we're going to be releasing to the community first, ultimately, potentially to the public, but how do you become an enterprise risk quantifying professional, right? So we have a cool knowledge graph that we've been working on that we're going to release to that, that if you join, ta-da, bonus, you get access to all

1:00:53the wonderful content that you've seen today. Will initially probably be released to the institute first and to the public later, because that's kind of the way that we do things. Yeah. So please join us if you've enjoyed this content. And not only join us, but engage, right? I mean, the beauty of having- Yeah ... this community platform is engage, right? You can engage with a Dr. Bob, with a Caroline Wong, with a Tony Markoven- Absolutely ... with a Sriram, with a CPat, with an Adam, right? So please join us.

1:01:21And with that, I am going to- Gracefully called to close my comments on this, other than, again, to express gratitude for everybody that participated in any form. So, back over to you, Mr. White. Final word. I second all of your kudos and appreciation. I do want to spotlight one person, though, and that person is you. Because you architected this agenda, and you did it artfully, and you did it in a way that was connected and took us on a journey. And I have thoroughly enjoyed this journey over the past two days.

1:02:09I'm in awe of the panelists, all the panelists we had. These are incredible folks. So, Andrew, it has been my pleasure to work with you on this. It has been my pleasure to build this institute with you for the past year. Thank you for all that you do for us and for the community, and thank you for engineering a great agenda for these two days.

1:02:41I appreciate those kind words. And having said that, because you know how I am about my last, last things, I do want to recognize both Teaser Sweeney, our director of community engagement, and Nicole Sundine for her work on making sure that this platform even existed for us to participate on. So, thank you both immensely for your efforts on behalf, and thank you for your kind words, David.

1:03:03Appreciate it. You're welcome. And with that, let's call this first ERQI Global Risk Summit to a close. Thank you for being with us, and we'll see you next time. Cheers. Thanks, everyone.