RA.L2-3.11.2 Vulnerability scan: requirements and evidence

What RA.L2-3.11.2 vulnerability scanning requires and why it cannot go on a POA&M

RA.L2-3.11.2 is a 5-point requirement that must be MET, not planned, before a defense contractor can reach Conditional or Final Level 2 status. If a contractor's CUI environment holds many endpoints, servers, cloud workloads and in-house applications, this requirement asks for a repeatable scanning routine that covers all of them. Under the CMMC Scoring Methodology in 32 CFR 170.24, a NOT MET result subtracts 5 points from the maximum score of 110. Because the point value is greater than 1, 32 CFR 170.21(a)(2) does not allow it on a plan of action and milestones (POA&M). The practical consequence is that the scanning program has to work on the assessment date, not after it.

The requirement, derived from NIST SP 800-171 Rev. 2 requirement 3.11.2, asks the organization to do four things. It must define a scanning frequency, scan its systems and its applications at that frequency, and scan again whenever new vulnerabilities affecting them are identified. The assessment objectives in NIST SP 800-171A test each of these parts separately, so a contractor that scans operating systems but never scans in-house applications, or that cannot show a written frequency, will fail part of the requirement. The frequency is the contractor's to set, but 32 CFR 170.14(d) caps any periodic interval at one year. Confirm the scope with your assessor or C3PAO early, since the CMMC Assessment Guide expects every asset in the assessment scope to be scanned, including laptops that do not regularly connect to the network. Custom-developed software may also need penetration testing or source code scanning, which is a scoping decision to document now.

Scanning is the detection step. It produces the findings that the organization must then prioritize and fix under RA.L2-3.11.3, and the scanning records feed the risk assessment covered under RA.L2-3.11.1. Before an assessment, check that scan configurations, the scan schedule, the asset list and recent scan reports are in final form and tie back to the system security plan. Evidence in draft form does not count toward a MET result under 32 CFR 170.16 and 170.17. Open-source tools such as Wazuh, Fleet, Greenbone Community Edition and DefectDojo can produce much of this evidence inside your own environment, but the organization owns the scope, the schedule and the records. Confirm each tool's coverage against your asset list before you rely on it.

Which assets and software fall inside the vulnerability scan scope

Scanning only the machines that are easy to reach leaves gaps an assessor will find. The cards below cover the asset types that most often fall inside the assessment boundary, and each one shows what to decide and confirm before you choose scanning tools.

Endpoints and servers in the boundary

Every server and workstation that processes, stores or transmits CUI, or that provides security protection for those systems, sits inside the assessment scope. For RA.L2-3.11.2 Vulnerability scan, the inventory is the starting point: a scanner can only cover hosts it knows about. Check that your asset list is reconciled against directory records, hypervisor inventories and network discovery, and that each host has an owner and a documented scan schedule. Start with a complete inventory before you argue about tool coverage.

Laptops that rarely join the network

The CMMC Assessment Guide for Level 2 expects all assets in the assessment scope to be scanned, including laptops that may not routinely connect to the network. Travelling staff and field devices are the usual gap, because a scanner that only reaches hosts on the corporate LAN will miss them. Confirm how these devices report in, for example through an endpoint agent that checks software inventory when the device connects, and record how long a device can go without a scan before it is treated as a finding. Ask your assessor how they expect remote devices to be evidenced.

Cloud workloads and virtual instances

Virtual machines, containers and managed database instances that hold CUI are in scope even when they are created and destroyed automatically. Short-lived instances are the risk: an instance that exists for a few hours between scans can carry a vulnerable package the scanner never saw. Confirm which cloud accounts and regions hold CUI, whether your scanner can reach each one, and how ephemeral instances get scanned at build time or at launch. Your system security plan should name the cloud environment and its boundary.

Network devices and appliances

Firewalls, routers, switches, VPN concentrators and other appliances that protect or connect CUI systems are part of the assessed environment. Many of them run firmware that a general host scanner does not inspect well, so you may need a network-aware scanner, the vendor's advisories, or a documented manual check. Record the firmware version of each device, the source you use to track vulnerabilities for it, and who signs off on upgrades. Confirm with your assessor whether appliances that only pass traffic are treated as in scope or as part of the boundary.

