03.11.02 Vulnerability monitoring and scanning: evidence

What 03.11.02 vulnerability monitoring and scanning asks for in Rev. 3

03.11.02 asks the nonfederal organization to monitor and scan its system for vulnerabilities at defined frequencies and whenever new vulnerabilities affecting the system are identified, to remediate those vulnerabilities within defined response times, and to keep the set of vulnerabilities being scanned up to date on a defined schedule and when new ones are reported. In Rev. 3 this is a single requirement. Rev. 2 split the same work across 3.11.2 (scanning) and 3.11.3 (remediation), and Rev. 3 withdrew 3.11.3 and folded it into 03.11.02. An assessor will therefore look for remediation evidence under this requirement, not under a separate one. NIST's change analysis classifies the change from 3.11.2 as significant, because the Rev. 3 wording asks for more detail and more foundational tasks.

The requirement has four organization-defined parameters (ODPs) that the organization must assign itself: the frequency of vulnerability monitoring, the frequency of vulnerability scanning, the response times for remediating vulnerabilities, and the frequency at which the set of vulnerabilities to be scanned is updated. NIST does not set these values. If the federal agency that holds the contract does not specify them, the organization must define them to complete the requirement, and SP 800-171A Rev. 3 checks that each value is defined before it tests the work itself. Confirm with the contracting agency whether it has published values, because an undefined ODP leaves an assessor with nothing to measure against.

This requirement is hard for three common reasons. Teams often have no defined values for the four ODPs, so their scanning runs on whatever schedule was set when the tool was installed. Asset inventories are incomplete, so scans never reach laptops, servers or cloud workloads that hold CUI. Endpoints that are not enrolled in any management tool produce no data at all. Before choosing a scanner, check that every system in the CUI boundary appears in an inventory the scanner can read, and write down the four ODP values with their justification so that the scan records can be compared against them.

Which systems, data and teams fall under 03.11.02 scope

Scope for 03.11.02 follows the CUI system boundary, not the whole IT estate. The cards below cover the component types inside that boundary, the scoping choices that change how much monitoring and remediation work is needed, and the teams that own each step.

Endpoints that handle CUI

Workstations, laptops and mobile devices that open, edit, print or sync CUI sit inside the boundary, and their operating systems and installed applications are where most vulnerabilities appear. Inventory each device class and confirm the agent or management tool reports installed software. Check whether contractors' personal devices or unmanaged browsers can reach CUI, because unmonitored endpoints leave a gap the scanning program cannot close.

Servers and cloud workloads

Servers, virtual machines, containers and cloud instances that store, process or transmit CUI are in scope even when a provider manages the underlying hardware. Determine which party patches the operating system and which patches the application, and record that split in the system security plan. Confirm that ephemeral or auto-scaled workloads are still enumerated, since short-lived instances are easy to miss in a scan schedule.

Network devices and security appliances

Firewalls, routers, switches, VPN concentrators and wireless controllers that form the CUI boundary or carry CUI traffic need vulnerability coverage too. These devices often run firmware that a general endpoint scanner does not inspect, so check whether your scanner supports them or whether the vendor's advisories must be tracked by hand. Include management interfaces and out-of-band consoles in the inventory.

Applications and APIs that touch CUI

Web portals, file transfer services, collaboration tools and internal APIs that process CUI are in scope as applications, not only as the hosts they run on. Scope the application's third-party libraries and packages, since a clean operating system can still run a vulnerable dependency. Vulnerability findings from application testing should be imported into the same tracking system as infrastructure findings so remediation deadlines apply to both.

Enclave boundaries and shared infrastructure

The scoping decision that changes the most work is whether CUI sits in a dedicated enclave or shares directory services, logging, backup and management systems with the wider business. Shared components that can affect CUI systems usually fall in scope, which widens the scanning and remediation population. Document each shared service, its owner, and whether its vulnerabilities must meet the same response times as enclave assets.

Third-party hosted components and teams

Services that a provider hosts still need a clear answer on responsibility. Where a cloud or managed service is part of the CUI system, your contract and the system security plan should state which vulnerabilities the provider scans and remediates and what evidence it supplies. Name the owners on each side: security operations for scanning, system administrators and developers for remediation, and procurement for provider reports.

