The first 24 hours after a cyber attack are when pressure is highest and when organisations are most likely to make decisions they later regret. In the rush to restore services, it’s easy to take actions that unintentionally increase the impact: wiping evidence, restoring too soon, confusing internal reporting, or creating regulatory and insurance complications.
The challenge is that there is no single “correct” playbook that fits every organisation. Your response needs to reflect your environment, your risk appetite, your third parties, and the rules you operate under.
Compliance obligations and cyber insurance policies can also shape what you can do, when you must notify and how you preserve evidence. That’s why this article focuses on what not to do in the first 24 hours, looking at common mistakes that repeatedly turn containable incidents into prolonged crises.
Common mistakes in the first 24 hours
Large organisations often have strong technical capability, but even well-prepared teams can struggle in the first 24 hours of a live incident. The situation evolves quickly, decisions have to be made with incomplete information, and multiple stakeholders need answers at the same time. That combination can drive rushed actions, inconsistent messaging and missed steps, especially when the priority becomes “get systems back online” rather than “contain, understand and recover safely.”
Common mistakes in the first 24 hours include:
- Treating the incident as an IT issue only:
Cyber incidents quickly become wider business events involving customer impact, operational disruption, legal exposure, and reputational risk. When the response is framed as “an IT problem”, key stakeholders can be left out of early decisions leading to misaligned priorities.
- Failing to involve legal, risk and communications teams early enough:
Legal teams help protect privilege, shape regulatory notifications and manage contractual obligations. Risk teams can help quantify business impact and escalate appropriately. Communications teams can prepare controlled internal and external messaging. If these groups are brought in late, the organisation may create avoidable exposure such as inconsistent statements, missed notification windows or unnecessary admissions before facts are confirmed.
- Restoring systems before containment is validated:
“Getting systems back” is often treated as the main goal, but restoring too early can reintroduce malware, re-enable attacker access or destroy the opportunity to understand what actually happened. If containment hasn’t been confirmed (such as compromised accounts disabled, persistence mechanisms removed, and ingress routes closed) recovery activity can simply reset the clock on the attack.
- Deleting logs or rebuilding devices too quickly:
In the scramble to clean up, teams sometimes wipe endpoints, rebuild servers, or rotate systems without preserving forensic artefacts. That can remove the evidence needed to establish scope, timeline, root cause and data access. It can also weaken the organisation’s ability to demonstrate due diligence to regulators, customers, auditors or insurers.
- Making external statements before the facts are understood:
Early in an incident, information is incomplete and sometimes wrong. Public updates made too soon can later require retraction or correction, which can damage trust and increase scrutiny. Communications should be accurate, consistent and aligned to what is known / what is still being investigated, so the organisation does not inadvertently mislead stakeholders or create legal issues.
- Assuming backups are safe without checking:
Backups are not automatically “clean”. Attackers may have tampered with backup processes, compromised backup credentials or ensured malware is present in backed-up systems. If backups are restored without validation, organisations risk reinfecting their environment or discovering too late that backups are incomplete, inaccessible or not usable under time pressure.
- Underestimating supplier or third-party involvement:
Large organisations depend on cloud services, MSPs, SaaS platforms and specialist suppliers, any of which could be part of the incident path. If third-party connections, shared credentials, integrations or upstream outages aren’t assessed early, containment can fail. The incident may also trigger contractual notification requirements or require supplier cooperation to obtain logs and evidence quickly.
- Allowing multiple teams to work from different versions of the incident picture:
For example, one team may believe the attacker has been contained while another team is still seeing signs of active compromise. In other cases, a system may be viewed as safe to restore even though evidence is still being collected. Without a single source of truth and clear, shared updates on timelines, scope and actions, organisations can duplicate effort, miss key containment steps and deliver conflicting messages internally and externally.
- Not checking cyber insurance notification requirements:
Cyber insurance often includes strict conditions such as when you must notify, which incident response providers can be used, what approvals are needed and how evidence must be handled. If these requirements are missed in the first day, organisations can create friction at the worst possible time, potentially delaying support, complicating claims or creating disputes about coverage.
- Losing sight of board-level reporting and business impact:
Senior leadership needs a clear view of what is happening, what decisions are required and what the business impact is likely to be. If reporting focuses only on technical detail, leaders may miss key questions. For example, which services are affected, what data is involved, what the operational consequences are, and what the organisation’s risk position is. Early, structured reporting helps avoid delayed escalation and unclear accountability.
- Failing to assign clear decision rights:
During an incident, decisions must be made quickly. For example: isolate systems, shut down services, pay for external support, notify stakeholders or take systems offline. If decision rights are unclear, teams either wait too long for approval or take unilateral actions that conflict with business priorities. A defined incident command structure avoids paralysis and reduces conflicting actions.
The right response needs technical discipline and business coordination: a controlled approach to containment and evidence alongside clear leadership, communications, and decision-making.
What the British Library cyber attack teaches about response and recovery
The British Library cyber attack shows why incident response and long-term resilience need to be considered together.
The organisation experienced significant disruption, with online systems compromised, data stolen and services affected for months.
One of the clearest lessons is that response is not only about the first technical containment actions. It also depends on leadership escalation, crisis management, communication, recovery planning and the ability to rebuild safely.
As covered in Data Connect’s British Library cyber attack analysis, many organisations do have security controls in place, but incidents often reveal where risks were not fully understood, prioritised or tracked across the business.
That is why large organisations need to review not only whether they have cyber controls, but whether those controls are connected to operational resilience.
How to prepare before an attack happens
The best time to improve incident response is before an incident.
Large organisations should have all of the following in place, while smaller companies should prioritise the measures most relevant to their risk profile and resources:
- A tested incident response plan
- Defined escalation routes
- Clear executive ownership
- Current asset and supplier visibility
- Working backup and restoration processes
- Centralised logging and monitoring
- Strong priviledged access controls
- Cyber insurance and legal contacts confirmed
- Pre-approved communications processes
- A post-incident review process
- Regular cyber exercises involving senior leadership
- Clear board reporting for material cyber risks
Preparation reduces confusion when time matters.
Where vSOC Assure fits into incident readiness
vSOC Assure helps organisations understand where cyber risk exists before an incident happens and links those risks to five core areas of cyber resilience: Identify, Protect, Detect, Respond and Recover.
Through risk analysis, benchmarking, vCISO advisory and strategic roadmap planning, Data Connect helps leadership and IT teams identify the gaps that could increase the likelihood or impact of an attack.
This may include weaknesses in privileged access, monitoring coverage, supplier assurance, incident response planning, backup testing, vulnerability management or executive reporting.
The vSOC Connect Console then gives your organisation a clearer way to track remediation activity, monitor progress and maintain visibility across security improvement projects.
That visibility matters. When an incident occurs, organisations with clearer ownership, better risk understanding and stronger security governance are better placed to respond with confidence.
Read “No Regrets” Proactive Cyber Assurance: What Does This Mean?
Controlled response, safer recovery
The first 24 hours after a cyber attack should be controlled, documented and coordinated. The priority is not to make the incident disappear as quickly as possible. It is to understand what is happening, contain it properly, protect the business and recover safely.
If your organisation is unsure where cyber risk sits today, or whether your response plans are mature enough for a real incident, Data Connect can help you build a clearer and more measurable path forward.
Get in touch today to talk to Data Connect about cyber risk management and incident readiness.
