NERC CIP-010 Configuration Change Management: Requirements, Evidence, and Best Practices

Each change may appear routine. But within a Bulk Electric System environment, an undocumented or poorly tested configuration change can affect cyber controls, system availability, and grid reliability.

NERC CIP-010 addresses this risk by requiring applicable entities to establish processes for configuration change management, configuration monitoring, vulnerability assessments, and the use of transient cyber assets and removable media.

The purpose of the standard is to prevent and detect unauthorized changes to BES Cyber Systems and reduce the possibility that a compromised or incorrectly configured system could contribute to Bulk Electric System misoperation or instability. As of July 2026, NERC lists CIP-010-4 as mandatory and subject to enforcement, while CIP-010-5 is identified as subject to future enforcement.

This article focuses primarily on the configuration change management and monitoring portions of the standard, including:

• What a CIP-010 baseline configuration must contain
• How changes should be requested, approved, tested, and documented
• When baseline records must be updated
• How unauthorized changes should be detected
• What evidence entities should retain
• Common gaps that create audit and operational risk

What Is NERC CIP-010?

NERC CIP-010 is formally titled Cyber Security: Configuration Change Management and Vulnerability Assessments.

The standard contains four major requirements:

Requirement R1: Configuration change management
Requirement R2: Configuration monitoring
Requirement R3: Vulnerability assessments
Requirement R4: Transient Cyber Assets and Removable Media

Configuration change management under R1 is designed to prevent unauthorized or unsafe changes. Configuration monitoring under R2 is designed to detect changes that occurred outside the authorized process. Vulnerability assessments under R3 help entities identify weaknesses in applicable systems, while R4 addresses risks introduced by temporary devices and removable media.

Together, these requirements create a control cycle:

1. Establish the approved configuration.
2. Control changes to that configuration.
3. Confirm security controls still operate after a change.
4. Monitor for unauthorized changes.
5. Assess systems for vulnerabilities.
6. Address risks introduced by temporary devices and media.

NERC’s technical rationale explains that R1 is intended to prevent unauthorized modifications, while R2 is intended to detect them.

Who Must Comply With CIP-010?

CIP-010 applies to designated Responsible Entities, including Balancing Authorities, qualifying Distribution Providers, Generator Operators, Generator Owners, Reliability Coordinators, Transmission Operators, and Transmission Owners.

For Distribution Providers, applicability is limited to specified facilities, systems, and equipment connected to BES protection or restoration functions, such as qualifying underfrequency load shedding, undervoltage load shedding, Remedial Action Schemes, certain Protection Systems, and Cranking Paths.

The individual requirement parts then identify the systems to which they apply. Depending on the requirement, these may include:

• High Impact BES Cyber Systems
• Medium Impact BES Cyber Systems
• Electronic Access Control or Monitoring Systems
• Physical Access Control Systems
• Protected Cyber Assets

Not every part applies to every system. For example, the 35-day configuration monitoring requirement under R2 applies to High Impact BES Cyber Systems and their associated EACMS and Protected Cyber Assets. It does not apply across all Medium Impact BES Cyber Systems in the same way.

Entities should therefore map applicability at the individual requirement-part level rather than treating CIP-010 as a single blanket requirement.

Why Configuration Change Management Matters

Industrial and operational technology environments are built for reliability, predictable performance, and long equipment lifecycles. A small configuration change can have consequences far beyond the system being modified.

Opening an unnecessary port may create an access path into a protected environment. Installing an incompatible patch may interrupt an operational application. Changing a firewall rule may affect Electronic Security Perimeter controls. Updating firmware may alter communications with other field equipment. A vendor modification may introduce software from an unverified source.

The risk is not limited to malicious activity. Many configuration incidents result from ordinary operational work performed without complete review, testing, authorization, or documentation.

A strong CIP-010 process provides a reliable answer to five questions:

1. What was the approved configuration?
2. What was changed?
3. Who authorized the change?
4. How was the security impact tested?
5. Does the current configuration still match the approved baseline?

Without those answers, teams may struggle to distinguish an authorized maintenance action from an unauthorized modification.

