Requirement 3.11.2 says to scan for vulnerabilities periodically and when new vulnerabilities affecting the system are identified. It does not prescribe a universal quarterly schedule. The organization therefore has to choose a cadence, define what triggers out-of-cycle work, and prove that the process covers the assessed environment.
A scan report with thousands of findings can still be weak evidence if half the assets were unreachable, authentication failed, cloud workloads were omitted, or the result cannot be tied to the inventory. Coverage and repeatability matter as much as the scanner's severity labels.
Start with the assessed asset and application population
Build the scanning population from the CMMC scope, not from whatever subnet happens to be configured in the scanner. Include relevant servers, workstations, network devices, security appliances, virtualization hosts, cloud workloads, and other in-scope systems that can be meaningfully scanned. Reconcile scanner targets to the asset inventory so exclusions are explicit.
The wording also includes applications. Infrastructure scanning alone may not identify weaknesses in web applications, internally developed software, exposed APIs, or application dependencies. Decide which application-oriented techniques are appropriate: authenticated application scanning, software composition analysis, dependency checks, code review, or other vulnerability-identification methods aligned to the technology.
Document technical limits. An OT device, printer, fragile appliance, or vendor-managed service may not tolerate the same active scan used on a Windows server. A justified alternate method or controlled scan profile is stronger than silently omitting the asset and later discovering it was in scope.
Define the periodic cadence and show why it is real
The requirement says periodically, but does not give every contractor a single mandated interval. Define the frequency in policy or procedure, align it to risk and operational reality, and configure the tool or calendar to execute it. The chosen cadence should be specific enough that a missed scan can be identified instead of hidden behind wording such as 'from time to time.'
Account for devices that are often off network. Remote laptops, traveling systems, lab equipment, and rarely powered servers can repeatedly miss a scheduled network scan. Use an agent, make-up scan, VPN-based scan, maintenance window, or other method so the scan coverage report can distinguish temporarily absent assets from permanently forgotten ones.
Measure completion. Track scheduled jobs, failure status, target counts, credential failures, and assets not seen. A scan that launches successfully but authenticates to only half the servers may provide far less depth than expected. Keep exceptions and follow-up work visible; deleting failed results from the evidence set hides coverage problems.
Create a second path for newly identified vulnerabilities
Periodic scanning is only half of 3.11.2. The second trigger is the identification of new vulnerabilities affecting organizational systems and applications. Establish how the company learns about them: vendor advisories, CISA alerts and catalogs, scanner intelligence, security-provider notifications, software-maintainer feeds, or other trusted sources relevant to the stack.
Then determine applicability. A newly published vulnerability in a product the company does not use is not the same as a vulnerability affecting an exposed VPN appliance in the CUI boundary. Keep enough inventory detail—product, version, operating system, application dependency, or service ownership—to make the applicability decision quickly.
When a relevant high-impact issue appears between routine scan cycles, run the needed targeted scan, query, configuration check, or validation instead of waiting for the next periodic job. Record the trigger, affected population, method used, date, and outcome. That evidence demonstrates the 'when new vulnerabilities are identified' portion as well as the periodic portion.
Use credentials and scan depth intentionally
Where technology supports it, authenticated or credentialed scanning can reveal missing patches, weak configuration, installed packages, and local conditions that an external probe cannot see. Protect scanner credentials as privileged technical identities: limit where they can log in, store secrets securely, rotate them when needed, and prohibit ordinary interactive use.
Do not assume every scan must be credentialed in exactly the same way. Network devices, cloud services, containers, appliances, and applications may require different methods. Define the expected depth for each class and verify the tool is actually achieving it. A dashboard showing 'green' because credentials failed is not reliable evidence.
Consider the scanner itself part of the security architecture when it has broad read or administrative access. Document who administers it, how its credentials are protected, how target changes are approved, and how scan data is retained. Vulnerability reports can reveal sensitive information about the environment even when they do not contain CUI.
Treat scan blind spots as findings of their own
Review the scanner's coverage errors after every meaningful run: unreachable hosts, credential failures, unsupported operating systems, excluded networks, cloud assets outside the connector, applications that need a separate testing method, and devices that were powered off. A clean dashboard can hide a weak scan if those failures are not surfaced.
Maintain an explicit exception path for assets that cannot be scanned safely or with normal tooling. Record why, what alternative assessment is used, who approved it, and when the exception will be reviewed. This is especially important around fragile OT, specialized assets, and vendor-managed appliances.
- Unreachable or offline assets
- Authentication/credential failures
- Unsupported operating systems or appliances
- Cloud resources outside scanner coverage
- Applications requiring separate testing
- Approved safety or availability exclusions
Keep scanning separate from remediation governance
Scanning discovers conditions. Requirement 3.11.3 addresses remediating vulnerabilities in accordance with risk assessments, while 3.14.1 addresses identifying, reporting, and correcting system flaws in a timely manner. Do not mark 3.11.2 complete merely because a ticket exists, and do not mark it failed merely because a valid exception keeps one finding open. Treat discovery and remediation as connected but separate evidence chains.
Normalize findings so duplicates from different scanners or repeated scan cycles do not hide the real workload. Record asset, vulnerability, severity or risk, first seen, owner, planned treatment, verification status, and exception rationale where applicable. The remediation process should be able to trace a closed finding back to a later scan or other verification that shows the condition was corrected.
Use scanner severity as one input, then add risk information. Exposure, exploitability, mission role, compensating safeguards, and whether the system handles CUI can affect priority. Document the organization's method so assessors can distinguish a deliberate risk decision from an unattended backlog.
Build an evidence package around coverage and repeatability
Prepare the scanning procedure, defined periodic cadence, in-scope target inventory, application coverage, recent successful scan outputs, failed or missed target follow-up, the source used for new-vulnerability awareness, and at least one example of an out-of-cycle applicability check or targeted scan if available. Avoid submitting only a vendor dashboard screenshot with no connection to the assessed scope.
Reconcile counts before the assessment. If the asset inventory lists 140 endpoints and the last report shows 117, explain the 23: decommissioned, off network, separately scanned, technically excluded with an alternate method, or genuinely missed. An unexplained delta invites a much harder scope conversation.
Sample a finding end to end. Show when it was discovered, which asset was affected, how the owner was notified, what decision was made, and how later evidence confirmed the state. This demonstrates that scanning is an operational process instead of a once-a-year evidence-production exercise.
A short working check
- ✓Derive scan targets from the current CMMC scope
- ✓Include applications as well as infrastructure where applicable
- ✓Define a specific periodic scanning cadence
- ✓Track missed, failed, and unauthenticated scan targets
- ✓Monitor trusted sources for newly identified vulnerabilities
- ✓Run targeted checks when a new vulnerability affects the environment
- ✓Protect scanner credentials and administration
- ✓Reconcile findings to remediation and verification records
Common questions
Does CMMC require quarterly vulnerability scans?
NIST SP 800-171 Rev. 2 requirement 3.11.2 says vulnerabilities must be scanned periodically and when new relevant vulnerabilities are identified. It does not establish one universal quarterly cadence for every contractor. The organization should define and consistently execute its cadence.
What should happen when a new critical vulnerability is announced between scans?
Determine whether it affects the environment and, when relevant, perform an appropriate targeted scan, query, or validation rather than simply waiting for the next periodic cycle. Preserve the applicability decision and result as evidence.
Official sources used for this guide
Open the primary source before making a contract-specific decision. Regulations and program implementation can change.
