3.11.3 — Fix What You Find

The One-Liner

Scanning without fixing is documenting problems without solving them.

What It Says

Remediate vulnerabilities in accordance with risk assessments.

What It Actually Means

Scan results without remediation are useless. Two things: vulnerabilities are identified (from scans, assessments, advisories) and they’re remediated in accordance with risk — highest risk first. Define remediation SLAs by severity: critical within 48-72 hours, high within 14-30 days, medium within 90 days, low in the next maintenance window. Track every vulnerability from identification through closure. The assessor will compare sequential scan results — if the same critical vulnerability appears in consecutive scans, that’s a finding.

---

Pass or Fail

Your assessor needs a “yes” to every row:

#	Question	What “yes” looks like
1	Are vulnerabilities identified?	Vulnerability scan results triaged and documented
2	Are vulnerabilities remediated by risk priority?	Remediation records showing SLA adherence; sequential scans showing closure

---

What to Have Ready on Assessment Day

Documents they’ll review: Risk assessment policy; vulnerability scan results (sequential); remediation records and SLA tracking; POA&M; patch management records; system security plan

People they’ll talk to: Personnel with risk assessment and vulnerability management responsibilities; information security personnel

Live demos they’ll ask for: “Show me your remediation SLAs by severity.” “Pick a critical finding — when found vs. when fixed.” “Show me sequential scans proving closure.” “How do you track remediation?”

---

The Assessor’s Playbook

These are the actual questions. Have answers ready.

• “Show me how you prioritize vulnerability remediation.”
• “What are your remediation SLAs by severity?”
• “Show me a critical finding — when was it found and when was it fixed?”
• “Are risk assessment results used to prioritize?”
• “Show me sequential scan results — are findings being closed?”

Real-World Example

A defense contractor defines remediation SLAs: Critical/KEV 48 hours, High 14 days, Medium 30 days, Low 90 days. Each finding from monthly scans gets a remediation ticket assigned to the responsible sysadmin. The IT Security Lead tracks SLA adherence in a dashboard. A follow-up scan 72 hours after each patch cycle validates closure. The assessor compares January and February scan results: critical findings from January are resolved in February; some medium findings persist with documented remediation plans.

---

Where Companies Trip Up

Scans without remediation. Reports pile up, nothing gets patched. Assign every finding a ticket with an owner and deadline.

No prioritization. Everything treated equally. Critical vulnerabilities sit alongside cosmetic findings. Use risk-based SLAs.

No tracking. Vulnerabilities fixed but not tracked to closure. Sequential scans should show decreasing vulnerability counts.

---

How to Talk About This

To a CEO or Board

Vulnerabilities are fixed by risk priority — critical within 48 hours, high within 14 days. Every finding is tracked from identification through verified closure.

To an Engineering Team

Remediation SLAs: critical 48h, high 14d, medium 30d, low 90d. Tickets per finding with owner and deadline. Follow-up scan validates closure. Dashboard tracks SLA adherence. POA&M for items needing extended timelines.

---

Connected Requirements

Requirement	Why it matters here
3.11.2 — Scan for Vulnerabilities	Scanning identifies the vulnerabilities this requirement remediates
3.14.1 — Patch Your Systems	Patching is the primary remediation method
3.12.2 — Track Every Gap	POA&M tracks items needing extended remediation

---

Implementation (coming soon)

Step-by-step setup for Microsoft 365 / Entra ID, AWS, Azure, and GCP — console steps, CLI commands, and evidence screenshots.

---

CMMC Practice ID: RA.L2-3.11.3 | SPRS Weight: 1 point | POA&M Eligible: Yes