Communicating with the Client and Presenting Results

A written report, however well crafted, rarely speaks entirely for itself. Most engagements end with a conversation: a presentation, a call, or a meeting where findings are discussed, questions are answered, and priorities are negotiated. This lesson prepares you for that conversation.

Why the conversation matters as much as the document

A report delivered silently by email can be misread, skimmed, or misunderstood, especially by readers without a deep technical background. A short presentation or discussion lets you adapt your explanation to the specific audience in the room, answer questions immediately, and gauge whether the most important message (from your executive summary) has actually landed. Many clients remember the conversation long after they have stopped looking at the document itself.

Preparing a results presentation

A typical closing presentation, often thirty minutes to an hour, generally follows this shape:

1. Reminder of scope and objectives, briefly, so everyone starts from the same shared understanding.
2. Overall risk picture, in plain language, mirroring the executive summary, often with a simple visual (such as a count of findings by severity).
3. The two or three most important findings, explained clearly, with enough context for a non-technical listener to understand both the issue and why it matters, saving exhaustive technical detail for the written report and for a separate, technical-only discussion if needed.
4. Clear, prioritised recommendations, directly connected to the findings just presented.
5. Time for questions, which is often where the most valuable part of the conversation actually happens.

Adapting your language to your audience

The same finding needs two different explanations depending on who is listening:

Audience	How to explain a finding
Executive	"An attacker could potentially access customer records without authorisation, which creates both a direct business risk and a regulatory one."
Technical team	"The order lookup page does not verify that the requesting user owns the order identified in the address, allowing retrieval of other users' order details by changing that identifier."

Both describe the same underlying weakness, but a good communicator gives each audience the version they actually need, without ever contradicting the other version or hiding genuine severity behind vague executive language.

Handling difficult reactions calmly

Findings can sometimes provoke defensive reactions: a team that built the system may feel criticised, or a manager may worry about budget implications. A professional tester stays calm, factual, and constructive in these moments:

• Reaffirm that the goal of the engagement is to help the organisation improve, not to assign blame to individuals.
• Stick to what was directly observed and confirmed, resisting the temptation to speculate beyond the evidence, even under pressure to give a definitive answer you do not actually have.
• Acknowledge genuine uncertainty honestly ("we did not have time to test X fully, so I cannot speak to that with confidence") rather than guessing to appear more authoritative.
• Offer to clarify technical points in writing afterwards if a live discussion becomes heated or unclear, giving everyone space to process calmly.

Supporting remediation, within the agreed boundaries

Many engagements include a limited period of follow-up support, for example clarifying questions as the client's team works on fixes, or a scheduled retest of the most critical findings once remediation is claimed complete. Being clear about exactly what support is, and is not, included (as should already be defined in the original contract from chapter 1) avoids misunderstandings and scope disputes after the main engagement ends.

Confidentiality continues after the engagement

The confidentiality obligations discussed throughout this course do not end when the report is delivered or the presentation given. A professional never discusses a specific client's findings, even in general or anonymised terms that might still be identifiable, in public talks, social media, or casual conversation, without the client's explicit, separate permission.

Your fil rouge: presenting Lighthouse Labs

Using the report you wrote in the previous lesson, prepare a short, written presentation outline following the five-part structure above: a few bullet points per section, written so that both an imagined non-technical "Lighthouse Labs owner" and an imagined technical lead could each get what they need from it. Save it as 06-report/presentation-outline.md.

Your turn: handle a reaction

During your results presentation, a development team lead says, visibly frustrated: "This finding is wrong, our code definitely checks permissions properly, you must have made a mistake." You are confident in your evidence, which includes a clear, saved screenshot showing the issue. How do you respond, in the room, in two or three sentences?

See a solution

A calm, professional response: "I understand this is unexpected, and I want to make sure we get to the bottom of it together rather than leave any doubt. Here is the exact evidence we captured [show the screenshot and the steps taken]; if you can show me the specific check you believe should have caught this, we can walk through it together right now or follow up in writing afterwards." This response stays factual, offers the concrete evidence rather than arguing from authority, and proposes a constructive path forward instead of escalating the disagreement in the room.

The next lesson steps back to look at where the legal and ethical boundaries of this whole profession truly sit, and when a tester must say "no" or stop.