Building Cyber Resilience: A Guide for Police Executives

Key Takeaways

• A cyber incident that knocks out computer‑aided dispatch (CAD), records, warrants, or jail systems still leaves radios and 911 phones functional, but the loss of those back‑end systems severely degrades speed, visibility, and confidence.
• Police leaders must treat the event as an incident‑command problem, not merely an IT recovery task, deciding which services stay online, when to go manual, who has authority to act, and how evidence and public trust are protected.
• Essential preparedness steps include: defining mission‑critical services and tolerable downtime; putting decision‑making authority in writing; building a single contact‑and‑reporting list; verifying baseline protections (CIS IG‑1, FBI CJIS, NIST OT guidance); separating business and operational networks; preserving evidence without compromising safety; and regularly exercising command‑failure scenarios.
• Resources such as the Center for Internet Security (CIS) Controls and the Multi‑State Information Sharing and Analysis Center (MS‑ISAC) provide useful checklists and threat intel, but the ultimate decisions about service continuity, manual work‑arounds, and system restoration remain with agency leadership.

Mission‑First Thinking Over Technology Inventory
Before counting devices or patching servers, chiefs and sheriffs should identify which services must stay uninterrupted and which can tolerate delays of four, twelve, or twenty‑four hours. Critical functions typically include CAD, records‑management, jail‑management, evidence systems, login/account services, radio‑support systems, fuel access, backup power, building controls, and any outside utilities or vendors. Documenting a manual alternative for each function and the point at which reduced operations become unsafe creates a clear baseline for decision‑making during an incident.

Clarifying Authority and Responsibility
Ambiguity about who can act prolongs response time. Agencies must put authority in writing: name the individuals who may activate continuity procedures, disconnect or reconnect computer systems, approve changes to operational or facility systems, authorize emergency spending, release public information, and approve a system’s return to service when residual risk remains. Primary and alternate contacts should be recorded, and an offline copy kept for command staff. When these roles differ—as they often do between incident command, IT, facilities, and procurement—having them documented prevents costly debates while the situation evolves.

Building a Unified Contact and Reporting List
A single, up‑to‑date contact list streamlines communication. It should distinguish among a generic service outage, a suspected cyber incident, and a suspected cybercrime. Include internal points of contact, the system owner, insurer, state cyber office, MS‑ISAC or other cyber‑support contacts, the regional fusion center, the FBI field office, CISA, and any required regulators. Verify phone numbers, after‑hours procedures, and escalation paths quarterly so that, when an alert arrives, the right people are reached instantly.

Validating Baseline Protections
Using CIS Implementation Group 1 as a starting checklist ensures that basic defenses are in place for business systems. Layer on FBI Criminal Justice Information Services (CJIS) requirements and federal guidance for emergency services and operational technology. Command staff should be able to confirm: all devices are inventoried; accounts are protected by more than a password; administrator accounts are reviewed; unnecessary public‑facing services are removed from the internet; protected backups restore successfully; and response procedures have been exercised. These verifiable results give leadership confidence that the foundation is solid before an incident strikes.

Separating Business and Operational Networks
Keeping IT (business) and OT (operational) networks apart limits lateral movement of attackers. Require multifactor authentication for remote access, eliminate unused or shared accounts, and document any allowed connections between the two environments. Never permit security testing, software updates, or reconfiguration of safety‑critical systems—such as jail door controllers, water‑control networks, or building‑safety systems—without the system owner’s explicit approval, a safety and operational review, and a tested rollback plan. This distinction acknowledges that restoring a server may be trivial, while tampering with a physical process could endanger lives or property.

Preserving Evidence Without Sacrificing Safety
Digital evidence is volatile; network connections, memory dumps, and logs can disappear quickly. Agencies must decide in advance how long system activity records are retained, ensure all clocks are synchronized, and assign evidence‑handling responsibilities. Preserve short‑lived data when feasible, but never let the pursuit of a perfect forensic record delay actions required to protect life or prevent physical harm. Record who made each critical decision, when, and why—this creates an auditable trail that supports both internal reviews and any subsequent criminal investigation.

Exercising Command Failure, Not Just Technology Failure
Readiness is proven when leaders practice making tough choices under simulated loss. An exercise should remove account/login services, phones, vendor remote access, a critical database, and one operational system, forcing commanders to weigh evidence preservation, service availability, and life‑safety. Alabama’s “Grid Down” drill exemplifies this approach: it ends with named owners, funded corrective actions, and deadlines. Regularly rehearsing these scenarios exposes gaps in authority, communication, and contingency plans before a real event occurs.

Leveraging CIS and MS‑ISAC as Starting Points, Not Substitutes
For agencies lacking large cybersecurity teams, the CIS Controls offer a practical, prioritized roadmap; Implementation Group 1 supplies 56 foundational safeguards suited to limited resources. Command staff need not administer these controls themselves but should use them to ask technology providers: What is complete? What has been tested? What remains open? The MS‑ISAC extends this by delivering government‑focused threat warnings, peer contacts, and access to a 24‑hour security operations center that can help analyze and respond to incidents. Nevertheless, a membership logo or completed checklist does not guarantee protection, satisfy CJIS policy, or address the safety risks of OT systems. Leadership must still decide which services stay online, when to shift to manual operations, who may disconnect or restore systems, how evidence is safeguarded, what the public is told, and what verification is required before a system returns to service—decisions that belong in the agency’s own continuity and incident‑response plans, exercised regularly.

Seven Immediate Decisions for Chiefs and Sheriffs

1. Define mission‑critical services and acceptable downtime windows for CAD, records, jail, evidence, login/account, radio‑support, fuel, backup power, building controls, and outside utilities; document manual fall‑backs and safety thresholds.
2. Put authority in writing—specify who may activate continuity plans, isolate/reconnect systems, approve OT changes, authorize emergency spending, release public information, and approve restored service with residual risk; list primary and alternate contacts and keep an offline copy.
3. Create a unified contact‑and‑reporting list distinguishing outage, cyber incident, and cybercrime; include internal leads, system owners, insurer, state cyber office, MS‑ISAC, fusion center, FBI field office, CISA, and regulators; verify after‑hours procedures quarterly.
4. Confirm baseline protections using CIS IG‑1, FBI CJIS, and NIST OT guidance; verify device inventory, strong authentication, admin review, removal of unnecessary public services, successful backup restores, and exercised response plans.
5. Control remote access and segregate networks—require MFA, prune unused/shared accounts, document allowed business‑OT links, and forbid any changes to safety‑critical OT without owner approval, safety review, and a tested reversal.
6. Preserve evidence while protecting safety—set retention logs, clock sync, evidence‑handling roles; capture volatile data when possible but never delay life‑saving actions; log every key decision with timestamp and rationale.
7. Exercise command‑failure scenarios—remove critical services and force leaders to prioritize evidence, service continuity, and safety; conclude with assigned owners, funded fixes, and deadlines, mirroring exercises like Alabama’s “Grid Down.”

Readiness Is a Command Discipline
Cyber readiness does not promise that every system will stay online; it guarantees that the agency can continue to serve the public when some systems fail. The CIS Controls and MS‑ISAC give valuable checklists and threat intelligence, but they do not decide when deputies switch to paper, how a jail operates when electronic controls are untrusted, or what verification is needed before a system is restored. Those judgments remain with the individuals accountable for the mission. By making the seven decisions above, documenting authority, maintaining a clear contact web, validating baseline defenses, separating business and operational networks, safeguarding evidence, and regularly practicing command‑failure drills, police leaders transform cyber risk from an IT problem into a manageable facet of incident command—protecting officers, the public, and the integrity of the justice system.