CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

A. Introduction
1.

Title:
Cyber Security — Configuration Change Management and Vulnerability
Assessments

2.

Number:3.

Purpose:To prevent and detect unauthorized changes to BES Cyber Systems by
specifying configuration change management and vulnerability assessment
requirements in support of protecting BES Cyber Systems from compromise that could
lead to misoperation or instability in the Bulk Electric System (BES).

4.

Applicability:

CIP-010-4

4.1. Functional Entities: For the purpose of the requirements contained herein, thefollowing list of functional entities will be collectively referred to as “Responsible
Entities.” For requirements in this standard where a specific functional entity or
subset of functional entities are the applicable entity or entities, the functional
entity or entities are specified explicitly.
4.1.1. Balancing Authority
4.1.2. Distribution Provider that owns one or more of the following Facilities,
systems, and equipment for the protection or restoration of the BES:
4.1.2.1. Each underfrequency Load shedding (UFLS) or undervoltage
Load shedding (UVLS) system that:
4.1.2.1.1. is part of a Load shedding program that is subject toone or more requirements in a NERC or Regional
Reliability Standard; and4.1.2.1.2. performs automatic Load shedding under a common
control system owned by the Responsible Entity,
without human operator initiation, of 300 MW or
more.
4.1.2.2. Each Remedial Action Scheme (RAS) where the RAS is subject toone or more requirements in a NERC or Regional Reliability
Standard.
4.1.2.3. Each Protection System (excluding UFLS and UVLS) that applies
to Transmission where the Protection System is subject to one
or more requirements in a NERC or Regional Reliability
Standard.
4.1.2.4. Each Cranking Path and group of Elements meeting the initialswitching requirements from a Blackstart Resource up to andincluding the first interconnection point of the starting station
service of the next generation unit(s) to be started.
4.1.3. Generator Operator
Page 1 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

4.1.4. Generator Owner
4.1.5. Reliability Coordinator
4.1.6. Transmission Operator
4.1.7. Transmission Owner
4.2. Facilities: For the purpose of the requirements contained herein, the following
Facilities, systems, and equipment owned by each Responsible Entity in Section
4.1 above are those to which these requirements are applicable. For
requirements in this standard where a specific type of Facilities, system, or
equipment or subset of Facilities, systems, and equipment are applicable, theseare specified explicitly.
4.2.1. Distribution Provider: One or more of the following Facilities, systems
and equipment owned by the Distribution Provider for the protection or
restoration of the BES:
4.2.1.1. Each UFLS or UVLS System that:
4.2.1.1.1.

is part of a Load shedding program that is subject
to one or more requirements in a NERC or Regional
Reliability Standard; and4.2.1.1.2.

performs automatic Load shedding under acommon control system owned by the Responsible
Entity, without human operator initiation, of 300
MW or more.

4.2.1.2. Each RAS where the RAS is subject to one or more requirements
in a NERC or Regional Reliability Standard.
4.2.1.3. Each Protection System (excluding UFLS and UVLS) that applies
to Transmission where the Protection System is subject to one
or more requirements in a NERC or Regional Reliability
Standard.
4.2.1.4. Each Cranking Path and group of Elements meeting the initialswitching requirements from a Blackstart Resource up to andincluding the first interconnection point of the starting station
service of the next generation unit(s) to be started.
4.2.2. Responsible Entities listed in 4.1 other than Distribution Providers: All
BES Facilities.
4.2.3. Exemptions: The following are exempt from Standard CIP-010-4:
4.2.3.1. Cyber Assets at Facilities regulated by the Canadian Nuclear
Safety Commission.

Page 2 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

4.2.3.2. Cyber Assets associated with communication networks and data
communication links between discrete Electronic Security
Perimeters.
4.2.3.3. The systems, structures, and components that are regulated by
the Nuclear Regulatory Commission under a cyber security planpursuant to 10 C.F.R. Section 73.54.
4.2.3.4. For Distribution Providers, the systems and equipment that are
not included in section 4.2.1 above.
4.2.3.5. Responsible Entities that identify that they have no BES Cyber
Systems categorized as high impact or medium impact
according to the CIP-002 identification and categorization
processes.
5.

Effective Date: See Implementation Plan for Project 2019-03.

6.

Background: Standard CIP-010 exists as part of a suite of CIP Standards related tocyber security, which require the initial identification and categorization of BES Cyber
Systems and require a minimum level of organizational, operational and procedural
controls to mitigate risk to BES Cyber Systems.
Most requirements open with, “Each Responsible Entity shall implement one or more
documented [processes, plan, etc.] that include the applicable items in [Table
Reference].” The referenced table requires the applicable items in the procedures forthe requirement’s common subject matter.
The term documented processes refers to a set of required instructions specific to the
Responsible Entity and to achieve a specific outcome. This term does not imply any
particular naming or approval structure beyond what is stated in the requirements.
An entity should include as much as it believes necessary in its documented processes,
but it must address the applicable requirements in the table.
The terms program and plan are sometimes used in place of documented processes
where it makes sense and is commonly understood. For example, documented
processes describing a response are typically referred to as plans (i.e., incident
response plans and recovery plans). Likewise, a security plan can describe an
approach involving multiple procedures to address a broad subject matter.
Similarly, the term program may refer to the organization’s overall implementation of
its policies, plans, and procedures involving a subject matter. Examples in thestandards include the personnel risk assessment program and the personnel training
program. The full implementation of the CIP Cyber Security Standards could also bereferred to as a program. However, the terms program and plan do not imply any
additional requirements beyond what is stated in the standards.

