SI.L2-3.14.1 Flaw remediation: requirements and evidence

What SI.L2-3.14.1 flaw remediation requires for CMMC Level 2

SI.L2-3.14.1 is a 5-point requirement that cannot go on a POA&M, so it must be fully MET before a Level 2 assessment can reach Conditional or Final status. In plain terms, it asks your organization to define time frames for identifying, reporting and correcting system flaws, and then to meet those time frames. Writing the time frames is the easy part. The hard part is showing an assessor that every system in the assessment boundary, including servers, endpoints, network devices, cloud workloads and specialized assets, was identified, reported and corrected within the limits you set, and that the records exist in final form for each one.

Assessors treat this requirement as a gating item because unpatched software is one of the most common ways an attacker gets into a system that holds CUI. A known flaw with a published fix that sits open for months gives an adversary a predictable entry point, and an organization that cannot show when it learned of a flaw and when it closed it cannot demonstrate control over its own environment. Before your assessment, confirm your written time frames for each system class, check that they are the ones your teams actually follow, and pull the records for a sample of recent flaws. Ask your assessor or C3PAO which evidence they expect, since the assessment objectives for this requirement in NIST SP 800-171A focus on the defined time frames and on meeting them.

Which systems, teams and vendors fall under flaw remediation

Flaw remediation applies to every system that stores, processes or transmits CUI, and to every system that provides security protection for it. The cards below cover the asset types, delivery teams and third parties that a assessor will expect you to include, and the scoping decisions that change how much work the requirement becomes.

Endpoints and end-user devices

Laptops, desktops and virtual desktops that can reach CUI are inside the flaw remediation scope, including those used by remote staff. Assessors look for an inventory that shows which devices exist and which operating system and application versions they run. Check that the inventory is current and that the time frame you defined for end-user computers is applied to each device, not just the ones managed centrally. Devices that are not enrolled in management tooling are a common gap.

Servers and hypervisors

Servers that host CUI, authentication services, logging and security tools are in scope, along with the hypervisors that run them. Patch time frames for servers are often set differently from endpoints, and the CMMC Assessment Guide Level 2 illustrates this with a longer cycle for servers than for end-user computers. Confirm that the time frame you chose is written down, that it covers each server class, and that exceptions are recorded with a reason.

Network devices and security appliances

Firewalls, routers, switches, VPN concentrators and wireless controllers often run firmware that carries flaws and vendor advisories. They sit on the CUI boundary, so an unpatched appliance can undermine every other control. Build a separate list for these devices, because they are frequently managed by a network team or a vendor and may not appear in endpoint tooling. Ask who receives vendor advisories for each model.

Cloud workloads and managed services

Virtual machines, containers, images and platform services that process CUI fall under the requirement wherever they run. Where a cloud provider patches the underlying platform, you still own the guest operating system, the images you build and the applications you deploy. Document the shared responsibility split for each service, and obtain the provider's evidence of its own patching where your contract depends on it.

Applications and third-party components

In-house applications, commercial software and open-source libraries that handle CUI all carry flaws that must be identified and corrected. Software composition data, such as a bill of materials for each application, is what allows you to match a new advisory to an affected component. Scope should include the build pipeline and container base images, since a flaw there reaches every build that depends on it.

Specialized, OT and test assets

Industrial control systems, lab instruments, test equipment and other specialized assets are in scope only when they are inside the CUI boundary. Scoping decisions here change the work substantially: a device that cannot be patched on the normal schedule still needs a defined time frame, a documented compensating approach, and a record that the flaw was identified and reported. Decide the boundary early, because it determines whether these assets need their own remediation process.

Teams and vendors who deliver updates

Flaw remediation depends on people as much as tooling: system administrators, network engineers, application owners, the security team and any managed service provider that patches on your behalf. Each party needs a named responsibility and an agreed time frame. When a vendor delivers patches or monitors advisories for you, include that contract in the scope and confirm it supports the evidence you will need at assessment.

How an assessor tests whether flaws are remediated on time

An assessor testing SI.L2-3.14.1 works through the six assessment objectives in NIST SP 800-171A (June 2018) for requirement 3.14.1. Those objectives ask two things. First, the organization must have specified time frames for identifying, reporting and correcting system flaws. Second, it must show that it actually meets each of those time frames. The assessor therefore looks for a written, defined schedule for each of the three stages, then looks for records that show flaws were handled inside that schedule. A policy that says flaws are fixed "promptly" does not satisfy the objectives because no time frame is defined.

