Configuration baseline monitoring tools for CIP-010

Which configuration baseline monitoring tools cover CIP-010 in practice?

The registered entity must maintain CIP-010-4 R1 baselines for its applicable Cyber Assets and monitor for changes to them at least once every 35 calendar days under R2. No single tool satisfies CIP-010. The entity owns the baseline, the monitoring cadence and the investigation records for any unauthorized change, and it must be able to defend those records to the Compliance Enforcement Authority. Tools and any implementation partner produce the data and the evidence trail, but they do not make the entity compliant on their own. A partner can configure collection, document the procedure and test that alerts reach the people who investigate them, but the entity's CIP Senior Manager and operations staff still decide what counts as an authorized change.

Cost and effort depend mainly on how many Cyber Assets fall within scope and which impact categories they belong to under CIP-002, since high and medium impact BES Cyber Systems carry the most applicable requirements. A baseline that covers a few Windows hosts and Linux servers is a different job from one that covers embedded firmware, network devices and virtualized hosts across several sites. Ask any provider to price the work against a written list of asset classes, the collection method for each (agent, scanner or manual export), the retention period for monitoring logs, and who performs the quarterly or 35-day review. Agent deployment and tuning are usually one-time effort, while alert triage, baseline updates after approved changes and evidence sampling recur for as long as the systems run. No figure for these costs is supplied here, so confirm estimates with the vendor and in your own environment before committing budget.

In practice, a workable pattern combines three kinds of evidence. Wazuh file integrity monitoring and Syscollector inventory can record software, ports and services and alert on changes, and osquery file_events records can add host-level detail, although osquery needs a manager such as Fleet or a log pipeline for central reporting. OpenSCAP oscap results, produced against SCAP Security Guide profiles, show the configuration state at a point in time and help confirm hardening baselines, but they do not monitor for change between scans. Before selecting tools, confirm with each vendor that the license and edition in use covers the features you need, such as retention, alerting and reporting, and document how each tool maps to the baseline elements in Part 1.1.

How file integrity, inventory and SCAP tools each produce CIP-010 evidence

File integrity monitoring tools detect when a watched file or directory changes, which gives you the raw events behind the 35-day change monitoring in CIP-010-4 R2. Wazuh FIM stores a baseline of checksums and file attributes for monitored paths, then alerts when a user or process creates, modifies or deletes a monitored file, either on a schedule or in real time. Its alerts record how and when the file changed and who made the change. osquery takes a different route: its agent watches the paths listed under file_paths in its configuration and writes each change to the file_events table with the action, time and path, and computes MD5, SHA1 and SHA256 hashes where possible.

What it records: Wazuh FIM records checksums, attributes and change details for monitored files. osquery records action, time, path and hashes in file_events.
What it cannot show alone: File events do not show the approved baseline, the change ticket or whether the change was investigated.
License: Wazuh is GPL-2.0-only. osquery is licensed under Apache-2.0 OR GPL-2.0-only.
Component limits: osquery is an agent only. Central query scheduling, result storage and reporting across many hosts need a separate manager such as Fleet or a log pipeline.
Scope limits: Monitoring covers only the paths you configure, so the monitored set must match the baseline's software and firmware locations.

Before relying on either tool, confirm with the vendor how each handles your operating systems, retention of events and alert records, and whether your monitored paths match the baseline you documented.

SCAP scanning evaluates a system against a configuration profile and reports which rules pass or fail. OpenSCAP provides the oscap scanner, which evaluates a system against SCAP content written in XCCDF and OVAL, such as profiles from the SCAP Security Guide. Its results can be exported as HTML, ARF or XCCDF reports. For CIP-010, these reports help document the security configuration portion of a baseline and show drift from an approved profile, but they do not replace the baseline itself or the monitoring record.

What it records: A pass or fail result for each rule in the selected profile, saved as HTML, ARF or XCCDF output.
What it cannot show alone: A scan reflects only the rules in the profile you chose. It does not capture software versions outside those rules or detect changes between scans.
License: OpenSCAP is LGPL-2.1-or-later.
Component limits: oscap is a command-line scanner. Scheduling, storage across many systems and reporting need your own tooling or a separate manager.
Profile fit: Choose or tailor SCAP Security Guide profiles to your approved baseline, and record the profile version and any deviations.

Ask the implementation partner which profile was applied, how deviations are documented, and how each scan result is linked to the baseline record it supports.

