INCIDENT RESPONSE: What to Do in the First 24 Hours After a Data Breach

A CISO's Hour-by-Hour Playbook for Containment, Communication, and Business Continuity

At 2:00 a.m., a privileged account authenticates from an unfamiliar location. A core application server begins connecting to an unknown external IP. The SOC cannot yet confirm data theft, but customer records may be involved.

This is both a technical incident and a management problem. Someone must decide who is in charge, which systems can be isolated, how evidence will be preserved, and when legal, privacy, and executive teams need to be involved.

CrowdStrike's 2026 Global Threat Report found that the average eCrime breakout time, the period between initial access and lateral movement to another system, fell to 29 minutes in 2025. The fastest observed breakout took 27 seconds, and in one intrusion data exfiltration began within four minutes of initial access. These figures do not mean every incident follows the same pattern. They do show why basic command and containment decisions cannot wait for a complete investigation.

The first 24 hours do not determine the final outcome on their own, but early decisions can preserve or remove important options. Poorly coordinated containment may destroy evidence, leave another access path open, or create avoidable business disruption. Clear ownership and a reliable incident record make later technical, legal, and regulatory decisions easier to defend.

The objective on day one is not to eradicate every trace of the attacker. It is to establish control, limit further harm, preserve evidence, understand the likely scope, and plan a safe recovery.

The Executive Hour-by-Hour Playbook

This timeline is a decision sequence, not a rigid schedule. If responders confirm active exfiltration, destructive activity, or rapid lateral movement, containment takes priority.

Why the first 24 hours after a data breach matter

Two different measures help explain the urgency: how quickly attackers can move after initial access, and how long organisations often take to identify and contain a breach. They are not directly comparable, but together they show the cost of delay at both ends of the incident lifecycle.

Verizon's 2026 Data Breach Investigations Report found that exploitation of vulnerabilities had overtaken stolen credentials as the leading initial access route, accounting for 31% of breaches. Ransomware appeared in 48% of breaches, and third-party involvement reached 40%. The practical lesson is simple: responders must be ready to investigate identity, vulnerable internet-facing systems, suppliers, and cloud services at the same time.

IBM's 2025 Cost of a Data Breach research measured a much longer part of the lifecycle. Breaches identified and contained in fewer than 200 days averaged $3.87 million, compared with $5.01 million when the lifecycle exceeded 200 days. That is a $1.14 million difference. The comparison does not prove that the first 24 hours alone produce the saving, but it does reinforce the value of earlier detection, disciplined containment, and prepared response processes.

The figures describe different stages of an incident, so they should not be treated as a single causal model. Their value is operational: attackers may move in minutes, while weak investigation and recovery processes can keep an organisation exposed for months.

The playbook below is designed to reduce that operational gap.

Separate facts, hypotheses, and unknowns

Do not force an early binary choice between 'false alarm' and 'confirmed breach'. Keep three categories visible in the incident record and in every executive update:

• What we know: confirmed facts supported by evidence, such as verified use of a named account from a specific IP address.
• What we suspect: working hypotheses supported by initial indicators, such as possible credential theft.
• What we still need to establish: material questions requiring further investigation, such as whether data left the environment.

Common high-impact incident scenarios

• Ransomware and extortion operations
• Compromised privileged credentials
• Cloud identity and infrastructure compromise
• Data access and exfiltration
• Supply-chain and third-party compromise
• Business email compromise (BEC)

Supply-chain compromise deserves early attention because the affected organisation may not control the original access point or all relevant evidence. - Verizon's 2026 DBIR found third-party involvement in 40% of breaches.

Hour 0–1: Establish Control & Command

1. Activate response governance

Assign ownership immediately. The CISO or a designated Incident Commander should direct the response so technical, legal, communications, and business teams work from the same priorities.

Core response cell: Incident Commander, SOC Lead, Lead Forensics Analyst, IT Infrastructure Lead, Legal Counsel, Privacy/DPO, Executive Communications.

