CMMC Level 2 Practice 3.11.3: Remediate vulnerabilities in accordance with risk assessments

CMMC Level 2 Practice 3.11.3 requires you to fix identified security weaknesses based on documented risk, not guesswork or patching by habit. To operationalize it, you need a repeatable workflow that turns vulnerability findings into risk-ranked remediation tickets, tracks exceptions, and preserves evidence that actions matched your risk assessment and timelines. ¹

Key takeaways:

• You must prioritize and remediate vulnerabilities based on risk assessments, not severity scores alone. ¹
• Assessors will look for closed-loop evidence: detect → assess risk → remediate or formally accept risk → verify. ¹
• “Missing implementation evidence” is a known failure mode; build recurring evidence capture into operations. ²

For most CMMC Level 2 programs, vulnerability management exists in some form, but 3.11.3 is where teams fail assessments: they scan, they generate reports, and then remediation happens inconsistently or without a defensible link to risk. This practice forces discipline. You need to show that you remediate vulnerabilities in accordance with risk assessments, meaning you (1) evaluate findings in the context of your environment and CUI exposure, (2) prioritize remediation work based on that risk, and (3) either fix, mitigate, or formally accept risk with approvals and compensating controls.

Operationally, this requirement touches IT operations (patching, configuration changes), security (scanning, triage, validation), governance (risk acceptance, exception handling), and third parties (managed service providers, SaaS platforms, vulnerability scanning vendors). It also ties directly to assessment readiness: CMMC assessments favor evidence that is routine, time-stamped, and attributable, not one-off cleanups.

The fastest path to compliance is to implement a closed-loop vulnerability remediation workflow, write down decision criteria, and collect the artifacts automatically each cycle. ²

Regulatory text

Excerpt (provided): “CMMC Level 2 practice mapped to NIST SP 800-171 Rev. 2 requirement 3.11.3 (Remediate vulnerabilities in accordance with risk assessments).” ¹

Operator meaning:
You must (a) identify vulnerabilities, (b) assess the risk they create in your specific environment (including CUI impact), and (c) remediate in a way that matches that risk decision. “In accordance with risk assessments” is the key phrase: the assessor is checking that your remediation priorities, timelines, and exceptions are justified by a documented risk process, not by convenience. ¹

Primary program context: CMMC is implemented under the DoD CMMC Program and codified in the CMMC Program rule structure. ^{3 2}

Plain-English interpretation

You need a vulnerability remediation program that can answer, with evidence:

1. What did you find? (scanner results, alerts, advisories)
2. How did you decide what matters most? (risk assessment + context: asset criticality, exploitability, exposure, CUI boundary)
3. What did you do about it? (patch, config change, compensating control, or risk acceptance)
4. How do you know the fix worked? (re-scan, verification, change record)
5. What happens if you can’t fix it quickly? (exception workflow with approvals and expiration)

If your current state is “high/critical gets patched when we can,” you likely have a gap: severity scoring is an input to risk, but it is not your risk assessment.

Who it applies to

Entities: Defense contractors and other organizations seeking or maintaining CMMC Level 2 for contracts involving Controlled Unclassified Information (CUI). ^{2 3}

Operational scope (what systems):

• Systems that store, process, or transmit CUI, plus supporting security tooling and infrastructure in the CUI enclave/boundary you defined for CMMC Level 2. ¹
• Systems managed by third parties (MSPs, hosting providers, SaaS) when they are in the CUI workflow or provide security-relevant services. Your obligation is to manage the risk and ensure remediation occurs, even if the fix is executed by a third party. ¹

Owners who must participate:

• Security/GRC: defines risk method, exception rules, evidence expectations.
• IT Ops/Engineering: implements patches and configuration remediations.
• System owners: accept risk and approve downtime or compensating controls.
• Procurement/TPRM: routes third-party remediation obligations through contracts and SLAs where applicable.

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

1) Define your vulnerability intake sources

Create an inventory of where vulnerabilities come from, such as:

• Authenticated vulnerability scans (internal/external)
• SAST/DAST (if applicable)
• Cloud security findings
• Vendor advisories for products in your environment
• Pen test or assessment findings

Control point: Document the tools and scan cadence you use as part of your operating procedure and assessment package. ²

2) Establish a risk assessment method for vulnerabilities

Document a lightweight method that translates findings into risk-ranked remediation. Keep it implementable:

• Asset criticality (CUI system vs non-CUI)
• Exposure (internet-facing, remote access, segmented internal)
• Exploitability (known exploit, weaponized, compensating controls present)
• Business impact (confidentiality of CUI, mission impact)

Create a simple decision matrix (example):

Input	Example rule	Output
CUI boundary + internet-facing	Any internet-exposed service in the CUI enclave	Highest remediation priority
Internal-only + strong compensating controls	Segmented, MFA, no inbound	Lower priority, still tracked
Third-party owned	SaaS vulnerability disclosure	Track, demand remediation, document vendor response

Your assessor wants to see that this matrix exists and is used consistently. ¹

3) Convert findings into tracked remediation work

For each vulnerability (or logical group of related findings), open a remediation ticket with:

• Unique ID, system, owner, discovery date
• Risk rating (based on your method)
• Planned remediation action (patch/config/mitigation)
• Target date based on risk
• Link to change management record (if applicable)

Practical tip: Grouping reduces noise, but do not group across different risk contexts (example: don’t bundle workstation patching with an exposed server vulnerability).

4) Remediate, verify, and close the loop

For each ticket:

• Implement fix (patch/config)
• Validate (re-scan, config validation, EDR policy confirmation)
• Capture proof of closure (before/after scan excerpt, change record, command output, screenshot, or tool-generated “fixed” state)
• Close ticket with evidence attached

This “detect → fix → verify” loop is the backbone of 3.11.3. ¹

5) Run an exception and risk acceptance process (for what you can’t fix)

Some vulnerabilities cannot be remediated quickly (legacy systems, vendor dependency, operational downtime). You still must manage them “in accordance with risk assessments,” which means:

• Document why remediation is delayed or infeasible
• Document compensating controls (segmentation, firewall rules, virtual patching, disabling feature)
• Record formal risk acceptance with an approver, expiration/review trigger, and monitoring plan

Assessor hangup: “We decided to accept the risk” is not sufficient without approvals and an expiry/review mechanism. ¹

6) Make evidence capture recurring, not manual

Your biggest operational risk is missing evidence over time. Build recurring exports/snapshots:

• Monthly (or per scan cycle) vulnerability summary
• Ticket aging report by risk
• Exception register with approvals and expirations
• Sample closure packets (before/after)

Daydream fits here as the system to map 3.11.3 into a documented control operation and recurring evidence capture, so you are not reconstructing proof during the assessment window. ²

Required evidence and artifacts to retain

Keep artifacts that show both decisioning and execution:

Core artifacts (expected in most assessments)

• Vulnerability management procedure (roles, tools, workflow, SLAs/targets by risk)
• Latest vulnerability scan reports (authenticated where applicable)
• Vulnerability risk triage methodology (matrix or written criteria)
• Remediation ticket records (open/closed), including owners and dates
• Verification evidence (re-scan results, configuration baselines, patch reports)
• Risk acceptance/exception register with approvals and expiration triggers

Supporting artifacts (strong differentiators)

• Asset inventory with CUI boundary tagging
• Change management records linked to remediation
• Third-party correspondence or SLAs for remediation when a provider owns the fix
• Metrics that show the workflow is operating consistently (trend lines are helpful, but don’t invent stats)

Common exam/audit questions and hangups

Assessors often probe these areas for 3.11.3: ¹

• “Show me one vulnerability from discovery through closure, including risk rationale.”
• “How do you decide remediation priority beyond CVSS or ‘critical/high’?”
• “Which systems are in scope for CUI, and how does that affect prioritization?”
• “Where are exceptions documented, who approves them, and when do they expire?”
• “How do you verify remediation worked?”
• “How do you ensure third-party-managed components are remediated?”