The CMMC Assessment Guide for Level 2 expects these time frames to cover all systems in the assessment scope, not only the servers that a contract owner remembers. It illustrates the expectation with an example policy of weekly patching for end-user computers and monthly patching for servers. That example is illustrative only. Your own schedule must reflect your risk and your environment, and it should be the schedule your staff actually follow. Confirm with your assessor or your C3PAO how they will sample systems, especially where cloud instances, network appliances or specialized equipment sit outside the normal patch cycle.

A requirement is MET only when every applicable objective is satisfied with evidence in final form, not drafts (32 CFR 170.16, 170.17 and 170.24(b)). Practically, the assessor will ask for the approved time-frame policy, scan or vendor-notice records showing when each flaw was identified, reporting records, and patch or change tickets showing when each flaw was corrected. They will compare those dates against your own schedule. Gather these records from your ticketing and change systems before the assessment, and confirm that each record is signed off or approved. Any gap in one objective leaves the whole requirement NOT MET, and because this requirement is worth 5 points, it cannot be carried on a POA&M.

What assessors ask for and where findings usually land

This table maps the six NIST SP 800-171A assessment objectives for SI.L2-3.14.1 to how an assessor tests each one, the evidence requested and the findings that most often prevent a MET result. Read it as a preparation checklist: each row is a point where an assessor will look for a defined time frame, a dated record or a sampled system, and a gap in any one of them can keep the requirement from being scored as MET.

Assessment objective	How the assessor tests it	Evidence requested	Where findings usually land
Time frames for identifying flaws are specified	Examine the patch and vulnerability management policy and standards for a stated identification cadence covering all system types	Approved policy with a stated cadence for end-user computers, servers and network devices, plus the scanning schedule	Policy says patch regularly with no cadence, or omits cloud, network or OT assets
Time frames for reporting flaws are specified	Examine the policy for a defined path from detection to the owner who records and escalates the flaw	Procedure naming roles, a ticketing or reporting workflow and the escalation trigger for high-severity flaws	Reporting step exists only in practice, with no written owner or deadline
Time frames for correcting flaws are specified	Examine the policy for remediation deadlines and interview the system owner about how they are applied	Remediation standard with deadlines, exception rules and the approval path for deferrals	Deadlines are stated but not tied to severity, or exceptions are granted without records
Flaws are identified within the specified time frames	Compare scan or patch-status records against the policy cadence for a sample of systems	Vulnerability scan reports, asset inventory and dated scan job history covering the sample period	Scans ran less often than the policy states, or the sampled assets were missing from scan scope
Flaws are reported within the specified time frames	Trace a sample of identified flaws to tickets or reports and check the dates against the policy	Tickets or findings records showing discovery date, report date and assigned owner	Tickets are opened late, undated or created only after the audit began
Flaws are corrected within the specified time frames	Sample hosts and check installed patch levels and remediation dates against the policy deadline	Patch deployment records, hot fix history, change control entries and post-patch test results for each sampled system	Sampled servers or endpoints remain unpatched past the policy deadline, or fixes lack change records

How to implement flaw remediation in six steps

The sequence below turns SI.L2-3.14.1 from a policy statement into a repeatable cycle that finds flaws, sets time frames for each asset class, fixes them under change control and leaves records an assessor can test against the SP 800-171A objectives.