Notify the cyber insurer or broker early, before appointing outside firms or making material recovery decisions. The UK NCSC advises organisations to report a ransomware attack to their insurer or broker; some policies also specify an approved legal, forensic, or communications panel. Record the claim reference and authorisation path in the incident log.

NIST SP 800-61 Revision 3 treats incident response as part of wider cyber-risk management. Govern, Identify, and Protect support preparedness; Detect, Respond, and Recover cover the operational response; and lessons feed continuous improvement. The incident command structure should reflect that cross-functional model rather than operate as an isolated technical team.

2. Shift to out-of-band (OOB) communications

Assume that normal corporate messaging could be monitored until the identity and communications environment has been assessed. An attacker with access to email, Slack, Teams, or an identity provider may be able to follow the response in real time.

• Use a pre-established, independently authenticated out-of-band channel for the core response team.
• Limit sensitive updates to people with a defined role in the response.

3. Initiate the master incident log

Establish a secure, central audit log from minute one. Document:

•     Timestamps of key alerts and discoveries

•     Systems, accounts, and networks involved

•     Every containment action taken, and who authorized it

•     Key decisions, regulatory consultations, and external communications

Hour 1–2: Contain Without Destroying Forensics

Immediate eradication can destroy volatile evidence and make the attack path harder to reconstruct. Preservation is not absolute, however. If a system cannot be isolated and continued operation would cause further harm, responders may need to power it down. That decision should be made deliberately and recorded, ideally with guidance from the forensic lead.

1. Evidence preservation protocol

Where circumstances permit, collect or preserve the following before destructive remediation:

• Endpoint memory dumps and disk images
• Identity provider and authentication logs
• Firewall, DNS, and proxy telemetry
• Cloud audit and control-plane logs
• Database access and query logs

2. Balance containment with business operations

Containment is not synonymous with shutting down the entire network. Use the narrowest effective action:

• Isolate compromised hosts using EDR or network controls. Power them down only when isolation is not possible or continued operation creates greater risk.
• Revoke compromised sessions and tokens, disable affected accounts where appropriate, and record every change.
• Block confirmed command-and-control infrastructure while checking for alternative channels and persistence.

No playbook can guarantee containment inside the 29-minute average breakout window. Prepared authority, known escalation routes, and rehearsed containment options do reduce the time lost to basic approvals during a live incident.

Hour 2–4: Establish Scope & Attack Path

Move from isolated symptoms to a working attack timeline. Reconstruct:

1. Initial access — how did the threat actor get in? Unpatched edge vulnerability, stolen credentials, phishing.
2. Persistence — did the attacker establish backdoors (new cloud identities, scheduled tasks, web shells)?
3. Cloud control plane — review identity federation, conditional access, service principals, OAuth grants, access keys, and newly created accounts in parallel with on-premises Active Directory.
4. Privilege escalation — did access move from standard user rights to Domain Administrator or Cloud Global Administrator?
5. Lateral movement — how far did the attacker travel across subnets, databases, and core application servers?

Access vs. exfiltration: precision matters

Avoid premature statements. In executive briefings, hold these three categories apart rigorously:

• Evidence of access — indicators confirm the attacker viewed or interacted with a system or database.
• Evidence suggesting exfiltration — anomalous outbound bandwidth or staging files hint at data transfer.
• Confirmed exfiltration — forensic proof that data was successfully extracted.

The distinction affects regulatory analysis, customer communications, insurance discussions, and the credibility of later executive reporting. Use precise language and revise it as evidence changes.

Hour 4–8: Assess Business & Data Impact

Translate technical findings into terms the business actually runs on:

• Operational downtime — which critical business workflows are disrupted by containment or compromise?
• Data sensitivity — categorize exposure across PII, intellectual property, financial records, and credentials.
• Regulatory exposure — flag potential compliance breaches based on affected data types and jurisdictions.

Do not estimate impact from record counts alone. Consider the sensitivity of the data, the privileges of affected accounts, whether the attacker retained access, the duration of disruption, and the organisation's ability to restore critical services safely.

Hour 8–12: Legal, Regulatory & Stakeholder Decisions

