Glossary · Testing and assessment
Remediation ends when the weakness is gone, not when the ticket closes.
The work of removing a weakness found by testing, scanning or an audit, by fixing its cause so the same finding cannot be reproduced.
Back to the glossary01 · In plain words
In plain words
The work of removing a weakness found by testing, scanning or an audit, by fixing its cause so the same finding cannot be reproduced.
A test report hands you findings. Remediation is the engineering and process work that makes each one go away: a patch, a code change, a configuration fix, a new review step. It is done when the weakness can no longer be used, not when someone marks a task complete.
02 · Why it matters
Why it matters
Who cares about this, and what depends on it.
Auditors and buyers rarely judge you on the number of findings. They judge how you handled them. ISO 27001 includes a control on managing technical vulnerabilities, SOC 2 criteria expect deficiencies to be evaluated and corrected, and the HIPAA Security Rule expects risks to be reduced to a reasonable level. A report with ten closed findings, dates and retest evidence reads as a working programme. A report with three open criticals a year later reads as risk the buyer will now carry.
03 · Where you meet it
Where you will meet it
The documents, meetings and reports where it appears.
- The findings tracker
- Each finding with an owner, a target date by severity, and its current status.
- Vulnerability management policy
- The fix-by timelines you commit to for critical, high, medium and low items.
- Audit evidence
- Tickets, change records and retest results that show a finding was closed.
- Risk register
- Where a finding you choose not to fix is recorded as an accepted or treated risk.
04 · An example
A worked example
An illustration, not a real client.
Illustrative: a hospital software vendor after its annual test
A vendor of clinic scheduling software receives a report with one critical, four high and nine lower findings. It fixes the critical injection flaw at its root by switching the affected queries to parameterised calls across the codebase, not only on the reported page. Two highs need a library upgrade that breaks an integration, so the team adds a web application firewall rule as mitigation, records the residual risk, and sets a date for the real fix. Every item gets an owner before the report is filed.
05 · Easy to mix up
Easy to mix up with
Neighbouring terms that mean something different.
- Mitigation
- Reduces the chance or impact while the weakness still exists, such as a firewall rule. Remediation removes it.
- Risk acceptance
- A recorded decision, by someone with authority, not to fix. It is legitimate, but it is not remediation.
- Retest
- The check that remediation worked. Remediation is the fix itself.
06 · What to do
What to do with it
Practical steps, and the guides that go deeper.
- Assign an owner and a target date to every finding the day the report arrives.
- Fix the cause across the codebase or estate, not just the instance the tester reported.
- Record mitigations and accepted risks explicitly, with who approved them and when they will be revisited.
- Book a retest for high and critical items and keep the result with the original report.
- GuideTechnical vulnerability managementFinding, ranking and fixing weaknesses on a schedule.
- GuideVulnerability managementScanning, ranking and tracking weaknesses until they are fixed.
- GuideNonconformity and corrective actionFrom a finding to a fix that holds, with root cause.
Sources: NIST SP 800-115 (post-testing activities and mitigation); ISO/IEC 27001:2022 Annex A control 8.8 and clause 10 (described, not quoted); AICPA 2017 Trust Services Criteria, CC4.2 and CC7.1; 45 CFR 164.308(a)(1) on risk management.
Questions about Remediation
How fast should findings be fixed?
As fast as your own policy says, by severity.
No single framework sets one clock for every company. Teams commonly set the shortest window for critical items and longer ones for lower severities, then write those windows into policy. Auditors then test whether you met your own timelines.
What counts as proof of remediation?
A record of the change and an independent check.
Keep the ticket or change record, the commit or configuration diff, and a retest result from the tester or a scan that shows the weakness is gone. A developer's note that it is fixed is a start, not proof.
Want this applied to your own systems?
Our team can walk through where this term touches your scope, your contracts and your evidence.