CIP-010 Requirement R1: Configuration Change Management

Requirement R1 requires applicable Responsible Entities to implement documented processes covering the applicable parts of Table R1.

A compliant process must do more than describe a general change management policy. It must show how the organization manages the specific baseline elements, approvals, testing, security verification, source validation, and documentation required by the standard.

1. Establish a baseline configuration

The baseline is the approved reference point against which future changes are evaluated.

For applicable High and Medium Impact BES Cyber Systems and associated EACMS, PACS, and Protected Cyber Assets, the baseline must include:

• Operating system and version, or firmware when no independent operating system exists
• Commercially available or open-source application software and versions
• Custom software installed
• Logical network-accessible ports
• Security patches applied

NERC permits baselines to be developed individually or by group. Evidence may be maintained in an asset management system, configuration repository, spreadsheet, or another controlled record that identifies the required baseline items.

Grouping can reduce administrative work when assets share the same approved configuration. However, the grouping method should be clear enough to determine which assets are covered and to identify exceptions.

For example, twenty identically configured workstations may share a standard baseline. If three have different application versions or port settings, those differences must be recorded rather than hidden within the group.

2. Authorize and document changes

Any change that deviates from the existing baseline must be authorized and documented.

Authorization should come from an individual or group with defined authority to approve the change. Evidence may include an electronically approved change request, work order, maintenance record, or other controlled documentation.

A useful change request should capture more than a brief statement such as “apply update.” It should identify:

• Affected asset or asset group
• Existing configuration
• Proposed configuration
• Business or operational reason
• Requester
• Implementer
• Approver
• Planned implementation date
• Expected security impact
• Testing method
• Rollback or recovery plan
• Related evidence

The record should make it possible for an independent reviewer to understand what changed and why the change was allowed.

3. Update the baseline within 30 calendar days

After completing a change that deviates from the baseline, the entity must update the baseline configuration as necessary within 30 calendar days.

The 30-day period should not become the normal target. Operationally, it is better to update the baseline as part of change closure.

Waiting creates a gap between the actual production state and the documented approved state. During that gap, monitoring tools may identify an authorized change as unauthorized, or teams may use an outdated baseline during troubleshooting, assessment, or audit preparation.

A well-designed workflow should prevent final closure until:

• Implementation evidence is attached
• Required testing is completed
• Post-change verification is recorded
• The baseline owner confirms the update
• The new configuration is entered into the approved repository

4. Evaluate affected CIP-005 and CIP-007 controls

Before implementing a baseline-deviating change, the entity must determine which required cybersecurity controls under CIP-005 and CIP-007 could be affected.

After the change, the entity must verify that those controls were not adversely affected and document the verification results.

This requirement turns change management into a security control rather than a simple IT approval process.

For example, a firewall upgrade may affect Electronic Security Perimeter access permissions, logging, authentication, or Interactive Remote Access. A server update may affect malicious code prevention, security event monitoring, account management, or patch processes.

A generic checkbox stating “security reviewed” may provide limited value. The change record should identify the controls considered and the results of the post-change verification.

5. Test changes affecting High Impact BES Cyber Systems

For High Impact BES Cyber Systems, changes that deviate from the baseline must be tested where technically feasible.

Testing may occur in a test environment or in production when performed in a way that minimizes adverse effects. The test environment should model the production baseline closely enough to determine whether required CIP-005 and CIP-007 controls could be affected.

When a test environment is used, the entity must document differences between test and production and explain how those differences were accounted for.

This is a frequent documentation challenge. A record may show that a test succeeded but provide no explanation of how the test environment differed from production.

Useful documentation should address differences such as:

• Network architecture
• Firewall policies
• Authentication services
• Hardware or firmware versions
• Connected field devices
• Data volume
• Redundancy
• Application integrations
• Security monitoring coverage

FERC’s published lessons learned have specifically encouraged entities to strengthen procedures and controls for documenting and accounting for differences between test and production environments.

6. Verify software source identity and integrity

Before certain baseline changes involving operating systems, commercial or open-source applications, or security patches, the entity must verify the identity of the software source and the integrity of the software when the method is available from that source.