Custom-developed applications

Applications your organization builds or customizes can contain flaws that no operating system scanner will report. The CMMC Assessment Guide notes that custom-developed software may need penetration testing or source code scanning. Identify which internal applications handle CUI, decide whether each one gets authenticated application scanning, source code analysis, penetration testing or a combination, and record the cadence. Treat third-party components inside these applications as part of the same scope, because their known vulnerabilities count toward the requirement.

How an assessor tests RA.L2-3.11.2 under NIST SP 800-171A

This table maps the five NIST SP 800-171A assessment objectives for RA.L2-3.11.2 to the test approach, the evidence an assessor requests and the findings that most often leave the requirement NOT MET. Read each row as one objective that must be satisfied with final-form evidence before the requirement can be scored as MET.

Assessment objective	Test approach	Evidence requested	Common findings
Scan frequency is defined	Confirm the organization set a scanning interval in its documentation and that the interval is no longer than one year, as 32 CFR 170.14(d) allows for periodic activities.	Written scanning procedure or system security plan stating the interval, plus scanner schedule configuration showing that interval.	No interval is documented, or the schedule in the tool does not match the interval written in the plan.
Systems are scanned at the defined frequency	Compare scan history against the defined interval and check that every in-scope system appears in completed scan runs.	Scan results with dates and target lists, scanning tool configuration documentation, and the asset inventory used to set scan scope.	Scans run on schedule for servers but skip laptops or remote endpoints that connect only occasionally.
Applications are scanned at the defined frequency	Check that web applications, APIs and custom-developed software are included in recurring scans, and that scope covers applications named in the assessment scope.	Application scan reports or penetration test results, scan scope definitions and records of custom software included in scanning.	Only operating systems are scanned, while in-house applications and their dependencies are missing from scope.
Systems are scanned when new vulnerabilities are identified	Ask how the organization learns of newly identified vulnerabilities affecting its systems, then check for an event-driven scan record after one of those notices.	Vulnerability advisory subscriptions or feed records, change tickets or scan logs showing an unscheduled scan triggered by a new vulnerability.	Feeds are received but nobody is assigned to trigger a scan, so no out-of-cycle scan is ever recorded.
Applications are scanned when new vulnerabilities are identified	Trace a newly disclosed application vulnerability to a triggered scan or test of the affected application, and confirm the scan covered the affected version.	Advisory-to-scan tickets, rescan results for the affected application and records showing the version that was tested.	Application scans run only on the regular schedule, and no triggered scan follows a published application vulnerability.
Supporting records support all five objectives	Verify that tool output, the security assessment report and patch and vulnerability management records agree with each other and with the scope statement.	Scanning tool configuration, scan results, the security assessment report, and patch and vulnerability management records.	Draft reports, unexplained gaps in scan history, or results that cannot be tied to a named asset or application.

How to implement vulnerability scanning in six steps

This sequence turns RA.L2-3.11.2 from a policy statement into a repeatable scanning program with a documented frequency, a complete asset list, scan configurations an assessor can inspect, and a dated record of results. Each step produces a artifact that the assessor will ask to see.