Define time frames by asset class
Before anything else, the organization sets written time frames for identifying, reporting and correcting flaws on every asset class in the CUI boundary, such as end-user computers, servers, network devices and cloud workloads. The CMMC Assessment Guide Level 2 expects these time frames to exist for all systems. As an illustrative example only, a policy might set weekly patching for end-user computers and monthly patching for servers. The output is an approved flaw remediation standard that names each asset class, its owner and its time frames, signed off by the system owner and linked from the system security plan.
Build the flaw inventory and scanning feeds
Next, the team confirms that every in-scope asset reports its software inventory and that vulnerability sources are connected to it. Self-hosted options such as Wazuh vulnerability detection, Fleet host software matching and Greenbone scan tasks can each produce findings from different data. Confirm each tool's update source, whether it can run from a local offline copy, and which assets it cannot see, such as OT or test equipment. The output is a list of in-scope assets with the tool that covers each one, plus a documented list of coverage gaps with owners.
Set up vendor notification intake
Flaws also arrive from vendor bulletins, security advisories and external notices that scanners do not capture. The organization assigns a named owner to monitor each vendor and product in the boundary, subscribes to the relevant notification channels and routes each notice into the same tracking system as scanner findings. Record which notices were reviewed, by whom and when. The output is a vendor register and a notification log that shows every relevant flaw notice was received and reviewed within the defined time frame.
Triage and prioritize each finding
Each finding is checked for duplicates, confirmed against the affected asset and assigned a severity and a remediation deadline drawn from the time frames in step one. Finding management platforms such as DefectDojo can import results from many scanner formats and deduplicate them, which reduces manual sorting. Where a fix is not available or not safe to apply, record a documented compensating action and its approval. The output is a triaged backlog in which every item has an owner, a severity, a due date set from the approved time frames and a status.
Patch under test and change control
The responsible administrator applies the fix through the change process, first in a test or staging environment where possible, and records the change request, approval and implementation window. Test results from the update and the installed patch or hot fix are saved as evidence. Security-relevant updates follow the same change control rules as other configuration changes. The output is a closed change record for each patch that links the finding, the approval, the test result and the post-change verification scan or inventory check.
Record closure and review remediation metrics
Each finding is closed only after a verification scan or inventory check confirms the flaw is gone, and the closure reason is recorded. Management reviews, at a defined interval, the number of findings by age, the share closed within the time frames, the exceptions and the assets that repeatedly miss deadlines. Those results feed back into the time frames and tooling. The output is a closure record for every finding and a periodic review record that shows the organization is acting on its time frames, which is the evidence an assessor will sample under the SP 800-171A objectives. Confirm with your assessor which review interval and metrics they expect.

Open-source tools that feed flaw identification and tracking

Flaw identification starts with knowing what software is installed. Wazuh and Fleet both approach this from the endpoint. Wazuh agents collect a software inventory from each monitored endpoint, and its vulnerability detection correlates that inventory with the Wazuh CTI vulnerability repository, or with a locally hosted offline copy, to identify vulnerabilities in the operating system and installed applications. Fleet detects vulnerable software on enrolled hosts by matching installed software against sources including the NVD, OVAL definitions, Microsoft security bulletins, Amazon Linux advisories and OSV.

Inventory coverage: Results are only as complete as the set of enrolled endpoints. Confirm which systems in your boundary have agents or enrollment, and which do not.
Source selection: Fleet's matching draws on several named sources. Confirm which sources apply to each operating system in your environment.
Offline operation: Wazuh can use a locally hosted copy of its vulnerability repository. Confirm whether this is required in an isolated network and who keeps that copy current.
Application coverage: Confirm that the installed applications you must track, not only the operating system, appear in the inventory.
Scope of detection: Matching against advisories identifies known vulnerabilities in software that is reported. It does not identify flaws in custom code.

Before relying on either tool for SI.L2-3.14.1 evidence, check the endpoint list against your system security plan boundary.

Evidence that proves flaws are found, reported and fixed on time

An assessor testing SI.L2-3.14.1 looks for a chain of records: what flaws exist, how fast they were addressed, and whether the organization's own time frames were met. Each card below is one artifact in that chain, and the set only holds together if every record is kept current between assessments.

Current flaw and vulnerability list

This is the inventory of known flaws and vulnerabilities potentially affecting in-scope systems, covering operating systems, installed applications and network devices. Assessors use it as the starting point for every other test in the chain. Check that it covers all systems in the CUI boundary, not only servers, and that each entry records its source, date found and current status. Scanner exports and endpoint inventory reports are the usual inputs.

Patch and hot fix records

These records show which patches, updates and hot fixes were installed, on which systems, and when. They are the direct evidence that flaws were corrected rather than merely logged. Check that each entry links back to the flaw it addresses, so an assessor can trace a finding from detection to correction without manual reconstruction.

Update test results

Before a security-relevant patch reaches production, the organization should record how it was tested and what the outcome was. Test results show that updates were validated against the systems that depend on them. Keep these records with the change ticket for the same update, so the link between testing, approval and deployment is visible in one place.

