Chapter 9 — Communication, ethics and reporting
Lesson map
Lesson 09 published. Map, example, EX041.
flowchart TD
N0["Learning outcomes"]
N1["9.1 Audiences"]
N2["9.2 One message, three forms"]
N3["9.3 Ethics"]
N4["9.4 Honesty"]
N5["9.5 Sensitive details"]
N6["Writing the summary"]
N7["Synthesis"]
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 Audiences"]
N2["9.2 One message, three forms"]
N3["9.3 Ethics"]
N4["9.4 Honesty"]
N5["9.5 Sensitive details"]
N6["Writing the summary"]
N7["Synthesis"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX041"]
[Learning outcomes]
|
v
[9.1 Audiences]
|
v
[9.2 One message, three forms]
|
v
[9.3 Ethics]
|
v
[9.4 Honesty]
|
v
[9.5 Sensitive details]
|
v
[Writing the summary]
|
v
[Synthesis]
|
v
[Worked example] --> [Exercise EX041]
Learning outcomes
You will (1) report findings clearly to different audiences; (2) handle sensitive information ethically; (3) avoid blame.
9.1 Audiences
Councillors want risk and cost in plain words; audit wants evidence; developers want technical detail. Each audience needs different information to make its decisions. Councillors decide on budget and accept risk on behalf of residents, so they need to know what was found, what was fixed and what remains. Audit decides whether findings can be closed, so it needs evidence for each. Developers carry out the changes, so they need exact permissions, images and versions. Hannah plans her reporting around these needs rather than writing one report and hoping it suits all three groups.
9.2 One message, three forms
Hannah writes a one-paragraph summary for councillors, an evidence table for audit and a technical note for developers. The three documents carry the same facts at different depths, so they never contradict each other. The summary for councillors states the risk and what was done in plain words. The evidence table for audit lists each finding, change, date and evidence. The technical note gives developers the details of removed permissions and rebuilt images. Hannah checks all three against the same source data before sending them, and Dev reviews them first. Hannah asks each audience whether the report met their needs and adjusts the format for the next one. Each report ends with a named contact for questions, so readers know whom to ask and do not guess at meanings.
9.3 Ethics
Findings describe systems and processes, not individuals. The contractor's leftover role is reported without naming the contractor. Leftover roles and excess permissions came from missing processes, not from individual carelessness. Naming people would not fix the causes, and could discourage staff from reporting problems in future. Hannah describes the contractor's role by its permissions and when it was last used, which is enough for audit to understand the finding. The same approach applies to the staff names in access logs, which are removed from shared summaries.
9.4 Honesty
Hannah reports the open reporting rebuild and the limits of 90 days of data rather than presenting a perfect picture. Ninety days of usage may miss rare tasks, so she states that unused permissions were confirmed with owners rather than inferred from logs alone. The open rebuild is reported with its exception and expected date. Hannah notes that presenting a perfect picture would undermine trust if the gap were discovered later. Being clear about limits also helps the council decide whether a longer review period is needed for future role reviews. Hannah avoids words like "critical" unless the evidence supports them, so readers trust her ratings.
9.5 Sensitive details
Detailed vulnerability information is shared only with those who need it until fixed. Until a vulnerability is fixed, details such as the affected image, version and exposure could help someone exploit it. Hannah shares this information with the digital team and Dev, who need it to fix the finding. The summary for councillors describes the risk in general terms without technical details. Once a fix is confirmed, the details can be shared more widely, for example with audit as part of the evidence for closing the finding. Reports go out after fixes for the most serious issues, so sensitive details are not circulated while still exploitable.
Writing the summary
The councillors' summary has four sentences: what audit found, what has been fixed, what remains and when, and the cost in staff time. It avoids technical terms. Hannah tests it on a colleague from another department, who suggests replacing "permissions" with "access rights", which councillors understand better.
The evidence table for audit lists each finding, action, evidence reference and date. The developer note includes role names, permissions and image versions.
Worked example
A councillor asks whether residents' data was at risk. Hannah answers that no evidence shows misuse, the most serious issues are fixed, and one internal item has compensating controls until fixed in two weeks.
Synthetic case. Synthetic.
Errors and limits
Reassuring without evidence damages trust when problems appear later.
Exercises
- EX041 — Audiences. What does each audience want? Rubric: 3 = councillors risk/cost, audit evidence, developers detail; 2 = two; 1 = one; 0 = none.
- EX042 — Blame. How was the contractor's role reported? Rubric: 3 = without naming; 2 = partial; 1 = vague; 0 = none.
- EX043 — Honest limits. Which limits did Hannah report? Rubric: 3 = open rebuild, 90-day data; 2 = partial; 1 = vague; 0 = none.
- EX044 — Detail sharing. Who receives detailed vulnerability information? Rubric: 3 = need to know until fixed; 2 = partial; 1 = vague; 0 = none.
- EX045 — Councillor answer. How did Hannah answer the councillor? Rubric: 3 = no evidence of misuse, serious fixed, one item controlled; 2 = partial; 1 = vague; 0 = none.
Synthesis
Tailor reports to audiences while staying honest and blameless.
Continue studying — chapter 09 of 12
← Chapter 08 (draft) · Course chapter index · Chapter 10 (draft) →