DoD Contractor Considerations for CMMC Practice Guide SI.L1-3.14.1

By Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager

DoD Contractor Considerations for CMMC Practice Guide SI.L1-3.14.1

Editor’s note: This article is one of a series of articles about the CMMC Level 1 Practices. In these articles we dive into the CMMC Practice Guides and provide our thoughts about the practices and what contractors should consider. The CMMC ecosystem is still developing, and as those developments occur, we will update these articles accordingly. As such, we hope that these articles represent an evergreen CMMC Level 1 resource.

Practice Title: Flaw Remediation
Practice Number: SI.L1-3.14.1
Practice: Identify, report, and correct information and information system flaws in a timely manner.

Assessment Objectives
Determine if:
[a] the time within which to identify system flaws is specified;
[b] system flaws are identified within the specified time frame;
[c] the time within which to report system flaws is specified;
[d] system flaws are reported within the specified time frame;
[e] the time within which to correct system flaws is specified; and
[f] system flaws are corrected within the specified time frame.

(source: CMMC ML-1 Assessment Guide)

Note: CMMC practice RA.L2-3.11.1 – Vulnerability Scanning and RA.L2-3.11.2 – Vulnerability Remediation are CMMC Level 2 requirements. For organizations that are targeting CMMC Level 2, there will almost certainly be some overlap/redundancy with the subject of this article SI.L1-3.14.1 – Flaw Remediation.

Overview of SI.L1-3.14.1

According to IBM’s Cost of a Data Breach Report 2023, roughly 6% of data breaches start with an attacker leveraging known vulnerabilities in software or firmware. The infamous Equifax data breach, in which hackers stole the personally identifiable information of 147 million Americans, was perpetrated by exploiting an unpatched vulnerability in the Apache Struts framework on an Equifax webserver.

These attacks also target end users. Such attacks start with a victim user being prompted to open a malicious file with a vulnerable application. When the application tries to open the malicious file, the application is usually forced into an error state, such as a buffer overflow, from which the malicious file can now run its own arbitrary code.

This happens more than you might think. The Common Vulnerability and Exposure (CVE) database, for example, reports 22 new vulnerabilities for Adobe Acrobat Reader in the first four months of 2024; 82 in 2023, and a staggering 2,115 vulnerabilities dating back to 1999. Nearly every recent Acrobat Reader vulnerability is exploited when victim users “open a malicious file.”

The good news, however, is that software manufacturers are generally pretty good about releasing patches to fix the vulnerabilities. Organizations that want to shore up those vulnerabilities have to apply those patches when they are available.

SI.L1-3.14.1 is the CMMC requirement that requires patching security vulnerabilities. Although simple in concept, organizations with complex infrastructure or immature endpoint security will have some work to do.

Flaw Remediation has six assessment objectives, which relate to three main areas:

  1. Identifying flaws [a, b]
  2. Reporting flaws [c, d]
  3. Correcting flaws [e, f]

Half of the objectives require formalizing timelines to identify [a], report [c], and correct [e] flaws; the other half [b, d, and f] require implementation of those timelines.

Software Inventory – A Helpful Prerequisite

To patch vulnerable software or firmware, you must first know a flaw exists to patch. And to know if a flaw exists to patch, you must first know what software and firmware is installed on your systems and network. A well-designed patching program is therefore predicated on the ability to maintain an inventory of software and firmware.

When creating an inventory, we recommend considering software that runs on:

  • Network devices – Firewalls, managed switches, wireless access points, and other network devices all have a type of software called firmware that needs patching.
  • Servers – Including the operating system and any other software necessary for the server to perform its function.
  • End-user computers – Operating systems, office productivity software, web browsers, PDF readers, and more.
  • IoT Devices – Multi-function printers, cameras, etc.

The most challenging of the above are end-user computers, and that challenge is most acute in organizations that allow end-users unrestricted rights to install software, usually through local admin privileges.

Maintaining a software inventory and a functioning patching program is practically impossible if end users can install whatever they want.

Organizations should disable local admin rights for end users wherever possible. If local admin privileges are necessary, as may be the case when certain end-user software requires it, other mitigations should be implemented to prevent unauthorized software from running (such as AppLocker).

Organizations may also find it helpful to use automated tools to generate inventory reports, monitor the software installed on end-user computers, and even patch them.

Identify Flaws

Once an organization has a reliable system inventory, it needs to have documented mechanisms to be notified when there are flaws and/or patches. This will typically mean some combination of configuring automated alerts or periodically checking sources for flaw notifications.

Organizations should identify in policy the cadence with which system flaws must be identified from the point in time they are published, e.g., weekly [a]. This establishes organizational requirements from which those tasked with execution can use to implement the practice.

To identify the flaws, we recommend organizations document how to identify flaws for each item in the system inventory [b]. Some examples might include:

  • In-application notifications of an available patch
  • Periodically visiting the vendor’s security notifications website
  • Subscribing to the vendor’s security notifications
  • Periodically logging into a device’s administration interface to check for available updates

Reporting Flaws

