CIP-010-4 R1 configuration change management

What CIP-010-4 R1 asks for and why configuration changes get audited

If you operate high or medium impact BES Cyber Systems, an auditor will expect you to show control over every change to their configuration before an audit begins. CIP-010-4 Requirement R1 asks for a documented baseline configuration that lists five required items, authorized and documented records of any deviation from that baseline, and a baseline update within 30 calendar days of completing a change. For each baseline change, you must determine which CIP-005 and CIP-007 security controls could be affected before the change and confirm afterward that they were not adversely affected. For high impact systems, where technically feasible, changes must also be tested in a test or suitable production environment and the results documented before production implementation. Before a baseline change to operating systems, firmware, application software or security patches, you must also verify the software source and its integrity where the source makes a method available.

The risk behind these parts is quiet erosion. A patch that disables a logging agent, a new service that opens an unneeded logical port, or a firmware update installed from an unverified source can weaken the electronic security perimeter and the controls around it without anyone noticing. The baseline is what lets you detect that drift and prove that every deviation was intentional. Without it, an organization cannot show what the system was supposed to look like, and an assessor will treat undocumented change as a control failure rather than a paperwork gap.

Compliance usually breaks down in three places. First, baselines were never built for many assets, or were built once and never reconciled with the live system, so the five required items are missing or stale. Second, change tickets do not tie back to the baseline, so you cannot show which deviations were authorized, what was updated and when. Third, software sources and hashes are hard to verify across vendors, open-source packages and manually delivered patches. Start by confirming which assets sit in scope under your CIP-002 categorization, then check whether each one has a baseline you can export today and whether your change records can be traced to it.

Which systems and changes CIP-010-4 R1 applies to

CIP-010-4 R1 does not apply the same way to every asset. The Applicable Systems column in each Part decides which BES Cyber Systems, associated EACMS, PACS and PCA carry the obligation, and which Parts add testing or software verification. Confirm each cell against the standard and your own CIP-002 categorization before you write the plan.

High impact BES Cyber Systems

High impact BES Cyber Systems fall under every Part of R1, including the baseline in Part 1.1, change authorization in Part 1.2 and the pre- and post-change control checks in Part 1.4. Your CIP-002 categorization sets which systems qualify, so the baseline inventory should start from that list rather than from the asset register. Confirm each high impact system and its Applicable Systems cell in the standard before you scope the baseline.

Medium impact systems with External Routable Connectivity

Medium impact BES Cyber Systems are in scope for R1 only where they have External Routable Connectivity, as the Applicable Systems cells define. Medium impact systems without that connectivity sit outside the baseline and change control Parts unless the cell says otherwise. Check each medium impact asset against your CIP-002 record and the cell wording, because a connectivity change can move a system into scope.

Associated EACMS, PACS and PCA

Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets are scoped by the cells alongside their associated BES Cyber Systems. Each supporting device that a CIP system depends on for access control or monitoring must be in the baseline, and its changes must go through the same authorization record. Confirm which of these devices the cells cover for each impact level, since the scope differs between Parts.

Part 1.5 testing for high impact systems

Pre-production testing under Part 1.5 applies to high impact BES Cyber Systems, and only where it is technically feasible. Where testing is not feasible, the change must still be made in a production environment designed to minimize adverse effects, and the results must be documented. Ask the vendor or operations team to document the feasibility decision for each system, because an auditor will ask why a test environment was not used.

Part 1.6 software verification reach

Software source and integrity checks under Part 1.6 reach high and medium impact systems, along with their EACMS and PACS. The check applies before baseline changes to operating systems or firmware, application software or security patches, when the source offers a verification method. Low impact systems fall outside this Part. Confirm which of your open-source and vendor packages publish verifiable checksums or signatures, and record where none exist.

Confirming each Applicable Systems cell

Before you finalize the scope, read every Applicable Systems cell in CIP-010-4 against your CIP-002 categorization for each Part. Record the impact level, connectivity status and asset type that drives each cell, and keep that record with the baseline. A competent auditor will test the scope decision first, so an unclear or undocumented decision can make the rest of the evidence harder to defend.

What a CIP-010-4 baseline must contain, item by item

Part 1.1 of CIP-010-4 R1 asks for a baseline configuration that records five things for each system in scope: the operating system or firmware with its version, the application software intentionally installed with its version (whether commercial or open source), any custom software, the logical network accessible ports, and the security patches applied. The baseline may be kept for each individual asset or for a group of assets that share the same configuration, but the group must be defined clearly enough that an assessor can see which assets it covers and that each member matches it. Choosing between individual and group baselines is the first decision to document, because it drives how many records you maintain and how often they must be refreshed.

