CIP-010-4 R2 configuration monitoring: scope and evidence

What CIP-010-4 R2 configuration monitoring asks for and why auditors check it

CIP-010-4 R2 requires you to monitor high impact BES Cyber Systems at least once every 35 calendar days for changes to the baseline configuration, and to document and investigate any unauthorized change you detect. If you are preparing for a first or repeat audit, that is the test an assessor will apply. R2 sits on top of the baseline set in R1. The baseline records what a system is supposed to look like, and R2 checks that the live system still matches it. The requirement applies to high impact BES Cyber Systems and their associated Electronic Access Control or Monitoring Systems (EACMS) and Protected Cyber Assets (PCA). Without monitoring, a baseline is only a document. Configuration drift accumulates through patches, vendor work, emergency fixes and quiet edits, and nobody learns about it until something fails or an auditor asks.

The penalty ceiling is worth stating plainly. NERC's Sanction Guidelines reference a maximum civil penalty of $1,584,648 per violation, per day, as adjusted by FERC Order No. 906 and shown in 18 CFR 385.1602(d). That figure is a statutory maximum, not an expected outcome. Actual penalties depend on factors such as the violation's duration and severity, the entity's compliance history and its self-reporting and mitigation. Confirm the current figure against the eCFR before you cite it internally, because the adjusted amount is updated over time.

Three things usually make R2 hard in practice. The first is scoping: you must know exactly which devices sit inside the high impact boundary, including EACMS and PCA, and keep that inventory current as systems change. The second is noise: collecting configuration changes is easy, but separating authorized changes that match a change ticket from genuinely unauthorized ones takes tuning and a clear record of what was approved. The third is proof of investigation. Auditors look for records showing that each detected unauthorized change was reviewed, the outcome was documented, and follow-up was completed, so confirm with your Regional Entity which evidence formats it expects before your first monitoring cycle.

Which systems and teams fall inside CIP-010-4 R2 monitoring

CIP-010-4 R2 applies to a narrower set of systems than many teams assume. The scope starts with high impact BES Cyber Systems identified under CIP-002-5.1a, extends to their associated EACMS and PCA, and depends on several boundary decisions that shape how monitoring is designed and who runs it.

High impact BES Cyber Systems

R2 starts with the high impact classification. CIP-002-5.1a sorts BES Cyber Systems into high, medium and low impact using its bright-line criteria. High impact systems are mainly found at Control Centers of Reliability Coordinators and qualifying Balancing Authority, Transmission Operator and Generator Operator Control Centers. Confirm the categorization record is current, since a change in CIP-002 outcome changes which baselines must be monitored every 35 calendar days.

Associated EACMS and PCA

R2 reaches beyond the BES Cyber Systems themselves to their associated Electronic Access Control or Monitoring Systems and Protected Cyber Assets. Access control servers, jump hosts and the monitoring tools that feed the perimeter often fall here. Map each high impact system to its associated EACMS and PCA in writing, because an unmapped device that is quietly left out of the monitoring scope is a common finding in reviews.

Control Center versus plant or substation

A system at a Control Center is usually easy to name as high impact. A system at a generation or transmission site is more often a medium or low impact asset, so R2 may not reach it at all. Teams should ask which site a device sits at, what impact rating the site was given, and whether any device at a generation or transmission facility was rated high under the bright-line criteria before they design monitoring for that location.

Operations technology and network owners

Operations technology engineers own the baselines of control system hosts, while network teams own the switches, firewalls and routers that sit in the Electronic Security Perimeter. Both groups change configuration, so the monitoring design must capture changes from each. Agree in writing who receives detected changes, who investigates them and who documents the outcome.

Identity and vendors with remote access

Accounts used by vendors and integrators to reach high impact systems can alter configurations without touching the console. Changes made through remote sessions, service accounts or vendor-managed tools must still appear in configuration monitoring. Ask each vendor which systems it can change, and confirm that its activity is logged and reviewed within the same monitoring cycle.

Medium and low impact boundaries

Do not assume R2 covers medium or low impact systems. Medium impact systems are governed by other parts of CIP-010 and by standards such as CIP-005 and CIP-007, while low impact systems fall under CIP-003. A monitoring tool that watches a medium impact device may satisfy a different requirement, but it does not by itself show R2 compliance. Document which requirement each monitored asset is in scope for.

How an assessor tests 35-day configuration monitoring