How an assessor tests 03.11.02 under SP 800-171A

This table breaks down how an assessor works through 03.11.02 under SP 800-171A Rev. 3, from the determination statements and ODP checks to the examine, interview and test methods. Use it to see which records to prepare and where assessments commonly stall.

Assessment element	What the assessor checks	Evidence to prepare	Where it commonly fails
Monitoring determination statements	Whether the system is monitored for vulnerabilities at the defined frequency and when new vulnerabilities affecting it are identified	Monitoring configuration, feed or advisory subscriptions, and dated records of monitoring runs	Monitoring frequency exists only in a document and is not what the tooling actually does
Scanning determination statements	Whether the system is scanned at the defined frequency and when new vulnerabilities are identified and reported	Scan schedules, completed scan reports with dates and scope, and scan tool configuration	Scan scope omits endpoints, cloud workloads or applications that hold or transmit CUI
Remediation determination statements	Whether vulnerabilities are remediated within the organization-defined response times	Patch and vulnerability management records linking each finding to a remediation action, owner and closure date	Scans run on schedule, but findings never reach a ticket, owner or closure record
Scanned set update statements	Whether the list of vulnerabilities to be scanned is updated at the defined frequency and when new vulnerabilities are reported	Dated records of signature, feed or vulnerability database updates and the review that followed	Scanner data is months old, so new vulnerabilities are never tested for
ODP definition checks (four)	Whether the monitoring frequency, scanning frequency, remediation response times and scanned-set update frequency are assigned values	A written statement of each ODP value, approved and dated, that matches the operating procedures	Parameters are left blank or described only as "regularly" or "promptly"
Examine method	Risk assessment policy and procedures, vulnerability scanning procedures, and patch and vulnerability management records	Current policy and procedures signed by an accountable owner, with the ODP values written into them	Procedures describe a process that differs from the scan schedule and remediation records
Interview method	Personnel who hold risk assessment and vulnerability scanning duties, and personnel who analyze scan results	Named roles, responsibilities and a short walkthrough of how a finding moves from scan to closure	Staff cannot explain the response times or who approves risk acceptance
Test method	Processes for vulnerability monitoring, scanning, analysis and remediation operate as described	A sample of recent scans, findings and closed tickets that an assessor can trace end to end	Exceptions are not documented, so accepted findings look like missed remediation

How to implement vulnerability monitoring and scanning in sequence

This sequence turns 03.11.02 from a policy statement into a working cycle: defined parameters, a complete inventory of what gets scanned, scheduled and continuous detection, current vulnerability data, tracked remediation, and periodic review. Each step produces a record an assessor can examine.

Assign the four ODP values in writing
Start by setting the four organization-defined parameters: how often the system is monitored for vulnerabilities, how often it is scanned, the response times for remediation, and how often the list of vulnerabilities to scan for is updated. Check first whether the contracting agency has specified any values, because if it has not, the organization must assign them. Leadership or the security owner approves the values and they go into the system security plan or a governing standard. The output is a signed parameter sheet that every later step references. Assessors check that each value is defined, so vague wording such as "regularly" will not pass.
Build a complete asset and software inventory
Identify every system within the CUI scope, including endpoints, servers, cloud workloads, network devices and the applications installed on them. Monitoring can only find vulnerabilities in software it knows about, so the inventory must match what is actually running. Reconcile the inventory against configuration management records and cloud account listings to catch gaps. The output is an inventory with an owner, location and scan status for each asset, reviewed before any scanner is pointed at the environment. Confirm how your chosen tools collect software data, since agent coverage and credentialed scanning differ by platform.
Configure continuous monitoring and scheduled scans
Deploy the detection tools that match your inventory. Agent-based vulnerability detection on endpoints can run continuously against collected software data, while network-based scanning runs as scheduled tasks at the scan frequency you set in step one. Open-source options include Wazuh for endpoint vulnerability detection, and Greenbone Community Edition for scheduled network scans managed through its vulnerability management service. Configure scan targets, credentials and schedules so the tasks match the ODP values. The output is a scan configuration export and a first completed scan run for each target group.
Keep vulnerability feeds current
Detection is only as good as the vulnerability data behind it. Confirm that each tool pulls from a maintained source, or that an offline copy is refreshed on the update frequency you defined. Fleet, for example, matches installed software against sources including the NVD and OSV, while Wazuh uses its CTI repository or a locally hosted offline copy. For air-gapped environments, document the process and schedule for importing updated feed data. The output is a feed update log showing the last successful update and the update frequency in effect. Assessors commonly ask for this log, so keep it as a routine record.
Consolidate findings and assign remediation
Send findings from all scanners into one place so duplicates are removed and each issue has one owner. DefectDojo can import reports from many tools and deduplicate findings, which keeps the remediation queue accurate. Assign each finding to the system owner with a due date based on the response time set in step one, and record any risk acceptance or compensating action with an approver. The output is a tracked findings register showing open, remediated and accepted items, with the response time that applied to each. Remediation evidence, such as patch records and rescan results, should be attached to the item before it is closed.
Review results and tune the cycle
On the review cadence defined in step one, the security owner examines open findings, overdue items and scan coverage gaps. Check that new assets appeared in the inventory, that failed or incomplete scans were rerun, and that the feed update log shows no missed updates. Adjust schedules or response times where the record shows they are not being met, and document the change and its approver. The output is a dated review record with decisions, which is the evidence that the requirement operates over time and not only at the moment of an assessment.

