CIP-002 Asset Identification — A Practical Guide

CIP-002 is the foundation of the entire NERC CIP compliance program. Get it wrong and every other standard has a problem — because the BES Cyber Systems you identify here determine what CIP-003 through CIP-011 apply to. This guide walks through how to do it correctly, what auditors look for, and the mistakes that generate findings.

What CIP-002 Actually Requires

CIP-002 requires responsible entities to identify their BES (Bulk Electric System) assets, identify the BES Cyber Systems associated with those assets, and then categorise each BES Cyber System as High, Medium, or Low impact based on defined criteria.

There are three requirements:

• R1 — Identify each of your BES assets using Attachment 1 criteria, then identify the BES Cyber Systems associated with each. Categorise each as High, Medium, or Low impact.
• R2 — Review and approve the categorisation at least once per calendar year and within 60 days of a change that triggers re-evaluation.
• R3 — Have the CIP Senior Manager or delegate review and approve the categorisation list.

Step 1 — Identify Your BES Assets

Before you can identify BES Cyber Systems, you need to identify your BES assets. Typical BES assets include generation resources at or above 20 MVA, transmission facilities at 100 kV or above, reactive and black start resources, and control centers performing reliability functions. If you're unsure whether a specific asset is BES, request a formal BES determination from your Regional Entity — this is documented, which is exactly what you want for audit purposes.

Step 2 — Identify BES Cyber Systems

For each BES asset, identify the Cyber Assets that could, if compromised, affect reliable operation within 15 minutes. These are your BES Cyber Assets. Group them into BES Cyber Systems — one or more BES Cyber Assets logically grouped to perform one or more reliability tasks.

Step 3 — Apply the Impact Rating Criteria

Attachment 1 of CIP-002 defines the criteria for High and Medium impact ratings. Anything that doesn't meet High or Medium criteria is Low impact by default. High impact typically covers Control Centers at 300 kV or above and transmission facilities at 500 kV or above. Medium impact covers most other Control Centers, generation above 1500 MW, and systems performing UFLS/UVLS or Special Protection System functions.

What Auditors Look For

Building an Asset Inventory Auditors Accept

Your BES Cyber System inventory must include at minimum: BES asset name and location, BES Cyber System identifier, impact rating (H/M/L), categorisation rationale citing the specific Attachment 1 criterion, list of BES Cyber Assets in the system, review date, and CIP Senior Manager approval signature. Keep prior versions — auditors may review changes over time and ask why a rating changed.

Managing Triggered Reviews

CIP-002 R2 requires re-evaluation within 60 days of any change that might affect a BES Cyber System's categorisation — new assets coming online, facility upgrades crossing a voltage threshold, changes to how a Control Center performs reliability functions, and new Cyber Assets added to an existing system. Build a process integrated with your change management system that flags these events automatically.

Low Impact Systems — Don't Ignore Them

Many organisations focus heavily on High and Medium impact systems and treat Low impact as a checkbox. CIP-003 R4 and R5 impose real requirements on Low impact BES Cyber Systems. Your Low impact inventory doesn't need to be as detailed as High/Medium, but it needs to exist. An undocumented Low impact BES Cyber System is still a compliance gap.

Published by PROMEC Systems. Based on NERC CIP v6. Always verify against current NERC standards and your Regional Entity's audit guidance. Not legal or regulatory advice.

Ignition SCADA I/O Lists — What to Include and Why

The I/O list is the foundational document of every SCADA project. Everything else — loop sheets, tag databases, alarm philosophies, commissioning checklists — flows from it. Yet most engineers either include too little (leaving gaps that cause rework) or too much (creating a document nobody maintains). This guide covers what belongs in an Ignition I/O list and why each column matters.

What an I/O List Actually Is

An I/O list is a structured register of every field signal entering or leaving your control system — every analogue input, digital input, analogue output, and digital output, plus any virtual or calculated points that need to be documented. It serves four purposes simultaneously: design reference for the tag database, procurement base for I/O card counts, commissioning record for signal verification, and as-built documentation for ongoing maintenance.

The Essential Columns

Columns Most Engineers Miss

Deadband / Exception Reporting

For analogue inputs feeding an Ignition Tag Historian or OSIsoft PI, document the deadband or exception reporting threshold. Without this, you get either too much data (every scan stored) or too little. Put it in the I/O list so it gets configured correctly at commissioning — not discovered missing six months after go-live.

Alarm Setpoints

