The compliance lead at a mid-size IOU sat across the table from a grid AI vendor's sales engineer and asked a direct question: "Who is responsible for our CIP compliance if your platform has a security gap?" The vendor's answer was smooth, well-rehearsed, and fundamentally wrong. "We take care of security," they said. "Our platform is SOC 2 certified and fully CIP-compliant." What that answer actually meant was: our internal security practices meet a general IT auditing standard, and we have not had a NERC enforcement action. What it did not mean was: your utility's compliance obligations are satisfied. Those obligations were never the vendor's to carry in the first place.

OT Security Fundamentals for AI Procurement

Operational Technology (OT) in a utility context refers to the systems that directly monitor and control physical equipment on the grid: the Energy Management System (EMS), the SCADA infrastructure, protective relays, and the real-time telemetry feeds that flow between them. OT is fundamentally different from IT in two ways that matter for AI procurement. First, the consequences of OT failure are measured in power outages, equipment damage, and physical safety risk, not in data loss or service degradation. Second, OT systems are typically older, more tightly coupled to vendor-specific hardware, and much more difficult to patch or update without operational risk.

When a grid AI platform touches OT data, it is not simply accessing a database. It is connecting to the nervous system of your power infrastructure. That connection, however indirect, creates pathways that must be explicitly analyzed under NERC CIP standards.

The OT-AI interface takes several forms. A topology optimization platform that receives near-real-time EMS telemetry is at the most sensitive end: it needs current operating state data to be useful, which means it needs a connection to a system that almost certainly sits within or adjacent to your Electronic Security Perimeter (ESP). A load forecasting platform that uses historical interval data from an AMI system is at the less sensitive end: the data it needs is not real-time, it may already exist in an IT data warehouse rather than an OT system, and the connection to the forecasting platform can be structured to keep all data within the IT boundary. A DER orchestration platform that sends dispatch signals to field devices sits at the highest-risk end: it is not merely reading OT data, it is writing commands to physical equipment.

Understanding where your specific AI use case falls on this spectrum is the prerequisite for the right-sized compliance analysis. Not every AI procurement triggers a full CIP-010 configuration management baseline. Some do. Some require only documentation of an IT data warehouse connection. Getting the categorization wrong in either direction is expensive: over-categorizing consumes engineering time and delays deployment; under-categorizing leaves compliance gaps that emerge in audits.

CIP-003-9 and CIP-012-2: The 2026 Obligations

Two NERC CIP standards are directly relevant to AI platform procurement in 2026.

CIP-003-9, which became enforceable April 1, 2026, extended the cyber security program requirements to low-impact Bulk Electric System (BES) Cyber Systems, with a specific focus on vendor electronic remote access and supply-chain security for those systems. Prior to CIP-003-9, low-impact assets had lighter documentation requirements and minimal controls on third-party remote connectivity. CIP-003-9 addressed that gap directly: if a vendor connects remotely to a system you have classified as low-impact BES Cyber System, that access must be controlled and documented under your cyber security plan. The significance for AI procurement is that a vendor's platform accessing any low-impact BES Cyber System is now subject to defined access controls and supply-chain risk management requirements, not merely the general IT security posture the vendor maintains for its other customers.

CIP-012-2, effective July 1, 2026, is specifically about protecting real-time operational data communicated between control centers. The prior operative version, CIP-012-1, established the baseline protections for confidentiality and integrity of that data. CIP-012-2 builds on that baseline by adding availability as an explicit requirement, meaning your controls must now protect the data not only from unauthorized disclosure or modification but also from being unavailable when the operator needs it. Its scope is narrower than it sounds: it applies to data communicated between a Reliability Coordinator, a Balancing Authority, or a Transmission Operator as part of real-time operations. If your AI platform sits in the data pathway between your control center and an ISO or RTO, or between two of your own operating centers, CIP-012-2's integrity, confidentiality, and availability requirements apply to that data pathway. The specific obligation is to implement and document controls that protect the real-time data from being modified in transit, from unauthorized access, and from being unavailable when needed.

What both of these standards share is that the obligation is yours as the registered entity, and the fact that a vendor is handling the data flow does not move the obligation to the vendor. This is not a technicality. It is the fundamental structure of NERC reliability standards. NERC registers utilities, not vendors. NERC enforces against utilities, not vendors. When a vendor's platform creates a CIP gap, your utility gets the finding. The vendor's contract may give you a right to recover damages from the vendor, but it does not protect you from the NERC enforcement action.

What SOC 2 and ISO 27001 Do and Do Not Cover

