We reach the point where the report stops describing problems and starts actually reducing risk. We documented each finding (06-01) and prioritized them by CVSS and business risk (06-02); we now have TechNova's priority table with the SQLi at the top. But a client does not pay for a pentest to receive a list of broken things: it pays to know what to do. The recommendations section is what transforms the report from a diagnosis into an actionable roadmap. It is, very likely, the part TechNova will read most.

In this lesson you will learn to write remediations a team can actually execute: specific (not "improve security"), prioritized (following the risk from 06-02), realistic (with what TechNova has, not with an ideal budget), and verifiable (so the fix can be confirmed). We will link back to the mitigations we already saw in Modules 4 and 5 without repeating them in full, we will talk about short/medium/long-term controls, about compensating controls when you cannot patch right away, about defense in depth, and about the retest. We do not cover here how to present all of this in the closeout meeting: that is the module's last lesson (06-04).

1. What makes a recommendation actionable
2. Anatomy of a recommendation
3. Fix the root cause, not the symptom
4. Prioritize remediation by risk
5. Short, medium, and long-term controls
6. Compensating controls when you cannot patch right away
7. Defense in depth
8. Verification and retest
9. Remediation roadmap for TechNova
10. Common Mistakes and Tips
11. Exercises
12. Conclusion

A recommendation is actionable when the team reading it knows exactly what to do the moment they finish reading, without having to research or interpret. Compare:

• Useless: "It is recommended to improve the security of the database."
• Actionable: "Rewrite all producto.php queries using PDO prepared statements with bound parameters; validate the id parameter as an integer before using it; and switch the application's DB account to one with read-only permissions on the tables it needs."

The second says what, where, and how. A good recommendation is specific to the finding and the asset, technically correct, and proportionate to the risk. Do not copy-paste generic advice: the value lies in grounding it in TechNova's case.

Each recommendation accompanies its finding and is best structured like this:

The estimated effort is a detail that sets the professional apart: TechNova needs to cross "how much risk do I reduce" with "how much does it cost me" to plan. A critical, low-effort fix is an obvious quick win.

The classic remediation mistake is covering the symptom. For TechNova's SQLi:

• Symptom (poor patch): filter out the single quote ' in producto.php. An attacker evades it with encoding and the flaw stays alive.
• Root cause (real fix): the application builds SQL by concatenating user input. The solution is to separate code from data with parameterized queries across all DB access, not just the parameter you happened to test.

Recall from Module 4 that the defense against SQLi is prepared statements (parameterized queries), input validation, and least privilege on the DB account. We do not repeat all that theory here: we reference it and turn it into a concrete instruction for TechNova's code. Fixing the root cause also means asking "is this same mistake elsewhere?": if producto.php concatenates SQL, categoria.php and buscar.php probably do too.

Remediation follows the risk order we set in 06-02, not whim or alphabetical order. What is critical and highest business impact is fixed first. But it is crossed with effort to identify quick wins:

A critical, low-effort finding (e.g. disabling an exposed admin panel) is done immediately; a critical, high-effort one (rewriting the entire data-access layer) is planned with resources but protected in the meantime with a compensating control (section 6).

Recommendations are grouped by time horizon, which helps TechNova plan without feeling overwhelmed:

The short term puts out the fire; the long term keeps it from reigniting. A report that only gives one-off patches condemns the client to repeat the same flaws in the next test.

Sometimes the definitive fix is not immediately feasible: rewriting code takes weeks, or the vendor has not yet released the patch, or the system is legacy and cannot be touched without risk. For those cases there are compensating controls: controls that reduce the risk without fixing the root cause, buying time.

For TechNova's SQLi, while the code is being rewritten:

• WAF (Web Application Firewall) with rules against injection patterns in front of tienda.technova.lab.
• DB account with least privilege right now: even if the code stays vulnerable, it limits what an attacker can do.
• Monitoring and alerting on injection patterns in the logs to detect attempts.

Make clear in the report that a compensating control does not replace the fix: it is a bridge, not the destination. A WAF can be evaded; it serves to reduce exposure while the real solution is applied.

No control is infallible, so good remediation layers defenses: if one fails, another contains the damage. For TechNova, a well-remediated SQLi is not just "parameterize", it is a stack of defenses:

Each layer contributes: validation reduces malicious input, parameterization fixes the root cause, least privilege limits the damage if something fails, the WAF filters known attacks, monitoring detects attempts, and encryption protects the data even if the DB is compromised. Defense in depth is what turns "I fixed the bug" into "I reduced the risk".

A recommendation is not closed until it is verified to have worked. That is why each recommendation includes how to check the fix, and the engagement usually contemplates a retest: the pentester repeats the tests for the fixed findings and confirms, with evidence, that they are no longer exploitable.

Typical states of a finding at retest:

