Key takeaway
Use a CVSS score with context: asset importance, exposure, exploitation evidence and controls can change the priority.
Management goes beyond a scan
Vulnerability management is an ongoing process addressing software defects and misconfigurations in systems, networks and applications. Assessment, validation, prioritization and remediation are separate tasks. Inventory devices, servers, software and cloud services, then check coverage and authentication of scans comparing installed versions with vendor vulnerability information.
Set asset coverage
Inventory exposed and internal systems, devices, network equipment, cloud resources and applications with an owner and environment. Record scanner permissions, uncovered assets and result time. Coordinate scan windows with service owners and check impact on critical systems.
Validate findings and add context
Check asset and software-version identification and whether the finding matches the actual configuration. Document false positives, assessment limitations and compensating controls. Add the asset owner, data and service context to the validated finding so the priority decision rests on evidence.
Use risk-based prioritization
CVSS describes technical severity; combine criticality, exposure, exploitation evidence and potential harm for business risk. Review critical services, internet exposure and active exploitation first. A lower-severity flaw can be urgent when it opens a path to a critical system. Add owner impact assessment and remediation dependencies, then document response windows, escalation and reasons for priority so limited resources address meaningful risk.
Compare treatments and manage exceptions
Compare risk reduction, cost and operational impact. Assign a change owner, approved testing window and rollback plan. If correction must wait, obtain a risk-owner-approved exception with a compensating control, residual impact and expiry. Do not automatically mark a mitigated finding as fixed; retain the option’s rationale and review date.
| Treatment | When to consider | Evidence of outcome |
|---|---|---|
| Patch or upgrade | A supported fix is available and tested. | Version and configuration plus a retest. |
| Configuration or segmentation | Reduce a reachable attack path or temporary exposure. | Changed control and validation of its effect; track the remaining finding separately. |
| Retire or replace | The asset is unsupported, unneeded or lacks a sustainable fix. | Dependency and data migration, with confirmed removal. |
Verify the fix
Closure needs evidence of the change on the actual asset and a check of its outcome. If a fix fails verification or the issue recurs, return the task to an accountable owner.
Check the change
Match the intended asset, version and configuration to the approved change record.
Test the outcome
Run an authorized rescan or suitable technical check, recording coverage and date.
Close or reopen
Retain closure evidence. If a fix fails verification or the issue recurs, assign an owner and review the controls still in place.
Report program outcomes
Link findings on a dashboard to risk owners, dates, treatment and retests. Track coverage, critical open findings, remediation time and reopened issues. Give leadership risk trends and technical teams actionable work, using evidence for investment and process improvement. Recurring assessments test whether mitigations remain effective as new threats appear.