How to Run a Incident Response Engagement

A well-run incident response engagement moves through five phases in a fixed order: detection and triage, containment, eradication, recovery, and post-incident review, typically completed within one to three weeks depending on scope. The single biggest factor in how well it goes is whether you had a plan and a partner lined up before the incident happened, not after.

What Triggers an Incident Response Engagement

Most engagements start one of two ways: an internal alert (a SIEM flag, a suspicious login, ransomware notes on a file share) or an external one (a customer reporting fraud, a vendor breach notification, a threat actor's extortion email). Either way, the clock starts the moment someone with authority decides "this is real." Companies in Toronto, Waterloo, and Ottawa dealing with regulated data (financial, health, or personal information under PIPEDA) have an added wrinkle: breach notification obligations kick in fast, and Quebec's Law 25 sets even tighter reporting expectations for organizations with Quebec residents' data. Knowing your legal clock before the incident starts is part of the prep work, not something to figure out mid-crisis.

Hour One: Detection and Triage

The first hour is about answering three questions: what happened, what's affected, and is it still happening. This is not the time for a full forensic timeline, it's the time for a fast, disciplined scoping call. A named incident commander (internal or from your response partner) pulls together whoever has visibility into the affected systems, logs, and business impact.

• Confirm the incident is real, not a false positive or a misconfigured alert
• Identify affected systems, accounts, and data categories
• Assign an incident commander and open a communications channel separate from potentially compromised email or chat
• Decide whether to isolate systems immediately or observe first to preserve evidence

This is exactly where a pre-negotiated incident response retainer earns its cost. Without one, a company spends the first several hours vetting vendors, negotiating statements of work, and waiting for a call back, while an attacker has free run of the network. With named responders already under contract and a service level agreement in place, the response team is on a call within the SLA window, not searching for one.

Days One to Three: Containment

Containment stops the bleeding without destroying evidence. Depending on the incident type, this might mean isolating a subnet, disabling compromised credentials, rotating API keys, or pulling a specific host off the network rather than shutting everything down. Overreacting (shutting down the whole environment) can cause more business damage than the incident itself and can also alert an attacker still inside the network to pivot or destroy logs.

A realistic timeline here is 24 to 72 hours for most incidents. Ransomware and active intrusions with lateral movement tend toward the longer end because containment has to happen system by system, verifying each is clean before reconnecting it. This phase is also where you decide whether outside counsel and cyber insurance need to be looped in, both of which have their own notification clocks running in parallel.

Week One: Eradication and Root Cause Analysis

Once the incident is contained, the work shifts to finding and removing the actual cause, not just the visible symptom. This means answering how the attacker got in (phishing, an exposed credential, an unpatched vendor tool), what they touched while inside, and whether they left anything behind (a scheduled task, a new admin account, a web shell) to get back in later.

This is the phase where experience matters most. A generalist IT team can usually contain an obvious threat, but root cause analysis on a real intrusion requires someone who has done log forensics and malware triage before. This is also where having a researcher-led team pays off, someone who has found and disclosed vulnerabilities (rather than only read about them) tends to spot attacker tradecraft that a checklist misses.

Week Two: Recovery and Validation

Recovery is not just restoring from backup, it's restoring with confidence that the restored environment is clean. That means rebuilding compromised systems from known-good images rather than patching in place, rotating every credential the attacker could plausibly have touched, and validating monitoring is actually catching the indicators of compromise you found during eradication before declaring the incident closed.

Rushing recovery is the most common mistake in incident response. Bringing systems back online before validation is complete is how organizations end up with a second, related incident two weeks later because the same gap that let the attacker in the first time was never actually closed.

After the Fire: Post-Incident Review and Remediation

The engagement isn't done when systems come back online. A proper post-incident review documents the full timeline, the root cause, what worked, what didn't, and a prioritized remediation plan. For regulated organizations, this document is also often what a regulator, auditor, or insurer will ask to see. Companies pursuing or maintaining a SOC 2 report need this documentation anyway, incident response is a required trust services criterion, so an engagement handled well can feed directly into audit evidence rather than becoming separate work later.

This is also the point where a lot of companies realize their broader security or compliance program has gaps that made the incident more likely or more damaging than it needed to be, whether that's missing MFA, flat network architecture, or no logging retention policy. Fixing the root cause is part of the engagement, not an optional add-on.

Where a Partner Actually Changes the Outcome

The value of an outside incident response partner isn't just technical skill, it's speed and objectivity. Named responders who already know your environment (from a retainer relationship, not a cold start) cut hours off the triage phase. An SLA means you know exactly when help arrives instead of hoping. And because the retainer model spreads a fixed cost across the year rather than requiring a full-time internal SOC team, it's typically far cheaper for small and mid-sized companies to retain outside expertise than to staff and maintain 24/7 internal monitoring and response capability year-round.

This matters just as much for a scaling SaaS company in Vancouver or Calgary as it does for a financial services firm in Montreal. Incident response readiness has become a baseline expectation from enterprise customers and cyber insurers alike, and having a named, tested response plan is often the difference between a contained incident and a headline.

Getting Ready Before You Need It

The best time to figure out your incident response process is before an incident, not during one. That means having a retainer in place, named contacts on both sides, and a tested communication plan so the first hour of a real incident is execution, not scrambling to find a vendor.

If your organization doesn't have an incident response plan in place, or you're not confident the one you have would hold up under a real intrusion, contact traztech to talk through a retainer built for your environment and your risk profile.

Who Actually Authorizes the Responder

The most common delay in the first twelve hours has nothing to do with technology. It is that nobody knows who is allowed to sign the engagement letter. If you carry cyber insurance, the policy almost certainly names a panel of approved forensics firms and approved breach counsel, and work done outside that panel may not be reimbursed. Some policies also require notice to the carrier before costs are incurred at all. Read that section now, while nothing is on fire, and put the carrier's hotline number in the plan next to the responder's. Then settle who signs, because a founder, a CFO and a general counsel who each believe someone else has authority will burn a night arguing about it.

Counsel first is not a legal technicality. In most Canadian and US matters the forensics firm is retained by external counsel rather than by the company directly, so the investigative work product sits under privilege. That changes nothing about how the technical work is done. It changes a great deal about who can later subpoena the draft timeline in which an engineer speculated, wrongly, about the initial access vector.

Evidence You Destroy in the First Hour Without Meaning To

Well-intentioned first responders wreck more evidence than attackers do. The instinct is to reboot, reimage, revoke everything and get back to work. Rebooting a compromised host clears memory, and memory is where you find injected processes, decrypted payloads and live connections. Reimaging before acquisition removes any chance of establishing dwell time, which is the number your regulator, your insurer and your largest customer will all ask for. Restoring from backup over a compromised volume overwrites the file system timeline you needed to show which records were touched.

The safe order is capture, then isolate, then remediate. Image memory if the host is still running. Snapshot the volume rather than deleting the instance. Pull cloud audit logs immediately, because default retention in many SaaS admin consoles is 90 days or less and some identity providers keep sign-in logs for 30 days on lower licence tiers. Export before you change configuration, since rotating credentials generates thousands of new events that push older ones out of the visible window. Isolating a host at the network layer preserves evidence. Powering it off destroys the best of it.

When You Should Not Call an Incident Response Firm

Plenty of security events do not need external responders, and paying for them anyway trains your team to escalate instead of think. A single phishing click with no credential entry, caught by the mail gateway, is a ticket, as is a laptop with commodity adware that the endpoint agent confirmed and you reimaged the same day. A failed login spike against an account with hardware-backed multi-factor authentication is a tuning problem. Handle these internally and record them, because that record is what shows an auditor your process works at low severity.

Call for help when an attacker has reached an identity provider or a cloud control plane, when data has been staged or moved, when production data is encrypted or destroyed, when there is a hands-on-keyboard adversary rather than automated malware, or when a notification decision turns on facts you cannot establish yourself. If your incident is genuinely small and your real problem is having no process for the next one, buy the plan work instead of the emergency. A written plan, severity tiers and a tabletop cost a fraction of a live response. Those sit on our fixed-scope pricing page, and the standing arrangements that shorten a real response, the tabletop and the logging review, are on the retainer and incident response page.

What Your Auditor Asks About the Incident Afterwards

Six months later a SOC 2 or ISO 27001 auditor will sample your incident log and pull this one. They are not evaluating whether you were breached. They are testing whether the control operated. Expect them to ask for the ticket with its opened and closed timestamps, the severity assigned and why, evidence that the people named in the plan were the people who acted, and the post-incident review with dated remediation items that actually closed. Remediation logged and never completed is a more common finding than the incident itself. Keep the record in the same system you use for ordinary tickets so timestamps are system-generated, and give every review item a named owner and a due date. That is the difference between an incident that strengthens your compliance position and one that becomes an exception in your report.