Definition
Remediation is the process of fixing a confirmed vulnerability or weakness so it can no longer be exploited, then re-testing to prove the fix works.
What remediation means
In security, remediation is the work of removing a vulnerability or weakness so it can no longer be used by an attacker. It covers the whole job: understanding the finding, applying the fix, and proving that the fix works.
A finding is not remediated when a ticket is closed or a patch is installed. It is remediated when the weakness has been re-tested and can no longer be exploited.
Remediation vs mitigation vs risk acceptance
Not every finding can be fixed right away. Teams usually choose one of three responses:
| Response | What it means | Example |
|---|---|---|
| Remediation | Remove the weakness completely | Patch the software, fix the code, remove the exposed service |
| Mitigation | Reduce the chance or impact while the weakness remains | Block access with a firewall rule until a patch is available |
| Risk acceptance | Decide to live with it, with a documented reason | A low-risk issue on a system that is about to be retired |
Mitigation is often a sensible first step, but it should come with a plan and a date for full remediation. Accepted risks should be reviewed regularly, because exposure and threats change.
The remediation process
- Confirm the finding. Make sure it is real and understand how it can be exploited, so time is not wasted on false positives.
- Prioritise. Decide what to fix first based on exploitability, exposure and what the affected system gives access to.
- Assign an owner. Every finding needs a person or team responsible for the fix, with a target date.
- Fix the root cause. Patch, change the configuration, update the code or remove what is not needed. Fix the cause, not just the symptom.
- Re-test. Repeat the original attack to prove the weakness can no longer be used.
- Close and record. Document what was done, when and how it was verified, for audits and future reference.
How to prioritise remediation
Most teams have more findings than time. These questions help decide what goes first:
- Is it exploitable? A confirmed, exploitable finding outranks a theoretical one with a higher score.
- Is it exposed? Internet-facing systems usually come before internal ones.
- Is it being exploited in the wild? Vulnerabilities in the CISA KEV catalog or with a high EPSS score need fast action.
- What does it lead to? A finding on an attack path to critical data matters more than one on an isolated test system.
- Is it a choke point? One fix that breaks several attack paths is worth more than several isolated fixes.
Remediation timelines
Many organisations set target times for fixing findings by risk level, often called remediation SLAs. A common pattern looks like this, though the right numbers depend on your risk appetite and any regulations you follow:
| Risk level | Typical target |
|---|---|
| Critical | Within days |
| High | Within a few weeks |
| Medium | Within one to three months |
| Low | Next planned maintenance or accepted |
Whatever the targets, they only work if they are tracked and if overdue findings are escalated.
Why re-testing matters
Fixes fail more often than people expect. A patch may not apply to every server, a code change may block one input but not another, or a configuration may be reset by the next deployment. Without re-testing, these gaps stay open while reports say the problem is solved.
Re-testing with the same technique that found the issue gives a clear answer: either the attack still works, or it does not. It also produces evidence that auditors and customers can rely on.
Common remediation challenges
- Growing backlogs: new findings arrive faster than old ones are fixed
- Unclear ownership: nobody is sure which team owns the affected system
- False positives: time spent on findings that were never exploitable
- Partial fixes: the symptom is fixed but the root cause remains
- Regressions: a fixed issue comes back after an update or redeployment
- Slow re-testing: waiting weeks or months for the next test to confirm a fix
How to measure remediation
- Mean time to remediate (MTTR): the average time from finding to verified fix
- SLA compliance: the share of findings fixed within their target time
- Backlog trend: whether open findings are going up or down over time
- Re-open rate: how often fixed findings come back
How Plainsea helps
Plainsea makes remediation faster by cutting out the noise and the waiting. Findings are confirmed exploitable before they reach your team and come with the evidence and attack path behind them, so engineers know what to fix and why it matters. When a fix is in place, you can re-test it on demand instead of waiting for the next scheduled test, and close the finding with proof that it works.
Read more about remediation tracking in Plainsea.