CIP-015-1 R1 internal network security monitoring

What CIP-015-1 R1 asks for before enforcement starts in 2028

CIP-015-1 R1 requires documented processes for internal network security monitoring inside the Electronic Security Perimeters of high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity. For Control Centers, enforcement begins on 1 October 2028, and other medium impact systems with External Routable Connectivity are phased in over the following 24 months. The requirement has three parts. Part 1.1 asks you to implement network data feeds, selected with a documented risk-based rationale, that cover connections, devices and network communications. Part 1.2 asks for methods that detect anomalous network activity using those feeds. Part 1.3 asks for methods that evaluate each detected anomaly to decide what happens next. R1 carries a Medium Violation Risk Factor, which signals that NERC regards a miss as significant but not the most severe category. The difficult part is the scope. Most CIP requirements look at the boundary, at Electronic Access Points, remote access and the systems that cross into the perimeter. R1 looks inside the ESP, at east-west traffic between Cyber Assets that many organizations have never instrumented. Start by inventorying the ESPs in scope, the network segments and devices within them, and the places where a sensor could see traffic without disrupting control operations. Confirm with your Regional Entity and internal engineering which sensors, taps or span ports are already available and which would need to be added, since the feasibility of each feed shapes the rationale you will have to defend. Do not wait for the 2028 date to write the risk-based rationale. Auditors will expect it to explain why each selected feed was chosen and why others were not, tied to the assets and threats in your environment, and it should be reviewed when the network changes. Build the evaluation process at the same time, including who triages an anomaly, how it is escalated and when it becomes a Cyber Security Incident under the CIP-008 incident response plan. Those decisions, not the sensor purchase, are what an assessor will test first.

Which systems and teams fall under R1 scope

CIP-015-1 R1 reaches only the networks inside the Electronic Security Perimeters of high impact BES Cyber Systems and medium impact BES Cyber Systems with External Routable Connectivity. The scoping decisions below determine how much monitoring you build, and the teams that own each piece need to agree on them before any data feed is selected.

High and medium impact categorization

Start from your CIP-002-5.1a categorization. High impact BES Cyber Systems, mainly Control Center systems, are in scope for R1. Medium impact systems are in scope only when they have External Routable Connectivity, so a medium impact plant with no routable path out of its ESP falls outside R1. Re-check the categorization after any new asset, acquisition or change to a Control Center.

ESP networks to monitor

Map each Electronic Security Perimeter that encloses an in-scope BES Cyber System, then document which network segments sit inside it. R1 monitoring applies to networks protected by those ESPs. Confirm whether shared network segments, jump hosts or Protected Cyber Assets sit inside one ESP or straddle several, because that affects where sensors go and how evidence is grouped.

Control Center phase-in date

Control Centers with in-scope high impact systems are the first group to face R1, with enforcement from 1 October 2028 under the CIP-015-1 implementation plan. Confirm the date applies to your Control Center systems and not only to a parent organization. Plan the first complete monitoring cycle backward from that date, including procurement, sensor placement and baseline collection.

Other medium impact phase-in

Medium impact systems with External Routable Connectivity follow a later phase-in of 24 months after the Control Center date under the implementation plan. Record which of your medium impact ESPs have routable connectivity and when they were confirmed, since that determines which phase-in applies to each site. Do not assume all medium impact sites share the Control Center timeline.

Network engineering team

Network engineers own the physical and virtual data sources: SPAN ports, taps, firewall and switch logs, and flow exporters. They decide which data feeds are technically feasible inside each ESP, and they must document why each feed was chosen under the risk-based rationale that R1 Part 1.1 requires. Involve them early, since sensor placement often changes segmentation.

Operations and security operations

Operations staff know which connections, devices and communications are normal for each BES Cyber System, which is the basis for the baseline used to detect anomalies. Security operations staff own detection rules, alert triage and the decision on further action under Part 1.3. Agree who has authority to close an alert and who must be notified before escalation.

