A Risk-Informed Remediation Management Approach for NERC CIP Compliance

Articles

The Standard Drafting Team’s intent of Requirement R2 is to require entities to know, track, and mitigate the known software vulnerabilities associated with their BES Cyber Assets. It is not strictly an “install every security patch” requirement; the main intention is to “be aware of in a timely manner and manage all known vulnerabilities” requirement.
– CIP-007-6 Guidelines and Technical Basis

Abstract and Introduction

This paper addresses the shortcomings of existing patching requirements in the electric sector, emphasizing the frequent violations of CIP-007-6 R2 – which specifically addresses security patching – and the growing operational burden on organizations. Vulnerability remediation should be an ongoing process instead of a one-time solution, as threats continuously evolve and previously patched vulnerabilities can reappear. By transitioning to a risk-informed remediation approach, leveraging Stakeholder-Specific Vulnerability Categorization (SSVC) and the Cybersecurity Advisory Framework (CSAF) to enhance decision-making and operational security, organizations can prioritize vulnerabilities based on actual risk impact rather than relying on reactive, compliance-driven patching.

Problem Statement

Despite years of mandated security patching requirements in the electric sector, compliance with CIP-007-6 R2 remains one of the most frequently violated NERC standards. Organizations face significant operational burdens due to the growing complexity of cyber assets and the increasing volume of security patches, making traditional compliance-driven patching approaches unsustainable. Additionally, reactive patching fails to address evolving threats effectively, as vulnerabilities can resurface due to system changes, newly discovered exploits, or shifts in threat profiles. Without a risk-informed vulnerability management strategy that prioritizes remediation based on actual risk impact, organizations struggle to allocate resources efficiently, maintain operational stability, and achieve meaningful security improvements.

Background

Understanding CIP Compliance Security Patching

The CIP-007-6 cybersecurity standard, which became enforceable in 2016, requires utilities to install every security patch on applicable systems. Before this, an older version of the rule simply required companies to check for security updates every month and make a plan for fixing any issues. However, the Federal Energy Regulatory Commission determined this was too vague in its Order 706 and required the development of stricter deadlines for applying patches. NERC and the industry responded with standards providing 35 days from discovery to patch or mitigation decision-making.

The 2024 Mid-Year NERC report shows NERC CIP-007-6 R2 remains the most-violated of any NERC reliability standard [3]. The 2023 annual report shows CIP-007-6 is both the most violated standard in the sector and carries the highest number of violations having severe risk to the Bulk Power System [4].

What Utilities Must Do

To comply with CIP-007-6 R2, companies must follow these steps when dealing with security patches:

Identify a Patch Source – Organizations must choose a trusted source (such as their software vendor) for security patches. This marks the starting point for all deadlines.
Assess Patches Within 35 Days – When a patch is announced, companies have 35 calendar days to identify, review, and assess it. Since patches are released frequently, companies often conduct monthly reviews to stay compliant.
Decide Whether to Apply the Patch – During the assessment, the organization must either apply the patch within 35 days or create a mitigation plan.
Create a Mitigation Plan (if necessary) – If a patch cannot be applied, the company must develop a detailed plan showing how they will address the risk. This plan must be well-documented and justified.

A screen shot of a computer screenAI-generated content may be incorrect.

Figure 2: CIP-007 Security Patching Timeline

The Challenges of Compliance

The number of cybersecurity vulnerabilities and exposures (CVEs) have grown over 520% since 2016 , making it harder for companies to keep up with required patches. However, the CIP-007-6 R2 requirements remain strict, leaving utilities in a cycle of constant updates with little time for analysis on what vulnerabilities are potentially the most impactful to their security posture.

Figure 3: Snapshot from https://nvd.nist.gov/general/nvd-dashboard

While IT systems can use automated tools to patch software efficiently, industrial control systems require manual updates. This increases compliance workload and resource use.

Mitigation Plans – A Difficult Alternative

If a company cannot apply a patch, they must create a mitigation plan. A mitigation plan has the following requirements:

