Writing an incident response plan a small agency team can follow

Reference article · 5 min read

Most incident response plans in small agencies were written to satisfy something: an audit finding, a grant condition, an insurance application. Those plans tend to be long, generic, and unread. A plan that holds up during a real incident is shorter, and it answers the questions people ask at two in the morning while systems are down.

This covers what belongs in one. It assumes a few people rather than a security operations center: an IT director, a couple of administrators, perhaps a managed service provider. NIST Special Publication 800-61 is a reasonable structural reference, but a small team does not need to reproduce it. It needs decisions made before they are needed.

Severity levels with examples from your own systems

Severity levels tell people how hard to push and whom to wake up. Three or four are enough, and what makes them usable is examples from systems the agency actually runs.

Low. One workstation with malware, contained by endpoint tooling. Handled during business hours by whoever is on duty.
Moderate. A confirmed phishing compromise of a staff mailbox, or unexplained administrator account activity. Notify the IT director the same day and begin preserving evidence.
High. Anything affecting a system the public or field staff depend on: utility billing, permitting, the records or dispatch system. The call list activates immediately.
Critical. Confirmed ransomware, suspected exfiltration of resident or employee data, or loss of a system supporting emergency operations. Executive and legal notification at any hour.

Write each level with its trigger, who is notified, and how fast. A plan that says "significant impact to critical systems" leaves the judgment to whoever is most tired.

Named roles, and who may disconnect

Assign roles by position title, not by person, with an alternate for each: an incident commander who runs the response rather than doing technical work, a technical lead, a communications lead, and a liaison to counsel and the insurer.

The role most often missing is containment authority. State plainly who may take a system offline, isolate a network segment, disable accounts, or pull an internet connection without first getting an executive on the phone. Small teams lose hours because the administrator who saw the problem was not certain they could act. Pre-authorization in writing, paired with a duty to notify immediately afterward, removes that hesitation. Include the limits: if a shutdown would interrupt 911 service, a utility control system, or a court function, say who must be consulted.

The call list

Keep it to one page, organized by role with alternates, with after-hours paths for the managed service provider and core application vendors, and keep a printed copy. A list stored only in email or on the file server is unavailable when it matters.

Executive leadership. The city manager, county administrator, or superintendent, the department heads owning affected systems, human resources if employee data is involved, and the public information officer.
Legal counsel. Call early. Counsel often directs the investigation and tracks breach notification deadlines, which differ by state and by data type.
Cyber insurance carrier or broker. Policies commonly require prompt notice and often require response firms from an approved panel, so hiring your own forensics vendor first can complicate coverage. Record the policy number, claims hotline, and notice window.
CISA. The Cybersecurity and Infrastructure Security Agency accepts incident reports from state and local governments and can offer assistance.
MS-ISAC and the state. The Multi-State Information Sharing and Analysis Center serves state, local, tribal, and territorial governments. Many states also route incidents through a state chief information security officer, fusion center, or homeland security office. Terms and channels change, so confirm yours.
Law enforcement. Your FBI field office and any state police cyber unit. Criminal justice information carries separate expectations under the CJIS Security Policy, and health information may carry HIPAA obligations.

Evidence preservation

Isolate rather than erase. Remove affected systems from the network instead of reimaging them.
Capture logs immediately. Firewall, VPN, identity provider, email, and endpoint logs are often retained briefly by default. Export copies outside the affected environment.
Protect backups. Verify that offline or immutable copies exist and are untouched, and stop any job that would overwrite good backups with compromised data.
Keep a written timeline. Time, person, action, system, time zone, recorded somewhere outside the affected environment if email and file shares are untrusted. It supports the insurance claim and the notification analysis.

Who approves a public statement

Name one person who approves external statements and one backup, and say whether counsel and the insurer review first. Draft short holding language in advance for a service outage and for a suspected data compromise, and say who tells staff what to do. Avoid early claims about cause, attribution, or record counts, because those change and corrections are costly. Assume internal messages may become public records.

Keeping it usable, and what to require of vendors

Review the contact list on a schedule, run a tabletop exercise at least annually, and keep printed copies offsite.

Contracts. Require vendors to report a security incident affecting agency data within a defined period, cooperate with the investigation, provide log access, and return or delete data at termination.
Managed service providers. Ask what the contract obligates during an incident, who directs the work, and whether response hours are billed separately.
Hosted applications. Ask where logs are kept, how long they are retained, and how fast the agency can obtain them.
Insurance. Ask for the approved panel and the notice requirements while you are renewing, not while you are responding.

Requirements change, so confirm reporting obligations with counsel and the official source. HQT works with state and local agencies on cybersecurity planning, assessments, and the technical work that follows an incident.

Frequently asked questions

What should a local government incident response plan include?

At minimum it should define severity levels with examples from the agency's own systems, name response roles by position title with alternates, state who is authorized to take systems offline, and provide a one-page call list covering leadership, counsel, the cyber insurer, CISA, the state or MS-ISAC contact, law enforcement, and key vendors. It should also describe evidence preservation steps and name who approves public statements. Anything longer than that tends to go unread during an actual incident.

Who decides whether to take a county or city system offline during a cyber incident?

The plan should decide it in advance rather than leaving it to the moment. Most agencies pre-authorize the IT director or an on-duty administrator to isolate systems, disable accounts, or disconnect network segments, with a requirement to notify leadership immediately afterward. Where a shutdown would interrupt 911 dispatch, a utility control system, or a court function, the plan should name the executive or department head who must be consulted first and how to reach them at any hour.

Do local governments have to report cyber incidents to CISA or MS-ISAC?

CISA accepts incident reports from state and local governments and can provide assistance, and for many local agencies that reporting is voluntary rather than mandatory. Specific obligations can still arise from state law, breach notification statutes, grant conditions, contracts, or sector rules such as the CJIS Security Policy or HIPAA. Reporting requirements and federal programs change over time, so confirm current obligations with your counsel and the official sources before relying on a template.

When should we notify our cyber insurance carrier after a ransomware attack?

As early as you reasonably can, and before hiring a forensics firm. Policies commonly require prompt notice and often limit response work to firms on an approved panel, so engaging your own vendor first can create coverage problems. Keep the policy number, the claims hotline, and the notice window on the printed call list so nobody has to find the policy while systems are down.

How often should an incident response plan be reviewed and tested?

Review the contact list on a set schedule, since staff turnover and vendor changes break it faster than anything else in the document. Run a tabletop exercise at least once a year, ideally with the executive who would approve a public statement in the room. Update the plan after every exercise and after every real incident, and keep printed copies offsite in case the environment is unavailable.