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 SOC 2 certification 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.