NERC CIP Compliance and Internal App Development: The Governance Gap in Energy and Utilities IT

A utility’s operations team needs a lightweight tool to track substation maintenance schedules. Someone on the internal applications team prompts an AI coding assistant, gets a working app in a day, and ships it. Nobody stops to ask whether that tool touches anything a NERC CIP auditor would classify as a BES Cyber Asset, or whether the access controls and change management around it would survive a Regional Entity audit.

AI Platform

Enterprise AI

Build AI-powered apps without exposing your data to anyone.

See How

That scenario is playing out across energy and utilities IT departments right now, and it’s a different risk profile than the generic security conversation most enterprises are having about AI-generated code. NERC CIP standards were written for a world of engineered control systems and formally reviewed software changes. They were not written with a world in mind where an internal developer can generate a working application in an afternoon, and the standards don’t bend just because the development method changed.

Why NERC CIP Makes This Especially Unforgiving

NERC’s Critical Infrastructure Protection standards govern how bulk electric system operators manage cybersecurity for systems that affect the reliability of the grid. CIP-007 covers system security management, including patch management and access controls. CIP-010 covers configuration and change management, requiring that changes to BES Cyber Systems go through a defined process with documented baselines. CIP-005 covers electronic security perimeters. None of these standards were designed around the assumption that new software could appear inside the perimeter as fast as a developer can write a prompt.

AI Platform

Enterprise AI

AI for the enterprise — built on security, not around it.

Get Started

That mismatch creates a specific compliance problem. CIP-010 requires a documented change management process for anything touching a BES Cyber System, including a security impact assessment before implementation. An AI-generated internal tool built in an afternoon and pushed into production the same day has, by definition, skipped the deliberate review process the standard assumes exists. It’s not that AI-generated code is inherently disqualifying. It’s that the speed AI coding tools enable is fundamentally at odds with the documentation and review cadence CIP-010 was built around, unless the organization has a way to make that review happen without slowing development back down to the old pace.

Where the Risk Actually Sits

Not every internal application a utility builds touches a BES Cyber System, and that distinction matters enormously for how much CIP exposure exists. A tool that tracks office facility requests carries essentially none. A tool that reads data from an operational technology network, feeds a workflow that affects generation or transmission decisions, or sits anywhere near a control system boundary carries a great deal, and the boundary between those two categories isn’t always obvious to whoever is prompting an AI coding tool to solve today’s problem.

AI Platform

Enterprise AI

Modernize legacy systems with enterprise-grade AI.

Learn More

This is exactly the ambiguity shadow IT, now running on AI, thrives on. A developer building a maintenance-tracking tool isn’t necessarily thinking about CIP scope. They’re thinking about solving a problem quickly. Whether that tool ends up touching data or systems that fall under CIP jurisdiction often isn’t decided deliberately, it’s discovered later, sometimes by an auditor asking a question nobody on the development team anticipated.

What an Ungoverned Utility App Actually Looks Like

Picture the substation maintenance tracker again. It pulls equipment status from a historian database that also feeds control room displays. It was built quickly, tested informally, and deployed without a documented security impact assessment because nobody flagged it as touching anything CIP-relevant. Six months later, during a Regional Entity audit, an auditor asks for the change management record and security impact assessment for every application with access to that historian.

AI Platform

Enterprise AI

Enterprise AI that fits your compliance, not the other way around.

Explore CloudApper

There isn’t one. The tool exists, it works, and it has been in production quietly reading from a system inside the electronic security perimeter, but the documentation trail CIP-010 requires was never created, because the tool was built the way AI-generated applications typically get built: fast, informally, and without anyone mapping it against a compliance framework designed for a much slower development cadence.

AI-generated code is fast to build and expensive to trust, and in a NERC CIP environment, expensive has a specific meaning that includes financial penalties, mandatory remediation plans, and a level of scrutiny on every subsequent internal development project the utility undertakes.

Why This Compounds Across a Utility’s IT Footprint

A single ungoverned application is a discrete, manageable risk. The exposure compounds when a utility’s internal development team, or its various operational groups, have each built a handful of AI-generated tools over the past year or two, each with its own informal approach to documentation, each built by someone with a different level of awareness of what CIP actually requires.

The hidden security risks of AI coding assistants without a governance framework apply to any enterprise, but in an energy and utilities context those risks intersect directly with mandatory federal compliance obligations tied to grid reliability, not just internal security policy. Every generated app creates its own logic and its own access pattern, and in a CIP environment, every one of those apps also needs its own security impact assessment, its own baseline configuration record, and its own place in the utility’s electronic security perimeter documentation. That doesn’t scale when a dozen internal tools have been built the same fast, informal way.

