Cybersecurity Best Practices for Connected Community Systems

We protect connected public services by assigning owners, limiting access, and testing safe recovery - not just installing security tools. One shared vendor, network, or account service can disrupt transit, water, power, and civic systems at once.

We use nine practices, guided by NIST CSF 2.0 and CISA, to turn that risk into clear tasks:

1. Assign owners: Name one accountable owner and one backup for each critical system.

2. Map dependencies: Record devices, data flows, vendors, and shared failure points.

3. Limit access: Require phishing-resistant MFA where supported and restrict staff and vendor permissions.

4. Separate networks: Control traffic between IT, OT, and public-facing services.

5. Monitor threats: Connect security alerts with changes in service and equipment behavior.

6. Protect systems and data: Secure settings, test updates, safeguard records, and isolate backups.

7. Practice response: Define decision rights, safety checks, reporting duties, and fallback modes.

8. Test recovery: Verify the full service - not just its servers - before reconnecting.

9. Measure results: Track coverage, response times, failed tests, and fixes that pass retesting.

Our starting point is simple: give each action an owner, deadline, and proof that it works. Review privileged access at least quarterly and exercise response plans at least annually. For equipment that controls physical processes, test changes with operators before deployment.

The goal is service you can safely restore. <u>A completed backup job does not prove recovery.</u>

9 Cybersecurity Practices for Connected Community Systems

Cyber Security: Protecting Data, Smart City Infrastructure and More from Cyber Crime

sbb-itb-8baf5f1

Apply NIST and CISA Guidance Safely

Use NIST Cybersecurity Framework 2.0 to organize security outcomes across Govern, Identify, Protect, Detect, Respond, and Recover. Create current and target profiles, then give each gap a deadline and require evidence that it has been closed.^[6][7] Use those profiles to guide decisions about ownership, segmentation, monitoring, and recovery.

CISA’s Cross-Sector Cybersecurity Performance Goals offer a baseline - not a complete security program. Map relevant goals to your profiles, starting with asset visibility, strong authentication, limited remote access, and tested recovery. CISA also recommends annual OT cybersecurity training for personnel who maintain or secure OT.^[8][10][11]

IT and OT need different change procedures. IT supports applications, business computing, and data processing. Operational technology (OT) monitors or controls physical processes. Industrial control systems (ICS) are a type of OT; SCADA is one ICS used to supervise distributed equipment. OT changes must put safety, reliability, and availability first. Even a routine scan, reboot, or authentication change can disrupt equipment that must run continuously.^[4][12] These differences shape how community systems segment networks and manage changes.

Before changing legacy equipment in production, require asset-owner approval, vendor review, representative testing, a verified configuration backup, and rollback steps. Schedule changes during controlled maintenance windows and confirm safe operation afterward. If patching or replacement is unsafe, use compensating controls: isolate the device, limit network paths to those required, route remote access through monitored jump servers, and use passive monitoring when active scans could disrupt operations. Document the specific risk, control owner, evidence of effectiveness, and review date.^[11][12]

Check applicable federal, state, contract, and grant requirements for your sector; adopting CSF and completing CPGs do not establish compliance.^{[6][8][10][5]} Use the resulting profile to assign segmentation, monitoring, and recovery tasks, with a named owner and a verification method for each control.

1. Name System Owners and Decision Makers

Control Objective and NIST CSF Function

Assign one accountable owner and one alternate to each critical system. Under NIST CSF 2.0’s Govern function, the owner has authority over resourcing, risk acceptance, escalation, and recovery priorities.^[6]

Implementation Steps

Define who can act during an incident. Build an ownership and decision-rights register that covers shared vendors, identity services, and network dependencies. State who can disable remote access, isolate networks, authorize shutdowns, notify the public, and approve a return to service.

Set risk limits for safety impact, data sensitivity, maximum outage, regulatory exposure, and recovery cost. Vendor contracts should spell out notification deadlines, evidence preservation, remote-access duties, and recovery support.^[14][15]

Short implementation checklist:

• ☐ Record each system’s owner, alternate, dependencies, outage limits, and recovery priority.

• ☐ Assign duties to operations, IT, security, legal, communications, procurement, and vendors.

• ☐ Keep an escalation directory offline or protected separately.

• ☐ Schedule quarterly cross-agency reviews and an annual executive review of funding and risk limits.

Transit, Water, Grid, and Civic-Data Uses

