Ransomware Recovery Priorities for Small Cities
Security Intermediate 7 min read

Ransomware Recovery Priorities for Small Cities

Ransomware recovery priorities for small cities: a service and dependency matrix, a four-tier restore model and controlled manual procedures.

Published: November 3, 2026 • Updated: November 3, 2026
ransomwareincident recoverylocal governmentcontinuity planningtraining

Ransomware recovery priorities for a small city should follow services, not departments. Rebuild a trusted foundation first (identity, networking, logging and backups), then restore what protects life and safety, then time-sensitive money and legal work, then resident portals and back-office tools. The exact order is a local decision. This guide gives a service and dependency matrix, a four-tier model and controlled manual procedures so departments can keep working while networked systems stay isolated.

What the Columbia, South Carolina incident shows

The City of Columbia, South Carolina, said a ransomware attack discovered on October 20, 2026 affected some public services. According to the city's October 23 website update, as reported by South Carolina Public Radio, IT contacted the State Law Enforcement Division (SLED), took impacted services offline as a precaution and brought in third-party cybersecurity professionals.

The reported unavailable services were MyColaSC, Animal Services, Parks and Recreation reservations and the city's Geographic Information Systems (GIS). The city said police, fire, 911 communications, Columbia Water and its Payment Center, including online payment options, remained operational, and residents could phone in requests normally made through MyColaSC. The city did not say when affected services would return.

The reporting does not describe the attack vector, architecture, restoration order or a recovery date, and this article infers none of them. What follows is general planning guidance, not a description of Columbia's response.

Why is a restoration list not a department ranking?

Residents experience services, and each service depends on systems that several departments and vendors own. Ranking Finance first says nothing about which identity, network, database and processor dependencies must be rebuilt before a payment counter works again.

Weigh five things for each service: health and safety, legal deadlines, revenue and payroll, resident impact, and hidden dependencies. The CISA and MS-ISAC #StopRansomware Guide asks organizations to know which systems are most critical for health and safety, revenue generation or other critical services, and to understand their interdependencies, so restoration priorities are clear before an incident. Those categories are a starting point, not a fixed municipal order.

Build a service and dependency matrix for recovery priorities

List 10 to 20 services residents or staff would miss within days, not a list of servers. NIST SP 800-34 describes the business impact analysis as the step that identifies and prioritizes the systems behind mission and business processes; the matrix is a lightweight version. For each service, record:

  • Service owner: the department head who defines "working" and accepts the workaround.
  • Minimum acceptable service: the smallest useful version, such as phone requests without online tracking.
  • Maximum tolerable outage: the owner's judgment of how long the service can be down before harm, legal exposure or lost revenue. Set it locally.
  • Systems and identity dependencies: applications, servers, directory accounts, single sign-on, DNS, network segments and certificates.
  • Data source: where the records live and the date of the last trusted backup.
  • Vendor or state dependency: hosted platforms, payment processors, state portals and support contacts.
  • Manual fallback: the approved offline procedure and where its forms are kept.
  • Backlog owner: who re-enters and reconciles manual records.
  • Safe reconnection criteria: what must be verified before the service rejoins the network.

A four-tier model for ordering recovery

Use tiers to group the matrix, then reorder when local impact or deadlines require it.

  • Tier 0, clean recovery foundation: incident command communications, trusted administrator access, identity, DNS and core networking, logging and monitoring, backup and recovery infrastructure, and a clean recovery environment where one is used. Protect the backup platform as carefully as identity; see why your backup server is a tier-0 target.
  • Tier 1, life safety and essential operations: support for 911 and public safety, and water and wastewater operations, according to local architecture and the authorities that run them. Some of these systems may be separate from city IT, so the city's job can be protecting shared dependencies rather than restoring the system itself.
  • Tier 2, time-sensitive resident and financial operations: payment acceptance, payroll, emergency procurement and legally time-bound work such as required notices.
  • Tier 3, resident portals and lower-impact services: request portals, permitting, reservations, GIS publishing, records requests and back-office tools. Move an item up when a statutory deadline or resident harm justifies it.

