Who should own DORA resilience planning when security, operations, and vendor management all overlap?

Ownership should sit with leadership, but execution has to be shared across security, operations, risk, and vendor management. DORA explicitly puts operational resilience on the board agenda, so boards must set risk limits and ensure resources are in place. Day-to-day controls, testing, and third-party coordination then need clear operational owners so accountability does not disappear in the handoffs.

Why DORA resilience ownership has to be explicit

When security, operations, and vendor management overlap, the first failure is usually not technical, it is organisational. DORA resilience planning only works when one accountable owner can set priorities, resolve conflicts, and keep the risk picture coherent. Without that, each function optimises its own tasks while no one owns the combined operational outcome.

That does not mean one team must do everything. It means the accountable owner must define the resilience objective, decide what level of disruption is acceptable, and make sure the supporting teams understand their part in testing, remediation, and third-party coordination. DORA places operational resilience on the board agenda, so the ownership model has to be visible above the working group level.

Practical ownership also needs to reflect where the control actually lives. Security may own threat and control design, operations may own service continuity and recovery, and vendor management may own third-party oversight, but those are supporting responsibilities. The resilience plan itself needs a single decision-maker who can reconcile those inputs when trade-offs appear.

How to split responsibilities without losing accountability

The cleanest model is a single accountable owner with shared execution responsibilities. In practice, that usually means leadership owns the risk decision, while security, operations, risk, and vendor management each own the controls and evidence in their lane. The plan should name who approves scope, who runs tests, who remediates findings, and who follows up with suppliers.

That division matters because resilience work fails when the handoff points are vague. A control can be technically sound but still ineffective if no one owns the escalation path, test schedule, or third-party remediation deadline. The ownership model should be documented alongside the service map, dependencies, and recovery assumptions so that planning is tied to real operational boundaries.

For third-party dependence, the vendor manager should not be the final risk owner just because the relationship is external. Vendor management can coordinate evidence, contract clauses, and follow-up, but the business or service owner must still accept the resilience impact of that dependency. That distinction becomes especially important when a supplier outage would affect customer-facing services or regulated processes.

Where a joint model is already in place, the key question is whether it produces decisions or only meetings. If the committee can approve exceptions, force remediation, and escalate unresolved exposure, the model is working. If it only records status updates, ownership has not been solved, it has been distributed.

Risk and Threat Considerations

Overlapping responsibility creates a familiar control failure: each function assumes another team is closing the gap. In resilience planning, that can leave testing incomplete, vendor dependencies under-assessed, or recovery assumptions unowned until an outage exposes them.

Failure mechanism: Ambiguous ownership weakens escalation, slows remediation, and allows gaps to persist across service continuity, control testing, and supplier oversight. When a disruptive event or third-party failure occurs, no single function has enough authority to force a coordinated response.

Impact: The organisation can misjudge its true resilience, approve weak controls, or fail to meet DORA expectations for governance and operational oversight. The result is often delayed recovery, inconsistent evidence, and greater regulatory exposure when planning assumptions do not match actual operating responsibility.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

CIS Controls v8 and NIST CSF 2.0 set the technical controls, while DORA define the regulatory obligations.

Framework	Control / Reference	Relevance
DORA	GOVERN — Governance	DORA places resilience governance and oversight on leadership.
	ICT-THIRD-PARTY — ICT Third-Party Risk Management	Vendor coordination and supplier dependence are central to the question.
	RESILIENCE-TESTING — Digital Operational Resilience Testing	The question includes day-to-day testing ownership across functions.
Recommendation — Assign board-visible accountability for resilience risk and resource decisions. Define clear owners for third-party oversight, testing, and escalation. Set one control owner for test planning, evidence, and remediation follow-up.
CIS Controls v8	6 — Access Control Management	Clear responsibility is needed to manage permissions and operational access safely.
Recommendation — Document ownership for access decisions and review exceptions promptly.
NIST CSF 2.0	GV.OC — Organizational Context	Ownership should align to business services, dependencies, and accountability.
	RS.RP — Response Planning	Resilience planning requires pre-assigned response roles and coordination paths.
Recommendation — Map resilience responsibilities to the services and outcomes they protect. Assign response roles and decision rights before a disruption occurs.

Practitioner Guidance

What to verify: The ownership model should identify one accountable executive or committee for the resilience plan, with named control owners for testing, recovery, and supplier follow-up. If any critical dependency lacks a named decision-maker, treat that as a planning defect rather than a documentation issue.

What good looks like: Every material service has a single resilience owner, a current dependency map, and a dated testing cadence with clear remediation ownership. Vendor issues, recovery gaps, and control exceptions should all have one path to escalation, not separate tracks that may never converge.

Practitioner takeaway: Shared execution is healthy, but shared accountability is not, the resilience plan only works when one owner can reconcile security, operations, and vendor trade-offs into a single decision.