Technical response, legal analysis, and regulatory assessment should run in parallel. Legal and privacy teams need verified facts early, even when the investigation is incomplete.

• UK GDPR threshold. A controller must notify the ICO of a personal data breach without undue delay and, where feasible, within 72 hours when the breach is likely to result in a risk to individuals' rights and freedoms. Not every security incident or personal data breach meets that reporting threshold.
• Phased notification. The ICO does not expect a complete forensic investigation within 72 hours. An organisation may provide the available facts first and submit further information without undue delay.
• Legal counsel. Involve counsel early to assess notification duties, preserve decision records, review communications, and identify contractual or sector-specific reporting requirements.

Hour 12–24: Recovery Strategy & Executive Communications

Transition from emergency response to controlled recovery planning.

• Executive and board briefings: report verified facts, current hypotheses, containment status, business impact, decisions required, and the next update time.
• Recovery planning: define the technical and business conditions for restoration. Rebuild from known-good media where practical, and test candidate backups in an isolated environment before reconnecting restored systems.
• Third-party and public communications: use pre-approved interim updates that state what is confirmed, what remains under investigation, and when the next update will follow. Do not fill gaps with reassurance that has not been verified.

Ten mistakes to avoid in the first 24 hours

1. Wiping or rebuilding systems before preserving necessary volatile and disk evidence.
2. Clearing logs or allowing short retention periods to overwrite the incident timeline.
3. Restoring service before establishing and closing the likely entry path.
4. Discussing response strategy through communications channels that may be compromised.
5. Assuming the first affected host or account represents the full scope.
6. Making categorical statements about data access or exfiltration before the evidence supports them.
7. Resetting credentials or revoking access without recording what changed, when, and by whom.
8. Treating initial containment as proof that persistence has been removed.
9. Allowing technical, legal, communications, and executive workstreams to maintain separate facts and timelines.
10. Waiting for a perfect investigation before assessing notification obligations and contractual deadlines.

Incident Response vs. Digital Forensics: Knowing What You Need

Often grouped together, IR and Digital Forensics (DFIR) actually serve distinct objectives:

• Incident response drives operational containment, threat eradication, and business service restoration.
• Digital forensics conducts deep evidence analysis to reconstruct the attack timeline, identify entry vectors, and prove whether data was accessed or exfiltrated.

In a significant incident, both disciplines operate together. Response teams contain and recover services while forensic specialists preserve and analyse evidence. This is consistent with NIST SP 800-61 Revision 3, which integrates Detect, Respond, and Recover with continuous improvement across the wider risk-management programme.

When to Bring in External Incident Response Support

Internal teams can get overwhelmed fast during complex incidents. Bringing in specialized external IR support is critical when:

• Privileged or identity-provider accounts are compromised.
• Ransomware or destructive activity is present. Verizon's 2026 DBIR found ransomware in 48% of breaches, reinforcing the need for tested restoration and decision procedures.
• Cloud environments show complex, multi-tenant compromise.
• Internal teams lack specialized forensic tools or capacity.
• An independent, defensible forensic report is required for regulators, insurers, or the Board.

For an active incident, suspected compromise, or post-incident assurance, REDSECLABS incident response services cover triage, containment, eradication, recovery, forensic analysis, and lessons learned.

What practitioner postmortems repeatedly reveal

Reddit discussions are anecdotal rather than formal evidence. Their value is in exposing operational friction that frameworks can understate. Across sysadmin, MSP, and security communities, four patterns recur:

• A backup is not a recovery plan until a representative system has been restored and validated in an isolated environment.
• An external responder can guide, investigate, and accelerate decisions, but an internal owner must still explain business priorities, dependencies, and acceptable disruption.
• Customer-care or contractual SLAs can pressure teams to state conclusions too early. Pre-approved interim messages should meet the need for an update without presenting hypotheses as facts.
• Forensic preservation and business recovery can pull in different directions. Record the trade-off, the decision owner, and the evidence that may be lost before rebuilding.

Cyber incident response checklist for the first 24 hours

Hours 0–1: Establish Control

