Follow

Keep up to date with the latest Stelia advancements

By pressing the Subscribe button, you confirm that you have read and are agreeing to our Privacy Policy and Terms of Use

When a breach hits, it won’t expose your policies. It’ll expose your governance.

Why recovery from a breach isn’t determined by the response. It’s determined by the groundwork – and whether governance was built in from the start.

Ask a room full of GCs what keeps them up at night these days, and the answer invariably includes some combination of cyber governance and security. It’s no wonder either – these are risks that can cause such monetary, reputational and (sometimes!) physical pain as to be of real, existential concern to a business. If you can’t secure your infrastructure, you are accepting that you, and possibly your customers, could be taken out at any time by any number of bad actors.

Earlier this month, I joined Tom Draper, Laura Brodahl, and Kit Lewin on stage at Scaleup GC 2026 to talk about what separates the organisations that recover effectively from a cyber breach from those that don’t.

The answer we kept returning to is rarely the response itself. It’s the groundwork beforehand and the difficult choices that had to be made, often long before any threat was visible, to ensure that recovery was even possible.

We are all conscious that the groundwork is only getting harder. The threat landscape is shifting in ways that make the familiar risk frameworks feel wholly inadequate. Attacks today are no longer exclusively human-motivated; we are increasingly facing machine-led threats, meaning we now need an understanding of machine logic as well as human psychology. We have created autonomous systems capable of reaching across applications they shouldn’t have access to, rewriting code in ways that are genuinely difficult for us to interpret, and operating on a form of logic that challenges our existing categories entirely.

These are complicated threats that we’re only beginning to get our heads around, or even uncover full stop – and they aren’t just security problems. There is genuine confusion across the industry about how to even describe certain system behaviours; what we mean by “intelligence”, and where accountability sits when models act unexpectedly. For legal and regulatory teams, the implication is that you are being asked to govern systems that the industry itself hasn’t fully come to terms with. Combine this with human-led attacks that are more sophisticated than ever, and agentic AI rapidly widening the attack surface, and the risk environment is genuinely without precedent.

When a breach hits in this landscape, legal teams become the focal point – for the board, for investors, for regulators – all at once. And the ability to lead through that moment depends entirely on the systems teams already have in place.

When a breach hits

In the immediate term, a few things matter above everything else:

  • Reach for your “who does what” emergency plan and notify your compliance and technical leads simultaneously – don’t wait for scope to be confirmed. Depending on your organisation, you may also have communications leads you want to put on notice; they can assist in liaising with essential stakeholders (investors, customers, suppliers) when the time is right.
  • Your emergency plan should also contain external contacts you can bring in to support in those critical first hours. A decent cyber insurer, for example, should have crisis support loaded into their repertoire, with crisis comms, regulatory support (e.g., for privacy breaches), and sometimes even ransomware decision support available – often essential to avoid accidentally breaching sanctions or terrorism laws. You may also have external counsel who can assist with regulatory comms. Understanding what they offer ahead of time will help enormously.
  • Contain before you fix – the first hours are for isolation, mitigation and documentation, not necessarily resolution. A good GC holds space for their board to ask the questions, rather than allowing decision-making to run ahead in a panic. Bear in mind that doing nothing is always an option, and sometimes this is exactly what your technical lead will advocate. If malware/malicious code was timed to attack but had otherwise been sitting undetected on your system for a while beforehand, the last thing you want is to revert to system backups, which restart the clock on that breach happening again.
  • And on that note, be comfortable saying you don’t know yet. Too many business cultures value incorrect confidence over honest uncertainty, and that is perilous in these situations, particularly given the widening categories of attack we’re now anticipating.
  • Document everything from the moment of discovery – decisions, actions, timelines – you will be asked to account for all of it.

But these actions are only executable if the conditions for them already exist. Which brings us to the real answer.

Your problem isn’t the response. It’s visibility

What I see most consistently in organisations that struggle in the face of a breach is not a failure of intent, but a failure of visibility. Legal and compliance teams are being asked to advise on risks they cannot actually see, and it comes down to the state of the underlying stack.

The fragmented stacks teams have been left to work with were never built for the complexities that AI capabilities operating across distributed, real-world environments bring. Data, decisions, and processes spread across disconnected tools with no unified line of sight make it almost impossible to govern end-to-end – or to answer the questions that matter when a crisis hits:

  1. Who controls what
  2. Who can isolate which systems
  3. Where do the relevant policies live
  4. Who needs to be called first

What began as a technical problem has become a serious governance liability. And when a crisis lands, it lands squarely in the lap of legal.

Governance as infrastructure

The organisations that recover well are those where governance was never a response framework – it was infrastructure, built long before any threat was visible. That means legal and regulatory teams being genuinely close to their technical counterparts. The GC who has a working relationship with their CTO is the one who knows by proxy what can actually be isolated, where the real vulnerabilities lie, and whether the policies they think exist are actually embedded in the systems they’re supposed to govern.

For enterprises running AI at scale, this has to be built into the infrastructure itself. Governance cannot sit on top of a fragmented stack; it has to run through every layer, from access controls and model routing to auditability and observability, end-to-end.

Stelia AI OS was designed on exactly this principle. It replaces fragmented tooling with a unified, full-stack operating system that gives legal and compliance teams the visibility they need, and engineering teams the control they require. Fully governed by design and auditable at every layer.

The legal and regulatory teams that lead best through the next breaches won’t be those who respond fastest in the moment. They will be the ones who recognised, long before the threat arrived, that governance was never something to reach for in a crisis. It was something to build into the foundation, something to trust it when it mattered most.

Stelia AI OS