Which vulnerability assessment tools satisfy CIP-010 R3?
No tool satisfies CIP-010 R3 by itself. The registered entity owns the vulnerability assessment, its scope, its results and its action plan, and a scanner only produces inputs that the entity reviews, documents and acts on. An auditor will ask who decided the scope, who reviewed the findings and what was done about them, so a scan report on its own is not evidence of R3 compliance. The tooling need follows from four obligations in CIP-010-4. Part 3.1 requires a paper or active vulnerability assessment at least once every 15 calendar months for high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. Part 3.2 adds an active assessment at least once every 36 calendar months for high impact systems where technically feasible, run in a test environment that models the production baseline or in production in a way that minimizes adverse effects, with differences documented. Part 3.3 requires an active assessment of a new applicable Cyber Asset before it joins a high impact production environment, subject to CIP Exceptional Circumstances and like-for-like replacements. Part 3.4 requires documented results and an action plan with a planned completion date and execution status.
Each obligation changes what a tool must do. A paper assessment can be built from software inventory and vendor advisories, which is where a host-level inventory tool such as Wazuh's vulnerability detection feature can supply input, provided the entity confirms it covers the operating systems and applications in scope. An active assessment needs a scan engine, such as the OpenVAS scanner in Greenbone Community Edition, but the free Greenbone Community Feed excludes tests for enterprise products, so the entity should confirm whether its own products are covered before relying on that scan. Pre-production testing under Part 3.3 requires a staging environment that reflects the baseline. Check whether TFE eligibility in NERC's March 2021 list applies to CIP-010 R3 Part 3.2 before planning any exception, and confirm with the Regional Entity how it will be applied to your systems.
Paper or active assessment: how to choose for each asset group
Where a high impact BES Cyber System, with its associated EACMS, PACS and PCA, can tolerate active scanning, the entity should plan an active vulnerability assessment at least once every 36 calendar months under Part 3.2, in addition to the 15-month paper or active assessment required by Part 3.1. The scan may run in a test environment that models the production baseline, or in production if it is run in a way that minimizes adverse effects. Either way, the entity must document the differences between test and production, because the auditor will compare the scan scope against the baseline.
- Scope the baseline: Record which assets, operating systems and applications the scan covers and match them to the CIP-010 baseline configuration.
- Document test and production differences: List every gap, such as missing agents, different network paths or unlike hardware, and state how each gap affects the results.
- Keep scan configuration records: Retain scanner version, feed date, credentials used and scan targets so the run can be reproduced.
- Feed the action plan: Each finding that is not closed moves into the Part 3.4 action plan with a planned completion date and status.
Before scheduling any active scan, confirm with the operations team and the vendor that the target systems can tolerate the load and that a rollback path exists.
Some high impact systems cannot be actively scanned without unacceptable operational risk, for example fragile control system hardware or devices that cannot accept network probes. For these, the 36-month active assessment in Part 3.2 applies only where it is technically feasible, and the entity's documented judgment on feasibility is what the auditor reviews. The 15-month paper or active assessment in Part 3.1 still applies, so the team typically relies on a paper assessment built from inventory, vendor advisories and configuration data for these assets.
- Record the feasibility decision: Write down why active testing is not feasible, who approved the decision and when it was last reviewed.
- Use paper assessments on a 15-month cycle: Compare the asset inventory and software versions against current vulnerability sources and record the results.
- Consider a Technical Feasibility Exception: Where the requirement cannot be met as written, check whether the item is on NERC's TFE eligibility list, which covers CIP-010 R3 Part 3.2, and follow the TFE process if so.
- Use passive or agent-based evidence: Where agents or passive monitoring are approved for the environment, use their output as supporting data for the paper assessment.
Confirm with your Regional Entity and internal compliance team how they expect feasibility decisions to be documented before relying on them.
For medium impact BES Cyber Systems and their associated EACMS, PACS and PCA, Part 3.1 requires a paper or active vulnerability assessment at least once every 15 calendar months. The 36-month active assessment in Part 3.2 is written for high impact systems, so it does not drive the medium impact cycle. The entity chooses the method, and many choose paper assessments for the bulk of the fleet and active scans only where they are safe and useful.
- Pick the method per asset class: Decide which asset types get paper assessments, which get active scans and why, and record the decision.
- Cover associated systems: EACMS, PACS and PCA are in scope, so include access control servers and their supporting hosts in the assessment, not only the control devices.
- Track the 15-month clock: Store the date of each completed assessment so the next due date is visible to the CIP Senior Manager.
- Document results and action plans: Record findings, the action plan under Part 3.4, and the execution status for each item.
Ask your auditor or Regional Entity how they expect paper assessments to be evidenced, since the standard leaves the content of a paper assessment to the entity.
Part 3.3 requires an active vulnerability assessment of a new applicable Cyber Asset before it is added to a high impact production environment. The standard makes exceptions for CIP Exceptional Circumstances and for like-for-like replacements that model an existing baseline. This rule is about pre-production testing, so it applies to new hardware or software introduced to high impact systems, not to the regular 15-month cycle.
- Test before connection: Run the active assessment in a test environment or staging network before the asset joins production.
- Compare to the baseline: Confirm that a like-for-like replacement matches the existing baseline before using the replacement exception.
- Record exceptions carefully: If the exception applies, document the reason and the baseline comparison, since an unsupported exception claim is a finding.
- Include the result in the change record: Link the assessment output to the change ticket that adds the asset, so the evidence trail is complete.
Confirm with compliance staff whether a given asset counts as new or as a like-for-like replacement, because that judgment determines whether the pre-production test is required.
What open-source scanners cover and miss for R3
Open-source scanners can produce part of the evidence CIP-010 R3 asks for, but each one sees a different slice of the asset list. The cards below separate what Greenbone Community Edition and Wazuh can scan from what they leave to other methods, so the assessment plan can be checked against the inventory before the next cycle starts.
Greenbone Community Edition as scan engine
Greenbone Community Edition runs the OpenVAS Scanner, which executes vulnerability tests from the daily updated Greenbone Community Feed against target systems, with gvmd controlling scans over the Open Scanner Protocol. For R3 Part 3.1 and Part 3.2 active assessments, the scan engine produces the raw results, but the team still has to document scope, credentials, scan windows and any test environment differences. Confirm each scan target is reachable and authenticated, because unauthenticated scans often miss installed software.
Community Feed excludes enterprise product tests
The free Greenbone Community Feed does not include vulnerability tests for enterprise products, which are only in the paid Greenbone Enterprise Feed. If your high or medium impact Cyber Assets run commercial enterprise software, the Community Feed may return no finding for those products even when a vulnerability is published. Ask the vendor which products are covered in each feed and record that limit in the assessment methodology so an auditor does not read a clean result as proof of absence.
Wazuh inventory-based vulnerability detection
Wazuh vulnerability detection correlates the software inventory collected by each agent with the Wazuh CTI vulnerability repository, or a locally hosted offline copy, to identify weaknesses in the operating system and installed applications of monitored endpoints. This is a paper-style assessment based on inventory, so it can support the 15-month paper assessment path for endpoints where an agent is installed. Confirm agent deployment coverage against the asset list, and decide whether the offline copy is needed for systems without outbound connectivity.
Network devices and firewalls
Scanners that rely on agents or authenticated host access may not inventory network devices, firewalls, switches and routers, and those devices are often in scope as Protected Cyber Assets or EACMS. Vendor-specific firmware versions frequently need manual lookup against vendor advisories. Plan a separate method for these assets, such as vendor advisory reviews, configuration exports or a commercial scanner, and confirm which asset types your tools actually identify.
OT firmware, embedded controllers and gaps
Programmable logic controllers, relays, human-machine interface devices and other embedded controllers often run firmware that generic scanners cannot fingerprint or safely probe. Active scanning of these devices can disrupt operations, so many programs use passive methods, vendor-supplied assessments or the TFE and testing approaches described elsewhere in this pillar. Confirm with each vendor what they support, and record in the action plan how each unscannable device is assessed and when.
When a TFE can apply to CIP-010 R3 Part 3.2
A Technical Feasibility Exception (TFE) can only be considered for CIP-010 R3 Part 3.2 if the requirement is on NERC's eligibility list, and it is. NERC's March 2021 list of CIP standards eligible for TFEs includes CIP-010 R3 Part 3.2, alongside parts of CIP-005, CIP-006 and CIP-007 and CIP-010 R1 Part 1.5. Eligibility is only the start. A TFE is a formal exception that a Regional Entity or the Compliance Enforcement Authority reviews for a specific system. It does not replace the vulnerability assessment, and an entity that stops running active assessments without an approved exception is exposed to the same violation risk as any other missed requirement. Confirm the current list directly from the NERC TFE eligibility list before you rely on it, since the list dates from 2021.
Where a high impact system cannot take an active scan in a test environment or in production without adverse effects, the entity must document why the active test is not technically feasible for that asset and what compensating measures reduce the risk in the meantime. Compensating measures for a vulnerability assessment usually mean more frequent paper assessments, tighter access restrictions and monitoring of the asset, and documented vendor patch review. The record should name each affected BES Cyber System and its associated Cyber Assets, the technical reason, the measures, and who approved them. Your open-source scanner output can support the paper assessment, but it does not prove feasibility. Keep the feasibility analysis separate from scanner logs.
Acceptance is not a decision the tool vendor or your scanning team makes. The Regional Entity or the compliance reviewer decides whether an exception is accepted, and an independent reviewer should check the technical justification before it is submitted. For future planning, confirm how the TFE approach changes. NERC's CIP changes for 2026 to 2029 replace TFEs with a per system capability approach, and CIP-015 adds internal network security monitoring with its own timing. Ask your compliance lead and the Regional Entity which of these changes affect your systems before you design long-term scanning or exception processes around TFEs.
Running the R3 cycle from scoping to action plan
The sequence turns CIP-010 R3 from a calendar obligation into a traceable record: which assets were assessed, how, when, what was found, and what is being done about it. Each step hands a defined output to the next, so an auditor can follow one asset from its categorization to its closed action plan item.
Confirm Applicable Systems from the CIP-002 categorization
Start from the current CIP-002 categorization and pull the list of high and medium impact BES Cyber Systems, along with their associated EACMS, PACS and Protected Cyber Assets. The compliance lead confirms this list with operations and the CIP Senior Manager, because R3 applies to these systems and not to the rest of the estate. The output is a dated asset inventory that names each system, its impact rating and its associated Cyber Assets. The step is complete when every asset in that inventory has an owner and a rating that matches the categorization record.
Select the assessment method for each asset
For each asset in the inventory, decide whether a paper assessment or an active assessment will satisfy the 15-month requirement. Paper assessments review known vulnerabilities against the documented baseline without touching the device, while active assessments run scans or tests against it. High impact systems also need a decision on whether the 36-month active assessment is technically feasible. The output is a method register that records the chosen method and the reason for each asset. Confirm with the Regional Entity or your own counsel where the choice is unclear.
Run paper or active assessments on the 15-month cycle
Run the selected assessment for each asset within the 15 calendar month interval, using scanners or manual review as the method requires. Open-source scanners such as OpenVAS and Wazuh can support active or inventory-based work, but their coverage gaps must be recorded and compensated for by other means. The output is a dated assessment report per asset that lists the scope, tool versions, feed or database dates, and findings. Check each report against the asset inventory to confirm nothing was skipped.
Run the 36-month high impact active assessment or document infeasibility
For high impact BES Cyber Systems, run an active vulnerability assessment at least once every 36 calendar months, either in a test environment that models the production baseline or in production with methods that minimize adverse effects. Record every difference between the test and production environments. Where the assessment is not technically feasible, document the reason and the alternative approach, and check whether a Technical Feasibility Exception applies to CIP-010 R3 Part 3.2 under the NERC eligibility list. The output is either a dated active assessment report with the environment documented, or a feasibility record approved by the CIP Senior Manager.
Assess new Cyber Assets before production use
Before a new applicable Cyber Asset is added to a high impact production environment, run an active vulnerability assessment on it. Like-for-like replacements that model an existing baseline and CIP Exceptional Circumstances are the only exceptions, so change control should flag every new asset before it is connected. The output is a pre-production assessment record linked to the change ticket. Confirm the test is complete before the asset is approved for production, because an assessment performed afterward does not meet Part 3.3.
Record assessment results and document the action plan
Consolidate the findings from each assessment into a results record that names each vulnerability, its affected asset and its severity as reported by the tool or the reviewer. For each finding, write an action plan that states the remediation or mitigation approach, the planned completion date and the current execution status. The output is a results register and a single action plan that an auditor can read without the scanner output. Review false positives and accepted risks with the CIP Senior Manager or delegate, and record the reasoning for each one.
Track the action plan to documented completion
Update the action plan as each item moves from planned to in progress to complete, and attach evidence of the fix or mitigation, such as a change record, a re-scan or a configuration baseline update. Carry any open items into the next assessment cycle so the register reflects reality at each review. The output is an action plan with an audit trail for every item, including items that were extended or closed as not applicable. The step is complete when each finding has either verified remediation or a documented mitigation with a named owner.
What must be in place before an R3 audit
An auditor testing CIP-010 R3 starts by checking whether your scope, method, records and remediation trail agree with each other. The five items below are the artifacts that tie those pieces together, and each one can be checked against your own environment before a Regional Entity asks for it.
Applicable Systems list tied to CIP-002
Start from your CIP-002 categorization. R3 applies to high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA, so the list must follow from the impact ratings, not from whatever inventory the team happens to maintain. Check that every asset on the list traces to a BES Cyber System and a rating, and that a newly added asset appears on the list before it goes into service. Ask whether any low impact asset was excluded for a reason you can document.
Documented assessment method per asset
For each Applicable System, your records should state whether the assessment is paper or active and why. Paper assessments review documentation and configuration evidence, while active assessments send traffic or run tests against the asset. Check that the method is recorded per asset or per asset group, that the choice matches the 15-month and 36-month cycles, and that any high impact asset with an active assessment cycle is covered by a documented plan.
Dated assessment records with reviewer sign-off
Each assessment needs a record showing when it ran, who performed it, which assets were covered and what the results were. Auditors look for a named reviewer who signed off on the results, because an unreviewed scan report is weak evidence. Check that the scanner output, the reviewer's sign-off and the asset list refer to the same date range and the same asset identifiers, and that no assessment cycle has lapsed past 15 calendar months.
Action plan with planned dates
Every finding needs an action plan entry. Part 3.4 requires documented results and a plan to remediate or mitigate each vulnerability, including a planned completion date and the current execution status. Check that each open finding has an owner, a planned date, and a status that is updated when work is done or when a mitigation replaces a fix. Entries with no date or with a date that has already passed without an update are the most common gaps in review.
Test and production differences documented
Where you use the 36-month active assessment in a test environment, the test model must reflect the production baseline. Document every known difference between the two, such as software versions, network paths or security tooling that exists in one environment only. Confirm that the baseline used for the test matches the current production configuration at the time of the assessment, and that the differences list is updated whenever the baseline changes.
Common questions about CIP-010 R3 tooling
Does an open-source scanner alone meet CIP-010 R3?
No. A scanner produces the raw evidence for Part 3.1 or Part 3.2, but R3 also requires the assessment to be documented, an action plan with a planned completion date and execution status under Part 3.4, and a process that the entity follows on its stated cycle. The entity owns the program, the scope decisions and the remediation records. Greenbone Community Edition runs the OpenVAS engine with the free Greenbone Community Feed, which excludes vulnerability tests for enterprise products, so confirm whether your installed products are covered before relying on a scan report. Wazuh vulnerability detection correlates agent software inventory with a vulnerability repository, which helps with operating system and application coverage but is not an active assessment of network devices or embedded controllers. Ask your compliance lead to map each in-scope asset type to a tool and a documented method.
Is a paper vulnerability assessment enough for medium impact systems?
Often yes for the 15-month requirement, because Part 3.1 allows a paper or active assessment at least once every 15 calendar months for high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. The 36-month active assessment in Part 3.2 applies to high impact systems where technically feasible, so medium impact entities do not face that cycle in the same form. A paper assessment still has to be complete, repeatable and tied to current asset and software inventories, and it still feeds the action plan under Part 3.4. Confirm the exact applicability against your CIP-002 categorization and the current standard text with your Regional Entity or a qualified advisor before deciding the method for each system.
What must the 36-month test environment model?
Part 3.2 asks for an active assessment in a test environment that models the production baseline, or in production in a manner that minimizes adverse effects. The entity must document any differences between the test and production environments. Practically, the test environment should match the baseline configuration, software versions, patch levels, network paths and access controls that the scan is meant to represent, because a clean lab can miss vulnerabilities that exist only in the live configuration. Record each known difference, such as a missing vendor service or a different firmware revision, and explain how it could change the results. Ask your engineers to compare the test baseline against the CIP-010 baseline records before the scan starts.
Can a Technical Feasibility Exception cover active scanning?
A TFE can only cover what NERC's eligibility list names. That list, dated March 2021, includes CIP-010 R3 Part 3.2, which is the active assessment on the 36-month cycle, so it is the part of R3 where an exception may be available. It does not cover Part 3.1, and it does not remove the documentation or action plan duties. Eligibility alone is not approval: an entity must show the technical infeasibility, file it through the process NERC and the Regional Entity set, and implement any required compensating measures. Confirm with your Regional Entity whether a TFE is the right route and whether the current list and procedures still apply, because CIP changes are scheduled through 2029.
What does an implementation partner do, and what stays with our staff?
A partner such as DeployOpen can plan the scan architecture, install and harden the scanner and inventory tools inside your environment, set up test environments, configure scan policies and schedules, and document how each tool produces evidence. The entity keeps ownership of the CIP program. Its staff decide the applicable systems, approve scope, classify findings, own the action plan and its completion dates, approve risk acceptances, and sign off on any TFE request. Only an independent auditor or the Compliance Enforcement Authority assesses compliance; DeployOpen does not issue audit reports or certifications. Ask any partner for a written scope that lists which tasks they perform and which your staff must complete.
What will the auditor review for R3?
The auditor will typically ask for the list of applicable assets, the assessment method used for each cycle, the dated assessment results, the documented differences between test and production where a test environment was used, and the action plan showing planned completion dates and execution status. They will also check that the 15-month and 36-month intervals were met and that new Cyber Assets were assessed before entering high impact production, except where a permitted exception applies. Retain raw scan outputs, scan configuration, versions of feeds and signatures, and records of the people who reviewed findings. Confirm the evidence list with your Regional Entity's current guidance before each audit period.
Who owns the assessment and who prepares the evidence
The registered entity owns CIP-010 R3. Its CIP Senior Manager or delegate decides which assessment method applies to each in-scope asset, approves the scope and the test environment used for any active assessment under Part 3.2, decides how results are interpreted, and signs off the action plan that Part 3.4 requires, including the planned completion date and execution status. An implementation partner can install and configure the scanner, set scan schedules against the 15-month and 36-month cycles, document the scan settings and prepare evidence packages such as scan reports, scope lists and remediation tracking exports. The partner does not decide whether a finding is acceptable, and it does not declare the entity compliant. A tool vendor or open-source project supplies software and documentation, not compliance conclusions.
The Regional Entity or its audit team reviews the evidence during a Compliance Audit, Spot Check or other monitoring engagement, and it is the only party that issues findings. Before any engagement starts, the entity should write down who performs each step, who signs each record and where the evidence is kept. Ask the partner to state in the written scope which deliverables are configuration documents, which are scan outputs and which are judgments that remain with the entity. Confirm with your Regional Entity how it expects paper assessments and active assessments to be documented, since the review approach is set by the Regional Entity and not by the standard alone. Keep signed records of scope decisions and TFE requests, because the reviewer will ask who made each call.
How DeployOpen prepares R3 evidence
DeployOpen plans, implements and documents self-hosted open-source vulnerability assessment tooling inside your own infrastructure, so the assessment records CIP-010 R3 asks for can be produced from your systems. Your organization owns the assessment program and its decisions, and an independent auditor or Regional Entity reviews the evidence.
How we scope
- Engagements are fixed-scope, with the BES Cyber Systems, EACMS, PACS and PCA covered by the assessments agreed in writing before work starts.
- Scope records which assets run paper assessments on the 15-month cycle and which high impact assets need active assessments on the 36-month cycle.
- Scope also sets how new Cyber Assets are assessed before they join a high impact production environment under Part 3.3.
How we build
- We configure scan engines, feeds and offline vulnerability data so that results can be tied to named asset baselines and assessment dates.
- We set up test environments that model the production baseline, and document each difference from production where Part 3.2 applies.
- We document where open-source coverage stops, such as feed limits on enterprise products, so gaps are visible before an assessment is recorded.
How we hand over
- Deliverables include assessment procedures, scan configuration records and templates for results and the Part 3.4 action plan with planned completion dates.
- Handover covers an operator runbook so your staff can repeat the assessment cycle and keep the evidence trail consistent.
- Confirm with your auditor or Regional Entity which evidence formats they accept before the handover is accepted.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- Retainers can cover feed and scanner updates, re-running assessments after scope changes, and reviewing action plan status between cycles.
- DeployOpen prepares systems and evidence only. It does not issue audit reports, attestations or certifications.