Address all vulnerabilities the patches fix.
Include a reasonable and justified deadline.
Outline additional steps to reduce risk.
Be approved by senior management for any deadline extensions.

However, creating mitigation plans is extremely difficult. A single patch might address multiple vulnerabilities, and auditors will scrutinize the plan to ensure all risks are covered. For large utilities managing hundreds or even thousands of vulnerabilities each month, this is nearly impossible to do manually.

While the necessary data exists to analyze vulnerabilities, the manual effort required to assess each data point and identify the appropriate mitigations far exceeds the available human resources of most entities. In contrast, patching the system requires only a single compliance record showing the patch was applied, with no comparable regulatory scrutiny applied to the decision-making process.

Because of this, most companies find it easier to simply apply patches. The CIP rules unintentionally encourage companies to patch everything rather than focusing on real security threats.

From Legacy Protections to Proactive Patching: The Evolution of CIP Mitigation Strategies

Many system vulnerabilities are not easily exploited by adversaries due to robust security measures such as multiple firewalls, VPNs, and anti-malware solutions that already reduce the risk posed by these flaws. However, the historical framework of the CIP standards has influenced how organizations develop their mitigation strategies and rely on existing defenses.

FERC’s Order 706 responded to observations that many entities were using firewall protection as their sole mitigation measure to delay or avoid patching. Previously, under earlier versions of the CIP standards, organizations could submit a single mitigation plan detailing existing protections for systems that could not be patched immediately. In contrast, the current standards under CIP-007-6 R2 emphasize the need for proactive measures that directly address the vulnerabilities each security patch is designed to remedy.

Despite this shift toward active mitigation, the guidelines do not preclude the use of existing defenses. The technical basis of CIP-007-6 acknowledges that mitigation plans can include both “actions to be taken” and measures that have “already been taken.” In fact, remediation plans that document previously implemented steps are considered complete once the documentation is finalized.

Understanding SSVC

Background

In 2019, experts at Carnegie Mellon University introduced a decision-tree framework to help organizations prioritize and manage cybersecurity threats. This system, called Stakeholder-Specific Vulnerability Categorization (SSVC), goes beyond traditional methods by not just giving a risk score but also suggesting what actions to take based on the specific situation of an organization.

In 2022, the U.S. government officially adopted SSVC to manage cybersecurity risks across its systems. The latest version, SSVC Version 2, is designed for three key groups:

Suppliers (Vendors) – Those who create and maintain software, responsible for fixing security flaws.
Coordinators (e.g., CERTs, ISACs) – Organizations that track vulnerabilities and help coordinate responses.
Deployers (End Users) – Companies and agencies that use the software and need to apply fixes or protections.

This document focuses on the deployer decision model and how end users should handle security threats in industries where critical infrastructure demands rapid, risk-based responses to emerging threats.

Decision Model

When a new cybersecurity vulnerability is discovered, organizations using SSVC classify it into one of four priority levels:

Defer – No immediate action is needed.
Scheduled – The fix can wait until the next regular maintenance period.
Out-of-Cycle – The fix should be done sooner than usual but in a controlled way.
Immediate – A critical threat that requires urgent action.

For example, an Immediate decision in an electric generation environment might involve assembling a rapid-response team to immediately address a severe vulnerability. A Scheduled decision is handled during a regularly scheduled plant outage. An Out-of-Cycle decision accelerates remediation while still allowing for normal change coordination and a Defer decision indicates that no prompt action is warranted under current risk conditions.

Decision Points and Criteria

To decide how serious a cybersecurity threat is, SSVC looks at key factors:

Decision Point

Possible Values

Description

Exploitation

None, Public Proof-of-Concept, Active

Whether exploits are known to exist, whether they are publicly demonstrated, and whether they are actively in use.

System Exposure

Small, Controlled, Open

The accessibility of the vulnerability over a network, ranging from minimal exposure to fully internet-facing.

Utility

Laborious, Efficient, Super Effective

Whether exploitation can be automated and how valuable that exploitation is in achieving an adversary’s objectives.

Human Impact

Low, Medium, High, Very High

Considers the potential consequences to safety and mission if the vulnerability is exploited.