Vendors frequently cite SOC 2 Type II certification or ISO 27001 compliance as evidence of security adequacy for grid environments. These certifications are genuine and meaningful for general IT security purposes. They are not substitutes for NERC CIP compliance documentation in a regulated utility context.

SOC 2 Type II certifies that a vendor's internal controls for security, availability, processing integrity, confidentiality, and privacy meet the AICPA Trust Service Criteria. ISO 27001 certifies that the vendor has an Information Security Management System (ISMS) that meets the ISO standard. Both are assessed by third-party auditors and are credible signals of baseline security hygiene.

What they do not cover: they do not address the specific requirements of NERC CIP. SOC 2 does not reference BES Cyber Systems, Electronic Security Perimeters, or Transient Cyber Assets. ISO 27001 does not include the specific access-logging, patch management, or incident-reporting requirements of NERC CIP standards. A vendor who has achieved both certifications has demonstrated that they operate a credible security program. They have not demonstrated that their platform meets your specific CIP obligations when integrated into your environment.

Vendor Due Diligence: The OT Security Checklist

The OT security due diligence for a grid AI vendor is not a questionnaire you send and file. It is a technical dialogue that produces documented evidence of how the vendor's system interacts with your CIP environment.

The first step is network architecture documentation. Before any data flows between your system and the vendor's platform, you need a network diagram that shows exactly where the connection crosses your ESP boundary or connects to systems within your CIP asset inventory. This diagram should be produced jointly: the vendor knows their platform architecture and you know your ESP boundary. The joint diagram identifies every data flow, its direction, its content, and the access control mechanism at the boundary crossing.

The second step is data classification. What data is the vendor's platform receiving? Is it near-real-time EMS telemetry that sits within your BES Cyber System? Is it historical interval data from an IT data warehouse? Is it output data from an AI model running on your infrastructure? Each of these has a different CIP scope implication. Classify the data before you begin the integration architecture, because the classification determines which CIP requirements apply.

The third step is access management verification. Who at the vendor has access to your data and through what mechanism? Personnel access to BES Cyber System information requires CIP-004-compliant access management, including personnel risk assessment (background checks) and access revocation when personnel changes occur. A vendor who says "our implementation team will access your data during the integration" without being able to specify who, with what credential, through what access pathway, and subject to what revocation process is not ready for CIP-adjacent integration work.

The fourth step is incident notification. If the vendor has a security incident that involves your data, how will they notify you, how fast, and in what format? Your CIP-008 incident-response obligations have reporting timelines. If the vendor's internal incident process does not align with those timelines, you may be unable to meet your own reporting obligations. Get the vendor's incident-response process description, confirm it aligns with your CIP-008 requirements, and make the notification obligation contractual.

The fifth step is the supply chain risk management assessment under CIP-013. CIP-013 requires utilities to manage cyber security risks in the supply chain for high and medium impact BES Cyber Systems. If a vendor's product falls within this scope, the procurement process itself must include a vendor risk assessment, and the contract must include provisions for the vendor to notify you of software updates and patches. A vendor who has not been assessed under CIP-013 may not be deployable in certain scopes without additional due diligence that adds time to the procurement process.

The vendor's platform is part of your CIP environment once it connects to your OT data. Managing that connection is your obligation as the registered entity, and no contract language transfers that obligation to the vendor.

Transient Cyber Assets and the Laptop That Touched the EMS

One frequently overlooked OT security question in vendor relationships involves Transient Cyber Assets (TCAs): laptops, tablets, and portable diagnostic devices that connect directly to BES Cyber Systems for maintenance or integration work. Under NERC CIP, TCAs must have documented security controls, including software management and malware protection, regardless of who owns them. If a vendor's implementation engineer connects a laptop to your EMS or SCADA infrastructure during integration work, that laptop is a TCA within the scope of your CIP program for the duration of the connection. You cannot delegate the responsibility for that laptop's security posture to the vendor's general IT policy. You need the vendor to demonstrate compliance with your TCA requirements specifically, and you need to document that the TCA assessment was completed before the connection was made. This is not a theoretical risk. Implementation engineers routinely connect diagnostic tools to OT systems. Without a documented TCA protocol for vendor integration work, every such connection is an undocumented compliance gap.

The Obligation That Does Not Transfer

Every utility lawyer and compliance lead should have this sentence memorized: the CIP compliance obligation belongs to the registered entity. It does not transfer to the vendor when you purchase their tool. It does not transfer when the vendor's contract includes security representations. It does not transfer when the vendor undergoes a third-party security audit and shares the results with you. The obligation is yours.