Change control records for security updates

Change records document who requested, reviewed and approved each security-relevant update, and when it was scheduled. Assessors check that emergency patches followed a defined path, even when it was shorter than the standard one. Confirm that the approval trail is complete before the change is closed, because an approval recorded after deployment will not satisfy the review.

Written time frame policy

The organization must define time frames for identifying, reporting and correcting flaws on all systems. The CMMC Assessment Guide Level 2 illustrates this with weekly patching for end-user computers and monthly patching for servers, but the organization sets its own values. The policy should be approved, dated and version controlled, because an assessor measures performance against the time frames written in it.

Records showing time frames were met

Compare each flaw's detection date with its correction date and record every exception with a reason and approver. This is the evidence that proves the written policy is followed, not just written. Review the ratio of missed deadlines each month, and confirm that drafts of this report are not presented as final, since only final-form evidence counts toward a MET determination.

What meeting SI.L2-3.14.1 costs in money and effort

This table breaks down the money and effort behind meeting SI.L2-3.14.1, showing who is paid for each component, whether it is one-time or recurring, and what moves it up or down. Use it to build a quote request, since no supplied figures set prices for any component. The main takeaway is that licence spend is often the smallest line, while the time to run and evidence a patch cycle keeps recurring.

Cost component	One-time or recurring	Who is paid	What drives it up or down
Scanning and patch tooling	Mostly one-time setup, then recurring operation	Tool vendor for commercial products, or no license fee for open-source tools such as Greenbone Community Edition, Wazuh and Fleet	Self-hosting removes license spend but adds hosting, storage and operator time. Confirm each tool's license terms before deployment.
Patch pipeline engineering	One-time build, recurring tuning	Internal platform engineers or an implementation partner under a fixed-scope agreement	Number of operating system and application types, and how much patching is automated. Fewer platform types usually means less effort.
Defined remediation time frames	One-time policy work, recurring review	Internal policy owner, often with an outside advisor	Number of system classes that need separate time frames. Ask for the policy to be written once and reused across all systems.
Flaw triage and findings management	Recurring	Internal security staff, or a managed service if outsourced	Volume of findings and duplicates. Deduplication in a findings platform such as DefectDojo can reduce manual review.
Change control and test evidence	Recurring	Internal change managers and system owners	Frequency of security-relevant updates and whether test results are captured automatically. Confirm how your change tickets link to patch records.
External testing or independent review	Periodic, often one-time for readiness	Independent assessor or security testing firm, quoted from written scope	Scope of systems in the assessment boundary and how mature the evidence set is before review.
Assessor sampling and evidence review	Recurring at each assessment	Certified third-party assessor (C3PAO) for Level 2 certification, or the organization for self-assessment	Number of systems sampled and whether evidence is in final form. Drafts do not count as MET, so finalize records before review.

Who owns flaw remediation and what a partner can take on

The organization owns the flaw remediation program. SI.L2-3.14.1 asks the organization to define time frames for identifying, reporting and correcting flaws, and to meet them. Only the organization can decide what those time frames are, which systems fall under them, who accepts risk when a patch cannot be applied on schedule, and who signs off on exceptions. These decisions belong in a written policy approved by leadership and tied to the system security plan. The CMMC Assessment Guide for Level 2 illustrates the idea with a sample policy of weekly patching for end-user computers and monthly patching for servers, but that example is not a template you must copy. Your own time frames should reflect your environment and your risk tolerance.

Policy and time frames: Set the identification, reporting and correction windows for each system class, and record who approved them.
Scope decisions: Decide which assets count as in scope, including cloud workloads, network devices and specialized equipment.
Risk acceptance: Name the role that may approve a deviation, and require a documented reason and an end date.
Staff accountability: Assign owners for each stage of the flaw lifecycle, from vendor notice to verified fix.

Before engaging anyone, confirm that a named executive can approve the policy and that the time frames match what your operations team can actually meet.

Common gaps that fail the 3.14.1 objectives

SI.L2-3.14.1 is worth 5 points and cannot go on a POA&M, so a gap here blocks Conditional or Final Level 2 status outright. The gaps below share one root cause: the organization can patch, but it cannot show a defined time frame, a dated record and a final-form trail for each flaw. Each card names the gap and the step that closes it.

