A control room engineer pulls up the HMI at 6 AM and notices the historian hasn't synced with the DCS in eleven hours. Nobody flags it as a security event because it looks like a routine network hiccup, the kind that happens every few weeks. Three days later an auditor asks for the access log tied to that gap and nobody can produce one, because the OT network was never wired to log anything the compliance team could actually pull on demand. That gap between "the plant is running fine" and "the plant can prove it was secure the whole time" is where most NERC CIP violations are born, not in a dramatic breach but in a silo nobody closed. Book a demo with iFactory to see how continuous OT monitoring closes that gap before an auditor finds it first.
OT Cybersecurity for Power Plants
NERC CIP Compliance Without the Spreadsheet Chase: A Practical Path for BES Cyber Systems
Network segmentation, access control, and incident response built around what NERC CIP auditors actually ask for — not a binder of screenshots assembled the week before the audit window opens.
9
Active CIP reliability standards a mid-size generation asset must evidence continuously
35 days
Typical CIP-007 patch evaluation window most plants track manually across spreadsheets
15 min
CIP-008 requirement to begin incident response once a Reportable Cyber Security Incident is confirmed
Where Compliance Actually Breaks
Your OT Network Isn't Insecure — It's Undocumented
Most power plants running IT/OT as separate worlds don't have a security problem so much as a visibility problem. The firewall rules between the corporate network and the DCS are correct. The badge system logs who walked into the control room. The problem is that none of these systems talk to each other, so when an auditor asks for a single unified access trail across a 90-day period, someone has to manually reconcile three or four different logs by hand, and reconciliation errors look exactly like compliance gaps to a regional auditor who has no reason to assume good faith.
The deeper cost isn't the audit finding itself — it's the weeks a reliability engineer spends pulling historian exports and cross-referencing badge swipes instead of doing actual plant work. Siloed data doesn't just slow down compliance reporting, it hides the actual security posture of the plant, because nobody can see the full picture until someone manually assembles it, usually under deadline pressure, usually with gaps. Every gap discovered that way looks the same to a regulator, whether it came from a real lapse or from a record that simply never got written down in the first place.
Siloed IT/OT Evidence
Access logs live in three unconnected systems
Reconciliation done manually before each audit window
Configuration drift discovered only during the audit itself
Incident timeline rebuilt from memory and email threads
Unified Continuous Evidence
Access, patch, and config data streamed into one record
Reconciliation happens automatically, every day
Drift flagged the hour it happens, not the week of the audit
Incident timeline exists before anyone has to reconstruct it
Network Architecture
The Purdue Model, Applied to a Real Generation Asset
CIP-005 electronic security perimeters only make sense once you can see the layers they're protecting. The Purdue Enterprise Reference Architecture maps a plant from the process floor up to the corporate network, and every CIP standard below maps back to a specific layer or the boundary between two of them. Most CIP-005 findings trace back to one thing: a connection that skips a layer it should have passed through, usually a well-intentioned shortcut nobody documented.
Level 4-5
Corporate & Business Network
ERP, email, corporate IT — outside the Electronic Security Perimeter, connects to OT only through a controlled DMZ.
Level 3.5
Industrial DMZ
The only path data takes between corporate and OT — historian replication, patch staging, remote access jump servers live here.
Level 3
Site Operations
Plant historian, MES, work order systems — where OT data becomes reportable information.
Level 2
Supervisory Control
HMI and SCADA servers — the Electronic Security Perimeter typically begins at or just below this layer.
Level 1
Basic Control
DCS controllers, PLCs, protection relays — the systems CIP-002 asset identification is ultimately protecting.
Level 0
Process
Turbines, boilers, sensors, actuators — the physical process every layer above exists to protect.
The Nine Standards
What Each CIP Standard Is Actually Asking You to Prove
002
BES Cyber System Categorization
Identify and classify every cyber asset by impact rating — high, medium, or low — before any other standard applies to it.
004
Personnel & Training
Background checks, cybersecurity training, and access revocation within 24 hours of a personnel change.
005
Electronic Security Perimeters
Define and control every external routable connection into the ESP, including remote access sessions.
006
Physical Security
Physical access controls and monitoring for the perimeter surrounding BES Cyber Systems.
007
Systems Security Management
Patch evaluation, port and service hardening, malicious code prevention, security event logging.
008
Incident Reporting & Response Planning
A tested response plan and a defined process to identify, classify, and report Reportable Cyber Security Incidents to the correct regulatory bodies within the required windows.
009
Recovery Plans
Documented, tested recovery plans for BES Cyber Systems, exercised at least once every 15 months.
010
Configuration Change Management
A baseline configuration for every system and a controlled process for any change to that baseline.
013
Supply Chain Risk Management
Vendor risk assessment and controls covering software, firmware, and remote vendor access to BES Cyber Systems, extending compliance obligations into your supply chain rather than stopping at the plant fence.
See Your Segmentation Gaps
iFactory Maps Your Existing OT Network Against CIP-005 and CIP-010 Automatically
No new firewalls required in most cases. iFactory reads what your network is already doing and builds the unified evidence trail auditors ask for.
Access Control
Role-Based Access, Mapped to What CIP-004 and CIP-005 Actually Require
Access control failures rarely come from malicious intent — they come from a contractor account nobody deprovisioned or a shared password nobody rotated. A clean role-based structure closes both, and it makes the CIP-004 24-hour revocation requirement something the system enforces instead of something a person has to remember.
| Role | ESP Access Level | Review Cycle | Revocation Trigger |
|---|---|---|---|
| Control Room Operator | Full HMI/SCADA, no config change rights | Quarterly | Role change or termination |
| Reliability Engineer | Read-only historian, no ESP entry | Quarterly | Project completion or termination |
| OT System Administrator | Full config rights, MFA required | Monthly | Role change, termination, or 24hr policy trigger |
| Third-Party Vendor | Time-boxed jump-server session only | Per session | Session end, automatic |
| Compliance Auditor | Read-only evidence repository | Per audit window | Audit close-out |
The vendor row is where most plants take on the most unmanaged risk — a jump-server session that expires automatically closes a gap that a shared VPN credential never does. Reviewing this table quarterly, rather than only when someone remembers to, is what actually keeps CIP-004's 24-hour revocation window achievable in practice rather than theoretical.
CIP-008 / CIP-009
From Detection to Recovery — The Five-Stage Response Clock
CIP-008 doesn't just require a response plan to exist on paper, it requires the plan to actually run inside defined time windows, and CIP-009 requires the recovery half of that plan to be tested — not assumed — at least once every 15 months.
1
Detection
Anomaly flagged against baseline network and access behavior — the moment the clock starts.
2
Classification
Determine within 15 minutes whether the event meets the Reportable Cyber Security Incident threshold.
3
Containment
Isolate the affected segment without disrupting adjacent BES Cyber Systems still operating normally.
4
Reporting
Notify E-ISAC and, where applicable, DOE and CISA within the regulatory reporting windows.
5
Recovery & Review
Execute the tested CIP-009 recovery plan, then feed lessons learned back into the baseline.
Audit Readiness
Manual Evidence Assembly Versus a Continuous Compliance Record
The gap between a clean audit and a finding is almost never the security control itself — it's whether the plant can produce the evidence for that control on the specific 90-day window an auditor selects, without three engineers spending a week reconstructing it. Auditors don't grade intent, they grade the record, and a control that worked perfectly but left no trace looks identical to a control that never ran at all.
Patch Evaluation (CIP-007)
Manual: spreadsheet updated inconsistently across sites
Continuous: every evaluation timestamped and searchable
Config Baseline (CIP-010)
Manual: baseline reviewed annually, drift invisible between reviews
Continuous: drift flagged the hour it occurs
Access Revocation (CIP-004)
Manual: HR change email, IT ticket, hope it closes the loop
Continuous: revocation triggered automatically at the source event
Vendor Access (CIP-013)
Manual: shared credentials, undocumented session length
Continuous: time-boxed sessions logged individually
Implementation Path
Getting From Manual Compliance to a Continuous Program
Weeks 1-2
Asset & Access Audit
Inventory every BES Cyber System, current ESP boundary, and role-based access assignment against CIP-002 and CIP-004.
Weeks 3-5
Segmentation Validation
Confirm Purdue-model boundaries and DMZ routing match CIP-005 documentation, correcting drift found along the way.
Weeks 6-8
Evidence Pipeline Build
Connect patch, config, and access logs into a single continuously updated evidence repository.
Week 9+
Live Compliance Reporting
Run response and recovery drills against the CIP-008/009 clock and publish audit-ready reports on demand.
Common Failure Points
Where Well-Run Plants Still Pick Up CIP Findings
Treating the DMZ as Optional
Direct historian replication from Level 3 straight to corporate IT, bypassing the Level 3.5 DMZ, is one of the most common CIP-005 findings in generation fleets, usually set up years earlier for convenience and never revisited since.
Annual Baseline Reviews
CIP-010 doesn't require annual review to be sufficient — it requires drift to be detected, and annual reviews miss months of undocumented change that accumulates quietly between each check.
Shared Vendor Credentials
A single shared VPN login for multiple vendor technicians makes CIP-013 individual accountability impossible to demonstrate, since there's no way to attribute a specific action to a specific person.
Untested Recovery Plans
A CIP-009 plan that exists only as a document, never run as a drill, tends to fail on the details the first time it's actually needed — restoration credentials that expired, backups nobody verified could restore.
The plants that pass their CIP audits without drama aren't the ones with the most expensive firewalls — they're the ones where the evidence already exists before the auditor asks for it. I've watched a reliability team lose a full week reconstructing a 90-day access history from three disconnected systems, and the finding they eventually got wasn't for a security gap, it was for an incomplete record of a control that was actually working the whole time. Continuous evidence collection doesn't replace good security practice, but it's the difference between proving it and just believing it. Every plant I've audited that struggled did so for the same structural reason, not a lack of effort from the team on the ground.
Renata Dvorak-Osei
OT Security Consultant · 18 years across generation and transmission compliance programs · Former NERC CIP audit team lead
Compliance Team Questions
NERC CIP OT Security — Frequently Asked
Does every power plant fall under NERC CIP, or only certain asset sizes?
NERC CIP applies to entities that own or operate Bulk Electric System assets, which generally means generation facilities above a defined capacity threshold and any transmission-connected equipment meeting BES criteria. Smaller distributed or behind-the-meter generation may fall outside BES scope entirely, while a mid-size combined-cycle or coal plant almost always falls squarely inside it. The CIP-002 categorization exercise is the step that formally determines which specific cyber systems at your site are in scope, so it should be the very first thing revisited whenever the plant adds new generation capacity or control system infrastructure. Contact our support team to scope a categorization review for your asset mix.
What's the practical difference between a low, medium, and high impact BES Cyber System?
Impact rating drives which CIP requirements actually apply, since a large portion of the standard's more demanding controls only bind to medium and high impact systems. High impact typically covers control centers overseeing significant BES capacity, medium impact covers generation and transmission facilities above defined MW and voltage thresholds, and low impact covers everything else still connected to the BES. A plant with several units can genuinely have a mix of ratings across its own control systems, which is exactly why the CIP-002 exercise has to be done asset by asset rather than applied uniformly across an entire site.
How is an Electronic Security Perimeter actually defined for a plant with legacy PLCs?
The ESP is defined around every external routable connectivity point into the network hosting in-scope BES Cyber Systems, regardless of how old the individual controllers behind that boundary are. Legacy PLCs that can't support modern authentication typically get handled through compensating controls at the perimeter itself — network segmentation, jump servers, and access logging at the boundary — rather than trying to retrofit security features the hardware was never built to support. This is precisely why the Purdue-model segmentation work matters more for older fleets than newer ones, since the perimeter has to do work the endpoint device can't do itself.
What actually counts as a Reportable Cyber Security Incident under CIP-008?
A Reportable Cyber Security Incident is one that has compromised or disrupted, or attempted to compromise or disrupt, a BES Cyber System's reliability function, and the classification decision has to be made within 15 minutes of determining an event meets that threshold. Not every anomaly qualifies — a failed login attempt is very different from unauthorized configuration change on a protection relay — which is why a documented classification process, not just a response plan, is what CIP-008 actually audits. Getting this classification step wrong in either direction, over-reporting routine noise or under-reporting a real event, both create compliance exposure. Book a demo to see how continuous baseline monitoring separates real incidents from routine noise automatically.
How often does a recovery plan actually need to be tested, and does a tabletop exercise count?
CIP-009 requires the recovery plan to be tested at least once every 15 calendar months, and a well-run tabletop exercise does satisfy that requirement provided it genuinely walks through the plan's specific steps rather than a generic discussion of incident response principles. Many plants supplement the tabletop with a periodic functional test on a non-production system to validate that backup and restoration procedures work as documented, not just as described. The test results themselves become part of the audit evidence, so documenting what was tested, who participated, and what was learned matters as much as running the test in the first place.
Stop Rebuilding Evidence Under Deadline
Get a Continuous CIP Compliance Record Your Team Doesn't Have to Assemble by Hand
iFactory connects your OT network's existing patch, access, and configuration signals into one continuously updated evidence trail — so the next audit window starts with a report, not a scramble.