How to detect and investigate an unauthorized change under R2

This sequence turns a monitoring alert into a documented decision: whether a change was authorized, how an unauthorized change was investigated and fixed, and whether the baseline now reflects the approved state. Each step leaves a record the auditor can sample against CIP-010-4 R2.

Confirm the monitoring interval is running
Before any alert is reviewed, the team confirms that the configuration monitoring tool is scanning each in-scope system at least once every 35 calendar days, as Part 2.1 requires. The owner of the monitoring tool checks the scan schedule, the last successful run per asset and any gaps. The output is a monitoring status record, such as a dated report from the tool showing each in-scope asset was checked within the window. A gap found here is itself a finding to document.
Receive and triage the change alert
The tool produces an alert when a monitored file, package, service, port or inventory item differs from the baseline. The security operations or CIP compliance analyst logs the alert in the ticketing or case system with the asset, the changed item, the time, and the user or process the tool recorded. Duplicate alerts from a single maintenance window are grouped under one record. The output is an alert case with a unique identifier that every later step references.
Match the change against authorized change records
The analyst compares the alert with approved change tickets for the same asset and time window. A change is classified as authorized when a ticket shows approval, a planned scope that covers the change, and a completed implementation by the expected party. Anything without a matching record is classified as a potential unauthorized change. The output is a classification entry on the alert case, naming the ticket reference or stating that no matching ticket exists.
Investigate the unauthorized change
For an unmatched change, the investigator determines what changed, who or what made it, how it was made, and whether it affects security controls or the software and ports listed in the baseline. Tool data such as file hashes, change times and process details, along with system and access logs, supports this work. Where a change is confirmed as unauthorized, the investigator also decides whether it is a Cyber Security Incident under CIP-008 and escalates accordingly. The output is a written investigation record with the evidence reviewed and the conclusion reached.
Document the finding and remediation
The team records the remediation step taken, such as reverting the file, removing the unapproved software, closing the port or re-imaging the asset, along with the person who approved it and the date it was verified. The verification step confirms the asset now matches the approved baseline. The output is a remediation record linked to the alert case, including the verification scan result. If the change was not fixed within the entity's own process, the record shows the reason and the follow-up owner.
Update the baseline for authorized changes
When the change was authorized, the baseline is updated so the approved configuration is the new reference. The change owner submits the updated baseline details (operating system or firmware version, installed software with version, ports and security patches as Part 1.1 lists them), and a reviewer confirms the update matches the approved ticket. The output is a versioned baseline record with its date and approver, which shows that the baseline was maintained and not left stale.
Close the case and retain the record set
The analyst reviews the complete case, confirming that each alert has a classification, the investigation and remediation records are attached, and the baseline is current where needed. The case is then closed and retained with the monitoring logs for the period the entity's records program requires. The output is a closed case package that an auditor can sample end to end, starting from the monitoring log and ending at the approved baseline or documented remediation.

What makes CIP-010 monitoring more costly or slower to evidence

Most of the effort in CIP-010 monitoring comes from scope and inconsistency, not from the tools themselves. The drivers below determine how many baselines exist, how many monitored sources feed them, and how easily a detected change can be traced to an authorized ticket.

Number of Cyber Assets and impact category

Every in-scope Cyber Asset needs a baseline, a monitoring source, and an investigation trail, so the count of high, medium and low impact assets sets the workload more than any product choice. Review the CIP-002 categorization first and confirm which assets sit under CIP-010 Applicable Systems. Ask for pricing or licensing by endpoint count, and check whether the tool can group assets into baselines by configuration so one record covers many identical devices.

Heterogeneous operating systems and firmware

Baselines must name the operating system or firmware with its version, so a mixed estate of Windows, Linux, network appliances and embedded controllers needs a separate collection method for each. Agent-based tools may not run on firmware-only devices, which pushes those assets toward manual or vendor-specific evidence. Test collection on one device from each family before committing to a rollout, and document which assets rely on a manual process.

Virtualized assets under the 2028 standards

Virtualization changes how baselines are defined, because hypervisors, guest images and templates can each carry configuration. CIP-010-5 is listed as effective 1 July 2028 under Order No. 919, so plan for virtual assets now but confirm the current requirement version that applies today. Ask whether the tool can monitor guest images and hypervisor hosts separately and whether it can record image-level baselines that link to the template used to build each guest.

Air-gapped and remote sites

