The Organisation Moves Slower
Than the Attack

The previous newsletter issue argued that resilience is now judged by what an organisation can still govern when prevention has been bypassed, certainty is incomplete, and pressure is already moving.

This newsletter #7, issue takes that question into the first live containment window. It asks where governability often begins to fail: not because no signal appeared, and not because nobody cared, but because the organisation had not yet agreed what may be changed when the signal is credible and the evidence is still incomplete.

A mature escalation path can move information towards senior leadership, yet it does not automatically create the authority to act. The question for executive teams is therefore sharper than speed alone: when a credible sign of malicious movement appears, which containment move is already authorised, by whom, and within what limits?

Late in the evening, a security analyst sees behaviour that should not be there. A legitimate account is touching systems it does not normally use. Nothing has failed. Production is still running, patients or customers are still being served, and the evidence is not yet complete.

Restricting the account may interrupt an important service. Leaving it alone may give an intruder the route they need. The analyst escalates. The security lead joins. Operations is called. Someone asks whether the account belongs to a supplier, whether isolation will affect a clinical workflow, payment run or production process, and who may accept that disruption.

Those questions are not bureaucratic noise. They are legitimate questions. They exist because containment is rarely a clean technical choice. A first move may protect the organisation, but it may also create operational friction, affect evidence preservation, disrupt a supplier dependency or force a critical workflow into degraded mode.

This is how an organisation can be observant, responsible and orderly - and still move more slowly than the attack. The weakness is rarely a complete absence of procedure. More often, the procedure can describe who must be informed, but cannot produce a bounded first move while the facts are still forming.

Most incident processes are designed around escalation. An alert becomes a ticket. The ticket reaches an incident lead. Technical findings are translated for operations, legal counsel or an executive decision-maker. As the possible impact grows, more people enter the conversation. The organisation is doing what it was told to do: seeking context, protecting continuity and avoiding an impulsive response.

Yet escalation and intervention are different capabilities. Escalation moves information. Intervention changes what the attacker can still reach. A governable organisation needs both, but they do not necessarily move at the same speed.

The avoidable delay begins when authority, impact and acceptable disruption are negotiated for the first time inside the incident. If nobody has established which temporary friction is acceptable, which services must be protected, which evidence must survive and which actions may be taken on provisional evidence, the response team must design its authority while it is trying to use it.

Attack speed is not a universal countdown. No benchmark can tell a board exactly how long its own organisation has during a specific incident. But current threat telemetry does expose a serious mismatch between adversary movement and institutional decision-making.

CrowdStrike reports in its 2026 Global Threat Report that the average eCrime breakout time observed across 2025 fell to 29 minutes, with the fastest observed breakout occurring in 27 seconds. Those figures should not be treated as a universal deadline. They should be treated as a warning that an approval path measured in meetings, callbacks and handovers may be operating on the wrong clock.

The important interval often begins before ransomware is visible and before the organisation can name the full incident. It begins when a credible signal suggests that a trusted account, supplier route, workload, data path or device may no longer be safe. At that point, a limited restriction can still reduce the attacker's options. Later, the same action may be too narrow because the route has already been used elsewhere.

This is why detection quality alone cannot answer the resilience question. A high-fidelity alert that waits for permission is still waiting. A well-written playbook that ends with "escalate to management" may be administratively correct while leaving the most consequential decision unresolved.

Several recent publications from us approached this same problem from different angles. The first alert is not necessarily the boundary of the incident. A green dashboard does not prove that data has remained under control. One breach can become everyone's problem when trust and dependency pathways cannot be restricted fast enough.

Together, those observations point to a less comfortable conclusion: visibility has operational value only when it can change the attacker's remaining freedom of movement.

That conversion requires interpretation, authority and an executable action. Remove any one of the three and the organisation may remain informed without becoming safer. The signal may be seen but misunderstood. It may be understood but held below an approval threshold. Permission may be granted, yet the account, connection, device, data route or workload cannot be restricted without a broad and uncertain shutdown.

This is governance latency: the time between credible recognition and a proportionate change in the environment. It is produced by decision rights, technical architecture, operational dependencies and the organisation's willingness to define acceptable impact before pressure arrives.

The Dutch Cybersecurity Act, which entered into force on 15 August 2026, makes the NIS2 governance direction concrete in the Netherlands. In-scope organisations face obligations around risk-management measures, incident reporting, registration and management responsibility.

At European level, Article 23 of NIS2 establishes a staged notification process for essential and important entities, including an early warning without undue delay and, in any event, within 24 hours of becoming aware of a significant incident.

This matters, but the distinction should remain clear. Reporting an incident and controlling one are not the same task. A notification route can tell an organisation when and where to report. It cannot decide which account may be restricted tonight, which supplier connection can be suspended safely, which data path should be paused or which operational consequence leadership has already agreed to accept.