This table compares what a Regional Entity auditor samples, checks and asks for when testing R2 Part 2.1, and where entities commonly fall short. Read each row as a test step with its evidence and the gap that usually produces a finding. Compliance is monitored through Compliance Audits, Spot Checks and Self-Reports, and no certificate is issued.

Test area	What the assessor does and expects	Common findings
High impact population	Confirms the list of high impact BES Cyber Systems and their associated EACMS and PCA from the CIP-002 categorization, then samples assets from that list and checks each one appears in the monitoring scope.	Associated EACMS or PCA left out of the monitored population, or assets added after categorization that were never onboarded.
Monitoring frequency	Reviews monitoring logs or tool reports across the audit period and checks that consecutive monitoring events are no more than 35 calendar days apart for each sampled system.	Gaps longer than 35 calendar days, often caused by collector outages, expired credentials or tools that stopped reporting without an alert.
Baseline comparison	Checks that the baseline the monitoring compares against is the one authorized and documented under R1, and that the baseline version matches the approved change record.	Monitoring compares against a default or outdated template, or the baseline was updated without a matching R1 change record.
Detected changes	Selects detected configuration changes from the logs and asks whether each one was an authorized change or an unauthorized change.	Changes flagged by the tool but never classified as authorized or unauthorized.
Investigation records	Traces each detected unauthorized change to a dated investigation record showing what was reviewed, who investigated and what action followed.	Detected unauthorized changes with no investigation record, or records that stop at the alert without a conclusion.
Evidence retention	Requests the monitoring logs, tool configuration, the baseline in use and the investigation records for the full audit period, and checks they are retrievable on request.	Logs rotated or overwritten before the audit period ends, or evidence that exists only in a tool's dashboard with no export.
Compliance monitoring route	Confirms the entity's evidence package is complete for the Compliance Audit, Spot Check or Self-Report that triggered the review, with the Compliance Enforcement Authority deciding findings. No certificate is issued.	Entities assume a passing tool report or a vendor statement stands in for their own evidence of monitoring and investigation.

How to set up 35-day configuration monitoring step by step

This sequence takes a high impact BES Cyber System from an unverified inventory to a working configuration monitor that alerts on baseline deviations, triages them, and records each investigation. Each step ends with an artifact the team can hand to an auditor.

Confirm the in-scope asset population
Start from the CIP-002 categorization and list every high impact BES Cyber System, along with its associated Electronic Access Control or Monitoring Systems (EACMS) and Protected Cyber Assets (PCA). The CIP-002 owner or compliance lead signs off on the list, and the operations team confirms it against the asset inventory. The step is done when each system has a unique identifier, a stated role, and a named owner, and the list matches the current categorization. Keep the list dated so it can show the population in effect during the audit period.
Pull the approved baseline for each asset
For each asset on the population list, retrieve the baseline configuration approved under CIP-010-4 R1, including its operating system, installed software, ports and services, and security controls. Confirm that the baseline is the approved version and that any changes since approval went through the change process. The output is a baseline reference sheet that links each asset to its approved baseline record. Gaps found here, such as assets with no baseline, should be treated as findings before monitoring starts.
Select a monitoring method that meets the 35-day interval
Choose one or more tools that can compare the live configuration of each asset against its baseline at least once every 35 calendar days. Options include agent-based file integrity monitoring, configuration assessment against policy files, and endpoint query tools. Confirm with the vendor or project that the tool can run on each asset class, that it can be tuned to the baseline items, and that it keeps its own logs. Where the tool cannot reach a device, document a compensating method. The output is a short method statement that names the tool, the check frequency, and the coverage per asset.
Configure the monitoring rules and schedule
Translate each baseline item into a monitoring rule, such as watched file paths, configuration keys, installed package lists, or running process checks. Set the schedule so every asset is checked at an interval shorter than 35 calendar days, and enable logging of each run with its timestamp and result. The engineer who builds the rules and a second reviewer should compare the rules to the baseline reference sheet. The step closes with exported configuration files and a schedule screenshot or log that proves the interval.
Define alert routing and the triage workflow
Decide who receives alerts, how quickly they are reviewed, and how each detected change is classified as authorized, unauthorized, or undetermined. Link each authorized change to an approved change ticket from the CIP-010 change management process. The operations or security lead approves the workflow, and the team tests alert delivery to the responsible roles. The output is a triage runbook with decision points and escalation paths, so that every detected change has a documented disposition.
Write the investigation procedure and record format
Document how an investigator confirms a detected unauthorized change, determines its scope, decides on containment and restoration, and closes the record. Define a standard record format that captures the asset, the baseline item, the detected value, the time of detection, the investigator, the findings, and the corrective action. The compliance lead reviews the procedure against the requirement to document and investigate unauthorized changes. The output is a template and a completed example record, marked as illustrative.
Run a test cycle with a deliberate change
On a non-production or approved test asset, make a controlled change to a monitored baseline item, such as a watched configuration file, and confirm that the monitor detects it within the configured schedule. Follow the triage runbook, create the investigation record, and restore the baseline through the change process. Save the monitoring log, the alert, the ticket, and the completed record together. The step is complete when the test shows detection, routing, and documentation working end to end, and the results are filed as evidence for the audit period.

