Incident Response Readiness: The First 72 Hours

Every organization will eventually face a serious cyber incident. The difference between a disruption and a disaster often comes down to the first 72 hours: how quickly the incident is recognized, how well evidence is preserved, how carefully the attacker is contained, and whether legal and contractual obligations are met.

Those hours go far better when the preparation happened beforehand.

Before the incident

A plan people have actually used

An incident response plan should define roles, decision authority, escalation paths, communication procedures and reporting obligations. It should be exercised: a tabletop exercise once or twice a year reveals gaps while they are cheap to fix. NIST SP 800-61 Revision 3, updated in 2025, frames incident response within broader cybersecurity risk management and is a useful reference.

Contacts ready

Keep current contact information for the incident response team, leadership, legal counsel, insurers, key vendors, law enforcement and any external incident response provider. Store it where it will be available if email and networks are down.

Logging in place

Investigations depend on logs: authentication, endpoint activity, network flows, cloud audit trails and application logs. If they are not collected and retained before an incident, they will not be there afterward.

Decision authority defined

Know who can authorize disconnecting systems, engaging outside help, paying for emergency services, notifying regulators and customers, and speaking publicly.

Obligations mapped

Know which laws, regulations, contracts and insurance policies impose notification requirements, and their deadlines. Defense contractors, for example, must report qualifying incidents to the Department of War within 72 hours under DFARS 252.204-7012.

The first 72 hours

Hour 0 to 1: declare and assemble

Once suspicious activity is confirmed as a likely incident, activate the plan. Name an incident lead, open an incident record with timestamps, and bring in the right people. Record when the incident was discovered, since many reporting clocks start then.

Hours 1 to 6: scope and preserve

Identify affected systems, accounts and data as far as possible. Preserve evidence before changing anything: memory and disk images of key systems, relevant logs, and copies of malicious files. Begin a timeline of attacker activity.

Hours 6 to 24: contain

Contain the incident deliberately. Isolate compromised systems, disable or reset compromised accounts, and block attacker infrastructure. Where the attacker may have broad access, plan containment actions together, so that removing one foothold does not alert them to change tactics or trigger destructive actions elsewhere.

Hours 24 to 48: investigate

Determine how the attacker got in, what they accessed, how they moved, and whether they are still present. Look for persistence mechanisms such as new accounts, scheduled tasks and remote access tools.

Hours 48 to 72: report and plan recovery

Meet notification obligations with the information available, and update as the investigation continues. Plan eradication and recovery: rebuilding systems from trusted sources, resetting credentials broadly and restoring data from backups verified to be clean.

Common mistakes

• Rebuilding before preserving. Wiping and restoring a server destroys evidence of how the attacker got in.
• Missing reporting deadlines while waiting for certainty.
• Communicating on compromised systems. If email or chat may be compromised, use out-of-band channels.
• Resetting a few passwords when the attacker may have broad credential access.
• Restoring from infected backups. Verify backups before restoring.
• Declaring victory early. Monitor closely after recovery; attackers often attempt to return.

After the incident

Hold a lessons-learned review. What worked, what did not, and what will change? Update the plan, strengthen controls and schedule the next exercise.

A readiness checklist for leaders

Before the next incident, leaders should be able to answer yes to each of these:

• We have an incident response plan, and we exercised it in the last year.
• We know who leads an incident, and who can make decisions about disconnecting systems and engaging outside help.
• Contact details for our team, counsel, insurer, key vendors and law enforcement are current and available offline.
• We collect and retain the logs an investigation would need, for long enough to be useful.
• We know our legal, regulatory and contractual reporting obligations and their deadlines.
• We can capture forensic images of servers, workstations and cloud workloads, and store them securely.
• Our backups are protected from tampering, and we have tested restoring them recently.
• We have an out-of-band way to communicate if email and chat are compromised.
• We have a retainer or relationship with an incident response provider, or know who we would call.

Each "no" is a specific, fixable gap.

Frequently asked questions

Should we pay a ransom? It is a business, legal and ethical decision that depends on circumstances, and it should be made with counsel and, where appropriate, law enforcement. Paying does not guarantee data recovery or deletion, and may carry legal risk. Preparation, especially tested, protected backups, reduces the chance of facing the decision.

When should we call law enforcement? Consider engaging law enforcement early for significant incidents. They may have information about the threat actor and can help with investigation. Your counsel can advise on timing.

How do we know the attacker is gone? You cannot be certain, but thorough investigation, broad credential resets, removal of persistence and heightened monitoring after recovery greatly improve confidence. Many organizations run a focused threat hunt after recovery.

How CDT can help

CDT's incident response and digital forensics team contains attacks, preserves evidence and restores operations, and our cyber hunt team finds attackers who are still present. If you are responding to an incident now, go to our Under Attack page.

Sources

• NIST SP 800-61 Rev. 3, Incident Response Recommendations and Considerations for Cybersecurity Risk Management
• DFARS 252.204-7012