What CIP-010-4 R3 asks for and why assessments go wrong
CIP-010-4 R3 requires a registered entity to assess its high and medium impact BES Cyber Systems for vulnerabilities on a fixed cadence, to assess new Cyber Assets before they go into a high impact production environment, and to document what the assessment found and what will be done about it. If you are the compliance lead preparing for a Regional Entity audit, the four parts to prove are: a paper or active vulnerability assessment at least every 15 calendar months (Part 3.1) for high and medium impact systems and their associated EACMS, PACS and PCA; an active assessment at least every 36 calendar months for high impact systems where technically feasible (Part 3.2); an active assessment of a new applicable Cyber Asset before it is added to a high impact production environment, subject to the exceptions in the standard (Part 3.3); and a documented action plan with a planned completion date and execution status for every identified vulnerability (Part 3.4). Confirm the exact applicability and exception language in the standard itself before you build your register.
The risk behind R3 is simple: a known weakness in an operating system, application or firmware that an attacker can reach from a compromised path. Assessments fail in practice for predictable reasons. Teams run a scanner on a schedule but never record which systems were in scope, so the auditor cannot tie results to the EACMS, PACS and PCA that the table requires. Scan output stays in a tool and is never turned into an owned action item, so Part 3.4 has no trail. Duplicate findings from several tools inflate the backlog until nobody triages it. Scans run in production without a documented way to minimize adverse effects, and the team cannot show what differs from the test environment used for the active assessment in Part 3.2.
A workable starting point is a single inventory of applicable Cyber Assets linked to each assessment record, a dated assessment report per cycle, and a remediation register where each finding has an owner, a planned completion date, and a status that changes over time. Ask your assessment vendor or integrator to show how a finding moves from detection to closure with an audit trail, and confirm which parts of the assessment your staff will perform versus a service provider. Open-source tooling such as Wazuh, Fleet, DefectDojo and Greenbone can produce scan records and deduplicated findings, but the controls, scoping decisions and sign-off remain the entity's responsibility. Confirm each tool's capabilities and license terms in your own environment before relying on it as evidence.
Which systems and Cyber Assets CIP-010-4 R3 covers
CIP-010-4 R3 applies by impact rating, not by device type alone. The cards below follow the order most entities work through scope: classify under CIP-002 first, then identify the associated systems and the Cyber Assets that enter the environment later.
Start with CIP-002 categorization
Every scoping decision under R3 depends on the impact rating CIP-002 assigns to each BES Cyber System. Under CIP-002-5.1a, the bright-line criteria in Attachment 1 sort systems into high, medium and low impact. R3 Part 3.1 reaches only high and medium impact systems, so a system rated low impact falls outside this requirement unless another standard applies. Check the categorization record before scoping any vulnerability work, and confirm that it still matches the current asset list.
Associated EACMS, PACS and PCA
R3 Part 3.1 extends beyond the BES Cyber Systems themselves to their associated Electronic Access Control or Monitoring Systems, Physical Access Control Systems and Protected Cyber Assets. Many entities scope only the operational control system and miss the jump servers, access gateways, badge controllers and engineering workstations that support it. Build a written inventory that maps each associated system to its parent BES Cyber System, because an assessor will test that mapping.
Where the 36-month active assessment applies
The active assessment every 36 calendar months under Part 3.2 applies only to high impact BES Cyber Systems, and only where it is technically feasible. Medium impact systems follow the 15-month paper or active cycle. Where an active assessment is not technically feasible, record the reason and the alternative approach. Confirm the feasibility decision for each high impact system, and document any differences between the test environment and production.
New Cyber Assets before production
Part 3.3 requires an active vulnerability assessment of a new applicable Cyber Asset before it joins a high impact production environment. The rule covers new hardware and software additions, and it is not triggered by changes that do not add an asset. Exceptions exist for CIP Exceptional Circumstances and for like-for-like replacements that model an existing baseline. Ask who decides whether a replacement qualifies, and keep that decision in the change record.
Cyber Assets that change scope
Scope moves when systems are reclassified, reused, virtualized or retired. A device promoted from a low impact asset to a medium impact system, or a PCA added during a control system upgrade, enters R3 the day it is in scope. Tie inventory updates to the change management process so that reclassification triggers a scope review. Assessors often find gaps where a new asset was installed through a maintenance ticket that never reached the CIP inventory.
Scope evidence an assessor will request
Auditors test scope before they test assessment quality. Expect requests for the CIP-002 categorization list, the mapping of associated systems, the feasibility decision for high impact active assessments, and the timestamped record of new asset assessments. Assemble these records as one scope package and review it after every CIP-002 update. Confirm the retention and naming conventions for these records with your Regional Entity before an audit notice arrives.
How an assessor tests R3 and what findings are common
This table compares each part of CIP-010-4 R3 (3.1 through 3.4) by how an auditor samples it, the evidence usually requested and the findings that appear most often. Read each row as a checklist of what to have ready before a Compliance Audit or Spot Check, since the assessor will select dates and records from the audit period rather than accept a summary.
| Part | What the assessor samples | Evidence requested | Common findings |
|---|---|---|---|
| Part 3.1 (paper or active assessment every 15 calendar months) | Assessment dates for each high and medium impact system, compared against the 15-month interval from the prior assessment | Dated assessment records covering high and medium impact BES Cyber Systems and associated EACMS, PACS and PCA | Gaps where one system was assessed on a different cycle, or where associated EACMS, PACS or PCA were left out of scope |
| Part 3.2 (active assessment every 36 months, high impact, where technically feasible) | Whether an active assessment occurred within the 36-month window and whether the environment was a test model or production with minimized effects | Test environment description, baseline comparison, and a documented list of differences from production | No record of why technical feasibility was limited, or a test environment that no longer matches the production baseline |
| Part 3.3 (assessment of new Cyber Assets before production) | Recent additions to high impact environments, with the pre-production assessment that preceded each one | Pre-production assessment records linked to change tickets, or documented CIP Exceptional Circumstances or like-for-like replacement reasoning | Assets placed into production before assessment, with no record linking the assessment to the change |
| Part 3.4 (documented results and action plan) | Assessment results and the matching action plan for each finding, including planned completion dates and status | Results report, remediation or mitigation plan, planned completion date and current execution status for each item | Plans without completion dates, overdue items with no status update, or findings that never reached an action plan |
| Cross-part consistency | Whether the inventory used for assessments matches the list of applicable systems in CIP-002 categorization | Current asset inventory, scope list and assessment scope statement dated to the audit period | Assessment scope drawn from an outdated inventory, so newly added assets were never assessed |
| Tool output | Whether scanner or agent results are complete, dated and traceable to the assessed systems | Exported scan reports, scan task schedules and the tool's record of users and permissions | Reports without dates or scope, or scans that ran against a subset of assets without a documented reason |
How to implement the R3 assessment cycle
This sequence turns CIP-010-4 R3 into a repeatable routine: a scoped asset list, the right assessment method for each asset, dated calendars for the 15-month and 36-month cycles, a gate for new Cyber Assets, and a documented remediation record that an auditor can follow from finding to closure.
Confirm the in-scope asset list
Start from the current CIP-002 categorization and list every high and medium impact BES Cyber System, along with its associated EACMS, PACS and Protected Cyber Assets. Name an owner for each system and record the Applicable Systems that R3 covers. Confirm the list with operations and the CIP Senior Manager. This step is done when each asset has a documented owner, impact rating and assessment scope, and the list is dated and version-controlled so an auditor can see what was in scope on any given day.
Select paper or active methods per asset
For each in-scope asset, decide whether a paper assessment (a review of documented configuration, patch and port data against known vulnerabilities) or an active assessment (scanning or testing against the live or test system) fits its risk and operating constraints. Confirm with the asset owner whether an active assessment is safe in production. Where high impact systems are involved, plan where an active assessment is technically feasible and where a test environment that models the production baseline is needed. Record the method and the reason for each choice in the assessment plan.
Set the 15-month and 36-month calendars
Build a calendar that tracks the Part 3.1 deadline of at least once every 15 calendar months for all high and medium impact systems, and the Part 3.2 active assessment of high impact systems at least once every 36 calendar months where technically feasible. Assign each date to a named owner and set reminders well before the due date. The output is a calendar with the last completion date, next due date and assessment type for every asset, reviewed at least quarterly by the compliance lead.
Build the pre-production assessment gate
Create a gate that a new applicable Cyber Asset must pass before it joins a high impact production environment under Part 3.3. The gate requires an active vulnerability assessment, a record of its result, and sign-off from the system owner and compliance lead. Define the exceptions that apply, such as CIP Exceptional Circumstances and like-for-like replacements that model an existing baseline, and require a written justification for each one. Done means the change ticket cannot close without a linked assessment record or a documented exception.
Run the assessments and capture raw results
Execute the planned paper and active assessments according to the plan and calendar. For active work, store scanner or tool output with the asset identifier, date, tool version and the configuration used. Where a test environment stands in for production, record each known difference between the two. Tools such as Greenbone Community Edition, Wazuh vulnerability detection or Fleet can produce this output, but the organization must confirm each tool's coverage for its own operating systems and applications. The output is a dated raw result set for each asset.
Document results and findings
Review the raw output, remove duplicate findings and separate confirmed vulnerabilities from false positives with a short written reason for each. A findings tracker such as DefectDojo can deduplicate results from several tools and keep the history. Have a qualified reviewer sign off on the consolidated results. The step is complete when each asset has a single, reviewed list of vulnerabilities with an assessment date and reviewer name.
Write the action plan with planned completion dates
For each confirmed vulnerability, record a remediation or mitigation action, the responsible owner, a planned completion date and the current execution status. Part 3.4 expects this plan to exist and to be followed, so each action needs a documented decision: fix, mitigate or accept with approval. Review the plan on a set cadence and update the status field each time. The output is an action plan that shows, for every finding, what was decided, who owns it, when it is planned to close and whether it is open, in progress or closed.
Retain evidence and close the cycle
Store the asset list, method decisions, calendar, gate records, raw results, reviewed findings and action plan together in a retention location that matches the audit period. Check that every high and medium impact asset has an assessment inside its window and that every finding has a plan entry. Record the cycle as closed in the calendar and open the next cycle. Confirm retention rules and evidence formats with the Regional Entity or the auditor, because the requirements for how long evidence is kept are set by the compliance program and monitoring process.
Choosing between paper and active assessments
A paper assessment reviews documented information about a Cyber Asset without sending traffic to it. The reviewer compares the software inventory, patch levels, configuration and known vulnerability data against published vulnerability sources, then records what was found and why. Part 3.1 accepts this method for high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA, on a cycle of at least once every 15 calendar months.
- Operational risk: Nothing is scanned or probed, so there is no direct risk to availability or control system performance.
- Effort: The work is mostly analysis and record keeping, but it must be repeated on schedule for every in-scope asset.
- Accuracy: The result depends on the quality of the inventory. An unlisted package or an outdated baseline produces a false sense of coverage.
- Evidence: Keep the input data, the date, the reviewer, the findings and the rationale for each conclusion.
- Limits: Paper alone does not satisfy the active assessment expectations in Part 3.2 or the new-asset check in Part 3.3.
Confirm with your own environment whether your asset inventory is complete enough to support a paper result. Ask your auditor how they expect the input data and reviewer reasoning to be documented.
An active assessment in a test environment sends probes or scans to a system that models the production baseline. This is the cleanest way to find vulnerabilities that a paper review can miss, because the scanner observes live behavior. Part 3.2 requires an active assessment at least once every 36 calendar months for high impact BES Cyber Systems where technically feasible, in a test environment that models the production baseline.
- Baseline fidelity: The test system must match production in the attributes that matter, such as operating system, installed software, patch level and configuration.
- Documented differences: Record every known difference between test and production, along with the reason it exists and the risk it introduces.
- Setup effort: A test environment that accurately mirrors production has its own build, patch and maintenance cost that recurs over time.
- Scope of findings: Results from a test system apply to production only as far as the baseline matches.
- Documentation: Keep the test environment description, the baseline comparison and the scan configuration with the results.
Confirm with your own environment whether a representative test system is feasible, and whether a vendor or auditor accepts the baseline you propose.
An active assessment in production runs scans against live systems in a manner designed to minimize adverse effects. Part 3.2 allows this approach for high impact BES Cyber Systems where a test environment is not feasible. It delivers results from the real operating system, but the entity accepts operational risk and must control it carefully.
- Scan selection: Use the least intrusive checks that answer the question, and avoid probes known to disrupt fragile control system devices.
- Timing and coordination: Agree windows with operations staff and document who approved each scan.
- Fallback: Define in advance how the team will stop a scan and recover if a device degrades.
- Documentation: Record why a test environment was not feasible, the controls used to minimize effects and any observed impact.
- Staffing: Scan planning, monitoring and post-scan review take skilled staff time on every cycle.
Confirm with your own environment and your vendors whether production scanning is safe for each device class, and document that determination before the first scan.
Evidence that passes a CIP-010 R3 audit
An auditor testing CIP-010-4 R3 looks for a chain of records: what was scanned, when, how it compared with production, what was found, and what was done about it. Each card below is one link in that chain, and the set only holds together if the records are dated, scoped and kept current between audits.
Vulnerability assessment reports
Each paper or active assessment needs a dated report stating which BES Cyber Systems and associated EACMS, PACS and PCA were covered, the method used, and who performed it. Under Part 3.1 the interval is at most 15 calendar months, so the report history should show a continuous sequence with no gap. Check that every applicable asset appears in at least one report within each window, not only in the newest one.
Scan configuration and asset inventory
An auditor will ask what the scanner was told to look for and which assets it was pointed at. Keep scan policies, credentialed scan settings, target lists and the software inventory exported at scan time, with the version of the vulnerability feed used. A scan report that cannot be tied to a current inventory of applicable Cyber Assets invites the question of what was left out.
Test versus production difference records
Where an active assessment for a high impact system runs in a test environment, the record must state how that environment models the production baseline and list every difference. Document differences in operating system versions, installed applications, network paths and security controls. Without this record, an active test result cannot be credited as representative of production.
Pre-production assessment records
Before a new applicable Cyber Asset joins a high impact production environment, keep the active assessment result, the date it was run, and the approver's sign-off. Record any CIP Exceptional Circumstance or like-for-like replacement that relied on the baseline exception, with the reason. Auditors check that the timing matches the change record, so tie each assessment to its change ticket.
Remediation action plans
Part 3.4 requires documented results and an action plan covering each vulnerability to be remediated or mitigated. Each entry should name the vulnerability, the affected asset, the planned completion date, the execution status and any compensating measure. Plans that show a planned date with no status update, or that quietly slip past their dates, are a common finding.
Retention and between-audit upkeep
Set a recurring review that confirms each assessment window is on schedule, reconciles the inventory against the last scan, and closes or re-dates open action plan items. Store records in a system with access controls and an export path, and confirm with the Regional Entity how long evidence must be kept for the audit period in use. Treat the retention period as a question to answer for your own registration, not a figure to assume.
What meeting CIP-010-4 R3 costs
This table separates the main cost components of running CIP-010-4 R3 vulnerability assessments, who is paid for each, whether it is one-time or recurring, and what drives it up. Use it to build a quote request, since no prices are published here and the real figures depend on your asset count, scope and environment.
| Cost component | Who is paid | One-time or recurring | What drives the cost |
|---|---|---|---|
| Tooling or licenses | Commercial scanner or vulnerability management vendor | Recurring, usually annual or per asset | Number of Cyber Assets in scope, number of impact categories covered, and support tier |
| Open-source tooling (self-hosted) | No license fee; staff time and infrastructure | One-time setup, then recurring operation | Hosting, storage for offline vulnerability data, and the team hours to run and tune it |
| Asset inventory and scan engineering | Internal staff or implementation partner | One-time build, then recurring upkeep | Size and diversity of the high and medium impact environments, and how many EACMS, PACS and PCA are in scope |
| Active assessments in test environments | Internal staff, test lab owner or external tester | Recurring, at least every 36 months for high impact where feasible | Whether a production-like test environment exists, and how far it differs from production |
| Review of paper assessments and remediation plans | Internal compliance staff or outside reviewer | Recurring, every 15 calendar months | Number of assessments, quality of prior records, and how many findings need an action plan |
| Evidence upkeep | Internal compliance staff | Recurring | Retention of scan results, action plans with completion dates and execution status, and differences between test and production |
| New asset assessment before production | Internal engineering or external tester | Recurring, per new high impact Cyber Asset | Rate of new asset additions and whether like-for-like replacements qualify |
| Auditor sampling | Regional Entity audit team (no fee to the entity for the audit itself) | Recurring, per audit cycle | Volume of evidence the auditor samples and how easily records are retrieved |
Open-source tools that produce R3 evidence
Can Wazuh vulnerability detection produce CIP-010-4 R3 evidence?
Yes, it can produce part of the evidence for Part 3.1 assessments. Wazuh's vulnerability detection correlates the software inventory that each agent collects with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications of monitored endpoints. For an assessment record, the reviewer can export the findings with dates and affected hosts. Wazuh covers software-level findings only, so it does not replace an assessment of ports, services, configuration or network exposure. Its license is GPL-2.0-only, which matters if you plan to modify the code and distribute it. For an offline environment, confirm with your team that the local copy of the vulnerability data is refreshed on a schedule you can document.
How does Fleet help track vulnerable software on CIP-scoped hosts?
Fleet detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV. That gives you a host-level view that can feed the Part 3.1 assessment record and the Part 3.4 action plan, because each finding can be tied to a host and reviewed over time. Fleet is MIT licensed, which keeps licensing simple, but enrolling hosts in a BES Cyber System environment requires a change control decision under CIP-010-4 R1, so plan the rollout with your baseline and change records in mind. Confirm which of Fleet's data sources cover the operating systems and applications in your fleet before you rely on them for evidence.
What does DefectDojo add to vulnerability remediation tracking?
DefectDojo gives the remediation plan a single place to live. It imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and it offers a generic findings import for other sources. It deduplicates findings using per-tool hashcode fields, so repeated results from successive assessments do not clutter the action plan. The Part 3.4 record needs the assessment results, the planned completion date and the execution status, and DefectDojo can hold those fields alongside each finding. DefectDojo is BSD-3-Clause licensed. Before you rely on its deduplication, test it with reports from your own tools, because the matching behavior depends on how each tool's fields are mapped.
Is Greenbone Community Edition suitable for scheduled active vulnerability assessments?
Greenbone Community Edition can support active scanning evidence, but scheduling and scope need to be confirmed in your environment. Its gvmd service manages scan tasks, stores results in PostgreSQL, handles users and permissions, and presents results through the Greenbone Security Assistant web interface. That combination produces dated scan records you can keep with the assessment file. Active scanning of high impact systems must be planned against Part 3.2 and the test environment or production constraints, so do not schedule scans on production BES Cyber Systems without a documented plan. Greenbone Community Edition is licensed under AGPL-3.0-or-later, so review the obligations with counsel if you modify it or offer it to others. Confirm the scan schedule, credential handling and retention settings during planning.
Do open-source scanners satisfy CIP-010-4 R3 on their own?
No. A tool produces evidence, but the responsible entity still owns the assessment, the judgment on findings and the remediation decisions. R3 requires documented assessments at defined intervals, assessment of new Cyber Assets before they enter a high impact production environment, and an action plan with dates and status. A scanner report that nobody reviews, signs or links to a plan will not meet those parts on its own. The auditor will look for who performed the assessment, when, against which assets, what was found and what was done about it. Use the tools to generate that record, then document the review process around them.
Which tool should we choose for CIP-010 vulnerability assessments?
Most programs combine tools rather than choosing one, because each covers a different layer. Wazuh and Fleet report on software inventory and installed packages, Greenbone covers network-facing active scanning, and DefectDojo consolidates findings and tracks remediation across them. Choose based on which assets are in scope, which operating systems you run, whether the environment is air-gapped and what your team can operate. Because each tool has its own license terms and edition limits, record those in your tool inventory. An implementation partner can prepare and test the combination against your scope in a fixed-scope engagement, but the entity still owns the assessment program and any report it submits to the Compliance Enforcement Authority.
What should we confirm before using these tools as audit evidence?
Confirm five things with your own environment before relying on the output. First, which CIP-scoped assets each tool can see, including whether Transient Cyber Assets and PACS are covered. Second, how often vulnerability data refreshes, especially for offline deployments. Third, whether Greenbone scan tasks run on the schedule you document for the 15-month and 36-month intervals. Fourth, how DefectDojo deduplicates findings from your specific report formats. Fifth, where the records are stored and how long they are retained, since the audit period and retention rules set how far back you must produce evidence. Test each item with a sample assessment and keep the results as part of the program record.
Who does what for R3: your team, a partner and the auditor
The registered entity owns CIP-010-4 R3 in full. Your team decides which Cyber Assets fall under Parts 3.1 to 3.3, selects the assessment method, approves scan scopes and test environments, and signs off on the results. Risk acceptance, the choice between remediation and mitigation, and the planned completion dates are business and operational decisions that only the entity can make and defend.
- Scope decisions: Maintain the list of high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA, and update it when the CIP-002 categorization changes.
- Assessment method: Choose paper or active assessments for each system, and decide whether an active assessment in production can minimize adverse effects or whether a test environment is needed.
- Risk and remediation: Approve the action plan under Part 3.4, including the planned completion date, execution status and any compensating measures.
- Evidence ownership: Keep the assessment results, approvals and status history in a form your team can produce for the Compliance Enforcement Authority.
- Operator knowledge: Confirm that scanners do not disrupt operations and that vendor-specific limits on active scanning are respected.
Before engaging anyone, confirm that a named owner can explain each assessment decision without referring to a vendor or consultant.
An implementation partner can prepare the systems that produce R3 evidence. Typical work includes deploying open-source scanning tools inside your own environment, configuring scan schedules and credentials, mapping findings to the Cyber Assets in your CIP inventory, and building a workflow that tracks findings from detection to closure. The partner works within the scope and written terms your team agrees to before work starts. The partner does not decide whether a vulnerability is acceptable, and does not certify that your program meets the standard.
- Tooling deployment: Install and harden the scanning and tracking platform inside your infrastructure, with access limited to the people who need it.
- Assessment workflow: Define how paper and active assessments are scheduled, run, reviewed and recorded against the 15-calendar-month and 36-month cycles.
- Evidence preparation: Build repeatable exports of scan results, deduplicated findings and action plan status that your team reviews before retention.
- Documentation: Write procedures and runbooks that describe how the tools are operated, not how compliance is concluded.
- Knowledge transfer: Train your staff to run and maintain the workflow after the engagement ends.
Ask any partner to state in writing which tasks it performs and which remain with your team, and confirm that it will not sign assessment conclusions on your behalf.
The Compliance Enforcement Authority, a Regional Entity or NERC, monitors CIP compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports, periodic data submittals and investigations. Auditors test whether your assessments happened on time, whether the methods met Part 3.2 and Part 3.3 where they apply, and whether the action plans were documented and followed. Their findings are issued by the Compliance Enforcement Authority, not by any consultant that helped you prepare.
- Independence: Auditors must remain independent of the entity and of any firm that helped build the program, so preparation work should never be framed as the auditor's conclusion.
- Sampling: Expect the auditor to select specific assets and assessment dates, then ask for the underlying scan records and approvals.
- Timing: Audit timing and scope are set by the Regional Entity's risk-based schedule, and notice procedures are described in NERC's audit preparation materials.
- Evidence requests: Respond with the records your team owns, and do not supply reconstructed or edited reports as if they were original.
- Outcomes: Findings, Mitigation Plans and any enforcement actions follow the Compliance Enforcement Authority's process.
Confirm the audit notification process and the evidence request format with your Regional Entity before the next monitoring engagement.
Where R3 programs usually fall short
Most R3 findings do not come from missing tools. They come from assessments that cannot be proven complete, from test results that never reach a remediation record, and from assets that enter production without anyone assessing them. The cards below cover the gaps auditors most often raise, with a closing check for each.
Assessments without clear scope or dates
An assessment report that does not name the systems, the Cyber Assets in each applicable category, the method used, or the date performed cannot show the 15-calendar-month interval was met. Auditors often start with the asset list and compare it against the scan targets. Check that each high and medium impact BES Cyber System, with its associated EACMS, PACS and PCA, maps to a dated assessment record that a reviewer can trace without help from the engineer who ran it.
No documented test versus production differences
Where an active assessment for high impact systems runs in a test environment, Part 3.2 expects the differences from production to be written down. Teams often run the scan in a lab that lacks the production patch level, firmware or network segments, then report results as if they describe production. Check that each active assessment record lists the environment used, how it models the production baseline, and each known difference.
New Cyber Assets added without assessment
Part 3.3 asks for an active assessment of a new applicable Cyber Asset before it joins a high impact production environment. The gap usually appears in change tickets that record a server or appliance as routine work, so the assessment never gets scheduled. Check that the change process routes every new applicable asset to a pre-production assessment, and that the only exceptions are the documented CIP Exceptional Circumstances and like-for-like replacements that model an existing baseline.
Findings without plans, owners or dates
Part 3.4 requires the assessment results to feed an action plan that states how each identified vulnerability will be remediated or mitigated, with a planned completion date and execution status. Many programs log findings in a scanner but keep no plan, so open items age without a recorded decision. Check that every finding carries a disposition, an owner, a planned completion date and a current status, and that accepted risks are recorded as decisions rather than left open.
Virtualized assets missed by scans
Hypervisors, virtual machines, container hosts and management consoles often sit outside the asset inventory that the scanner uses, especially when platform teams provision them. The result is an assessment that looks complete but never reached the virtual layer that carries BES Cyber Systems. Check that the asset list is generated from the hypervisor or cloud control plane, and that each virtual Cyber Asset appears in the assessment scope. Ask the operator which virtual assets are covered and which are not.
How much effort and time does CIP-010-4 R3 take?
What drives the effort of CIP-010-4 R3 vulnerability assessments?
The main driver is how many applicable Cyber Assets you have in scope, because R3 applies to high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. Effort rises with the number of device types, the number of vendor platforms, how many systems sit in each impact category, and whether assessments are paper-based, active or both. Documenting results and an action plan under Part 3.4 also adds work, especially where many findings need owners and completion dates. Confirm the asset inventory and applicable systems list before estimating anything.
How often do CIP-010-4 R3 assessments recur?
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 systems. Part 3.2 adds an active vulnerability assessment at least once every 36 calendar months for high impact systems where technically feasible. Part 3.3 requires an assessment of each new applicable Cyber Asset before it enters a high impact production environment, so that work recurs with every addition. Plan these as recurring cycles rather than a single project.
Can our own staff perform CIP-010-4 R3 assessments in-house?
Often yes, if your team has the skills to run scans, interpret results and maintain documentation. The standard does not require outside help, and the organization owns its compliance obligations. Teams commonly need someone who understands both the operational technology in scope and the vulnerability tooling, plus a repeatable process for evidence. An implementation partner can set up the tooling and evidence workflow, but only an independent auditor issues any assessment report. Decide ownership of each step in writing before work starts.
What skills and team roles does the work need?
The work typically needs people who can own the applicable systems inventory, operate the scanning or assessment tools, and review findings against operational constraints. Engineers must know which assets are safe to scan actively and which need a paper assessment, and who can approve changes in test or production. Compliance staff need to maintain the action plan, planned completion dates and execution status. Name a single accountable owner for each role so evidence does not depend on one person.
What recurring costs should we expect after the first assessment cycle?
Recurring costs include staff time for each 15-month cycle, tool maintenance and updates, test environment upkeep if you model the production baseline, and any scheduled active assessments for high impact systems every 36 months. Costs also rise each time new Cyber Assets are added and must be assessed before production use. Open-source tools remove license fees but not labor or infrastructure. Ask any vendor or partner to separate one-time setup from recurring support in the quote.
What should we confirm with the Regional Entity before starting?
Confirm which of your assets are high or medium impact and therefore in scope for R3, and how your Regional Entity expects paper and active assessments to be documented. Ask what evidence it reviews during a Compliance Audit, how it treats assessments of systems in a test environment, and whether it has guidance on documenting differences between test and production. Also confirm how it treats Technical Feasibility Exceptions for active scanning. Get answers in writing, since monitoring is done by the Compliance Enforcement Authority.
Do we need an outside firm to prepare for the assessments?
You do not need one by rule, but many organizations bring in help for setup, evidence design and a readiness review. An implementation partner such as DeployOpen can plan, implement and document self-hosted tooling inside your own infrastructure under a written, fixed scope. It does not issue audit reports or attestations, and independent auditors remain the only parties that do. Ask any firm to state its deliverables, the evidence it will prepare and what remains your responsibility.
How DeployOpen prepares R3 assessment evidence
DeployOpen plans, implements and documents self-hosted vulnerability assessment tooling inside the client's own infrastructure, so that the registered entity can produce R3 evidence from systems it controls. In practice this means deploying a scanner such as Greenbone Community Edition (OpenVAS) or a host-level tool such as Wazuh vulnerability detection in the entity's environment, defining which Cyber Assets fall under each assessment, and setting up gvmd scan tasks, scan schedules and user permissions so that every 15 calendar month assessment leaves a dated, attributable record. Where scanning is not technically feasible for a device, the work also covers the paper assessment method and the documentation that explains why.
Findings only become R3 evidence when they are recorded and worked. DeployOpen can configure a finding aggregation layer such as DefectDojo, import results from each tool, and set deduplication so that one vulnerability on one asset is tracked once. The remediation plan required under Part 3.4, with its planned completion dates and execution status, is a decision the registered entity must make and sign off. DeployOpen can prepare the templates, ticket fields and reporting views, but the entity decides which findings are remediated, mitigated or accepted and by whom. Confirm with your Compliance Enforcement Authority which evidence format it expects before the first assessment.
The entity also owns the test-environment question for high impact systems: whether an active assessment in a test environment that models the production baseline is feasible, and how differences between test and production are documented. DeployOpen can scope and run security testing under a fixed-scope written agreement, including active assessments, and can document the results. It does not issue audit reports, determine compliance or certify any system. Those judgments belong to the registered entity and, when the Compliance Enforcement Authority reviews the program, to that authority. Ask any implementation partner to state in writing which deliverables are configuration, documentation and testing, and which decisions remain with your team.
