Remediation recommendations that get acted on

Objective 5.2 in this course covers documentation — creating attack narratives and providing remediation recommendations. This is the remediation half, the Domain 5 capstone, and the last lesson in the course.

Why this matters

A finding nobody fixes protected nobody. Remediation is where the entire engagement either produces value or does not, and it is the part testers most often do badly — because it requires understanding not just the vulnerability but the client's constraints, and writing advice they can actually follow.

The course opened (lesson 1) with "the deliverable is the report, not the shell." This lesson is where that claim is cashed: a report whose recommendations get acted on is the difference the client paid for.

The lesson

Fixing the cause rather than the instance you found

The single most important principle, and one every Domain 4 lesson pointed at.

• Fix the class, not the case. One SQL injection found means the pattern that produced it exists elsewhere. "Parameterise this query" fixes one; "the application builds queries by concatenation — parameterise throughout, and add a check that prevents new concatenated queries" fixes the class. Lessons 30 to 32 each made this point; the report is where it lands.
• Ask why the vulnerability exists. A missing patch is an instance; the absence of a patching process is the cause. Recommending the patch fixes today; recommending the process fixes the recurrence.
• Group findings by root cause in the recommendations, so the client sees that fifteen findings may share three causes, and fixing the causes closes the fifteen and prevents the next.

The framing to the client: individual fixes are necessary but they are treating symptoms, and the value of the report is in naming the causes so the same findings do not return next year.

Sequencing: what to do this week against this year

A client cannot do everything at once, so unsequenced recommendations get triaged by the client — badly, or not at all. Sequencing is part of the advice.

• Immediate. The things that need doing now — a critical, internet-facing, demonstrated path to sensitive data. Often a temporary mitigation while the real fix is built.
• Short term. The high-impact fixes that need a little planning.
• Longer term. The structural changes — a patching process, segmentation (lesson 22), tiering (lesson 26), an identity redesign (lesson 34) — that remove whole classes but take time and investment.

The sequence should reflect risk, from lesson 6's severity work, not the order you found things. And it should be realistic: a recommendation to re-architect the network by Friday will be ignored, which helps nobody.

Cost, disruption and the recommendation a client can afford

Recommendations that ignore the client's constraints get ignored in turn, so the advice accounts for what a fix costs to apply.

• Acknowledge cost and disruption. A fix that requires downtime, a purchase, or significant effort should say so, so the client can plan rather than be surprised into inaction.
• Offer the realistic option, not only the ideal one. The textbook fix may be unaffordable this year; a recommendation that also gives a cheaper interim reduction is one the client can act on now.
• Match the fix to the organisation. A small team and a large enterprise cannot follow the same advice, and a recommendation should fit who is receiving it.
• Do not recommend a product as the answer where a configuration change is the answer — most of this course's findings are fixed by configuration and process, cheaply, and saying so builds the trust that gets the report acted on.

The honest framing: the best recommendation is the one that actually gets implemented, and that is frequently the good-enough fix the client can afford rather than the perfect one they cannot.

Compensating controls when the real fix is not available

Sometimes the proper fix genuinely cannot be applied — a legacy system that cannot be patched, an application that cannot be changed, a business constraint that blocks the ideal. The recommendation cannot then be "do the impossible."

• Offer compensating controls. If the vulnerable system cannot be fixed, what reduces the risk around it — segmentation to limit its reach (lesson 22), monitoring to detect exploitation, restricted access to shrink exposure?
• Reduce the attack surface. If a flaw cannot be removed, make the vulnerable path reachable by fewer people.
• Be explicit that it is a mitigation, not a fix. A compensating control manages a risk that remains, and the report should say so, so the client does not record the finding as resolved when it is contained.
• Recognise accepted risk. A client may decide, informed, to accept a risk — and a recommendation that offered a realistic path lets them make that decision knowingly rather than by default.

This is the same reasoning as lesson 18's "a true positive that is not a real risk," applied forward: severity accounts for compensating controls, and so does the remediation.

Re-test criteria agreed in writing

The engagement closes here, and it closes by defining how the client will know the fixes worked — which is where the whole report's re-run standard (lesson 40) pays off.

• Define what "fixed" means for each finding, so a re-test has a clear pass condition rather than a judgement call.
• The narrative is re-runnable (lesson 40), so the re-test is concrete: follow the path again and confirm it is now blocked.
• Agree the re-test in writing — scope, timing, and what will be checked — as part of closing the engagement, so verification is planned rather than improvised months later.
• This is also the re-test criterion the earlier lessons kept deferring: lesson 22's "verify segmentation on a schedule," lesson 34's "continuously check" — the report is where those become a commitment with a definition.

The engagement that ends with agreed re-test criteria is the one whose fixes get verified, which is the one whose findings actually stay fixed — and that is the whole point of the report, and of the course.

What to take into the exam

• Fix the cause, not the instance: group findings by root cause, and address why the vulnerability exists, not just the case you found.
• Sequence recommendations by risk into immediate, short and longer term, and make them realistic.
• Account for cost and disruption; the best recommendation is the one that gets implemented, often a good-enough affordable fix over an unaffordable ideal.
• Offer compensating controls where the real fix is unavailable, labelled as mitigations of a remaining risk.
• Close with re-test criteria agreed in writing, using the re-runnable narrative to define what "fixed" means.