Governance Reporting Lines and Escalation

Reporting lines show how information about ICT risk travels from operations to the management body. Escalation shows what happens when a risk, incident or finding is serious enough to require higher level attention or a board decision. Under DORA governance, both need to be clear before they are needed, because during a disruption there is no time to design a route, and after a disruption it is too late to discover that the route did not exist.

Clear lines and escalation routes protect the management body from two opposite failures: being flooded with detail that obscures serious risks, and being shielded from serious risks by filtering at lower levels. The aim is a route that carries material information upward promptly, with enough context for judgement, while routine information is handled at the level where it belongs. Governance design, and the culture around escalation, determine whether that aim is met.

Reporting lines should follow services and decisions, not only organisational charts. A line that reports technology activity upward, without linking it to services, gives the board information it cannot easily judge. A line that reports by service, with technology and provider information attached to the service it affects, gives the board a basis for decisions. Design should therefore start from the question: who needs to know what, in order to decide what, and by when?

Escalation should be triggered by materiality to services and customers, not only by technical severity. A technical fault that affects a critical customer service requires escalation even if the underlying cause seems routine. Conversely, a technically complex issue with no customer impact may be handled at operational level, with reporting in due course. Materiality criteria should therefore be expressed in service and customer terms, so that operational teams can recognise an escalation case without needing board level judgement.

Other triggers include risks that exceed appetite, test findings that reveal a recovery weakness, provider incidents that affect a critical service, and remediation that is delayed beyond its agreed point. Each trigger should name who escalates, to whom, and with what information. Vague escalation guidance, such as escalating significant issues, leaves the crucial judgement undefined. More useful guidance describes the kinds of service impact, provider effect, or finding that require escalation, in terms that operational teams can apply under pressure.

During an incident, escalation needs a pre-agreed rhythm and a named incident leadership structure, as discussed in the roles guide. Early escalation should be encouraged, even when the full picture is unclear, because the management body can better support recovery when it learns early than when it learns late. An early, incomplete report is more useful for governance than a late, polished report that arrives after key decisions have already been forced.

Escalation during an incident should also carry decision requests, not only information. The management body may need to decide recovery priorities, customer communication, provider engagement, or acceptance of a temporary workaround. Framing escalation as a decision request, with options and consequences, helps the board act rather than merely observe. After the incident, the escalation record becomes part of accountability evidence, showing when the board learned of the incident, what it decided, and how those decisions shaped recovery.

Culture affects escalation more than any written route. Staff escalate early when they believe that raising a problem will lead to support and a decision. They delay escalation when they fear blame, when previous escalations were ignored, or when they believe that senior managers prefer reassurance to difficulty. The management body's reaction to unwelcome escalations therefore shapes every future escalation, whether it intends to or not.

Reporting lines and escalation routes can be tested through exercises and through review of real events. A tabletop exercise that simulates a provider failure or a service outage can reveal whether escalation routes are known, whether deputies are available, and whether the board receives information in a usable form. Such exercises test governance as well as operations, and their findings should be treated as governance findings, with owners and follow-up.

Real incidents provide the strongest test. An incident review should examine the escalation timeline: when was the issue recognised, when was it escalated, who received it, and what decision followed? Delays, missed routes, or information that stopped at an intermediate layer should be recorded as governance lessons, not merely as operational observations. Over time, that review discipline improves both the written routes and the culture around them, so that the next escalation is faster, clearer, and more likely to lead to a timely decision.