Who should be accountable for building cyber resilience when regulation, funding, and third-party risk all intersect?

Accountability should sit with the teams that own the risk, not only with security. Government leaders, infrastructure owners, and control owners must coordinate on resilience, reporting, and supplier oversight. The article makes clear that regulation alone is not enough. Funding, implementation, and third-party security all need clear ownership if resilience is to improve.

Who owns cyber resilience when the risk sits across regulation, funding, and suppliers?

Accountability should follow the risk owner, because resilience breaks down when it is treated as a security-only concern. The right owner is usually the business, infrastructure, or control team that can change funding, supplier choices, operating priorities, and recovery expectations. Security should advise and challenge, but it cannot carry the entire burden alone.

That ownership model matters because regulation creates obligations, third-party dependencies create exposure, and funding determines whether resilience is real or only documented. If the team that controls the system or service does not also own the resilience outcome, gaps appear quickly between policy, implementation, and oversight.

How accountability should be distributed across leaders, operators, and suppliers

In practice, resilience needs a shared operating model with one clear accountable owner and several supporting functions. Government or executive leadership sets the mandate, allocates budget, and accepts the residual risk. Infrastructure owners and product or service control owners translate that mandate into architecture, controls, testing, and recovery capability. Security, procurement, and risk teams provide challenge, evidence, and assurance.

The key distinction is between accountability and contribution. A supplier may deliver a control, and security may verify it, but the internal owner must still answer for the outcome. That is especially important where resilience depends on contract terms, service levels, incident notification, recovery testing, and access controls in the supply chain.

Third-party risk is often where accountability becomes ambiguous. If a supplier hosts data, runs a critical platform, or holds privileged access, resilience depends on what the organisation has specified, funded, measured, and enforced. Internal owners need to know which suppliers support critical operations, what failure would look like, and which recovery dependencies are actually under contract.

Why this structure fails when ownership is vague

When no one owns the full resilience outcome, each group optimises for its own slice of the problem. Compliance teams may focus on evidence, finance may focus on cost, operations may focus on uptime, and security may focus on control design. The result is a system that can look compliant while still being fragile under stress.

Funding is a common failure point because resilience work competes with visible delivery work until an incident occurs. If budget is not attached to the system owner, important controls such as backup testing, supplier assurance, segmentation, and recovery exercises tend to be deferred. That creates a control gap between regulatory expectation and operational reality.

Third-party exposure increases the stakes because failures can cascade across multiple services at once. In a supplier-driven incident, the organisation may still be accountable to customers, regulators, and partners even when the root cause sits outside its direct control. That is why accountability has to include oversight of dependencies, not just internal technical control.

Risk and Threat Considerations

When accountability is split across regulation, funding, and supplier oversight, the main risk is that no single owner treats resilience as a live operating obligation. The organisation may have policies, attestations, and contracts, but still lack tested recovery paths, clear escalation, or supplier performance evidence.

Failure mechanism: ownership gaps allow critical assumptions to go unchallenged, especially where a third party, shared platform, or outsourced control is expected to absorb failure without explicit testing or funding.

Impact: incidents become harder to contain, recovery takes longer, reporting can be incomplete, and regulators or customers may hold the organisation responsible even when the immediate failure originated with a supplier.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	Aligns ownership of resilience to the risk the organisation is choosing to manage.
	GV.SC-02 — Cyber Supply Chain Risk Management	Directly addresses third-party risk, supplier oversight, and dependency management.
	GV.PO-01 — Policies, Processes, and Procedures	Supports clear accountability by defining who owns resilience policy execution.
Recommendation — Assign a named risk owner for each critical service and tie resilience actions to that owner's decisions. Require supplier oversight, recovery evidence, and contractual controls for critical dependencies. Document ownership for resilience activities so policy, funding, and execution remain linked.
CIS Controls v8	CIS 15 — Service Provider Management	Covers third-party governance where supplier failure can create direct resilience exposure.
	CIS 17 — Incident Response Management	Resilience accountability must include reporting, escalation, and coordinated response.
Recommendation — Maintain oversight of service providers that support critical operations and recovery. Define who must report, coordinate, and escalate when supplier or system resilience fails.
DORA	Article 5 — Governance and Organisation	Makes management body accountability central to ICT risk and resilience governance.
	Article 28 — ICT Third-Party Risk	Directly addresses supplier oversight where third-party risk intersects with resilience.
	Article 11 — ICT Risk Management	Requires resilience controls to be governed as part of ICT risk management, not isolated security work.
Recommendation — Make leadership accountable for ICT resilience decisions, funding, and oversight. Set explicit third-party oversight, testing, and exit expectations for critical suppliers. Integrate resilience controls into ICT risk management and keep accountability with the service owner.

Practitioner Guidance

What to prioritise: Assign one accountable owner for each critical service or risk domain, then map every major resilience dependency to a named control owner and supplier owner. If a control has no funded owner, treat it as incomplete.

What to verify: Check that the owner can evidence funding, supplier oversight, recovery testing, and reporting responsibilities, not just policy approval. A resilience programme is credible only when the owner can show how those duties are executed in practice.

Decision rule: If a third party can affect availability, integrity, or reporting, the internal business or service owner must remain accountable for resilience, with security and procurement acting as control partners rather than substitutes.

Practitioner takeaway: Resilience improves when accountability sits closest to the risk, because only the risk owner can align budget, supplier leverage, and operational priorities with the failure modes that matter most.