RA.L2-3.11.3 vulnerability remediation: evidence guide

What RA.L2-3.11.3 vulnerability remediation requires in practice

RA.L2-3.11.3 asks a defense contractor to identify vulnerabilities on systems that process, store or transmit CUI and to remediate them in accordance with its own risk assessments. The requirement is the CMMC Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.11.3, and it is worth 1 point in the scoring methodology under 32 CFR 170.24. Assessors test it against two objectives in NIST SP 800-171A (June 2018): that vulnerabilities are identified, and that they are remediated in line with the risk assessment. Picture a contractor whose CUI enclave has a scan report with several hundred open findings. The requirement does not demand zero findings. It demands a defensible link between what the organization found, how it ranked each issue, and what it fixed, deferred or accepted.

The difficulty is rarely the scanner. Volume overwhelms teams that have no agreed rule for priority, so low-impact findings get patched while exposed, CUI-facing weaknesses wait. Accepted risks are the second trap: a finding marked as not worth fixing in a spreadsheet, with no owner, no rationale and no review date, is hard to defend when an assessor asks for it. The CMMC Assessment Guide Level 2 expects organizations to close the most critical vulnerabilities first, track remediation to completion and track the vulnerabilities they decide not to fix. Before any assessment, confirm that your risk assessment defines severity thresholds and remediation timeframes, and that every open finding can be traced to one of those decisions.

Current status matters for planning. On 13 July 2026 the Department of War suspended CMMC Phase II, which would have required Level 2 C3PAO certification for applicable contracts. Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place, so contractors handling CUI still need working remediation records. The Department has also said it will enforce NIST SP 800-171 Rev. 2 in the interim, even though NIST withdrew Rev. 2 when it published Rev. 3. Confirm the current status of Phase II and the applicable Rev. 2 requirements with your contracting officer and the DoW CIO About CMMC page before you set your remediation program's scope.

Which assets, findings and teams fall under RA.L2-3.11.3

RA.L2-3.11.3 applies to every system that processes, stores or transmits CUI, so the scope starts with an accurate asset inventory. The decisions below determine how much remediation work exists, who must act on it, and which findings reach the assessor's evidence.

Asset inventory that matches the CUI boundary

Start from the system security plan boundary and list every endpoint, server, network device, cloud workload and application that touches CUI. Inventory gaps are the most common reason a vulnerability goes unremediated because no team knows the asset exists. Check that the inventory is reconciled against scanner coverage and that shadow systems, such as test instances and administrative workstations, are either included or documented as out of scope with a reason.

Third-party components and dependencies

Libraries, container base images, firmware and managed services that a CUI system depends on can carry the vulnerabilities an assessor asks about. Record each component with its version and the owner who receives its advisories. Confirm whether vendors patch on their own schedule and whether your contract gives you the right to receive that information in time to act on it.

Risk assessment sets remediation priority

The findings are ranked by the risk assessment, not by scanner severity alone. A critical vulnerability on a system with no CUI exposure may rank below a moderate one on a CUI file server. Confirm that the risk assessment defines criteria for asset value, exposure and threat, and that the ranking method is written down so an assessor can trace each fix to its risk decision.

Asset owners who act on findings

Each in-scope asset needs a named owner who is accountable for patching, configuration changes and exceptions. Without this, findings sit in a queue that belongs to everyone and no one. Confirm that owners have the authority and change windows to remediate, and that assessors can interview them about how findings were handled, since SP 800-171A allows interviews with personnel responsible for remediation.

External service providers and their reports

Managed service providers, cloud platforms and hosting partners that operate part of a CUI system must tell you about their vulnerabilities and remediation status. Define in writing how and how often they report findings, who receives those reports, and how they map to your plan of action. Where a provider only shares summaries, ask what evidence supports the claim that a finding was fixed.

Scanner data and the findings register

