The first 72 hours of a cyber incident

Every incident is different, and the hour bands below are a way to organize the work, not a promise of how long any step will take. A single compromised mailbox may be understood in a day; a ransomware attack across several sites can take weeks to fully investigate.

The structure follows the incident response lifecycle in NIST SP 800-61 Rev. 3 (published April 2025, now aligned with the NIST Cybersecurity Framework 2.0) and ISO/IEC 27035: detect and analyze, contain, eradicate, recover, and learn. In Canada, privacy law adds a parallel track: deciding whether there has been a breach of security safeguards that must be reported and recorded.

Keep affected devices powered on and do not reboot them or log users out: the Canadian Centre for Cyber Security warns this erases volatile forensic evidence. Isolate them from the network instead. Then confirm the incident, note when it started, which devices and data are involved and who had access, and call your lawyer, insurer and incident responder.

1. 01

   Confirm and scope the alarm

   Establish what was seen, where and when. Is it one user, one device, one site, or everything? Write it down with times.

2. 02

   Stop the bleeding without destroying evidence

   Disconnect affected machines from the network but leave them on. Disable (don't delete) compromised accounts. If money moved, call the bank's fraud line now.

3. 03

   Make the calls

   Your incident responder, your lawyer, and your insurer's claims line if you have cyber coverage. Decide who leads internally and who speaks for the organization.

4. 04

   Switch to safe communications

   If email or Teams may be compromised, use phone calls and a separate channel for incident discussion.

5. 05

   Preserve volatile data

   Responders capture memory and running state from key systems, and export cloud sign-in and audit logs before short retention windows roll them off.

This is where an incident either becomes understood or becomes guesswork. Responders image key systems or collect targeted artifacts, pull firewall, VPN, endpoint and cloud logs, and build a first timeline. Hash values and chain-of-custody records are kept so the evidence can stand up later with insurers, regulators or a court.

In parallel, access is closed: passwords and sessions reset for affected accounts, attacker persistence (new admin accounts, remote-access tools, mailbox rules, OAuth app grants) identified and removed in a controlled order, and internet-facing weaknesses (exposed remote desktop, unpatched VPNs) shut. Doing this before you know how the attacker got in risks tipping them off while they still have another door.

By now the questions shift from 'how do we stop it' to 'what happened'. How did they get in? What did they touch? Did data leave, and whose? The answers drive everything that follows, including whether you have privacy obligations.

Under PIPEDA, an organization must report to the OPC, and notify affected individuals, any breach of security safeguards involving personal information under its control where it is reasonable to believe the breach creates a real risk of significant harm (RROSH). Notification to individuals must be given as soon as feasible after you determine the breach occurred. Separately, the Breach of Security Safeguards Regulations (SOR/2018-64) require you to keep a record of every breach of security safeguards for 24 months, whether or not it was reportable. Provincial laws (such as Ontario's PHIPA for health information custodians, Quebec's Law 25, and Alberta's PIPA) can add their own duties.

Your lawyer makes the legal call; the forensic findings give them facts to make it with.

If counsel or an insurer is already involved, see forensics for breach counsel and insurers.

• Rebuild or restore systems from known-good sources, in an order the business agrees on.
• Verify backups are clean before restoring; attackers often sit in a network for a while before they act.
• Close the root cause: MFA gaps, legacy authentication, exposed services, missing patches.
• Increase monitoring for several weeks; attackers often try to come back.
• Produce a final report suited to its audience: executive summary, technical timeline, data-impact findings, and recommendations.
• Hold a lessons-learned session and update your incident response plan.

• Reimaging laptops or restoring servers before anyone captures what was on them.
• Deleting the phishing email, the malicious inbox rule or the attacker's account to 'clean up'.
• Discussing the response by email on a compromised tenant.
• Waiting days to call the insurer or lawyer, then finding steps were taken that the policy or privilege strategy didn't allow.
• Assuming nothing was taken because nothing was encrypted.
• Not checking how long logs are kept; Microsoft 365 audit records, for example, roll off after a fixed retention period that depends on licence.