Compliance team and third-party monitoring providers

Compliance owns the evidence set, including the rationale for data feeds, detection events and escalation records. If a managed monitoring provider or contractor operates the system, the registered entity still owns the R1 obligation, so contracts must require the provider to produce evidence on request. Ask providers which in-scope networks they can access and how they retain logs.

How an assessor tests R1 and what they ask to see

This table sets out how an auditor typically approaches each part of CIP-015-1 R1, what evidence they request and the findings that come up most often. Read it as a checklist of what to have ready before a Compliance Audit, Spot Check or self-certification request. The main takeaway is that the rationale, the baseline and the evaluation records have to agree with each other and with the systems actually deployed.

Requirement area	Test approach	Evidence requested	Common findings
Documented process (R1 overall)	Confirm a written process exists for INSM covering ESPs of high impact and in-scope medium impact BES Cyber Systems, and that staff follow it.	Approved process document, revision history, scope statement tied to the CIP-002 categorization, and training or procedure acknowledgments.	Process covers only high impact systems and omits medium impact systems with External Routable Connectivity, or the process is not approved or dated.
Part 1.1: risk-based rationale	Check that the rationale explains why each selected data feed was chosen and how it relates to risk in the ESP.	Written risk-based rationale, network diagrams of the ESP, and a list of data feeds with their sources and purpose.	Rationale describes feeds that are not deployed, or deployed feeds have no rationale at all. Rationale is generic and not specific to the ESP.
Part 1.1: implemented data feeds	Compare the rationale to live configuration and walk through the feeds to confirm they capture connections, devices and network communications.	Sensor or sensor-output configuration, capture point placement, and screenshots or exports showing the feed is active.	Feeds are documented but collection is partial, misconfigured, or stopped. Coverage gaps are not explained or risk-accepted.
Part 1.2: detection methods	Review the detection methods in use and confirm they operate on the data feeds from Part 1.1.	Detection rule or detector inventory, INSM system configuration settings, and sample detection events traced back to their source feed.	Detection rules reference log sources that are not in the feed list. Detection is configured but not running or not tied to the ESP.
Part 1.2: network communication baseline	Confirm a baseline of normal network activity exists, how it was built, and how detections are measured against it.	Baseline documentation, date and method of creation, review or update records, and the detection logic that uses it.	Detection runs with no documented baseline, or the baseline was never reviewed after network changes. Baseline is undocumented for some segments.
Part 1.3: evaluation of detected anomalies	Select a sample of detected anomalous activity and trace each one to its evaluation record and determination.	Evaluation records for sampled events, analyst notes, triage criteria, and the determination reached for each event.	Evaluations with no recorded outcome, or closed alerts with no reasoning. Evaluation criteria are not written down or not applied consistently.
Part 1.3: actions taken	Check that determinations lead to documented further actions, including escalation where needed.	Action records such as tickets, containment steps, escalation records and links to CIP-008 incident response records where an incident was declared.	Actions are described in general terms only. Escalation paths exist on paper but no tickets show they were used.
Sampling approach	Assessors generally select a sample from the population of detected anomalies and check each evaluation end to end, rather than reviewing every event.	Population report or export of detected anomalies for the audit period, from which the assessor chooses items.	Organizations cannot produce a complete population, so sampling fails before the content is reviewed. Ask the Regional Entity how it will draw the sample.

How to implement R1 in sequence, with the output of each step

The sequence turns CIP-015-1 R1 into a working program: scope is fixed first, then data feeds, baseline, detection and evaluation are built in that order, and a review cycle keeps each output current. Each step leaves a written artifact that an auditor can trace back to the requirement.