Assign service-specific decision makers for transit, water, grid, and civic-data systems. Their authority to act should match the risk they manage.

Verification Results and Service Outcomes

Track which critical systems have named owners and alternates, which vendor contracts include security duties, and which exceptions have approval and expiration dates.

During cross-agency incident exercises, measure the time from escalation to authorized containment, public communication, and restoration decisions. Report unresolved gaps quarterly, with an owner and deadline for each corrective action. These checks test whether governance supports action - not just paperwork.^[10][13][15]

Next, map the assets and data flows each owner must protect.

2. Map Critical Assets, Dependencies, and Data Flows

Control Objective and NIST CSF Function

Create one authoritative inventory of assets, services, dependencies, and data flows to guide access control, segmentation, and monitoring. NIST CSF 2.0’s Identify function calls for maintained inventories of hardware, software, services, systems, network flows, and data types.^[6]

Implementation Steps

Give each asset a unique ID and record its location, manufacturer, model, firmware or software version, network zone, owner, and technical custodian. Include its safety impact, restoration priority, support status, internet exposure, remote access, backup location, and last verification date. Flag unsupported equipment and single points of failure, linking each to a mitigation and replacement plan.^[16][19]

Start with passive or vendor-approved OT discovery. Cross-check switch logs, firewall records, engineering drawings, maintenance records, and backups. Use active scanning only after owner and vendor approval, representative testing, a maintenance window, and a rollback plan. For every authorized flow, map the source, destination, protocol, port, direction, authentication method, data type, purpose, and service owner.^[6][17]

Transit, Water, Grid, and Civic-Data Uses

Cover transit signaling and fare systems, water-treatment controls, grid protection and distributed-energy devices, and environmental and traffic sensors.

Include cloud services, APIs, portals, and sensitive civic records. Trace dependencies on power, communications, identity providers, DNS, vendors, and backups to identify shared failure points.^[18]

Verification Results and Service Outcomes

Track the share of in-scope assets with verified records, dependencies, flows, and recovery priorities. Count unknown devices, stale records, unsupported assets, exposed remote-access paths, and unresolved single points of failure.

Require owner validation after changes to equipment, firmware, networks, or vendor access. Set review intervals based on safety and service risk.^[13][19] Use the inventory to define access boundaries, trusted paths, and monitoring priorities.

3. Require Strong Authentication and Limit Access

Once assets are mapped, control who can reach them and what they can do. Transit, water, grid, and civic data systems share vendors and dependencies, so least privilege must follow the asset and data-flow map.

Control Objective and NIST CSF Function

Under NIST CSF 2.0’s Protect function, give each employee, operator, contractor, and vendor one individual account with only the access their job requires. Prohibit shared human credentials where supported, and document legacy exceptions. Keep standard and administrator accounts separate. Never use privileged identities for email or browsing.^[20][21]

Implementation Steps

Require phishing-resistant MFA wherever supported for privileged and remote access, including vendor connections. Use FIDO/WebAuthn security keys, passkeys, or PKI-based smart cards or certificates.^[10][22][23] Manually entered one-time codes are not phishing-resistant MFA.^[26]

Route remote OT administration through hardened, monitored jump hosts. Approve vendor access against a ticket, limit its destinations and permissions, set automatic expiration, and log sessions.^[24][25]

Give each machine identity a technical owner and access only to the APIs, devices, or databases it needs. Store secrets in a managed vault or hardware-backed keystore, and use short-lived credentials. Prohibit interactive service-account logins unless justified.

For legacy equipment, document the asset, limitation, risk owner, accepted risk, compensating controls, and fix date. Use isolated devices, restricted access windows, and extra logging and alerting. These controls reduce risk; they do not remove it.^[10][24]

Transit, Water, Grid, and Civic-Data Uses

Separate transit telemetry viewing from control commands; water monitoring from dosing changes; grid monitoring from protection-setting changes; and civic-data analysis from database administration or public posting.

Apply the same limits to badge and system access. Grant elevated permissions only for approved work - not simply because someone belongs to a team.^[20]

Verification Results and Service Outcomes

Review privileged, vendor, and emergency access at least quarterly, with system-owner approval. Use HR, procurement, identity management, and system-owner workflows to trigger prompt offboarding. Disable directory and local accounts, revoke sessions, certificates, and tokens, remove badges, and rotate exposed secrets.

