Incident Response Requirements: A Practical Checklist

At minimum, incident response requirements mean a written plan, named responders with defined roles, a tested notification process, and a signed retainer or internal team ready to act within a set SLA, typically one hour for detection and containment to begin. Below is the checklist we use when we help Canadian companies stand up or audit their program.

Do You Have a Written Incident Response Plan

Not a slide deck. A document that names who does what, in what order, with contact information that stays current. Auditors for SOC 2, ISO 27001, and most cyber insurance underwriters will ask for this by name. If your plan lives only in someone's head, it fails the moment that person is on vacation or leaves the company.

• Scope defined: what counts as an incident versus a routine alert.
• Severity tiers: a P1 ransomware event is handled differently than a phished employee account.
• Version control: reviewed and dated at least annually, more often after a real incident.

Named Responders With Defined Roles

"IT will handle it" is not an answer regulators or auditors accept. You need named individuals for incident commander, technical lead, communications lead, and legal counsel, each with a backup. Small and mid-sized companies in Toronto, Waterloo, and Ottawa often run lean security teams, which is exactly why the roles need to be explicit rather than assumed. If your technical lead is also your only sysadmin, you have a single point of failure baked into your response plan.

Service Level Agreements for Detection and Containment

An SLA turns "we'll get to it" into a measurable commitment. Common benchmarks:

• Acknowledgment: within 15 to 30 minutes of a confirmed alert.
• Initial triage: within one hour.
• Containment started: within four hours for high-severity events.
• Client or stakeholder notification: within 24 to 72 hours, depending on contractual and regulatory obligations.

These numbers matter for insurance renewals and for enterprise procurement questionnaires, which increasingly ask for documented SLA commitments rather than a general statement of intent.

An Incident Response Retainer or an In-House SOC

This is the decision point most growing companies hit. Building a 24/7 internal security operations centre means hiring, training, and retaining specialized staff around the clock, a cost that rarely makes sense until a company is well past a few hundred employees. A incident response retainer gives you named responders on call, pre-negotiated SLAs, and a lower fixed cost than carrying that headcount internally, without the coverage gaps that come from relying on whoever happens to be online when something breaks.

Detection and Logging Coverage

You cannot respond to what you cannot see. A checklist item auditors probe hard:

• Centralized logging across cloud infrastructure, endpoints, and identity providers.
• Alert thresholds tuned enough to catch real incidents without drowning the team in noise.
• Log retention that meets both your compliance framework and any Canadian privacy obligation for breach investigation.

Communication and Notification Procedures

Incident response is not purely technical. Canadian organizations carry specific notification duties. Under PIPEDA, a breach involving personal information that creates a real risk of significant harm must be reported to the Office of the Privacy Commissioner and affected individuals, and records of every breach must be kept for two years even if it did not meet the reporting threshold. Quebec's Law 25 adds its own notification timeline and register requirements for any business handling Quebec residents' data. Build your communication tree, including legal counsel and, where relevant, cyber insurance carriers, before an incident forces you to figure it out live.

Tabletop Exercises and Plan Testing

A plan that has never been rehearsed is a plan you are testing for the first time during a real breach. Run a tabletop exercise at least annually, walking the response team through a realistic scenario, ransomware, a compromised admin credential, a third-party vendor breach, and time how long it actually takes to move through detection, containment, and notification. This is also where gaps in the named-responder list surface, usually the backup contact nobody updated after a role change.

Vendor and Third-Party Breach Coverage

Your incident response plan needs to cover breaches that originate outside your own environment. If a SaaS vendor, payment processor, or contractor suffers a breach that exposes your data, your plan should specify how you find out, how fast, and what your own notification obligations become as a result. This is a frequent gap in companies scaling quickly across Toronto, Vancouver, and Calgary tech hubs that add vendors faster than they update their vendor risk register.

Post-Incident Review and Documentation

Every incident, resolved or contained, should generate a written post-mortem: what happened, how it was detected, what worked, what did not, and what changes follow. This documentation is what auditors and cyber insurers want to see, and it is what actually improves your response time the next time.

Why the Checklist Matters More Than the Tooling