Which open-source tools can produce configuration monitoring evidence

Four open-source tools can detect or record changes to system configuration and files, which is the raw material for CIP-010-4 R2 evidence. Each produces different records, so the choice depends on what the auditor will ask to see. None of them satisfies R2 alone, because the entity still owns the baseline, the 35-day cadence and the investigation record.

Wazuh security configuration assessment

Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies that check files, directories, registry keys and running processes, and it recommends remediation for each failed check. Most shipped policies draw on CIS benchmarks, and custom policies can encode your own baseline items. Confirm that scan results are retained long enough to show a 35-day monitoring cycle, and that the policy checks match the baseline recorded under R1. The product is licensed under GPL-2.0-only, so confirm how that license applies if you modify or redistribute it.

Fleet policies for device compliance

Fleet policies are yes or no questions asked of devices as osquery queries, and the policies page shows which devices in each fleet pass or fail each one. This gives a per-device record that a baseline item is present, such as a required setting or an installed agent. Check that the policy frequency and stored results let you show evidence at least once every 35 calendar days for each high impact system. Fleet is MIT licensed, but confirm which edition and support terms your deployment uses before you rely on it for audit records.

osquery file integrity monitoring

osquery watches the files and directories listed under file_paths in its configuration and writes each change to the file_events table with the action, time and path. Where possible it also calculates MD5, SHA1 and SHA256 hashes of changed files, which helps show what changed and when. Confirm that the watched paths cover the baseline items you documented under R1, and that the event records are exported and retained for audit. Its license is Apache-2.0 OR GPL-2.0-only, so pick the license option that fits your distribution model and document the choice.

Bareos verify jobs

Bareos Verify jobs compare files on a system against attributes cataloged during an earlier backup, which gives a Tripwire-like check for unexpected changes. This is a backup tool feature, so it fits best as a secondary check for files that rarely change, not as a real-time monitor. Confirm that the verify schedule is frequent enough to meet the 35-day cadence for the systems in scope, and that the cataloged baseline matches the one approved under R1. Bareos is licensed under AGPL-3.0-only, and network use of a modified version can trigger source obligations, so review that with counsel before deployment.

Evidence that passes an R2 configuration monitoring review

An auditor reviewing R2 tests whether monitoring actually happened on schedule, covered the right assets, compared against a defined baseline, and produced a documented response to every change. The cards below cover the artifacts that together show each of those points, and how to keep them current between audits.

Monitoring logs for each 35-day window

System logs or reports showing that every in scope asset was checked within each 35 calendar day window across the audit period. Auditors look for gaps, so a single missed cycle on one asset is the finding most likely to be written up. Check that timestamps are retained for every window, not only the most recent one, and that the export covers the full period the Regional Entity will request.

Monitored asset list matched to CIP-002

A list of every monitored asset, mapped to its BES Cyber System, its impact rating and its role as high impact BES Cyber System, associated EACMS or PCA. The list must match the current CIP-002 categorization. A mismatch, such as a monitored host that is not in the categorization or a categorized EACMS that no tool watches, is a common reason an audit scope gets questioned.

Baseline reference used for each comparison

The baseline configuration each monitoring comparison used, with its version and approval date. Show that the monitoring tool compared against the documented baseline and not against a snapshot taken after an unreviewed change. Keep baseline files under version control so you can prove which baseline was active on any given date.

Records of detected unauthorized changes

Alerts or change records that carry the timestamp, asset, changed attribute and the hash or value before and after the change. These records prove that detection worked. Confirm that the tool flags deviations from the baseline and that alerts are not silently suppressed, because a clean log with no detections can look the same as a monitor that never ran.

Investigation notes and corrective action

