Third-party risk management for OT/ICS vendors in utilities

A single unpatched HMI at a third-party SCADA integrator can take down substation monitoring for an entire service territory. That's exactly why OT ICS vendor risk management utilities build needs to be more than a signature on a purchase order. Utilities have spent a decade hardening their own control networks, but the vendors who build, install, and remotely maintain those networks — protection relay manufacturers, RTU firmware suppliers, metering contractors, SCADA integrators — are frequently onboarded with nothing more than a signed NDA and a purchase order. That gap is why regulators (NERC CIP-013, TSA pipeline directives, EU NIS2) now explicitly require utilities to manage supply chain risk, not just perimeter risk.

This is a practical guide to building a program you can actually operationalize: how to inventory vendors by criticality, run a real operational technology vendor security assessment, structure a utility SCADA vendor audit, write enforceable industrial vendor cybersecurity requirements into contracts, and keep the whole program alive after go-live instead of letting it rot as a one-time questionnaire exercise.

Step 1: Inventory Every OT/ICS Vendor and Score Criticality

You cannot risk-manage a vendor you haven't catalogued. Start by pulling every vendor with logical or physical access to generation, transmission, distribution, or metering systems — not just the ones under an active "cybersecurity" contract. Common blind spots:

• Relay and RTU firmware/OEM support contracts
• SCADA/HMI integrators and their subcontractors
• AMI/metering head-end vendors
• Building automation and physical security vendors wired into the same network segment
• Remote monitoring/managed OT services providers

For each vendor, score criticality on three axes: access (remote, VPN, on-site, none), function (safety-instrumented system, protection, monitoring-only), and blast radius (single substation vs. fleet-wide firmware). A simple weighted model works well:

criticality_score = (access_weight * 0.4)
                   + (function_weight * 0.4)
                   + (blast_radius_weight * 0.2)

Tier vendors into three buckets — Critical, Significant, Standard — and let that tier drive everything downstream: assessment depth, audit frequency, and contract language. A firmware vendor for protection relays across your transmission fleet should never be assessed on the same cadence as a vendor supplying break-room badge printers, even if both technically "touch the network."

Step 2: Run a Structured Operational Technology Vendor Security Assessment

Generic IT security questionnaires (SIG, CAIQ) miss almost everything that matters in OT. An operational technology vendor security assessment needs OT-specific questions layered on top:

• How is remote access brokered — dedicated jump host, VPN with MFA, or direct dial-in? Request architecture diagrams, not narrative answers.
• What is the vendor's patch validation process for control system firmware, and what is their mean time to patch a critical CVE in a shipped product (not just their own corporate IT)?
• Do they maintain a signed SBOM (software bill of materials) for firmware and HMI software, and can they produce one on request within a defined SLA?
• What's their incident notification SLA specifically for OT-impacting events, distinct from general data breach notification?
• Do they segment engineering workstations used for your systems from their general corporate network?

Score each response against your tier. For Critical-tier vendors, don't accept self-attestation alone — request evidence: a recent pen test summary, SBOM samples, or a walkthrough call with their security lead. Track results in a structured system rather than a spreadsheet graveyard; you'll need the history for step 5.

Step 3: Conduct the Utility SCADA Vendor Audit Before and After Onboarding

Assessments tell you what a vendor says; a utility SCADA vendor audit tells you what's actually true. For Critical and Significant tier vendors, audits should happen pre-contract-signature and then on a recurring cycle (annually for Critical, every two years for Significant).

A right-to-audit clause is only useful if you exercise it. A minimal audit checklist:

1. Verify remote access paths match what was documented in the assessment — pull firewall rules or jump-host logs, don't just ask.
2. Confirm patch and vulnerability management evidence for the last 12 months, mapped against the vendor's own SLA commitments.
3. Validate that any subcontractors (a common gap — SCADA integrators often subcontract commissioning work) are covered under the same security terms.
4. Review physical security controls at any facility where your firmware, configs, or credentials are stored or built.
5. Test incident response readiness with a tabletop scenario specific to a vendor-introduced compromise (e.g., "your RTU vendor's build server is compromised — what do you do in the first hour?").

Document findings with severity ratings and remediation deadlines, and track them the same way you'd track an internal audit finding — with an owner and a due date, not a PDF that gets filed away.

Step 4: Write Industrial Vendor Cybersecurity Requirements Into Every Contract

Assessment and audit findings are worthless if they aren't binding. Bake industrial vendor cybersecurity requirements directly into procurement templates and master service agreements so security isn't a post-signature negotiation. Minimum clauses for Critical/Significant tier vendors:

• SBOM delivery: required at time of delivery and on every subsequent update, in a machine-readable format (SPDX or CycloneDX).
• Vulnerability disclosure and patch SLA: e.g., critical CVEs affecting shipped firmware patched or mitigated within 30 days of public disclosure, high within 90.
• Right to audit: annual for Critical tier, with 30 days' notice, including subcontractors.
• Breach notification: OT-impacting incidents reported within 24-72 hours, distinct from and faster than general data breach clauses.
• Access revocation: contractual commitment to remove remote access and rotate shared credentials within a defined window (e.g., 24 hours) of contract termination or personnel change.
• End-of-life/EOL disclosure: advance notice before a vendor stops patching a product still deployed in your environment.

Sample clause language you can adapt for an MSA:

Vendor shall, within thirty (30) days of a request by Utility, provide a
current Software Bill of Materials (SBOM) in SPDX 2.3 or CycloneDX 1.5
format for any firmware, application, or HMI software delivered under
this Agreement, and shall notify Utility within seventy-two (72) hours
of any vulnerability rated CVSS 7.0 or higher affecting such software.

Legal will want to soften SLAs; hold the line on Critical-tier vendors specifically, since these are the contracts where a missed patch has physical consequences.

Step 5: Sustain OT ICS Vendor Risk Management Utilities Programs With Continuous Monitoring

The most common failure mode in OT ICS vendor risk management utilities run is treating the assessment as a one-time gate. A vendor that passed review in January can ship a compromised firmware update in June. Build continuous signals into the program:

• Subscribe to CVE and vendor security-bulletin feeds mapped to your actual deployed asset inventory (not a generic feed), so a new relay-firmware CVE surfaces against the specific vendor and product version in your fleet.
• Re-score criticality whenever a vendor's access or function changes — a monitoring-only contract that expands to remote firmware push should retrigger the full assessment.
• Set calendar-driven reassessment triggers tied to tier (annually for Critical, biennially for Significant) so nothing depends on someone remembering.
• Track vendor security posture drift over time — a vendor whose assessment score is trending down for two consecutive cycles should trigger an unscheduled audit, not wait for the next scheduled one.

A simple way to operationalize the reassessment cadence is a scheduled check against your vendor registry:

# pseudo-cron: flag any Critical-tier vendor not reassessed in 365 days
0 6 * * MON  vendor-risk-check --tier=critical --max-age-days=365 --notify=security-team

Troubleshooting and Verification

Vendor pushes back on the audit clause or SBOM requirement. This is common with smaller relay/RTU manufacturers who've never been asked. Offer a phased timeline (e.g., SBOM within 6 months of contract start) rather than dropping the requirement — a documented remediation plan is still auditable; silence isn't.

You inherited legacy contracts with no security language at all. Don't try to retrofit every clause at renewal. Prioritize by criticality tier: renegotiate Critical-tier contracts first, and use compensating controls (network segmentation, enhanced monitoring on that vendor's access path) as an interim measure for lower-priority contracts still under old terms.

Assessment responses look complete but you can't verify anything. Cross-check self-reported answers against independent signals: does the vendor have a public vulnerability disclosure policy? Do their published CVEs match their claimed patch SLA in practice? A vendor's actual CVE-to-patch timeline history is often more honest than their questionnaire answers.

You have hundreds of vendors and no way to prioritize. Re-run the criticality scoring from Step 1 ruthlessly — most utilities find that fewer than 15% of vendors carry real OT access or blast radius, and that's where audit and monitoring effort should concentrate first.

Findings pile up faster than they get remediated. Treat vendor audit findings like internal control gaps: assign an owner, a severity, and a due date, and report aging findings to whoever owns vendor risk governance monthly, not annually.

How Safeguard Helps

Safeguard gives utilities and their security teams a single system of record for OT/ICS vendor risk instead of a folder of spreadsheets and PDFs. It ingests SBOMs directly from vendors in SPDX and CycloneDX formats and continuously maps disclosed CVEs against your actual deployed firmware and software inventory — so when a vulnerability is published against a relay, RTU, or SCADA component, you know within minutes whether it affects a vendor and asset you actually run, instead of finding out during the next audit cycle.

Safeguard also automates the assessment and audit lifecycle: criticality tiering, reassessment scheduling by tier, evidence collection for right-to-audit clauses, and drift detection when a vendor's security posture changes between review cycles. For compliance teams working against NERC CIP-013 or NIS2 supply chain requirements, that means audit-ready evidence on demand rather than a scramble before every regulatory review — and for security teams, it means the vendor risk program keeps running in the background instead of depending on someone remembering to open last year's spreadsheet.