Page 3 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Responsible Entities can implement common controls that meet requirements for
multiple high and medium impact BES Cyber Systems. For example, a single training
program could meet the requirements for training personnel across multiple BES
Cyber Systems.
Measures for the initial requirement are simply the documented processes
themselves. Measures in the table rows provide examples of evidence to show
documentation and implementation of applicable items in the documented processes.
These measures serve to provide guidance to entities in acceptable records ofcompliance and should not be viewed as an all-inclusive list.
Throughout the standards, unless otherwise stated, bulleted items in therequirements and measures are items that are linked with an “or,” and numbered
items are items that are linked with an “and.”Many references in the Applicability section use a threshold of 300 MW for UFLS and
UVLS. This particular threshold of 300 MW for UVLS and UFLS was provided in Version
1 of the CIP Cyber Security Standards. The threshold remains at 300 MW since it isspecifically addressing UVLS and UFLS, which are last ditch efforts to save the BES. A
review of UFLS tolerances defined within regional reliability standards for UFLS
program requirements to date indicates that the historical value of 300 MW
represents an adequate and reasonable threshold value for allowable UFLS
operational tolerances.
“Applicable Systems” Columns in Tables:
Each table has an “Applicable Systems” column to further define the scope ofsystems to which a specific requirement row applies. The CSO706 SDT adapted thisconcept from the National Institute of Standards and Technology (“NIST”) Risk
Management Framework as a way of applying requirements more appropriately
based on impact and connectivity characteristics. The following conventions are usedin the applicability column as described.
•

High Impact BES Cyber Systems – Applies to BES Cyber Systems categorized ashigh impact according to the CIP-002 identification and categorization processes.

•

Medium Impact BES Cyber Systems – Applies to BES Cyber Systems categorized
as medium impact according to the CIP-002 identification and categorization
processes.

•

Electronic Access Control or Monitoring Systems (EACMS) – Applies to eachElectronic Access Control or Monitoring System associated with a referenced
high impact BES Cyber System or medium impact BES Cyber System. Examples
may include, but are not limited to, firewalls, authentication servers, and log
monitoring and alerting systems.

Page 4 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments•

Physical Access Control Systems (PACS) – Applies to each Physical AccessControl System associated with a referenced high impact BES Cyber System or
medium impact BES Cyber System with External Routable Connectivity.

•

Protected Cyber Assets (PCA) – Applies to each Protected Cyber Assetassociated with a referenced high impact BES Cyber System or medium impact
BES Cyber System.

Page 5 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

B. Requirements and Measures
R1.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-010-4 Table R1 – Configuration Change Management. [Violation Risk Factor: Medium][Time Horizon: Operations Planning].

M1. Evidence must include each of the applicable documented processes that collectively include each of the applicablerequirement parts in CIP-010-4 Table R1 – Configuration Change Management and additional evidence to demonstrate
implementation as described in the Measures column of the table.
CIP-010-4 Table R1 – Configuration Change Management
Part
1.1

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and3. PCA

Requirements
Develop a baseline configuration,individually or by group, which shall
include the following items:
1.1.1. Operating system(s) (including
version) or firmware where no
independent operating system
exists;1.1.2. Any commercially available oropen-source application
software (including version)
intentionally installed;

Measures
Examples of evidence may include, but
are not limited to:•

A spreadsheet identifying therequired items of the baseline
configuration for each Cyber Asset,
individually or by group; or•

A record in an asset management
system that identifies the required
items of the baseline configurationfor each Cyber Asset, individually or
by group.

1.1.3. Any custom software installed;
1.1.4. Any logical network accessible
ports; and1.1.5. Any security patches applied.
1.2

High Impact BES Cyber Systems andtheir associated:
1. EACMS;

Authorize and document changes thatdeviate from the existing baseline
configuration.

Examples of evidence may include, but
are not limited to:Page 6 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

CIP-010-4 Table R1 – Configuration Change Management
Part

Applicable Systems

Requirements

2. PACS; and3. PCA

Measures•

A change request record andassociated electronic authorization(performed by the individual orgroup with the authority toauthorize the change) in a change
management system for eachchange; or•Documentation that the change was
performed in accordance with therequirement.

Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and3. PCA

1.3

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCAFor a change that deviates from theexisting baseline configuration, update
the baseline configuration as necessary
within 30 calendar days of completingthe change.