Why the scan records and remediation trail matter more than the scanner

An assessor testing 03.11.02 is not asking which scanner your organization bought. The question is whether the system was monitored and scanned at the frequencies your organization defined, whether new vulnerabilities were picked up when they were identified, whether the scanned set was updated on schedule, and whether each finding was remediated within the response time your organization set. Because the four organization-defined parameters (ODPs) for this requirement are chosen by your organization, the schedule and response times you write down are the yardstick. If no values are documented, there is nothing to measure against, so confirm the four values with your assessor before the assessment starts.

The evidence that answers those questions is a chain, not a single report. A scan result from a tool such as Greenbone Community Edition or DefectDojo should lead to a ticket, the ticket should show the date the finding was triaged and the owner, and the change record should show when the patch or configuration change went live and was verified by a rescan. Where a finding cannot be fixed inside the response time, the decision needs its own record, and if it is carried as a plan of action and milestones entry, the entry must meet the conditions in 32 CFR 170.21 for the CMMC context. Confirm with your assessor whether they will accept the POA&M route for this requirement in your scope, because the rules for Rev. 2 and Rev. 3 assessments differ in how they treat open items.

A missed remediation window becomes a finding because the assessor can compare the scan date with the closure date and find the gap. Illustratively, a critical finding detected on a Monday that is still open after the response time you set, with no exception approved and no rescan showing it closed, is the kind of record that fails the test regardless of how sophisticated the scanner was. Before the assessment, run a sample check: pick several findings across different severity levels, trace each one from scan to ticket to change to rescan, and confirm that the timestamps match your documented ODPs. Gaps you find this way are much cheaper to explain than gaps an assessor finds.

Evidence that satisfies 03.11.02 and how to keep it current

An assessor testing 03.11.02 looks for records that show the organization defined its vulnerability parameters, ran scans on schedule, and acted on results within its own response times. The cards below cover each artifact and how to keep it accurate between formal assessments, so that the evidence reflects routine operation rather than a last-minute collection effort.

Written ODP assignments

Record a value for each of the four organization-defined parameters in 03.11.02: the monitoring frequency, the scanning frequency, the remediation response times, and the frequency for updating the set of vulnerabilities to be scanned. NIST does not assign these values, so an assessor will expect a signed or approved document that states them. Review the document whenever the system boundary, asset classes or risk tolerance changes, and record the date and approver of each revision.

Scan schedules and configuration exports

Export the scan task definitions, target lists and schedules from the scanning tools so the configured behavior can be compared with the written parameters. A mismatch, such as a weekly schedule where the policy says daily, is a common finding. Export on a fixed cadence, store the exports in version control or a locked evidence repository, and diff each export against the previous one to catch silent changes.

Dated scan reports

