What Utility Third-Party Risk Controls Actually Mean
Utility third-party risk controls are the rules, technical restrictions, evidence requirements, and review processes used to manage risks created by contractors, software vendors, cloud providers, meter specialists, consultants, data processors, and other organizations that can access utility systems or information. They matter because a water, electric, gas, or facilities operator may control its own environment while still allowing an outside company to install software, maintain equipment, connect remotely, process customer data, or support operational technology. As of 28 September 2026, the practical objective is not to eliminate every vendor; it is to ensure that each external relationship has an identified owner, defensible access, defined responsibilities, monitored performance, and a documented way to reduce or terminate exposure.
Also worth reading: How Do Modern Workplace Teams Manage Virtual Utilities and Vendor Operations Effectively? · How Should Organizations Control Third-Party OT Access Without Slowing Operations? · What Is the Best Facilities Vendor Software for Managing Third-Party Work Orders?
A useful program treats third-party risk as a continuing management discipline rather than a one-time security questionnaire. The scope should include privileged remote access, physical maintenance, application integrations, portable media, shared accounts, vendor-managed services, and subcontractors. It should also account for risks outside conventional cyber security, such as delayed maintenance, unsafe work practices, poor billing data, service disruption, and failure to meet regulatory or contractual obligations. For utilities, the severity of an event can depend on time: a compromised billing account may be serious, while unauthorized access to a pump station or valve-control path can have immediate operational and public-safety consequences.
The direct answer is that utilities should use a tiered control model based on service criticality, access privilege, data sensitivity, connectivity, recoverability, and contractual dependence. Tier 1 controls belong to vendors whose actions could directly disrupt essential service or safety. Tier 2 applies to parties with important system or information access, while Tier 3 generally covers lower-risk business suppliers. Controls should be proportionate to the risk, but “proportionate” should never mean undocumented exceptions or controls that the utility cannot monitor or enforce.
Why Utilities Face a Distinctive Third-Party Exposure
Utility systems often combine operational technology, legacy equipment, distributed field assets, telecommunications, billing platforms, and enterprise applications. Some of these systems were designed for stable, closed environments and may not support modern security features. A vendor may also be the only organization with practical knowledge of a specialized controller, meter family, or remote-support procedure. That dependence can create a difficult tradeoff: strict access rules may slow urgent repairs, while broad access can enlarge the attack surface and make accountability harder to establish.
The exposure is not only digital. Contractors can bring removable storage, connect diagnostic laptops, install unapproved firmware, misconfigure equipment, or physically enter restricted sites. Remote-access tools create another path because a vendor employee may be trusted even when the device, account, or session is not adequately controlled. Authorities have warned infrastructure operators to reduce privileges and control remote access because third-party connections can serve as a route into otherwise protected environments. The lesson is not that every connection is hostile; it is that connectivity must be authorized, limited, logged, and reviewed.
Regulatory pressure adds another reason to formalize these controls. Financial entities subject to the EU Digital Operational Resilience Act are seeing third-party oversight become more structured, including inventories, contractual provisions, incident information, concentration concerns, and exit planning. Although DORA does not automatically govern every water or electric utility, its control patterns are relevant to utilities that supply critical infrastructure or participate in larger regulated supply chains. ISO/IEC 27001 similarly treats risk treatment as the selection of controls, with availability among the considerations for protecting information. A utility can use these concepts without claiming that either framework is a complete safety standard.
Vendor management also becomes harder when responsibilities are split. A meter manufacturer may supply firmware, a software company may host the platform, a contractor may perform installation, and a consultancy may administer user access. A failure may cross all four organizations, yet each may point to another party’s work. Controls must therefore define who owns each decision, who must report an incident, who can approve exceptions, and who verifies that corrective actions were completed.
A Practical Control Model for Utility Vendors
Start by creating a complete third-party inventory that records the vendor, service, business owner, system touched, data handled, access method, privilege level, criticality, subcontractors, contract end date, and alternative provider. A practical threshold is to reassess any vendor with administrative access, real-time control capability, privileged remote connectivity, sensitive customer or employee information, physical access to critical assets, or a role in recovery. For a larger utility, a defensible program might review high-risk relationships at least quarterly, other technology vendors annually, and low-risk business suppliers on a risk-based cycle; those are governance targets, not universal regulatory deadlines.
Access controls should be as restrictive as the work permits. Use individual identities rather than shared vendor accounts, multifactor authentication for administrative and remote paths, managed devices, time-limited access, approval for each session, and logging that records the user, vendor, device, target, time, and actions performed. Privileges should be granted to roles or tasks rather than to entire systems. Standing administrative access should be exceptional, and dormant accounts should be disabled. A reasonable operational target is to remove unused accounts within 24 hours of notification and review privileged access monthly, but actual targets should reflect staffing, emergency procedures, and applicable rules.
Contracts should establish minimum requirements before work begins. They should cover approved use, security standards, confidentiality, access restrictions, incident reporting, vulnerability handling, audit rights, subcontractor consent, data return or deletion, business continuity, insurance, service levels, and termination assistance. Utility-specific language should address operational technology, field equipment, configurations, drawings, customer data, emergency coordination, and the consequences of an unavailable service. A contract should not merely promise “industry-standard security”; it should identify which controls, evidence, and response times the vendor must maintain.
Evidence should be collected continuously where possible. Relevant artifacts may include independent assurance reports, penetration-test summaries, vulnerability-management information, access-control policies, business-continuity plans, and records of software or equipment support. Certification can help, but it is not a substitute for examining scope, exceptions, current findings, and the vendor’s actual connection to the utility. High-risk suppliers may also need technical demonstrations, architecture reviews, recovery exercises, or direct observation of an administrator session.
Comparison: Build, Buy, or Use a Shared Program
Utilities have three broad ways to manage third-party risk. A custom program can fit a complex organization closely, but it creates substantial maintenance and staffing requirements. A commercial platform can accelerate evidence collection and workflow, but it does not replace technical access controls, contract negotiation, or operational judgment. A shared managed-services arrangement can add specialist capacity, although it may make responsibilities less clear unless contracts and reporting are precise.
| Feature | Custom Utility Program | Commercial Risk Platform | Managed Service or Shared Program |
|---|---|---|---|
| Initial implementation | Often $100,000–$500,000+ for a multi-utility environment | Often $30,000–$150,000+ annually depending on modules, users, and integrations | Often $75,000–$300,000+ annually, based on scope and service level |
| Fit to legacy operations | Can support unusual systems and detailed local requirements | Usually depends on integrations and data quality | Can be practical where internal expertise is limited |
| Strength | Maximum alignment with utility architecture and risk decisions | Consistent inventory, workflows, dashboards, and evidence tracking | Adds specialist monitoring and governance capacity |
| Main weakness | Expensive to maintain and vulnerable to internal drift | Can become another questionnaire database without technical follow-through | Risks unclear ownership, hidden costs, and dependence on the provider |
| Best use case | Large or highly regulated utility with internal control ownership | Organization needing centralized supplier governance across many business units | Utility needing temporary capacity, specialist expertise, or 24/7 monitoring |
| Time to initial value | Commonly 6–18 months | Commonly 3–9 months | Commonly 2–6 months, depending on contracting and access |
The most balanced option is often hybrid. A commercial tool can maintain supplier records, approvals, documents, findings, and review dates, while utility personnel retain responsibility for architecture, access, operational safety, and exception approval. External specialists can perform penetration tests, recovery exercises, or supplier assurance reviews, but the utility should still interpret the results. A provider can supply evidence; only the utility can decide whether a deficiency is acceptable for a particular service.
How to Implement the Controls Without Slowing Operations
Implementation should begin with the systems and vendors whose failure could affect safety or essential service. A sensible first pass is to identify remote-access gateways, vendor-managed accounts, privileged enterprise services, billing interfaces, customer-data processors, and contractors with physical access to generation, distribution, treatment, or storage assets. The team can then reduce immediate exposure by removing stale accounts, reviewing standing privileges, requiring multifactor authentication, and documenting emergency-access paths. These actions often provide more value than adding another questionnaire tool.
A cross-functional review group should include operations, information security, information technology, legal, procurement, privacy, compliance, safety, finance, and business continuity. One named individual should own each supplier, even if specialists support the assessment. During a vendor review, the team should ask what could stop the utility from performing the service itself, how quickly the vendor could restore operations, which subcontractors have access, and what evidence demonstrates that controls work. Risk treatment should be recorded as acceptance, mitigation, transfer, avoidance, or termination, with a reason and expiration date for any accepted exception.
Operational technology requires special care. A change to a pump controller, protection relay, meter gateway, or valve system may have safety and availability consequences beyond ordinary information technology. Vendor work should be scheduled with authorized personnel, use approved configurations and change records, and include rollback or recovery steps. A secure account does not make an unsafe change safe. For urgent work, the utility should define a documented emergency process that still verifies the request, limits privilege, records the action, and requires follow-up review.
Performance should be measured using more than the number of questionnaires completed. Useful measures include the percentage of critical vendors with current inventories and contracts, privileged accounts reviewed each month, time to remove inactive users, median time to remediate high-risk findings, percentage of remote sessions approved and logged, and the proportion of critical vendors tested for recovery. A target of 100% inventory coverage for in-scope suppliers is more meaningful than a target of 100% questionnaire completion, because a complete form can still describe the wrong system or omit a subcontractor.
Common Mistakes That Make Controls Ineffective
A frequent mistake is treating third-party risk as a procurement exercise. Procurement can confirm that a contract was signed, but it cannot determine whether a vendor account is overprivileged, a contractor is using an unmanaged laptop, or a service can be restored during an outage. Another mistake is relying on a generic cybersecurity score. Scores may obscure differences between a vendor that handles marketing content and one that can change field equipment. The assessment must describe the actual service and connection, not just the supplier’s corporate reputation.
Shared accounts are another persistent weakness. They make individual attribution difficult and often allow credentials to be passed informally among technicians. Temporary access is more manageable when it is individually approved, expires automatically, and is visible to both the vendor and utility. Another error is assuming that the vendor’s other customer is a control. A service may be secure in one environment but poorly isolated in the customer environment receiving the utility’s connection. Evidence must include the relevant service scope and configuration.
Contracts are also sometimes drafted without operational realism. Requirements that demand a 15-minute breach notification may be impossible for a small maintenance contractor, while vague promises provide no enforceable standard. The contract should distinguish between confirmed incidents, suspected events, material service disruption, and routine support, and it should specify how the vendor will preserve evidence and communicate with the utility. The utility should not create impossible promises merely to appear strict; it should set deadlines the supplier can meet and test them through exercises.
Finally, controls can fail when exceptions have no owner or expiration. A critical system may remain connected through a temporary exception for two years because no one is authorized to close it. Every exception should state the affected service, reason, compensating measures, risk owner, approval authority, review date, and end condition. The best program is not the one with the fewest recorded exceptions; it is the one that can show that exceptions are limited, visible, technically controlled, and regularly reconsidered.
When to Act, and What It May Cost
A utility should act immediately when it cannot identify who can access a critical system, when a vendor has standing administrative access that is not required, when privileged remote sessions are not logged, or when a supplier can affect safety or continuity without a tested recovery plan. Immediate action is also appropriate after a merger, major contract, cloud migration, new billing platform, change in subcontractors, or incident involving a third party. Waiting for an annual assessment may be reasonable for a low-risk supplier, but not for a control path into operational or customer information.
For a small utility, the first-year cost may range from approximately $50,000 to $200,000 when existing procurement and security staff perform much of the work. A multi-site utility with legacy systems, many suppliers, complex contracts, and 24/7 monitoring requirements may spend several hundred thousand dollars or more. Costs include staff time, legal review, technical testing, software, identity or remote-access tools, supplier assurance, training, and recovery exercises. The largest expense is often not the platform; it is the organizational work required to reconcile inventories, contracts, technical access, and operational ownership.
The decision to build, buy, or use outside specialists should be based on the control objective and available capability. Buying a platform makes sense when the problem is inconsistent inventory, overdue reviews, or scattered evidence. Hiring a specialist makes sense when the utility lacks penetration-testing, cloud, identity, incident-response, or recovery expertise. Building the entire governance system internally makes sense only when the utility has enough skilled staff to maintain it and a clear business requirement that commercial tools cannot satisfy. If no option can be justified, begin with the highest-risk access paths and assign accountable owners rather than postponing all action.
Success should be judged by reduced exposure and faster, safer operations, not by the number of documents produced. Within the first 90 days, a utility might aim to inventory all critical remote-access paths, review privileged accounts, identify unmanaged vendor devices, confirm incident-reporting contacts, and document recovery dependencies. Within 6–12 months, it can expand coverage to the full third-party inventory, negotiate missing contract provisions, test one or more critical supplier recoveries, and establish recurring metrics. The program should then mature through annual independent review, scenario exercises, and adjustments based on service changes and incidents.