Operational resilience isn't delivering: two shifts firms can't ignore

Earlier this year I sat down with John Licata from the ServiceNow Futures team. In the roundtables and client conversations I've had since, the same challenge comes up every time — and it's remarkably consistent, whatever the firm's size or maturity.

How do you shift operational resilience from a compliance exercise to something you actually trust? Allowing you to sleep at night, confident that you're resilient, and confident that if something does go wrong you can respond and recover without customers feeling it.

There is a lot of work to do — and the numbers back that up.

Operational resilience has been a major focus in UK financial services for around eight years. We've made real progress — incident reporting alone has improved enormously. And yet the regulator recorded 157 incidents across just nine firms over a two-year period. Technology incidents are costing the UK economy £3.7 billion a year, a fivefold increase in six years.

So, we've spent the money. We've built the frameworks. And the incidents keep coming.

The root cause is a mindset, not a control gap

Firms have not yet put operational resilience on a par with financial resilience. It's still treated as a compliance exercise — evidence produced, boxes ticked, spreadsheets maintained. Nobody would run financial resilience that way, and nobody would accept the results if they did.

Getting genuinely resilient means changing two things:

1. Get honest about what actually matters to customers.

Not what an internal model tells you is important — what the customer would actually feel the loss of. The most useful lens I've seen here is the minimum viable firm: in a prolonged disruption, what do we need to keep running? Which services would we have to stop? What is the true customer impact of stopping them? Those questions are uncomfortable to sit through, which is precisely why they work. They narrow a sprawling, unfocusable problem down to the handful of things worth defending properly.

2. Accept that spreadsheets cannot carry this.

Operational resilience is too broad and too interconnected. You need a platform that holds the customer outcome, the business processes behind it, the technology enabling those processes, the third parties delivering them, the locations they run from — and crucially, the dependencies between all of it. Without that spine, you cannot answer the only question that matters during an incident: what does this actually affect?

Where AI genuinely changes the game

This is the part I get most excited about, and it's not hypothetical — we're building it with clients now.

Take change, one of the top three causes of incidents alongside cyber and third parties. You automate the controls: every change is tested before promotion, every change has a back-out plan. An agent reads those results. Fine, useful. But then it reads across — are there open incidents on that technology? Known vulnerabilities? And wider still: is the user population affected by this change already absorbing several others this quarter?

That's the shift from reporting on what happened to spotting what's about to.

Scenario testing is moving the same way. We've gone from tabletop exercises to agents ingesting internal data — incidents, vulnerabilities, changes — alongside external signals like geopolitical events and weather, and defining scenarios that are actually relevant to your firm. Then Monte Carlo simulation gives you the range of outcomes rather than one static answer. And then there's chaos testing, where an agent learns how your infrastructure behaves in a steady state and starts asking what happens when something degrades.

The reset

We need to move away from a compliance mindset towards genuinely building capability — focusing on what's truly important, with executives actively involved rather than reviewing a paper. AI gives us a real opportunity to shift the dial and stop customers suffering intolerable harm.