An example of evidence may include,
but is not limited to, updated baseline
documentation with a date that iswithin 30 calendar days of the date of
the completion of the change.

For a change that deviates from theexisting baseline configuration:

An example of evidence may include,
but is not limited to, a list of cybersecurity controls verified or tested
along with the dated test results.

Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and3. PCA
1.4

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
and their associated:

1.4.1. Prior to the change, determine
required cyber security controls
in CIP-005 and CIP-007 that could
be impacted by the change;
1.4.2. Following the change, verify that

Page 7 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

CIP-010-4 Table R1 – Configuration Change Management
Part

Applicable Systems
1. EACMS;
2. PACS; and3. PCA

Requirements

Measuresrequired cyber security controls
determined in 1.4.1 are notadversely affected; and1.4.3. Document the results of theverification.

1.5

High Impact BES Cyber Systems

Where technically feasible, for eachchange that deviates from the existingbaseline configuration:
1.5.1. Prior to implementing any
change in the production
environment, test the changes
in a test environment or test thechanges in a production
environment where the test is
performed in a manner thatminimizes adverse effects, thatmodels the baseline
configuration to ensure that
required cyber security controls
in CIP-005 and CIP-007 are notadversely affected; andAn example of evidence may include,
but is not limited to, a list of cybersecurity controls tested along withsuccessful test results and a list ofdifferences between the production
and test environments withdescriptions of how any differenceswere accounted for, including the dateof the test.

1.5.2. Document the results of thetesting and, if a test
environment was used, thedifferences between the test
environment and the production
environment, including adescription of the measures
Page 8 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

CIP-010-4 Table R1 – Configuration Change Management
Part

Applicable Systems

Requirements

Measuresused to account for any
differences in operation
between the test andproduction environments.
1.6

High Impact BES Cyber Systems andtheir associated:
1. EACMS; and2. PACS
Medium Impact BES Cyber Systems
and their associated:
1. EACMS; and2. PACS

Prior to a change that deviates from theexisting baseline configuration
associated with baseline items in Parts
1.1.1, 1.1.2, and 1.1.5, and when themethod to do so is available to the
Responsible Entity from the software
source:1.6.1. Verify the identity of thesoftware source; andNote: Implementation does not require
the Responsible Entity to renegotiate
1.6.2. Verify the integrity of theor abrogate existing contracts
software obtained from the(including amendments to master
software source.
agreements and purchase orders).
Additionally, the following issues arebeyond the scope of Part 1.6: (1) the
actual terms and conditions of a
procurement contract; and (2) vendor
performance and adherence to acontract.

An example of evidence may include,
but is not limited to a change request
record that demonstrates theverification of identity of the software
source and integrity of the software
was performed prior to the baselinechange or a process which documents
the mechanisms in place that would
automatically ensure the identity of thesoftware source and integrity of thesoftware.

Page 9 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

R2.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-010-4 Table R2 – Configuration Monitoring. [Violation Risk Factor: Medium] [TimeHorizon: Operations Planning].

M2. Evidence must include each of the applicable documented processes that collectively include each of the applicablerequirement parts in CIP-010-4 Table R2 – Configuration Monitoring and additional evidence to demonstrate
implementation as described in the Measures column of the table.
CIP-010-4 Table R2 – Configuration Monitoring
Part
2.1

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. EACMS; and2. PCA

Requirements

Measures

Monitor at least once every 35 calendar
days for changes to the baseline
configuration (as described in
Requirement R1, Part 1.1). Document
and investigate detected unauthorizedchanges.

An example of evidence may include,
but is not limited to, logs from asystem that is monitoring theconfiguration along with records ofinvestigation for any unauthorizedchanges that were detected.

Page 10 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

R3.

Each Responsible Entity shall implement one or more documented process(es) that collectively include each of theapplicable requirement parts in CIP-010-3 Table R3– Vulnerability Assessments. [Violation Risk Factor: Medium] [TimeHorizon: Long-term Planning and Operations Planning]

M3. Evidence must include each of the applicable documented processes that collectively include each of the applicablerequirement parts in CIP-010-3 Table R3 – Vulnerability Assessments and additional evidence to demonstrate
implementation as described in the Measures column of the table.
CIP-010-4 Table R3 – Vulnerability Assessments
Part
3.1

Applicable Systems
High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA
Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and3. PCA

Requirements
At least once every 15 calendar
months, conduct a paper or active
vulnerability assessment.

Measures
Examples of evidence may include, but
are not limited to:•

A document listing the date of theassessment (performed at least
once every 15 calendar months),
the controls assessed for each BES
Cyber System along with themethod of assessment; or•A document listing the date of theassessment and the output of any
tools used to perform theassessment.

Page 11 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

CIP-010-4 Table R3 – Vulnerability Assessments
Part
3.2

Applicable Systems
High Impact BES Cyber Systems