A visible application cannot safely return before its identity, network, database, logging and vendor dependencies are trustworthy. CISA's ransomware response checklist calls for restoring critical systems on a clean network, rebuilding based on the prioritization of critical services, and adding only clean systems to a recovery network so restored systems are not reinfected.

What must be true before a service reconnects?

Its identity source, network path, database, logging and vendor connections must be rebuilt or verified clean, and both the service owner and the incident lead must sign off. Department pressure is not a reconnection criterion.

Write example criteria into the matrix in advance: service accounts reset after cleanup, host rebuilt from a known good image or verified by the response team, logs reaching monitoring, the vendor's side of any integration confirmed, and restored data checked for completeness.

Controlled manual procedures for departments

Manual work buys time; it does not replace the system. NIST SP 800-34 lists performing affected processes by alternate manual means as an option typically acceptable only for short-term disruptions. The templates below are examples. Each needs approval before an incident from the service owner and, as applicable, legal and privacy staff, finance, records management and public safety leadership.

  • Resident service requests: a published phone line and a numbered intake log with the request, location, callback number and the staff member taking it.
  • Public works dispatch: printed work orders from the intake log, assigned by a supervisor and closed with a completion note for later entry.
  • Payment intake: only if finance approves an offline method. Pre-numbered receipts, two people counting and signing each batch, daily totals and no handwritten card numbers.
  • Permits and inspections: date-stamped paper intake and approved inspection forms. Decisions that depend on records the city cannot check should wait, and the applicant should be told in writing.
  • Internal approvals: signed paper approvals, with two approvers for anything that moves money.

Public safety dispatch, water and wastewater operations and other operational technology have their own continuity procedures owned by those agencies; this guide does not replace them.

Safeguards for manual records

  • A unique ticket or receipt number from a pre-numbered sequence.
  • Date, time and staff identity on each entry.
  • Two-person approval for money, refunds or account changes.
  • Only the sensitive data the eventual system entry needs.
  • Locked storage, a named custodian and a sign-out log.
  • Daily totals reported to the backlog owner.
  • Chain of custody for records that may become evidence.
  • Reconciliation rules agreed before re-entry: who enters, who checks and how mismatches are resolved.

What should departments not do during recovery?

Do not reconnect systems or improvise workarounds outside the incident lead's decisions. Manual procedures exist so that pressure to restore a service early does not reopen the network.

  • Do not reconnect a system because a department is under pressure; use the reconnection criteria.
  • Do not run a workaround on a device that may be compromised.
  • Do not create uncontrolled spreadsheets of resident information on personal or unmanaged storage.
  • Do not discard paper records after re-entry unless records management confirms the retention schedule allows it.
  • Do not let manual payments skip dual control or reconciliation.

One-page planning checklist

  • Name an owner for each of 10 to 20 services and complete the matrix.
  • Agree tiers with department heads, public safety and utility leadership, and record the reasons.
  • Write reconnection criteria for every Tier 1 and Tier 2 service.
  • Draft manual forms and get them approved.
  • Keep printed copies of the matrix, forms, contacts and incident response plan; CISA recommends a hard copy and an offline version of the plan.
  • Confirm offline, tested backups for each data source.
  • Assign backlog owners and reconciliation rules.
  • Validate public safety, water and wastewater, finance, records retention, privacy and labor requirements locally.
  • Review the matrix yearly and after major system changes.

Use the matrix in your next tabletop

The 60-minute ransomware tabletop for a small IT team includes a recovery decision inject. Bring the matrix to it and test whether the team can explain each service's tier and its reconnection criteria. Department leaders can rehearse the manual forms separately.

FEMA's Continuity Guidance Circular places continuity responsibility on local governments too, and its first planning step is identifying essential functions. This matrix applies that step to IT-dependent services. It is not legal advice, sets no recovery times and does not replace counsel, insurers or the agencies that run public safety and utility systems.

Sources