EP284 Closest Alligator to the Canoe: How Transforming SOC Became P0 for Lloyds Bank
29 Jun 2026 · 26 min
In this Cloud Security Podcast episode, hosts Tim Peacock and Anton Chuvakin interview Matt Rowe, Chief Security Officer of Lloyds Bank, about the bank’s multi‑year security transformation. Rowe explains how the organization secured board and executive buy‑in by aligning security goals with the bank’s ambition to become the UK’s biggest fintech, and how that vision drove a 20× reduction in daily human‑worked SOC alerts (from ~250‑300 to under 10) through Google StackOps and AI‑enabled triage. The conversation covers the dual challenges of adopting agentic AI—balancing competitive pressure with regulatory risk—and the need to modernize identity and access management (IAM) to support fine‑grained, ephemeral permissions for AI agents. Rowe describes three AI‑driven agents in the SOC: a triage agent, a threat‑hunting agent, and an SRE‑style pipeline‑monitoring agent. He also delves into vulnerability management, emphasizing exposure management, remediation velocity, and the importance of operating security controls at machine speed. The discussion expands to legacy mainframe patching, crypto‑agility, and preparing for quantum‑era threats. Finally, Rowe offers advice to other CISOs on sequencing transformations—prioritizing IAM, SOC, exposure management, and data‑security posture—while stressing that transformation is a deliberate, hard‑chosen path that requires cultural safety around failure.
Chapters
Security. Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host here today, well, it's just me, but Anton's going to join us for the opener as well. Tim Peacock, Group PM for a bunch of agentic and infrastructural stuff on Google SecOps. And of course, Anton Chuvakin, Senior Staff in Google Cloud's Office of the CISO. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/cloudsecurity/podcast. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. Follow the show, argue with us and the rest of our Cloud Security Podcast listeners on YouTube, youtube.com/@CloudSecPodcast. Anton, this was a super fun episode to record. I'm so sorry you missed it this morning.
I mean, it's absolutely my fault, and I'm happy to do a full, I missed all the fun, and that's just such a great seesaw, such a great topic. And also a great previous episode, but what happened happened, and I'm just going to go and interview you about the episode now. So, Tim. Okay.
Do you want to hear the highlights? Do you want me to tell you what you missed?
Yes, I want you to give me the highlights.
Yeah. You missed Matt talking us through change leadership. You missed him talking about how they achieved a 20x reduction in the number of things that humans look at when they migrated to Google StackOps. You missed a discussion of forcing functions and funnels and all his optimism about the need to transform his team so that his company, which is 250 years old, can be around for another 250 years. And so just incredible.
Wow. Okay. Yes. Now it sounds like I did miss a lot. And I have a suspicion that we may have to ask him about the 20x because people usually blame us for how 10x is an exaggeration. But we keep seeing examples where somebody improved something in security by more than 10x. And they wisely point out that actually 10x is kind of reasonable, not excessive. And then people show up and say, do you mean by 10%? And we say, no, actually, we do mean 10x. We really do mean 10x. And sometimes 10x is a low boundary. That is very optimistic, yet also very grounded in reality. Yes.
So maybe without any further optimism, pessimism, or other isms, let's turn things over to today's guest. Today we're joined by Matt Rowe, the Chief Security Officer at Lloyds Bank. Matt, thank you so much for joining us today. I think this episode started for me at Next 2025 when you gave me a hug. Is that right? Do you remember this?
That was the start for me as well. Yeah, it's great to be here. Thank you very much.
Yeah, thank you for joining us.
I'm sad I'm not hugging you today, but we are virtual.
Ah, yes, we can have a virtual hug. And listeners, you can let us know if that's the same or not. I want to start with the change leadership thing, because a year ago we had Manisha on the show talking about SOC transformation, and I caught up with her a couple of months ago, and I, I heard you tricked her into another kind of transformation. But aside from Manisha, I want to understand, how did you get your board bought in on this and how did you get the team bought in to execute on it? Because you're in the middle of a second transformation, you've done one. So what's the process there? How did you do it?
Yeah. So to get the board bought in and the leadership of the whole organization, We're really having a conversation with them about what we want to be, the organization we want to be when we grow up.
Aren't you a multi-hundred-year-old bank?
Exactly. Exactly. And hopefully many, many hundreds of years in front of us as well. So, the thing we talk about in the organization, my boss, our Chief Operating Officer, Ron van Komenhede, talks about us being the biggest fintech in the UK. So, yeah, we're 250 years old, and we want to be the biggest fintech in the UK. So that's about us being able to do what our customers need, exceed their expectations, put brilliant, like, services, tech products into their hands as quickly as possible to beat the competition on pace, to out-innovate them, to reimagine customer experience. And if we need to do all of those things as an organization, if we want to be a fintech, that's the organization we want to be when we grow up, then in the security organization, you need to think about what does that mean for security? Well, we can't be what we used to be. That's not going to work anymore. So the modernization campaigns, they really come from this need for us to meet the business in its ambition and its strategy for where we're going as a whole organization, so that in security, we're enabling it. We're enabling the group to safely go faster.
That makes a ton of sense and is a really nice transition into the second thing I wanted to ask, which is about AI adoption. And so do you see more risk on the blocking AI adoption? It sounds like the answer is going to be yes. Or on the AI adoption goes wrong and customer data goes everywhere and the UK regulator does what I fear UK regulators are very good at.
So, yeah, I mean, this is one adoption of AI, particularly the next generation agentic AI capability. We're really excited about it. I'm personally a tech optimist, but there are risks on both sides. So, yes, if you don't adopt this technology, you are likely to get outcompeted. Other people will innovate past you. And that's obviously a huge problem as it relates to being successful as a business. But to your point, you can't just unthinkingly adopt this stuff with zero regard for safety, with zero regard for security. So we are aiming to navigate through— there's a ditch on both sides. We need to navigate through that and make sure we're adopting it at pace, but we're doing a brilliant job of safe adoption. So that we hit that higher standard.
So how are you explaining on pace to your leadership and maybe more interestingly to your regulars? Surely they're saying you're out ahead. Why are you out ahead? Or maybe they're not. And if they're not, probably your leadership is saying, why aren't we out ahead? So how do you navigate that?
So I think it's all about how we unlock pace, which is about fast loops of experimentation, learning, getting some stuff wrong, improving. So that by the time we've got the latest technology that's in a production context or in a product in our customers' hands, we've had multiple learning loops already. And that's one of the really important things in terms of how we work now. We're not delivering in great big monolithic programs that take forever to get from an idea to something that pops out the other end. They're really short increment sprints of experimentation, of learning, of improving. Fail, fail fast, so that the thing that actually goes live has got all of that rigor with it.
And when you fail, how do you make that safe for the team to admit that they failed? What's that look like when a team, look, boss, we got it wrong?
Yeah, the only way to make it safe is by going through it, and it's proven by the reaction when it happens. So it's really important to incentivize and make examples of people who do a good job of this, which is that they have, with the best intentions, gone for something, tried something out, it didn't work, and then we have a transparent conversation about it didn't work, and we're going to learn a load from it. So, our reaction as leaders in that moment is the thing I believe that is the difference between it being safe or unsafe. And if you lift up those examples, well, we tried this, and it didn't work. This team had a go, and they failed. Actually, taking the baggage away from that word, using that word, and embracing that word failure, those are all parts of it.
We have an internal— I forget if it's quarterly, or half-ly, or yearly, but we have a newsletter that goes out internally of Google's greatest misses and fails. And they're told in such a fun style that you read these things, you're like, wow, we lost how many packets because a cow stepped on a fiber line that fell down in a field? And yeah, they're, they're always fascinating to understand, not just the particular failure, but the systems that led to that failure. So I want to talk about specifically IAM because I got an earful from Manisha about it. And specifically with agents, how are you getting ready for IAM and agents? And what does, what does that look like for, you know, a company of your scale?
Yeah. So you've referenced it a couple of times this year. We're running an identity access management modernization campaign and there's like a couple of legs to it. Firstly, we needed to modernize this stuff anyway for the human context, for the preexisting machine context. Where we've got to with identity access management is pretty disappointing as an industry, as a security profession, right?
Yeah.
So the need for modernization was there anyway. And then Agentic AI is very helpful in a way because it creates— it's a forcing function. So the preexisting identity access management capability, it was underwhelming, it was disappointing, it was frustrating already, and it's definitely not going to meet the moment for agentic. It just won't scale. And if we sort of carry forward some of the limitations of the current approach, it will be the point of friction. It will be the constraint, the impediment for us actually adopting agentic at scale and at pace. Really helpful forcing function. So that basically means, right, if we were to start again, if we were to start again with a blank sheet of paper and redesign identity and access in the agentic era, what do we do?
Yeah. What would you do?
And we were like, it's come to that. Working with our technology partners, we're working through that right now. And it's like a big, hard problem and it's fascinating and fun. But the intent is like to solve it for agentic. will give us the opportunity to then extend that back into the preexisting machine context, to extend it back into the human context, and actually just make the world a better place. Try and get past some of the sort of doom loop that we've had in the past with IAM, where quite a lot of the things that we do, like, nobody can really explain why. How on earth did we get here? We've kind of always done it that way. So we're trying to break away, break away from that.
You got a lot of cutting the roast in half before you cook it things.
Exactly. Exactly. And then in terms of precisely how we do it, like there's live conversations happening right now and people taking completely different points of view on what does good look like.
Mm-hmm.
But the point is, I think we've got to think about the identity of the agent and then how we apply permissions and how we orchestrate for autonomy. Like these are a set of ecosystem considerations and we have to think of it in a whole system way. There is an opportunity and a need, I believe, for AI agents to have much more fine-grained permissions where the task that an individual agent is performing, it's fine-grained. The task and the permissions of that task are ephemeral. They serve a purpose and then get burned down. And, and because the autonomy gets enabled through orchestration, that is where a lot of this control does need to be applied.
Hmm.
So it's quite a different way of thinking about it. Whereas, you know, in the human context, if we go right back to the other end of things, permissions, you know, like generally speaking, were given to a person's role or like an RBAC profile and were quite long-lived.
Yeah.
And that created quite a lot of challenges. So we're almost trying to invert like what identity and access management as a model looks like working with our partners. We're not saying that we've got all of the right ideas, but we're definitely in a space of like Let's do some greenfield work here.
I really love that. It so often feels like identity and access permissions are this thing that are only accretive. They only pile up and you only become riskier the longer you are at an organization. So that's really interesting. As you're going through this, what's been the hardest part? Is it, is it changing mindsets? Is it changing tools? Is it changing process? Like, where is this really spiking? And maybe which part has been surprisingly spiky in terms of difficulty?
So, it's a bit of all of the above, of course. And like I said, thinking about it as an entire system, what is technology versus what is operating model, is a really interesting thing to try and really pare it back to first principles. In terms of the hardest thing, it's because we are needing to make some moves now, that creates the pressure of time on a topic which is just straightforwardly complex. And you the reality is you do start in a place. We start with a bunch of existing procedures, existing processes, even existing skill sets and mindsets. So then to do a really big shift forward, that you need to like run those 2 things at the same time, very much like the SOC modernization program that we run.
Yeah.
Like we're having to build new, run existing, and then work out how you jump across when you're ready. And we're doing an equivalent Right now when we think about identity access management modernization alongside getting ready for agentic AI.
So you're not busy at all. You have lots of time to come on podcasts.
I love it.
Indeed.
Yeah, it's never boring.
So I want to go back to the SOC for a minute and talk about how you're using AI there. How is AI adoption going for your security program? Where are you seeing value? How are you measuring that value? Let's start there and we'll dig in more.
Yeah, there's a couple of ways that AI is being applied. And some of it is like native, native AI that we're consuming from your good selves. Oh, and then— Exactly. And then we're building a bunch of stuff on top of that as well.
Tell me about what you're building, because I talk about my stuff all the time on the show, but I want to hear what people are doing.
So, and I'll just give a bit of a context point. I think you probably have heard this data point before. In our preexisting security operations center, we were generating in the region of 250 to 300 alarms every 24 hours that got worked by humans. And then when we fast forward to the other side of the transformation, it's now fewer than 10, fewer than 10 alarms a day.
Fewer than 10 alerts per day in Google SecOps?
Yeah, correct.
Wild.
Getting worked by humans is the thing.
Okay. Wild.
Exactly. So, massive shift. So, what does that represent? You've hugely cleaned up what generates an alarm, and now when it fires, it's interesting. And I'll come back to, I think you've had long conversations before about what you do with that human time further up the value chain. Proactive work, threat hunting.
All the good stuff.
Then when we add in the AI opportunity, we have a triage agent that we're just testing and seeing how that works, giving it like half the alarms a day to work on. And that's going pretty well. Looks pretty effective, generally speaking. Not perfect, but actually can make a contribution, releasing more human time to do more proactive stuff. And then in terms of the stuff we're building, so the triage agent is one that we consume. Stuff that we're building, we're looking at a few things. Threat hunting agent, for example. How do we take all of the intelligence we've got about threats outside and then all of the intelligence we've got about LBG, combine those things so that a threat hunting agent can really give us a leg up in terms of things to pay attention to and to explore? And then more on a functional basis, also building out an SRE agent to manage the pipelines of the data that gets ingested into the SOC.
Oh, that's cool. Say more about that because I feel like users so often get, you know, lots of thinking about detection agents, a lot of thinking about triage agents. But tell me about the SRE agent because that sounds fun.
Yeah, well, I mean, firstly, it's quite early days, but the concept is—
Yeah, it's all early days.
Yeah, exactly. The concept is to try and identify where we might have a problem with a feed, a pipeline. And that's obviously something that the sooner you know about it, the sooner that you can address it. But then working out how the agent might be able to actually take steps to address that before a human even knows that something's gone wrong is the concept. So making steps, and of course, it's quite a big ecosystem. So we're just trying to chip away at what we can safely give an agent to look after. What's the art of the possible, starting at the more benign end of the profile and then building from there?
So I never thought I would ask so many questions about vulnerability management. I thought VM was the most boring thing on the planet. But Mythos has gotten me and a lot of other people interested in it for the first time in 20 years. And so, first, has your board heard about this? Has your team heard about this? Yes, that looks like a yes. And then, what are you doing about it? Are you going to be able to patch faster? What does the future hold for VM at LBG?
Yes.
That's fun to say. It sounds like LBJ, but LBG.
It's cool. Exactly. So, yes, there's lots of focus on it. And You know, the key thing I would say is that Mythos itself is a data point on a trend.
Yeah.
So something that we've talked about in our team, the models and the tools that we have today, they're the most powerful they've ever been. They're the least powerful they'll ever be again. So really what we need to pay attention to is this shift that's happening and what comes next. And there's a couple of things in that regard. I think exposure management becomes an absolutely critical capability. We've always had a funnel with loads of stuff at the top. And fewer things at the bottom that we really need to pay attention to and fix fast because they're exploitable. You know, an RCE on an internet-exposed asset is clearly a problem.
Yeah, that's bad news bears.
Exactly. And today when we think about exposure management, increasingly we're able to illuminate an attack path. So an attacker can do these 3 or 4 things in sequence because of a set of gaps. So exposure management is critical. It remains critical. Now we're going to have even more things, you know, 10x, 100x more things at the top of the funnel, and we're going to have more things at the bottom. But the things at the bottom of the funnel will remain a subset.
Mm-hmm.
It's critical that we're efficient identifying things that we need to do first. Next thing I would say is remediation velocity is key. We talk about patching velocity. Well, it's patching plus, plus, plus. There's a set of things that you, you might be able to remediate a problem through a non-patching method within minutes, and then the patching takes n hours, even n days on some tech debt.
It's very easy to fix things that way. You can always unplug them.
Exactly. But I'm thinking about, you know, it might be on a preventative control, adding a new policy or changing numbers, you know. And I guess the point I'm getting to is that you want all of your security capabilities to be operating at or near machine speed. I'm really glad we did SOC mod last year. We can now define and implement a new detection analytic into production, you know, at real pace when we need to.
Yeah.
So obviously, that's a detective control, but if you've got every single one of your security capabilities that are able to operate at that level, at that kind of speed, then you're well set in this era of AI-identified vulnerabilities to stay in front of things. Because the reality is, we all need to massively shift our patching velocity That's not going to be easy. It's not a magic wand. We're not going to be able to solve that in the coming weeks. So all of the other things need to be there in concert.
So Anton and I have been going back and forth about patching velocity for a couple of weeks now. Actually started in the room where you and I met, this conversation. Do you see enterprise patching speed as a sound barrier where, you know, with sufficient courage, Chuck Yeager can go faster than it? And, you know, new engineering like jet engines, propellers, Or do you see it like the speed of light, where only Captains Kirk and Picard can go faster than that?
Well, let's say it's a sound barrier. And yet, if we think about automated patching, evergreening in a microservices architecture, even starting to leverage agentic AI to achieve really brilliant velocity, and if we take that cluster of things as, like, the future, the future's here, it's just not evenly distributed. So even if we can get to really good on the leading edge, there's going to be some stuff behind it. There's going to be a tail. And that kind of goes back to what I was saying before, which is like, I definitely believe this thing is a forcing function. It's going to get us there. It's going to get us there much quicker than we otherwise would have done. But to trade through from where we start to where we need to be, we're going to have to use a range of those security capabilities in the meantime.
What about your mainframes? Do you still have mainframes?
Of course.
Are you going to patch your mainframes faster? Like, what's the plan there? Like, the real legacy stuff, what's the thinking?
Yes. So, like, the short answer is, even with a mainframe, you can use DevOps practices, and you can definitely get to, like, a much higher patching velocity. But it connects to the point I said about exposure management, which is, we need to make sure we're focused on the right stuff in the right order. So, everything just needs to be have a higher patching velocity now. That's definitely true. And yet, if we, you know, said, like, the problem we're solving is how do you patch a mainframe N times per given period, you potentially would be, like, using up quite a lot of time, effort, money, and goodwill on something that was not the most critical point of needing velocity in your entire stack, especially when you think about an attack path. So like, this comes back to why is exposure management critical? Because with the best will in the world, you know, we have to do the first thing and then the second thing and then the third thing. Let's make sure we do it in the right order.
That is such a sensible answer. Like, I have a lot of conversations where I come away scratching my head, but this one feels very, very sane and sensible. You've got me thinking about funnels and how we adjust the shapes of funnels now. So I'm going to go away and think a lot about this episode. Unfortunately, we're getting to the point in the episode where I have to ask our traditional closing questions because we're coming up on our time. One, do you have advice for other chief security officers thinking about these kind of transformation programs? Like, should they do IAM first? Should they do SOC first? Actually, bonus question before I get to my closing questions. What comes after IAM mod for you? What's the next thing you're going to modernize?
So we're modernizing everything. And your point on the sequence is really key. And I think, like this one, it's about the organization. To be really deliberate and planful and strategic is one thing, but then sometimes you've got the crocodile nearest the canoe, and something just needs dealing with right away.
Is that a figure of speech? I've never seen a crocodile near a canoe.
Lucky you.
I love it. Yes, lucky me indeed. Okay, so sometimes something comes up.
Yeah, so something comes up, and then there's something that comes up, and what does that reveal? And then you can bat the crocodile away, or you can you go, actually, no, this thing is going to keep coming at me if I don't deal with it, and then take that moment to really drive the transformation. So, I think it's a balance of thinking about what are the 5 or 6 things that you really need to transform over time, and then a bit of pragmatism regarding the order in which you do them is certainly where we arrived at. And I think the other point I'd make is, like, transformation's a choice. It is a choice, and it's choosing to take the harder path, to get much further forward. And that's something that I always remind myself, because obviously there are some confronting moments when you're taking on something really big, but you've got to remind yourself, we've chosen to take the harder path to get much further forward. And that's what I would say about transformation. It's the choice. It's a choice you have to take to get to really good.
And so, when you make that choice and you decide to do the hard thing, not because you thought it would be easy, but because you knew it would be hard and worthwhile, What's your advice to other CISOs and CSOs on ordering? Should they start with IAM? Should they start with SOC? Should they start with exposure management, VM management? Like, what would you say? How should they sequence that, or does it just depend?
So, I do think it depends. But then if you think about what are the set of really fundamental capabilities, then those are the ones that you need to go after sooner than later. So, I do think identity and access is key. Identity at the foundation of the security model, You think about the security operations center, that is really, that's in the middle of the security model. So that's a really important thing to go after. Thinking about then, like, wider hygiene factors. So actually, I think everybody now should be moving beyond vulnerability management to think about posture and exposure. And that is therefore, like, when we talk about the era we're now in, it's definitely a really big part of it. So yeah, I would say those, and then, like, you can't get away from data security. With quantum around the corner, crypto agility with data security, thinking about data security posture management as something that we all need to be paying attention to. I think that's like the big one that will come next for us. And that's really, really hard to do well. So look forward to it.
Yeah. Quantum is a whole nother episode. Are you getting a lot of pressure on that from, from regulators? Is that a peer group pressure or just like you're seeing where Google and Cloudflare are at and you're like, okay, if those guys think it's real, we better get on it.
Yeah, there's definitely interest in it. And we believe, yeah, we believe it's real. We believe it's real. And it's something that we need to take every step to get in front of. And even if you took the quantum part out of the equation, crypto agility is an important thing just to reflect the reality of the threat landscape and AI-driven threats in particular. We just need to be better at, well, shortening the lifecycle of secrets, automating their swap out and things like that. So yeah, that's the world we live in now.
Okay. I love it. Matt, thank you so much for joining us today. This was an absolute delight.
Thank you for having me.
And now we are out of time. Thank you very much for listening and, of course, for subscribing. Please subscribe so you can get new episodes piping hot. And if you love our content, please drop us a review on your platform of choice.
You can find this podcast on YouTube, Apple Podcasts, Spotify, or wherever you get your podcasts. Also, you can find us on our website, cloud.withgoogle.com/cloudsecurity/podcasts. You can argue with us on the Google Cloud Security Community site, googlecloudcommunity.com.
You can follow us on X, x.com/cloudsecpodcast. Tweet at us, email us, argue with us. And if we like or hate what we hear, we can invite you to the next episode.
See you on the next episode of the Cloud Security Podcast by Google.
Security.
More from Anton


EP289 Software Engineering vs. Software Craft: How Google Scalably Eliminates Classes of Vulnerabilities


EP288 CISO Tested, Board Approved: Cloud Resilience with General Mills CISO Noah Korba


EP287: Creating Trust at Global Scale with Local AI: Reken-ing with Shuman Ghosemajumder


EP286 Building an AI-pilled, solo vibe-coded, Clickhouse-based SIEM with Dan Lussier


EP285 Scaling Lessons from Leading the NSA to Defending the World with Morgan Adamski


EP283: How Google Cloud CISO Chris Betz Uses LLMs to Defend Billions of Users from Vulnerablities


EP282: Debating Coupled or Decoupled SIEM with Alex Hurtado and Christopher Witter


EP280 Hyperscaling Cloud Security: Wiz Joins the Cloud Security Podcast by Google