This post is part of a blog series recapping highlights from our webinar series, where industry experts share their knowledge and field lessons from utilities building internal network security monitoring (INSM) programs. In the fourth episode, we focused on one of the trickiest and most nuanced topics in INSM implementation: how to classify the components of your INSM. I was joined by my Nozomi colleague, Mike Dutko, who has an extensive background in both OT cybersecurity and electrical engineering.
When we polled attendees during episode #4 of our INSM webinar series, a surprising number selected “don’t know” when asked how they planned to classify their INSM sensor. And when asked whether their INSM sensor would be inside the Electronic Security Perimeter (ESP), there was uncertainty. That uncertainty is common, so we’ve done our best to unpack the many factors that lead to sound decisions that support compliance.
Why Classification Matters
Correct classification isn’t just a regulatory checkbox. It determines which requirements apply, how much audit risk you carry, and ultimately, how much effort your team will spend maintaining compliance. Classification isn’t new to the Reliability Standards; it touches eight of them (CIP-004 - 011). INSM is just a new system you must classify. Bottom line: classify every INSM asset correctly to limit requirements and risk.
This oversimplified chart shows how these classifications translate into compliance efforts. While each program is different, the level of effort tends to align.
INSM System Components: Not Just One Thing
INSM deployments are often discussed as a single system, but in practice, they’re made up of multiple components, each potentially requiring a different classification. They fall into three main areas:
- Data feed sources: Collection and aggregation points including network taps, switches, aggregator switches, traffic brokers, sensors and data diodes
- Data feed processing: Ingestion, processing and management, which may be distributed or centralized
- Storage and analytics: Data storage, analytics and evidence repositories, often feeding SIEMs, ticketing systems or compliance platforms
Each component’s capabilities, architecture and function can impact its classification and compliance requirements.
Common INSM Classifications
The three most common classifications for INSM components are:
- EACMS (Electronic Access Control or Monitoring Systems): Cyber assets that perform electronic access control or monitoring of the ESP or Bulk Electric System (BES) Cyber Systems. These typically carry the highest compliance burden.
- PCA (Protected Cyber Assets): Cyber assets connected within the ESP that aren’t part of the highest-impact BES Cyber System. The impact rating is equal to the highest-rated BES Cyber System in the same ESP.
- BCSI Storage Locations: Systems that store BES Cyber System Information. While not a NERC glossary term, BCSI Storage Location is referenced in CIP-011 and often tracked as part of BES asset classification.
CIP-015-2: Function Matters Just as Much as Location
With CIP-015-1, which will be enforced in 2028, location within or outside the ESP was the main driver for INSM classification. CIP-015-2 changes that by bringing EACMS and physical access control systems (PACS) into scope. Many of those systems live outside the ESP, and their function is as important as location. For example, would the switch with a mirror port connected to the PACS be considered in scope of your INSM classification? I would recommend not, but I would make sure your program has clear reasoning why not. This complexity means that classification under CIP-015-2 just got much harder.
Four Basic Questions to Guide INSM Classification
To simplify some of the complexity around classification, I recommend starting with four basic questions:
Use This Decision Tree to Classify Your INSM Components
Through many working sessions with asset owners, partners and other industry experts, we’ve refined the four questions above into this decision tree that walks through the classification process step by step. It starts with impact, then location, function, management interfaces, communication paths, and finally, whether the system stores or processes BCSI. This practical tool helps utilities navigate real-world architectures and arrive at defensible classifications.
Key Takeaways
INSM system classification is a complex subject full of nuances and NERC CIP nerdiness, so much so that we previously blogged about it in December, before CIP-015-2 added system function into the mix. In addition to the starter questions and decision tree above, here are five recommendations to help you address classification in your INSM program.
If you don't document your methodology, at audit time you may be asked to defend some of your decisions, including omissions. Auditors love to pull threads. Documentation gives them confidence that you’ve thought everything through.
- Treat all of your INSM system components as in-scope for NERC CIP. INSM isn’t just one thing. In addition to the monitoring sensor, it may include a headend or management console, or wherever the data is stored. Each component must be reviewed and classified separately.
- If NERC doesn’t define it, define it yourself. NERC’s glossary of terms is exacting, but what about terms that aren’t included, such as BCSI storage locations? It’s up to you to define them based on what they mean in your program.
- Document your decision process and outcome for every asset. If you don't document your methodology, at audit time you may be asked to defend some of your decisions. Documentation gives them confidence that you’ve thought everything through.
- Maintain an INSM asset list with classification. Your asset inventory should include all your INSM components, regardless of their function and classification. This is especially important for anything outside of the ESP or scope.
- Revisit your assessment at least annually and upon any major change. Go back to your rationale and review any changes. For example, review drawings and make sure your sensors are actually where you said they’d be. There are bound to be discrepancies.
Final Thoughts
Classification isn’t just about compliance; it’s about risk management, operational clarity and audit defensibility. Don’t wait until after deployment to decide how you’ll classify your INSM components. Have these conversations early, challenge assumptions and document your reasoning. It will pay dividends during audits, expansions and inevitable architecture changes.
If you found this post helpful, I encourage you to register for the webinar series and watch the episode #4 replay where Mike and I delve into INSM system classification as only two NERC nerds can, complete with detailed diagrams. And if you need help applying anything we’ve shared to your own architecture, reach out. We’re here to support you.
.webp)