Companies often buy detection tools first and figure out process second. It should be the other way around. A well-documented plan with named responders and clear SLAs, backed by a retainer for after-hours coverage, closes more audit findings and prevents more damage than another dashboard. If your company is working toward SOC 2 or a broader compliance program, incident response sits alongside compliance readiness as one of the first things auditors check.

traztech works with companies across Toronto, Waterloo, Ottawa, Vancouver, Calgary, and Montreal to build incident response plans that hold up under audit and under real pressure, backed by named responders and a fixed-cost retainer instead of an expensive internal SOC build-out. Contact us to talk through your current plan and where the gaps are.

Severity Tiers That Someone Can Actually Apply at 3am

Most plans define severity in language that only works in daylight. "Significant impact to the business" is not a criterion, it is a discussion. The tiers need to be written so that the on-call engineer who found the alert can classify it alone, without waking anyone up to ask.

Write each tier against observable facts. A high-severity event is one where any of a short list of conditions is true: production customer data is confirmed or suspected to have been accessed by an unauthorized party, an administrative credential is confirmed compromised, encryption or extortion activity is observed, a production service is unavailable due to suspected malicious action, or a regulator, customer or researcher has told you about a breach before you found it. Any one condition triggers the tier. Lower tiers are defined the same way, against facts rather than judgement.

Then write down who may declare, and make the list longer than you think. If declaration authority sits with one executive, your effective response time is that person's availability. Give the authority to everyone on the on-call rotation, and make over-declaration explicitly safe. The plan should say, in a sentence, that nobody has ever been criticised for declaring an incident that turned out to be nothing. Otherwise the engineer who is not sure spends forty minutes trying to be sure, and those forty minutes are the ones that matter.

Runbooks Beneath the Plan

The plan describes roles and process. It does not tell anyone what to type. Underneath it you need a small number of scenario runbooks, and four cover most of what actually happens to companies your size.

Compromised user or admin credential. Revoke active sessions, not just the password. Check for persistence in the identity layer: added MFA methods, new app passwords, OAuth grants to third-party applications, mail forwarding rules and inbox rules that hide replies. Pull sign-in logs for the account going back as far as retention allows and identify every resource it touched.

Ransomware or destructive activity. Isolate at the network level rather than powering systems off, confirm backup integrity before you touch anything else, and identify whether backups themselves were reachable from the compromised credentials, because in most cases they were.

Leaked secret in code or a public repository. Rotate first, then work out the exposure window from the commit history, then check the logs of everything the secret could reach for use during that window. Rotating without checking usage is the step teams skip, and it is the step that determines whether this was an exposure or an intrusion.

Third-party or vendor breach. Determine what data of yours the vendor held, under what contract, and what your own notification obligations become. This runbook is mostly questions, and having them written down in advance is what stops the first day being spent looking for the vendor contract.

Each runbook should name where the logs live, which account has authority to act, and what to preserve before acting. Two pages each is plenty. A twenty-page runbook does not get read during an incident.

The Clocks You Are Actually Running Against

The checklist item is notification, but there is rarely one deadline. Most Canadian companies are running four clocks at once, and they do not start at the same moment.

Under PIPEDA, a breach of security safeguards involving personal information must be reported to the Office of the Privacy Commissioner and to affected individuals as soon as feasible where it creates a real risk of significant harm. The assessment of that risk turns on the sensitivity of the information and the probability of misuse, and the records requirement applies to every breach, including ones that fall below the reporting threshold, kept for twenty-four months. Quebec's Law 25 requires prompt notification of a confidentiality incident presenting a risk of serious injury and maintenance of an incident register.

Contractual clocks are usually tighter than statutory ones and get missed more often. Enterprise customer agreements routinely require notification within twenty-four or forty-eight hours of becoming aware of a security incident affecting their data, sometimes with a definition of incident far broader than a confirmed breach. Nobody reads those clauses until they are in one. Pull every enterprise contract you have signed, extract the notification clause and the definition, and put the shortest one in your plan as the governing deadline. If you process card data, the card brand and acquirer notification obligations run separately again, and if you hold data on individuals in Europe the seventy-two hour regime applies on top.

The practical output is a table in your plan showing each obligation, who triggers it, what the deadline is measured from, and who drafts the notice. Build it before an incident, because the day you need it you will also be trying to work out what happened.