Boards therefore need more than assurance that an incident plan exists. They need to know whether the plan can authorise a real intervention while uncertainty is still present. Governance becomes operational when a team can point to a defined trigger, a named decision owner, a permitted action and a boundary beyond which escalation is mandatory.

Pre-agreed authority is sometimes mistaken for permission to act aggressively or autonomously. That would simply replace one risk with another. The objective is a bounded first move: proportionate to the available evidence, reversible where possible, protective of critical services, conscious of evidence preservation and connected to a clear escalation path.

A useful mandate might allow a response team to suspend a suspect privileged session without disabling an entire identity domain; isolate one endpoint while preserving forensic data; restrict a supplier route to an agreed minimum; pause a high-risk data flow; or protect a sensitive virtual environment while ownership is confirmed.

The technical option will vary by sector and architecture. The governing principle is consistent: reduce the attacker's freedom without creating an unexamined operational failure of your own.

That principle depends on preparation outside the incident. Leaders, operators and security teams need to agree where temporary friction is acceptable, where even a brief interruption could cause harm, and who has authority to balance those consequences. The point is not to remove judgement. It is to stop the organisation from rebuilding the same judgement pathway each time a credible signal appears.

A tabletop exercise often tests whether people know the plan. A containment pressure test should go further and ask whether the plan produces an action. Take one plausible, incomplete signal - a privileged account behaving abnormally, encryption beginning on a file share, an unmanaged supplier identity, unusual access to a sensitive repository, or suspicious movement near a virtual environment - and follow it until something in the environment actually changes.

Five questions usually reveal where the route slows:

1. What evidence is sufficient to trigger a limited containment action before the incident is fully classified?
2. Who may authorise that action at 02:00, and who can act if that person is unavailable?
3. Which identities, supplier routes, data stores, endpoints or virtual systems can be restricted without a broad shutdown?
4. Which operational impact has already been accepted, and which services require a higher decision threshold?
5. What evidence, rollback path and post-action review must be preserved?

If this exercise ends with a message, a meeting or a search for the right executive, it has found something valuable: the organisation's first containment move is still an escalation. That is a governance gap even when every participant followed the procedure correctly.

At the S10 Group, we work alongside existing security and operational capabilities to make that first move more governable. This begins with the environment an organisation already has: its detection stack, identities, dependencies, decision rights and continuity constraints.

The aim is to expose where visibility currently stops, then define how a credible signal can become a controlled intervention without demanding certainty that the incident cannot yet provide.

Technology is part of that answer because authority that cannot be executed safely is authority on paper. Yet tooling alone does not resolve the issue. The containment options, operating boundaries and escalation rules must be designed together. A team should know both what it is technically able to restrict and what it is organisationally permitted to change.

Our platform fits within that operational layer. When prevention has been bypassed, it helps organisations detect and terminate lateral movement after entry, interrupt malicious behaviour before it spreads, prevent data theft while the incident is active, protect VMware/vSphere/ESXi environments, and stop ransomware encryption before a broad shutdown becomes the only remaining move.

Our platform is not the protagonist of this newsletter. The protagonist is the organisation's ability to turn visibility into a bounded act of control while the situation is still moving.

The practical starting point is small: choose one high-consequence route and trace the path from signal to authorised action. Measure the time, record each handover and identify the point at which your organisation begins discussing permission rather than exercising it. Then decide, under calmer conditions, what a bounded first move should be.

This governance exercise is separate from the focused technical assessment described below.

For organisations with more than 250 employees that want a practical comparison, we can run a free ransomware resilience assessment remotely in a controlled sandbox environment, with your existing security controls left active.

Our assessment has a deliberately narrow scope. It examines one specific stage: what happens once ransomware begins encrypting files. We use several different ransomware variants to run controlled encryption scenarios and observe how your current security stack responds. We then repeat the same scenarios with our ransomware-containment layer enabled, while keeping your existing controls active, and compare the outcomes. This provides a direct side-by-side comparison of what your current security stack does on its own and what changes when our additional containment layer is active.

The assessment does not test lateral-movement detection, the prevention of data theft or exfiltration, the capabilities of Server Intrusion Protection, or the protection of VMware/vSphere/ESXi environments. Nor does it validate your wider incident-response, governance or business-continuity capabilities. These broader platform capabilities are explained separately during the accompanying technical presentation and discussion.

If this focused comparison would be relevant for your team, please feel free to contact me:

The next issue in The Governable Organisation series will move from governance latency to the way trust, identity and dependency shape the blast radius: why mature security stacks can still fail under pressure when trusted pathways remain too broad, too persistent or too difficult to restrict safely.

The issue is not whether the organisation can see the attack. It is whether seeing the attack changes what the attacker can still do.