Cyber Incident Response: What to Do in the First 72 Hours

 

Opening Direct Answer: The First 72 Hours

When a cyber incident is confirmed or suspected, the first 72 hours are not about solving the problem – they are about not making it worse. Contain the spread, preserve evidence, notify the right people at the right time, and keep the business running where it safely can. Organizations that fail in the first 72 hours typically do so not because they lack technical capability, but because they have no plan, no clear decision authority, and no pre-established communication structure when the pressure is highest. A documented, tested incident response plan is the single highest-leverage preparation investment any organization can make.

The 6 Phases of Incident Response

The internationally recognized incident response lifecycle, codified in NIST SP 800-61 and reflected in ISO 27035, defines six sequential phases. Each phase has distinct objectives, owners, and time pressures.

Phase 1: Preparation

Preparation is everything that happens before an incident occurs. It is the phase most organizations underinvest in until they experience a breach. Preparation encompasses: a documented and board-approved Incident Response Plan (IRP), a designated Incident Response Team (IRT) with defined roles and escalation authority, pre-negotiated retainer agreements with external IR specialists and legal counsel, communication templates for regulators, customers, and media, and regular tabletop exercises that test the plan against realistic scenarios.

An untested plan is a hypothesis. Organizations that experience their first IR process during an actual incident typically find that their plan fails on the first contact with reality – decision-makers cannot be reached, escalation paths are unclear, and evidence collection procedures are not followed.

Phase 2: Detection and Analysis

Detection is identifying that an incident has occurred or is occurring. Analysis is determining its nature, scope, and severity. Both are harder than they appear. Most breaches are not discovered through automated alerts – they are discovered through user reports, third-party notification, or anomaly investigation. The 277-day average detection-to-containment timeline reflects how long sophisticated attackers can operate undetected in enterprise environments.

During this phase: confirm the incident is real (not a false positive), establish initial scope, activate the IRT, begin evidence collection and chain-of-custody documentation, and make the first notification decisions based on preliminary analysis. Do not wait for complete certainty before notifying – regulators require notification on reasonable grounds, not confirmed facts.

Phase 3: Containment

Containment stops the bleeding. It has two sub-phases: short-term containment (stopping immediate damage) and long-term containment (stabilizing the environment while investigation continues).

Short-term containment may include isolating affected systems from the network, revoking compromised credentials, blocking attacker-controlled infrastructure at the perimeter, and disabling affected services. The critical tension here: containment measures can destroy forensic evidence. Before wiping or reimaging systems, capture memory dumps, log data, and disk images. Speed and preservation are in tension – the IR plan must pre-define how to balance them.

Long-term containment allows the organization to operate in a degraded but stable state while eradication is prepared. This may involve temporary alternative systems, enhanced monitoring, or service degradation that the business has accepted as preferable to continued exposure.

Phase 4: Eradication

Eradication removes the threat: closing the attack vector, removing malware, eliminating attacker persistence mechanisms, and patching the vulnerabilities that enabled the compromise. Eradication must be thorough – attackers routinely plant multiple backdoors specifically to survive initial remediation. Rushing eradication to restore services faster is one of the most common reasons organizations experience reinfection within days of “recovery.”

A complete eradication checklist includes: all attacker-controlled accounts removed, all persistence mechanisms identified and eliminated, all compromised credentials rotated, all exploited vulnerabilities patched, and evidence of compromise documented for regulatory reporting.

Phase 5: Recovery

Recovery restores normal operations. This is not simply turning systems back on. Recovery requires: verifying that restored systems are clean, enhanced monitoring during the initial recovery period to detect any residual attacker presence, staged service restoration (not everything at once), and user communication about what to expect.
Recovery is also when the business pressure to “just get back to normal” is most acute. Executives who are not deeply familiar with IR processes will push for faster recovery than is safe. The IR plan must give the response team the authority to pace recovery appropriately, with board-level support pre-established.

Phase 6: Post-Incident Activity (Lessons Learned)

Within two to four weeks of containment, conduct a formal post-incident review. This is not a blame session – it is a structured analysis of what happened, how, and what changes to the security program will reduce the likelihood or impact of recurrence. Document the timeline, root cause, detection gap, response effectiveness, and specific remediation actions with owners and deadlines.

The lessons-learned output feeds directly back into Phase 1 (Preparation) – updating the IR plan, improving detection coverage, adjusting training content, and informing the risk register.

Regulatory Notification Timelines by Framework