Evidence may include a change record documenting source validation and integrity verification or an automated process that performs those checks.

Possible methods include:

• Vendor-provided cryptographic hashes
• Digital signatures
• Signed repositories
• Certificate validation
• Trusted software distribution platforms
• Controlled internal repositories populated from verified sources

The process should record what was checked, how it was checked, who performed the verification, and the result.

Simply downloading software from a familiar-looking web page may not demonstrate source identity or file integrity.

CIP-010 Requirement R2: Configuration Monitoring

Change management controls authorized activity. Configuration monitoring helps identify activity that bypassed those controls.

Under R2, applicable High Impact BES Cyber Systems and their associated EACMS and Protected Cyber Assets must be monitored for changes to the baseline at least once every 35 calendar days. Detected unauthorized changes must be documented and investigated.

Configuration monitoring should compare the observed state against the approved baseline elements covered by R1.1, including operating systems, applications, custom software, logical network-accessible ports, and applied security patches.

The process should produce evidence showing:

• When monitoring occurred
• Which assets were checked
• Which baseline attributes were compared
• What differences were detected
• Whether each difference was authorized
• How unauthorized changes were investigated
• What corrective actions were taken
• Whether the baseline or production state was corrected

Monitoring only produces value when exceptions are reviewed. A tool may generate hundreds of configuration alerts, but an entity still needs a defined process for triage, ownership, investigation, escalation, and closure.

FERC’s historical lessons learned have recommended automated mechanisms that enforce asset inventory updates during configuration management and procedures that detect and investigate unauthorized baseline changes.

An Effective CIP-010 Change Workflow

A practical CIP-010 workflow can be organized into eight connected stages.

Stage 1: Submit the request

The requester identifies the affected assets, proposed change, business reason, implementation date, and expected operational impact.

Stage 2: Determine applicability

The change is evaluated against asset categorization, CIP-010 applicability, and the current approved baseline.

The reviewer determines whether the change alters a baseline element and whether additional requirements apply because the asset is part of a High Impact BES Cyber System.

Stage 3: Assess cybersecurity impact

The entity identifies potentially affected CIP-005 and CIP-007 controls. The assessment should involve cybersecurity, operations, engineering, or asset owners as appropriate.

Stage 4: Plan testing and rollback

The team defines the testing method, expected results, success criteria, production safeguards, and rollback procedure.

For High Impact BES Cyber Systems, the record should explain whether testing is technically feasible and how differences between test and production will be addressed.

Stage 5: Approve the change

An authorized individual or group reviews the request, security assessment, testing plan, and implementation approach.

Approval should occur before implementation except where a documented CIP Exceptional Circumstance applies.

Stage 6: Implement and verify

The implementer completes the work and records the actual configuration, time, outcome, deviations, and any unexpected effects.

The team then verifies that identified CIP-005 and CIP-007 controls continue to operate as intended.

Stage 7: Update the baseline

The asset or configuration owner updates the baseline promptly and no later than the required 30-calendar-day limit.

Stage 8: Monitor and investigate

Configuration monitoring compares the actual state with the approved baseline. Any unexplained difference enters an investigation workflow with an owner, due date, findings, and corrective action.

Evidence Needed for CIP-010 Compliance

A policy alone does not demonstrate that the process operated.

Evidence should connect the documented procedure to individual changes and monitoring activities. A defensible evidence package may include:

• Approved configuration management procedures
• Asset-to-baseline mappings
• Current and historical baseline records
• Change requests and approvals
• Cybersecurity impact assessments
• Test plans and test results
• Test-to-production difference analysis
• Post-change control verification
• Software source and integrity checks
• Implementation records
• Baseline update timestamps
• Configuration monitoring logs
• Unauthorized change investigations
• Corrective action records
• Exception documentation
• Management review records

CIP-010-4 generally requires entities to retain evidence for each requirement for three calendar years, unless the Compliance Enforcement Authority directs a longer period or information relates to unresolved noncompliance.

Evidence should be organized by requirement, asset, and change rather than dispersed across inboxes, shared folders, ticketing platforms, and vendor systems.

