Incident Communication to the Board

Board communication during a major ICT incident should give the management body a clear picture of the service effect, the response, the risk, and the decisions that need board attention, without dragging the board into the technical fix. The board needs to know what stopped, for whom, how the firm is responding, what remains uncertain, and what could change the picture. After the incident, the board needs the root cause, the lessons, and the follow up actions with owners and dates. That reporting supports oversight and challenge, and it creates the record that the board exercised its responsibility.

While an incident is running, the board needs a concise briefing, not a seat at the incident table. The briefing should state the services affected, the groups affected, the current state of restoration, and the main risks if recovery stalls. It should also state what decisions, if any, are being asked of the board, such as approving a major workaround, accepting a service change, or supporting a communication to customers or to an authority. A briefing that only describes technical symptoms will leave the board unable to judge the business risk, while a briefing that only reassures will leave it unable to challenge. The best briefings are short, updated at agreed intervals, and explicit about uncertainty.

The technical account explains how a system failed and how it is being fixed. The board account explains what that failure means for the firm, its customers, and its obligations. The two accounts draw on the same log, but they answer different questions. A board member does not need the name of every component involved, but does need to understand whether the incident threatens a service the firm has promised to keep within a tolerance, whether it affects a regulatory report, and whether it exposes a weakness in a provider relationship. Translating the technical account into those terms is the job of the incident lead and the service owner together, not a task to leave to the technical team alone.

Effective board challenge during an incident is focused and limited. The board can ask whether the classification reflects the service effect, whether the response has enough resources, whether customer communication is candid, and whether the reporting route to the authority is on track. It can also ask what would make the position worse, and what contingency exists for that case. What the board should avoid is directing the technical response itself, because that blurs accountability and slows the team that is closest to the fault. Challenge works best when the board has, before any incident, agreed what it expects to hear and when, so that during an incident it can test the briefing against those expectations rather than improvising its questions.

The post incident report to the board should cover the chronology in brief, the root cause as established, the service effect in full, the handling of customer and authority communication, and the lessons drawn. It should name the follow up actions, the owner of each, and the date by which each will be done, so the board can track completion rather than merely noting the lessons. It should also be candid about what went well, because a report that only lists failures teaches the firm to hide the next incident's weaknesses. Where the root cause points to a wider weakness, such as a provider dependency or a testing gap, the board report should say so plainly, even if the remedy will take time and money.

The record of board communication matters because it shows that oversight happened, not merely that information was sent. Minutes or notes that record the briefing given, the questions asked, and the decisions taken create a trail that a later reviewer can follow. They also help the next board, or the next incident, because they show what the firm learned and what it committed to do. A firm that briefs its board informally and keeps no record will struggle to demonstrate that the management body was engaged, however attentive its directors were in practice. Good incident governance is therefore partly about the quality of the briefing and partly about the discipline of writing it down.