Test that terminated users and expired vendor accounts cannot reconnect through direct, federated, remote, emergency, or cached access paths. Track MFA coverage, orphaned accounts, vendor expiration, revocation time, machine-identity ownership, and legacy exceptions by service area. Confirm that jump-host logs reach monitoring, and retain evidence of reviews and failed access attempts.^[10][20][24]

Use these access rules to guide network segmentation and service isolation.

4. Separate IT, OT, and Public-Facing Services

Control Objective

Once access is controlled, separate systems by trust boundary to limit how far a compromise can spread. Define boundaries by function, ownership, trust, and operational impact - not just location.^[27] Separate VLANs alone aren’t enough; enforce traffic controls between zones.^[21][28]

Implementation Steps

Apply default-deny rules at every boundary. Route IT–OT traffic through an industrial DMZ and controlled gateways, and block direct enterprise-to-controller access.^[10]

For each approved connection, document its source, destination, purpose, owner, and review date. Require approval from network, operations, and safety owners before changing a boundary.

Transit, Water, Grid, and Civic-Data Uses

Apply the same boundary rules across transit, water, grid, and civic-data systems, including safety systems, building controls, IoT, guest Wi-Fi, cloud workloads, and public portals. Share approved operational data through restricted, read-only intermediaries. Never expose OT databases or controllers directly.

Verification Results and Service Outcomes

Review diagrams and rules, then test allowed and blocked paths in a lab before testing in production. Work with operators to coordinate maintenance windows, process monitoring, and rollback. Avoid active scanning of sensitive OT.

Confirm that monitoring receives boundary decisions and gateway sessions. Track direct IT–OT paths, owner-approved rules, and overdue reviews. Reassess after major changes and at least annually, using these records to update monitoring points and recovery priorities.

Keep one boundary register for each zone pair. Record the owner, permitted traffic, intermediary control, system constraints, and test evidence.

5. Monitor Security Events and Process Anomalies

Control Objective

Once ownership, access, and segmentation are defined, monitor security events alongside service and process behavior.

Connect security events to service impacts. Centralize logs from identity and privileged access systems, firewalls, remote access, endpoints, cloud services, applications, and OT. This lets analysts connect logins, device changes, and alarms. Give each log source an owner, and alert when critical logs are disabled or delayed.^[31][10]

Implementation Steps

Encrypt logs in transit and restrict access. Keep analyst permissions separate from administrative and deletion rights, and store critical records in immutable storage. Set retention periods based on legal, regulatory, contractual, service operations, and investigation needs. Synchronize clocks, record UTC timestamps where practical, and monitor clock drift. Buffer events when collection is unavailable.^[10][16][29]

Flag unexpected privileged activity, off-hours remote sessions, configuration or firmware changes, unexpected industrial protocols, and unusual transfers. Link changes to approved work orders and retain before-and-after values. Use passive OT sensors to monitor sensitive devices without polling them directly. Alert on conditions that threaten service availability or safety.^[30]

Tune alerts to each service. The same event may pose different risks in transit, water, power, or civic systems.

Transit, Water, Grid, and Civic-Data Uses

Track anomalies in transit signaling, water treatment, grid protection, and civic-data APIs and large data exports; analysts and operators should validate alerts together before isolating, shutting down, or rerouting services.

Verification Results and Service Outcomes

Test after-hours paging when the primary contact fails to respond, email is unavailable, and a service disruption occurs at the same time. Confirm backup contacts and identify who can authorize safe shutdowns.

Measure acknowledgment and triage times, how current the logs are, timestamp accuracy, and critical-asset coverage by service area. Require analysts to reconstruct incidents using identity, network, device, and process records. Check whether that evidence gives operators enough information to act safely, and use any gaps to prioritize fixes.^[31]

Use the findings to refine alert thresholds and incident response playbooks.

6. Protect Data, Devices, and Configurations

Once access controls and segmentation are in place, harden the data, devices, and configurations that keep services running.

Control Objective

Protect sensitive data, device integrity, and safe operation. Classify data by sensitivity and its impact on services. Encrypt sensitive data in transit using current, supported protocols such as TLS. Encrypt it at rest in databases, backups, laptops, and portable media.

Manage encryption keys separately, with restricted access, regular rotation, and documented recovery procedures. Collect and retain only the civic data needed: remove unnecessary identifiers, limit secondary use, and set deletion schedules.

Implementation Steps