Confirm scope from the CIP-002 categorization
Start from the entity's approved CIP-002 categorization to identify which BES Cyber Systems are rated high impact, and which medium impact systems have External Routable Connectivity. Those systems define the Electronic Security Perimeters that R1 covers. Confirm the ESP boundaries with the CIP Senior Manager and the operations team, because monitoring applies only inside those boundaries. The output is a scope register listing each in-scope ESP, its systems and the basis for each inclusion. The step is complete when the register matches the current categorization record and every ESP has a named owner.
Document the risk-based rationale for data feeds
Decide which network data sources to collect, such as connection records, device logs, flow data and communications between assets, and record why each was chosen. The rationale should explain the risk each feed helps detect and the coverage gaps it leaves. Security engineering and the asset owners review the draft together. The output is the risk-based rationale document, which R1 evidence expects to show. The step is complete when each in-scope ESP has a documented rationale signed off by the accountable manager.
Deploy network data feeds inside the ESP
Build the collection points described in the rationale inside each ESP, using the entity's own infrastructure and approved change process. Configure sensors, span or tap points, or log forwarding so that the chosen feeds reach the monitoring platform. Record each feed's source, destination, format and retention location. The output is a feed inventory and the configuration exports for each collector. The step is complete when every feed in the rationale is live, the inventory matches what is running, and gaps are logged as open items with owners.
Establish the network communication baseline
Observe normal traffic for each ESP long enough to describe expected connections, devices, protocols and communication pairs. Operations staff should validate the baseline against known system behavior, since an unvalidated baseline produces either noise or blind spots. Store the baseline with its collection period and the approver. The output is a baseline record that the detection methods will reference. The step is complete when operations has signed the baseline and changes to it go through a documented update process.
Define and test detection methods
Select detection methods that compare live feed data against the baseline, such as Suricata rules, Sigma-based detectors, or SIEM correlation rules, and map each method to the feed it uses. Test each method with known benign and simulated anomalous activity inside a non-production or approved test window. Tune thresholds to reduce false positives without disabling detection. The output is a detection configuration export and a test record showing what each method flagged. The step is complete when every method has a documented purpose, a tested result and an owner.
Write the evaluation process and escalation path
Write the procedure that decides what happens after an anomaly is detected: triage criteria, who evaluates it, how the evaluation is recorded, and which actions are possible, including closure, further investigation and escalation. Define the handoff to the CIP-008 incident response plan for anomalies that meet its criteria. Walk through the procedure with the security operations team using a sample alert. The output is the evaluation procedure and an escalation matrix. The step is complete when each alert category has a defined disposition path and the CIP-008 handoff is written into both documents.
Set up the review cycle and evidence retention
Establish a recurring review of the rationale, feed inventory, baseline, detection methods and evaluation records. Define who runs each review, what triggers an out-of-cycle review (such as a new asset, a changed ESP or a significant detection), and where evidence is stored. Confirm the retention period with compliance and legal, because the CIP-015 data retention and protection requirements apply to the monitoring data. The output is a review calendar and an evidence index that maps each artifact to R1. The step is complete when the first review has been run and recorded.

Evidence that passes R1 and how to keep it current

An assessor testing CIP-015-1 R1 will ask whether each part of the requirement can be shown with records dated inside the audit period. The six artifacts below map to the documented process, the data feeds, the detection methods and the evaluation steps, and each one goes stale quickly unless it is refreshed on a fixed schedule. The audit period and retention window depend on the Regional Entity, so confirm both with them before building the evidence calendar.

Risk-based rationale for data feeds

This is the written justification for which network data feeds you collect inside each ESP and why others are excluded. An assessor will check that the rationale names the feeds, ties them to the ESP's connections, devices and communications, and was reviewed when the network changed. Keep a dated version history and record each review, including reviews that concluded no change was needed. Confirm with your Regional Entity how it expects this document to be presented.

Anomalous network detection events

These are the alerts your detection methods raised against the collected feeds. An assessor will look for alerts that trace from the sensor to a stored record with timestamp, source, destination and rule or detection logic. Export matching alerts to durable storage on a schedule, so an event from early in the audit period is still retrievable at audit time. Confirm which alert fields your Regional Entity expects to see.

INSM system configuration settings

