Prioritise security findings
Build a remediation backlog that considers exposure, exploitation evidence, business impact, dependencies and the proof needed to close each issue.
A remediation queue should explain why one action comes before another. Sorting a spreadsheet by severity is a useful view, but it does not establish the organisation's actual order of work.
Separate the technical finding from the treatment decision. Keep the original evidence and severity available, then record the local context, owner, action and review point. This makes changed priorities explainable when new information arrives.
Collect the context that changes the decision
| Question | Evidence to record | Why it changes the response |
|---|---|---|
| Are we affected? | Installed version, configuration and applicable vendor advisory | A product name alone may not establish applicability |
| Who can reach the weakness? | External exposure, network restrictions and access required | Exposure changes the opportunity for misuse |
| What is known about exploitation? | Credible advisory, observed activity or investigation result, with its date | A theoretical weakness and active compromise require different decisions |
| What would fail? | Service dependency, data sensitivity, safety and operational consequences | A technical impact needs business context |
| What reduces the risk now? | A checked control and its limitations | An assumed mitigation should not justify delay |
| What does the remedy depend on? | Supplier release, change window, test environment and rollback plan | Dependencies affect delivery, not the underlying risk |
FIRST's CVSS guidance explains why Base severity is not a complete risk assessment. For actively exploited weaknesses, the NCSC's vulnerability guidance also connects remediation with assessment for compromise. Installing an update does not establish whether an earlier intrusion occurred.
Worked backlog for a fictional service team
The records below are invented. The ordering illustrates a discussion, not universal deadlines or a mandated scoring model.
| Item | Evidence and context | Agreed action | Owner and review point |
|---|---|---|---|
| A: exposed gateway weakness | Applicable vendor advisory; exploitation reported externally; gateway provides access to business services | Escalate urgently, assess exposure and possible compromise, apply the approved containment and remediation plan | Platform lead with incident lead; review at the next incident update |
| B: cross-customer attachment access | Demonstrated with synthetic accounts in staging; same component awaits production release | Hold the affected release; correct entitlement checks; verify the production version separately | Application lead; review before release approval |
| C: unsupported internal reporting component | Limited network access; critical dependency for month-end reporting; replacement needs coordination | Confirm restriction, plan supported replacement and record the temporary risk decision | Reporting service owner; review before the next business-critical run |
| D: verbose error message | Demonstrated on a public service; no sensitive data shown in the observed response | Correct in the planned deployment and confirm that useful internal diagnostics remain | Web team; review at deployment verification |
Item A receives immediate attention because current exposure and reported exploitation may create an incident concern. Item B is a release decision: the team can prevent a known flaw entering service. Item C may need an interim control and an accountable exception while replacement is arranged. Item D still needs an owner, even though it does not displace the urgent work on this evidence.
If item D were found to disclose credentials, its context and priority would change. Do not preserve an old queue position when new evidence changes the consequence.
Record a treatment, not just a due date
For every significant finding, choose a documented next step:
- Remediate: change the underlying implementation or configuration, then verify the result.
- Reduce exposure temporarily: apply a specific checked control while a full fix is prepared.
- Remove the affected function or asset: verify that removal addresses the relevant access paths and dependencies.
- Accept a defined residual risk: obtain a decision from the responsible risk owner with a reason, expiry or review trigger, and conditions.
- Investigate applicability or impact: assign the uncertainty, evidence needed and decision deadline to someone.
“Awaiting supplier” is a dependency, not a complete treatment. Record what is being done while waiting and what event will cause escalation. A temporary firewall rule should have an owner and review point rather than becoming an undocumented permanent assumption.
Handle exceptions explicitly
An exception record should state the finding, affected assets, business reason, remaining exposure, interim measures and person accepting the decision. Include when it will be reconsidered: a date, a new vendor release, changed exposure or evidence of exploitation.
Do not lower a finding's technical severity simply to make an overdue item disappear. Keep the original assessment and the business decision together. Where the technical finding was wrong, correct it with supporting evidence and preserve the explanation.
Check progress by outcome
A useful review asks whether the risk has changed and what evidence establishes that. Counting completed tickets can hide partial deployments, failed changes or reopened findings.
For item B, “code merged” is an engineering milestone. “The agreed cross-customer checks failed safely on the deployed release, and normal authorised access still worked” is verification evidence. The retesting guide shows how to keep these stages distinct.
When observations suggest an incident, move the relevant investigation into the incident-triage process while keeping the remediation work linked. That preserves the question of what happened as well as what needs fixing.
Sources and further reading
- FIRST: CVSS v4.0 User Guide — checked 2 November 2026
- NCSC: Responding to active exploitation of vulnerabilities — checked 2 November 2026