Keep the completed scan reports with their start and end times, the targets covered, the scanner and plugin or feed version used, and the authenticated or unauthenticated scan mode. Reports show the scanning actually happened at the defined frequency and covered the monitored assets. Archive them on the schedule the organization sets, and confirm that reports from scans that failed or were incomplete are kept rather than discarded.

Feed and signature update logs

Vulnerability data changes constantly, and 03.11.02 requires the set of vulnerabilities to be scanned to be updated at a defined frequency and when new vulnerabilities are reported. Keep logs showing when each vulnerability feed, plugin set or advisory source was synchronized, including failed syncs and any offline copies used in disconnected environments. A gap in these logs suggests scans ran against stale vulnerability data.

Remediation tickets with timestamps

Each finding that requires action should have a ticket that records when it was detected, assigned, remediated or accepted, and who closed it. Compare the timestamps against the organization's response times to show whether remediation met the defined windows. Link tickets to the scan report and finding identifiers so an assessor can trace a finding from detection through closure without relying on verbal explanation.

Exceptions and POA&M records

When a vulnerability cannot be fixed within the response time, document a risk acceptance or a plan of action and milestones with an owner, a compensating control, and a target date. Review open exceptions at a regular interval and close or re-approve them. For CMMC Level 2 work, confirm with the contracting officer or assessor how the scoring rules in 32 CFR 170.21 apply before carrying a 3.11.2 finding on a POA&M, because that requirement carries a specific limit on Conditional status.

What meeting 03.11.02 costs in money and effort

This table breaks down the cost and effort components of meeting 03.11.02, showing who is paid for each, whether it is one-time or recurring, and what drives it up or down. Use it to build a quote request and to see where open-source tooling removes license spend while labor and assessment costs remain.

Cost component	Who is paid or who carries the effort	One-time or recurring	What drives it
Scanning and monitoring tooling	Open-source platforms carry no license fee, but hosting, storage and any commercial feeds or support contracts are paid to vendors or cloud providers	Setup one-time, hosting recurring	Choice of tools, number of monitored endpoints, and whether a locally hosted offline vulnerability copy is needed
Asset inventory and scan scoping	Internal IT or platform engineers, or an implementation partner preparing the inventory and scan targets	One-time, then recurring as assets change	Asset count, endpoint diversity across operating systems and applications, and how current the CMDB is
Scan configuration and scheduling	Engineering time to define scan frequencies, credentials and schedules for each ODP value	One-time, with periodic review	Number of defined ODP values, scan depth, and the number of distinct network segments
Remediation labor	Patching teams and application owners, typically internal staff	Recurring	Volume of findings, severity mix, and whether the defined response times are short enough to require out-of-cycle work
Findings triage and deduplication	Security analysts reviewing results, often supported by a findings management platform	Recurring	Scanner overlap across tools, quality of per-tool hashcode fields, and how often the same findings reappear
Evidence upkeep	Compliance or security staff keeping scan reports, schedules and remediation records ready for review	Recurring	Number of systems in the assessment boundary and how often assessors sample records
External scanning or penetration testing	Independent testing providers, if the organization or its contract requires outside testing	Recurring per test cycle	Scope of external exposure, test depth, and the frequency the organization or contract sets
Assessor sampling	Independent assessors, paid by the organization for the assessment engagement	Recurring per assessment cycle	Number of systems sampled, depth of evidence reviewed, and whether scan records are complete and consistent

Which self-hosted open-source tools produce 03.11.02 evidence

Wazuh addresses the monitoring side of 03.11.02 for endpoints. Each monitored system runs an agent that collects a software inventory, and the Wazuh server correlates that inventory with the Wazuh CTI vulnerability repository or a locally hosted offline copy. That gives an assessor a running record of which operating system and application vulnerabilities were identified on each endpoint, and when.

Inventory-driven detection: Findings depend on the package inventory each agent reports, so unmanaged or agentless devices fall outside the record.
Offline operation: A locally hosted copy of the vulnerability content supports environments that cannot reach external feeds, which is relevant to CUI enclaves with restricted egress.
Scope of coverage: Wazuh detects operating system and installed application vulnerabilities on monitored endpoints, not network services that never run an agent.
Licensing: Wazuh is GPL-2.0-only. Confirm with counsel how that license applies to any modifications or redistribution in your environment.
Feed confirmation: Confirm which vulnerability sources are enabled, how often they update, and whether your operating systems and applications appear in them.