Configuration files and settings for sensors, rulesets, detectors and log forwarding show how the monitoring system was set up during the period. An assessor will compare exported settings against the documented process and check that changes went through your change management records. Export configurations on a fixed schedule and store them with a hash or version tag, so a later edit cannot quietly replace the earlier state. Relevant keys and files, such as suricata.yaml in a Suricata deployment, should be named in your procedure.

Network communication baseline

The baseline describes the normal connections, devices and communication patterns that your detection methods compare against. An assessor will ask how it was built, when it was last updated, and whether later anomalies were judged against the baseline that existed at the time. Store each baseline version with its date and approver, and record changes that follow planned network work. A baseline that was never updated is difficult to defend when the network has changed.

Records of actions on anomalies

Each detected anomaly needs a documented evaluation and a decision about further action, including the decision to take no action. An assessor will sample events and trace each one to the evaluator, the reasoning and the outcome. Tie every alert record to a case ticket that holds the evaluation notes, so the chain from detection to decision is preserved. Confirm with your auditor how closed, dismissed and false positive cases should be documented.

Escalation procedures referencing CIP-008

When an evaluation finds a possible Cyber Security Incident, the escalation path should lead into your CIP-008 incident response plan. An assessor will look for a written procedure that names the trigger, the handoff and the owner, and for evidence that the path was exercised or updated. Review the escalation steps whenever CIP-008 testing or plan updates occur, and keep records of those reviews. Confirm with your Regional Entity whether it expects a tabletop or live example to show the path works.

What meeting R1 costs in money and effort

This table compares each cost component of meeting CIP-015-1 R1, who is paid for it, whether it is one-time or recurring, and what moves it up or down. Read it as a checklist for a written quote, since no dollar figures or durations are supplied for this requirement. The main takeaway is that open-source software removes license spend but moves cost into engineering, tuning and evidence work.

Cost component	One-time or recurring	What drives it and how to reduce it
Sensor and data feed hardware or virtual appliances	One-time purchase or build, plus recurring hosting	Number of ESPs, link speeds and volume of traffic selected under the risk-based rationale. Narrow feeds to the segments that matter and confirm the hardware or virtual footprint in writing.
Monitoring software licenses	Recurring if commercial, often none for open source	Vendor licensing often scales with data volume or endpoints. Self-hosted open-source tools such as Suricata, Wazuh and OpenSearch can remove license spend, but confirm the edition and feature limits before assuming it.
Engineering time for deployment and baseline	One-time	Number of ESPs, asset types and protocols to baseline. A clear inventory of connections and devices shortens the work. Ask the quote to state the baseline method and what it covers.
Detection tuning and alert triage staffing	Recurring	Alert volume, false positive rate and the number of analysts on rotation. Tuning rules against the baseline early reduces noise. Ask who triages, at what hours and how escalation to CIP-008 is handled.
Evidence upkeep	Recurring	Frequency of configuration changes, baseline updates and retained records of anomalies and actions taken. Automated export of configuration settings and event records lowers the manual burden.
External testing or review	Recurring or periodic	Scope of any penetration test or independent review of the monitoring design. Ask whether testing covers detection coverage in the ESP, not only the perimeter.
Auditor sampling time	Recurring, per audit cycle	Entity-side effort is driven by how quickly evidence can be produced for sampled anomalies, baselines and data feed rationales. Organized evidence reduces the time auditors and staff spend on requests.

Which open-source tools can produce R1 evidence

Several open-source components can generate the records an auditor will ask to see for CIP-015-1 R1: network detections, alert logs and configuration. Each one covers a different layer of the monitoring chain, so the choice depends on where the data feeds sit inside the ESP and who will review the output.

OPNsense built-in IDS/IPS

OPNsense ships an intrusion detection and prevention system built on Suricata, which can load rulesets such as Emerging Threats and Abuse.ch and alert on or block matching traffic. It can forward alerts to syslog in EVE JSON format, which gives the team a retained detection record and a documented configuration. Check whether the chosen rulesets and sensor placement cover the ICS and OT protocols used in your ESP, and confirm the license terms for any commercial ruleset you add.