Scanner output from several tools must land in one place so that duplicates are merged and each finding has a single status from detection to closure. Open-source platforms such as DefectDojo can import findings from many scanner formats and deduplicate them, which makes it easier to show one trail per vulnerability. Confirm which tools feed the register and that the register is the record an assessor will sample.

How an assessor tests vulnerability remediation against 3.11.3

This table compares the two assessment objectives behind RA.L2-3.11.3, showing how an assessor examines and interviews for each, what evidence to have ready, and where organizations usually fall short. Read each row as one half of the requirement: finding vulnerabilities and then fixing them in line with the organization's own risk assessment. Both halves must be shown with records that agree with each other.

Assessment objective	Test approach and evidence requested	Common findings
Identifying vulnerabilities	Examine scan results, vulnerability reports and the scope of scanned assets, and confirm they match the system boundary. Interview the people who run scans and review findings. Expect to show the risk assessment that the findings feed into.	Scan coverage gaps for assets in the boundary, scan reports that are not retained, or findings that never reach a tracked queue.
Remediating vulnerabilities in accordance with risk assessments	Examine patch and vulnerability management records, remediation tickets with dates and owners, and the risk assessment that sets priority. Check that the most critical items were addressed first. Interview remediation owners on how they chose the order of work.	Fixes applied on a schedule that ignores risk ratings, critical items left open while low items close, or no link between a finding and the risk assessment that justified its priority.
Tracking fixes to completion	Examine ticket history showing each vulnerability moved from detection to verified closure, including re-scan results that confirm the fix.	Tickets closed without verification, or remediation marked complete with no record of the change or the re-scan.
Tracking accepted risks	Examine the signed risk acceptance decisions, their rationale, the approver and any review dates. Confirm that accepted items are linked to a plan of action where the organization intends to correct them later.	Accepted risks with no written decision, no named approver, or no review, and risks quietly deferred without a record.

Implementing risk-based remediation step by step

This sequence turns scanner output and risk ratings into a single tracked register, so the most critical vulnerabilities close first and every fix or accepted risk leaves a record an assessor can follow.

Confirm the risk assessment and its ratings
Start from the current risk assessment, not from raw scanner severity. Confirm which systems and assets carry CUI, how each finding was rated for likelihood and impact, and who approved those ratings. The output is a short ratings record, dated and signed off by the person accountable for the risk assessment, that defines what counts as critical, high, moderate and low for your environment. Your team is done with this step when every rating category has a written definition and an approver. An assessor will ask how the remediation priorities were derived, so this record is the starting point for that answer.
Aggregate scanner findings into one register
Pull results from every in-scope scanner and assessment source into a single findings register. Vulnerability scanners for infrastructure and applications both feed it, along with any manual or penetration test findings. Open-source tools such as DefectDojo can import and reimport findings from many scanner report formats and deduplicate them using per-tool hashcode fields, which reduces the same flaw being counted twice. The output is one register where each finding has an asset, a source, a rating and a first-seen date. Confirm the register covers every in-scope asset, because a gap here means the remediation record cannot be complete.
Assign owners and due dates by risk
Give every finding a named owner responsible for the fix and a target date set by its risk rating. The owner is the person who can change the affected system, such as a platform or application team lead, not the scanner administrator. Set due dates from the ratings record in step one, using the internal timelines your organization defines and can defend. The output is an assigned register with owners, dates and the ratings they came from. Confirm that every critical and high finding has an owner, since unassigned findings tend to stall and an assessor will look for that gap.
Close the most critical vulnerabilities first
Work the register from the top, closing the most critical vulnerabilities before lower-rated ones. Where a fix is not immediately possible, document interim measures such as isolating the asset, restricting access or disabling the affected service, and record them against the finding. The output is a change or patch record for each closed item that names the change, the date and the approver under your change control process. Check that the critical items are closed or have a documented interim measure before the team moves to moderate findings. The CMMC Assessment Guide Level 2 expects the most critical vulnerabilities to be addressed first.
Verify each fix and track it to completion
Do not mark a finding closed when the change ticket is closed. Rescan or otherwise verify the affected asset and confirm that the vulnerability no longer appears. The output is a verification record for each fix, showing the scan or check that confirmed it, its date and the person who reviewed it. Track every item through to verified completion, including items that slipped past their due dates, with the reason and the new date recorded. Assessors commonly ask for this trail, so verification evidence should exist in final form, not as a draft note.
Record each decision not to remediate
Some vulnerabilities will not be fixed, for example where no patch exists, the product is end of life or the fix would break a mission function. Each of these needs a documented risk acceptance: the finding, the reason it stays open, the compensating controls, the approver with authority to accept the risk and a review date. The output is an accepted-risk record kept in the same register so it stays visible. The CMMC Assessment Guide Level 2 expects accepted vulnerabilities to be tracked, so an unrecorded decision is a gap an assessor will find.
Link open items to plans of action
Connect any finding that is not closed at assessment time to a plan of action and milestones under CA.L2-3.12.2, which covers operational plans of action. The register should reference the POA&M entry for each open item, so the remediation record and the plan stay consistent. Confirm that the POA&M states what remains open, the milestones and the responsible owner. This link lets the team drive remediation through the POA&M and shows the assessor that open risk is managed, not ignored.