Before relying on this evidence, check that every in-scope system has an agent and that the feed update schedule matches the frequencies your system security plan defines for 03.11.02.

Where organizations fail 03.11.02 and how to close each gap

Most 03.11.02 failures are not missing scanners. They come from undefined parameters, incomplete inventories, and remediation that cannot be proven. Each card below names one gap, why it weakens the requirement, and the action that closes it before an assessor arrives.

Undefined ODP values

03.11.02 has four organization-defined parameters: the monitoring frequency, the scanning frequency, the remediation response times, and the frequency for updating the set of vulnerabilities to be scanned. NIST does not assign these values, and if the federal agency does not specify them, the organization must. Write each value into the system security plan with a named owner, then confirm the assessor's ODP determination checks will find those values in the document. A blank parameter fails the requirement even when scanning runs daily.

Incomplete asset inventory

A scanner only evaluates the hosts it knows about. If the asset list omits cloud instances, build servers, network devices, or laptops that handle CUI, those systems are never monitored and the gap is invisible in dashboards. Reconcile the scanner's target list against the configuration management inventory and the cloud account listing each quarter. Record the reconciliation as evidence, because an assessor will ask how new assets enter scope.

Scans that skip endpoints

Network scans often cover servers and miss user endpoints, which are where many installed applications and browser plug-ins sit. Agent-based detection closes this gap by reporting the software inventory from each device. Wazuh correlates each agent's inventory with its vulnerability repository, and Fleet matches installed software on enrolled hosts. Confirm that every system holding CUI reports to at least one of these inventories, and document any exception with compensating monitoring.

Stale vulnerability feeds

Detection is only as current as its data source. A vulnerability repository that was last synchronized months ago reports clean results for flaws disclosed since then. Set the update frequency for vulnerability data and scan definitions as a documented ODP, and check the last-update timestamp before each review cycle. For offline or air-gapped environments, schedule the process for refreshing a locally hosted copy and keep a record of each import.

Remediation without timestamps

The requirement expects vulnerabilities to be remediated within defined response times, and assessors test that with dated records. A finding that shows only a status change, with no detection date, severity, owner, or closure date, cannot show timeliness. Configure the findings tracker to record each of those fields and retain the history. Deduplicating imported results in DefectDojo keeps one finding per vulnerability, so the age of each item stays accurate across scanner runs.

POA&M misuse for Conditional status

Under the CMMC scoring methodology, 3.11.2 (RA.L2-3.11.2) carries 5 points and cannot be placed on a plan of action and milestones to reach Conditional status. Teams sometimes list an overdue scan finding as a planned item and assume the score is protected. Check the CMMC rules for the current status before relying on any POA&M entry, and fix the scan or remediation gap before the assessment rather than documenting it as open work.

Common questions about 03.11.02 cost, effort and scope

Can we run 03.11.02 vulnerability monitoring and scanning in-house?

Yes, most organizations can run the activity in-house, but the organization owns the outcome either way. The requirement asks for monitoring, scanning, a defined scan set, and remediation within response times you define. Open-source tools such as Wazuh, Fleet, DefectDojo and Greenbone Community Edition can cover parts of that workflow. The harder work is usually staffing the triage and remediation loop, keeping asset inventories accurate, and writing the procedures and records an assessor will examine. Decide early which parts your team can sustain week to week and which you want an implementation partner to build and document first.

How long does it take to get 03.11.02 working, and what drives the effort?

The timeline depends on the size and variety of the estate, not on a fixed template. Effort rises with the number of endpoints, operating systems and applications in scope, the number of scanning sources, how many systems are already inventoried, and how well existing patching is documented. Remediation workload is often the largest variable because it depends on how many findings exist and how many owners must act on them. Ask any partner to size the work from a written scope that lists assets, tools, reporting needs and the response times you intend to set.

What does a partner need from our team to scope this work?

