CMMC Level 2 Practice 3.11.2: Scan for vulnerabilities in organizational systems and applications periodically and when new

CMMC Level 2 Practice 3.11.2 requires you to run vulnerability scans on the systems and applications in your CUI environment on a defined schedule and also whenever meaningful changes or new vulnerabilities could affect you. Operationalize it by defining scan scope, tool coverage, trigger events, remediation SLAs, and evidence collection that proves scans happened and findings were handled. ¹

Key takeaways:

• Define “periodic” in writing, align it to asset criticality, and prove execution with scan logs and tickets. ¹
• “When new” means event-driven scans after material changes and when new relevant exposures appear, not just a calendar scan. ¹
• Assessors look for coverage gaps (cloud, endpoints, network devices, apps) and for closed-loop remediation evidence. ²

The fastest path to meeting the cmmc level 2 practice 3.11.2: scan for vulnerabilities in organizational systems and applications periodically and when new requirement is to treat vulnerability scanning as an operated control with measurable, repeatable outputs: scope, cadence, triggers, and proof. You are being asked to do two things: (1) run vulnerability scans on organizational systems and applications on a defined schedule, and (2) run scans when conditions change in a way that could introduce new weaknesses or expose you to newly disclosed issues. ¹

For a CCO or GRC lead, the operational challenge is rarely “buy a scanner.” It is preventing blind spots (like unmanaged endpoints, ephemeral cloud assets, or externally hosted applications), and creating assessment-ready evidence that connects scanning to remediation decisions. CMMC Level 2 maps to NIST SP 800-171 Rev. 2 practices and is implemented in the context of handling CUI for the DoD supply chain, so you should anchor your approach in the CUI environment boundary and the system security plan (SSP). ^{3 2 1}

Regulatory text

Excerpt (as provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.11.2 (Scan for vulnerabilities in organizational systems and applications periodically and when new).” ¹

What the operator must do:
You must (a) define which systems and applications are in scope for vulnerability scanning, (b) run scans on a recurring basis (“periodically”), and (c) run scans based on change or newly relevant risk (“when new”). Then you must keep evidence that scans occurred and that you triaged and acted on results. ^{1 2}

Plain-English interpretation

This requirement expects a living vulnerability discovery process. A calendar-based scan alone is not enough if you deploy new servers, publish new internet-facing services, add a new application module, or make network segmentation changes that alter exposure. “Organizational systems and applications” includes endpoints, servers, network devices, and applications that store, process, or transmit CUI, plus supporting components inside the CUI boundary that could be used to access CUI. ^{1 3}

What assessors generally want to see is that you can answer three questions with artifacts:

1. What did you scan?
2. When did you scan it (scheduled and event-driven)?
3. What did you do about what you found? ²

Who it applies to (entity and operational context)

Entity types: Defense contractors and other federal contractors handling CUI who are pursuing or required to meet CMMC Level 2. ^{3 2}

Operational context (where it lands in the org):

• IT/SecOps owns tooling, scan execution, and technical triage.
• System owners / app owners own remediation decisions, maintenance windows, and exception rationales.
• GRC/Compliance owns the written requirement interpretation, SSP alignment, evidence retention, and assessment readiness. ²

Typical in-scope assets:

• Endpoint fleets (workstations used by engineers, program staff, admins)
• Servers (on-prem and cloud), VMs, containers where applicable
• Network devices (firewalls, routers, VPN concentrators)
• Applications (custom apps, COTS apps, web apps) within the CUI boundary
• External attack surface assets if you host services tied to CUI workflows (document portals, SFTP, identity endpoints) ¹

What you actually need to do (step-by-step)

1) Define scan scope using your CUI boundary

• Start from your SSP and CUI environment boundary: list the systems and applications that store/process/transmit CUI, and the supporting infrastructure that can access them. ¹
• Create an asset inventory view that your scanner can actually target (IP ranges, cloud accounts/subscriptions, container registries, application URLs). If the scanner cannot “see” an asset, you cannot prove scanning coverage. ²