Which remediation records pass an assessment

An assessor testing RA.L2-3.11.3 looks for a chain of records that starts with a risk-based priority and ends with a verified fix or a documented decision to accept the risk. Each card below is one artifact in that chain, with the checks that keep it current between assessments.

Vulnerability scan results

These are the raw outputs that show which vulnerabilities were found, on which assets, and when. Assessors use them to confirm that identification is happening at the frequency your own system security plan defines. Check that each scan record names the asset, the scanner version, the scan date and the scan policy used, and that scans cover every in-scope system, including those that are not always on the network. Keep the native reports and the scanner's stored results, since a summary alone rarely shows coverage.

Finding register with status history

A finding register holds one row per vulnerability with its severity, owner, due date, and every status change from open to closed. It is the record that proves the most critical vulnerabilities were addressed first and that nothing dropped out of tracking. Check that status changes are dated and attributed, that duplicates from different scanners were merged rather than lost, and that closed items keep their history. Deleting a finding to clean up the list removes evidence an assessor will ask about.

Patch and change tickets showing fixes

A patch or change ticket links a specific finding to the action that fixed it, the change approval, the implementation date and the person who performed it. Assessors compare the ticket against the finding to confirm the fix addressed the stated vulnerability on the stated system. Check that each ticket references the finding identifier, that emergency changes were reviewed afterward, and that the change record does not depend on a chat message or a verbal instruction.

Verification scan results after remediation

A verification scan run after a fix shows the vulnerability no longer appears on the asset. Without it, a closed ticket only shows that someone believes the work was done. Check that the verification scan targets the same asset and uses the same scan policy as the original finding, and that the result is attached to the finding before the status changes to closed. Where a fix cannot be verified by scanning, record the alternative check and who performed it.

Risk acceptance records with approver and rationale

When an organization decides not to remediate a vulnerability, the decision needs its own record. It should state the vulnerability, the affected system, the reason the fix is deferred or not made, the compensating controls, the named approver and the review date. Assessors expect these records to be tracked just like fixes, so an accepted risk that quietly disappears from the register is a finding in its own right. Check that approvers hold the authority your governance documents assign to them and that each acceptance is reviewed before it expires.

Risk assessment that set priority

The risk assessment is the document that explains why one vulnerability was fixed before another. It ties severity to the importance of the affected system and the impact on CUI, which is the reasoning behind the remediation order. Keep the version that was in effect when each priority was set, and update it when the system boundary or threat picture changes. A priority list without a traceable link to this assessment is hard to defend.

