The security session at Google Cloud Summit in London on Wednesday opened with a reframing that I have not been able to shake since. For most of my career, regulation in financial services has been about keeping data safe. Don't lose it, don't leak it, don't let the wrong people see it. Every framework I have worked under has had data protection at its heart. The speaker's argument was that this framing is now out of date. The threat has moved from data loss to disruption. The question is no longer "did they take our data" but "did they stop our business from working."
The example that landed hardest was not a bank at all. A vendor providing blood test services was attacked, the NHS could not process blood tests as a result, and a person died. Nobody attacked the hospital. They attacked something several steps up the supply chain, and the consequences arrived anyway. This is the part most continuity planning quietly ignores. We plan for our own systems failing. We rarely plan for a supplier we have barely heard of failing in a way that takes us down with it. And the uncomfortable detail underneath all of it: most business continuity plans begin with "send an email to notify everyone," and a serious incident takes out your ability to send that email before you have even reached step two.
The frontier AI angle was genuinely sobering. These models are now good at finding vulnerabilities in code, which sounds like a defensive win until you remember the attackers have the same models. A great deal of the world's code is poor quality, written with no real incentive for security, and the comfortable assumption that the easy vulnerabilities have already been found no longer holds. One experiment chained exploits together into a thirty-two step attack plan that cost around sixty-five dollars to run. Ransomware is now sold as a service, with established criminal ecosystems behind it. The economics of attacking you have collapsed in exactly the wrong direction. Much of the practical defensive advice that followed was unglamorous and correct. Get rid of legacy that is beyond support. Fix the bugs you already know about. Stop using passwords and move to passkeys. None of it is new. All of it still goes undone.
The honest question underneath the whole session was about agents. We are heading towards a world where security agents spot issues and fix them, where they triage the thousand alerts a day that no human team can sensibly process, most of which are false. That is obviously useful, and for a stretched security team it is close to irresistible. But your best security agents will, by necessity, hold the highest privileges in the building. They will be the most powerful things on your network. Are we ready to hand security decisions to an agent? And what happens when the attackers are running their own agents against yours, because they will be. Nobody in the room had a comfortable answer, and I respected them for not pretending otherwise. This is going to be a contest of daily capabilities, each side's agents probing the other's, and it is one you have to actually turn up for.
The most useful part was the planning advice, drawn from organisations that have lived through the worst. Breaches are inevitable, so design for them. The retailers who came through recent attacks well were the ones whose systems were properly segregated, so the tills kept working even when other things did not. Good design contains the blast radius. Beyond that, have a plan to operate for four weeks without your technology, which in our world is roughly one monthly business cycle, and know how you would rebuild at scale rather than improvising it during the crisis. The benchmark a board or a regulator will eventually hold you to is blunt: twenty-four hours to respond, forty-eight to fix, and what exactly did you do about all this in the last three years.
If that sounds overwhelming, the advice was to start anyway and start small. Understand your supply base, because you cannot defend what you have not mapped. Get the defensive fundamentals right before worrying about what more you might do with agents. And work out, in advance and in detail, how you would manage a crisis and rebuild your technology at the same time, because doing both at once is the actual test. You cannot do everything that is needed on day one. You can invoke a plan, and then go a level deeper, and then a level deeper again. The organisations that cope are simply the ones that had a plan at all.
The reassuring footnote came from a session at a separate cyber conference, where the chief executive of a company that had been breached described it as the biggest trauma of their technology career, and yet concluded that the public mostly forgives. They forgive a breach if you handle it like an adult. What they remember is the human impact and how you responded to it, not the bare fact that you were hit. Which is worth holding onto, because if breaches really are inevitable, then how you respond is the only part still under your control.
About Richard
Richard Forss is the CTO of EXANTE, where he leads the evolution of the firm’s cutting-edge proprietary trading platform. With 30+ years in fintech, Richard has built tech for hedge funds, crypto brokerages, asset managers, and global banks — including leadership roles at Crypto Finance (Deutsche Börse Group), Covario AG, Argentière Capital, Deutsche Bank, and UBS.
Based in Switzerland, he’s a strategic technologist with deep expertise in trading infrastructure, crypto, and AI. Richard is shaping the future of financial technology — and is a sought-after voice on innovation in capital markets.