For many small and midsize organizations, there is no practical distinction between identification [a, b] and reporting [c, d]. This is because the same person or team often performs system administration and security functions, and there is no need to report something to yourself!

Larger organizations that have dedicated security analysts, who are constantly on the hunt for vulnerabilities and flaws, should document time frames for reporting flaws to system administrators [c] and report them through a formal mechanism such as an internal ticketing system [d].

Correcting Flaws

With knowledge of what needs correcting, administrators can correct the actual flaws. Most commonly, this is simply the application of security patches that are available from the vendor. However, correcting a flaw could be changing a configuration, for example, using a more secure cipher in a site-to-site VPN.

Organizations should document in policy a timeframe within which to correct flaws [e] and implement a process to apply the corrections within that timeframe [f].

For SMBs, we recommend a document, such as the one below, that identifies all the software and firmware within the enclave that needs patching as well as other information needed to implement the practice, including who is responsible.

Inventory ItemIdentification MethodSourcePatching
Windows 11 Professional & Office 365Automatic Email SubscriptionAutomated-Monthly
Procedure: All end user PCs receive all available MS security updates the week Microsoft releases them. Domain Administrators monitor the patch status via endpoint management system.
ABC CAD SoftwareManualWebsiteManual-Monthly
Procedure: Endpoint management system reports version but does not support patching ABC CAD Software. Domain Administrators check the noted URL weekly for security updates. If available, Administrators notify the end users and instruct them to apply the patch through the software’s user interface. Administrators monitor the patching status through the version reporting available in the end point management software. After a week, Administrators manually update unpatched systems.
XYZ MFC PrintersManualWebsiteManual-Monthly
Procedure: Domain Administrators visit the support page for XYZ MFC Printer to determine if new firmware is available that addresses security flaws. If so, the Administrator downloads and manually deploys the updated firmware to the network printers.
Engineering Analysis SystemManualCLI commandManual-Monthly
Procedure: The Engineering Analysis System is internally developed and leverages some open-source packages. On a weekly basis, the Lead Developer must run the CLI command:
dotnet list package --vulnerable --include-transitive
This will identify vulnerabilities in packages. The results must be provided to the Domain Administrators in a support ticket and analyzed to evaluate risk and develop a patching strategy.
FirewallAutomaticEmail SubscriptionManual - Weekly
Within the Firewall GUI, Domain Administrators configure notification preferences to include when new software and firmware is available and to receive Security Notices. If there is new software/firmware that contains security patches, the Administrator backs up the current configuration and schedules the patch to apply outside of business hours.


To retain evidence that these patching activities are occurring, we recommend documenting each one in a ticket within the organization’s ticketing system. Ticket types, tags, and naming conventions could further assist in the generation of evidence for an assessor or to support your Senior Official’s Annual Affirmation.

With the following in place, organizations should have no problem passing this practice:

  • Policies defining timeliness requirements for flaw identification, reporting, and correction
  • Implementation details/instructions for each type of software/firmware (see the example in the table above)
  • Tickets showing when the activities take place
  • The ability to show the current versions of software for an assessor wishing to check individual software / firmware installations


Applying software patches is a largely automated process and computer operations tend to be deterministic. Once configured it should just work, right?

Not exactly. The reality, however, is that applying updates across an enterprise is notoriously fickle, especially when it comes to end user computers. For a variety of reasons, some computers get stuck and never successfully install a patch without manual intervention.

CMMC Level 2 contains practice requirements for Security Control Assessments (CA.L2-3.12.1) and Security Control Monitoring (CA.L2-3.12.3). Adding a layer of monitoring and periodic assessments to your system patching will help catch those patching recalcitrant systems and support Level 2 requirements.


SI.L1-3.14.1 – Flaw Remediation – requires organizations to identify, report, and correct flaws in a timely manner. For most, this is a simple matter of layering some additional governance and documentation onto existing system patching processes. However, organizations that have provided end users with the ability to download and install any software will have some additional work.

Many DoD contractors will not have the expertise or resources needed to perform a CMMC CMMC RPOreadiness assessment, identify the gaps, and develop corrective action plans. In these cases, the contractors are turning to cybersecurity consultants with knowledge of NIST and the CMMC framework. If you want to learn more about CMMC, Keiter’s team of cybersecurity specialists can help you. Email | Call: 804.747.0000.

Our team will continue to monitor the rollout of the CMMC program and update you on new information and changing requirements for DoD contractors.

Share this Insight:

About the Author

Christopher Moschella

Christopher Moschella, CPA, CISA, Risk Advisory Services Senior Manager

Chris is a Senior Manager in Keiter’s Risk Advisory Services. Chris has a strong combination of IT skills, which range from IT audit and internal control assessments, including general computer controls and application controls, to full stack web development. Most recently, Chris developed a Cybersecurity web application that assesses an organization’s resistance to social engineering attacks. Chris shares his cybersecurity insights on our blog.

More Insights from Christopher Moschella

The information contained within this article is provided for informational purposes only and is current as of the date published. Online readers are advised not to act upon this information without seeking the service of a professional accountant, as this article is not a substitute for obtaining accounting, tax, or financial advice from a professional accountant.


Contact Us