Undefined or inconsistent time frames

The assessment objectives require the organization to specify time frames for identifying, reporting and correcting flaws, and then to meet them. A policy that says patch promptly does not meet this. Define separate time frames for each stage and for each asset class, such as end-user computers and servers, and state them in the policy and system security plan. The CMMC Assessment Guide Level 2 illustrates this with weekly patching for end-user computers and monthly patching for servers, which is an example, not a required schedule. Then check the records against those numbers.

No vendor notification intake

If flaw information arrives in a mailbox that nobody watches, the organization cannot show when it identified a flaw. Route vendor bulletins, advisories and scanner output into one intake queue with an owner, a timestamp and a triage decision. Subscribe to every vendor for the products in the system security plan, including firmware and network appliances. Keep the intake log, because an assessor will ask for the date each flaw was first seen, not the date it was fixed.

Patches applied without records

A patch installed by an administrator with no ticket, no change record and no test result looks identical to no patch at all. SP 800-171A lists installed patches and hot fixes, test results from updates and change control records for security-relevant updates as potential evidence. For each flaw, keep the identifier, the affected asset, the remediation action, the approval, the test result and the completion date in one record. Tools such as DefectDojo can track findings from several scanners through reimports and deduplication, which helps tie a scan result to the closing action.

Unpatched appliances and OT assets

Firewalls, VPN concentrators, switches, printers, and engineering or test equipment often sit outside the normal patch cycle. Agent-based tools may not run on them, so the flaw never appears in any queue. Build an inventory that includes these devices, record the vendor support status and the patch method for each, and put them on a defined schedule. Where a device cannot be patched, document the compensating reason and the review date. Confirm with each vendor how firmware is delivered and whether that path requires a maintenance window.

Scanner coverage gaps

A vulnerability scanner that has never seen a subnet produces a clean report that proves nothing. Compare the scanner's asset list against the configuration management inventory each cycle, and investigate any system that appears in one but not the other. Agent-based detection, such as Wazuh correlating each agent's software inventory with a vulnerability repository, depends on the agent being installed, so check agent health as part of the review. Record the scan scope and date so the assessor can see which systems were covered at each point in time.

Evidence that exists only as drafts

A requirement is MET only when the evidence is in final form. Time frame policies stuck in draft, remediation tickets never closed, and a patch report saved as a working spreadsheet all fail that test. Set a document control process that marks each policy, procedure and record as approved, dated and versioned, and that archives superseded versions rather than overwriting them. Before the assessment, have someone who did not write the evidence check that each item is final and matches what the systems show.

Flaw remediation questions buyers ask before hiring help

How much effort does flaw remediation take in-house?

The effort depends less on the requirement itself than on how many systems you run and how well they are inventoried. SI.L2-3.14.1 asks you to identify, report and correct flaws within time frames you define, and the assessment objectives in NIST SP 800-171A test whether those time frames are both specified and met. The work falls into four recurring parts: maintaining an inventory of every system, watching vendor and advisory feeds, testing and deploying patches, and keeping records that show each step. Teams with a small, uniform estate and an existing patch cadence can absorb this with current staff. Teams with mixed operating systems, unmanaged endpoints or many business applications usually find the inventory and record-keeping take more time than the patching itself. No fixed hours figure is supplied here, so ask your team to time a sample month of patch cycles before estimating.

Can flaw remediation for CMMC be done with open-source tools?

Yes, the tools can cover much of the evidence trail, but they do not replace the policy or the people. The requirement is about identifying and correcting flaws, so scanners and vulnerability feeds do the identifying. Greenbone Community Edition (OpenVAS) schedules scans and stores results in PostgreSQL, Wazuh correlates each agent's software inventory with vulnerability data to flag operating system and application flaws, and Fleet matches installed software against sources such as the NVD and OSV. DefectDojo can track findings from many scanner formats, deduplicate them and record remediation status, which helps build the reporting trail. Confirm each tool's supported platforms and data sources in your own environment before relying on it. Patch deployment itself usually comes from your existing endpoint or server management stack.

How long does it take to be ready for flaw remediation?

