Incident response phases

The blocked script at Riverside Family Law on November 9 lasted only seconds on the paralegal's screen, but it kept Keisha busy for most of the afternoon. She opened Brightline's incident response plan, a twelve-page document every client had approved, and worked through it step by step while Jordan watched and took notes. At one point he asked why she was following a checklist for something the EDR had already stopped. Because the checklist does not know it is small yet, she said, and neither do I. The plan makes sure we ask every question before we decide it is over, and it makes sure we do the same things in the same order when it is not small.

This lesson explains what an incident is, the phases of incident response, the people and documents involved, how incidents are communicated and reported, and how compliance frameworks change what must be done. Lesson 10 covers evidence handling, which runs through every phase.

Events and incidents

Not everything that appears in a log is an incident. An event is any observable occurrence: a sign-in, a blocked email, a file download. An alert is an event that a tool has flagged as possibly important. A security incident is an event or series of events that actually threatens or harms the confidentiality, integrity or availability of systems or data, or that breaks security policy. A phishing email that is blocked is an event. A phishing email that a user opens, triggering malware, is at least a possible incident until proven otherwise. A mailbox signed into by an attacker is an incident.

A breach is a particular kind of incident in which data is accessed, disclosed or lost without authorization. Whether an incident counts as a breach matters a great deal, because breaches involving personal information can trigger legal duties to notify regulators and affected people. Deciding that question is part of the analysis, not something to assume at the start.

The incident response lifecycle

The most widely taught model comes from the US National Institute of Standards and Technology. Its incident handling guide, Special Publication 800-61, described for many years a four-phase lifecycle: preparation; detection and analysis; containment, eradication and recovery; and post-incident activity. Revision 3, published in April 2025, reorganizes the guidance around the six functions of the NIST Cybersecurity Framework 2.0 from Lesson 6, but the work it describes is the same, and the four phases remain the clearest way to learn it. Another common model, from the SANS Institute, splits the same work into six steps: preparation, identification, containment, eradication, recovery and lessons learned.

Preparation

Preparation happens before anything goes wrong, and it decides how well everything else goes. It includes an incident response plan approved by leadership, defined roles and contact lists, playbooks for common incident types, tools such as EDR and central logging already in place, backups that have been tested, and training and practice. Brightline's plan named Keisha as incident lead, Owen as the person who talks to the client's leadership and decides on outside help, and Marisol as coordinator for any help-desk work such as password resets. Each client contract named the client's own decision-maker and stated who would notify regulators, insurers and police if needed.

Playbooks are short, step-by-step guides for specific scenarios: a phishing email clicked, a compromised mailbox, a lost laptop, ransomware, a malware detection. They save time and reduce mistakes under pressure. Contact lists must work when systems do not, so Brightline kept a printed copy and stored phone numbers outside its own email system, an example of planning for out-of-band communication.

Detection and analysis

Detection comes from many places: EDR and SIEM alerts, user reports, a vendor's warning, a customer noticing something odd or even a ransom note. Analysis decides what is really happening. The analyst confirms whether it is an incident, works out its scope, which systems, accounts and data are involved, and assigns a severity that sets how fast and how widely to respond.

For the Riverside alert, analysis took about an hour. The EDR history showed the document started the scripting program, the script was stopped before it ran any command, the laptop made no new network connections, and no other device had received the email. Keisha classified it as low severity, with a note that it would become medium if anything else turned up. A key habit of good analysis is writing down each finding with its time and source as you go, because memory is unreliable and the notes become the record of the incident.

Containment, eradication and recovery

Containment stops the incident from getting worse. Short-term containment acts fast: isolating a device, disabling an account, blocking an address or taking a website offline. Long-term containment keeps the business running safely while a full fix is prepared, for example by moving a server to an isolated network segment. Containment decisions involve trade-offs. Pulling the network cable stops malware spreading but may destroy evidence in memory or warn an attacker, which is why Lesson 10 matters here.

Eradication removes the cause: deleting malware, closing the vulnerability that let it in, removing accounts or forwarding rules an attacker created, and resetting credentials that may be known to the attacker. Recovery returns systems to normal, often by restoring from clean backups or reimaging, followed by closer monitoring for a while to make sure the attacker does not come back. At Riverside, containment was the automatic isolation, eradication was the reimage and mail-filter rule, and recovery was returning the laptop to the paralegal the next morning with her files restored from the cloud.

Post-incident activity

After every significant incident, the team meets to review what happened, usually within a couple of weeks while memories are fresh. The review is blameless: its goal is to improve the system, not to punish the person who clicked. It asks what happened and when, what went well, what was hard, what should change, and who will make each change by when. The output is a short report and a list of actions, and the incident record is closed only when the actions are assigned. Lessons learned feed back into preparation, which is why the lifecycle is drawn as a circle.

The Riverside review was only fifteen minutes long, but it produced two useful changes. Brightline turned on a setting in the firm's email service that blocks active content in documents from outside senders by default, and it added the court-notice theme to the next awareness session, because the email had been tailored to a law firm.

Communication during an incident

Incidents are as much about communication as technology. The plan should say who needs to know, who tells them, what they are told and when. Inside the organization that includes leadership, the people affected and staff who may need to change what they do. Outside it can include customers, insurers, lawyers, police, regulators, vendors and sometimes the media. Messages should be factual, avoid speculation and be approved by the person the plan names. During a serious incident, assume the attacker may be able to read email on compromised systems, and switch to phone or a separate messaging system.

Brightline's clients usually asked the same three questions, so Owen's first message always answered them in plain language: what happened, what we have done about it, and what you need to do now. Updates followed at agreed intervals, even when the update was that nothing had changed.

Reporting and notification duties

Compliance frameworks, introduced in Lesson 6, shape incident handling most directly through notification duties. A technician does not decide on legal obligations, but must recognize when they might apply and escalate promptly so that the people who decide have time to act.

In Canada, PIPEDA requires an organization to report to the Office of the Privacy Commissioner any breach of security safeguards involving personal information that creates a real risk of significant harm, to notify affected individuals as soon as feasible, and to keep a record of every breach, even small ones, for at least 24 months. Quebec's private-sector law requires confidentiality incidents that present a risk of serious injury to be reported to the province's information commissioner, and every incident to be recorded in a register. Provincial health information laws, such as Saskatchewan's Health Information Protection Act, add duties for health information. Incidents can also be reported voluntarily to the Canadian Centre for Cyber Security, and crimes such as fraud and extortion to the police.

Other frameworks add their own duties. PCI DSS requires merchants to follow the card brands' and their bank's procedures when card data may be compromised. The European Union's GDPR requires notice to the supervisory authority within 72 hours of becoming aware of a reportable breach. Cyber insurance policies usually require prompt notice to the insurer and may require using the insurer's approved responders, so calling the insurer early is part of most plans.