How NERC CIP-010 vulnerability assessments work for utilities and grid operators
CIP-010-4 R3 requires periodic paper or active vulnerability assessments of BES Cyber Systems, and open-source scanning can support those assessments if scope, timing and records are controlled. If you run high or medium impact BES Cyber Systems, the core obligations are a paper or active assessment at least once every 15 calendar months under Part 3.1, and, where technically feasible for high impact systems, an active assessment at least once every 36 calendar months under Part 3.2. Those assessments cover the associated EACMS, PACS and PCA as well. There is no CIP certificate. The Compliance Enforcement Authority, which is either a Regional Entity or NERC, monitors compliance through Compliance Audits, Spot Checks, Self-Certifications, Self-Reports and periodic data submittals. DeployOpen plans, deploys and documents self-hosted scanning and prepares the evidence your team reviews, but it does not issue audit reports or attestations. Those come from your Compliance Enforcement Authority and your own compliance function.
Before any scanner touches a control system network, confirm which Applicable Systems each scan covers and whether the scan runs in a test environment that models the production baseline or in production in a way that minimizes adverse effects. Part 3.2 also requires you to document differences between test and production, so that record belongs in your evidence file from the start. Greenbone's scanner runs active vulnerability tests against targets, so the scan profile, target list, credentials and timing must be approved by the OT owner, not only by IT. Ask your team to confirm which Greenbone components and feed data run in the assessment environment and whether that environment can reach the vulnerability data it needs, since the Greenbone Community Containers depend on feed data loaded at startup.
Part 3.4 is where many assessments fall short. Results alone do not satisfy it: you need a documented action plan to remediate or mitigate each identified vulnerability, with a planned completion date and an execution status. Decide in advance who owns each finding, how exceptions and compensating measures are approved, and where the plan lives. DefectDojo's OpenVAS parser can import Greenbone reports in CSV or XML format, which gives you one tracked record per finding and a reviewable history for the Compliance Enforcement Authority. Before go-live, confirm the CIP-010-4 version that applies to each system with NERC's current standards page, because several CIP standards have 2026 and later effective dates and a virtualization-related revision is approved for July 2028.
Mapping CIP-010-4 R3 Parts 3.1 to 3.4 to scanning and tracking work
This table pairs each part of CIP-010-4 R3 with what the requirement asks for, how to configure Greenbone and a tracking tool such as DefectDojo or a ticketing system, and what evidence to keep. Read each row as a control to confirm with your compliance team and your Regional Entity, since scope depends on your CIP-002 impact categorization. The main takeaway is that the scanning schedule is only part of the work: assessment scope, test-versus-production decisions and remediation plans with dates must be recorded too.
| Requirement part | Function requirement | Greenbone and tracking configuration |
|---|---|---|
| Part 3.1, periodic assessment | Run a paper or active vulnerability assessment at least every 15 calendar months for high and medium impact BES Cyber Systems and their associated EACMS, PACS and PCA. | Create a Greenbone target per in-scope asset group, tagged by impact category and system type. Schedule authenticated scans and record the scan date and scope in gvmd. Export reports to DefectDojo for a dated assessment record. |
| Part 3.2, active assessment cadence | For high impact systems where technically feasible, run an active assessment at least every 36 calendar months in a test environment that models the production baseline, or in production in a way that minimizes adverse effects. Document test versus production differences. | Keep a separate Greenbone target and scan profile for the test baseline. Record the baseline version, the differences from production and the reason for any production scan in the DefectDojo engagement notes. Confirm the technical feasibility basis with NERC's eligibility list before relying on it. |
| Part 3.3, new Cyber Asset assessment | Assess a new applicable Cyber Asset before adding it to a high impact production environment, unless a CIP Exceptional Circumstance or a like-for-like replacement modeling an existing baseline applies. | Add a pre-commissioning gate in the change ticket that requires a Greenbone scan report attached to the change record. Tag the asset in Greenbone as pending production. Log any exceptional circumstance or like-for-like justification in the ticket with the approver. |
| Part 3.4, documented results | Document assessment results and an action plan to remediate or mitigate each vulnerability, including a planned completion date and execution status. | Import Greenbone results into DefectDojo, deduplicate, and assign each finding to an owner. Each open finding needs a plan field, planned completion date and status. Use DefectDojo or the ticketing system as the system of record, with gvmd as the source of scan evidence. |
| Mitigation and exceptions | Record how each unresolved vulnerability is mitigated, and keep the remediation plan current until the work is complete. | Use DefectDojo risk acceptance or a ticket status such as mitigated, accepted or planned. Link compensating control evidence to the finding. Review plans on a fixed cadence and keep prior versions for auditors. |
| Evidence retention | Keep records that show the assessment was performed, the scope, the results and the action plan for the Compliance Enforcement Authority to review. | Store exported gvmd reports, scan configuration, target lists and DefectDojo engagement exports with timestamps in an access-controlled repository. Confirm retention periods with your compliance program and the Regional Entity. |
When active scanning with Greenbone is safe in control system networks
Choose between a paper assessment and an active assessment before anyone points a scanner at a BES Cyber System. CIP-010-4 Part 3.1 accepts either for high and medium impact systems and their associated EACMS, PACS and PCA, at least once every 15 calendar months. A paper assessment reviews configuration baselines and vendor advisories against known exposures and carries no traffic risk to fragile devices. An active assessment with Greenbone sends probes to live assets, so it is only justified when the asset owner can accept that risk. Where active scanning is technically feasible for high impact systems, Part 3.2 also requires an active assessment at least every 36 calendar months, either in a test environment that models the production baseline or in production with minimized adverse effects. Document which path you chose for each system and why. Greenbone's architecture drives the hosting decision. gvmd, PostgreSQL, the scanner services and the feed data containers run together, and the Greenbone Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended. Keep that stack on a dedicated host outside the control network, reached through a tightly limited path, and never inside an electronic security perimeter that is not already governed by its own change control. Within scans, set up profiles that skip destructive or fragile checks, exclude known fragile devices by address, and schedule active runs inside documented maintenance windows. Confirm with each vendor whether scanning their device is supported, and record that answer alongside the asset. Notus host checks are credentialed, since they compare installed software on a host against known vulnerable versions, so the scanner needs logon details for the asset. For OT hosts, that means a stored credential, an authenticated session and additional activity on the device, which may be unacceptable on some engineering workstations or embedded controllers. Treat credentialed scanning as a separate approval, use a dedicated low-privilege account, and document the change. Before any active scan, confirm the vendor's device safety guidance, your own change control approval, and the test-to-production differences you must record under Part 3.2. Have the asset owner sign off on the scan plan.
Running a CIP-010 assessment cycle from scope to closed action plan
This sequence turns CIP-010-4 R3 from a calendar obligation into a traceable cycle: each BES Cyber System is scoped, assessed by an appropriate method, tracked to a remediation plan with dates and status, and closed with records an auditor can sample. Compliance, operations and security staff each own a defined part of the cycle.
Confirm applicability from the CIP-002 categorization
Compliance staff start from the entity's approved CIP-002 impact categorization and list which BES Cyber Systems are high impact, which are medium impact, and which associated EACMS, PACS and PCA fall within the Applicable Systems for R3. Low impact assets are scoped separately under their own requirements. The output is a signed-off scope list that names each system, its impact category and the requirement parts that apply to it. Confirm the scope with the entity's compliance team before any scanning starts, because the Applicable Systems column in the standard drives every later step.
Build the asset inventory per applicable system
Operations and engineering staff build an inventory for each in-scope BES Cyber System, listing hosts, network devices, firmware-bearing assets, EACMS, PACS and PCA with their addresses, operating systems, software versions and network zones. Virtualized environments need the same detail for hypervisors and virtual machines. The inventory is complete when every in-scope asset appears once, each has an owner, and the compliance team has reviewed it against the baseline configuration records kept under R1. Gaps found here are cheaper to fix before scanning than after findings arrive.
Choose paper or active assessment for each asset
For each asset, the compliance lead and the control system engineers decide whether Part 3.1 is met by a paper assessment, which reviews documentation and configuration without touching the device, or by an active assessment, which probes it on the network. High impact systems also face Part 3.2, which asks for an active assessment where technically feasible, in a test environment that models production or in production in a way that minimizes adverse effects. Record the method, the reason and any differences between test and production. Where an active scan is not technically feasible for an asset, this is the point to open a Technical Feasibility Exception path with the entity's compliance team, since the eligibility and approval rules sit with them.
Run and schedule scans with Greenbone
Security engineers configure Greenbone scan targets, credentials and scan configurations that match the decision in the previous step, and run active scans in the agreed window or in a test environment that models production. Scan settings should be reviewed with control system engineers to limit intrusive checks on fragile devices. Scheduled tasks then repeat assessments within the cycle the entity has committed to under Part 3.1 and Part 3.2. The output is a dated scan report per target and a record of any target that was skipped, with the reason.
Import results into DefectDojo for tracking
The security team imports Greenbone reports into DefectDojo using its OpenVAS parser, which accepts reports in CSV or XML format, so that all findings for in-scope assets sit in one tracked record. Paper assessment results and manual findings are entered in the same product so the cycle has one source of truth. The step is complete when each finding maps to an asset in the inventory and the import log confirms that every report was loaded. Imports that fail or lose assets should be treated as a gap in the assessment, not as a clean result.
Triage findings and assign owners
Security analysts review findings with control system engineers to confirm which are real, which are false positives on devices that report banner versions incorrectly, and which need compensating measures because the device cannot be patched. Each confirmed finding receives a severity, an accountable owner and a remediation or mitigation decision. Changes to a control system baseline still follow the configuration change management steps in CIP-010. The output is a triaged list where every open item has a named owner and a recorded decision.
Record the action plan with dates and status
Compliance and operations leads write the action plan that Part 3.4 requires, listing each vulnerability, the chosen remediation or mitigation, a planned completion date and the current execution status. Plans are updated when dates move, and the change and its reason are kept rather than overwritten. Confirm with the compliance team how the entity defines an acceptable plan, because the standard sets the content and the entity sets the internal approval path. The output is an approved plan that matches the findings list one to one.
Verify closure and retain assessment records
After remediation or mitigation, the security team reruns the relevant scan or records the paper review, then updates each finding in DefectDojo with its closure evidence and date. Items that stay open past their planned completion date are escalated to the compliance owner. The cycle closes when every action plan item has a verified status, and the scan reports, import logs, inventory, method decisions, exception records and plan history are stored together under the entity's retention rules. The compliance team should confirm the retention period and the evidence format required by the Compliance Enforcement Authority.
Open-source platforms that fit CIP-010 vulnerability assessment work
CIP-010-4 R3 requires paper or active vulnerability assessments of BES Cyber Systems and their associated systems, with documented results and an action plan. The platforms below cover the active scanning, central tracking and passive inventory pieces, and each one has a boundary that the OT team and compliance lead need to confirm before deployment.
Greenbone Community Edition scanner
Greenbone Community Edition runs vulnerability tests through the OpenVAS scanner, with gvmd managing scans, users, schedules and results in PostgreSQL. Access is through the Greenbone Security Assistant web interface or the GMP protocol, which tools such as gvm-tools can call. The openvas-scanner code is GPL-2.0 and gvmd is AGPL-3.0. Confirm with the Greenbone documentation that the Community Feed excludes tests for some enterprise products, so the coverage of your control system assets may need a different feed or a manual assessment record.
Greenbone container deployment
The Community Containers run through Docker Compose and load feed data such as vulnerability tests, Notus data and CVE and CPE data into volumes at startup. The documented minimum is 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended. Place the scanner in a segment that the control system change process has approved, and record the feed version used for each assessment so the Part 3.4 record can show what was tested.
DefectDojo central tracking
DefectDojo imports OpenVAS and Greenbone reports in CSV or XML format, so assessment results from several scan runs can sit in one place. This supports the Part 3.4 requirement to document results and track an action plan with planned completion dates and execution status. Confirm that the import preserves the asset, the scan date and the finding status, and decide whether remediation work is tracked there or in a separate ticketing system.
Wazuh inventory as a complement
Wazuh vulnerability detection uses agent inventory data to flag software with known vulnerabilities, which gives a continuous view of hosts where an agent can be installed. It does not replace active assessments for BES Cyber Systems, and it adds a software footprint on the asset. Confirm which systems allow an agent, what the inventory covers on your operating systems, and that the record is presented as a supplement to the paper or active assessment required by Part 3.1.
Adjacent identity controls
Keycloak and OpenBao are not vulnerability scanners, but they support the access and secrets context around the assessment. Scanner credentials, which are needed for authenticated checks, should be held in a managed secret store and limited to named operators. Confirm with your compliance lead how scanner accounts and their access logs are reviewed, since those records may be requested alongside the assessment evidence.
Evidence auditors request for CIP-010 vulnerability assessments
This table lists the records a Compliance Enforcement Authority is likely to ask for under CIP-010-4 R3, what each record shows and which component or process produces it. Read it as a checklist for building the evidence trail before an audit or spot check, since the authority decides what it samples. Its main takeaway is that scan reports alone rarely satisfy R3, which also needs scope, schedules, action plans and change records held in a controlled repository.
| Evidence item | What it shows | Which component produces it |
|---|---|---|
| Asset list by Applicable System | Which high and medium impact BES Cyber Systems, associated EACMS, PACS and PCA are in scope, and which Cyber Assets sit in each category | CMDB or asset inventory maintained with the CIP-002 categorization record |
| Scan scope and schedule records | Target ranges, credentialed or non-credentialed scope and the 15-calendar-month cadence for Part 3.1 per system | Greenbone task and target definitions in gvmd, plus the change-approved schedule document |
| Dated scan reports | Which assets were assessed, when, by which scanner and feed version, and what was found | Greenbone reports exported from gvmd, with feed and scanner versions recorded |
| Paper assessment records | Reviews of configuration and documentation where an active scan is not used, with reviewer, date and findings | Signed review records kept in the controlled evidence repository |
| Test versus production difference documentation | For Part 3.2 active assessments in a test environment, how the test baseline models production and where it differs | Architecture diagrams, baseline configuration exports and a written difference list |
| Pre-addition assessment records | Active vulnerability assessment of a new Cyber Asset before it joins a high impact production environment (Part 3.3) | Greenbone scan report for the new asset, linked to the commissioning ticket |
| Action plans with planned completion dates and status | Each identified vulnerability with a remediate or mitigate decision, a planned completion date and execution status (Part 3.4) | Findings tracker such as DefectDojo fed by Greenbone CSV or XML exports, plus a dated action plan |
| Change tickets | Patches and configuration changes that closed findings, with approval and verification evidence | Change management system tied to action plan items |
| Exception or TFE records | Technical Feasibility Exceptions or CIP Exceptional Circumstances used to justify deviations, with approvals and compensating measures | Governance register owned by compliance, referencing scan results |
What scanning tools alone do not satisfy under CIP-010
A scanner produces findings, but CIP-010-4 R3 asks for a documented assessment, an action plan and a record of how each system was classified and tested. The cards below cover the gaps that a Greenbone deployment does not close by itself, and the decisions a compliance lead needs to make before the first assessment.
Passive monitoring is not an active assessment
Part 3.1 allows a paper or active vulnerability assessment, and Part 3.2 names active assessment for high impact systems where technically feasible. Passive network monitoring can show that a device exists and what it talks to, but it does not test the device for weaknesses. Before relying on monitoring alone, confirm with your Compliance Enforcement Authority and your own records which assessment type each Applicable System receives.
Missing asset inventory and impact classification
A scan only covers the addresses it is given. CIP-002 impact classification determines which systems fall under high, medium or low impact scope, and the R3 tables depend on that result. Teams often discover that Protected Cyber Assets, EACMS or PACS devices are missing from the scan target list. Reconcile the scanner's asset list against the approved BES Cyber System inventory before each assessment cycle.
No authority to approve TFEs or exceptions
A scanner reports findings but cannot decide that a finding is acceptable. Technical Feasibility Exceptions and CIP Exceptional Circumstances need an approval path owned by people with authority in your organization, with the justification and any compensating measures recorded. Define who signs off on each exception and how it links to the action plan under Part 3.4 before the first scan produces findings that cannot be patched.
Unverified device safety for OT
Scanning tests running on a target can cause a controller, relay or human-machine interface to crash, freeze or reset. Greenbone's vulnerability tests and authenticated checks need to be reviewed before they touch OT devices. Ask the device vendor which test types are safe, run the first scans in a test environment that models the production baseline, and record every difference from production, as Part 3.2 requires.
Manual paper assessments still need records
Some Applicable Systems are assessed on paper, through document review and configuration checks rather than network scanning. Those assessments still must be dated, attributable and tied to the same asset list and remediation tracking as active scans. Standardize a paper checklist and store its results beside scanner exports so that auditors see one consistent record across both methods.
2026 revisions change the scope
FERC Order No. 919 approved CIP-010-5 and related virtualization revisions, which NERC lists as effective 1 July 2028. CIP-015-1 internal network security monitoring is subject to future enforcement from 1 October 2028. Track which version applies to each system and date, and plan containers, virtual machines and monitoring sensors as in-scope assets once those versions take effect. Confirm the current status with NERC before changing your program.
Questions utilities ask before adding open-source scanning to CIP-010
What drives the cost of open-source vulnerability scanning for CIP-010?
Cost depends on who runs the scanner, how much hardware it needs, and how much time people spend on triage and evidence. Greenbone Community Containers need at least 2 CPU cores, 4 GB of RAM and 20 GB of storage, with 4 cores, 8 GB and 60 GB recommended, so hosting is a one-time build plus recurring infrastructure. Software licensing is usually zero, but the entity still pays for staff time on scan scheduling, feed updates, false positive review, remediation coordination and assessment records. Ask any partner for a written quote that separates one-time setup, recurring operation, and effort per assessment cycle, and that states who pays for each line.
How long does setup take and what does the entity need to provide?
Setup length depends on the size of the estate and how many change control approvals are needed, so ask for a timeline in the written scope rather than relying on a generic figure. Before scanning starts, the entity normally needs a current asset inventory that identifies BES Cyber Systems, EACMS, PACS and PCA by impact category, sign-off from OT engineering on scan targets and timing, and entries in the change management process for the scanner itself. Scoping against the CIP-002 impact categories should come first, because it decides which assets are in the assessment.
Can our own staff run open-source vulnerability assessments without a partner?
Yes, many teams can run Greenbone internally if they have Linux and Docker Compose skills, a PostgreSQL-backed service to maintain, and people who understand both the scanner and the control system. The harder part is usually sustained work: keeping feeds current, reviewing results with OT engineers, documenting each assessment and building an action plan with planned completion dates and execution status. Ask whether your team has capacity for those recurring tasks across the 15-month and 36-month cycles, and whether a partner would cover planning, implementation or ongoing support as a fixed-scope engagement.
Is active scanning allowed on high impact BES Cyber Systems?
Active scanning on high impact systems is permitted only when it is safe and technically feasible, and CIP-010-4 Part 3.2 sets out the alternatives. Where active scanning is not feasible, the standard allows a paper assessment within the 15-month cycle, while an active assessment must still occur at least once every 36 calendar months, either in a test environment that models the production baseline or in production in a manner that minimizes adverse effects. Any differences between test and production must be documented. Confirm the approach with OT engineering and your Compliance Enforcement Authority's expectations before the first scan, and run unauthenticated or low-intensity profiles only after the vendor and asset owner agree to them.
How do we track the 15-month and 36-month assessment intervals?
Track each applicable asset with its last paper or active assessment date, its last active assessment date for high impact systems, and the date the next assessment is due. CIP-010-4 Part 3.1 requires a paper or active assessment at least once every 15 calendar months for high and medium impact systems, and Part 3.2 adds the 36-month active assessment for high impact systems where technically feasible. Keep the schedule in a system that is independent of the scanner, such as a ticketing queue or compliance register, and set reminders well ahead of each due date. Record exceptions, such as a technical feasibility exception, in the same register with the justification and approval.
Does the open-source scanner satisfy CIP-010 by itself?
No. A scanner produces results, but CIP-010-4 Part 3.4 also requires documenting the assessment results and an action plan to remediate or mitigate each vulnerability, including a planned completion date and execution status. Your evidence set should include scan configuration and scope, dates, asset lists, reviewed findings, remediation or mitigation records and exception approvals. There is no CIP certificate; compliance is judged through audits, spot checks, self-certifications and self-reports by the Compliance Enforcement Authority, so keep records that can be shown to an auditor months later.
What does a DeployOpen engagement cover and what does it leave to the utility?
DeployOpen plans, implements, configures, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, and it runs security testing and prepares systems and evidence for compliance assessments. For a CIP-010 program, that can include scanner deployment, scan profiles agreed with OT, reporting templates and evidence preparation. DeployOpen does not issue audit reports or attestations, and it cannot decide your NERC impact categories or accept risk on your behalf. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. Ask for the exact exclusions in the written scope.
What should a written quote for this work include?
A useful quote lists each deliverable, the environments in scope, the asset count by impact category, the scan profiles and their approval steps, and who performs each task. It should separate one-time work (design, deployment, OT sign-off, initial assessment) from recurring work (feed updates, scan cycles, triage, reporting and retainer support). Ask for assumptions about test environments, change windows, the number of assessment cycles covered, and how additional assets are priced. DeployOpen does not publish a price list, so a quote follows from the written scope.
How DeployOpen scopes and delivers CIP-010 vulnerability assessment support
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source scanning inside the client's own infrastructure, including networks that contain BES Cyber Systems. We start from the client's CIP-002 impact categorization and Applicable Systems list, then agree a written scope before any scanner touches a control system network.
How we scope
- Confirm which BES Cyber Systems, EACMS, PACS and PCA fall under the assessment, using the client's CIP-002 impact categorization.
- Record which assessments are paper-based and which are active, with the Part 3.1 and Part 3.2 cadence for each system.
- Agree in writing which networks, test environments and production segments are in scope, and which are excluded.
How we build
- Deploy Greenbone Community Containers in the client's environment, sized to the documented minimum and recommended resources.
- Configure scan profiles, schedules and rate limits for each network zone, with change control review before any active scan runs.
- Test scanning behavior in a representative test environment and document any differences from production before live use.
How we hand over
- Deliver assessment records that show scope, dates, method and results for each assessment cycle.
- Document remediation or mitigation action plans with planned completion dates and execution status, as Part 3.4 expects.
- Provide runbooks, configuration records and training so the client's compliance and operations staff can run future assessments.
How we support
- Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts.
- Ongoing upgrades, feed maintenance and assessment support are available as a retainer, scoped separately from the initial build.
- Ask any implementation partner to confirm who signs off on compliance evidence, since DeployOpen prepares records but independent auditors assess them.