Readiness depends on whether your time frames already exist in writing and whether you can show they were met. The CMMC Assessment Guide for Level 2 expects you to define time frames for identifying, reporting and correcting flaws on all systems, and it gives weekly patching for end-user computers and monthly patching for servers as an illustrative example, not a required standard. If you already patch on a schedule and keep change records, the gap is often documentation and inventory coverage, which can close in weeks. If you have no defined cadence or unmanaged systems, the gap is larger. Because SI.L2-3.14.1 is worth 5 points and cannot be placed on a POA&M, it must be fully MET before you reach Conditional or Final Level 2 status. Ask any provider to produce a gap list against the six objectives before agreeing on a timeline.

What does flaw remediation need from my own team?

Your team owns the decisions and the sign-off, and the work needs named roles rather than a general hope that someone will patch. You need an owner who sets the time frames and approves exceptions, system administrators who apply patches and test them, someone who reviews vendor notices and security advisories, and an approver for security-relevant changes. Expect to provide access to asset inventories, change management tickets, and the systems that the scanners must reach. The assessment looks for records of recent patches and hot fixes, test results from updates, and change control entries for security-relevant updates, so those records must be kept as the work happens, not reconstructed later. A short written procedure that names these roles will help any external party understand your process quickly.

Can an implementation partner also run the CMMC assessment?

No. An implementation partner can prepare the systems, scanners, records and procedures, but it cannot perform the assessment or issue a certification. Level 2 certification assessments are performed by C3PAOs authorized or accredited by the CMMC Accreditation Body, and assessors must remain independent of the work they evaluate. DeployOpen plans, implements, hardens and documents self-hosted platforms inside your own infrastructure and prepares the evidence for assessment, but it does not issue audit reports or certifications. Keep the implementation partner and the assessor as separate engagements. Also confirm the current assessment path with the Department of War before you contract, because the program schedule has changed.

Does the Level 2 requirement change if the rules are paused?

The requirement text does not change, but the timing of assessments may. SI.L2-3.14.1 is the Level 2 version of NIST SP 800-171 Rev. 2 requirement 3.14.1, and the Department of War said on 13 July 2026 that it would suspend CMMC Phase II and enforce Rev. 2 in the interim. Phase I self-assessments, SPRS postings and DFARS 252.204-7012 obligations remain in place, so you should still meet the flaw remediation objectives now. The DoW CIO page and the eCFR text may not agree on the current schedule, so confirm the status with your contracting officer and your legal team before you plan certification dates.

What should I ask a provider in a quote for this work?

Ask for a written scope that lists the systems covered, the scanners and feeds used, the time frames you will define, the records produced, and what you must supply. A useful quote separates one-time work from recurring work. One-time items usually include the gap assessment, inventory cleanup, scanner setup, procedure drafting and evidence mapping. Recurring items include scan maintenance, feed monitoring, patch testing support and evidence reviews before each assessment. Ask how the provider will test that each of the six assessment objectives is covered, which systems are out of scope, and who owns the final evidence. DeployOpen works from a written scope and provides a quote from that scope, and it does not publish a price list.

How DeployOpen prepares flaw remediation evidence

DeployOpen plans, implements and documents the flaw identification, reporting and correction process behind SI.L2-3.14.1 inside your own environment, using self-hosted open-source platforms. The organization keeps ownership of its policy, time frames and decisions, while DeployOpen prepares the systems and records an assessor will examine.

How we scope

Engagements are fixed-scope, with systems, deliverables and timelines agreed in writing before work starts.
The written scope lists which asset types, operating systems and applications fall under your defined flaw remediation time frames.
We confirm which vendor advisory sources and feeds the organization will monitor, and who reviews them.

How we build

We deploy vulnerability detection that inventories installed software on endpoints and servers in your environment.
We configure scanning and findings workflows so each identified flaw is recorded, assigned and tracked to correction.
We set up patch management records that link each correction to change control entries and post-update test results.

How we hand over

We document the time frames you define for identifying, reporting and correcting flaws, with the reasoning behind each value.
We deliver sample records showing flaw identification, reporting, correction and verification for your own review.
We provide runbooks so your staff can produce the same evidence in final form after the engagement ends.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the initial handover.
Retainers can cover platform updates, review of findings backlogs and checks that time frames are still being met.
Assessment decisions and certification remain with your organization and the independent assessor you select.