Requirements
Where technically feasible, at least
once every 36 calendar months:
3.2.1 Perform an active vulnerability
assessment in a test
environment, or perform anactive vulnerability assessment
in a production environment
where the test is performed ina manner that minimizes
adverse effects, that models
the baseline configuration of
the BES Cyber System in a
production environment; andMeasures
An example of evidence may include,
but is not limited to, a document
listing the date of the assessment(performed at least once every 36
calendar months), the output of thetools used to perform the assessment,
and a list of differences between the
production and test environmentswith descriptions of how any
differences were accounted for in
conducting the assessment.

3.2.2 Document the results of thetesting and, if a test
environment was used, thedifferences between the test
environment and the
production environment,
including a description of themeasures used to account forany differences in operation
between the test andproduction environments.

Page 12 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

CIP-010-4 Table R3 – Vulnerability Assessments
Part

Applicable Systems

Requirements

Measures3.3

High Impact BES Cyber Systems andtheir associated:
1. EACMS; and2. PCA

Prior to adding a new applicable Cyber
Asset to a production environment,
perform an active vulnerability
assessment of the new Cyber Asset,
except for CIP Exceptional
Circumstances and like replacementsof the same type of Cyber Asset with abaseline configuration that models an
existing baseline configuration of theprevious or other existing Cyber Asset.

An example of evidence may include,
but is not limited to, a document
listing the date of the assessment(performed prior to thecommissioning of the new Cyber
Asset) and the output of any tools
used to perform the assessment.

3.4

High Impact BES Cyber Systems andtheir associated:
1. EACMS;
2. PACS; and3. PCA

Document the results of theassessments conducted according toParts 3.1, 3.2, and 3.3 and the action
plan to remediate or mitigate
vulnerabilities identified in theassessments including the planned
date of completing the action plan andthe execution status of any
remediation or mitigation action
items.

An example of evidence may include,
but is not limited to, a document
listing the results or the review orassessment, a list of action items,
documented proposed dates ofcompletion for the action plan, andrecords of the status of the action
items (such as minutes of a status
meeting, updates in a work ordersystem, or a spreadsheet tracking theaction items).

Medium Impact BES Cyber Systems
and their associated:
1. EACMS;
2. PACS; and3. PCA

Page 13 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

R4.

Each Responsible Entity, for its high impact and medium impact BES Cyber Systems and associated Protected Cyber Assets,shall implement, except under CIP Exceptional Circumstances, one or more documented plan(s) for Transient Cyber Assets
and Removable Media that include the sections in Attachment 1. [Violation Risk Factor: Medium] [Time Horizon: Long-term
Planning and Operations Planning]

M4. Evidence shall include each of the documented plan(s) for Transient Cyber Assets and Removable Media that collectively
include each of the applicable sections in Attachment 1 and additional evidence to demonstrate implementation of plan(s)for Transient Cyber Assets and Removable Media. Additional examples of evidence per section are located in Attachment
2. If a Responsible Entity does not use Transient Cyber Asset(s) or Removable Media, examples of evidence include, but are
not limited to, a statement, policy, or other document that states the Responsible Entity does not use Transient Cyber
Asset(s) or Removable Media.

Page 14 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

C. Compliance1.

Compliance Monitoring Process
1.1. Compliance Enforcement Authority: “Compliance Enforcement Authority”(CEA) means NERC or the Regional Entity, or any entity as otherwise designatedby an Applicable Governmental Authority, in their respective roles ofmonitoring and/or enforcing compliance with mandatory and enforceable
Reliability Standards in their respective jurisdictions.
1.2. Evidence Retention: The following evidence retention period(s) identify theperiod of time an entity is required to retain specific evidence to demonstratecompliance. For instances where the evidence retention period specified below
is shorter than the time since the last audit, the CEA may ask an entity toprovide other evidence to show that it was compliant for the full-time period
since the last audit.
The applicable entity shall keep data or evidence to show compliance as
identified below unless directed by its CEA to retain specific evidence for alonger period of time as part of an investigation.
•

Each applicable entity shall retain evidence of each requirement in thisstandard for three calendar years.

•

If an applicable entity is found non-compliant, it shall keep information
related to the non-compliance until mitigation is complete and approved orfor the time specified above, whichever is longer.

• The CEA shall keep the last audit records and all requested and submitted
subsequent audit records.
1.3. Compliance Monitoring and Enforcement Program: As defined in the NERC
Rules of Procedure, “Compliance Monitoring and Enforcement Program” refers
to the identification of the processes that will be used to evaluate data or
information for the purpose of assessing performance or outcomes with theassociated Reliability Standard.

Page 15 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Violation Severity Levels
R#

R1.

Violation Severity Levels

Lower VSL

Moderate VSLHigh VSL

Severe VSL

The Responsible Entity has
documented andimplemented a
configuration change
management process(es)that includes only four of
the required baseline items
listed in 1.1.1 through 1.1.5.
(1.1)