Sites without continuous network connectivity cannot stream change data to a central manager in real time, which affects how the 35-day monitoring cycle is evidenced. Local collectors, scheduled exports and offline evidence packages add handling steps and delay review. Confirm how often each remote site must be polled, how logs are carried out of the site, and who signs off on imports. Document the transfer procedure so an auditor can trace a change from the site to the central record.

Quality of existing change tickets

Monitoring can only confirm that a change happened. Whether it was authorized depends on change tickets that name the asset, the change, the approver and the date. When tickets are vague or created after the fact, each detected change becomes an investigation, which is the costly part of CIP-010 R2. Before deploying tools, sample recent changes and check that each one maps to a ticket. Ask the tool vendor or integrator whether alerts can reference the ticket number automatically.

Retention of monitoring logs

Monitoring records, baseline versions and investigation notes must remain available for the audit period, so storage grows with asset count and polling frequency. Short default retention in a monitoring platform can remove evidence before an assessment. Decide the retention period with your compliance lead, set it in the platform configuration, and test restoring an archived record. Ask the vendor how logs are protected from modification, since an auditor will ask whether the evidence itself can be trusted.

Who is paid for what in a CIP-010 monitoring project

This table splits a CIP-010 baseline monitoring project into its cost components, showing who pays for each, whether it is one-time or recurring, and what moves it up or down. Use it to build a written quote request that compares like with like, since open-source tools shift cost from licenses to labor and retained support.

Cost component	Who is paid or who bears it	One-time or recurring	What drives it up or down
Internal engineering time	The registered entity's own staff, including OT, IT and CIP compliance roles	Both: initial baseline build is one-time, monitoring triage and evidence review recur	Number of BES Cyber Systems in scope, number of vendor-specific baselines, and how many alerts need investigation
Open-source tool licenses	No license fee for the GPL-2.0-only, Apache-2.0 OR GPL-2.0-only and LGPL-2.1-or-later tools named in this topic; confirm the edition and license terms before deployment	Recurring only where paid support, subscriptions or hosted editions are chosen	Whether the entity runs community editions alone or buys a supported distribution, and any edition limits on features needed for evidence
Implementation partner fixed-scope work	Outside firm paid under a written scope for design, deployment, baseline capture and documentation	One-time	Number of Cyber Asset types, integration with existing change management, and whether the partner also writes the evidence procedure
Managed monitoring or retainer support	Outside firm paid on a recurring basis for tuning, upgrades, alert review or ticket support	Recurring	Alert volume, hours of coverage, and whether the entity wants the provider to investigate or only to supply logs
Hardware and hosting for the monitoring manager	Entity pays its cloud, data center or on-premises provider; confirm whether the manager sits inside the ESP or in a compliant location	Both: setup is one-time, storage and compute recur	Endpoint count, log retention needed to cover the audit period, and whether BCSI-bearing data is stored off-premise
Independent Compliance Audit costs	The entity pays its own internal audit preparation; the Regional Entity or NERC conducts the audit at no fee to the entity	Recurring on the audit cycle set by the Regional Entity	Audit schedule under Section 403.10.1 or the risk-based schedule, size of the evidence package, and how well baselines and investigation records are already organized

What must be in place before a CIP audit reviews configuration evidence

An auditor reviewing CIP-010 configuration evidence will look for a documented baseline, a working monitoring cycle, alerts that have been tested, and records that connect each detected change to an approved decision. Each card below is one item the organization should confirm, with a dry-run evidence pull as the check.

Documented baselines for each Applicable System

CIP-010-4 R1 Part 1.1 expects a baseline per system or per group, listing the operating system or firmware with version, intentionally installed software with version, custom software, logical network accessible ports and security patches applied. Before the audit, confirm every high and medium impact BES Cyber System, and each associated EACMS, PACS and PCA in scope, has a baseline that matches what the tool actually sees. For the dry run, pick one system at random and compare its baseline record with a fresh Syscollector or inventory export from the same host.

Monitoring interval shorter than 35 days

CIP-010-4 R2 Part 2.1 requires monitoring for baseline changes at least once every 35 calendar days. Set the configured schedule for file integrity and inventory checks to a clearly shorter interval, and document that interval in the program so the reviewer does not have to infer it. For the dry run, pull the scan or check timestamps for the last several cycles and confirm no gap approaches 35 days, including gaps caused by agent outages or maintenance windows.