This framing is not designed to make vendor procurement complicated. It is designed to keep utility compliance leads from making the mistake of treating a vendor security certification as a compliance substitute. Regulators and auditors assess the utility's environment, the utility's controls, and the utility's documentation. The vendor does not participate in your NERC audit. You do.

The practical consequence is that your compliance documentation must include vendor-related components. If Vendor X's platform receives data from a system within your ESP, your CIP asset inventory must reference that connection. Your access management records must include the credentials used by the vendor's personnel. Your incident-response plan must include the vendor as a notification recipient and the vendor's notification process as a trigger for your own reporting timeline. Your change management records must include any changes to the vendor's platform that affect the CIP-relevant configuration of your environment.

A vendor who cannot help you build this documentation is a vendor who is not ready to operate within your CIP environment. That is a disqualifying finding for any platform that will touch your operational systems. It is not a minor administrative gap.

Worked Example: The Topology Optimizer CIP Assessment

A transmission utility is deploying a topology optimization platform. The platform needs near-real-time data from the EMS historian to generate switching recommendations. Here is how a CIP assessment should proceed.

Step one: identify the data source. The EMS historian contains SCADA telemetry updated every four seconds. It resides within the utility's Electronic Security Perimeter. The historian contains state data for Transmission assets that qualify as high-impact BES Cyber Systems.

Step two: determine the access pathway. The topology optimization platform's integration architecture calls for a one-way data feed from the historian to a data staging layer in the vendor's cloud environment. The feed uses a utility-controlled export mechanism with a one-minute aggregation interval, which delays the data enough to take it out of the "real-time" threshold for CIP-012-2 purposes.

Step three: classify the CIP scope. The data being exported contains transmission system state information. Even with the one-minute delay, this data may qualify as BES Cyber System Information (BCSI) under CIP-011. The compliance lead confirms that the historian export data qualifies as BCSI and that the export mechanism must be protected in transit.

Step four: document the controls. The utility implements encryption for the data feed, documents the access credentials and revocation process for the vendor's personnel who will access the data, and confirms with the compliance lead that the vendor's cloud environment has completed a CIP-013 risk assessment.

Step five: update the CIP asset inventory. The export mechanism and the data pipeline to the vendor's staging layer are added to the CIP asset inventory. The vendor's platform access is documented in the access management records. The incident-response plan is updated to include vendor notification requirements.

Step six: confirm the boundary. The topology optimization platform's output, the switching recommendations, flows back to the utility through a separate interface that delivers output to a display system within the utility's network. This output pathway does not create a return data flow into the ESP, which the compliance lead confirms preserves the one-way data flow architecture.

This six-step process takes several weeks of engineering and compliance work. It is not optional. It is the documentation that makes the deployment defensible in a NERC audit and that protects the utility if the vendor has a security incident involving the exported data.

Key Takeaways

• OT and AI intersect at three levels of risk: read-only access to historical IT data (lower risk), near-real-time read access to OT telemetry (higher risk), and write access that sends commands to physical devices (highest risk). Match your CIP assessment depth to the actual access level.
• CIP-003-9 (enforceable April 1, 2026) specifically addresses vendor electronic remote access and supply-chain security for low-impact BES Cyber Systems. CIP-012-2 (effective July 1, 2026, the prior operative version being CIP-012-1) adds availability protections to the confidentiality and integrity requirements for real-time data communicated between control centers. Neither obligation transfers to the vendor because you purchased their tool.
• SOC 2 and ISO 27001 certifications are credible signals of IT security hygiene. They are not substitutes for NERC CIP compliance documentation, which addresses different requirements for a different regulatory framework.
• The five OT security due-diligence steps are: network architecture documentation, data classification, access management verification, incident notification alignment, and CIP-013 supply chain risk assessment. All five produce documented evidence that goes into your compliance binder, not into a vendor's presentation.
• Your CIP documentation must include vendor-related components: the vendor connection in your asset inventory, vendor personnel in your access records, the vendor's notification process in your incident-response plan, and vendor platform changes in your change management records.
• A vendor who cannot provide specific, documented answers to your CIP boundary questions is not ready to operate within your OT environment. That is a disqualifying finding, not an administrative gap to resolve post-deployment.
• The compliance obligation is yours as the registered entity. No contract language, vendor certification, or third-party audit result transfers that obligation to the vendor. Build the documentation as if the vendor does not exist, because in a NERC audit, they effectively do not.