Continuity Governance and Ownership

Continuity governance answers a simple question with serious consequences: who owns this plan, who can challenge it, and who decides when it is activated. The service owner owns the service plan, even where technical teams, suppliers or a central resilience function do much of the work. That ownership includes keeping the plan current, arranging testing, acting on findings, and explaining the plan in plain language to reviewers. Under DORA in the EU, which applies from 17 January 2025, and under the separate UK regime in FCA PS21/3 and PRA PS6/21, governance expectations should be labelled by regime, because accountability language differs and should not be blurred in firm documents.

Ownership fails when it is shared so widely that nobody feels responsible. A plan owned by a committee, a programme or a function, without a named individual accountable for a named service, tends to age quietly. The named owner should be senior enough to secure resources, to challenge suppliers, and to make difficult trade-offs about recovery priorities. Deputies should also be named, with the authority and access to act when the owner is unavailable. That deputisation should be tested, because a deputy who has never exercised the role, or who lacks the permissions to do so, leaves the firm with ownership on paper and a gap in practice.

Challenge is the second governance element. A plan written by the team that will execute it benefits from independent review by people who were not involved in its creation. Reviewers should ask awkward questions: does the recovery sequence match the customer journey, are contacts current, has the workaround been practised, does the supplier arrangement actually support the tolerance, and what happens if the assumed data copy is unavailable. That challenge should be recorded, including disagreements and how they were resolved. A governance process that only approves plans, without ever questioning them, gives the appearance of control while leaving weaknesses unexamined until disruption exposes them.

Consider an illustrative lending service, where continuity depends on credit systems, payment partners and customer contact teams. Its owner needs authority across those areas, or at least a clear route to escalate when a dependency owner disagrees about priorities. Governance should define that escalation route before disruption, including who convenes a decision group, who records decisions, and how conflicts between service recovery and other pressures, such as commercial deadlines or change programmes, are resolved. During disruption, that clarity prevents parallel decision making, where different teams pursue different recovery sequences and customers receive inconsistent messages about what is happening.

Governance also covers resources and maintenance. Continuity work competes with other priorities, and without explicit ownership, testing and plan updates are easily deferred. A governance forum should review, for each important service, whether its plan is current, whether its last test produced actions, whether those actions are closed, and whether any change to the service or its suppliers requires a plan update. That review should focus on evidence and overdue actions, not on the volume of documents produced. A forum that reviews plan versions without asking about test findings and supplier changes is reviewing paperwork, not resilience.

After disruption, governance determines whether learning sticks. The service owner should own the post-incident review for their service, including changes to the plan, the dependency map, tolerance reasoning and supplier arrangements. Findings should have owners and follow-up dates, and the governance forum should check closure rather than accepting a review report as the end of the work. Over time, that discipline creates a record that shows how continuity capability has developed, where it remains weak, and where investment is needed. That record is also what allows a firm to explain, credibly, how it governs continuity for each important service, rather than describing a general framework that may or may not reach the service itself.