A partner needs access to the people and records that show how your systems are currently monitored and patched. Expect to provide an asset or software inventory source, a list of system boundaries that handle CUI, existing scanner or endpoint tool configurations, patch and change records, and the names of people who review scan results and approve remediation. A named owner for the requirement, with authority to set the ODP values, speeds decisions. Access to cloud accounts or data center networks inside your environment is also needed, since DeployOpen works inside the client's own infrastructure.

Did 03.11.02 change from Rev. 2 to Rev. 3?

Yes, the change is significant. Rev. 3 folded the Rev. 2 remediation requirement, 3.11.3, into 03.11.02, so monitoring, scanning, response times and keeping the scanned vulnerability set current now sit in one requirement. NIST's change analysis classifies the mapping from Rev. 2 3.11.2 as significant, with more detail and foundational tasks. Importantly, the CMMC Level 2 practice RA.L2-3.11.2 still follows Rev. 2, and current DoD contract documents name Rev. 2, so contractors in that path still work from the 110 Rev. 2 requirements. Confirm which version your contract specifies before changing your evidence set.

How are ODP values for 03.11.02 chosen?

NIST does not assign organization-defined parameter values, so the organization sets them, unless the federal agency you contract with specifies them. For 03.11.02 there are four: how often the system is monitored for vulnerabilities, how often it is scanned, the response times for remediation, and how often the scanned vulnerability set is updated. Choose values that match your risk appetite, your change windows and the severity of your systems, then record the rationale in your system security plan. Ask your contracting officer whether any values are already specified, because a pending FAR proposal would have DoW publish ODP values for contractors to use.

What recurring costs should we expect after the first assessment?

The recurring cost is mostly internal labor and tool operation rather than a single fee. Ongoing work includes reviewing scan results, tuning scan schedules, keeping the asset inventory current, tracking remediation against your response times, and maintaining records for periodic assessment. If you add a retainer for upgrades, continuous testing or support, that cost follows the written scope agreed in advance. DeployOpen does not publish a price list, so ask for a quote built from the scope, the number of assets, and the support level you need.

Does using open-source tools satisfy the requirement on its own?

No. Tools produce evidence, but the requirement is met through the organization's defined frequencies, response times and follow-through. Wazuh, Fleet, DefectDojo and Greenbone Community Edition can detect vulnerabilities, track findings and store results, but an assessor will also examine your policy, procedures, scan schedules and remediation records. Confirm with each tool's documentation which operating systems and software sources it covers in your environment before you rely on it for evidence.

How DeployOpen scopes and prepares vulnerability scanning evidence

DeployOpen plans, implements, hardens and documents self-hosted vulnerability monitoring and scanning platforms inside the client's own cloud accounts, data centers or air-gapped networks, under a fixed scope agreed in writing before work starts. For 03.11.02, the scope decision that matters most is which tools will monitor and scan which systems, because the organization must define the four organization-defined parameters (the monitoring frequency, the scanning frequency, the remediation response times and the frequency for updating the set of vulnerabilities to be scanned). NIST does not assign those values, so the organization sets them, and the written scope should record who approved each one and where it is documented.

In practice, a scope usually names the asset inventory that feeds scanning, the agent-based and network-based tools in use, the ticketing or findings system that tracks remediation, and the retention location for scan results. Candidate components include Wazuh for endpoint vulnerability detection, Fleet for host software inventory, Greenbone Community Edition for network scanning and DefectDojo for consolidating findings. The engagement should confirm which of these the client actually needs, since each adds deployment and upkeep effort. DeployOpen prepares evidence for an assessor, such as scan schedules, configuration records, scan results, remediation tickets and the ODP values in use. An independent assessor or certification body reviews that evidence and issues any report. DeployOpen does not issue audit reports or certifications. Security testing is a separate, optional service. An organization may want an independent test of its scanning coverage or its remediation process, and that work is scoped and priced on its own. Ongoing support, upgrades and continuous testing are available as a retainer, which suits organizations that must keep scan sets current and maintain evidence between assessments. Ask for the written scope, the list of deliverables, the evidence each deliverable produces and the responsibilities split before signing.

03.11.02 Vulnerability monitoring and scanning