Deliverable: Vulnerability Scanning Scope Statement (one page) tied to the SSP boundary. ¹

2) Set your “periodic” scanning cadence and document it

• Choose a cadence by asset class (endpoints vs servers vs network devices vs applications). Write it down in a Vulnerability Management Procedure.
• Ensure authenticated scanning where feasible (credentialed checks produce better results than unauthenticated banner grabs).
• Define how you will handle assets that cannot be scanned (segmented legacy systems, third-party hosted systems). For those, document compensating measures or alternative assurance (for example, provider reports, configuration baselines, or restricted connectivity) without assuming scanning is “impossible.” ¹

Decision point (operator-ready):

• If an asset is inside the CUI boundary and you control it, default to scanning it.
• If a third party controls it, require contractual or technical assurance that vulnerabilities are identified and remediated, and keep the evidence. ¹

3) Define “when new” trigger events (the part most teams miss)

Document event-driven triggers that require an out-of-cycle scan. Examples that map cleanly to the intent of 3.11.2:

• New system or application deployed into the CUI boundary
• Major version upgrade or new feature release
• Network/security architecture change (segmentation changes, firewall rule refactors, new VPN path)
• New internet exposure (new public DNS, new open ports, new load balancer)
• New high-impact vulnerability relevant to your tech stack (for example, affecting your OS, hypervisor, identity service, web framework) ¹

Practical rule: if a change could reasonably alter your attack surface or introduce new code paths, treat it as “when new” and scan. ¹

4) Run scans and create a closed-loop remediation workflow

• Execute scans per schedule and per trigger.
• Normalize findings (dedupe, confirm asset ownership, validate false positives).
• Route findings into a ticketing workflow with:
  • severity/priority
  • required action (patch, config change, compensating control)
  • due date policy (your internal SLA)
  • exception path with documented risk acceptance and time bounds ²

Minimum operator standard: every critical finding must have a documented decision (fix, mitigate, accept) and evidence of completion or ongoing tracking. ¹

5) Prove coverage, not just activity

Assessors regularly see “we scanned” screenshots that don’t show completeness. Build coverage proof:

• % of in-scope assets reporting in the scanner (treat as an internal metric; you don’t need to publish a number externally)
• last scan date per asset group
• exceptions register for unscannable assets with compensating controls ²

6) Operationalize recurring evidence capture (assessment readiness)

Map the requirement to a repeatable evidence package you can regenerate on demand. A simple pattern:

• Monthly evidence folder: exports, reports, and sample tickets
• Change-trigger evidence folder: change record + scan output + remediation ticket(s) ²

If you use Daydream, treat it as the system of record for control mapping and recurring evidence capture so the assessment package is assembled continuously instead of at the end. ²

Required evidence and artifacts to retain

Keep artifacts that prove design and operating effectiveness:

Governance

• Vulnerability Management Policy / Standard (includes periodic cadence and “when new” triggers) ¹
• Vulnerability Scanning Procedure / Runbook (roles, tools, credential handling, triage workflow) ¹
• SSP references showing the CUI boundary and in-scope components ¹

Operational evidence

• Scan schedules (calendar, job schedules, tool configurations) ¹
• Scan outputs (exported reports, raw results, or immutable dashboards) showing date/time, scope, and findings ¹
• Tickets or work items tied to findings (including closure proof) ²
• Change records that triggered “when new” scans (change tickets, deployment records) ¹

Risk decisions

• Exception/risk acceptance register for deferred fixes, with approver, rationale, compensating controls, and review cadence ²

Common exam/audit questions and hangups

Expect these assessor lines of inquiry:

• “Show me your defined periodic cadence. Where is it written, and what did you do last cycle?” ¹
• “What triggers an out-of-cycle scan? Show examples from change records.” ¹
• “How do you know you scanned everything in the CUI boundary? Show coverage and the exceptions list.” ²
• “Do you scan applications or only networks? How are web apps and internally developed apps addressed?” ¹
• “Show remediation follow-through. Pick a finding and walk it to closure.” ²

