Threats and Vulnerabilities
How a Small Team Should Decide What to Patch First
Patch management is a core requirement for any company handling Controlled Unclassified Information (CUI) under NIST SP 800-171 Rev 2 and CMMC Level 2. For small or mid-sized teams without a dedicated security staff, the challenge is not whether to patch, but what to patch first, and how to prove you are meeting requirements like SI.L2-3.14.1 (flaw remediation). The reality is that you cannot patch everything at once. You need a process to decide what matters most.
What does SI.L2-3.14.1 require for patch management?
SI.L2-3.14.1 requires you to identify, report, and correct system flaws in a timely manner. In CMMC Level 2, this is one of the seven controls in the System and Information Integrity family. NIST SP 800-171A, the official assessment guide, breaks this down into specific objectives: you must have a policy and documented procedure for flaw remediation, maintain an inventory of software, identify relevant flaws, test patches, and install them within a defined timeframe. You also need evidence that this happens in practice, timestamped system artifacts, more than a policy on paper.
How should a small team prioritize what to patch?
You do not need a security operations center to meet the intent of SI.L2-3.14.1. What you need is a defensible, repeatable process that shows you are making informed decisions. The best starting point is the CISA Known Exploited Vulnerabilities Catalog (KEV). This catalog lists 1665 vulnerabilities as of August 2026, with 181 added since January. Out of these, 349 are flagged as being used in known ransomware campaigns.
If a vulnerability is in the KEV Catalog, you have authoritative evidence that it is being actively exploited. This gives you a clear, government-backed priority list. When time and resources are tight, patching KEV-listed flaws, especially those with known ransomware use, should come first.
How do you map KEV to your patch management plan?
- Inventory your systems and software. You cannot prioritize what you do not know you have. SI.L2-3.14.1 expects you to maintain a list of all software in scope for CUI processing.
- Check the KEV Catalog weekly. The catalog is updated regularly. Filter the list for products your organization uses. Focus first on those vulnerabilities that CISA flags as being used in ransomware campaigns.
- Document your review and decisions. For each KEV entry that applies to your environment, record when you identified it, when you reviewed the relevant patch or mitigation, and when you applied it. If you cannot patch immediately, document why and what compensating controls you are using.
- Test before deploying. SI.L2-3.14.1 requires testing patches before rollout, especially in production environments. For small teams, this can be as simple as testing in a staging environment or on a non-critical system.
- Install the patch or apply mitigation. Once tested, deploy the patch. If a patch is not available, apply any recommended mitigation from the vendor or CISA.
- Keep evidence. System logs, patch management tool reports, and change tickets are all valid forms of evidence. You will need these if asked to prove compliance in a self-assessment or a government-led review.
What is the risk of not prioritizing patch management?
DFARS 252.204-7012 and the annual self-assessment affirmation require you to accurately report your compliance status. If you claim to be meeting SI.L2-3.14.1 but cannot show evidence of timely patching, especially for known exploited vulnerabilities, you increase your risk under the False Claims Act. Recent enforcement actions have named more than contractors but also their owners and private equity sponsors when companies failed to remediate known vulnerabilities or lacked a documented patching process.
How do you sequence patching when you have limited staff?
For a small team, sequencing is about making the best use of limited hours. Here is a practical order:
- KEV-listed vulnerabilities with known ransomware use. These are your highest priority. For example, in 2026, the KEV Catalog added critical flaws in Microsoft SharePoint Server, SonicWall SMA1000, and ConnectWise ScreenConnect, all with confirmed ransomware campaign use.
- Other KEV-listed vulnerabilities. Next, address vulnerabilities in the KEV Catalog that affect your systems, even if ransomware use is not confirmed.
- Vendor critical advisories. After KEV, look to vendor advisories for other critical flaws, especially those affecting externally facing systems.
- Routine patches. Finally, address remaining patches as part of your regular update cycle.
This approach aligns with the intent of SI.L2-3.14.1: you are not required to patch everything at once, but to have a documented, risk-based process for flaw remediation.
What documentation should you keep for an assessment?
Under NIST SP 800-171A, you must be able to show:
- Your policy and procedure for flaw remediation.
- An up-to-date software inventory.
- Records of vulnerability identification (for example, KEV reviews).
- Evidence of patch testing and deployment.
- Proof that patches were applied in a timely manner.
Documentation alone is not enough; you need system-generated evidence. For example, export logs from your patch management tool that show when patches were installed. Keep change tickets or emails that document your review of KEV entries and the actions you took.
Common questions
How often should I check the KEV Catalog? At a minimum, review the CISA Known Exploited Vulnerabilities Catalog weekly. More frequent checks may be warranted if your environment changes or a major vendor releases an emergency advisory.
What if I cannot patch a KEV-listed vulnerability right away? Document the reason (such as vendor patch unavailability or operational constraints) and implement compensating controls if possible. Record your decision and revisit it regularly until the vulnerability is remediated.
Does CMMC Level 2 require third party certification right now? No. As of July 2026, the Department of War has suspended the CMMC Phase II third party certification requirement pending review. However, DFARS 252.204-7012, NIST SP 800-171 Rev 2, self assessments, SPRS posting, and annual senior official affirmation are all still required and enforced.
Prioritize Vulnerabilities Based on Business Risk
If you are a defense contractor working toward CMMC or NIST 800-171 readiness and need help assessing your patch management process, consider applying for the Cyber Grants Alliance CMMC Gap Assessment Grant. This in kind grant is delivered as services and covers all 110 NIST 800-171 controls for qualifying defense contractors. Learn more at https://cybergrantsalliance.org/cmmc-gap-assessment-grant/.
By making the KEV Catalog your priority queue, you can meet compliance requirements and reduce your exposure to known threats, even with a small team.