CIP-015 Clarified: Mixed-use PACS/EACMS and What’s Actually In Scope
By Patrick Miller
ERC Order 907-A clarifies CIP-015 on shared networks. INSM must monitor only east-west traffic used for access monitoring of EACMS and PACS. Non-CIP assets and data flows are out of scope, even in mixed-use or commingled PACS/EACMS environments. Learn practical patterns to filter collection, segment analytics, and produce audit-ready evidence.
Overview
Bottom line: You can share platforms, licenses, and even network segments with non-CIP systems. CIP-015 INSM only cares about specific east-west paths tied to EACMS and PACS, and not every packet your tool can technically see. That’s now overtly stated in FERC Order No. 907-A (Order on Clarification).
What FERC Just Clarified, and Why It Matters
Non-CIP assets are out of scope. On shared segments outside the ESP, the “CIP-networked environment” does not capture non-CIP assets. If a segment carries both corporate and CIP gear, INSM scope only covers east-west traffic used for access monitoring of EACMS and PACS; all other traffic to/from non-CIP devices on that segment is not in scope.
“Controllers” means in-scope CIP PACS controllers/EACMS. FERC confirmed the term does not sweep in generic/non-CIP controllers. CIP PACS to/from non-CIP PACS controller and EACMS to/from non-CIP comms are out; CIP PACS to/from CIP PACS-controller traffic is in scope.
The horizon stays the same. NERC still must draft CIP-015-2 to extend INSM outside the ESP to EACMS and PACS within 12 months of the final rule’s effective date, but now with these scoping guardrails.
Plain English: INSM follows trust, not license count, platform, or other forms of logical or physical grouping. If you commingle assets or networks, you are required to monitor only the communications between BCS, EACMS, PACS, and PCAs that support access monitoring. Nothing more.
How to Share Platforms or Licenses
Put scope in writing (R1.1)
Your INSM process should say: “On shared hardware/tenants, we ingest only CIP paths (strictly between BCS, EACMS, PACS, and PCA) and exclude all non-CIP traffic even if visible to the tool.” Back it with a diagram showing how and where you filter.
Constrain collection technically
Use SPAN/TAP directionality, BPF/ACL filters, VRFs/VDOMs so only in-scope conversations hit the collector. If a license would let you pull everything, don’t. Where possible, feed only the filtered streams into INSM.
Partition analytics and storage
Stand up a CIP-only tenant/workspace or pipeline that processes the filtered feeds. Evidence stores hold only anomaly-linked data from those feeds (R2) and are protected from tampering (R3). This is also how you keep corporate confidential or similarly restricted/controlled data out of the vault to keep from mixing regulatory footprints.
Separate the management plane
If the shared box is administered by both CIP and non-CIP teams, segregate credentials and admin paths so non-CIP admins cannot alter CIP capture/retention or delete evidence (R3 intent).
Label “controllers” correctly
Your diagrams and SOPs should use CIP PACS controller (in-scope) vs non-CIP PACS controller (out-of-scope) so no one “accidentally” widens scope during audits.
Three Reference Patterns That Work
Dedicated context on shared hardware
One SIEM/firewall/NAC, with a CIP-only VDOM/tenant: separate mirroring, RBAC, and storage; filters at ingress.
Pro: leverages existing spend
Con: requires careful admin separation
Out-of-band CIP collector
Leave the shared platform for operations, but use only filtered CIP paths to a separate collector feeding INSM.
Pro: clean evidence chain
Con: extra boxes/links.
Edge filtering on PACS/EACMS uplinks
Apply capture filters right where PACS/EACMS uplink into shared cores/distribution. Corporate traffic never enters the INSM pipeline.
Pro: minimal noise
Con: needs precise network maps.
Recommended Evidence Components
Scope statement quoting and referencing 907-A: non-CIP assets/traffic out of scope; only access-monitoring east-west for EACMS/PACS is in.
Diagrams of shared segments showing filter points and which VLANs/ports are mirrored (CIP paths only).
Configs (SPAN/BPF/ACL/tenant routes) proving exclusions.
Analytics/tenant metadata showing only CIP feeds are processed.
Case records from anomalies originating on those scoped paths, with retained artifacts and integrity controls (R2/R3).
Common Traps to Avoid
“We licensed it, so we ingest it all.” License breadth does not equal CIP scope. That said, don’t vacuum up corporate traffic and hope to justify later. 907-A says it’s out but don’t make it hard for the auditors to understand your approach.
Watch for controller/asset label drift. Only CIP PACS controllers/EACMS are in play. Non-CIP PACS controllers are not bound to CIP. Be sure to inventory and label correctly. Consider this as part of initial commissioning and then maintain through strong/reliabile change management controls.
Unsegmented admin. If non-CIP admins can disable your capture or nuke your evidence, you’ve undercut R3’s purpose. Be sure to procedurally restrict this at a minimum, but even better, remove the technical capability and audit for any changes to your config.
The Question We’re Getting the Most
Q: “Our PACS environment controls both CIP and non-CIP doors and readers. Are the non-CIP assets/flows in scope because they live in the same PACS?”
A: No. FERC explicitly says the CIP-networked environment does not capture non-CIP assets or their traffic on shared segments. Scope the INSM to access-monitoring traffic and communication between BCS, EACMS, PACS, and PCAs, but not the rest of that segment.
Paste-Ready Policy Language
The language below, or something along these lines, should be considered for your INSM policy set.
“We operate shared security platforms across CIP and non-CIP networks. For CIP-015, our INSM collects and analyzes only communications between BES Cyber Systems, EACMS, PACS, and PCAs used for access monitoring on shared segments; all other traffic is excluded by design via technology-specific filters. This aligns with Order 907-A clarifying that non-CIP assets/traffic are out of scope.”
Final thought
CIP-015 is a program, not a product. 907-A gives operators relief from “monitor everything” fears on mixed networks and focuses you on the trust plane that matters: access monitoring paths for EACMS and PACS. Build your collection and analytics around those paths, prove your exclusions, and protect your evidence. You’ll be compliant and better prepared to catch the slow, lateral activity your perimeter never saw.