Most baselines fail an assessor's tie-out on two fields. The first is version information. A record that says the operating system is installed, without the exact build or firmware version, cannot be compared against what the monitoring tools report, so the assessor cannot confirm the baseline matches reality. Application entries need the same precision, and open-source packages are often missed because they were installed by a developer or as a dependency rather than through a formal request. The second is the logical network accessible ports list. Teams often record the ports they intended to open, not the ports that actually listen. Before you sign off a baseline, run a port and service inventory on each asset and reconcile it line by line with the record. Confirm with your Regional Entity which evidence format it accepts for the tie-out.

Custom software and security patches need their own checks. Custom software should be listed by name and version, with a pointer to the source repository or build record, so that a later change can be traced. For patches, record what has been applied and which patches were assessed and deliberately not applied, since CIP-007 patch decisions feed into this baseline. A practical check is to take one high impact asset, compare its baseline line by line against a fresh scan, and log every mismatch as a finding before the audit does it for you. Build the reconciliation into the change record so the baseline is updated as a routine output of each approved change rather than as a separate clean-up exercise.

How to implement CIP-010-4 R1 in an operating environment

This sequence turns CIP-010-4 R1 into a working routine: a defined baseline for each system, controlled changes, checks before and after each change, and records an auditor can trace from request to verified baseline.

Define baseline scope for each BES Cyber System
The compliance lead and the system owners first confirm which BES Cyber Systems are in scope, using the CIP-002 categorization, and decide whether each system gets its own baseline or shares one with a group of identical assets. Grouping is only sensible where the configurations are truly the same, so the team should record the grouping rule and the asset list it covers. The output is a scoped asset inventory that names each baseline, its owner and the impact rating that drives which additional requirements apply. An auditor will ask for this inventory first and will test whether every in-scope asset appears under one baseline.
Capture the five required baseline items
Engineers record, for each baseline, the operating system or firmware with its version, the intentionally installed commercial or open-source application software with versions, any custom software, the logical network accessible ports, and the security patches applied. Discovery tools can collect much of this data, but a person should review the results against the asset owner's build records. The output is a versioned baseline document or configuration record per system or group. Auditors typically compare a sample of these records against the live system, so the record must match what is actually running.
Set up change authorization and documentation
The organization defines a change workflow in which any deviation from the baseline is proposed, reviewed and authorized before it is made, with the requester, the approver, the reason and the planned scope recorded. Ticketing or change management tools can hold these records, provided the approvals are retained and linked to the affected baseline. The output is a set of change tickets with dated authorizations, which auditors use to confirm that no deviation happened without an approval record. Confirm with your Compliance Enforcement Authority how it expects emergency changes to be documented.
Run pre-change impact checks and post-change verification
Before each baseline change, the engineer determines which CIP-005 and CIP-007 security controls the change could affect, such as electronic access points, port and service settings, malicious code protection and logging. After the change, the engineer verifies that those controls were not adversely affected and records the result against the same change ticket. The output is a pair of signed checks per change, one before and one after. Auditors commonly sample changes and ask to see both checks, so a missing post-change verification is a common finding.
Test changes in a representative environment
For high impact BES Cyber Systems, where technically feasible, the team tests the change in a test environment that models the baseline or in a production environment configured to minimize adverse effects. Test results are documented before the change goes live. Where a test environment is not technically feasible, the team should record why and what alternative controls it used, and confirm that approach with the auditor in advance. The output is a documented test record linked to the change ticket. Ask the compliance lead to confirm which systems meet the feasibility condition in your own environment.
Verify software source and integrity before installation
Before a baseline change to operating systems or firmware, application software or security patches, the team verifies the identity of the software source and the integrity of the software, where the source makes a verification method available. This applies to high and medium impact systems and their associated EACMS and PACS. The engineer records the method used, such as checking a published hash or signature, and the result. The output is a verification record attached to each relevant change. Teams should confirm with their vendors which verification methods each source actually publishes.
Update the baseline within 30 days
After a change is completed, the baseline record is updated within 30 calendar days to reflect the new state. Configuration management or monitoring tools can flag drift between the recorded baseline and the live system, which helps staff catch missed updates before the deadline. The output is an updated baseline version that cross-references the change ticket, the pre and post checks and any test or verification record. Auditors check the gap between change completion and baseline update, so the closing date on each ticket should be recorded precisely.

How an auditor tests CIP-010-4 R1 change control

This table lists each part of CIP-010-4 R1, the test approach an assessor typically takes, the evidence usually requested and the findings that appear most often. Sampling and scope are set by the Compliance Enforcement Authority, so confirm the sample size and period with your Regional Entity before fieldwork begins. Use the rows as a preparation checklist for the change records you already keep.

