ISO Compliance Insights & Best Practices
CART
ISO Compliance Insights & Best Practices
NERC CIP-010 is the reliability standard that controls how BES Cyber Systems change, and it is a frequent source of audit findings because it depends on discipline across engineering, operations and security teams every single day. A baseline that was accurate in January and never updated is a violation waiting to be discovered.
This guide explains the four requirements in CIP-010, what evidence auditors expect, how the recurring timelines work and how to build a process that keeps up with real changes. It applies to responsible entities in North America with the relevant impact levels. The text we reviewed was CIP-010-4; standards are revised regularly, so check NERC’s site for the version currently enforceable in your region. This article is not a compliance opinion.
Free gap assessment
Does your IACS programme match the 2024 restructure?
Score the eight security programme elements, free, with zones, conduits and target security levels assessed alongside them.
Run the free IEC 62443 gap assessment → or View premium report sample
CIP-010 is titled cyber security configuration change management and vulnerability assessments. Its purpose is to prevent and detect unauthorized changes to BES Cyber Systems that could destabilize the bulk electric system. In the version we reviewed, the requirements apply to high and medium impact BES Cyber Systems and their associated assets, while low impact systems are addressed under a different standard; see our guide to NERC CIP low impact.
Before you can apply it, you must know which systems are in scope. That depends on categorization; read BES Cyber System categorization first. For the broader family, see NERC CIP standards and NERC CIP compliance.
R1 requires a configuration change management process for each in-scope system. The baseline must record operating systems or firmware with versions, commercial or open-source applications with versions, custom software, logically accessible network ports and applied security patches.
Any change that deviates from the baseline must be authorized and documented. Before the change, you identify the cyber security controls from CIP-005 and CIP-007 that could be affected; after the change, you verify the controls still work and document the result. Within 30 calendar days of completing a change, update the baseline as necessary. Changes must be tested in a test environment or the production environment in a manner that minimizes adverse effects, and differences between the test and production environments must be documented. Where technically feasible, you must also verify the identity and integrity of software sources.
A simple ticket template that captures each of those steps makes the audit evidence almost automatic.
R2 requires you to monitor for changes to the baseline configuration at least once every 35 calendar days, and to investigate and document any detected unauthorized changes. Monitoring can be tool-based, such as a configuration management or file integrity product, or procedural, but it must actually run on schedule and produce records.
The 35-day interval is a rolling compliance clock. Set up an alert that warns when a system approaches its due date, and keep the output of each run. Auditors will sample systems and dates, and a gap of even a day can be a finding.
| Requirement | Purpose | Key timing |
|---|---|---|
| R1 Configuration change management | Baselines, authorized changes, impact assessment, testing, software verification | Update baseline within 30 calendar days of a change |
| R2 Configuration monitoring | Detect unauthorized changes to the baseline | At least once every 35 calendar days |
| R3 Vulnerability assessments | Find and address weaknesses | At least once every 15 calendar months; active assessment at least every 36 calendar months for high impact |
| R4 Transient cyber assets and removable media | Control temporary connections and media | Before connection, according to the plan |
| Records | Show the process operated | Retain at least three calendar years |
R3 sets two recurring assessments. A vulnerability assessment of the cyber systems must occur at least once every 15 calendar months, and for high impact systems an active assessment in the production or test environment must occur at least once every 36 calendar months. A paper assessment reviews configurations, ports and services; an active assessment scans or tests the system. New cyber assets must be assessed before being put into production, with certain exceptions.
Results need documentation: findings, an action plan to remediate or mitigate, and the planned date of completion. Track each item to closure. Our guide to NERC CIP patch management explains how this links to CIP-007 patch tracking, and CIP-013 supply chain covers vendor aspects of the same systems.
R4 governs laptops, test equipment and removable media that connect temporarily to in-scope systems. The entity must have a plan that authorizes users, locations and uses and that mitigates software vulnerabilities, malicious code and unauthorized use. When a third party manages a transient cyber asset, the entity must review the third party’s patching and malware protections and add mitigations where needed before connection.
For removable media, the plan must authorize the media and scan it for malicious code using a non-BES cyber asset before it is connected. Enforce this with process and, if possible, technical controls such as port blocking.
Retain evidence for at least three calendar years. For R1, keep baselines with dates, change tickets with authorization, impact assessments, test records and baseline updates. For R2, keep the monitoring outputs and investigation records. For R3, keep the assessment reports, action plans and closure evidence. For R4, keep the plan, authorizations and scan records. Our page on the NERC CIP audit process explains how regional entities sample this evidence.
A useful practice is to map each requirement part to one evidence location and to test retrieval quarterly. If a team cannot pull the last change record for a named system in a few minutes, the audit will be hard.
Typical issues include baselines missing ports or software versions, changes made without authorization or without a CIP-005 and CIP-007 impact check, baselines not updated within 30 days, monitoring that missed the 35-day window, vulnerability assessments without action plans and transient assets connected without the required checks.
Avoid them with automation where possible, a single change ticket template, scheduled reminders and periodic internal audits. Also make sure operations staff understand that CIP-010 applies to emergency changes too; document them after the fact if needed but do not skip the steps. Related reading: CIP-015 INSM and CIP-014 physical security.
The documents behind CIP-010 include the configuration change management procedure, baseline register, change request and impact assessment forms, monitoring records, vulnerability assessment reports and plans, and a transient cyber asset plan. The NERC CIP Toolkit includes editable templates across the CIP standards, so your team can adapt a structure instead of writing from scratch. Compare with international practice in NERC CIP vs IEC 62443.
For the standard itself, see the NERC CIP-010-4 standard text. Templates help with documentation, but auditors test whether the process ran on each system on schedule.
A utility engineer needs to update the firmware on an engineering workstation inside a medium impact control center. Under the process described above, the engineer opens a change ticket stating the system, the firmware version and the reason. A supervisor authorizes it. Before the change, the team records which CIP-005 and CIP-007 controls might be affected, such as the ports and services on the device and its logging. The firmware is tested on a spare unit, and the differences between the spare and the production unit are noted. The installer’s source and checksum are verified. After the change, the team confirms the controls still work and records the results, then updates the baseline within the 30-day limit. The next monitoring run shows the new baseline with no unauthorized differences. Details in this example are illustrative.
Track a handful of indicators each month: the percentage of changes with complete tickets, the number of baselines updated within 30 days, the number of systems within their 35-day monitoring window, the age of the oldest open vulnerability action item and the number of transient cyber assets connected without approved checks. Report the figures to the compliance lead and review trends quarterly. Metrics like these help you catch drift early, before it becomes a potential violation, and they show your regional entity that the program is managed, not improvised.
Name an owner for each requirement and train the engineers, operators and contractors who make changes. Short sessions built around real tickets work best. Include the people who handle emergency work, because emergency changes are where steps are most often skipped. Refresh the training when the process changes, and record attendance so you can show that the people doing the work understand the requirements and the evidence needed to prove them.
Teams often treat the baseline as a one-time project. They rely on memory for the 35-day and 15-month clocks. They forget test-versus-production differences. They skip verification of software sources and assume vendor media is trustworthy. Another problem is scope drift, where a newly added device never enters the baseline register. Keep the asset inventory, categorization and baselines in sync and review them together.
It is the reliability standard for configuration change management and vulnerability assessments for BES Cyber Systems, with four requirements.
At least once every 35 calendar days, with investigation of unauthorized changes.
At least once every 15 calendar months, and an active assessment at least once every 36 calendar months for high impact systems.
In the version reviewed, it applies to high and medium impact systems; low impact is handled under another standard. Check the current version for your region.
At least three calendar years, per the standard’s compliance section, or longer if required by your regional entity.