Common CIP-010 Configuration Management Gaps

Incomplete baselines

Baselines may capture operating systems and applications but omit custom software, network-accessible ports, or applied patches.

Changes performed outside the workflow

Emergency maintenance, vendor work, and minor administrator changes may be treated as operational activity rather than configuration changes.

Approval after implementation

A ticket approved after the work is completed does not demonstrate prior authorization.

Weak security impact assessments

Change records may include a generic security approval without identifying the affected CIP-005 or CIP-007 controls.

Missing test-environment analysis

Testing may be documented, but differences between test and production are not recorded or addressed.

Late baseline updates

The production environment changes, but the baseline is not updated until the next audit, assessment, or monitoring cycle.

Monitoring without investigation

Tools detect differences, but alerts remain open or are closed without determining whether the changes were authorized.

Poor oversight of third parties

Vendors may install updates, connect diagnostic devices, or perform assessments without producing evidence that meets the entity’s CIP-010 procedure.

FERC emphasizes that registered entities remain responsible for compliance tasks performed by contractors, vendors, consultants, or other third parties. Entities should retain written evidence of third-party task completion and maintain appropriate oversight.

Using Automation to Strengthen CIP-010 Compliance

Automation should connect change records, asset data, approvals, evidence, and monitoring results.

Useful capabilities include:

• Structured change request forms
• Asset-based applicability rules
• Required approval routing
• Automated due dates
• Testing and verification checklists
• Evidence attachment requirements
• Baseline update reminders
• Escalations before the 30-day deadline
• Recurring 35-day monitoring tasks
• Unauthorized change investigation workflows
• Version-controlled procedures
• Audit-ready reports

Automation does not replace technical monitoring or engineering judgment. It reduces the chance that a required review, approval, update, or evidence item is missed.

Metrics for Managing CIP-010 Performance

Entities can improve the process by tracking a small set of operational indicators:

• Percentage of changes authorized before implementation
• Percentage of baseline updates completed within 30 days
• Average time from implementation to baseline update
• Percentage of applicable changes with documented security impact reviews
• Percentage of High Impact changes with complete testing evidence
• Percentage of monitoring cycles completed within 35 days
• Number of unauthorized changes detected
• Average investigation closure time
• Number of overdue corrective actions
• Percentage of vendor-performed changes with complete evidence

These measures help management identify weaknesses before they become audit findings or operational incidents.

Start your 21-day free trial and experience how VComply helps you with your policy management and compliance maturity.

Ready to strengthen policy management and compliance across your organization, Book a personalized demo with VComply and take the first step toward smarter compliance management.

Frequently Asked Questions (FAQs)

1. What is NERC CIP-010 configuration change management?

NERC CIP-010 configuration change management requires applicable entities to establish, document, and maintain approved baseline configurations for BES Cyber Systems. It also requires organizations to authorize, assess, test, document, and monitor changes that affect those configurations.

2. What must be included in a CIP-010 baseline configuration?

A baseline configuration should document the operating system or firmware, commercial and open-source software versions, custom software, logical network-accessible ports, and applied security patches for applicable systems.

3. How quickly must a baseline be updated after a configuration change?

When a change causes the system to deviate from its approved baseline, the baseline must be updated within 30 calendar days. Organizations should ideally update it as part of the change closure process rather than waiting until the deadline.

4. Does every configuration change require testing under CIP-010?

Changes affecting High Impact BES Cyber Systems must be tested when technically feasible. Testing should determine whether the change could adversely affect applicable CIP-005 or CIP-007 cybersecurity controls.

5. How often must configuration monitoring be performed?

Applicable High Impact BES Cyber Systems, Electronic Access Control or Monitoring Systems, and Protected Cyber Assets must be monitored for changes to the approved baseline at least once every 35 calendar days.

6. What evidence should organizations retain for a CIP-010 audit?

Organizations should retain baseline records, approved change requests, testing results, cybersecurity impact assessments, software integrity checks, implementation records, baseline update evidence, monitoring logs, unauthorized change investigations, and corrective action records.