Document the scan frequency
The contractor sets the periodic scanning interval in the System Security Plan or a vulnerability management procedure. Under 32 CFR 170.14(d), where a requirement uses the word periodically, the contractor sets the interval, but it may be no longer than one year. Write the frequency, the trigger for event-driven scans, and the owner who approves changes to them. The step is done when the procedure is approved and version-controlled, and the SSP points to it.
Build the in-scope asset inventory
The system owner lists every asset in the CMMC assessment scope, including laptops and other endpoints that do not routinely connect to the network, servers, network devices, cloud workloads and applications. Reconcile the list against the system boundary in the SSP so that no CUI-processing component is missing. Record the operating system, version and owner for each asset. The step is done when the inventory and the SSP boundary describe the same set of assets, and the differences are explained in writing.
Configure authenticated scans
The security engineer deploys a scanner or agent-based tool that can read installed software and patch levels, such as Wazuh, Fleet or Greenbone Community Edition, and configures credentialed scans for operating systems and applications. Scan both systems and applications, and confirm that custom-developed software is covered by a suitable method, such as penetration testing or source code scanning. The step is done when a test scan returns the expected software inventory for a sample of assets, and the configuration is exported and stored.
Add event-driven scans for new vulnerabilities
The team subscribes to vulnerability feeds relevant to the asset inventory and defines how a newly published vulnerability affecting an in-scope product triggers a targeted scan. Use the vulnerability sources the tool relies on, and confirm whether the tool works from a locally hosted offline copy in an isolated environment. The step is done when the trigger rules are written down, tested with a known recent advisory, and the test result is recorded.
Run scans and review results
The operator runs the scheduled and triggered scans, then a reviewer checks the results for false positives, duplicates and assets that were not scanned. Import findings into a tracker such as DefectDojo if the team needs deduplication across tools. Record who reviewed each run and hand confirmed vulnerabilities to remediation under RA.L2-3.11.3. The step is done when every scan run has a completion record, every in-scope asset appears in a run, and unscanned assets are logged with a reason.
Retain scan history for assessment
The compliance lead archives the scan configurations, scanner exports, results and review notes in a location with access control and a defined retention period. Organize the archive by date so an assessor can compare results against the documented frequency and the event-driven triggers. Ask the independent assessor which evidence form they accept before the assessment begins. The step is done when a sample scan cycle can be traced from the procedure to the inventory, the scan, the review and the remediation record.

Open-source tools that produce scanning evidence

Each tool below covers a different part of the scanning workflow: detecting vulnerable software on endpoints, collecting findings from many scanners, and running scheduled network scans. An assessor will still expect the organization to show scan frequency, asset coverage and results that stand on their own, so choose the tools that fit your environment and confirm their coverage before relying on them.

Wazuh vulnerability detection

Wazuh correlates the software inventory that each agent collects from an endpoint with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy. That matches the operating system and installed applications of monitored endpoints against known vulnerabilities. For RA.L2-3.11.2, the evidence is the scan output and the agent inventory behind it. Confirm that agents are deployed on every in-scope asset, including laptops that do not always reach the network, and that an offline copy is kept current if your enclave cannot reach the internet. Wazuh is licensed under GPL-2.0-only, so have counsel review license obligations before distribution or embedding.

Fleet host software detection

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. Its strength for RA.L2-3.11.2 is host-level inventory across mixed fleets, which helps show that every in-scope endpoint was assessed. Check whether your operating systems and key applications are covered by the advisory sources Fleet uses, because gaps in a source mean gaps in findings. Fleet is licensed under MIT. Ask counsel to confirm the license terms match your internal and customer use.

DefectDojo findings consolidation

DefectDojo imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and offers a generic findings import. It deduplicates findings using per-tool hashcode fields. For RA.L2-3.11.2, it gives one place to hold results from Wazuh, Fleet, Greenbone and other scanners, which supports the scan results an assessor will request. Confirm that the report formats you actually use are supported and that deduplication behaves as you expect. DefectDojo is licensed under BSD-3-Clause, and counsel should confirm the terms for your use.

Greenbone scheduled network scanning

Greenbone Community Edition runs OpenVAS through gvmd, which stores results in PostgreSQL, manages users and permissions, and schedules scan tasks. Users run scans and review results in the Greenbone Security Assistant web interface. For RA.L2-3.11.2, the scheduler supports a defined scanning frequency and scans triggered when new vulnerabilities are identified, provided the schedule is set and documented. Confirm that scan targets cover every in-scope system and application, and that credentialed scanning is configured where your environment allows it. Greenbone Community Edition is licensed under AGPL-3.0-or-later, and counsel should review network-use obligations before offering it to others as a service.

Which scanning evidence an assessor accepts as final

An assessor marks RA.L2-3.11.2 as MET only when every applicable assessment objective in NIST SP 800-171A is satisfied with evidence in final form, not drafts. For this requirement, that means the written scan frequency, the scanner configuration, the scope of what was scanned, dated results for both systems and applications, and records showing that new vulnerabilities triggered scans. Under the CMMC Scoring Methodology this is a 5-point requirement that cannot go on a POA&M, so a gap in any one of these artifacts can hold back Conditional or Final Level 2 status.

