Incident Response Basics: A Guide

What is incident response?
Incident response (IR) is the organized approach to handling a suspected cyber attack or data breach. Recognized practice breaks it into phases: preparation, detection and analysis, containment, eradication and recovery, and post-incident review. An IR plan documents, before anything happens, who does what in each phase — so the first hours are executed, not improvised.

Why do the first hours matter so much?
Early actions are hard to undo. Well-meaning staff may wipe or rebuild infected machines, destroying the evidence needed to determine what data was taken, or delay escalation while an attacker is still active. A practiced response contains the incident faster, preserves evidence, and gets notifications moving within required timeframes.

Why do public entities need a plan?
Public entities run services that cannot simply pause — utilities, courts, payroll, emergency dispatch — and face statutory breach notification duties, records requests, and media scrutiny that private firms may not. With small teams wearing many hats, a written plan and pre-arranged outside help matter more, not less, than in a large enterprise.

What if we don't prepare?
Without a plan, outages tend to last longer and cost more, regulatory notification deadlines can be missed, and evidence needed by forensic investigators or law enforcement may be lost. Late notice to your insurer or pool could also complicate coverage for costs the policy was designed to pay.

What frameworks should we be aligned to?
NIST Cybersecurity Framework (CSF) 2.0 dedicates two of its six functions to this topic: Respond and Recover. CIS Controls v8 addresses it through Control 17 (Incident Response Management), which covers designating personnel, establishing contacts, defining processes, and exercising the plan.

Process defenses: plan, assign, and rehearse
Keep a written IR plan naming an incident lead and backups, with a 24/7 contact list: your insurer or risk pool hotline, breach counsel, IT provider, and law enforcement. Store copies offline in case systems are down, and run a tabletop exercise at least annually so roles are familiar before they're needed.

Practical do's and don'ts for the first hours
Do isolate affected machines from the network, preserve logs, and notify your insurer or pool early. Don't wipe or rebuild systems before evidence is captured, don't power off machines unless instructed by responders, and don't communicate with an attacker or discuss the incident broadly before counsel is engaged.

Checklist
When building or reviewing your incident response readiness, consider the following:

Do you have a written incident response plan with a named incident lead and designated backups?
Does your 24/7 contact list include your insurer or pool hotline, breach counsel, and IT provider? implemented.
Are copies of the plan and contact list stored offline, where they remain reachable during an outage?
Have you run a tabletop exercise testing the plan within the last 12 months?
Are system and security logs retained long enough to support a forensic investigation?
Do staff know how to report a suspected incident, and to isolate rather than wipe affected machines?

Incident Response Basics: A Guide

How an organization acts in the first hours of a suspected cyber incident often determines whether it becomes a manageable event or a prolonged crisis. Here is KYND's guide to incident response basics — what to prepare, who to call, and what to avoid when something goes wrong.