For the SQLi, verification is direct: replay the payloads from finding TN-001 and confirm they no longer return data or SQL errors, keeping the screenshot as evidence of closure. The retest is what closes the loop and gives TechNova the assurance that the money invested in fixing translated into real risk eliminated. (The logistics of the retest as a next step are picked up in 06-04.)

We bring it all together into a roadmap that crosses priority, timeframe, effort, and verification. This is the deliverable TechNova executes:

Notice the logic: items 2 and 3 are quick wins (critical/high and low effort: done right away); item 1 is high effort but maximum risk, so it is protected with compensating controls while it is being rewritten; items 5 and 6, of low risk, do not steal resources from the urgent work. That cross-prioritization is exactly the value TechNova bought.

• Generic recommendations. "Apply best practices" helps no one. Ground each piece of advice in TechNova's specific asset and code.
• Covering the symptom. Filtering a single quote does not fix a SQLi. Always go to the root cause and check whether the pattern repeats in other files.
• Ignoring effort and the client's reality. Recommending "rewrite the whole backend this week" is useless. Give a phased plan with quick wins and compensating controls.
• Presenting the compensating control as the final solution. A WAF buys time, it does not close the vulnerability. State this explicitly so no one lowers their guard.
• Not defining verification. Without a retest criterion, no one knows if the problem was solved. Each recommendation says how it is checked.
• [Ethics] Recommending only to sell more services. The goal is to reduce TechNova's risk; recommendations are honest and proportionate, not a sales catalog.
• Tip: order by risk × effort. Quick wins with high impact and low cost build trust and momentum with the client.

Exercise 1. For finding TN-014 (admin panel accessible without authentication), write a complete recommendation following the anatomy in section 2: primary action, concrete steps, temporary mitigation, effort, priority, and verification.

Exercise 2. TechNova tells you that rewriting the data-access layer to fix the SQLi (TN-001) will take at least six weeks. Propose three compensating controls that reduce the risk in the meantime and explain why none of them replaces the definitive fix.

Exercise 3. Order these four findings for the roadmap and justify the order using risk and effort: (A) critical SQLi, high effort; (B) admin panel without auth, critical, low effort; (C) server version disclosed, low risk, low effort; (D) weak SSH passwords, high risk, low effort.

Solution 1. Recommendation for TN-014:

• Primary action: implement mandatory authentication and role-based authorization across the entire /admin/ directory, applying the deny-by-default principle.
• Concrete steps: (1) protect /admin/ with the application's authentication system; (2) verify the admin role on every action, not just at login; (3) check that no panel routes are reachable directly without going through the control.
• Temporary mitigation: restrict access to /admin/ by IP or require VPN while authentication is being implemented.
• Effort: low. Priority: high (quick win).
• Verification: try to access /admin/ without credentials and confirm it is denied; test access with a user without the admin role and confirm it is also denied.
• Reference: OWASP A01:2021 (Broken Access Control), CWE-284.

Solution 2. Compensating controls while the code is rewritten: (1) a WAF with anti-injection rules in front of tienda.technova.lab; (2) a least-privilege DB account (read-only on the necessary tables), to limit the damage if exploited; (3) monitoring/alerting on injection patterns in the logs to detect attempts. None replaces the fix because the code still builds SQL by concatenating input: a WAF can be evaded with encoding, least privilege limits but does not eliminate improper access, and monitoring detects but does not prevent. They reduce exposure and buy time; the root cause is only eliminated by parameterizing the queries.

Solution 3. Proposed order: B → D → A → C.

• B first: critical risk and low effort (a quick win of maximum value: a trivial access is eliminated right away).
• D second: high risk and low effort (another quick win that closes access to the internal server).
• A third: it carries the highest risk (critical), but its high effort forces it to be planned; it is launched in parallel with compensating controls from day one so as not to stay exposed during the rewrite.
• C last: low risk; even though the effort is low, it should not consume resources ahead of what is urgent. It goes to the backlog.

We have turned the prioritized risk list into a roadmap that truly reduces risk. We saw what makes a recommendation actionable (what, where, and how, grounded in TechNova), its anatomy, and the golden rule of attacking the root cause, parameterizing the whole data-access layer, instead of the symptom. We organized remediation by risk crossed with effort to draw out quick wins, staggered it across short/medium/long term, and learned to use compensating controls (WAF, least privilege, monitoring) as a bridge when you cannot patch right away, always without selling them as the final solution. We added defense in depth by layering controls, and we closed the loop with verification and the retest, which confirm with evidence that the risk was eliminated. Everything crystallized in TechNova's remediation roadmap.

We now have the complete report: findings documented (06-01), risks classified (06-02), and remediations with their roadmap (06-03). The written work is done. What is missing is what decides whether all this effort translates into action within TechNova: communicating it well. A brilliant report that no one understands, or that offends the technical team, reduces no risk. The module's last lesson, 06-04: Presenting Results, is about how to deliver and present all of this to each audience, leadership and technical, with the right tone and clear next steps.