Start with the written scan frequency. Because 32 CFR 170.14(d) lets the contractor set the interval for periodic requirements but caps it at one year, the document should state the chosen interval, who approved it, and its effective date. Pair it with a scanner configuration export, such as the scan task and target settings from your tool, and a scan scope list tied to your asset inventory. The scope list matters most for laptops and other endpoints that do not connect every day, because the Assessment Guide expects every in-scope asset to be scanned. Also confirm with your assessor whether custom-developed applications need penetration testing or source code scanning as part of the application evidence.

Keep dated scan reports for systems and for applications separately, plus event-driven scan records showing the date a new relevant vulnerability was identified and the scan that followed. Then show the path from results into the security assessment and remediation records, so an assessor can trace a finding to its fix or accepted risk. Ask your assessor or C3PAO how they expect scan history to be retained, including the retention period, the format of exports and whether they will accept a tool's own history or require archived reports. Confirm this before your assessment, since the answer determines how you should export and store records now.

What meeting RA.L2-3.11.2 costs in money and effort

This table breaks the cost of RA.L2-3.11.2 into its components, showing who is paid, whether each cost is one-time or recurring, what moves it up or down, and how open-source scanners change the license line. No prices are given, so use the list of quote items after the table to compare written proposals on the same basis.

Cost component	One-time or recurring, and who is paid	What drives it up or down	How to reduce it
Scanning tools or licenses	Recurring if commercial subscriptions apply. Open-source scanners such as Greenbone Community Edition carry no license fee, though hosting and staff time still apply.	Number of assets and IP ranges, scanner product tier, and whether reporting or integration modules are licensed separately.	Confirm the license terms of every tool in writing, and price open-source options with hosting and support included.
Engineering time to deploy and tune scans	One-time, paid to the internal team or implementation partner for build, scan profiles and schedules.	Number of network segments, scan policies needed, and how many false positives must be tuned before results are reliable.	Document scan profiles once and reuse them across segments, and fix the scan scope before tuning begins.
Authenticated credential management	One-time setup, then recurring upkeep when accounts rotate. Paid to internal staff or the partner.	Count of OS types and applications that need credentialed scans, plus the vault or secrets process required to store them.	Use a single scan account per platform type and a managed secrets store already in use, and document rotation steps.
Inventory upkeep	Recurring, paid to internal IT or asset management staff. Needed so every in-scope asset is scanned.	Asset churn, laptops that rarely join the network, cloud instances created and destroyed, and the accuracy of the CMMC Assessment Scope.	Feed scanner targets from an authoritative inventory or agent-based discovery, and reconcile it against the assessment scope on a fixed schedule.
Evidence retention	Recurring storage and review time. Paid to internal staff for exporting scan results, schedules and remediation tickets.	Scan frequency, number of retained reports, and whether results are kept in a system that supports access control and integrity.	Set a retention period that matches the organization's own policy and store reports in the CUI enclave with access limits.
External penetration testing or source code review for custom software	Recurring or periodic, paid to a specialist firm. Needed where custom-developed software may require it under the CMMC Assessment Guide.	Number and complexity of custom applications, internet exposure, and the depth of testing agreed in scope.	Limit the scope to applications that process or expose CUI, and combine testing with existing development security reviews.
Assessor or consultant time	Recurring for readiness reviews and any assessment support. Paid to a consultant or the assessor, and the assessor's own fees are separate from implementation.	Size of the assessment scope, how mature the evidence already is, and whether the consultant prepares evidence or only advises.	Ask for a fixed-scope readiness review, keep the consultant out of control ownership, and confirm the certifying assessor is independent of the implementation partner.

Who owns the scanning control and who prepares the evidence

Your organization owns RA.L2-3.11.2. Leadership must accept the scanning frequency, because the assessment asks whether a frequency was defined and whether scans happened at that frequency and when new relevant vulnerabilities were identified. Your team also owns the asset inventory that defines what gets scanned, and the triage decisions that turn raw findings into remediation work or documented risk acceptance. An implementation partner can configure tools, but it cannot decide what your environment is or accept risk on your behalf.