The Responsible Entity has
documented andimplemented a
configuration change
management process(es)that includes only three ofthe required baseline items
listed in 1.1.1 through 1.1.5.
(1.1)

The Responsible Entity has
documented andimplemented a
configuration change
management process(es)that includes only two of therequired baseline items
listed in 1.1.1 through 1.1.5.
(1.1)

The Responsible Entity has
not documented or
implemented any
configuration change
management process(es).
(R1)

OR
The Responsible Entity has aprocess as specified in Part
1.6 to verify the identity ofthe software source (1.6.1)
but does not have a process
as specified in Part 1.6 toverify the integrity of thesoftware provided by thesoftware source when themethod to do so is available
to the Responsible Entity
from the software source.
(1.6.2)OR
The Responsible Entity has
documented andimplemented a
configuration change
management process(es)that includes only one of therequired baseline items
listed in 1.1.1 through 1.1.5.
(1.1)
ORThe Responsible Entity does
not have a process(es) that
requires authorization anddocumentation of changes
that deviate from theexisting baseline
configuration. (1.2)
ORPage 16 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

R#

Violation Severity Levels

Lower VSL

Moderate VSLHigh VSL

Severe VSL
The Responsible Entity does
not have a process(es) to
update baseline
configurations within 30
calendar days of completinga change(s) that deviatesfrom the existing baseline
configuration.(1.3)
OR
The Responsible Entity does
not have a process(es) todetermine required security
controls in CIP-005 and CIP007 that could be impacted
by a change(s) that deviatesfrom the existing baseline
configuration. (1.4.1)
OR
The Responsible Entity has aprocess(es) to determine
required security controls in
CIP-005 and CIP-007 that
could be impacted by achange(s) that deviates fromthe existing baseline
configuration but did notverify and document thatthe required controls were
Page 17 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

R#

Violation Severity Levels

Lower VSL

Moderate VSLHigh VSL

Severe VSL
not adversely affectedfollowing the change. (1.4.2& 1.4.3)
OR
The Responsible Entity does
not have a process fortesting changes in anenvironment that models
the baseline configuration
prior to implementing achange that deviates frombaseline configuration.
(1.5.1)OR
The Responsible Entity does
not have a process to
document the test results
and, if using a test
environment, document thedifferences between thetest and production
environments. (1.5.2)
OR
The Responsible Entity does
not have a process as
specified in Part 1.6 to verify
the identity of the software
Page 18 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Violation Severity Levels

R#

Lower VSL

Moderate VSLHigh VSL

Severe VSL
source and the integrity ofthe software provided by
the software source whenthe method to do so isavailable to the Responsible
Entity from the software
source. (1.6)

R2.

N/A

N/A

N/A

The Responsible Entity has
not documented or
implemented a process(es)to monitor for, investigate,
and document detected
unauthorized changes to thebaseline at least once every
35 calendar days. (2.1)

R3.

The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes foreach of its applicable BES
Cyber Systems, but has
performed a vulnerability
assessment more than 15
months, but less than 18
months, since the lastassessment on one of its

The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes foreach of its applicable BES
Cyber Systems, but has
performed a vulnerability
assessment more than 18
months, but less than 21months, since the lastassessment on one of its

The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes foreach of its applicable BES
Cyber Systems, but has
performed a vulnerability
assessment more than 21months, but less than 24
months, since the lastassessment on one of its

The Responsible Entity has
not implemented any
vulnerability assessment
processes for one of its
applicable BES Cyber
Systems. (R3)ORThe Responsible Entity has
implemented one or more
documented vulnerability
assessment processes foreach of its applicable BES
Page 19 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Violation Severity Levels

R#

Lower VSL

Moderate VSLHigh VSL

applicable BES Cyber
Systems. (3.1)

applicable BES Cyber
Systems. (3.1)

applicable BES Cyber
Systems. (3.1)

OR

OR

OR

The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has performed
an active vulnerability
assessment more than 36
months, but less than 39
months, since the last active
assessment on one of its
applicable BES Cyber
Systems. (3.2)

The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has performed
an active vulnerability
assessment more than 39
months, but less than 42
months, since the last active
assessment on one of its
applicable BES Cyber
Systems. (3.2)

The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has performed
an active vulnerability
assessment more than 42
months, but less than 45
months, since the last active
assessment on one of its
applicable BES Cyber
Systems. (3.2)

Severe VSL
Cyber Systems, but has
performed a vulnerability
assessment more than 24
months since the lastassessment on one of its
applicable BES Cyber
Systems. (3.1)
OR
The Responsible Entity has
implemented one or more
documented active
vulnerability assessment
processes for Applicable
Systems, but has performed
an active vulnerability
assessment more than 45
months since the last active
assessment on one of its
applicable BES Cyber
Systems.(3.2)
OR
The Responsible Entity has
implemented anddocumented one or more
vulnerability assessment
processes for each of its
applicable BES Cyber
Systems, but did not
Page 20 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

R#