Suricata EVE JSON records

Suricata's EVE output writes JSON records for rule alerts, anomalies, flows and protocol transactions such as DNS, TLS, SSH and SMB. Flow and transaction records are the closest match to the network communication baseline that R1 evidence often needs, because they show who talked to whom and when. Confirm which protocol parsers are enabled for your OT traffic, since unparsed protocols produce fewer useful transaction records.

OpenSearch Security Analytics findings

OpenSearch Security Analytics runs detectors against ingested logs using prepackaged or custom Sigma rules and records each match as a finding with its rule, log type and severity. Its correlation graph links findings across log types, which helps an evaluator decide whether related events form one anomaly. Document which Sigma rules are enabled, who receives alert notifications, and how findings are closed out, because those records become the evaluation evidence for R1 Part 1.3.

Wazuh rules and alert logs

Wazuh decodes collected logs and compares each event against more than 3,000 built-in rules and decoders plus any custom rules. It writes matches to alerts.log and alerts.json and maps them to MITRE ATT&CK, which gives reviewers a common vocabulary for detections. Confirm that its agents or collectors can read the devices and historian sources inside your ESP, and that custom rules for OT protocols are tested and version controlled.

Who owns R1 and what an implementation partner can take on

Your organization owns CIP-015-1 R1 in full. The standard places the obligation on the registered entity, so the risk-based rationale for choosing data feeds, the decisions about which detected anomalies need further action, and the sign-off on the program stay with your staff. A partner can draft these artifacts, but your accountable owner must review, adopt and maintain them.

Risk-based rationale: Decide which network segments, device classes and communication paths inside each ESP get data feeds, and document why.
Anomaly evaluation decisions: Determine whether each detected anomaly is benign, needs investigation or triggers a CIP-008 response, and record the reasoning.
Baseline ownership: Approve the network communication baseline that detection is measured against, and review it when the environment changes.
Escalation and sign-off: Define who receives alerts, who can close them and how escalation reaches incident response.
Tool administration: Keep ownership of INSM configuration settings and their change records.

Before accepting a partner's draft, confirm that a named individual on your side can explain every rationale and decision in an audit interview.

Questions buyers ask about R1 cost, effort and outside help

How much effort does CIP-015-1 R1 take in-house compared with using a partner?

The effort depends mainly on scope: how many ESPs contain high impact BES Cyber Systems or medium impact BES Cyber Systems with External Routable Connectivity, how many network segments sit inside each perimeter, and how much traffic visibility you already have from firewalls, switches and existing logging. An organization with few perimeters and mature network telemetry will need far less new work than one that must add sensors, tune detections and document baselines across many sites. Ask a partner to split its quote into discovery, data feed design, detection build-out, evaluation procedures and evidence packaging, so you can see which parts your own staff must absorb and which the partner would carry. No figure applies to every environment, so treat any single number as a question to put to a written scope.

Can an organization meet CIP-015-1 R1 without an outside partner?

Yes, a registered entity can design, build and document its own internal network security monitoring program, since the standard places the obligation on the entity and not on a vendor. The harder parts are usually the risk-based rationale for choosing data feeds, a defensible network communication baseline, and written evaluation and escalation steps that connect to the CIP-008 incident response plan. Teams without staff who have run network detection engineering often underestimate the tuning work needed to keep alerts useful. A partner can supply that engineering capacity, but the organization still owns the decisions, the approvals and the evidence. Compliance is monitored by the Compliance Enforcement Authority, a Regional Entity or NERC, through audits, spot checks, self-certifications and self-reports, so keep records that show how your program actually runs.

What does R1 need from our internal staff?

R1 needs named owners who can decide and sign off, not just technicians who deploy sensors. Expect the following roles to be involved:

A network architect who can identify which feeds reflect real connections, devices and communications inside each ESP
A security analyst who reviews detections, records the outcome of each evaluation and decides on further action
A CIP compliance lead who maps the procedures to R1 and keeps evidence current
Operations staff who can change configurations and confirm that the system still matches what was documented

Staff time is recurring, because baselines drift as the network changes and detection rules need review. Confirm with any partner which of these roles it expects you to fill and for how many hours each month.

How do the 2028 and phase-in dates affect our planning?

CIP-015-1 R1 becomes enforceable on 1 October 2028 for Control Centers, and other medium impact systems with External Routable Connectivity are phased in over the following 24 months under the implementation plan. Because the enforcement dates differ by asset type, start with a categorization check under CIP-002 so you know which BES Cyber Systems fall under R1 and when. Work backward from your enforcement date to schedule procurement, network changes, baseline collection and the first documented evaluation cycle. Also check how the CIP-015-2 extension to EACMS and PACS, approved by FERC with an effective date of 1 October 2029, changes your scope. Confirm your exact dates against the NERC implementation plan rather than relying on summaries.

Do open-source tools remove license cost, and what do they add?

Open-source tools can remove software license fees for components such as intrusion detection, log analytics and alerting, but they do not remove cost. Each tool carries its own license terms, which you should review before deployment, and the work of integrating, hardening, tuning, upgrading and documenting them is paid for through staff time or a partner. For example, a sensor such as Suricata produces EVE JSON records that a log platform such as OpenSearch Security Analytics can ingest and match against rules, but someone must design that pipeline, protect the stored data and keep the rules current. Ask any partner to show how each tool supports the evidence list in the standard, including configuration settings, detection events and actions taken.

What should we ask for in a written quote for R1?

Ask for a written scope that names the ESPs, BES Cyber Systems and network segments in scope, and the data feeds the partner plans to use. The quote should list each deliverable, such as the risk-based rationale document, the INSM architecture, the baseline method, detection and evaluation procedures, escalation paths into CIP-008, and an evidence index. Separate one-time work, such as design and deployment, from recurring work, such as tuning, rule updates, log retention and review. Confirm which items the partner prepares and which only an independent auditor or the Regional Entity can assess, since no partner issues audit reports or certificates. Also ask for the assumptions behind each estimate and the change process if the network scope grows.

How DeployOpen scopes, implements and prepares R1 evidence

DeployOpen plans, implements and documents self-hosted open-source network monitoring inside the client's own infrastructure, so the entity keeps control of its ESP networks and its evidence. Our work prepares systems, documentation and evidence for R1. The organization remains responsible for its controls, and only an independent auditor or the Compliance Enforcement Authority assesses compliance.

How we scope

Confirm which BES Cyber Systems and ESPs fall under R1 based on the entity's CIP-002 categorization.
Document the risk-based rationale for selecting network data feeds, with each feed and the activity it monitors.
Agree the written scope, deliverables and timeline before work starts, since engagements are fixed-scope.
Confirm which other teams own CIP-008 escalation, change control and the network baseline inputs.

How we build

Deploy and configure the network sensors and monitoring stack inside the client's own environment.
Set up detection methods for anomalous network activity and tune them against a documented communication baseline.
Build the evaluation workflow that records what was decided on each anomaly and why.
Test detection and evaluation paths with the entity's staff so the processes work as documented.

How we hand over

Deliver documented processes covering data feed selection, detection methods and evaluation steps for R1.
Export INSM configuration settings, baseline records and sample detection events as evidence artifacts.
Provide action and escalation records that show how anomalies move into the CIP-008 incident response plan.
Train the named operators on the runbooks, evidence locations and review steps they will maintain.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Review baselines, detection rules and evidence sets as the network and the CIP standards change.
Ask any assessor, auditor or Regional Entity contact to confirm the evidence format and retention they expect.
Confirm the R1 enforcement dates for your Control Center or medium impact systems with NERC before planning.