Set secure baselines for each device class, covering approved software, firmware, accounts, ports, and apps. Remove default credentials and turn off unused services. Check production systems against these baselines using authenticated scans or configuration tools. Use manual reviews when scanning could disrupt OT.

Prioritize exposed flaws that attackers are actively exploiting, using CISA’s Known Exploited Vulnerabilities Catalog.^[10] Test OT changes before deployment and document rollback steps. When patching could threaten safety or uptime, isolate the asset, disable the vulnerable function, or restrict connections. Give every exception an owner, an expiration date, and a fix plan.

Run application allowlisting in audit mode before enforcing it. Block removable media that hasn’t been approved, disable AutoRun/AutoPlay, and scan approved transfer devices. Keep backups isolated from production and protect them with separate credentials. Follow the 3-2-1 rule: three copies, two media types, and one offsite copy.^[35]

Require suppliers to provide secure development practices, prompt vulnerability disclosure, supported versions, signed updates, test evidence, and support dates. Verify update signatures, review release notes, and stage changes before using them in production. Keep rollback packages ready.^[32][33]

Transit, Water, Grid, and Civic-Data Uses

For transit, protect payment data and validate fare processing after updates. For water, separate customer records from process-control data and preserve controller logic and chemical-feed settings. For grid systems, protect relay settings and verify protection-device communications without disrupting live operations. For civic portals, minimize identifiers and check re-identification risks before publishing de-identified or aggregated data.

Verification Results and Service Outcomes

Record installed versions, approvals, test results, rollback status, and operational-owner signoff. Confirm that each change fixes the security issue without degrading service. If a check fails, roll back the change or document compensating controls.

Track baseline coverage, KEV findings patched or mitigated on time, validated supplier updates, and overdue exceptions. Test restoration at least annually and measure recovery time against service objectives. After correcting a failed restore, test it again.^[9][10][34] Feed unresolved gaps into incident-response and recovery plans.

7. Plan and Practice Incident Response

Control Objective

Protect people and essential services while containing the incident. Align the plan with NIST SP 800-61 Rev. 3, finalized in April 2025. Rate severity by safety impact, service loss, data sensitivity, scope, and restoration time. Name an incident commander, technical lead, operations/safety lead, executive decision-maker, legal/privacy contact, public-information lead, records manager, and vendor liaison. Give each role a backup.^[36]

Use the monitoring alerts, access revocation paths, and boundary rules already in place to guide containment.

Implementation Steps

Set three escalation levels: localized incidents; confirmed compromise of critical systems or sensitive data; and critical events that may affect safety or essential services. Define who can make decisions at each level.

Have legal counsel maintain a notification checklist covering applicable sector, state breach, contractual, insurance, and federal reporting duties. Verify current requirements and deadlines - don’t assume every incident requires the same report. Store plans and emergency contacts both on paper and in offline digital copies.^[37][41]

Keep playbooks for ransomware, credential compromise, unauthorized OT access, data theft, destructive malware, and vendor outages. Each should spell out safety checks, containment options, evidence to preserve, escalation contacts, and prerequisites for restoration.

Revoke compromised sessions and get operations approval before changing OT controls. Validate isolated backups and restore points, and follow vendor escalation procedures. Preserve logs, representative system images, memory captures where safe, and a timestamped decision log with chain-of-custody details. Do not reboot or disconnect OT equipment if doing so could disrupt safe operation.^[38]

Transit, Water, Grid, and Civic-Data Uses

Connect each playbook to the fallback mode the service will use under stress.

Define approved reduced-service modes, such as limited transit operations, manual water operations, fare collection alternatives, traffic-control fallback procedures, emergency dispatch workarounds, and manual permitting.

For each mode, define safety limits, maximum duration, staffing requirements, approval authority, and the trigger for escalation or shutdown. When services or safety are affected, coordinate with emergency management, public health, law enforcement, neighboring jurisdictions, and sector partners. Have the public-information lead issue safety instructions and service updates on a predictable schedule.

Verification Results and Service Outcomes

Exercise the plan at least annually, with added technical or operational drills for high-consequence systems.^[39][42] Include operators, executives, legal counsel, communications staff, emergency partners, and vendors.

Use CISA tabletop packages and sector-specific materials to test escalation, safe containment, evidence collection, notification, and reduced-service activation. Assign every finding an owner, deadline, and retest date. Track response times and corrective actions closed on time.

Use the findings in the next tests of restoration and service continuity.

