Vulnerability Remediation

In accordance with risk assessments means you choose priorities, in writing.

The requirement does not demand that every finding be fixed. It demands that what you fix, defer, and accept follows your assessment of risk. Write the rule down: which severity levels get remediated and on what timeline, which can be accepted, and who signs the acceptance. One defensible rule remediates everything high and critical on a set timeline, drives mediums to a recorded fix-or-accept decision, and risk-accepts documented lows. The same behavior with no written rule is just a backlog.

Show the full life of a finding, twice.

The convincing evidence for this requirement is a pair of examples end to end: a vulnerability appearing in a scan, tracked in a ticket, fixed, and absent from the next scan. Two before-and-after report pairs demonstrate [a] and [b] together better than any process description.

Track what you decided not to fix, or the decision looks like neglect.

A finding you evaluated and accepted, with the reasoning and an owner recorded, is a met requirement. The same finding sitting unexplained in every quarterly report is an unaddressed vulnerability. Severity ratings from the scanner are the input. Your documented disposition is the evidence.

Use the scoring rule for gaps you cannot close on demand.

Under 32 CFR 170.24(b)(1), two kinds of gap are still assessed as MET. An enduring exception is MET when your system security plan, the document that describes how your system meets each requirement, describes the exception and its mitigations. A temporary deficiency is MET when an operational plan of action appropriately addresses it. The machine controller that cannot be patched without breaking the machine belongs in the first category, with its isolation described. The fix awaiting a vendor patch belongs in the second. The regulation gives you both paths, so use them instead of hiding the finding.

A finding whose exploit conditions do not exist in your environment can be reclassified, after an investigation you write down.

When a vulnerability requires a port you have closed, a module you have not installed, or a configuration you do not run, investigate. Record what you checked, and mark the finding not applicable. The documentation is the difference between a risk decision and wishful dismissal.