☐  Activate the Incident Response Plan and designate an Incident Commander

☐  Move key responders to secure, out-of-band communication

☐  Initialize the Master Incident Log

☐  Freeze log retention policies to prevent overwriting evidence

☐  Notify the cyber insurer or broker and confirm any approved-provider requirements

Hours 1–4: Contain & Scope

☐  Isolate compromised systems and disable high-risk accounts

☐  Preserve disk and memory images of critical endpoints

☐  Map the initial access vector and review perimeter telemetry

Hours 4–8: Investigate & Measure

☐  Reconstruct lateral movement and identify persistence mechanisms

☐  Evaluate impact on core operations and sensitive data repositories

☐  Differentiate verified data access from confirmed exfiltration

Hours 8–12: Governance & Alignment

☐  Brief executive leadership and legal/privacy teams

☐  Assess UK GDPR/ICO, contractual, insurance, and sector-specific reporting requirements

☐  Draft initial external and internal communication statements

Hours 12–24: Recover & Plan

☐  Finalize containment validation with technical teams

☐  Establish phased restoration priorities for business services

☐  Test-restore critical backups in an isolated environment before production recovery

☐  Prepare the board-level update and map out long-term remediation

Preparedness determines how quickly you can act

The worst time to agree authority, access, secure communications, evidence handling, and commercial terms is during an active breach. A tested plan and a pre-arranged response relationship remove much of that delay.

The first 24 hours will always contain uncertainty. The purpose of the playbook is to keep decisions controlled and evidence-led while the facts develop. Organisations without permanent security leadership can place preparedness, tabletop exercises, and executive coordination under a vCISO programme, while retaining specialist incident responders for live events.

PREPARE BEFORE THE INCIDENT

A REDSECLABS incident response retainer establishes the response relationship before a crisis. It defines a contracted response SLA, reserves specialist capacity, and agrees the legal and commercial terms that would otherwise slow mobilisation. Readiness work can include response-plan review, quarterly tabletop exercises, and proactive threat hunting so the first-day decisions in this playbook have been tested before they are needed.

Request an Incident Response Retainer Readiness Review ->

Frequently Asked Questions

Q1: What should an organization do first after detecting a breach?

Ans: Confirm that the event is being managed, appoint an Incident Commander, start an incident log, preserve relevant telemetry, and move the core team to a trusted communications channel. Containment should begin as soon as the affected assets and accounts can be identified.

Q2: Should a compromised server be powered off immediately?

Ans: Not automatically. Isolate the system through EDR or network controls when possible so volatile evidence can be preserved. If isolation is not possible and the system is causing continuing harm, powering it down may be the safer containment action. Record the decision.

Q3: How does an organization preserve digital evidence correctly?

Ans: Use trained personnel to capture volatile memory and forensic images, preserve source logs and cloud audit records, document every collection step, and maintain chain-of-custody information when the evidence may be used for legal, insurance, disciplinary, or regulatory purposes.

Q4: When should an organization bring in external forensic experts?

Ans: Bring in external support when privileged identity, ransomware, cloud control planes, sensitive data, or several business systems are involved; when internal capacity is limited; or when an independent forensic report is needed for counsel, regulators, insurers, or the board.

Q5: Does every cybersecurity incident require regulatory notification?

Ans: No. Under UK GDPR, notification depends on whether a personal data breach is likely to create a risk to individuals' rights and freedoms. Reportable breaches must be notified to the ICO without undue delay and, where feasible, within 72 hours of awareness. Record the assessment even when notification is not required.

Q6: What is the difference between Incident Response and Digital Forensics?

Ans: Incident Response focuses on stopping the attack and restoring business operations. Digital Forensics analyses evidence to establish how the attack occurred and what data was affected.

Q7: How fast do attackers actually move once they're inside a network?

Ans: CrowdStrike's 2026 Global Threat Report recorded an average eCrime breakout time of 29 minutes in 2025, with a fastest observed breakout of 27 seconds. Breakout time measures movement from the initial compromised host to another system; it is not the duration of the whole breach.