We have reached the last lesson of Module 6, and a point many technical people underestimate: an excellent report is worthless if it is not communicated well. We documented the findings (06-01), classified them by risk with CVSS (06-02), and built a remediation roadmap (06-03). The written work is finished. But the pentest's ultimate goal, helping TechNova reduce its risk, is only met if the organization understands, accepts, and acts on what we found. And that runs through people: the leadership that allocates budget and the technical teams that carry out the fixes.

This lesson is about how to present the results to different audiences, how the executive summary reads, how the closeout meeting (debrief) is run, how to manage the tone so it is constructive and not blaming, how to use metrics and comparison with standards to give context, and how to make the secure delivery of the report and set clear next steps, including the retest. It is the "soft" part of the pentest, but it decides whether all the technical work before it turns into action or stays a PDF forgotten in a folder.

1. One report, two audiences
2. The executive summary
3. The closeout meeting (debrief)
4. Tone: constructive, never blaming
5. Managing expectations
6. Metrics and comparison with standards
7. Secure delivery of the report
8. Next steps and retest
9. Common Mistakes and Tips
10. Exercises
11. Conclusion

We already saw in 06-01 that the report is structured into two blocks because it serves two audiences with opposite needs. When presenting it, that difference becomes critical:

The beginner's mistake is giving both the same technical talk: leadership gets lost in the jargon and tunes out, and the technical people get bored with the generalities. Adapt the message to the listener, telling the same story at a different level.

The executive summary is the most-read part of the report and the one that decides whether there will be budget to remediate. It is read by people with no time and no technical background, so it must be understandable in a few minutes and without a single line of jargon. What it contains:

• What was done and with what scope: one sentence about the authorized engagement against TechNova.
• Overall security posture: an honest assessment ("serious weaknesses were identified that require priority attention").
• Main risks in business language: the top 3-5 findings translated into consequences (customer data leak, store going down, non-compliance).
• A visual summary: usually a count of findings by severity.
• The highest-level recommendation: where to start and with what urgency.

Example excerpt of the executive summary, in markdown, for TechNova:

Notice the tone: it reports the risk with clarity and urgency, but without drama or jargon. Leadership walks away knowing what is at stake and what is being asked of them.

The debrief is the meeting where the pentester presents the results in person. It is the moment of greatest communicative value: it lets you add nuance, answer questions, and get everyone aligned. An effective structure:

Tips for the debrief:

• Start with the context, not with the juiciest finding. Remember it was an authorized test with an agreed scope.
• The attack timeline (the compromise chain from Module 5) is your best narrative tool: telling how a SQLi led to the internal server and pivoted to 10.10.10.0/24 makes the risk tangible better than any table.
• Adapt the depth to who is in the room. If leadership and technical people are together, start at a high level and offer to go into detail when needed.
• Leave time for questions. Often the client discovers in the debrief what they really need to understand.

This is perhaps the most important point of the lesson. The findings are someone's mistakes: a developer who concatenated SQL, an administrator who left a weak password. If your presentation sounds like an accusation, the team gets defensive, argues the findings, and remediation stalls. The goal is to help TechNova improve, not to hand out blame.

Contrast the tone:

Talk about the system and the code, not about the people. Frame each finding as an improvement opportunity with a known solution. Also acknowledge what TechNova does well: if the centralized logging was well set up or the segmentation held, say so. A report that only points out the negative comes across as unfair and loses credibility.

Presenting well includes correctly framing what a pentest is and is not, so that TechNova does not draw the wrong conclusions:

• A pentest is a snapshot in time, not a permanent guarantee. "We did not find X" does not mean "X does not exist"; it means it was not found within the agreed scope and timeframe.
• Scope and limitations: recall what was out of scope (systems, hours, techniques not permitted by the RoE). If an area was not tested, say so clearly so no one assumes it is "verified".
• Zero findings is not zero risk. And many findings do not mean TechNova is "worse" than others: it means it now knows where its problems are, which is an advantage.
• The responsibility to fix is the client's. The pentester diagnoses and advises; TechNova executes. Set clear expectations about timeframes and about the retest.

Managing expectations avoids two opposite reactions, both bad: panic ("we are doomed") and false calm ("we have been audited, we are safe forever").

Data gives context and makes the presentation more convincing and objective. Useful resources:

• Count by severity and evolution relative to previous audits (has TechNova improved since the last test?).
• Comparison with standards and frameworks: placing the findings against recognized references, OWASP Top 10, CWE Top 25, CIS controls, gives authority and helps the client understand that their problems are known categories with known solutions.

Mapping each finding to a standard turns your report from "one consultant's opinion" into "these are problems from the catalog recognized by the industry", which makes it easier for leadership to take them seriously and for the technical people to find established remediation guides.

The final report is the most sensitive document of the engagement: it is an exact map of how to compromise TechNova. Delivering it badly can cause more harm than the vulnerabilities themselves. Delivery rules:

• Encrypted and authenticated channel: never by unencrypted email. Use a secure portal, a password-encrypted file with the password shared over another channel, or end-to-end encryption.
• Only authorized recipients: the people designated in the contract, no one else.
• Clear confidentiality marking on the document.
• Delivery record: keep a record of who received it and when.
• Agreed retention and destruction: keep your encrypted copy for the agreed period and destroy it securely when it expires, along with the evidence (this links to the evidence handling in 06-01).

Secure delivery is not a formality: it is consistency with everything you have preached about confidentiality throughout the engagement.

A good presentation ends by looking forward, not back at the problem. Always close with concrete actions:

• Prioritize the remediation according to the 06-03 roadmap, starting with the critical quick wins.
• Set the retest: agree when the pentester will return to verify that the fixed findings are no longer exploitable, closing the loop (recall the retest states from 06-03: fixed / mitigated / open / risk accepted).
• Point of contact for questions during remediation.
• Continuous-improvement culture: fit the pentest into a periodic cycle, not as an isolated event.

The retest is what transforms "we know what is wrong" into "we confirmed we fixed it", and it is the best proof that the pentest met its goal: reducing TechNova's real risk.

• Giving a technical talk to leadership. They get lost and tune out. Talk business risk and leave the detail for the technical people.
• Accusatory tone. Blaming people puts the team on the defensive and stalls remediation. Talk about the system and the code, in terms of improvement.
• Only bad news. Acknowledge what the client does well too; it gives credibility and balance.
• Promising absolute security. A pentest is a snapshot in time, not a guarantee. Manage expectations.
• Delivering the report over an insecure channel. It is an attack map; encrypt it and control it. Leaking it would be the worst possible end to the engagement.
• Ending without next steps. Without an agreed roadmap or retest, the report gets forgotten. Always close with actions and a retest date.
• Tip: rehearse the debrief thinking "what would this person do when they leave the room?". If the answer is clear and actionable for each audience, you have done it well.

Exercise 1. You are going to present TechNova's results in a meeting with the CEO (non-technical) and the head of development (technical). Describe how you would structure the session and what you would adapt in the message for each, without giving two separate meetings.

Exercise 2. Rewrite these three sentences from a debrief draft so they are constructive instead of blaming: (a) "Your developers have no idea about security"; (b) "It is incredible that no one noticed this"; (c) "You have the worst security I have ever seen".

Exercise 3. The TechNova lead wants to send you the signed final report by regular email to "move fast" and forward it to the entire IT team. Explain what you would recommend and why, in terms of secure delivery and confidentiality.

Solution 1. Structure a single session in layers: begin with context and a high-level executive summary (for the CEO: what was done, overall posture, business risks, main recommendation), using the attack timeline to make the risk tangible without jargon. Once the CEO has the picture, go deeper into the technical detail for the head of development: specific findings, reproduction, and remediation, offering to drill down to maximum detail on the points they need. Close with the roadmap and next steps, relevant to both. You adapt the language (business vs. technical) and the level of detail, but you tell the same coherent story; that way the CEO decides to invest and the technical lead knows what to execute.

Solution 2. Constructive rewrites: (a) "The data-access code follows common vulnerable patterns; with secure training and parameterized queries it is fixed at the root"; (b) "It is a frequent flaw and easy to overlook; what matters is that it is now identified and has a known solution"; (c) "We found several priority areas for improvement; with the proposed plan they can be addressed in an orderly way, and there are controls that already work well and are worth keeping". All talk about the system, not the people, and point toward the solution.

Solution 3. I would recommend not using regular email: the report is an exact map of how to compromise TechNova, and unencrypted email is an insecure channel where it could be intercepted or forwarded uncontrolled. Instead: deliver it over an encrypted channel (a secure portal or a file encrypted with the key shared through another means), only to the authorized recipients in the contract, with a confidentiality marking and a delivery record. Forwarding it "to the entire IT team" needlessly widens the exposure: it should be limited to those with a genuine need to know. Speed does not justify turning the security deliverable into a data leak.

With this lesson we close Module 6 and the complete reporting cycle: document (06-01), classify by risk (06-02), recommend remediations (06-03), and now present the results so they turn into action. We learned to serve two audiences with one report, to write an executive summary without jargon, to run the closeout meeting leaning on the attack timeline, and, most importantly, to keep a constructive tone, never blaming, because the goal is to help TechNova improve, not to point fingers. We added managing expectations (a pentest is a snapshot in time), the use of metrics and standards like OWASP Top 10 to give authority, the secure delivery of the confidential report, and the next steps, with the retest closing the loop and confirming that the risk was really reduced.

Here ends the work of turning the pentest into value for the client: from the technical evidence captured in Module 5 we have arrived at a report that is presented, understood, and actionable. Throughout the whole course we have used an arsenal of tools, from reconnaissance to exploitation and reporting, often only in passing. Module 7: Additional Tools and Resources revisits that toolkit to get to know it in depth: the Kali Linux distribution, the Metasploit framework, the web-auditing proxies Burp Suite and OWASP ZAP, and the resources to keep learning continuously. With the method complete, it is time to master the tools that make it possible.