Violation Severity Levels

Lower VSL

Moderate VSLHigh VSL

Severe VSL
perform the active
vulnerability assessment ina manner that models an
existing baseline
configuration of its
applicable BES Cyber
Systems. (3.3)
OR
The Responsible Entity has
implemented one or more
documented vulnerability
assessment processes foreach of its applicable BES
Cyber Systems, but has not
documented the results ofthe vulnerability
assessments, the actionplans to remediate or
mitigate vulnerabilities
identified in theassessments, the planned
date of completion of theaction plan, and theexecution status of the
mitigation plans. (3.4)

R4.

The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and

The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and

The Responsible Entity
documented its plan(s) for
Transient Cyber Assets and

The Responsible Entity
failed to document or
implement one or more
Page 21 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Violation Severity Levels

R#

Lower VSL

Moderate VSLHigh VSL

Severe VSL

Removable Media, butfailed to manage its
Transient Cyber Asset(s)according to CIP-010-4,
Requirement R4,
Attachment 1, Section 1.1.
(R4)

Removable Media, butfailed to implement theRemovable Media sections
according to CIP-010-4,
Requirement R4,
Attachment 1, Section 3.
(R4)

Removable Media, butfailed to authorize its
Transient Cyber Asset(s)according to CIP-010-4,
Requirement R4,
Attachment 1, Section 1.2.
(R4)

plan(s) for Transient Cyber
Assets and Removable
Media according to CIP-0104, Requirement R4. (R4)

OR

OR

OR

The Responsible Entity
documented its plan(s) for
Transient Cyber Assets andRemovable Media, butfailed to document theRemovable Media sections
according to CIP-010-4,
Requirement R4,
Attachment 1, Section 3.
(R4)

The Responsible Entity
documented its plan(s) for
Transient Cyber Assets andRemovable Media plan, butfailed to document
mitigation of software
vulnerabilities, mitigation
for the introduction ofmalicious code, or
mitigation of the risk ofunauthorized use forTransient Cyber Assets
managed by the Responsible
Entity according to CIP-0104, Requirement R4,
Attachment 1, Sections 1.3,
1.4, and 1.5. (R4)The Responsible Entity
documented its plan(s) for
Transient Cyber Assets andRemovable Media, butfailed to implement
mitigation of software
vulnerabilities, mitigation
for the introduction ofmalicious code, or
mitigation of the risk ofunauthorized use forTransient Cyber Assets
managed by the Responsible
Entity according to CIP-0104, Requirement R4,
Attachment 1, Sections 1.3,
1.4, and 1.5. (R4)OR

OR

The Responsible Entity
documented its plan(s) for

The Responsible Entity
documented its plan(s) forOR
The Responsible Entity
documented its plan(s) for
Transient Cyber Assets andRemovable Media, butfailed to document
authorization for Transient
Cyber Assets managed by
the Responsible Entity
according to CIP-010-4,

Page 22 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

R#

Violation Severity Levels

Lower VSL

Moderate VSLHigh VSL

Requirement R4,
Attachment 1, Section 1.2.
(R4)

Transient Cyber Assets andRemovable Media, butfailed to document
mitigation of software
vulnerabilities or mitigation
for the introduction ofmalicious code for Transient
Cyber Assets managed by aparty other than the
Responsible Entity according
to CIP-010-4, Requirement
R4, Attachment 1, Sections
2.1, 2.2, and 2.3. (R4)

Transient Cyber Assets andRemovable Media, butfailed to implement
mitigation of software
vulnerabilities or mitigation
for the introduction ofmalicious code for Transient
Cyber Assets managed by aparty other than the
Responsible Entity according
to CIP-010-4, Requirement
R4, Attachment 1, Sections
2.1, 2.2, and 2.3. (R4)

Severe VSL

Page 23 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

D. Regional Variances
None.

E. Associated Documents•

Implementation Plan for Project 2019-03.

•

CIP-010-4 Technical Rationale

Page 24 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Version History
VersionDate

ActionChange Tracking

1

11/26/12

Adopted by the NERC Board ofTrustees.

Developed to define theconfiguration change
management andvulnerability assessment
requirements incoordination with other
CIP standards and toaddress the balance of
the FERC directives in its
Order 706.

1

11/22/13

FERC Order issued approving CIP-0101. (Order becomes effective on
2/3/14.)2

11/13/14

Adopted by the NERC Board ofTrustees.

Addressed two FERC
directives from Order No.
791 related to identify,
assess, and correct
language andcommunication networks.

2

2/12/15

Adopted by the NERC Board ofTrustees.

Replaces the version
adopted by the Board on
11/13/2014. Revised
version addresses
remaining directives from
Order No. 791 related totransient devices and low
impact BES Cyber Systems.

2

1/21/16

FERC Order issued approving CIP-0103. Docket No. RM15-14-000

307/20/17

3

08/10/17

3

10/18/2018

4

08/01/2019

4

11/05/2020