Part	Typical assessor approach	Evidence requested	Common findings
1.1 Baseline configuration	Compare the documented baseline with the live configuration of sampled systems and check that each required item is present.	Baseline records listing OS or firmware with version, installed application software with version, custom software, logical network accessible ports and applied security patches.	Baselines missing version numbers, open ports not recorded, or patches listed without dates or applicability.
1.2 Authorized and documented changes	Select sampled changes that deviate from the baseline and trace each to an authorization and a record.	Change tickets showing the change, the approver, the reason and the baseline deviation, along with the sample list the auditor selects.	Changes implemented without authorization, emergency changes with no later documentation, or tickets that do not name the deviation.
1.3 Baseline update within 30 days	Compare the completion date of each sampled change with the date the baseline record was updated.	Change completion records and baseline version history showing update dates.	Baselines updated after 30 calendar days, or updates made in a spreadsheet that does not keep prior versions.
1.4 Security control verification	Check that the entity identified which CIP-005 and CIP-007 controls could be affected before each change and verified them afterward.	Pre-change impact assessments, post-change verification results and the list of CIP-005 and CIP-007 controls checked.	Impact assessment absent or generic, or post-change checks not recorded for changes that touched access or port controls.
1.5 Test before production (high impact)	Where technically feasible for high impact systems, confirm a test or minimally adverse production environment was used and results were documented before implementation.	Test environment descriptions, test plans and results, and documented reasons where testing was not technically feasible.	No record of testing, test environments that do not model the baseline, or no rationale for skipping test.
1.6 Software source and integrity verification	Confirm that before a baseline change to OS or firmware, application software or security patches, the entity verified the source and integrity where the source offered a method.	Verification records such as checksum or signature checks, the vendor method used, and records showing where the method was not available.	Verification skipped for patches, no record of the method used, or no documented reason where the vendor offered no method.

Which open-source tools can produce CIP-010-4 R1 evidence

Open-source tools can produce much of the record-keeping behind CIP-010-4 R1, but none of them satisfies R1 on its own. Each tool produces records, not compliance. The entity remains responsible for its baselines, its authorizations and its verification decisions, and it must confirm that each tool fits its own environment and its own license obligations before relying on it for audit evidence. GLPI (GPL-3.0-or-later) is the most natural home for change records. Its Assistance module, which follows ITIL practices, lets teams create, follow and process tickets, problems and changes, with plannings, statistics and a Kanban view. A change ticket can hold the Part 1.2 authorization, the Part 1.4 list of CIP-005 and CIP-007 controls that could be affected, the post-change verification and the Part 1.3 baseline update, which gives an auditor one thread to follow. Confirm with the vendor and your own configuration whether the change workflow, approvals and retention settings meet your evidence needs.

Wazuh (GPL-2.0-only) and Fleet (MIT) can help with the comparison between an approved baseline and what is running. Wazuh's Security Configuration Assessment scans monitored endpoints against YAML policies, shipped mostly based on CIS benchmarks and extendable with custom policies, and recommends remediation. A custom policy that encodes your baseline's operating system version, listening ports and approved packages can produce pass or fail results over time. Fleet policies ask yes or no osquery questions of devices, and its policies page shows which devices pass or fail each policy. Both tools check state, so they support verification after a change, but they do not decide what the baseline should contain or whether a deviation was authorized. Ask each vendor which fields in its output can be exported as evidence and how long the results are retained in your deployment.

Zammad (AGPL-3.0-only) can serve as the intake point for change requests, collecting requests from email and other channels into one ticket system, with GLPI or another change process handling approval and records. Keep the intake and the authorization record linked, so the request that started a change and the approval that allowed it can be shown together. The AGPL-3.0-only license matters if you modify Zammad and offer it to users over a network, so have counsel confirm the obligations that apply to your deployment. Before you commit to this architecture, document which tool is the system of record for each R1 element, test the export of a sample change from start to finish, and confirm that the combined evidence still supports the 30-day baseline update and the test-environment results that Part 1.5 requires where technically feasible.

Which evidence passes an R1 audit and how to keep it current

An assessor testing CIP-010-4 R1 follows each change from the baseline to the authorization, the verification and the source check that surrounds it. The six artifacts below form that chain, and each one stays useful only if it is kept current between audits.

Baseline configuration records

Keep one baseline record per system or group of systems, listing the operating system or firmware with version, intentionally installed application software with version, custom software, logical network accessible ports and security patches applied. Assessors compare the record against the live system, so a baseline that names a version the device no longer runs is a finding. Version every baseline, keep superseded versions, and confirm that each one can be reproduced from the change record that produced it.