‍

By combining these factors, organizations can determine the best course of action. For example, if a vulnerability is actively being exploited, easy to access, useful to hackers, and could cause major harm, it would likely require an Immediate response.

On the other hand, if a vulnerability is not being used by hackers, difficult to access, hard to exploit, and has minimal impact, then it would likely fall under Defer or Scheduled.

Why This Matters

Cyber threats are evolving rapidly, and organizations need a structured way to respond to them. SSVC helps decision-makers avoid guesswork by providing a clear, logical system to determine how urgent a cybersecurity issue really is and what action should be taken.

By following this approach, organizations can balance security with operational needs and ensure that they focus on the most serious threats first while minimizing unnecessary disruptions. This type of decision-making can help improve the efficiency of complying with NERC CIP standards by prioritizing remediation and generating evidence of a clear decision path.

Figure 1: Sample SSVC Deployer Decision Tree Outcomes

Understanding CSAF

Background

The Common Security Advisory Framework (CSAF) was developed to standardize the way security advisories are created, distributed, and processed. It originated from efforts by the OASIS Open CSAF Technical Committee, which sought to improve how organizations handle vulnerability disclosures.

CSAF builds upon the legacy Common Vulnerability Reporting Framework (CVRF) and enhances machine-readable advisories for better automation and integration into security workflows.

Why This Matters

CSAF provides a structured, machine-readable format (JSON-based) for publishing and consuming security advisories related to vulnerabilities, patches, and mitigations. By offering a standardized framework, CSAF enables:

Automation of vulnerability management: Organizations can programmatically ingest security advisories and take action quickly.
Improved coordination between vendors and users: Ensures that security updates are communicated consistently and efficiently.
Better risk assessment and response: Facilitates integration with vulnerability management tools, enhancing security decision-making.

CSAF helps cybersecurity teams stay ahead of threats by streamlining advisory distribution, improving clarity, and enabling automation with consistent formatting.

Understanding Software Vulnerabilities, Security Advisories, and Remediation

Software Vulnerabilities

In the software remediation ecosystem, it is essential to distinguish between software suppliers and deployers. Suppliers, whether commercial companies or open source projects, manage and distribute software packages, while deployers are the end users tasked with implementing and securely maintaining the software. A software vulnerability is any weakness in the code, configuration, or even in an external dependency that may be exploited. Vulnerabilities can originate in the supplier’s own code, in third-party dependencies, or through misconfigurations. Typically, these issues are identified through internal security assessments, bug bounty programs, or responsible disclosure. Once recognized, many vulnerabilities are cataloged in standardized resources like the National Vulnerability Database (NVD) via the Common Vulnerabilities and Exposures (CVE) framework, which helps deployers understand and mitigate potential risks.

Security Advisories

Effective communication between suppliers and deployers is critical for maintaining secure systems. Suppliers issue security advisories to report both discovered vulnerabilities and the associated remediation measures. These advisories are usually tied to specific software releases and often bundle multiple vulnerabilities into a single document. This comprehensive approach allows deployers to receive detailed instructions necessary for safeguarding their environments. In cases where vulnerabilities affect multiple products or hardware configurations, advisories may incorporate the Common Platform Enumerator (CPE) to help deployers align the information with their specific systems. Frameworks like the Common Security Advisory Framework (CSAF) supports these decisions by providing a standardized way to share information about one or more vulnerabilities in one or more products.

Remediation

Remediation in the software context involves more than just patching vulnerabilities. In many industrial environments, systems are purpose-built for critical operations, and the challenges associated with patching, such as scheduling downtime and conducting regression testing, can be significant. When vulnerability urgency outpaces standard product release cycles, deployers may need to adopt alternative remediation strategies. These can include workarounds that temporarily reduce risk, mitigations that lower exposure without fully resolving the issue, or vendor fixes delivered as patches or software upgrades. Although vendor fixes represent the most definitive remediation, workarounds and mitigations are often necessary until a complete solution is available. It is important to note that remediation does not automatically eliminate all risk. Changes in the operational environment or emerging threats may require vulnerabilities to remain under continuous review even after remediation steps are implemented.