What meeting RA.L2-3.11.3 costs in tools, labor and upkeep

This table compares the cost components of remediating vulnerabilities under RA.L2-3.11.3, who is paid for each one, whether it is one-time or recurring, and what pushes it up or down. Use it to build a request for quote, and note that no prices or durations are stated because none were supplied for this requirement.

Cost component	Who is paid	One-time or recurring	Cost drivers and how to reduce them
Scanning and ticketing tools	Software vendor or open-source hosting staff	Licensing recurs; hosting setup is one-time, upkeep recurs	Asset count and finding volume. Self-hosted open source such as Greenbone Community Edition and DefectDojo can remove license spend, but hosting, patching and database upkeep remain. Confirm each tool's license terms before deployment.
Engineering time for patching and verification	Internal IT staff or a implementation partner	Recurring	Patch cadence, number of third-party dependencies, and change control steps. Grouping fixes by system and reusing standard maintenance windows reduces repeated effort.
Triage and prioritization	Security analysts	Recurring	Volume of deduplicated findings and quality of asset criticality data. Deduplication in a findings manager lowers the number of items each analyst reviews.
Remediation register and evidence upkeep	Compliance lead or GRC staff	Recurring	Number of systems in the CUI boundary and how often records are updated. Keeping scan results, tickets and closure evidence in one system avoids rebuilding records at assessment time.
Risk acceptance reviews	Risk owners and leadership	Recurring	Count of findings the organization decides not to fix and how often each acceptance is re-reviewed. Fewer, well-documented acceptances with set review dates keep this cost down.
Plan of action coordination	Compliance lead and system owners	Recurring until closeout	Number of open items tied to CA.L2-3.12.2 plans of action. Linking each open finding to its plan of action early avoids duplicate tracking.
External testing or independent review	Security testing firm or consultant	Often recurring, scope-dependent	Scope of external testing, testing frequency and whether results are reviewed by a third party. Ask whether testing is fixed-scope and what re-testing costs.
Assessor time	Independent assessor or C3PAO	One-time per assessment cycle	Number of in-scope systems, evidence quality and interview time with personnel who remediate vulnerabilities. Organized, final-form evidence reduces follow-up time.

How the POA&M link affects RA.L2-3.11.3 scoring

RA.L2-3.11.3 carries 1 point under the scoring method in 32 CFR 170.24, and it is not on the exclusion list in 32 CFR 170.21(a)(2)(iii). That means an organization can place it on a plan of action and milestones (POA&M) and still pursue Conditional Level 2 status, provided its total score is at least 88 of 110 (0.8). Every POA&M item must close out within 180 days. A single point looks small, but it is the point that keeps a conditional status available, so confirm the current scoring arithmetic in the rule before you count on that margin. Track the score as the assessment would calculate it, not as your internal risk register describes it.

The CMMC Assessment Guide Level 2 links remediation to the plans of action required under CA.L2-3.12.2. It advises closing the most critical vulnerabilities first, tracking every remediation to completion, and tracking any vulnerability the organization decides not to fix. Your vulnerability register, built from scanning results and the risk assessment, should feed the POA&M directly. Each entry should show four things: the vulnerability (identifier, affected asset, and the risk rating from the risk assessment), the planned fix or documented decision to accept the risk, a named owner accountable for delivery, and a closeout date that falls within the 180-day window. An entry missing any of these is hard to defend when an assessor asks how the finding was controlled.

Before you rely on this path, confirm where the program stands. On 13 July 2026 the Department of War suspended CMMC Phase II, but Phase I self-assessments, SPRS postings, annual affirmations and DFARS 252.204-7012 obligations remain in place. The DoW CIO's About CMMC page stated as of 17 October 2026 that implementation is paused and may require only self-assessments at Levels 1 and 2, while the eCFR text of 32 CFR 170.3(e) still shows the original four-phase schedule. Check that page and your contracting officer's requirements at the time of your decision, and ask whether your contract requires a certification assessment or a self-assessment. The answer determines whether a POA&M is a planning tool or a condition of award.

