System flaws are everywhere. Operating systems ship with vulnerabilities. Software vendors release patches weekly. Third-party tools like Adobe and Java need updates. The question is not whether your systems have flaws, but whether you have a process to find them, track them, and fix them before an attacker does.
SI.L2-3.14.1 requires you to identify system flaws, report them through your organization, and correct them in a timely manner. For most small defense contractors, this means implementing patch management: setting up your systems to check for and install patches on a schedule, defining timelines for when patches must be applied based on how severe they are, and scanning periodically to catch anything that slips through.
What the assessor is actually evaluating
Your patch management process. Do you have a documented policy that says when patches must be applied? Is there a person or team responsible for managing patches? Does your organization apply patches consistently, or do some systems fall behind?
Your patch timelines. The standard your organization chooses matters less than consistency and reasonableness. Critical patches should be applied within 24 hours, and if CISA or another authority issues an emergency directive, immediately. High-severity patches within 14 days, medium within 30, low within 90. Whatever timeline you set, you need to meet it.
Your vulnerability scanning. Are you actively looking for unpatched systems? A vulnerability scan run monthly or quarterly helps you spot systems that have fallen behind and find configuration drifts. The assessor will ask: when was your last scan, and what did it show?
Third-party patching. Patches are not just Windows Update. Chrome, Firefox, Adobe Reader, Java, Office, and dozens of other tools that run on your systems need updates. Do you have a process for identifying and applying these patches, or do they sit on systems indefinitely?
Patch exceptions and waivers. Sometimes you cannot patch a system immediately. A critical legacy application might not work with the latest patch, or a device might be isolated and require manual testing before patching. When this happens, you document why the system cannot be patched, what mitigations you have in place (such as isolation or compensating controls), who approved the exception, and when you will revisit it. The assessor expects to see these exceptions documented, not hidden.
SSP example section
Policy: System flaws are identified, reported, and corrected in a timely manner through our patch management process.
Process: The IT manager is responsible for patch management. All systems receive Windows Update checks at least weekly. Critical patches are applied within 24 hours of release, or immediately when directed by CISA. High-severity patches are applied within 14 days. Medium-severity patches are applied within 30 days. Low-severity patches are applied within 90 days. Patch status is reviewed monthly through Intune or WSUS compliance dashboards. Third-party applications including Chrome, Adobe Reader, and Java are patched through automated or manual updates on the same timeline as the operating system. Quarterly vulnerability scans are performed to identify unpatched systems and configuration drifts.
Exceptions: Systems that cannot be patched on schedule are documented in a patch exception log. The log includes the system name, the flaw or patch in question, the reason the patch cannot be applied, the date the patch will be revisited, and the IT manager approval. Mitigating controls such as network isolation or application whitelisting are applied to any system with an active exception.
Remediation: When a flaw is identified, it is logged with priority based on severity. Patches are downloaded and tested on a non-production system before deployment to production. If a patch causes a system or application to malfunction, the patch is backed out and documented as an exception.
How to present your evidence
Walk the assessor through your patch management tool. Open Intune, WSUS, or your vendor’s dashboard and show the compliance percentages. You want 95%+ of systems current on critical patches. If your organization uses an MSSP, ask the MSSP representative to pull up the compliance report during the assessment. Most MSPs keep this on a shared portal and can display it in seconds.
Show the assessor your patch policy document. A one-page policy is sufficient if it covers the timeline, the responsible party, the scope (what systems are included), and how exceptions are handled.
Bring vulnerability scan results from the last 90 days. Run a scan with Nessus, Qualys, or OpenVAS if you have not already. Walk through a few high-risk findings to show you know what the scan is reporting and how you plan to address it.
Bring documentation of any patch exceptions. A simple spreadsheet with the system name, reason the patch was not applied, revisit date, and approval signature. Even if you have no exceptions, say so and the assessor will move on.
Common failures
Patch compliance below 85%. The assessor will check your patch compliance report and see that 20 or 30% of your systems are 30, 60, or 90 days behind on critical patches. This is the most common failure. Usually it happens because patches were applied once or twice and then stopped. Push out patches automatically or check compliance monthly and make patching part of your routine.
No documented patch policy. You apply patches, but when the assessor asks what your timeline is, you say “as soon as we can.” Write down a simple policy. Critical within 24 hours, high within 14 days, medium within 30, low within 90. Sign it. You are done.
Third-party applications not patched. Intune shows your Windows systems are 98% patched, but Adobe Reader has not been updated in a year. The assessor checks a user’s system and sees the outdated version. Add Chrome, Firefox, Adobe Reader, Java, and any other applications your organization uses to your patch policy. Define how and when they get updated.
No scanning for vulnerabilities. You apply patches reactively when Microsoft releases them, but you have never run a scan to see if anything is missed. Conduct a quarterly vulnerability scan using Nessus, Qualys, or another tool. The scan does not need to be deep or exhaustive, but it needs to happen.
Patch exceptions with no documentation. A system is six months behind on critical patches because the user said it will break an old application if you update it. When the assessor asks about it, you have no documentation showing who approved the exception, what mitigations are in place, or when it will be revisited. Create a patch exception log and document these situations before the assessor asks.
If you use an MSP or MSSP
If your MSP or MSSP manages patching, the assessor will ask them to show the compliance dashboard. Make sure your vendor agreement specifies the patch timeline (critical within 24 hours, high within 14 days, etc.) and includes a clause stating that the vendor will provide compliance reports monthly or on request. During the assessment, ask your vendor to log into their portal and show the assessor your organization’s compliance percentage and recent patch activity. If the vendor cannot show compliance reports, that is a gap you need to close with them before the assessment.
Keep answers short. Show the evidence, don't describe it. Let the assessor drive. For more on how to present in the assessment room, see How to Present Evidence in the Assessment Room.
Q&A: What the assessor asks and what good answers sound like
This page reflects common practices for organizations pursuing or maintaining CMMC Level 2 compliance. Patch timelines and tools vary by organization. Always verify your specific requirements with your C3PAO or CMMC consultant. This is not legal or compliance advice.