Scan frequency decision: Document the interval your organization sets, approved by a named owner. Under 32 CFR 170.14(d), periodic activities may be set by the contractor but may be no longer than one year, so the chosen interval must be defensible.
Asset inventory: Maintain the list of in-scope systems, endpoints, laptops that rarely join the network and custom applications. Gaps here become gaps in scan coverage.
Triage and sign-off: Review scan results, discard confirmed false positives with a reason, and assign remediation owners.
Trigger process: Define who watches for new relevant vulnerabilities and how an out-of-cycle scan is started.
Records: Keep scan reports, triage notes and approvals in final form.

Before engaging anyone, confirm that a named employee can explain the frequency, the inventory and the last triage cycle without referring to a vendor.

Where scanning programs fall short of the requirement

Most failed scan findings under RA.L2-3.11.2 do not come from missing scanners. They come from gaps in scope, timing, records and follow-through. Each card below names one gap, why an assessor will notice it, and the fix to put in place before the assessment.

Laptops and remote endpoints left out of scope

Assessors expect every asset in the CMMC assessment scope to be scanned, including laptops that rarely join the corporate network. A scanner pointed only at servers and always-on desktops leaves the devices most likely to carry unpatched software, such as travel laptops, out of view. Check the scope against your asset inventory, and confirm that each endpoint reports to the scanning platform even when it is off the VPN. An agent-based approach, such as the software inventory feature in Wazuh, can reach hosts that a network scan cannot.

Custom applications never scanned

Operating system scans rarely reach software your team wrote or heavily modified. The CMMC Assessment Guide notes that custom-developed software may need penetration testing or source code scanning. Confirm which in-scope applications were built in-house, list them as assets, and assign each one a test method and owner. Without that record, an assessor can find that applications were not covered by the scan program at all.

No documented scan frequency

The requirement asks the organization to define how often scanning happens, and an assessor will test whether that definition exists. A scanner that runs when someone remembers it fails this objective even if the results look healthy. Write the interval into the system security plan or the vulnerability management procedure, and make sure the scheduled tasks in the tool match it. Under 32 CFR 170.14(d), the interval may be no longer than one year, but most programs set a shorter cycle to support the event-driven scans described next.

Event-driven scans not triggered

The requirement also calls for scanning when new vulnerabilities affecting your systems are identified, not only on the regular cycle. Many programs skip this step because no one owns the trigger. Assign a responsible role to watch vendor advisories and vulnerability feeds for each in-scope product, and define a rule such as scanning the affected assets within a set window after an alert. Record each trigger and the scan it produced, since assessors ask for that link.

Scan results not kept as dated records

Scan results are assessment evidence only if they are final, dated and retained. Draft exports, overwritten reports and results held only in a dashboard make it hard to show what was scanned and when. Set a retention rule for raw reports and summaries, store them in a location with access controls, and keep the scanner configuration documentation alongside them. Confirm the retention setting and any default expiry in your chosen tool before relying on it.

Findings not linked to remediation

A scan that finds problems but produces no tickets, risk decisions or tracked fixes shows the scanning objective was met while the program was not working. Assessors look for a path from each finding to a remediation record, an accepted risk or a plan of action. Use a findings platform to deduplicate results across tools and route them to owners, and make sure each open item has a status and due date. Remediation requirements under RA.L2-3.11.3 depend on this link.

Questions buyers ask about RA.L2-3.11.2 cost, effort and outside help

How much effort does RA.L2-3.11.2 take in-house?

Most of the effort comes from making scanning complete and provable, not from running the scanner. The requirement asks the organization to define a scanning frequency, then scan both systems and applications at that frequency and whenever new vulnerabilities affecting them are identified. Your team must maintain an accurate asset list for the CMMC Assessment Scope, keep scanner configuration and schedules documented, review results, and keep records that an assessor can trace from scan to remediation. Laptops that rarely join the network also need scan coverage, which often takes the most planning. Ask your team to estimate hours for asset inventory, scan operations and results review before you decide what to outsource.

What drives the cost of vulnerability scanning for CMMC Level 2?

