Resilience Roles and Accountability

Resilience work needs named roles because shared responsibility, without definition, becomes no one's responsibility. Under DORA the management body remains ultimately accountable, while executives, risk functions, technology teams and assurance functions carry distinct parts of the work. A clear role map shows who proposes a framework, who approves it, who operates controls, who tests them, and who independently checks whether they work.

The value of that map appears during disruption and afterwards. When a service stops, people need to know who decides recovery priorities, who talks to providers, and who owns the follow-up. When an incident is reviewed, the same map lets the entity trace decisions to individuals and roles instead of to a general sense that the organisation should have done better. Roles do not create blame for its own sake. They create a route from a problem to a person who can fix it.

Senior management typically carries day to day implementation: operating the framework, managing technology and providers, handling incidents and reporting upward. The risk function challenges that work, checking whether risk assessments are realistic and whether controls match the risks identified. Technology teams build, maintain and recover systems, while business owners own the services those systems support and understand what disruption means for customers.

Assurance functions, including internal audit where present, provide independent checking. Their independence matters because the people who operate a control are poorly placed to judge its effectiveness alone. A role map that places operation, challenge and assurance in the same hands weakens all three. Separation does not require a large organisation, as discussed in the small firms guide, but it does require that the same person is not simultaneously marking their own work in every case.

Service ownership connects technology work to customer consequences. A service owner understands who uses a service, what happens if it stops, and which dependencies matter most. That understanding shapes risk assessment, testing priorities and recovery sequencing. Without a service owner, resilience work tends to organise itself around systems, and the customer view is reconstructed only after a failure, when it is too late to shape preparation.

Take a retail banking example. A current account service involves channels, authentication, transaction processing and statement generation. Different teams may own each component, but the service owner owns the whole customer journey. During an incident, that owner can say which customer needs matter first, while component owners focus on restoring their parts. After the incident, the service owner can also judge whether recovery met customer needs, not merely whether systems returned. That judgement is a governance judgement, not a technical one.

Overlaps appear where two teams both believe they own a task, such as incident communication or provider oversight, and each assumes the other is acting. Gaps appear where a task belongs to no team, such as tracking remediation after testing, maintaining a dependency map, or reviewing provider exit arrangements. Both problems are common at boundaries: between business and technology, between the entity and a group function, and between the entity and its providers.

A role review should therefore focus on boundaries rather than only on job titles. For each boundary, the question is simple: who decides, who acts, and who checks? If any answer is vague, the boundary needs work. Role descriptions that list responsibilities in general terms without naming decision rights leave those questions unanswered. Decision rights are the practical content of accountability, and they should be written down where they can be found during an incident, not reconstructed from memory.

During an incident, normal reporting lines may be too slow, and roles need a clear incident form. That form should name who declares an incident, who leads recovery, who coordinates providers, who decides on customer communication, and who records decisions for later review. Those incident roles may differ from everyday roles, and that difference should be planned rather than improvised.

Roles decay as organisations change. People leave, teams reorganise, services are added, and providers change. A role map that is not reviewed becomes a picture of a former organisation. Review should therefore follow organisational change, not a fixed calendar alone, although regular review also helps catch gradual drift that no single change announces.

Review should also test roles against evidence. If testing repeatedly finds that no one owned a remediation, the role map has a gap, however complete it looks on paper. If incident reviews repeatedly show confusion about who decided a recovery priority, the incident roles need clarification. Roles are not an administrative exercise. They are a hypothesis about how the entity will act under stress, and incidents and tests are the evidence that either confirms or refutes that hypothesis.