Tested alerting for unauthorized changes

A monitoring schedule only produces evidence if a detected change reaches a person who can act on it. Test the path end to end: make a controlled change to a monitored file or package in a non-production copy, confirm the alert fires, and confirm it lands in the queue or log the operations team reviews. Keep the test record with the date, the change made and the alert received. Confirm which tool generates the alert and who is on the notification list.

Change ticket linkage for detected changes

Every detected change should be traceable to an approved change request or to a documented determination that it was unauthorized. Confirm the monitoring output carries the host, the time, the path or package and the actor where the tool records it, and that your ticketing system uses the same host identifier. For the dry run, select three changes from the period, find the matching tickets or approvals, and confirm each one closes the loop. Changes with no ticket are the first items to investigate.

Sample investigation record

CIP-010-4 R2 expects documentation of how each detected unauthorized change was investigated, and an auditor will ask to see a sample. Prepare at least one complete record showing the alert, the reviewer, the findings, the determination, the corrective action and any baseline update. Identify who owns each step and confirm the record can be retrieved without the original analyst. For the dry run, ask a team member who was not involved to produce the record from the case system alone.

Owner for the control and its evidence

Name one accountable owner for the baseline program and one for alert review, and confirm both can explain the process to an assessor. Record who approves baseline changes and who may update the baseline after an approved change. Any implementation partner can prepare the tooling and runbooks, but the organization owns the control and its results. For the dry run, ask each named owner to walk through one example from start to finish without preparation.

Who owns the controls, who prepares the evidence and who assesses it

The registered entity owns its CIP-010 controls. The baseline configurations, the 35-day monitoring cycle, the investigation of unauthorized changes and the decision on what counts as an authorized change all sit with the entity's own staff, and accountability for the program sits with the CIP Senior Manager named under CIP-003. A monitoring tool does not change that. If Wazuh, osquery or OpenSCAP is deployed, the entity still decides which hosts are in scope, which file_paths are watched, who receives alerts and who signs off the investigation records. Before any work starts, confirm in writing who inside the organization approves baseline changes and who is named as the CIP Senior Manager for these systems.

An implementation partner such as DeployOpen can plan the monitoring design, configure and harden the tools inside the entity's own environment, document the procedures and prepare the evidence the entity will show. In practice that means mapping each Applicable System to its baseline elements, setting up scheduled checks that run within the 35-calendar-day window, testing that an unauthorized change produces an alert, and keeping the records of how alerts were handled. The partner works under a written scope and does not take on the entity's decisions, its baseline approvals or its operation of the systems. Ask for the deliverables list and the operating handover in the scope before signing.

Only the Compliance Enforcement Authority assesses compliance. That is the Regional Entity or NERC, which carries out Compliance Audits, Spot Checks, Self-Certifications and investigations under the NERC Rules of Procedure. No implementation partner, consultant or tool vendor issues a report, attestation or certificate for CIP-010, and there is no CIP certificate to obtain. The question for the entity is whether its evidence will hold up when the auditor asks to see baselines, monitoring logs and investigation records for the audit period. Review the NERC CIP standards page for the current status of CIP-010-4 and confirm the audit approach with the Regional Entity.

Common questions about CIP-010 monitoring tools and outside help

Are open-source tools enough to meet CIP-010 baseline monitoring?

Open-source tools can produce much of the baseline and monitoring evidence, but they cannot define the baseline the standard requires. CIP-010-4 R1 Part 1.1 expects a baseline that records the operating system or firmware with version, intentionally installed application software with version, custom software, logical network accessible ports and security patches applied. Wazuh file integrity monitoring and the Syscollector inventory can capture many of these elements, osquery records file changes as an agent, and OpenSCAP checks configuration against SCAP content. Gaps remain. osquery needs a separate manager for central reporting, and some embedded or vendor-managed devices may not run an agent at all. Confirm coverage for each device type in scope. Your entity still owns the baseline, the change records and the investigation of unauthorized changes.

How much internal effort does CIP-010 baseline monitoring take?

Effort is driven by the size and variety of the environment, not by a single published figure. The main drivers are the number of in-scope Cyber Assets, the mix of Windows, Linux, network and firmware-based devices, how many baseline groups you maintain, how many change-approval workflows feed the baseline, and how much tuning the alerts need before they are useful. Initial setup is one-time work: agent deployment, baseline capture, file path lists and alert routing. Recurring work is reviewing monitoring output within each 35-day cycle, investigating detected changes, updating baselines after approved changes and keeping tool versions current. No supplied figure covers hours, so ask for a written breakdown of setup and recurring tasks in any scope you receive.