Cost is driven by the number of in-scope assets, the variety of operating systems and applications, how many environments you run (on-premises, cloud, remote endpoints), and how much custom-developed software needs testing. Custom software may require penetration testing or source code scanning under the CMMC Assessment Guide Level 2, which adds scope beyond a standard vulnerability scan. Tool licensing is only one line item. Recurring costs include staff time, scanner maintenance, data storage for results and periodic reviews. Ask any provider for a written scope that lists assets, environments, scan frequency and deliverables, so quotes can be compared on the same basis.

Can a small team run open-source scanners itself?

A small team can run open-source scanners itself if it has someone who can operate the tools, maintain their configuration and keep the records an assessor will ask for. Options such as Greenbone Community Edition (OpenVAS), Wazuh vulnerability detection and Fleet each cover different asset types, so you may need more than one tool to reach every in-scope asset. Consider the skills needed to tune scans, handle false positives, deduplicate findings and keep the server patched. Many teams keep ownership of the program and bring in an implementation partner only for the initial setup, documentation or integration work.

How long does setup take, and what changes the timeline?

Setup time depends on scope, not on a fixed period that applies to every organization. The main drivers are the number of in-scope systems, how many scanners and reporting tools you deploy, whether results must feed a central tool such as DefectDojo, how well asset inventories already exist, and how quickly your team can approve changes to network access and agents. Fixed-scope engagements usually agree on timelines in writing before work starts, so ask for a timeline tied to named deliverables. Also confirm how the timeline interacts with your own CMMC schedule, since current Department of War guidance on Phase II is being reviewed.

What does the work need from our own staff?

Your staff must own decisions that outside help cannot make for you. Someone must define the scanning frequency, which the organization sets, and must confirm the asset inventory and the scope boundary. Network and endpoint administrators need to grant scanner access, install agents and approve maintenance windows. Security staff must review findings, assign remediation owners and link accepted risks to the right records. Ask a provider to list these tasks in the statement of work so your staff can plan time for them before the engagement starts.

Can an outside partner see the assessment result?

An implementation partner can see the scanning setup, scan records and evidence it helped produce, but it does not issue the assessment result. Under CMMC, Level 2 certification assessments are performed by C3PAOs authorized or accredited by The Cyber AB, and the organization owns its controls and evidence. Partners that prepare systems and evidence can help you organize it for the assessor, but the assessor decides whether the requirement is MET. Agree in writing which records the partner will hand over, where they will be stored, and who keeps access after the engagement ends.

How DeployOpen scopes and implements vulnerability scanning for CMMC

DeployOpen plans and deploys self-hosted open-source scanning inside your own environment so every in-scope asset is covered at a frequency you define and documented for assessors. We prepare the scanning systems and evidence for RA.L2-3.11.2, while your organization owns the control and an independent assessor decides whether it is met.

How we scope

We confirm the CMMC Assessment Scope and list every system, laptop and application that needs scanning, including devices that rarely connect.
We agree in writing the scanning frequency your organization defines, within the one-year ceiling for periodic requirements.
We identify custom-developed applications that may need penetration testing or source code scanning, and record them as separate scope items.

How we build

We deploy an open-source scanner such as Greenbone Community Edition, Wazuh or Fleet, matched to your operating systems and asset types.
We configure scan tasks for both systems and applications, plus triggers that run scans when new relevant vulnerabilities are identified.
We test the scanning, analysis and reporting mechanisms so each of the five assessment objectives can be shown with records.

How we hand over

We deliver scanner configuration documentation, scan schedules, scope mapping and sample scan results in a form your assessor can review.
We set up findings workflows, for example in DefectDojo, so results link to remediation records and to your plan of action where needed.
We document how the evidence was produced so your team can repeat the process and answer assessor questions without us.

How we support

Ongoing support, scanner upgrades and continuous testing are available as a retainer after the fixed-scope work is complete.
We can review scan coverage when assets are added, retired or moved, so the scope stays accurate between assessments.
We prepare evidence for your assessment, but only an independent assessor issues a determination, and we do not issue certifications.

RA.L2-3.11.2 Vulnerability scan