Hangup pattern: Teams can produce scan output, but not the linkage to risk decisions and closure evidence.

Frequent implementation mistakes and how to avoid them

Mistake	Why it fails 3.11.3	Fix
Treating scanner severity as “risk assessment”	Risk must be contextual to your environment	Add asset criticality + exposure + CUI impact to triage criteria
No exception workflow	Unremediated findings linger without justification	Create a risk acceptance template with approvals and expiration
No verification step	You can’t prove remediation occurred	Require re-scan or validation evidence before closure
Evidence scattered across tools	Hard to prove consistent operation	Standardize closure packets and recurring exports 2
Third-party issues ignored	You still own the risk	Track third-party vulnerabilities and document provider remediation commitments

Enforcement context and risk implications

No public enforcement cases were provided in the source catalog for this specific practice. Keep your risk framing tied to CMMC program expectations and assessment outcomes under the DoD CMMC Program. ^{2 3}

Practical risk: failure to show repeatable remediation tied to risk can drive assessment findings, delay certification, and create contract friction. Treat 3.11.3 as an operational control with governance, not a one-time cleanup.

Practical 30/60/90-day execution plan

First 30 days (stabilize and document)

• Confirm CUI boundary and in-scope asset inventory for vulnerability management prioritization. ¹
• Document triage criteria that turns findings into a risk rating tied to environment context.
• Stand up a single remediation tracking mechanism (ticketing or GRC workflow).
• Define exception/risk acceptance template and approvers.

Days 31–60 (operate the workflow and collect proof)

• Run a scan cycle and create tickets for findings in scope.
• Remediate a representative set across endpoints, servers, and network devices.
• Require verification evidence for closures.
• Start an exception register with expirations and compensating controls where needed.

Days 61–90 (make it repeatable and assessment-ready)

• Produce recurring evidence packs: scan summary, aging by risk, closure samples, exception register.
• Tune triage criteria based on what created bottlenecks.
• Test assessor-style sampling: pick a few findings and ensure you can show the end-to-end story fast.
• Map the practice in Daydream to a documented control operation with recurring evidence capture, so the system stays audit-ready between scan cycles. ²

Frequently Asked Questions

Does “in accordance with risk assessments” mean I need a formal enterprise risk management program?

No, but you do need a documented method for assessing vulnerability risk in your environment and evidence that remediation followed that method. Keep it simple, consistent, and tied to your CUI scope. ¹

Is CVSS enough to satisfy the risk assessment part?

CVSS can be an input, but assessors expect environmental context such as exposure, asset criticality, and CUI impact. Document how you adjust priorities based on that context. ¹

What evidence is most persuasive to an assessor for remediation?

A closed ticket that includes the original finding, the risk rationale, the change record, and verification (re-scan or validation output). Random scan PDFs without linkage to action usually create follow-up questions. ¹

How do I handle vulnerabilities owned by a third party (like SaaS or an MSP)?

Track the finding internally, document the provider’s remediation commitment, and retain communications or SLA terms that show ownership and status. Your obligation is to manage the risk and demonstrate governance even when you don’t apply the patch. ¹

Can I accept risk instead of remediating?

Yes, when justified by your risk assessment, but you need formal approval, compensating controls where appropriate, and a defined review/expiration trigger. Keep risk acceptances time-bound in practice, even if your template uses events instead of dates. ¹

What’s the fastest way to avoid the “missing evidence” failure mode?

Build recurring evidence capture into the workflow: standardized closure packets, periodic exports of ticket aging, and a live exception register. Tools like Daydream help by mapping 3.11.3 to a documented control operation with recurring evidence capture. ²

Footnotes

1. NIST SP 800-171 Rev. 2

2. DoD CMMC Program Guidance

3. 32 CFR Part 170