8. Test Recovery and Service Continuity

Control Objective

Measure recovery by safe service - not by restarted servers. Use a business-impact assessment to define each service’s RTO (maximum acceptable downtime), RPO (maximum acceptable data loss), minimum operating level, dependencies, and decision maker.^[43][46]

Recovery puts ownership, access control, and segmentation to the test under stress. After containment, the goal is to restore trusted service in a clean environment.

Implementation Steps

Use isolated, tested backups that include OT logic, firmware, licenses, drawings, and approved configurations. Restore systems in a clean, isolated environment. Check that files are complete, and verify configurations, credentials, logs, and segmentation.

Require cybersecurity and operations approval before reconnection. Verify sensors, alarms, interlocks, and safe states, then validate service states before reconnecting to production networks. Once the system passes validation, take a new backup.^{[10][40][41][47]}

Transit, Water, Grid, and Civic Data Uses

Backups alone cannot restore a service. Recovery also depends on every system and resource that keeps it running. Test the full dependency chain: power, identity, DNS, time services, telecommunications, vendors, and staffing.

Include scenarios that remove internet access and primary communications. Verify that radio or other independent channels work. Train staff to use paper or manual procedures with defined triggers, safety limits, maximum duration, and reconciliation steps.^[44][45]

Verification Results and Service Outcomes

Test restoration more often for high-consequence systems and those that change frequently. Compare actual recovery time and the age of recovered data against approved RTOs and RPOs. Record failed dependencies, safety issues, fallback duration, corrective-action owners, and retest dates - not simply that a drill took place.^[10][11][48]

Use the template below to turn recovery targets into service-specific tests. This is a planning template, not an operating procedure. Fill it in only with locally approved sequences and fallbacks. Enter measured drill outcomes; the template assumes no results.

Service	Critical indicators	Response owner	Reconnection limits	Restoration dependencies	Recovery order	Fallback	Drill results
Transit	Dispatch, signaling, vehicle location, operator communications	Transit operations director	Vehicle controls and signaling require safety and integrity checks	Power, radio/cellular, identity, dispatch, signaling, telemetry	Emergency communications; dispatch and safety services; validated signaling and telemetry; passenger information and payments	Radio dispatch, paper manifests, manual headways, station announcements	Dispatch RTO/RPO, routes affected, communications delay, safety issues, corrective actions
Water	Treatment, pressure, water quality, pumps, valves, alarms	Utility operations manager	Maintain safe dosing and equipment states; isolate compromised controls	Power, field communications, engineering workstations, PLC logic, sensors, historian, vendor support	Safe plant state; operator visibility; validated controls, alarms, interlocks, and sensors; remote sites; customer systems	Trained local/manual operation, paper logs, radio, approved emergency set points	Time to safe control, telemetry gaps, manual duration, alarm checks, water quality
Grid	Frequency, voltage, protection, control visibility, outages	Control-center manager and protection lead	No unsafe switching or uncontrolled reconnection; follow operating and reliability rules	Generation, transmission/distribution controls, telecom, time services, crews, fuel	Stabilize and isolate; control visibility; validated protection and telemetry; critical substations/feeders; operator-approved load reconnection	Voice/radio dispatch, local control, paper switching orders, mutual aid	Visibility restored, sequence deviations, communications availability, switching checks, RTO/RPO
Emergency communications	911 intake, dispatch, radio, public warnings, responder coordination	Emergency communications director	Maintain life-safety communications; no unverified systems in service	Carriers, radio, computer-aided dispatch, identity, power, backup sites, notification platforms	Alternate center/channel; call intake and dispatch; validated recording, location, radio, and priority functions; public alerts	Alternate public safety answering point, mutual-aid dispatch, radio, satellite/cellular voice, runners	Call routing, dispatch delay, radio coverage, staffing, alternate-channel activation, safety issues
Civic data	Emergency records, election/public-safety data, permitting, benefits, portals	Data-system owner	Preserve privacy, integrity, retention, and chain of custody; no unvalidated publication	Identity, databases, cloud, storage, DNS, APIs, records systems, vendors	Clean identity and database restoration; validated records and permissions; priority APIs and internal services; public portals	Offline forms, public counters, phone intake, printed records, queued transactions	Records restored, integrity findings, privacy incidents, portal availability, backlog, reconciliation rate, RTO/RPO

9. Measure Coverage and Close Security Gaps