If a tag has process alarms configured in Ignition's Alarm Notification system, document the setpoints — High, High-High, Low, Low-Low. This doesn't replace an alarm philosophy document, but it gives commissioning engineers a reference during FAT and SAT.

Historical Tag Reference

If you're using OSIsoft PI alongside Ignition, document the PI Point Name for each historically logged signal. Mismatches between Ignition tag names and PI point names are a common source of data quality issues that are expensive to untangle after go-live.

Tag Naming Conventions in Ignition

Ignition's folder-based tag structure means your naming convention determines your tag path structure. Getting this right at the start saves significant rework.

# Structure: [Provider]/Site/Equipment/Signal

[default]/SITE_A/PUMP_01/RunStatus
[default]/SITE_A/PUMP_01/SpeedFeedback   # AI — kW
[default]/SITE_A/PUMP_01/StartCommand    # DO
[default]/SITE_A/PUMP_01/FaultStatus     # DI

Key rules: use underscores not spaces or hyphens, UPPER_CASE for equipment and site identifiers, PascalCase for signal names, keep equipment codes consistent with P&ID tag numbers, and don't embed engineering units in the tag name. Most importantly — agree the convention before the first tag is created.

Common Mistakes That Cause Commissioning Rework

Published by PROMEC Systems. Based on Ignition 8.1. Tag naming recommendations reflect best practices from production SCADA deployments across generation, transmission, and process industries.

OT Network Segmentation — DMZ Design for Industrial Systems

Connecting an OT network to enterprise infrastructure without proper segmentation is one of the highest-risk things an industrial organisation can do. Not because connectivity is inherently dangerous — but because most teams design the firewall rules before they design the architecture, put the wrong servers in the wrong zones, and create paths between IT and OT that are never documented and therefore never reviewed.

Why OT Network Segmentation Is Different

IT network segmentation is about protecting data. OT network segmentation is about protecting physical processes — and the consequences of getting it wrong are not a data breach, they're a generation trip, a process upset, or physical damage to equipment. This changes the design priorities. In OT, patch windows are planned months in advance, system restarts may require controlled process rundown, and brief communication interruptions can cause spurious trips or missed events. The architecture must protect the OT network without affecting system availability or performance.

The Three-Zone Model

The defensible baseline architecture for industrial systems connecting to enterprise infrastructure is three zones separated by two firewalls:

The key principle: OT-initiated traffic can flow from OT to DMZ. Enterprise-initiated traffic cannot reach the OT zone. The historian in the DMZ pulls data from the OPC server in the OT zone — not the other way around.

What Goes in the DMZ

Should be in the DMZ

• Historian server — OSIsoft PI, SQL Server, or Ignition Tag Historian. Must live in the DMZ, not in the OT zone and not in the corporate network.
• Jump server / bastion host — The only path for remote access into the OT zone. All vendor, support, and engineering remote sessions terminate here first. MFA required.
• File transfer server — For moving files between enterprise and OT zones in a controlled, logged manner. Replaces USB drives and email attachments.
• Patch staging server — Approved patches are copied here before being pushed to OT systems.
• AV/endpoint update server — OT systems pull signature updates from here, not directly from the internet or corporate network.

Should NOT be in the DMZ

• SCADA application servers — These belong in the OT zone. A SCADA server in the DMZ is exposed to enterprise.
• Active SCADA HMI clients — An active HMI with write access to OT devices must be in the OT zone.
• Safety systems — SIS requires physical separation, not just logical separation.
• Domain controllers with write access — Creates a path for lateral movement from corporate to OT via domain trust.

Firewall Rules — The Minimum Viable Ruleset

Every rule in your firewall ruleset should be justified by a specific operational requirement. "Allow any" rules in either firewall are a compliance failure under NERC CIP CIP-005 and a security failure. Each rule needs a named source, named destination, specific protocol and port, and a business justification. Rules without justifications don't survive an audit review.

NERC CIP CIP-005 Requirements

For NERC CIP-regulated systems, CIP-005 defines the Electronic Security Perimeter (ESP). The three-zone DMZ architecture maps directly to compliance: the OT zone boundary (Firewall 2) defines your ESP; all Interactive Remote Access must go through an Intermediate System (your jump server); MFA is required for all remote access; and sessions must be encrypted. Auditors will ask for your ESP diagram and want to see that every line maps to a documented, justified firewall rule.

Common Segmentation Mistakes

Published by PROMEC Systems. Architecture recommendations align with NERC CIP CIP-005 and IEC 62443 zone-and-conduit model principles. Review designs with your IT security team and validate against your regulatory requirements.