Modified to address certain directives Revisedin FERC Order No. 829.
Adopted by the NERC Board ofTrustees.
FERC Order approving CIP-010-3.
Docket No. RM17-13-000.
Modified to address directives in FERC Revised
Order No. 850.
Adopted by the NERC Board ofTrustees.

Page 25 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments
VersionDate

4

3/18/2021

4

4/5/2021

ActionFERC order approving Docket No.
RD21-2-000
Effective Date

Change Tracking

10/1/2022

Page 26 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

CIP-010-4 - Attachment 1
Required Sections for Plans for Transient Cyber Assets and Removable Media
Responsible Entities shall include each of the sections provided below in their plan(s) for
Transient Cyber Assets and Removable Media as required under Requirement R4.
Section 1.

Transient Cyber Asset(s) Managed by the Responsible Entity.
1.1. Transient Cyber Asset Management: Responsible Entities shall manage
Transient Cyber Asset(s), individually or by group: (1) in an ongoing manner
to ensure compliance with applicable requirements at all times, (2) in an ondemand manner applying the applicable requirements before connection toa BES Cyber System, or (3) a combination of both (1) and (2) above.
1.2. Transient Cyber Asset Authorization: For each individual or group of
Transient Cyber Asset(s), each Responsible Entity shall authorize:
1.2.1. Users, either individually or by group or role;
1.2.2. Locations, either individually or by group; and1.2.3. Uses, which shall be limited to what is necessary to perform business
functions.
1.3. Software Vulnerability Mitigation: Use one or a combination of the following
methods to achieve the objective of mitigating the risk of vulnerabilities
posed by unpatched software on the Transient Cyber Asset (per Transient
Cyber Asset capability):•

Security patching, including manual or managed updates;•

Live operating system and software executable only from read-only
media;•

System hardening; or•Other method(s) to mitigate software vulnerabilities.

1.4. Introduction of Malicious Code Mitigation: Use one or a combination of thefollowing methods to achieve the objective of mitigating the introduction ofmalicious code (per Transient Cyber Asset capability):•

Antivirus software, including manual or managed updates of signatures
or patterns;•

Application whitelisting; or•Other method(s) to mitigate the introduction of malicious code.

1.5. Unauthorized Use Mitigation: Use one or a combination of the following
methods to achieve the objective of mitigating the risk of unauthorized useof Transient Cyber Asset(s):Page 27 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Section 2.

•

Restrict physical access;•Full-disk encryption with authentication;•

Multi-factor authentication; or•Other method(s) to mitigate the risk of unauthorized use.

Transient Cyber Asset(s) Managed by a Party Other than the Responsible Entity.
2.1. Software Vulnerabilities Mitigation: Use one or a combination of thefollowing methods to achieve the objective of mitigating the risk ofvulnerabilities posed by unpatched software on the Transient Cyber Asset(per Transient Cyber Asset capability):•

Review of installed security patch(es);•Review of security patching process used by the party;•

Review of other vulnerability mitigation performed by the party; or•Other method(s) to mitigate software vulnerabilities.

2.2. Introduction of malicious code mitigation: Use one or a combination of thefollowing methods to achieve the objective of mitigating malicious code (perTransient Cyber Asset capability):•

Review of antivirus update level;•

Review of antivirus update process used by the party;•

Review of application whitelisting used by the party;•

Review use of live operating system and software executable only fromread-only media;•

Review of system hardening used by the party; or•Other method(s) to mitigate malicious code.

2.3. For any method used to mitigate software vulnerabilities or malicious code
as specified in 2.1 and 2.2, Responsible Entities shall determine whether any
additional mitigation actions are necessary and implement such actions prior
to connecting the Transient Cyber Asset.
Section 3.

Removable Media
3.1. Removable Media Authorization: For each individual or group of Removable
Media, each Responsible Entity shall authorize:
3.1.1. Users, either individually or by group or role; and3.1.2. Locations, either individually or by group.
3.2. Malicious Code Mitigation: To achieve the objective of mitigating the threatof introducing malicious code to high impact or medium impact BES Cyber

Page 28 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

Systems and their associated Protected Cyber Assets, each Responsible Entity
shall:
3.2.1. Use method(s) to detect malicious code on Removable Media using a
Cyber Asset other than a BES Cyber System or Protected Cyber Assets;
and
3.2.2. Mitigate the threat of detected malicious code on Removable Mediaprior to connecting the Removable Media to a high impact or medium
impact BES Cyber System or associated Protected Cyber Assets.

Page 29 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

