What a board actually needs from a red team report
Fewer pages, more decisions. A structure that works.
The report is not the work
A red team operation produces a great deal of detail. Timelines, techniques, screenshots, logs and a long list of findings. All of it matters to the people who will fix things. Very little of it matters to a board.
Boards do not need to understand how an operation unfolded step by step. They need to understand what it means for the organisation, and what they are being asked to decide. A report that leads with technical detail asks them to do the translation themselves. Most will not, and the value of the operation stops at the security team.
Start with the decision
The most useful question to ask before writing is a simple one: what do we want the board to decide? Fund a programme. Accept a risk. Change a priority. Hold someone to a timeline.
This sounds obvious. In practice, most reports are written from the operation outwards, in the order things happened, because that is how the team lived it. Boards need the opposite order: the conclusion first, then just enough of the story to trust it.
If the answer is nothing, the report is a briefing, and it should be short. If the answer is something, everything in the board section should serve that decision and nothing else.
A structure that works
We use a structure of five parts. It fits on two pages, and everything else belongs in the appendix.
- The objective: what we set out to show, in business terms.
- The outcome: whether we got there, how long it took and whether anyone noticed.
- The impact: what a real adversary could have done from the same position.
- The causes: the few underlying reasons behind the findings.
- The asks: the decisions needed, each with an owner, a cost and a timescale.
Causes before findings
The most common mistake is to present a board with a ranked list of vulnerabilities. A long table, colour-coded by severity, tells a board that there is a lot to do. It does not tell them why it happened, or whether it will happen again.
Underneath most findings sit a small number of causes. Privilege that is granted easily and removed rarely. Monitoring that sees activity but lacks the context to judge it. Ownership that blurs at the boundary between teams. These are the things a board can actually change, through priorities, funding and accountability.
Name the causes plainly and connect each one to the findings it explains. The board then has something to govern, rather than something to worry about.
Language that travels
Board papers are read quickly and quoted later. Write for that. Use the organisation's own words for its systems and processes. Describe impact in terms the board already uses: customers, revenue, operations and obligations. Leave out any acronym that would need a glossary.
Be honest about what went well. If the defenders spotted something and acted, say so. It builds trust in the rest of the report, and it shows the board where investment is already working.
Keep the technical report too. It is the record your engineers will work from and the evidence that later reviews will ask for. It belongs behind the board paper.
What to do about it
Before the next report goes to the board, change its shape.
- Decide what you want the board to decide before you write a word.
- Keep the board section to two pages: objective, outcome, impact, causes and asks.
- Present the underlying causes rather than the list of findings, and give each one an owner.