Severity tells the client what to worry about; remediation tells them what to do about it. Reports that pair both produce change.
Apply a vendor update that fixes the underlying flaw.
Modify settings so the flaw is absent in this deployment.
Fix the root cause in the application's own source.
Restructure so the vulnerable component is unreachable or unnecessary.
Leave the flaw; add controls that reduce likelihood or impact (WAF, segmentation, detection).
Document the residual risk as a conscious decision — the client's call, not the tester's.
Real engagements typically combine forms: patch long-term, restrict access short-term, monitor as compensating control.
Standard for known CVEs in vendor software. The report should address:
For misconfiguration findings, the fix is configuration. Specify:
"Configure the service securely" is not remediation. The specific directive is.
State clearly whether a recommendation is a true fix or a mitigation.
A defining quality of strong remediation: it addresses the root cause, not the individual symptom.
| Type | Example (SQLi at /search) |
|---|---|
| Symptom | Validate input on the search parameter |
| Root cause | Replace string-concatenated SQL with parameterized queries throughout; audit all endpoints for the same pattern |
Discipline: for each finding, ask "what is the underlying pattern?" — then recommend the pattern-level fix with the specific finding as one example.
Root-cause remediation fixes the class of findings — including ones the tester didn't discover. Engineering teams move faster fixing categories than instances.
The implicit test: "If I read this, can I open the relevant file or panel and make the change?"
Each line above is filler. None answers: where, how, against what threat?
A remediation block that becomes the operational ticket:
This structure maps directly to a Jira / ServiceNow / Azure Boards ticket — the client's team can take it straight to their backlog.
Combine multiple signals — not CVSS alone:
| Tier | Typical contents |
|---|---|
| Immediate (days) | Internet-exposed criticals; KEV-listed; auth/authz failures at scale; regulatory deadlines |
| Short term (weeks) | Highs in less-exposed contexts; mediums in high-criticality systems; foundational fixes |
| Medium term (months) | Bulk of mediums; lows in critical systems; architecture-level work |
| Long term (quarters) | Broad architectural changes; process improvements; technical debt without forcing function |
Deliver a prioritized remediation plan — not a CVSS-sorted inventory.
Client closes easy findings, defers structural ones indefinitely. The underlying class keeps producing new findings.
Client attempts architecture work for months while easy exploitable wins remain open.
Quick wins remove immediate exposure. Structural work addresses root causes. Both tracked openly — with honest acknowledgement that structural work takes time.
Push back when a small config fix is being deprioritized without reason — make the cost visible.
Retest scope, timing, and depth belong in the original scope document (Topic 04). Post-engagement friction most often traces here.
Engineers want technical specifics; management wants the bottom line. The executive summary of the remediation section answers:
Top priorities, effort, expected outcome. No CVEs, no directive names.
Per-finding remediation blocks with full specifics, referenced to each finding.
| Antipattern | Problem |
|---|---|
| "Update to the latest version" | Doesn't say what version, why, or the upgrade path; may not be safe or feasible |
| "Implement proper input validation" | Where, against what, with what consequences? |
| "Train your developers in secure coding" | Long-term cultural work, not a fix for this finding |
| "Disable the vulnerable service" | May be operationally impossible; ignores why the service exists |
| "Restrict access to authorized users only" | All access controls do this; doesn't address the specific inadequacy |
| "Use industry-standard cryptography" | Which? At what parameters? Replacing what? |
| Pasted boilerplate not referencing the finding | Signals the remediation work was not done |
These patterns are recognizable — clients and reviewers notice and discount the whole report.
Rank these four findings by remediation priority: (a) Critical CVE in an internet-facing service, no known working exploit; (b) Medium IDOR in a customer-data API; (c) Low — missing security header on internal staging; (d) Critical config-management drift across the production fleet, KEV-listed.
(d) first — KEV-listed means actively exploited in the wild; fleet-wide config drift amplifies exposure. (b) second — IDOR in a customer-data API is real customer impact even at Medium CVSS; authorization flaws score poorly but matter directly. (a) third — Critical with no working exploit is high latent risk; queue but not crisis. (c) last — Low in internal staging; queue with the bulk mediums. KEV + reachability + customer impact beats CVSS-only ordering.
Next: Topic 22 — Report writing. Turning findings, scores, and remediation into a deliverable that produces change.