For each detected change, a written investigation showing who reviewed it, what was found, whether the change was authorized under the CIP-010 change process, and what corrective action followed. The conclusion matters as much as the detection. Link each note to the ticket or change request so the reviewer can trace it from alert to resolution without asking for more material.

Monitoring and investigation procedure

The documented procedure that defines how monitoring runs, who reviews the output, how often, how baselines are updated, and how unauthorized changes are escalated. Auditors compare actual records against this document, so it should describe the process as operated. Review it at least once a year and record each revision with its approval.

What meeting CIP-010-4 R2 costs in money and effort

This table lists each cost component of CIP-010-4 R2 configuration monitoring, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. No supplied figures exist for these costs, so use the table to structure a written, scope-based quote and compare line items across bids.

Cost component	One-time or recurring, and who is paid	Cost drivers	How to keep it down
Tooling or licenses	Recurring for commercial monitoring subscriptions. One-time for setup if the tool is bought outright. Paid to the software vendor or reseller.	Number of high impact BES Cyber Systems and associated EACMS and PCA, number of monitored endpoints, and whether the vendor prices per device or per platform.	Self-hosted open-source tools such as Wazuh, Fleet, osquery or Bareos can remove license spend, but staff time to deploy, tune and maintain them still counts as a cost.
Engineering time to configure monitoring and baselines	One-time for initial setup, with periodic recurring updates. Paid to internal staff or an implementation partner under a fixed-scope agreement.	Number of baseline configuration items, number of platform types, and how many baselines must be documented per Cyber Asset.	Reuse standard baseline templates across like-kind systems, and confirm in writing which baseline items the partner will build versus which the entity must verify itself.
Alert triage and investigation time	Recurring. Paid as internal staff time or through a managed service retainer.	Change volume on monitored systems, false positive rate from policy tuning, and how many changes fall outside documented change tickets.	Tie detected changes to change management records so routine approved changes can be closed quickly, and tune monitoring rules before go-live.
Evidence upkeep across the audit period	Recurring across the audit period. Paid as internal compliance staff time, often with support from an implementation partner.	Length of the audit period, number of monitoring logs retained, and how many investigation records must be produced on request.	Set up automated log retention and a consistent investigation record template from the start, so evidence does not need to be rebuilt before an audit.
External testing or review	Periodic or one-time for each review. Paid to an independent assessor or security testing firm, separate from the auditor's own fees.	Scope of configuration checks reviewed, number of platforms tested, and whether the reviewer must validate tool output or only the process.	Ask for review scope in writing, and prepare evidence in advance so reviewers spend less time reconstructing records.
Auditor sampling effort on the entity side	Recurring at each Compliance Audit or Spot Check. Entity staff time to respond, retrieve samples and explain findings.	Number of high impact assets sampled, how easily logs can be filtered by asset and date, and how well investigation records link to their alerts.	Keep logs searchable by asset and date, and maintain a single index that maps each sampled change to its investigation record.
Managed or vendor-hosted components	Recurring. Paid to the managed service provider or cloud provider under contract terms.	Share of the monitoring stack that is vendor managed, data residency needs, and contract terms on log export and retention.	Confirm in the contract how logs can be exported for audit, and check that a self-hosted option is viable within the entity's own infrastructure.

Who owns each part of R2 monitoring and what can be outsourced

The registered entity owns CIP-010-4 R2 from start to finish. The standard places the obligation on the entity, so the entity decides what the baseline contains, which changes are authorized, and how each detected deviation is resolved. No vendor or partner can accept that responsibility on the entity's behalf.

Baseline ownership: The entity approves the baseline configuration for each high impact BES Cyber System and its associated EACMS and PCA, and approves every update to it.
Authorized change decisions: Operations and security staff decide whether a detected change matches an approved change record or is unauthorized.
Investigation outcomes: The entity documents the investigation of each unauthorized change, records the root cause and decides on containment, rollback or further action.
Compliance record: The entity's CIP Senior Manager or delegate reviews and signs off the compliance record that shows how monitoring ran.
Staffing and alert handling: The entity assigns named people to review alerts within its own procedures.

Confirm with your compliance lead which named role signs each record, and confirm that your change tickets link to the monitoring output you will show an auditor.

Questions buyers ask about CIP-010-4 R2 monitoring cost, effort and outside help

Can our team meet CIP-010-4 R2 with in-house staff alone?

