Managing Dependency: Building Resilient Third-Party Risk Frameworks in an Interconnected World [T9]

What are best practices for clearly defining and enforcing ownership and accountability across third-party risk management processes, particularly in complex, multi-stakeholder environments?

The first principle for me is very simple: the business that chooses to depend on the third party ultimately owns the risk.

A third-party risk function can provide governance, oversight and challenge but it should not become the owner of every supplier risk. The business owner needs to remain accountable for the relationship and, critically, understand what that dependency means for the service they are responsible for.

In complex organisations, cyber, technology, procurement, legal, operational risk, compliance and resilience will all have responsibilities. The danger is that everyone owns one part of the process but nobody owns the outcome.

That is why good practice comes down to clear accountability, defined decision rights and effective escalation. There should be no ambiguity about who can accept the risk, who owns remediation and who has the authority to act when a supplier moves outside the organisation's risk appetite or can no longer deliver a critical service.

And accountability needs to work under pressure, not just look good on a governance chart.

The real test is simple: when the supplier fails, do we know who makes the decision?

How can organisations effectively integrate technology, cyber, and operational risk assessments into a single, cohesive third-party risk framework without creating duplication or silos?

I think one of the biggest mistakes is starting with the individual risk disciplines rather than with what the organisation is trying to protect.

Cyber will naturally look at security controls. Technology risk will look at systems and architecture. Operational risk will consider process failure. Resilience teams will look at continuity and recovery. Those perspectives are all important but ultimately the organisation needs to understand what they collectively mean for its ability to continue delivering its critical services.

I would build a common view of the dependency:

Business service → third party → technology → data → people → locations → fourth parties → recovery