SCADA Awareness and Vendor Risk Guide for Town Managers

Public Sector & Local Government

Updated July 12, 2026

A town manager does not need to operate a supervisory control and data acquisition system to govern its risk. The manager does need to know which public services depend on operational technology (OT), who is authorized to change it, how vendors reach it, and what happens when the normal control path is unavailable. Water and wastewater controls are common examples, but building automation, access control, generators, pumps, traffic equipment, and public-safety facility systems can create similar IT/OT dependencies.

Safety boundary: this guide is for oversight and questions, not live configuration. Never use a web article to change a controller, process set point, network path, safety control, or remote-access method. Only the system owner, authorized operator, engineer, integrator, and other required parties should approve and execute work under the town's safety, regulatory, change-control, backup, and rollback procedures. NIST's Guide to OT Security emphasizes that OT security must account for performance, reliability, and safety requirements that differ from ordinary business IT.

Start with the public service, not the device

Ask department leaders to map essential services before requesting a technical inventory. For each service, record the responsible department, normal operator, facilities involved, public or employee impact, manual operating capability, communications dependencies, electric-power dependencies, upstream data, downstream reporting, and the technical or vendor contacts needed for recovery. A police facility may depend on building access, dispatch connectivity, radios, cameras, and generator monitoring even when none of those systems is casually called SCADA.

CISA's OT asset inventory guidance treats an inventory and taxonomy as a foundation for a defensible architecture and lifecycle management. Management should ask whether the inventory has an owner, a review date, and relationships between assets and services. It should not demand indiscriminate active scanning of sensitive networks; the OT owner should choose discovery methods that are safe for the environment.

Which essential service stops if this system or its communications path fails?
Which functions can be performed manually, by whom, for how long, and under which approved procedure?
Who can authorize normal work, emergency work, remote access, and return to service?
Where are current diagrams, configurations, licenses, backups, manuals, and vendor contacts held?
Which dependencies cross from business IT into OT, including identity, time, name resolution, email, cloud portals, cellular service, or shared facilities?

Maintain a vendor-access register

Remote maintenance can support small teams, but an undocumented vendor pathway becomes a continuity and accountability problem. CISA's Guide to Securing Remote Access Software explains that legitimate tools are also misused by threat actors. The 2026 NIST water and wastewater OT remote-access practice guide offers an example architecture, not a mandate to install its components in every environment.

Register field	What management should be able to confirm
Service and system	Public function supported and exact assets within the approved access scope
Vendor and named users	Company, individual identities, employer status, and current authorization owner
Business purpose	Maintenance or support task, contract reference, and why remote access is needed
Approved path	Town-approved access service and entry point documented by the technical owner
Access conditions	Approval method, permitted time, scope, expiration, and supervision requirement
Account controls	Individual account, authentication requirement, privilege boundary, and disablement owner
Evidence	Connection and activity logging, change ticket, work record, and post-work review location
Escalation	Vendor and town contacts for suspected misuse, outage, safety concern, and contract dispute

Review the register when personnel, contracts, equipment, or support arrangements change, and at a defined local cadence. An account should not stay enabled merely because a vendor may need it someday. CISA's primary OT mitigations call for securing essential remote access, applying least privilege, disabling dormant accounts, and segmenting IT and OT. The technical design and change sequence still require environment-specific engineering and safety review.

Ask segmentation and dependency questions safely

A manager should ask for a diagram and risk explanation, not prescribe a firewall rule. Useful questions include: Is there an intentional boundary between office users and control functions? Which approved communications must cross it? Who reviews a new connection? Can the town identify unexpected paths? Does a business-system compromise automatically expose an operator workstation? Are monitoring and administration paths separated appropriately? What is the rollback plan if a boundary change affects operations?

CISA's Cross-Sector Cybersecurity Performance Goals 2.0 provide prioritized outcomes for IT and OT owners. They are voluntary guidance, not proof that a particular segmentation design is safe. Record unanswered questions as owned risks and have qualified technical and operational personnel resolve them in an approved maintenance window.

Put lifecycle and incident duties in vendor governance

Contracts and work orders should identify supported versions, maintenance scope, security notification, access authorization, subcontractors, change records, configuration and backup deliverables, response contacts, end-of-support notice, transition assistance, and data or documentation return. Confirm who owns software licenses, device credentials, diagrams, and configuration copies. Avoid a model in which the only usable documentation or administrative identity belongs to one technician.

The maintenance review should connect asset condition to service impact: unsupported components, expired support, failed backups, unavailable spares, changed communications providers, untested manual procedures, and single-person knowledge. EPA's water-sector cybersecurity resources include assessment, planning, incident, and exercise materials. EPA's assessment page also explains specific federal risk-assessment obligations for certain community water systems; town leaders must confirm actual system classification and current applicability rather than generalize that requirement to every utility or OT system.

Plan escalation, recovery, and exercises together

Define the conditions that trigger the operator, department head, IT lead, vendor, public information officer, emergency management, executive leadership, insurer, law enforcement, regulator, or other required notification. A suspected cyber event and an unsafe process condition may require parallel but different response leadership. The approved operations and safety procedure remains controlling.

Use a tabletop scenario that begins with a service symptom, such as loss of visibility, unavailable vendor support, or a business-network incident that may affect OT.
Have participants identify the decision authority, safe operational posture, alternate communications, evidence owner, and next notification without touching production.
Test whether current contacts, diagrams, vendor records, recovery materials, and manual procedures are available to authorized staff.
Document decisions that were delayed, responsibilities that conflicted, and dependencies that were missing.
Assign corrective actions with owners and dates, then update the relevant plan and repeat the scenario.

Coordinate this work with the town's incident response playbook, emergency communications plan, and cyber tabletop program. The outcome is not a claim that an incident cannot happen; it is a safer, faster decision path when information is incomplete.

Sources and scope

NIST, CISA, and EPA materials have different audiences and scopes. Water-sector requirements do not automatically apply to police, building, transportation, or other town systems, and voluntary guidance does not replace engineering standards, permits, operating procedures, vendor instructions, or law. Confirm applicability with the responsible operator, engineer, security lead, regulator, counsel, and emergency-management officials.

Suggested next step

Book a discovery call if your town needs a facilitated, non-invasive review of service dependencies, vendor access, and recovery ownership.