Open-source tools that produce remediation evidence

The assessor for RA.L2-3.11.3 looks for records showing which vulnerabilities were found, how they were prioritized, and what happened to each one. The three open-source tools below can each produce part of that trail, but none of them fixes a system, and each one needs to be confirmed in your own environment before you rely on it.

Centralize findings in DefectDojo

DefectDojo (BSD-3-Clause) imports and reimports findings from more than 500 security tool report formats through its UI or API, including in the open source edition, and it offers a generic findings import for tools without a native parser. It deduplicates findings using per-tool hashcode fields, so a vulnerability reported by several scans appears once. For RA.L2-3.11.3, this gives you one register of findings with status history, which is the record an assessor will ask to see. Confirm that your scanner's output format is supported and that hashcode settings match how you want duplicates handled.

Scan and store results with Greenbone

Greenbone Community Edition (OpenVAS, AGPL-3.0-or-later) uses gvmd as its vulnerability management service. It stores results in PostgreSQL, manages users and permissions, and schedules scan tasks, while analysts review results in the Greenbone Security Assistant web interface. This produces dated scan results that show which assets were examined and what was found, which feeds the identification half of the requirement. Check that scan tasks cover every in-scope asset, and confirm with your legal team what the AGPL-3.0-or-later license requires if you modify and distribute the software.

Map audits with CISO Assistant

CISO Assistant (AGPL-3.0-only) ships more than 200 frameworks, including NIST CSF, PCI DSS and NIS2, and runs audits and compliance assessments against them with automatic mapping between frameworks. You can use it to record how each finding ties to a risk assessment, the decision taken, and the status of the related control. This supports the requirement to remediate in accordance with risk, but the mapping only reflects what the framework data and your configuration say, so verify any cross-framework link before presenting it to an assessor. Confirm that your team holds the license obligations the AGPL-3.0-only terms place on hosted modifications.

In-house, partner or auditor: who does what for remediation

Your organization owns the controls and every decision that determines whether a vulnerability is fixed, accepted or deferred. The requirement asks you to identify vulnerabilities and remediate them in accordance with your risk assessments, so the people who answer for the risk assessment must also answer for the remediation priorities. An outside partner can set up the tools, but it cannot decide that a finding on a CUI enclave may wait for a maintenance window.

Risk decisions: Set the severity thresholds, remediation deadlines and the rule for which findings are critical, tied to your RA.L2-3.11.1 risk assessment.
Fixes and change control: Patch, reconfigure or retire affected systems through your own change process, and keep the change tickets that show the fix happened.
Risk acceptances: Record each finding you decide not to remediate, with the rationale, the approver and a review date.
The POA&M: Own the plan of action entries, owners and closeout dates, and confirm each entry matches a real open or closed finding.
Interviews: Assessors may interview the people responsible for remediation, so those people must be able to explain the process and show records.

Before any assessment, check that a named individual signs each risk acceptance and that every critical finding has a documented outcome.

What buyers ask about RA.L2-3.11.3 cost, effort and outside help

What drives the effort of vulnerability remediation tracking?

The effort is driven mainly by how many assets are in scope, how many findings each scan produces, and how many teams own the systems that need patches. Every finding needs an owner, a severity or risk rating taken from your risk assessment, a target date and a closure record, so the workload grows with the number of open items rather than with the scan itself. Duplicate findings from several tools add work until they are consolidated. Expect the largest effort in the first cycle, when the backlog is cleaned up, and a smaller recurring effort afterward. Ask any outside party to show how it will handle deduplication, ownership and closure evidence before you agree to a scope.

Can a small team run RA.L2-3.11.3 remediation in-house?