Yes, many registered entities run R2 internally, and nothing in the standard requires an outside firm. The work is recurring: you must monitor high impact BES Cyber Systems and their associated EACMS and PCA at least once every 35 calendar days, document detected changes to the baseline, and investigate unauthorized ones. Confirm that you have named owners for each step, backup coverage for the 35-day cycle, and enough analyst time to triage alerts. An outside partner can help with setup and evidence, but the organization keeps ownership of the controls.

What drives the effort of CIP-010-4 R2 monitoring?

Effort rises with the number of in-scope Cyber Assets, how many baselines must be maintained, how many platforms and operating system types you run, and how much change noise each system produces. The number of changes that need investigation matters more than the number of systems, because every detected unauthorized change requires documented follow-up. Plan for the cost of keeping baselines current after approved changes, since a stale baseline creates false alerts. Ask any provider to break its estimate down by these drivers.

Are open-source tools enough to meet R2?

Open-source tools can produce much of the monitoring and evidence R2 asks for, but they do not decide compliance on their own. Wazuh's Security Configuration Assessment checks endpoints against YAML policies, osquery's file integrity monitoring records changes to listed paths with hashes, and Bareos Verify jobs compare files against cataloged attributes. Each tool has its own license and edition limits, so confirm that the features you need are included in the version you deploy. You must still define the baseline, the monitoring scope and the investigation process.

What does R2 require from our organization before setup starts?

Before setup, you need an accurate list of high impact BES Cyber Systems and their associated EACMS and PCA, along with the approved baseline configuration for each. You also need change approval records, so monitored changes can be matched against authorized work. Staff time is needed for triage of alerts and for investigating unauthorized changes, which should be scheduled before go-live. Confirm who owns each input, because gaps in asset lists are the most common reason monitoring evidence fails to cover the intended scope.

How long does R2 monitoring setup take?

The timeline depends on the number of in-scope systems, how complete your baselines already are, whether the monitoring platform is already deployed, and how quickly approved changes can be reviewed. Testing in a non-production environment and resolving access or network constraints in your own infrastructure also add time. Ask a provider for a timeline tied to a written scope, with the dependencies you own listed separately. Because DeployOpen works in the client's own infrastructure, the schedule also depends on your change windows and approval processes.

What will an auditor ask to see for R2?

An auditor will typically ask for the list of in-scope high impact systems, the approved baselines, and logs from the system that monitors configuration across the audit period. They will also review records showing that monitoring occurred at least every 35 calendar days and that detected unauthorized changes were documented and investigated. Expect requests to match alerts to change tickets and to see who reviewed each one. The Regional Entity, not your consultant, decides whether the evidence is sufficient, so test the evidence set against the standard before an audit. Our NERC CIP audit preparation guide lists the wider audit process.

What should a written scope contain before a partner quotes R2 work?

A written scope should name the in-scope systems by identifier, the monitoring tools and versions, and the baseline items to be tracked. It should state the monitoring cadence, the evidence to be produced, and how investigation records will be kept. List the client-owned inputs, such as asset lists, approved baselines, change records and staff for triage, and the acceptance criteria for each deliverable. Also state what the partner will not do, including that it does not issue audit reports or certifications. Most DeployOpen engagements are fixed-scope and agreed in writing before work starts, and quotes follow from that written scope.

How DeployOpen scopes and prepares CIP-010-4 R2 monitoring evidence

DeployOpen prepares the configuration monitoring systems and evidence that support CIP-010-4 R2 Part 2.1 inside your own infrastructure. The entity keeps ownership of its baselines, its high impact classification and its compliance decisions, while DeployOpen plans, builds, documents and hands over the open-source tooling that produces the monitoring records.

How we scope

Confirm which high impact BES Cyber Systems and associated EACMS and PCA fall inside the written scope.
Record the baseline configuration sources and the 35-day monitoring interval each in-scope system must meet.
Agree in writing which platforms, networks and cloud accounts DeployOpen will touch before work starts.

How we build

Deploy the chosen open-source monitoring tools inside your own accounts, data centers or air-gapped networks.
Configure checks for baseline drift, such as file integrity and security configuration assessments, against the agreed baselines.
Test alert routing and confirm that detected unauthorized changes are logged and reach the investigation queue.

How we hand over

Deliver configuration documentation covering each monitored system, its baseline, its check frequency and its log retention.
Provide a runbook for investigating and documenting detected unauthorized changes, with sample records for your auditor to review.
Map each deliverable to the CIP-010-4 R2 measure it supports, and state what your own staff must still perform.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing of the monitoring stack are available as a retainer.
Confirm with your Compliance Enforcement Authority which evidence format and retention period it expects before the engagement closes.