The IT director of a municipal water utility faces a different security posture than the IT director of a hospital or a financial institution — and in some respects, a harder one. The data at risk isn't patient records or account numbers. It's operational telemetry that, in the wrong hands, provides a map of the vulnerabilities in a piece of critical public infrastructure. The CISA classification of water and wastewater systems as critical infrastructure isn't a formality; it reflects a genuine threat environment that has changed substantially in the past five years.
When Watsynq's integration team connects to a utility's SCADA historian for the first time, we're working through an IT security review that can take anywhere from two weeks to three months, depending on the utility's IT governance maturity and internal approval processes. That review is appropriate. This post is an attempt to frame the relevant questions clearly, so that the review conversation is productive rather than a negotiation over paperwork.
What data is actually being transmitted
The first question for any analytics vendor receiving SCADA data: what precisely is being transmitted, and what is not? The distinction matters because different data elements have different sensitivity profiles.
For Watsynq's integration, the data transmitted is: pressure and flow time-series readings from distribution system measurement points, associated sensor metadata (sensor ID, zone ID, coordinate location), and water quality parameter readings (chlorine residual, turbidity, pH, conductivity) from instrumented nodes. This is operational telemetry data — it describes the hydraulic and chemical state of the network at a measurement point level.
What is not transmitted: SCADA control commands, valve actuator states, pump control logic, network topology schematics, or any data that would allow the Watsynq system to directly influence or disrupt distribution system operations. Watsynq is a read-only analytics platform; it ingests sensor data and returns risk scores and alerts, but has no write access to any operational control system. The read/write boundary should be explicitly confirmed in your integration agreement and technically enforced at the connection level — not just stated in a service agreement.
Data residency and sovereignty
Municipal utilities with state or federal grants attached to their water systems may have data residency requirements that limit where operational data can be stored. Arizona municipalities subject to the state's public records law also have obligations regarding the treatment of government data — how it's stored, who can access it, and how long it's retained.
The relevant questions for any cloud analytics vendor are: In which geographic region (specifically, which AWS, Azure, or GCP region) is utility telemetry data stored? Is data replicated to additional regions for redundancy, and if so, to which regions? How long is raw telemetry data retained, and can retention periods be configured to comply with your state data management requirements? What happens to your data if you terminate the contract — is there a data return and deletion provision, and what's the timeline?
Watsynq stores utility data exclusively in US-region cloud infrastructure. We provide data return in a standard format within 30 days of contract termination, and permanent deletion confirmation within 60 days. These provisions should be in your service agreement as explicit contractual terms, not just vendor policy statements.
Access controls: who at the vendor can see your data
The access control question is often where IT reviews stall, because most utility IT teams haven't thought through what they actually want here. The relevant framework is role-based access control (RBAC) with a principle of least privilege — vendor staff should have access only to the specific data elements needed to provide the contracted service, not blanket access to all customer data.
Ask your vendor: how many employees have access to production customer data, and in what role? Is access to customer data logged — meaning there's an audit trail showing who accessed which customer's data at what time? Are data access events reviewed regularly, and is there a policy for revoking access when an employee changes roles or leaves? What's the vendor's procedure for a security incident involving customer data?
For Watsynq: customer data is accessible only to the integration engineer assigned to that utility's account and to senior engineering staff for diagnostic purposes. All data access events are logged in an immutable audit log. We provide customers with access to their own audit log on request — you can see who at Watsynq touched your data and when. This is a specific, auditable control that is meaningfully different from a vendor simply asserting "your data is secure."
The OT/IT network boundary question
This is the most technically sensitive point in the integration review. SCADA systems in water utilities are operational technology (OT) networks — they operate on different security principles and often different network hardware than the IT networks that handle administrative and business applications. Connecting an OT network historian to any external system, even a read-only analytics platform, requires crossing the OT/IT boundary in a controlled way.
The safest architecture for this integration is a one-way data diode or a historian data forwarding agent that operates within the DMZ between the OT network and the IT network. The agent reads from the historian in the OT zone and forwards to the analytics platform via the IT zone — data flows one direction, and there is no return path from the analytics platform into the OT network. This architecture eliminates the possibility of a compromise of the analytics platform being used as a lateral movement vector into the operational control systems.
We're not suggesting that connecting a read-only analytics platform to a historian is inherently unsafe if done with appropriate network architecture. What we are saying is that the OT/IT boundary should be addressed explicitly in your integration design, not treated as an IT network issue. Your SCADA vendor and your OT network administrator should both be part of the integration review, not just the IT security team.
What to ask any vendor before granting data access
The checklist for evaluating a data governance posture is not long, but every item on it should have a verifiable, contractual answer — not just a vendor assertion:
- Data storage region: which specific cloud region(s)?
- Encryption: data encrypted in transit (TLS 1.2+) and at rest (AES-256 or equivalent)?
- Access audit log: is it immutable, and can you access it?
- Data return and deletion terms: explicit in the service agreement?
- Incident response: what is the notification timeline for a data breach?
- Subprocessors: does the vendor share your data with third-party subprocessors, and who are they?
- Penetration testing: has the platform been independently tested, and can they share a summary?
If a vendor cannot answer these questions concretely and in writing, that's a governance gap — not just an administrative inconvenience. The operational technology environment of a municipal water system is a high-value target. The IT and security review for any vendor accessing SCADA data should be treated accordingly.
Ethan Morales is CEO and Co-Founder of Watsynq.