Remediation
Remediation is the findings queue aggregated by fix.
A single missing patch can produce findings on forty hosts. The findings queue shows forty items, correctly - each is fixed and confirmed on its own. The remediation queue shows one piece of work with forty instances behind it, which is how the person doing it thinks about the job.
Same underlying data, grouped for a different question:
| Queue | Answers |
|---|---|
| Findings | What is wrong, and where? |
| Remediation | What should we do, and how much does each thing clear? |
Why work from this view
It surfaces leverage. Sorting by how many findings a remediation clears puts the highest-value work at the top, and it is frequently not what severity ordering would have chosen. One dependency upgrade closing sixty findings beats one configuration change closing one, even if the second is a Critical.
It matches how fixes actually happen. Nobody patches a library forty times. They patch it once and roll it out.
It makes estimating possible. "Upgrade this library across twelve services" is a thing you can size. "Forty findings" is not.
Working an item
A remediation carries what to do and which findings it resolves. The sequence:
- Pick by leverage, not only by severity.
- Check the instances. Forty findings is not always one job - some assets differ enough to need separate handling, and that is visible before you commit.
- Move the findings to a remediation status. See Findings and triage.
- Apply the fix.
- Let a scan confirm it. Findings close when a subsequent scan stops seeing them, not when somebody says the work is done.
That last step is the one to respect. A remediation marked complete on trust is indistinguishable from one that silently failed on eight of forty hosts.
Partial completion
A rollout that reaches most instances but not all is the normal case, not an exception.
Because each finding closes independently as scans confirm it, this resolves itself: findings on fixed hosts close, findings on missed hosts stay open, and what remains is visible rather than buried under a remediation someone ticked off. The stragglers are usually hosts that were down, out of scope, or drifted from their configuration - all worth knowing about separately.
Remediation and SLAs
SLA deadlines attach to findings, not to remediations. A remediation clearing forty findings clears forty separate deadlines, each computed from when its finding was opened.
So a remediation is not overdue; its findings are. If you are prioritising by deadline pressure, sort the findings and work back to the remediation that clears the most of them. See Remediation and SLAs.
Export
The queue exports to XLSX, which is the usual way this reaches people who do not use the platform - a patching team, a third-party supplier, a change advisory board.
API
The endpoints behind this section are in the API reference.
Next
- Findings and triage - the per-instance view
- Remediation and SLAs - how deadlines work
- Remediation SLA policy - setting them