One of the highest-stakes decisions in the first 72 hours is when and what to notify to which regulatory bodies. Missing notification deadlines carries significant penalties. The following table covers the major frameworks applicable to Israeli and EU enterprises.

Framework	Notification Trigger	Timeline	Who to Notify
NIS2 Directive	Significant incident with substantial impact on services	24h early warning; 72h formal notification; 1 month final report	National competent authority / CSIRT
GDPR	Personal data breach likely to result in risk to individuals	72 hours from awareness	National supervisory authority (e.g., DPA); affected individuals if high risk
DORA (Financial Sector)	Major ICT-related incident per classification criteria	4h initial notification; 72h intermediate; 1 month final	Competent authority (NCAs); in some cases, ECB and ESMA
ISO 27001	Any incident affecting information security objectives	Per documented incident management procedure	Internal stakeholders; external parties per contracts
SEC Rule 33-11216	Material cybersecurity incident	4 business days from materiality determination	SEC Form 8-K; investors
Israeli Privacy Protection Law	Data breach affecting Israeli residents	Promptly (no fixed timeline; “without undue delay”)	Israeli Privacy Protection Authority (PPA)

Critical point: NIS2 notification timelines begin when there are “reasonable grounds to believe” a significant incident has occurred – not when the incident is confirmed or fully understood. This means notification decisions must be made on incomplete information, which is uncomfortable but legally required. Engage legal counsel immediately upon detecting a potential significant incident to navigate this determination.

The Role of Legal Counsel in Incident Response

Legal counsel is not a post-incident resource, it must be engaged within hours of incident detection. The reasons are structural, not procedural.

Attorney-Client Privilege Communications made under legal counsel’s direction during an incident investigation may be protected by attorney-client privilege in some jurisdictions. This can significantly affect what information becomes discoverable in subsequent litigation or regulatory proceedings. Organizations that conduct incident investigations without legal involvement from the outset may inadvertently waive protections they would otherwise have had.

Regulatory Notification Strategy Legal counsel – specifically counsel experienced in data protection and cybersecurity law – advises on notification thresholds, content, and timing. What you say in a regulatory notification matters. Notifications that are too expansive create unnecessary regulatory exposure. Notifications that are too narrow or late create enforcement risk. This is not a determination that the IR team should make alone.

Contractual Obligations Most enterprises have data processing agreements, customer contracts, and cyber insurance policies that specify incident notification obligations. Legal counsel maps these obligations and ensures they are met within their respective deadlines, which may differ from regulatory timelines.

Ransom Payment Analysis Where ransomware is involved, legal counsel advises on the legality of ransom payments, OFAC sanctions considerations (payments to sanctioned entities are illegal regardless of the circumstances), and cyber insurance coverage conditions.

Ransomware-Specific Guidance

Ransomware deserves specific treatment because it combines technical, operational, legal, and regulatory complexity in a compressed timeframe. The following principles apply regardless of the specific ransomware variant or attacker.

Do not immediately reboot or power off affected systems. Memory forensics, volatile data that disappears on shutdown, can be critical for identifying the attack vector, persistence mechanisms, and attacker tooling. Capture memory before shutdown.

Isolate, do not wipe. Contain affected systems by network isolation, but do not immediately reimage them. Preserve forensic evidence for investigation, insurance claims, and potential law enforcement referral.

Check your backups before you negotiate. The first question in any ransomware response is whether clean, restorable, uncompromised backups exist. Many ransomware operators specifically target and encrypt or delete backup systems before triggering the encryption payload. Verify backup integrity before making any ransom-related decisions.

Engage specialists before engaging attackers. Do not attempt to negotiate with ransomware operators without experienced IR specialists. Amateur negotiation errors – including acknowledging specific organizational details or making early payment commitments – regularly result in higher demands and longer timelines.

Understand the double-extortion reality. Most modern ransomware operations combine encryption with data exfiltration. Even if you restore from backups and decline to pay, the attackers may still publish or sell exfiltrated data. This transforms every ransomware incident into a potential data breach requiring regulatory notification under GDPR and NIS2.

Do not pay without legal clearance. OFAC sanctions prohibit payments to designated entities. Multiple ransomware groups are on the OFAC Specially Designated Nationals list. Paying without confirming the group’s sanctions status is a potential federal violation, independent of the cybercrime involved.

What NOT to Do: Common Mistakes That Make Things Worse

The mistakes organizations make in the first 72 hours are remarkably consistent across industries and company sizes.