Ultimately, effective automation in vulnerability and patch management should streamline the transition from identification to remediation, ensuring that deployers can rapidly and reliably secure their systems.

Responsibilities

Who’s Responsible for Fixing Software Issues?

In the world of software security, there are two key groups involved in fixing vulnerabilities:

Suppliers – These are the people or organizations that develop and maintain software. They can be commercial vendors (like Microsoft) or open-source projects.
Deployers – These are the end users or companies that use the software and are responsible for keeping it secure.

A software vulnerability is a weakness in a program’s code, settings, or even in third-party components it relies on. These weaknesses can be discovered in different ways—sometimes by the suppliers themselves through security checks, or externally through bug bounty programs and public vulnerability databases like the National Vulnerability Database (NVD).

Once a vulnerability is identified, suppliers share information about the issue through security advisories, which also explain how to fix the problem—usually by installing a software patch.

How Security Advisories Help Deployers

Security advisories provide essential details for deployers, often grouping multiple vulnerabilities into one document. This helps companies keep track of risks in their software environment. Suppliers may also use a standardized format, like the Common Security Advisory Framework (CSAF), to communicate vulnerabilities more efficiently.

For deployers, the goal is to understand what needs to be fixed and how to do it quickly. Some vulnerabilities might only affect certain versions of a product, so advisories often include a Common Platform Enumerator (CPE) to help match fixes to the right software or hardware.

Challenges

How Software Vulnerabilities Are Fixed

Most software has built-in update mechanisms to apply fixes, a process known as patch management. However, in industries like energy and manufacturing, where software runs critical infrastructure, patching isn’t always straightforward. These systems can’t afford unexpected downtime, and any changes must go through rigorous testing.

When urgent vulnerabilities arise but a patch isn’t immediately available, suppliers provide alternative solutions, known as remediation strategies. Remediation strategies in the CSAF may include:

Workarounds – Temporary changes to reduce risk until a patch is released.
Mitigations – Additional security measures that lower risk but don’t fully fix the issue.
Vendor Fixes – The best solution, usually in the form of a patch or software update.
No Fix Available – If a patch isn’t an option, deployers must find their own ways to reduce risk.

The Ongoing Battle of Vulnerability Management

Fixing a vulnerability doesn’t always mean the risk is gone forever. Workarounds and mitigations can become less effective over time as new threats emerge, and even patches can be undone by later updates. That’s why vulnerabilities need continuous monitoring, even after they are marked as "resolved."

To improve security, companies should invest in automation to speed up vulnerability detection and remediation—moving from identifying issues to actively fixing them as efficiently as possible.

‍

A New Approach to CIP-007 Patching

Bastazo’s implementation of Stakeholder-Specific Vulnerability Categorization (SSVC) automatically processes new vulnerabilities and determines optimal remediation actions aligned with CIP-007-6 R2 requirements. These actions include either:

Applying a patch within the required timeframe, or
Establishing a dated mitigation plan if immediate patching is not feasible.

Since SSVC is a vulnerability-driven model, assessments begin by analyzing vulnerabilities rather than security patches. The final output maps each vulnerability to its corresponding remediation action. If a single remediation action addresses multiple vulnerabilities, the highest-priority vulnerability with the earliest deadline dictates the overall work decision.

Key Decision Points in SSVC Deployer Model

To determine appropriate remediation actions, SSVC relies on several key decision points:

Exploitation – Has the system been exploited? Assumes that any known PoC could be used by adversaries, even if it has not yet been publicly reported.
System Exposure – How much of our system would an attack affect? Determines exposure at the asset, asset-group, or system level.
Utility (Automatable Attack Feasibility) – How vulnerable is the system? Measures how easily an attacker can automate exploitation of targeted assets. This metric depends on two main factors. First, vulnerability automatability is determined using CVSS metrics by assessing whether exploitation requires user interaction, delivers a high integrity impact (such as arbitrary code execution), requires remote network access, and avoids the need for elevated privileges. Second, asset exploit value reflects how effectively an exploited vulnerability can provide adversaries with further access into the network. Based on these factors, vulnerabilities are classified into three categories. Laborious vulnerabilities are not easily automated and offer minimal exploit value. Efficient vulnerabilities are either easily automated or involve high exploit value, while Super Effective vulnerabilities are both automatable and linked to high exploit value. For example, a privilege escalation vulnerability requiring user interaction is considered lower utility, whereas a remote code execution vulnerability that requires no user interaction on an engineering workstation is deemed high utility.
Human Impact (Mission Impact Assessment) – What impact would an attack have? Evaluates the potential severity of a vulnerability by examining its effects on Confidentiality, Integrity, and Availability (CIA). It considers the vulnerability’s CVSS impact scores, adversary intent and expected CIA effects, and the organizational impact at both the system and asset levels. The final mission impact score is calculated by taking the minimum impact for each CIA factor and then using the highest of these values.

SSVC Remediation Actions and CIP-007 R2 Work Plans

After evaluating these decision points, SSVC generates remediation actions mapped to CIP-007-6 R2 compliance requirements.

SSVC Outcome

Work Plan

CIP Compliance

Defer

Risk Monitoring Plan

A CIP-007 R2.3 mitigation plan describing the deferment strategy based on the threat, vulnerability, and environment. The risk monitoring plan is part of the ongoing mitigation.

Scheduled

Remediation Plan

Includes patching within 35 calendar days (no signed mitigation plan needed) or alternative mitigations (workarounds, containment, compensating controls).

Out-of-Cycle

Accelerated Remediation Plan

Occurs within the 35-calendar-day cycle.

Immediate

Remediation Response

An alert response to apply remediation. There is no immediate response required for CIP and compliance documentation would treat this as a normal patch application or mitigation plan.

‍

Figure 6: Moving from SSVC decision output to NERC CIP-compliant work plan

Work Plans for Vulnerability Management

Building on the SSVC decision model, the vulnerability management strategy is articulated through four distinct work plans that ensure appropriate action.

Risk Monitoring Plan: Under this approach, CIP-007-6 R2.3 mitigation plans incorporate a monthly risk monitoring plan for vulnerabilities in the Defer category. In this specialized plan, threat, organizational, and vulnerability characteristics are reviewed at least once every 35 days. If any shift alters the SSVC decision, the risk monitoring plan ensures the vulnerabilities are promptly reevaluated.
Remediation Plan: Remediation may involve patching or applying alternative mitigation measures (e.g., workarounds or compensating controls). When patching is chosen, the standard 35-day CIP patching window applies. For non-patch mitigations, the necessary actions are added to a monthly cumulative mitigation plan, which can be approved in bulk by the CIP Senior Manager. This reduces the number of required signatures to one monthly plan for risk monitoring and one monthly plan for cumulative mitigations.
Accelerated Remediation Plan: Remediation in these plans should happen within the monthly work cycle. This is very similar to the remediation plan for CIP compliance purposes, but the actions are prioritized higher.
Remediation Response: This is critical to a risk-informed vulnerability management program. It ensures that the relatively small number of vulnerabilities requiring urgent action are addressed promptly. While these methods fulfill CIP patching requirements, they also expedite critical risk remediation.

Conclusion

The increasing complexity of vulnerability management requires a fundamental shift from compliance-driven patching to strategic, risk-based remediation. By leveraging SSVC and CSAF, organizations can transition from a reactive patching cycle to a proactive, informed risk management framework—ultimately improving cyber resilience, compliance performance, and operational efficiency.

This approach ensures that security teams focus their efforts where they matter most, namely mitigating the highest risks while maintaining system stability and compliance.

By integrating risk-informed vulnerability management with automated patch tracking and mitigation planning, organizations can:

Ensure full compliance with CIP-007-6 R2 requirements.
Streamline patching workflows using automated decision-making.
Prioritize vulnerabilities based on exploitation risk, system exposure, and mission impact.
Provide clear, auditable compliance evidence to regulators.

This structured approach enables organizations to maintain both regulatory compliance and strong cybersecurity resilience.