The Software Supply Chain Angle Utilities Can’t Ignore

NERC CIP compliance increasingly intersects with software supply chain security, particularly after CIP-013 introduced supply chain risk management requirements for BES Cyber Systems. CISA’s guidance on software supply chain security and AI-generated code is relevant here specifically because AI-generated applications introduce a supply chain question that didn’t exist a few years ago: who is accountable for the provenance and integrity of code that no single developer fully wrote or reviewed line by line?

For a utility, that question isn’t abstract. CIP-013 requires utilities to have a documented supply chain risk management plan covering vendor and software risk. An internally built application generated largely by an AI coding tool sits in an odd category, it isn’t quite third-party vendor software, but it also isn’t fully human-authored and reviewed in the traditional sense. Utilities that haven’t updated their supply chain risk management approach to account for this category of software are carrying a compliance gap that’s likely to surface the next time CIP-013 documentation gets audited.

What a Governed Approach Looks Like for Utility IT

The fix isn’t to slow internal development back down to a pre-AI pace, and it isn’t realistic to ask utility IT teams to manually map every internal tool against CIP scope before it ships. The fix is building the compliance posture into the development platform itself, so that documentation, access control, and change management happen as a byproduct of how the application gets built, not as a separate manual step someone has to remember.

CloudApper eliminates the security, compliance, and maintenance risks of AI-generated code by generating governed application definitions rather than raw source code, executing them inside a certified runtime that maintains consistent access controls, audit logging, and change tracking across every application built on it. For a utility, that means a maintenance-tracking tool and a tool with genuine BES Cyber System exposure both inherit the same documented baseline configuration and the same change management trail, because neither one exists as an independent, informally built codebase outside the platform’s governance layer.

AI Platform

Enterprise AI

Enterprise AI that's secure enough for the systems you can't risk.

Explore Now

That consistency is what CIP-010 change management actually asks for: a documented process applied uniformly, not a best effort recreated from scratch for every new internal tool. When every application an operations team builds runs through the same governed foundation, answering an auditor’s question about a specific tool’s security impact assessment becomes a lookup instead of a scramble.

Evaluating Vendors for a CIP-Regulated Environment

Not every AI development platform is built with a regulated critical infrastructure environment in mind, and utilities evaluating options need to ask sharper questions than a typical enterprise buyer might. Secure enterprise app development platforms need to be evaluated with compliance as a non-negotiable criterion, and for a NERC CIP context that means asking whether the platform can produce a documented baseline configuration for every application it generates, whether access controls are consistent and auditable across the entire portfolio of internally built tools, and whether the vendor understands the distinction between an application with genuine BES Cyber System exposure and one that doesn’t touch anything CIP-relevant.

Vendors built for prototyping or general business automation typically can’t answer those questions in the specificity a CIP compliance team needs. A practical AI coding governance framework has to account for the fact that energy and utilities IT operates under a compliance regime most other industries don’t, and the evaluation criteria should reflect that rather than treating CIP as an afterthought layered on top of a generic governance approach.

What Energy and Utilities IT Should Do Before the Next Tool Ships

The starting point is the same inventory question every AI governance conversation eventually reaches, but with a CIP-specific twist: which internally built applications, generated with AI coding tools over the past two years, touch systems or data that fall under CIP scope, and can the organization currently produce a security impact assessment and baseline configuration record for each one? Most utility IT departments cannot answer that question completely today, and that gap is exactly what a Regional Entity audit is designed to surface.

From there, the priority is establishing a single governed path for internal application development before the next tool gets built, one where CIP scope gets assessed as part of the development process rather than discovered after the fact. AI coding tools aren’t going away from utility IT departments, they’re too valuable for the operational efficiency gains they enable. The choice utilities actually face is whether that speed runs through a governed platform that produces the documentation CIP compliance requires as a byproduct of normal development, or through a scattered collection of fast, informally built tools that each carry their own undocumented compliance exposure into the next audit cycle.

CloudApper helps energy and utilities IT teams build internal applications that inherit consistent access controls, change management documentation, and audit trails from day one, without slowing down the development speed AI coding tools made possible. If your organization needs a governance model for internal app development that holds up under a NERC CIP audit, reach out to CloudApper to talk through what that looks like for your environment.