Exit Criteria and Closure

Nearly every plan we review describes how an incident starts and none describe how it ends. Without exit criteria, incidents either get declared closed while the attacker still holds access, or drag on as an open ticket for weeks because nobody wants to be the person who called it.

Closure should require four things to be true and recorded: the initial access path is identified and closed, all identified persistence is removed and verified, monitoring specific to this event has run clean for a defined period, and the notification obligations above have been discharged or formally assessed as not applicable. Write down who signs each one. If you cannot identify the initial access path, that is an acceptable outcome, but it needs to be stated explicitly rather than glossed, because it changes how much confidence anyone can place in the containment.

What Auditors and Insurers Actually Ask For

The gap between having a program and evidencing one is where audit findings live. For SOC 2 and ISO 27001 the requests are predictable: the current plan with a version history and an approval date, the incident register for the period, and a sample of tickets from that register traced end to end. Tracing means the auditor picks two or three entries and follows them from detection through triage, containment, resolution and post-incident review, checking the timestamps line up and the people involved match the roles in the plan.

Two things trip companies here. An empty incident register for a full year reads as under-detection rather than as a quiet year, so log the low-severity ones too. And a plan whose approval date is the week before fieldwork tells the auditor the program was assembled for the audit, which invites harder sampling everywhere else.

The tabletop evidence request is separate: the scenario used, who attended, what was found, and what changed as a result. An exercise report with no findings and no follow-up actions is treated as a meeting, not a test. Insurers ask for a narrower set at application and renewal, usually confirmation that the plan exists and has been tested in the past twelve months, alongside attestations about multi-factor authentication coverage, backup practice and endpoint detection. Those attestations are contractual statements, so check them against reality rather than intent before signing.

Metrics Worth Tracking

Four numbers tell you whether the program is improving. Time from first signal to declaration, which measures whether people are willing to pull the trigger. Time from declaration to containment started, which measures whether the runbooks and access work. Percentage of incidents with a post-incident review completed within a week, which measures whether learning survives the return to normal work. And percentage of post-incident actions closed within their target date, which is the one that quietly predicts whether you will have the same incident twice.

Track them on the incidents you actually have, including the small ones. A company that only measures the serious events has a sample size of nearly zero and no way to know whether anything is getting better.

Common Ways the Checklist Passes and the Program Still Fails

The contact list lives in the system that is compromised. A plan stored only in the corporate wiki, with phone numbers in the corporate directory, is unavailable during exactly the incidents where you need it. Keep an offline copy with personal mobile numbers, refreshed quarterly.

The plan assumes an environment you no longer have. Plans written around on-premises servers survive migrations to cloud infrastructure unnoticed for years, because nobody re-reads a document that is not being used. Any material infrastructure change should trigger a plan review.

Roles are filled by the same person three times. In a small company the incident commander, technical lead and communications lead are often one exhausted engineer. That is workable if it is acknowledged and a backup is named for each role, and dangerous if the plan pretends otherwise.

Legal is looped in last. If external counsel is going to be involved, they should be involved from the declaration, not after the technical work is finished, because privilege and notification analysis both depend on how the engagement was structured from the start.

When You Should Not Buy Any of This Yet

If you have no centralized logging and no managed endpoints, a retainer and a polished plan will not help you. The responder arrives and finds nothing to look at. Spend first on visibility: one identity provider with multi-factor authentication enforced, endpoint detection actually deployed, cloud audit logs retained for months rather than weeks, and backups you have restored from at least once. That work closes more of this checklist than any document will, and it is the same work your framework will require later.

If you are a small team with no customer personal information and no regulatory exposure, a two-page plan you wrote yourself, an offline contact list, and a firm you have spoken to once and could call is a proportionate answer. Do not let anyone sell you a full program because a questionnaire asked a question. And if your cyber policy already places you with a panel responder, confirm the response commitments in the policy before buying a second arrangement that duplicates them.

Where outside help earns its cost is when an enterprise contract, an audit or a regulator has put a deadline on you, or when the same handful of people cannot both run the business and hold the response. That is the point to look at a retainer, and the point where the plan, the runbooks and the evidence should be built together rather than as three separate purchases.