1. Communicating on compromised channels. If your email or messaging systems may be compromised, do not use them to coordinate the response. Attackers routinely monitor internal communications during active intrusions. Establish an out-of-band communication channel (personal mobile numbers, a pre-established secure messaging platform) before you need it.

2. Deleting logs or artifacts in an attempt to “clean up.” Evidence destruction – even unintentional – creates legal exposure and destroys the forensic record needed for investigation, insurance claims, and regulatory reporting. Establish a clear evidence preservation protocol and enforce it.

3. Announcing the incident publicly before regulatory notification. Regulatory bodies expect to hear about significant incidents from the affected organization, not from media reports. Premature public disclosure before regulators are notified can damage the relationship with your supervisory authority and affect enforcement discretion.

4. Failing to notify cyber insurers immediately. Most cyber insurance policies require prompt notification of a potential claim event. Delayed notification, even if the incident is ultimately contained, can void coverage. Notify your insurer immediately upon detection, not after investigation is complete.

5. Assuming the attacker is gone after initial containment. Initial containment stops the visible attack. It does not mean the attacker has been removed. Sophisticated actors plant persistence mechanisms specifically to survive initial response. Treat the environment as hostile until eradication is confirmed by a forensic specialist.

6. Making public statements without legal review. Statements made by executives during an incident – to media, on social platforms, in employee all-hands meetings – can create legal liability, contradict regulatory filings, and affect insurance coverage. All external communications must be reviewed by legal counsel before release.

The Case for an IR Retainer

An incident response retainer is a pre-negotiated agreement with an external IR provider that guarantees response capacity, defined service level agreements (SLAs), and pre-agreed commercial terms. The case for retainers is straightforward.

Speed: When an incident is detected, every hour matters. Organizations without retainers spend the first 12–24 hours finding, evaluating, and contracting with an IR provider – time the attacker is using productively. Retainer clients receive immediate response under pre-agreed terms.

Readiness assessment: Retainer engagements typically include pre-incident readiness reviews – the IR provider familiarizes itself with the client’s environment, identifies forensic sensor gaps, and validates that IR plan assumptions match operational reality.

Insurance alignment: Many cyber insurers offer premium discounts for organizations with pre-negotiated IR retainers, and some policies specify approved IR providers. Align your retainer selection with your insurance policy requirements before you need it.

Cost predictability: IR retainers are significantly less expensive than emergency IR engagement during an active incident, when provider leverage is high and urgency drives premium rates.

How IPV Security Approaches Incident Response

IPV Security provides incident response leadership as a core component of every vCISO engagement, integrated with the CISOteria Cyber OS™ platform’s incident management module. Our approach to IR is built on the principle that the response capacity you have at the start of an incident is the response capacity you have – there is no time to build it during the event.

Every client engagement begins with an assessment of IR readiness against our 6-phase framework. For clients without a documented IR plan, we develop one as a foundational deliverable. For clients with existing plans, we conduct tabletop exercises to validate plan assumptions and identify gaps before they become critical under pressure.

When incidents occur, our team provides executive-level IR leadership: coordinating with the technical response team, advising on regulatory notification timing and content, managing stakeholder communication, and leading the post-incident review. We operate alongside client legal counsel and cyber insurers, not independently of them.

The CISOteria Cyber OS™ platform maintains the incident register, tracks all response actions and their owners, and generates the regulatory notification documentation required by NIS2, GDPR, and DORA. When an incident occurs, the documentation burden – which typically consumes a disproportionate share of response capacity – is reduced to a structured, guided process.

For organizations requiring immediate response capability, our emergency line operates 24/7. For those building their IR readiness proactively, our compliance and IR program services provide the foundation.

 

About the Author

Ido Ganor is the Founder and CEO of IPV Security and creator of the CISOteria Cyber OS™. With 21+ years of enterprise CISO experience spanning financial services, critical infrastructure, and technology sectors, Ido has led incident response for significant cyber events across multiple industries and jurisdictions. He advises mid-market and enterprise organizations across Israel and the EU on building incident response capability that meets NIS2, GDPR, and DORA requirements while protecting operational continuity.

 

Related Articles

• Compliance Guide: ISO 27001, NIS2, and DORA Explained
• What Is a vCISO Program? The Complete Guide
• Board-Level Cybersecurity Governance: The Executive’s Complete Guide

 

Experiencing an incident now? Call IPV Security’s 24/7 line.

Every hour of uncontrolled access costs you more. Our incident response team is available around the clock to provide immediate leadership, regulatory guidance, and forensic coordination.

Contact IPV Security Emergency Line →