Control Objective

Measure verified protection, not paper compliance. Check earlier controls through coverage and gap-closure metrics. Use NIST CSF 2.0 Govern and Identify practices to assign accountability and track gaps. Evidence from Protect, Detect, Respond, and Recover should show how demonstrated outcomes in the Current Profile compare with required outcomes in the Target Profile.^[49][50]

Implementation Steps

After recovery testing, measure which protections are in place. Assign each metric an owner, data source, reporting frequency, target, and escalation threshold.

Track owner-confirmed asset records, privileged MFA coverage across IT, OT, cloud, and vendor access, unapproved IT–OT paths, and usable coverage of critical logs. Document approved exceptions explicitly.^[10][22][34] Reconcile IT and OT inventories monthly, and count an asset as owned only when its named owner confirms it.

Next, check whether those controls hold under incident pressure. Track detection and containment times, the time needed to revoke vendor accounts and sessions, unresolved high-risk vulnerabilities by age and service impact, and exercise findings closed by their deadlines. Report median and high-percentile times so slow cases remain visible. Count a finding as closed only after testing proves the fix works.

Transit, Water, Grid, and Civic Data Uses

For community systems, tie metrics to service risk. Prioritize service outcomes, not tool counts. Each funding request should name the affected service, expected risk reduction, cost, dependencies, accountable owner, and consequence of delay. Set vulnerability-funding priorities based on exploitability and operational impact, including CISA’s Known Exploited Vulnerabilities catalog - not severity scores alone.

Verification Results and Service Outcomes

Report restoration-test coverage, recovery-objective attainment, and trends in access, monitoring, and remediation. Reassess both Profiles after incidents, exercises, major system or vendor changes, and newly discovered dependencies. Use identity exports, network-flow records, log-quality checks, revocation tickets, and proof of fix testing to confirm whether funded work reduced risk.^[49][50] Feed these results into the next risk review.

Conclusion: Start With Ownership, Access, and Tested Recovery

Once you’ve measured gaps in transit, water, grid, and civic data services, assign named owners and fund the fixes. Each critical service needs one accountable owner with clear authority to fund, accept, and act on risk. Link that ownership to asset visibility, strong authentication, network separation, monitoring, coordinated response, and tested recovery. Together, these support the NIST CSF 2.0 cycle: Govern, Identify, Protect, Detect, Respond, and Recover.^[1][14]

Build a funded, risk-based roadmap, starting with services whose disruption threatens health, safety, or essential operations. Verify their dependencies, control remote administration, and test whether they can be restored. Give every action an owner, budget, deadline, and acceptance criteria. Use CISA’s voluntary Cybersecurity Performance Goals to prioritize high-impact work.^[10]

Treat remote access, segmentation, and alerting as one control set, not separate tasks.^[10]

Recovery is complete only when the restored service is verified safe. A completed backup job alone does not prove that essential services can resume.^[14][52]

Review dependency maps and exercises annually and after major changes. Track corrective actions through closure to keep connected community systems resilient.^[10][51]

FAQs

Which cybersecurity fixes should we fund first?

Prioritize funding for fixes that prevent or limit outages and public harm. Pre-negotiate MOUs/SLAs and incident-response contracts, including forensics, so roles and approvals are ready before an incident occurs ^[1].

Then reduce data exposure across connected platforms and transit datasets. Set vendor security and access requirements, automate deletion and redaction, and build privacy and security into procurement and day-to-day operations ^[2][3].

Also fund recovery readiness to restore essential services, and review incidents to strengthen future policy ^[1].

How can small communities secure legacy OT?

Define partner and vendor roles through MOUs and SLAs, with clear expectations for each party. Arrange forensic support and incident response in advance to shorten remediation and approval times ^[1]. Contracts should spell out access controls, audit rights, security and retention requirements, and exit and portability clauses for removing or replacing providers ^[2].

Use trusted providers for 24/7 monitoring and targeted patching of legacy OT systems. Pair that monitoring with clear recovery priorities to restore safe operations quickly ^[1].

How can we test recovery without disrupting services?

Cities can bring IT, legal, finance, and emergency management teams together for joint tabletop exercises to practice recovery plans in a controlled setting. These simulations help teams build working relationships and check procedures without affecting live systems ^[1].

Organizations can also test solutions on a small scale before rolling them out more broadly. This approach reduces risk and lets teams refine processes based on performance in actual use ^[2].