Do we need an outside partner to set up CIP-010 monitoring?

Nothing in CIP-010 requires an outside partner, so the decision depends on your team's capacity and experience. A partner is most useful when staff lack time, lack experience with the operating systems in scope, or have not produced CIP evidence before, or when the deployment spans many sites. DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure, and it prepares systems and evidence for compliance assessments. DeployOpen does not issue audit reports or certifications, and compliance determinations come from the Compliance Enforcement Authority. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and a quote follows from that written scope.

How often will an auditor test our 35-day configuration monitoring?

Auditors test it during a compliance monitoring engagement, and the timing is set by the Compliance Enforcement Authority rather than by you. Under the NERC Rules of Procedure, entities registered as Balancing Authorities, Reliability Coordinators or Transmission Operators receive a Compliance Audit at least once every three years. Other registered entities are audited on a risk-based schedule set by the Regional Entity. Spot Checks, Self-Certifications, Self-Reports, periodic data submittals and complaints can also bring monitoring records into review at any time. Because the 35-day monitoring recurs throughout the period, an auditor will typically expect records for every cycle in the audit period, not only the most recent one. Confirm the audit period and retention expectations with your Regional Entity.

What evidence should we keep for CIP-010 R2 monitoring?

Keep records that show monitoring ran at least once every 35 calendar days and that every detected change was investigated. The core set includes:

Monitoring logs for each in-scope system, with dates that show each 35-day cycle
Baseline records under CIP-010-4 R1 Part 1.1, with software and firmware versions and the date each baseline was captured
Change records for each detected change, including the investigation, the conclusion and any follow-up
Change tickets that link approved changes to the baseline updates they caused
Tool configuration, including file_paths lists, scan schedules and alert rules
Version records and access logs for the monitoring platform

Wazuh alerts record how and when a file changed and who changed it, and osquery file_events record the action, time, path and available hashes. Confirm retention periods with your Regional Entity and internal records policy.

Can our own engineers run CIP-010 monitoring without outside help?

Yes, if the team has the skills and time to run the program every cycle. Internal staff can deploy Wazuh, osquery or OpenSCAP, define baselines, write the investigation procedure and keep the evidence organized. Before deciding, check whether engineers know the operating systems on in-scope assets, whether someone owns the review and investigation of alerts outside normal change windows, whether change management feeds the baseline reliably and whether the team can keep the tools patched. Licensing also matters. Wazuh is licensed under GPL-2.0-only and osquery is available under Apache-2.0 OR GPL-2.0-only, so confirm the terms that apply to your deployment and any edition limits with each vendor. Plan for a separate manager if you use osquery across many hosts.

How DeployOpen scopes and implements CIP-010 monitoring

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source monitoring for CIP-010 baselines inside the client's own infrastructure, whether that is their cloud accounts, data centers or air-gapped networks. Work starts from a written, fixed scope that names the BES Cyber Systems, Protected Cyber Assets and associated EACMS and PACS in the monitoring boundary, the baseline attributes to be captured for each asset group, the file paths and inventory fields to be watched, the alert destinations, and the 35-day review cadence the client's procedures will follow. Deliverables and timelines are agreed in writing before any configuration changes are made to production systems.

The handover is the set of artifacts the client's compliance team and auditors will use: the deployed configuration for the file integrity, inventory and SCAP scanning components, the baseline definitions tied to each Applicable System group, runbooks for detecting, documenting and investigating unauthorized changes, and the evidence procedures that show how monitoring logs and investigation records are exported and retained. Ask for a list of every artifact in the quote, a named owner for each one on the client side, and a statement of which components are in scope for support after handover. Confirm with the client's own CIP program owner that the procedures match the approved cyber security plan before the work is accepted.

DeployOpen does not issue audit reports, attestations or certifications, and it does not guarantee an audit result. The registered entity remains responsible for its CIP-010 compliance, for the accuracy of its baselines and for the decisions made in investigations. Independent evaluation is performed by the Compliance Enforcement Authority, which monitors compliance through audits, spot checks and self-certifications. Before engaging, ask any implementation partner to state in writing which tasks they perform, which decisions stay with the registered entity, and how the evidence will be reviewed by the entity's own staff.