Frequent implementation mistakes and how to avoid them

1. Scanning only IP ranges and missing cloud or endpoints.
   Fix: align scanner targets to your asset inventory and identity sources (EDR/MDM/cloud inventory) and reconcile gaps routinely. ²

2. No documented definition of “periodic.”
   Fix: write the cadence per asset class in policy/procedure, and keep evidence that the schedule ran. ¹

3. Ignoring “when new” or treating it as “when we remember.”
   Fix: tie triggers to change management. Require a scan step in deployment checklists for in-scope systems/apps. ¹

4. Findings live in a report, not in a workflow.
   Fix: require tickets for material findings, with owners and closure evidence. ²

5. Relying on a third party’s tool without evidence.
   Fix: contract for proof (reports/attestations) or implement technical monitoring that you control, and retain the artifacts. ¹

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. The real risk is assessment failure or delays due to inability to demonstrate scanning coverage and repeatability, plus increased exposure to known vulnerabilities in the CUI environment. CMMC Level 2 is implemented through the DoD CMMC Program and mapped to NIST SP 800-171 Rev. 2 expectations, so evidence quality matters as much as tooling. ^{2 3 1}

Practical 30/60/90-day execution plan

Use this as a sequencing plan; adapt to your environment and assessment window.

First 30 days (stand up the control)

• Confirm CUI boundary and in-scope asset categories in the SSP. ¹
• Publish a Vulnerability Scanning Scope Statement and Vulnerability Management Procedure (cadence + “when new” triggers). ¹
• Validate tooling coverage against inventory (endpoints, servers, network devices, apps). ²
• Create a standard evidence bundle structure (by periodic cycle and by change-trigger event). ²

Days 31–60 (run it and close the loop)

• Execute the first full periodic scan cycle for all in-scope asset groups and export results. ¹
• Stand up ticketing workflow mapping findings to owners and closure states. ²
• Run at least one “when new” scan driven by a real change record, and file the evidence bundle. ¹

Days 61–90 (make it assessment-ready)

• Reconcile scanning coverage gaps and document exceptions with compensating controls. ²
• Add quality checks: authenticated scan coverage where feasible, false-positive handling, and escalation paths. ¹
• Perform an internal walkthrough: pick a finding and trace it from detection to remediation and retest evidence. ²

Frequently Asked Questions

What counts as “periodically” for 3.11.2?

The requirement does not define a fixed interval in the provided excerpt; you must define the cadence in your policy and follow it consistently. Assessors will test whether your stated cadence matches actual scan execution evidence. ^{1 2}

What does “when new” mean in practice?

Treat it as event-driven scanning after material changes and when newly disclosed vulnerabilities are relevant to your environment. Tie triggers to change management so you can show the change record and the resulting scan. ¹

Do I need to scan internally developed applications too?

Yes, the text includes “systems and applications,” so you need a method to identify vulnerabilities in in-scope applications, not only network infrastructure. How you do it can vary, but you must retain evidence that it happens on a schedule and on relevant change events. ¹

If a third party hosts a system that touches CUI, can I rely on their scanning?

You can rely on third-party controls only if you can obtain and retain evidence that vulnerabilities are scanned and managed for the relevant scope. If you cannot get adequate artifacts, reduce exposure by limiting connectivity and documenting compensating controls within your boundary. ¹

What evidence is strongest for an assessor?

Time-stamped scan outputs showing scope and results, plus tickets that show triage and closure, plus a written procedure defining cadence and triggers. Assessors also respond well to an exceptions register that explains any assets you cannot scan and how you manage the risk. ^{2 1}

How do I prevent “scan but no remediation” from becoming a finding?

Require an owner and disposition for material findings (fix, mitigate, accept) and keep closure proof or risk acceptance documentation. Build a retest step after remediation and retain the retest evidence with the original finding. ^{2 1}

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170