CIP-010-4 - Attachment 2
Examples of Evidence for Plans for Transient Cyber Assets and Removable Media
Section 1.1: Examples of evidence for Section 1.1 may include, but are not limited to, themethod(s) of management for the Transient Cyber Asset(s). This can be included
as part of the Transient Cyber Asset plan(s), part of the documentation related toauthorization of Transient Cyber Asset(s) managed by the Responsible Entity orpart of a security policy.
Section 1.2: Examples of evidence for Section 1.2 may include, but are not limited to,
documentation from asset management systems, human resource management
systems, or forms or spreadsheets that show authorization of Transient Cyber
Asset(s) managed by the Responsible Entity. Alternatively, this can be
documented in the overarching plan document.
Section 1.3: Examples of evidence for Section 1.3 may include, but are not limited to,
documentation of the method(s) used to mitigate software vulnerabilities posedby unpatched software such as security patch management implementation, theuse of live operating systems from read-only media, system hardening practices
or other method(s) to mitigate the software vulnerability posed by unpatchedsoftware. Evidence can be from change management systems, automated patch
management solutions, procedures or processes associated with using live
operating systems, or procedures or processes associated with system hardening
practices. If a Transient Cyber Asset does not have the capability to use method(s)that mitigate the risk from unpatched software, evidence may include
documentation by the vendor or Responsible Entity that identifies that theTransient Cyber Asset does not have the capability.
Section 1.4: Examples of evidence for Section 1.4 may include, but are not limited to,
documentation of the method(s) used to mitigate the introduction of malicious
code such as antivirus software and processes for managing signature or pattern
updates, application whitelisting practices, processes to restrict communication,or other method(s) to mitigate the introduction of malicious code. If a Transient
Cyber Asset does not have the capability to use method(s) that mitigate theintroduction of malicious code, evidence may include documentation by thevendor or Responsible Entity that identifies that the Transient Cyber Asset does
not have the capability.
Section 1.5: Examples of evidence for Section 1.5 may include, but are not limited to,
documentation through policies or procedures of the method(s) to restrict
physical access; method(s) of the full-disk encryption solution along with theauthentication protocol; method(s) of the multi-factor authentication solution; or
documentation of other method(s) to mitigate the risk of unauthorized use.
Section 2.1: Examples of evidence for Section 2.1 may include, but are not limited to,
documentation from change management systems, electronic mail or proceduresthat document a review of installed security patch(es); memoranda, electronic

Page 30 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

mail, policies or contracts from parties other than the Responsible Entity that
identify the security patching process or vulnerability mitigation performed by the
party other than the Responsible Entity; evidence from change management
systems, electronic mail, system documentation or contracts that identifies
acceptance by the Responsible Entity that the practices of the party other thanthe Responsible Entity are acceptable; or documentation of other method(s) tomitigate software vulnerabilities for Transient Cyber Asset(s) managed by a party
other than the Responsible Entity. If a Transient Cyber Asset does not have thecapability to use method(s) that mitigate the risk from unpatched software,evidence may include documentation by the Responsible Entity or the party otherthan the Responsible Entity that identifies that the Transient Cyber Asset does nothave the capability.
Section 2.2: Examples of evidence for Section 2.2 may include, but are not limited to,
documentation from change management systems, electronic mail or proceduresthat document a review of the installed antivirus update level; memoranda,
electronic mail, system documentation, policies or contracts from the party otherthan the Responsible Entity that identify the antivirus update process, the use of
application whitelisting, use of live of operating systems or system hardening
performed by the party other than the Responsible Entity; evidence from change
management systems, electronic mail or contracts that identifies the Responsible
Entity’s acceptance that the practices of the party other than the Responsible
Entity are acceptable; or documentation of other method(s) to mitigate malicious
code for Transient Cyber Asset(s) managed by a party other than the Responsible
Entity. If a Transient Cyber Asset does not have the capability to use method(s)that mitigate the introduction of malicious code, evidence may include
documentation by the Responsible Entity or the party other than the Responsible
Entity that identifies that the Transient Cyber Asset does not have the capability.
Section 2.3: Examples of evidence for Section 2.3 may include, but are not limited to,
documentation from change management systems, electronic mail, or contracts
that identifies a review to determine whether additional mitigations arenecessary and that they have been implemented prior to connecting theTransient Cyber Asset managed by a party other than the Responsible Entity.
Section 3.1:

Examples of evidence for Section 3.1 may include, but are not limited to,
documentation from asset management systems, human resource management
systems, forms or spreadsheets that shows authorization of Removable Media.
The documentation must identify Removable Media, individually or by group of
Removable Media, along with the authorized users, either individually or bygroup or role, and the authorized locations, either individually or by group.

Section 3.2: Examples of evidence for Section 3.2 may include, but are not limited to,
documented process(es) of the method(s) used to mitigate malicious code suchas results of scan settings for Removable Media, or implementation of ondemand scanning. Documented process(es) for the method(s) used for mitigating

Page 31 of 32

CIP-010-4 – Cyber Security — Configuration Change Management and Vulnerability Assessments

the threat of detected malicious code on Removable Media, such as logs from themethod(s) used to detect malicious code that show the results of scanning andthat show mitigation of detected malicious code on Removable Media or
documented confirmation by the entity that the Removable Media was deemed
to be free of malicious code.

Page 32 of 32