• Business owners must retain accountability for third-party risks and supplier relationships.
• Integrated risk frameworks should focus on critical business services rather than individual risk disciplines.
• Effective due diligence requires visibility of fourth parties and underlying dependencies.
• Continuous monitoring, testing and early exit planning are essential for lifecycle management.
• Organisations should assess dependency concentration, not just supplier concentration.
• True resilience is demonstrated by the ability to operate when critical suppliers fail.

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

That is where integration becomes valuable.

Integration does not mean forcing every function into one enormous assessment. It means bringing those different perspectives together to create one view of the dependency, one view of the potential business impact and clarity over the decisions that may need to be made.

A very simple question often cuts through a huge amount of complexity:

If this third party became unavailable tomorrow, what would stop, what would the impact be and how long could we tolerate it?

That moves the conversation away from individual risk scores and towards resilience.

What does robust, end-to-end due diligence look like in today’s environment, and how can firms address common gaps when dealing with layered or indirect supplier relationships?

For critical suppliers, due diligence has to go beyond whether the right policies and controls exist.

We need to understand financial viability, cyber posture, operational resilience, recovery capability, geographic exposure, technology dependencies and reliance on subcontractors. But increasingly, the biggest risks sit beneath the supplier we can see.

I often think of this as the dependency behind the dependency.

You may contract with one supplier but that supplier could depend on a cloud provider, data centre, software platform or specialist fourth party that also supports multiple other suppliers across your organisation.

That creates interconnected risk which may not be visible when relationships are assessed individually.

So due diligence should answer two questions:

·      Can this supplier meet our requirements?

·      And what does this supplier depend on to keep meeting them? 

For the most critical relationships, I also believe we need to move beyond assurance towards validation.

A supplier telling me they have a recovery plan gives me assurance. Demonstrating that they can recover within the timeframe my critical service requires gives me evidence.

Where proportionate, test it. Exercise it. Challenge the assumptions. Understand whether recovery works against the scenarios that actually matter to your organisation.

A plan tells you what should happen. A test tells you what actually might.

What are the key elements of best-in-class lifecycle management for third-party risk—from onboarding and contracting through to continuous monitoring and exit strategies?

The risk profile you assess when you sign a contract is not necessarily the risk profile you will have two or three years later.

Suppliers change. Technology changes. Subcontractors change. Financial conditions change. Geopolitical exposure changes. And, importantly, your own dependency on that supplier can quietly increase over time.

I think about the lifecycle as:

Understand → Assess → Contract → Monitor → Test → Respond → Exit

At onboarding, understand criticality and dependency. Contractual requirements should then reflect that criticality, particularly around security, resilience, incident notification, recovery, audit rights, data and subcontracting.

Monitoring should be continuous and proportionate to risk. But for critical suppliers, monitoring alone is not enough. We also need to understand what happens when the control environment fails.

What happens if the supplier is unavailable for 24 hours? Three days? Several weeks?

Can we operate manually? What happens to customers and critical services? Do we have a genuine alternative? How quickly could we transition? And who has the authority to make that decision?

That is where third-party risk becomes operational resilience rather than supplier administration.

And exit planning needs to begin much earlier than many organisations think.

A contract can end relatively quickly. A dependency often cannot.

What proven approaches can organisations adopt to identify, measure, and mitigate concentration risk and supply chain vulnerabilities across increasingly interconnected third-party ecosystems?

This is one of the areas I think organisations need to challenge themselves most.

You can look diversified on paper and still be highly concentrated underneath.

You might have ten different suppliers but if eight ultimately rely on the same cloud platform, data centre, telecommunications provider, specialist technology or geographic region, you do not necessarily have the resilience you think you have.

That is why I would distinguish between supplier concentration and dependency concentration.

Supplier concentration tells you how much business you have with individual providers. Dependency concentration tells you where multiple critical services ultimately rely on the same underlying capability.

I would therefore map concentration across suppliers, fourth parties, cloud platforms, technology, geographic locations, infrastructure, specialist skills and, most importantly, critical business services.

Once those concentrations become visible, scenario testing becomes extremely powerful: What happens if this provider, technology or region becomes unavailable and several critical services are affected at the same time?

That is a very different resilience challenge from losing one supplier in isolation.

Not every concentration can or should be removed. Commercially, that would be unrealistic. The objective is to make concentration visible and intentional rather than hidden and accidental.

Once leadership understands the dependency and its potential impact, it can make a conscious decision: diversify, strengthen contingency, improve recovery capability, redesign the service or knowingly accept the exposure.

Ultimately, I don't see third-party risk as simply managing suppliers.

It is about managing dependency.

Knowing what we rely on, what sits underneath it, who is accountable for it and whether we can continue operating when that dependency fails.

Because ultimately, resilience is not demonstrated by how well we understand a supplier when everything is working.

It is demonstrated by what the organisation can still do when that supplier is not.