What would you switch off first during a cyber incident?
Something suspicious is spreading across the network.
Users are reporting unusual login prompts. A server is making connections nobody recognises. Files are beginning to disappear from a shared drive.
The technical team wants to contain it, but doing so could mean disabling remote access, taking email offline or interrupting a service customers rely on.
Who makes that decision?
And how long does everyone spend discussing it while the incident continues?
Containment comes with consequences
Most incident response plans include a containment stage. Isolate affected devices. Disable compromised accounts. Block malicious traffic. Stop the problem spreading.
All perfectly sensible.
The difficult part is that containment can cause disruption of its own.
Disabling one user account is unlikely to bring the business to a halt. Taking a production system offline is different. It could stop orders, affect customers or leave employees unable to work.
There is rarely a completely safe choice.
Act too slowly and an attacker may gain more access, steal more information or cause greater damage. Act too quickly, without understanding the dependencies, and the business may create an avoidable outage or lose useful evidence.
The decision is not simply technical. It is a judgement between two forms of risk.
Waiting is still a decision
Businesses are understandably reluctant to switch off important systems based on an alert that has not been fully investigated.
What if it is a false positive? What if the disruption costs more than the incident? What if the affected system is essential?
Those are reasonable questions, but certainty is a luxury you may not have.
During a genuine incident, the evidence is often incomplete. The team might know something is wrong without yet knowing the cause, the extent of the compromise or which systems can still be trusted.
Waiting for the complete picture can feel cautious. In reality, it may give the problem more time to spread.
The better question is not, “Are we absolutely certain?”
It is, “Do we know enough to justify a proportionate containment action?”
That action might not mean shutting down the entire business. It could mean isolating one device, suspending a supplier’s remote access, disabling a compromised account or restricting traffic between parts of the network.
Good containment is often selective. That is only possible if the business understands how its systems connect and has the technical ability to separate them.
Who has the authority?
Imagine suspicious activity is detected at 8pm on a Friday.
The IT manager believes remote access should be disabled immediately. Doing so will affect employees working over the weekend and may interrupt a customer-facing service.
Can they make that decision?
Do they need approval from a director? Which director? What happens if that person cannot be reached? Does an external IT or security provider have permission to act, or can it only recommend what to do?
An incident response document might list everyone’s contact details and responsibilities. That does not necessarily give anyone the authority to make a difficult call.
The NCSC’s incident guidance warns that organisations may need to take operationally critical systems offline. People therefore need to understand what authority they have in advance, including outside normal working hours.
If the answer during an incident is “we need to find someone who can approve that”, the plan is incomplete.
Decide before the incident
Nobody can prepare for every possible scenario. What businesses can do is agree the principles that will guide the decision.
For each critical service, establish:
- What would happen if it became unavailable?
- What other systems depend on it?
- How quickly could it be isolated?
- Could the business continue in a reduced or manual form?
- Who can authorise the action?
- Who has the access and knowledge to carry it out?
- How would employees and customers be informed?
This does not need to become a hundred-page playbook. A short decision table covering the most important systems may be far more useful.
Email is a good example. Taking it offline could disrupt communication across the business. Leaving a compromised email environment running could allow an attacker to monitor conversations, reset passwords, impersonate employees or interfere with the response.
There is no answer that works in every situation. What matters is that the organisation has considered the decision before it has to make it under pressure.
Test the decision, not just the document
A tabletop exercise should do more than talk through the stages of an incident response plan.
Give the decision-makers an uncomfortable but realistic situation:
We have signs that an attacker may be moving through the network. We cannot yet confirm how far they have got. Disabling remote access will affect operations, but leaving it active may allow the attacker to continue. You have ten minutes to decide.
Who asks for more information? Who gives the final approval? What happens if the usual decision-maker is unavailable? Can the technical team implement the decision safely?
That discussion is likely to reveal more than another review of the written plan.
The purpose is not to identify one system that should always be switched off first. There is no universal answer.
It is to make sure that when containment becomes necessary, the business knows who can make the call, what will guide them and how the decision will be carried out.
Because during a cyber incident, the most expensive delay may not be technical.
It may be waiting for someone to say yes.
If you are unsure how those decisions would be made in your organisation, a practical incident exercise is a good place to find out—before the situation is real.