Purpose
Turn findings into risk reduction
Scanning alone does not reduce risk. RACF-CC joins asset ownership, secure configuration, vulnerability intelligence, exposure and operational criticality so a small team can act on the weaknesses most likely to cause harm.
What good looks like
Supported assets have known owners and baselines, high-risk findings receive deadlines, remediation is verified, internet-facing and legacy systems receive extra attention, and unresolved exposure has compensating controls and formal acceptance.
Risk picture
Why backlogs become dangerous
Incomplete inventory
Unknown or poorly owned systems escape scanning, patching and lifecycle decisions.
Severity without context
A score alone does not capture exposure, exploitability, service impact or existing safeguards.
Configuration drift
Secure settings erode through rebuilds, exceptions and inconsistent policy application.
Internet-facing exposure
Public services face continuous scanning and require shorter review and remediation cycles.
Unsupported technology
Some vulnerabilities cannot be patched and persist without isolation or replacement.
Unverified remediation
A closed ticket may not prove that the weakness is absent from the live system.
Prioritised action
The RACF-CC vulnerability control set
| Priority | Control direction | Outcome | Evidence |
|---|---|---|---|
| First | Reconcile the asset inventory with scan, management and security-platform coverage. | Creates a trustworthy remediation denominator. | Coverage and ownership exceptions. |
| First | Prioritise actively exploitable, exposed and privilege-enabling weaknesses. | Focuses limited effort on plausible attack paths. | Risk-ranked queue and rationale. |
| First | Patch supported systems through defined emergency and routine timescales. | Reduces preventable exploitation. | Deployment and verification reports. |
| Next | Apply and monitor secure configuration baselines. | Reduces drift and unnecessary functionality. | Baseline compliance and exceptions. |
| Next | Review external exposure and remove unnecessary services. | Shrinks the reachable attack surface. | Exposure tests and service ownership. |
| Next | Contain unpatchable systems and record residual risk. | Reduces reachability while replacement is planned. | Segmentation and acceptance records. |
| Develop | Automate evidence collection, ownership and revalidation. | Makes remediation repeatable at scale. | Trend, ageing and rescan outcomes. |
Implementation
A four-phase roadmap
Phase 1
Know and triage
- Reconcile assets and scan coverage
- Assign system owners
- Review critical exposed findings
- Set remediation deadlines
Phase 2
Remediate and verify
- Patch supported platforms
- Remove unnecessary exposure
- Rescan after change
- Track overdue exceptions
Phase 3
Standardise
- Deploy configuration baselines
- Integrate vulnerability and change records
- Improve supplier coordination
- Report ageing and trends
Phase 4
Modernise
- Replace unsupported dependencies
- Automate routine assurance
- Test attack-path reduction
- Refine risk-based targets
Patch quickly, but safely
Urgency must be balanced with care continuity. Use risk-based emergency paths, representative testing, maintenance windows, rollback readiness and post-change verification. Where a patch cannot be deployed, reduce exposure immediately and record the residual risk.
Stage patches and configuration enforcement safely
Assess/audit → pilot → validate → enforce → monitor → reviewUse representative systems, maintenance approval, compatibility evidence, communications and tested rollback before expanding patches, baselines or application restrictions. Use the Safe Enforcement Pattern →
When patching is not feasible
Do not let “we can't patch it” become the end of the decision. Record the constraint, reduce exposure, apply compensating safeguards and put the remaining risk under dated review. Use the legacy-risk treatment guide →
Track the supplier side of remediation
Where fixes, testing or access depend on a third party, record responsibilities, evidence, escalation routes and the residual exposure rather than treating “with the supplier” as closure. Use the Supplier and Third-Party Risk guide →
Evidence
Measure exposure and ageing
Residual risk and escalation
Record vulnerabilities that cannot yet be remediated
What may remain unresolved?
Unsupported care applications, deferred patches, supplier-managed systems, scan blind spots and insecure configurations required by legacy dependencies may remain open.
Compatibility risk, care-service uptime, unavailable vendor fixes, maintenance constraints, replacement cost or incomplete asset access can delay remediation.
Remove exposure, isolate the system, restrict identities and protocols, increase monitoring, disable vulnerable features and maintain recovery readiness.
The accountable system or service owner owns continued operation, supported by vulnerability, infrastructure and supplier-management roles.
Review by severity and exposure, after new threat information, vendor updates, architecture change or any missed remediation target.
Active exploitation, internet exposure, critical-service impact, compensating-control failure, repeated deadline breach or loss of vendor support.
Recording does not equal acceptance. Deferral needs a justified treatment, accountable approval and an expiry or remediation decision—not an indefinitely open finding.
References
Standards alignment
- NIST SP 800-40 Rev. 4 — patch management as preventive maintenance.
- NIST SP 800-53 Revision 5 — flaw remediation, scanning and configuration controls.
Continue
Protect the information and prove recovery
Domain 5 combines controlled data access with backup governance and tested recovery.