Scanning finds problems. Remediation fixes them. RA.L2-3.11.3 is where you prove that you actually address the vulnerabilities you discover. The assessor will focus on two areas: your documented remediation policy and your actual track record of fixing things.
Your remediation process closes the loop started by vulnerability scanning. Items you can’t remediate immediately go on your POA&M and feed your risk assessment. If a vulnerability requires a config change, that’s tracked in configuration management.
What the assessor is actually evaluating
The assessor will examine:
Remediation policy with clear SLAs: Your policy should state specific timelines for each severity level. Example: “Critical vulnerabilities must be remediated within 7 days. High-severity within 30 days. Medium within 90 days. Low-severity within 180 days.” The assessor will ask to see the policy and verify it is reasonable for your organization.
Actual remediation execution: The assessor will pull a sample of vulnerability findings (from scan reports over the past 6-12 months) and check whether each one was remediated. They will calculate the time from discovery to remediation and compare it against your policy. If you missed the SLA, that is a gap.
Evidence of remediation: For each vulnerability fixed, you should have a record showing what was done (e.g., “patched OpenSSL 1.1.0 to 1.1.1k on server-web-01” or “disabled SSL 3.0 on firewall”). The assessor may ask you to re-run the vulnerability scan to verify the fix was actually applied. For vulnerabilities that can’t be patched immediately (waiting on vendor fix, for example), document the compensating control or risk acceptance in your incident handling process.
What a realistic SSP definition looks like
Policy: “The organization remediates vulnerabilities according to the following schedule: Critical vulnerabilities within 7 days, High within 30 days, Medium within 90 days, Low within 180 days. Vulnerabilities without a practical remediation are mitigated through compensating controls or risk acceptance.”
Supporting details:
- Remediation tracking: Vulnerabilities are logged in Jira with assigned SLA dates based on severity.
- Approval process: The IT manager or security team approves remediation plans for critical/high findings before work begins.
- Verification: After remediation, a re-scan is performed within 5 days to confirm the vulnerability is closed.
- Exception process: If a vulnerability cannot be remediated within the SLA (e.g., requires a vendor patch), the issue is escalated and documented with a risk acceptance or compensating control plan.
How to present your evidence
- Remediation policy document: Signed and dated, with SLA timelines for each severity level. Should address what happens if a vulnerability cannot be remediated on time.
- Tracking spreadsheet or ticketing system reports: Show a sample of recent vulnerabilities with discovery date, assigned SLA, remediation completion date, and verification. Pull 10-15 vulnerabilities across all severity levels from the past 6-12 months.
- Remediation records: For each sample vulnerability, provide documentation of what was done. This might be a ticket description, a patch log, a configuration change record, or a screenshot showing the vulnerability no longer appears in the latest scan.
- Re-scan verification: Show that after remediation, a follow-up scan was performed and the vulnerability was marked as closed or no longer detected.
- Exception/waiver documentation: If you have any vulnerabilities that are mitigated but not directly remediated, show the risk acceptance or compensating control approval.
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.
Assessor: “Walk me through your remediation process. How quickly do you fix vulnerabilities?”
You: “We prioritize by severity. Critical vulnerabilities are fixed within 7 days, high within 30 days. Each vulnerability gets a ticket, and we verify closure with a re-scan.” [Pull up remediation policy and a sample Jira report]
Assessor: “Show me three critical vulnerabilities from the past year and their remediation records.”
You: [Pull up three tickets with dates from discovery to closure. Each shows the SLA was met or document why it was extended]
Assessor: “I see this one was discovered on January 15th and closed on January 19th. What was the vulnerability?”
You: “Critical remote code execution in Apache Struts. We patched the server on January 18th and re-scanned the next day to confirm.” [Pull up the patch record and verification scan]
Common failures
No documented SLA: You remediate vulnerabilities, but your policy does not specify timelines. The assessor will say “Your policy is vague. Without clear SLAs, I cannot determine whether you are remediating in a timely manner.” Define specific days for each severity level.
Missed SLAs with no explanation: You have critical vulnerabilities that are 45 days old, but your policy says 7 days. If there is no documented justification or risk acceptance, this is a compliance gap. Every missed SLA needs to be explained and documented.
No verification of remediation: You fixed vulnerabilities in a ticketing system but never confirmed the fix actually worked. Re-scan the system after remediation. Show the old vulnerability is no longer detected.
Short, practical breakdowns of what assessors actually ask and how to answer. No compliance jargon, no sales pitch. Subscribe free on Substack.
Clean remediation tracking: A spreadsheet or report showing every vulnerability discovered in the past year, with closure dates and verification scans. This demonstrates consistency and discipline.
Proactive remediation beyond SLA: Some vulnerabilities are fixed in 2-3 days even though the SLA allows 30. This demonstrates that your organization prioritizes security over merely complying with minimum thresholds.
If you use an MSP/MSSP
If your MSP remediates vulnerabilities on your behalf, ensure the service agreement includes specific SLA commitments that align with your policy. Request monthly remediation reports showing vulnerabilities fixed and timelines. You remain accountable to CMMC assessors for the remediation rate and timeline, even if an MSP performs the work. Have a clear escalation process for critical vulnerabilities that are approaching or exceeding the SLA.
This guide is for reference only and does not replace official CMMC documentation or professional compliance advice.