A board pack can be accurate and still be late.
Board-level privacy failures rarely begin with a director ignoring an obvious risk. They begin earlier, in how the organisation reports the risk in the first place. A cyber incident gets handled by the technical team and reported through one channel. Privacy sits with another team and reports through another. Legal exposure arrives through a third. Customer impact is managed somewhere else again. Each report can be correct on its own terms, and yet none of them, taken alone, tells the board what is actually happening.
The reporting treats cyber, privacy, legal and customer impact as separate but related problems, when they are actually dimensions of the same incident that needs to be treated as one.
This piece came together at a security conference where a Medibank speaker landed a line that has stayed with me since: security teams look for evidence; if there is no evidence of an intruder, they report it as such until they find one, but that doesn’t mean the intruder isn’t in the building. The line was about cyber, but the pattern generalises. “No evidence” gets read by boards as “no risk”, when it actually means “we haven’t seen the signs yet”. The same pattern came up again when I was recently briefing a board on the Australian Clinical Labs decision: each report on its own was telling the truth, and the board was filling the gap with the wrong assumption.
The Privacy Event Forms Inside The Cyber Event
In the early hours of an incident, cyber containment dominates. The technical team can describe what was breached, what is being patched, and where the perimeter holds. That report is necessary, and usually first. It also frames the issue as a technical event, which is true but partial.
The privacy event is forming inside the cyber event. Personal information may be involved. The harm profile is starting to take shape. Notification thresholds are being assessed. The regulator’s likely response is being read. The customer impact is being modelled. All of this is happening at the same time as the technical containment, often by different teams on different clocks, and none of it is captured in the cyber report.
When the privacy report arrives, it arrives separately, after the technical report has already framed the board’s understanding of the event. The information in each is correct, but the picture each gives the board is incomplete; the board has received two reports about one event and been left to assemble the picture between them.
Timing Is Where Most Board Papers Quietly Lose Value
Boards don’t need every operational detail during a fast-moving incident, but they do need to know what decisions are coming, what assumptions management is operating under, and what information would change the call. Most incident timelines that get reported are technical timelines: what happened, what was contained, what is being restored. Those are necessary, and they aren’t the governance timeline.
The governance timeline runs in parallel and ends at different decision points: notifications that have legal deadlines, customer communications that have to go out before customers hear it from somewhere else, regulator engagement that has to happen while there’s still time to shape the response. The board needs to see both timelines running, not just the incident as it unfolds in real time.
Status reporting outside incident response has the same problem in slower form. A dashboard might show a control declining one quarter and stabilising the next, and present the second movement as recovery, even though the control may still be materially below its previous level. Nothing has improved (the deterioration has simply stopped getting worse), and the board has been shown a flat line that signals stability without delivering it. Reporting cultures often prefer status to bad news because “stable” is easier to present than “underperforming with no credible remediation path”, and boards end up seeing the framing the reporting culture preferred, not the deterioration that actually happened.
The Synthesis Has To Be Someone’s Job
Strong board reporting on incidents doesn’t abandon technical detail. It puts technical detail inside a governance frame. Directors should still get the core facts. They also need a synthesis of privacy impact, regulatory exposure, likely decision points, customer consequences, and what those mean for control design going forward. That synthesis can’t depend on directors connecting three committee papers and five management updates themselves.
It has to be assembled deliberately, and someone has to own the assembly. A board paper that does this well distinguishes what is known from what is assumed and what is still unresolved. It names the decisions that have to be made now, what new information would shift them, and where the incident exposes broader weaknesses the board should be governing alongside the event itself.
The Australian Clinical Labs case is the example of what happens when the wrong person owns the synthesis. ACL’s incident in 2022 was run by the CIO with an external cybersecurity consultancy, StickmanCyber. StickmanCyber concluded the attack had caused no harm because they could not confirm data had been exfiltrated, and ACL determined on that basis that the breach didn’t meet the notification threshold for the OAIC. The problem was the test: “no evidence of exfiltration” is the cyber test for what happened, but “likely to result in serious harm to one or more individuals” is the privacy test for what to notify. The cyber team owned the synthesis, applied the cyber test to a privacy question, and the answer came back wrong. Four months later, 86GB of patient health and financial data appeared on the dark web. ACL eventually notified the OAIC, paid $5.8 million in civil penalties (Australia’s first under the Privacy Act), and 223,000 individuals went four months longer than they should have without the warning that would have let them take protective action.
Boards rarely fail to act because they were given too little information. They fail to act because the information arrived in pieces, on different clocks, from different functions, and the synthesis was left for them to assemble in real time. The organisations that brief their boards well during a privacy incident don’t generate more reports. They either appoint someone to assemble one, or they require all the experts in the room with the right information before the assembly of one (so the ACL case doesn’t happen to them).