Change authorization records

Each deviation from the baseline needs a record showing who authorized it, when, what changed and why. Link the change ticket to the baseline version it modifies so an assessor can trace a change from request to approval to the resulting baseline. Sample tickets periodically for missing approvals, emergency changes approved after the fact, and changes whose stated scope does not match what was actually altered.

Baseline update records

After a change completes, the baseline must be updated within 30 calendar days. Record the completion date, the new baseline version and the person who made the update, then compare the two dates during review. Set an alert on open changes that have passed completion without a baseline update, because a late update is easy to miss until an assessor samples it.

Pre and post-change control verification

Before a baseline change, record which CIP-005 and CIP-007 controls could be affected, such as ports, services, malicious code protection, and electronic access points. After the change, record the check that confirms those controls were not adversely affected. A verification note that says only "tested OK" rarely satisfies an assessor, so name each control and the method used, and attach the scan or configuration output.

Test environment results for high impact changes

For high impact BES Cyber Systems, where technically feasible, changes must be tested in a test or production environment that models the baseline before production deployment. Document the environment, how closely it matches the baseline, the tests run, the results and the approval to deploy. Keep the record linked to the production change, and note where a test environment could not be used and what compensating checks were performed instead.

Software source and integrity records

Before a baseline change to operating systems, firmware, application software or security patches, record how the identity of the software source was verified and how file integrity was checked, such as vendor signatures or published hashes. Where the source does not offer a verification method, document that fact and the alternative control used. Retain these records with the change ticket, since an assessor will ask for them on a sampled change.

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

This table compares the main cost components of meeting CIP-010-4 R1, who is paid for each, whether it is one-time or recurring, and what moves it up or down. Use it to frame a quote request, since most of the cost is labor that open-source tooling reduces but does not remove.

Cost component	Who is paid	One-time or recurring	What drives it
Tooling or licenses	Software vendor or subscription provider	Recurring if commercial, near zero license cost if self-hosted open source	Number of BES Cyber Systems in scope, and whether the chosen edition includes the needed features. Confirm license and edition limits with each vendor.
Engineering time to build baselines	Internal engineers or an implementation partner	One-time for initial baselines, recurring for new or replaced assets	Asset count, device diversity, and how many Cyber Assets can be grouped under one baseline by Part 1.1 group rules
Change process effort	Internal change managers, system owners and reviewers	Recurring	Change volume, number of deviations from baseline that need authorization under Part 1.2, and how much change tracking is automated
Baseline update effort	Internal staff who record completed changes	Recurring	Number of changes that must update the baseline within 30 calendar days under Part 1.3, and whether updates are captured automatically
Test environment upkeep	Internal infrastructure team or a hosting provider	Recurring, with a one-time setup	Test environment fidelity to production and whether Part 1.5 testing is required for the high impact systems in scope
Software source and integrity verification	Internal security staff, vendors or integrators	Recurring per software source and patch cycle	Number of software sources, whether vendors publish verification methods, and how much verification is automated
Evidence upkeep	Internal compliance staff	Recurring	Retention period, number of systems, and whether baselines, change tickets and test results are stored in a searchable system
External review or testing	Independent auditor, consultant or testing firm	Recurring, tied to audit cycles	Audit scope, sample size, the Regional Entity's schedule, and whether an outside party reviews baseline or change records beforehand

Who does what: your team, an implementation partner and the auditor

Your organization remains accountable for CIP-010-4 R1. Your staff decide what the baseline for each BES Cyber System should contain, approve or reject each change that deviates from it, decide how and where testing happens for high impact systems, and make the attestations you submit to the Regional Entity. Those decisions are governance decisions, so they need named owners and documented authority.

Baseline ownership: Assign an accountable owner for each baseline, covering the operating system or firmware, intentionally installed software with versions, custom software, logical network accessible ports and security patches applied.
Change authorization: Approve deviations from the baseline before they occur, and record who approved them and why.
Test decisions: Decide when a test environment is technically feasible for high impact systems, and document the test results before production implementation.
Source and integrity sign-off: Confirm that software source identity and integrity checks were performed where the source makes a method available.
Regional Entity attestations: Own every statement you make to auditors and keep it consistent with the evidence.

Check that each of these duties has a named person, a backup and a record of the decision.

Questions buyers ask about CIP-010-4 R1

How much effort does CIP-010-4 R1 take to implement?

The effort depends mainly on how many BES Cyber Systems are in scope, how many distinct device types they contain, and how much of the baseline information already exists in a usable form. R1 asks for five baseline items per system or group, a record of every authorized deviation, a baseline update within 30 calendar days of each completed change, a pre-change and post-change check of the CIP-005 and CIP-007 controls that could be affected, and, for high impact systems, testing where technically feasible. Most of the work is one-time baseline capture and procedure design, followed by recurring change handling. Ask any provider to show how they will split effort between the initial baseline and the steady-state change workflow before accepting a quote.

Can an entity implement CIP-010-4 R1 in-house?

Yes, an entity can implement R1 in-house, and many do. The standard does not require outside help, and the organization owns its compliance program. In-house teams usually need staff who understand the vendor platforms, a change record system that can hold baselines and approvals, and enough configuration knowledge to say which CIP-005 and CIP-007 controls a given change could touch. Outside help is most often used for the initial baseline capture across many device types, for building the verification steps, or for an independent gap review before an audit. Whichever path is chosen, the entity remains accountable for the result.

How long does it take to stand up a CIP-010-4 R1 baseline program?

The timeline depends on the number of systems in scope, the state of existing documentation, and how many change processes need to be redesigned rather than simply written down. Systems with stable, well-documented configurations can be baselined faster than estates with undocumented vendor appliances or ad hoc change practices. A written scope should state the systems covered, the baseline items for each, the change workflow to be built, the test approach for high impact systems, and the review and handover steps. Ask the provider to commit to a schedule against that written scope rather than offer a generic estimate.

What does R1 need from operations and change management staff?

R1 needs operations staff to maintain accurate baselines and to explain how each system is actually configured, and change management staff to authorize, document and track every deviation from the baseline. In practice, operators must record the operating system or firmware version, installed application software and versions, custom software, logical network ports, and applied security patches. Change managers must define who approves a change, what evidence accompanies it, and how the security control check before and after the change is recorded. Both teams need a shared rule for when a baseline update is due, because the 30 calendar day clock starts when the change is completed.

Are open-source tools enough to meet CIP-010-4 R1?

Open-source tools can support R1 well, but they do not satisfy it on their own. A ticketing system such as GLPI, which follows ITIL practices and includes a change workflow, can hold authorizations and documentation. Wazuh's Security Configuration Assessment can compare endpoint settings against YAML policies, and Fleet policies can answer yes or no questions about devices through osquery queries. Each tool must be confirmed against your own environment, especially for vendor-specific appliances, which often fall outside general endpoint agents. Check the license terms and edition limits before deployment, and confirm that the tool's output can serve as the evidence an auditor will request.

How does a partner's role differ from the auditor's role?

A partner such as DeployOpen plans, implements, configures, documents and supports the systems and evidence that R1 requires. The entity owns its controls and remains responsible for compliance. An independent auditor or assessor is the party that tests the controls and reaches a conclusion about them, and the Compliance Enforcement Authority, a Regional Entity or NERC, monitors compliance through audits, spot checks and self-reports. Note that NERC CIP has no certificate issued by a partner. DeployOpen does not issue audit reports or certifications. Confirm the division of responsibilities in the written scope before work starts.

How DeployOpen scopes and prepares CIP-010-4 R1 evidence

DeployOpen helps registered entities prepare the systems, baselines and change records behind CIP-010-4 R1 Configuration change management. The registered entity keeps ownership of its controls and its compliance determinations, while DeployOpen plans, implements and documents the supporting setup inside the entity's own infrastructure.

How we scope

Engagements are fixed-scope, with the systems in scope, deliverables and timelines agreed in writing before work starts.
The written scope names the BES Cyber Systems, EACMS, PACS and PCA whose baselines and changes are covered, as categorized by the entity under CIP-002.
Scope also records which change sources, software repositories and test environments the entity uses for high impact systems.

How we build

We configure baseline capture for operating systems, firmware, application software with versions, custom software, logical ports and applied security patches.
We set up change tickets that require authorization, a documented reason and a record of which CIP-005 and CIP-007 controls the change could affect.
We build post-change verification and test-environment records for high impact changes, and set up software source and integrity checks where the source offers them.

How we hand over

Handover includes baseline records, change procedures, test results and verification records mapped to each Part of CIP-010-4 R1.
Operators receive runbooks that show how to update a baseline within 30 calendar days of completing a change.
The entity's compliance team receives an evidence index that shows where each record is stored and how long it is retained.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, with terms agreed in writing.
Retainer work can include reviewing change records and baseline drift before a regulator's audit or spot check.
Entities should confirm with their Regional Entity which evidence format and retention period it expects before handover.

CIP-010-4 R1 Configuration change management