Yes, a small team can run it in-house if it has a named owner, a written remediation process tied to the risk assessment, and time set aside for patching and tracking. The practical limit is capacity and continuity: one person who understands the tracker and the scan schedule is a single point of failure. Open-source tools such as DefectDojo can hold findings and records, and Greenbone Community Edition can run scans, but you still need staff to set priorities, approve risk acceptances and verify fixes. An outside implementation partner can set up the tooling and documentation, while your staff keep ownership of decisions and daily work.

How long does preparation take and what sets that duration?

No fixed duration applies to this requirement, and no official figure for preparation time is supplied here. The duration depends on the size of the environment, how mature your patch process already is, whether scanning and a ticketing or tracking system exist, and how many backlog items must be closed or formally accepted before assessment. Organizations with recorded remediation history usually need less preparation than those starting from scattered spreadsheets. Ask for a written plan with milestones, the systems in scope, and the evidence that will exist at the end of each milestone before accepting any timeline.

What does the work need from our own staff?

Your staff must own the decisions that an outside party cannot make for you. This includes system owners who apply patches or approve maintenance windows, security staff who rate findings against the risk assessment, and managers who sign off on accepted risks. Staff also need to keep records current, since assessors look for remediation evidence in its final form. Plan for these people to attend review meetings and to answer interview questions, because SP 800-171A allows assessors to speak with personnel responsible for remediation. Confirm named individuals and their time commitment in the written scope.

Do accepted risks need formal sign-off?

Yes, the CMMC Assessment Guide Level 2 expects organizations to track vulnerabilities they decide not to remediate, and a decision to accept a risk should be documented and approved by an accountable manager. Each accepted risk should record the reason, the compensating controls, the approver, the review date and the conditions under which it must be reopened. Accepted risks that are never reviewed are a common assessment finding. Define your approval authority before the first cycle and confirm it matches your governance documents and system security plan.

What will the auditor do and what will the auditor not do?

An independent assessor tests whether your remediation practice meets the assessment objectives in SP 800-171A, by reviewing scan results, patch and vulnerability records, the risk assessment and the security assessment report, and by interviewing staff. The assessor does not fix vulnerabilities, write your risk decisions, build your tracker or prepare your evidence. Level 2 certification assessments are performed by C3PAOs, and only those independent bodies issue results. An implementation partner prepares systems and evidence, and it does not issue reports or certificates. Confirm the current assessment phase and requirements with the DoW CIO before planning, because the program status has changed.

How DeployOpen scopes and prepares RA.L2-3.11.3 evidence

DeployOpen plans, implements and documents the vulnerability remediation workflow inside your own infrastructure, so that findings are prioritized by risk and every fix or accepted risk leaves a record. We prepare the systems and evidence for your assessment, while your organization owns its controls and an independent assessor or certification body makes the determination.

How we scope

The written scope names the in-scope systems that process, store or transmit CUI and the scanning and ticketing tools involved.
We confirm how your risk assessment ranks vulnerabilities, so remediation deadlines follow your own criteria.
Scope also states who in your organization approves accepted risks and which plans of action item each one links to.

How we build

We configure open-source tools such as DefectDojo to import scan results, deduplicate findings and assign owners by severity.
We set up remediation tracking so each finding carries a status, due date, fix reference and closure evidence.
We define a documented path for accepted risks, with a review date and the approval record stored alongside the finding.

How we hand over

You receive documented procedures for prioritizing, remediating, tracking and closing vulnerabilities against your risk assessment.
Evidence exports include remediation records, scan history and accepted-risk decisions, arranged to match the assessment objectives of NIST SP 800-171A.
We walk your staff through the workflow so personnel who remediate vulnerabilities can explain it during an assessment interview.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after the fixed-scope engagement ends.
Retainers can cover tool upgrades, periodic review of open findings and refreshes of the remediation evidence set.
Before any engagement starts, ask us to confirm in writing which assessment decisions remain with your organization and your assessor.

RA.L2-3.11.3 Vulnerability remediation