CIP-015-1 Is Here. Here’s What It Actually Takes to Meet It.

NERC CIP-015-1 is the first reliability standard to require electric utilities to look inside their networks, not just guard the perimeter.

That’s a meaningful shift. Most of the CIP framework has been about what gets in and out: firewalls, access controls, electronic security perimeters. CIP-015-1 says that’s not enough. If an adversary is already inside, you need to know about it. And you need to be able to prove to an auditor that you would have known.

The standard calls this Internal Network Security Monitoring, or INSM. It applies to High Impact BES Cyber Systems and Medium Impact systems with External Routable Connectivity. If you operate generation, transmission, or control systems at that tier, this is your program to build.

Here’s what it actually requires and what most programs get wrong.

What the standard asks for

CIP-015-1 has three requirements.

R1 is the monitoring requirement. You need to implement network data feeds inside your ESPs using a risk-based rationale, use those feeds to detect anomalous network activity, and evaluate what you find to determine whether further action is needed. That evaluation piece matters. The standard isn’t satisfied by alerts that go unreviewed. You need a documented workflow for what happens when something looks wrong.

R2 is retention. You keep monitoring data associated with anomalous activity until the response actions are complete. Not forever. Not nothing. Until the action is done and documented.

R3 is protection. The data you collect and retain has to be protected from unauthorized deletion or modification. RBAC, immutable storage, access logs; the mechanics will look different depending on your environment, but the intent is clear: an auditor needs to trust that what you retained is what actually happened.

The audit evidence expectations follow from this. Documented processes, risk-based rationale for how you selected your data feeds, detection configuration, anomaly case records, evaluation notes, response documentation, and proof that retained data was protected. That’s your compliance package.

Where programs typically fall short

The three requirements sound simple. The implementation is where things get complicated.

Most network monitoring tools were designed for enterprise IT. They assume cloud connectivity, a stable environment where baselines can be established over weeks or months, and a SOC with enough staff to handle alert volume. Utility OT environments are often none of that.

The networks inside an ESP running generation or transmission infrastructure may be deliberately isolated. They can’t be connected to a cloud-based monitoring service without introducing risk the utility doesn’t want to accept. They run on equipment that hasn’t changed in a decade. There’s rarely a dedicated security team on-site reviewing alerts in real time.

And baseline-dependent detection has a specific problem in OT: these networks don’t generate enough varied traffic to establish a meaningful behavioral baseline quickly. Anomalies in an OT environment can look a lot like normal operation to a tool trained to expect enterprise traffic patterns.

The result is that a lot of utilities stand up something that technically monitors their network, generates evidence they can point to, and doesn’t actually tell them much. That’s a CIP program, not a security program.

What a real implementation looks like

The utilities I’ve worked with that are getting this right share a few things in common.

They start with feed selection that reflects actual risk. R1.1 doesn’t require you to monitor everything. It requires a risk-based rationale for what you monitor. That’s an opportunity to focus coverage on the segments that matter most: control system communications, east-west traffic between zones, connections to historian servers, rather than trying to boil the ocean.

They use behavior-based detection rather than signature or baseline approaches. In an OT environment, you need a system that can identify adversary behavior from how devices are communicating, not from matching known patterns. Lateral movement, reconnaissance, anomalous command sequences; these show up in traffic behavior before they show up in a signature database.

They close the loop on evaluation. R1.3 is where a lot of programs have a gap. Detection fires. Nobody documents what they did with it. An auditor asks for evidence of evaluation actions and the record isn’t there. The fix is a workflow, automated where possible, that ties detected anomalies to documented responses.

And they treat retention and protection as a system design problem, not an afterthought. If your monitoring data lives somewhere that’s easy to delete or hard to export for an audit window, you have an R2 and R3 problem waiting to happen.

How AtlasCyber approaches this

We built AtlasCyber for environments exactly like this.

The platform passively ingests PCAP, NetFlow, and CSV from inside the ESP via CrunchSense sensors. No disruption to operations. No cloud dependency. Runs fully air-gapped if that’s what the environment requires.

Detection is behavioral, not signature-based. Our Graphite engine analyzes network communications directly on the wire to identify adversary behavior in near real time, mapped to MITRE ATT&CK®. There’s no baseline period. The platform is looking for behavior, not deviation from a learned norm.

ClemAI, our edge AI, closes the evaluation loop. When something anomalous is detected, it produces a structured intelligence report with severity scoring, context, and response guidance. That’s your R1.3 documentation built into the workflow, not a manual afterthought.

For R2 and R3, the platform supports case-centric retention that preserves packet and flow context tied to each identified anomaly through investigation closure. On-prem deployments keep data under the entity’s control with access controls, immutable storage options, and role-based access that maps to CIP evidence requirements.

We’ve deployed this into utility environments across New England including a Massachusetts municipal electric utility that stood up AtlasCyber with no cloud connectivity, no baseline period and no added staffing and had it monitoring IT and OT environments within minutes. The audit artifacts are generated automatically. The evidence package builds itself as the program runs.

The standard isn’t going away

CIP-015-1 is approved and in effect. And FERC has already directed NERC to extend INSM requirements further to electronic access control and monitoring systems outside the ESP by September 2026.

This is the direction of travel. INSM isn’t a one-time compliance task. It’s the foundation of a program that tells you what’s actually happening on your network, in the environments where the consequences of not knowing are highest.

If you’re working through CIP-015-1 implementation and want to talk through what it looks like in practice, reach out. We’ve done this across New England and we’re happy to share what we’ve learned.

www.crunchatlas.com/request-access