Chapter 9 — Communication, ethics and reporting
Lesson map
Lesson 09 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Two voices"]
N2["9.2 Pressure"]
N3["9.3 Responsible handling"]
N4["9.4 Report structure"]
N5["9.5 Threat-led language"]
N6["9.6 Positive observations"]
N7["9.7 Clear recommendations"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX041"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["9.1 Two voices"]
N2["9.2 Pressure"]
N3["9.3 Responsible handling"]
N4["9.4 Report structure"]
N5["9.5 Threat-led language"]
N6["9.6 Positive observations"]
N7["9.7 Clear recommendations"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]
[Learning outcomes]
|
v
[9.1 Two voices]
|
v
[9.2 Pressure]
|
v
[9.3 Responsible handling]
|
v
[9.4 Report structure]
|
v
[9.5 Threat-led language]
|
v
[9.6 Positive observations]
|
v
[9.7 Clear recommendations]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) write for executives and for engineers; (2) handle pressure to hide findings; (3) apply responsible disclosure ethics; (4) structure the HCU report.
9.1 Two voices
Executives get risk, affected members, decisions and dates. Engineers get reproduction, evidence and fix guidance. Mixing them produces a report nobody finishes. Leo drafts two paragraphs for the cookie-flag finding that share the same facts. The CISO paragraph covers member-session risk, asks for one decision, the 1 November date for the cookie fix, and names app-sec as owner. The app-sec paragraph gives reproduction steps and the Secure and HttpOnly fix, quoting the staging response header and the Set-Cookie attributes that are missing.
9.2 Pressure
Someone may ask to drop a finding before an exam. Leo's answer: findings stay; owners may add a management response. Ethics beat convenience. Requests usually arrive in the weeks before the annual exam, when owners fear an open item on the examiner list. In the worked example the request came from a product manager and concerned the open-redirect finding. Leo kept the finding, told his supervisor the same day and offered to place the manager's remediation plan beside the finding as a management response. The written record of the request goes into the engagement notes, so examiners can see the finding survived pressure; softening facts under pressure destroys trust when examiners ask later.
9.3 Responsible handling
Do not publish HCU findings publicly. Do not share with friends. Vendor bugs found in third-party software follow the vendor's disclosure path only with CISO approval. HCU findings stay inside the agreed audience: the report's distribution list names the CISO, the online-banking product owner, app-sec and the network team, and nobody else. Friends and public posts are never an audience. If Leo finds a bug in a vendor product used at HCU, he stops and logs it in the ENG-440 notes with product and version, and asks the CISO before any vendor disclosure path is used.
9.4 Report structure
Executive summary; scope and methods; findings by severity; positive observations; retest plan; appendices. Leo's ENG-440 report follows that order so the CISO can read the summary and decisions first, while engineers open the appendices for evidence. The executive summary fits on one page and ends with the decisions the CISO must take this month. Each appendix is referenced by finding number, so an engineer can jump straight to the evidence. Skipping positive observations or the retest plan leaves leaders without balance or a next step.
9.5 Threat-led language
If HCU later sponsors a CBEST or TIBER-EU style test, reports also describe scenarios and detection gaps, still without publishing exploit detail. Leo's current reports stay within HCU's web and VPN review. The scope line in the ENG-440 report reads web and VPN configuration review, matching the signed ROE word for word, so examiners reading the method notes do not see a threat-led exercise HCU has not sponsored. Calling ENG-440 threat-led would also imply intelligence work and a white team that HCU never organised. Leo keeps CBEST and TIBER-EU language out of ENG-440 until the CISO funds that programme separately.
9.6 Positive observations
Reports should also note what worked: MFA on staff VPN logins, rapid SOC response to the start message, clean staging isolation. Positive observations show balance and tell leaders which investments are paying off; leaders who only see failures cannot tell which investments to keep. Leo limits the VPN observation to ordinary staff logins, because the shared admin password finding shows that the admin path did not yet require a second factor. Each positive observation carries evidence, such as the time the SOC took to acknowledge the start message. Keeping staging isolated is an investment the CISO can defend at budget time because the report shows it held.
9.7 Clear recommendations
Each finding's recommendation names a concrete change, an owner role and a suggested date. "Improve security" is not a recommendation; "set Cookie Secure and HttpOnly on the session cookie in the online-banking app by 1 November, owner: app-sec" is. Vague improve-security lines are rewritten before the report leaves the team, and each rewritten line names the owner and the change, so tickets can be opened without a decoding meeting. The ticket opened from the cookie line is T-15, which only became closed-ready once the owner and verification that lab_ticket reported missing were filled.
9.8 Review before send
A peer reads the executive summary for blame language, missing decisions and unexplained jargon. That review takes about ten minutes and happens before the summary reaches the CISO. Catching blame language, missing decisions and jargon before send avoids a rewrite the night before an examiner meeting. The peer is someone outside ENG-440, so the summary is read by a person who did not sit through the testing. Comments go into the draft as tracked changes, and Leo resolves each one before the report leaves the team.
Worked example (synthetic HCU)
A product manager asks Leo to remove the open-redirect finding until after the exam. Leo refuses, offers to include the manager's remediation plan beside the finding, and informs his supervisor.
Synthetic case — Harborline Credit Union (HCU). The credit union, Leo Okonkwo and all figures are invented for teaching.
Errors and limits
Local policies and laws differ; follow HCU's authorization and your jurisdiction. This book never authorizes testing of real systems.
Exercises
- EX041 — Exec sentence. Write one executive sentence for open redirect on online banking. Rubric: 3 = risk to members + decision ask; 2 = partial; 1 = jargon only; 0 = none.
- EX042 — Engineer detail. What three technical points do engineers need? Rubric: 3 = reproduction, evidence ref, fix guidance; 2 = two; 1 = one; 0 = none.
- EX043 — Drop request. How does Leo answer a request to drop a finding? Rubric: 3 = refuse; offer management response; tell supervisor; 2 = refuse; 1 = drop it; 0 = none.
- EX044 — Public blog. May Leo blog about HCU's findings after the test? Rubric: 3 = no; confidential under agreement; 2 = no; 1 = yes anonymised freely; 0 = none.
- EX045 — Report order. Order: appendices, executive summary, findings. Rubric: 3 = summary, findings, appendices; 2 = partial; 1 = wrong; 0 = none.
Synthesis
Tell the truth in the right voice; never drop findings under pressure; keep results inside the agreement.
Continue studying — chapter 09 of 12
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →