Accountability When a Service Fails
Accountability when a service fails is tested by the governance record made before the failure. This guide explains how decisions, challenge and follow-up show whether oversight was real.
The short answer
When a service fails, accountability means being able to show what the management body knew, decided and followed up, before the failure, during recovery, and afterwards. It does not mean that the board prevented every failure, because no governance arrangement can promise that. It means that oversight was real: a framework was approved, risks were discussed, testing and incident information were reviewed, and findings were tracked until they were addressed.
The failure itself becomes a test of earlier governance. If the record shows decisions, recorded challenge and completed actions, the entity can demonstrate oversight even in unwelcome circumstances. If the record shows only that resilience was discussed, with no decision attached, accountability evaporates at exactly the moment it is most needed. That evaporation is the pitfall this cluster warns against, and this guide explains how to avoid it.
What should the record show before a failure?
Before a failure, the record should show that the management body approved the framework, reviewed risk and testing information, and acted on findings. That includes decisions about priorities, about provider risks, and about accepting or mitigating known weaknesses. A record of that kind does not need to be long. It needs to be specific: which service, which risk, which decision, which owner, and what follow-up was required.
How is accountability exercised during an incident?
During an incident, accountability is exercised through clear incident roles and recorded decisions. Recovery priorities should be decided by the role that holds that authority, provider engagement should be coordinated, and customer communication should be owned. Decisions taken under pressure still need a record, even if that record is created shortly afterwards from contemporaneous notes. Memory alone is a fragile basis for later review.
Incident accountability also involves restraint. The management body should support the incident team without pulling it into repeated reporting that slows recovery. Governance during an incident therefore balances two needs: the need for timely information, and the need to let recovery proceed. A pre-agreed incident reporting rhythm helps, because it gives the board information at planned points without requiring the response team to improvise a reporting structure while also restoring a service.
What happens after recovery?
After recovery, accountability requires a review that is honest about what worked, what did not, and what will change. The review should examine the timeline, the decisions taken, the recovery sequence, provider performance, and customer impact. It should also examine governance itself: whether earlier decisions and follow-up were adequate, and whether any warning signs were missed or left unactioned.
Lessons from the review should become owned actions, with the same discipline as test findings. A lesson that is noted in a review report but never assigned, tracked or evidenced has not been learned in governance terms. It has been written down. The difference becomes visible at the next incident, when the same weakness reappears. Accountability after a failure is therefore measured less by the quality of the review document than by the changes that follow from it.
How do individual and collective accountability relate?
Under DORA, the management body is collectively responsible, while individuals carry specific roles within that collective responsibility. Both levels matter. Collective responsibility prevents accountability from being pushed onto a single scapegoat, while individual role ownership prevents it from dissolving into a general sense that the organisation failed. A review should therefore be able to say what the body decided together, and what individual role holders did within their remits.
That balance requires care in language. Reviews that blame individuals without examining the framework, the information available, or the resourcing decisions behind their work produce defensiveness rather than learning. Reviews that blame only the system, without examining decisions and follow-up, produce no accountability at all. A balanced review examines decisions at each level, asks what information was available at the time, and identifies changes at the level where they will prevent recurrence.
How can an entity show accountability to supervisors and customers?
An entity shows accountability through its records and its actions, not through its statements. Supervisors and other reviewers look for a coherent trail: framework approval, risk and test reporting, recorded challenge, decisions, action tracking, incident records and remediation evidence. Consistency across that trail matters. A framework that promises regular review, combined with a record that shows no review for a long period, undermines confidence more than an honest admission of a gap would.
Customers experience accountability differently, through communication and recovery. Clear, timely information during a disruption, honest acknowledgement of impact, and visible remediation afterwards all contribute to trust, even when the disruption itself was serious. Governance cannot control every aspect of customer experience during a failure, but it can ensure that communication is owned, that recovery priorities reflect customer needs, and that lessons lead to change. Those are governance choices, and they are visible to customers whether or not the boardroom record ever is.
Primary sources on the record
- Regulation (EU) 2022/2554, EUR-Lex text.
- European Banking Authority, operational resilience pages.
- European Securities and Markets Authority, ESMA home page.
Legal status: Regulation (EU) 2022/2554 in force; applies from 17 January 2025, with technical standards applying on the dates stated in each standard. Application position for this topic: Applies from 17 January 2025. Technical standards apply on their own stated dates.