A leadership team can have a current supplier register and still struggle to explain how a critical business service would recover from disruption. Procurement understands the contracts. Technology understands the platforms. Operations understands what customers need. The gaps appear where those views should connect.

That matters commercially. A supplier outage can interrupt orders, delay payments or leave colleagues unable to serve customers. A cyber incident can create the additional problem of deciding which connections and information can still be trusted. Restoring a platform is only one part of restoring the business.

Third party risk needs a view of the service from beginning to end, with clear decisions about ownership, recovery and the evidence required to trust the arrangements. The practical starting point is a service the organisation cannot afford to lose.

Define what must continue, then map what makes it possible

Choose a service in business language: accepting and fulfilling customer orders, for example. Agree who uses it, what outcome it provides and how disruption would affect customers, colleagues and cash. Define the minimum acceptable operation and when the consequences become unacceptable. Those decisions should involve the business owner alongside technology and security.

Then trace the people, applications, data and external services needed to deliver it. An order journey might depend on an online storefront, identity provider, payment processor, stock information, warehouse systems and a logistics partner. This is an illustrative example, not a client incident. Its value is in exposing the connections that a supplier-by-supplier review can miss.

The NCSC’s supply chain mapping guidance provides a useful foundation for understanding suppliers, information flows and relevant subcontracting relationships. Apply that understanding to the service being examined, keeping the information secure and proportionate to the risk.

Look for dependencies shared by apparently separate suppliers. Two alternative routes may still rely on the same underlying provider. Record uncertainty explicitly rather than drawing a reassuring connection that has never been checked. The map should support a decision about continuity and investment; detail that does neither can wait.

Make ownership clear at the handovers

A supplier can operate a platform while the organisation retains responsibility for the customer outcome. That distinction needs to become practical before an incident. Name the business service owner, the technical recovery leads and the people authorised to make decisions across organisational boundaries.

Consider the decision to disconnect a supplier suspected of compromise. Security may recommend isolation. Operations needs to understand which customer activities will stop. Finance may need to authorise emergency expenditure. Someone must decide whether a limited manual service is acceptable, and someone must communicate the consequences. A contact list alone does not settle those choices.

Document who can declare an incident, request supplier support, approve a workaround and accept restoration. Agree deputies and an alternative communication route if normal email or identity services are unavailable. Check whether supplier escalation arrangements cover the times the business actually operates.

Commercial agreements should support these arrangements, including relevant notification, cooperation and access requirements. They also need operational owners who understand how to use them. A contractual response target and the time needed to restore customer service are different measures. Leadership needs to understand the gap, decide whether it is acceptable and fund changes where it is not. Outsourcing creates a relationship to manage throughout the service lifecycle.

Ask for assurance that answers the service’s real questions

Supplier assurance should help the organisation judge whether the dependency is acceptable. A completed questionnaire or certificate may contribute evidence, but the useful question is what that evidence covers and how it relates to the service being relied upon.

For a critical hosted application, ask what was tested, when it was tested and what the results showed. Understand the restoration assumptions, customer responsibilities and remaining exceptions. Check whether evidence covers the contracted service and the relevant operating environment. A broad statement about the supplier’s organisation may leave important questions unanswered.

The NCSC’s approach to assessing supply chain cyber security supports a proportionate process that develops and improves over time. In practical leadership terms, the depth of review should reflect the dependency, access and potential business impact.

For the illustrative order service, the payment provider and a low-impact advisory supplier need different attention. Prioritise the questions that could change a decision: whether recovery meets the business requirement, whether essential data can be recovered, and whether access can be controlled during disruption. Keep unresolved assumptions visible with an owner and a review date. The output should be a reasoned decision about risk, supported by evidence and a practical improvement plan.

Exercise the customer service across the whole chain

A supplier’s successful recovery test does not establish that the organisation can resume its own operation. Internal integrations, access, data reconciliation and business decisions may still prevent the service from working. An exercise should follow the customer outcome far enough to reveal those dependencies.

Start with a realistic scenario and clear objectives. For example, assume the external platform is unavailable and the supplier cannot yet confirm a recovery time. Ask the participants to work through the decisions they would make with the information available. Include business operations, technology, security and communications, with important suppliers involved where appropriate. The NCSC recommends including key partners in incident response exercises.

Test the proposed workaround against real constraints. Can colleagues obtain the information they need without the affected platform? Is the information current enough? Who checks accuracy and prevents duplicate processing when systems return? A manual process that depends on an unavailable login offers little continuity.

A discussion exercise tests coordination and judgement; technical recovery testing provides different evidence. Use both where justified, in controlled conditions. Record what was demonstrated, what was assumed and what failed. Give each material finding an accountable owner, a practical action and a retest date. An exercise earns its value when the organisation changes something and checks that the change works.

Use the evidence to make investment and growth decisions

Dependency knowledge becomes useful when it changes leadership decisions. A critical service may need better recovery arrangements, clearer supplier cooperation or investment in internal capability. In some cases the right decision is to accept a limitation knowingly, with defined conditions and an owner. The important point is that the trade-off is understood.

Report at service level. Show the business impact at risk, the recovery capability actually demonstrated, the important assumptions still untested and the improvements requiring a decision. Avoid implying certainty through a single green supplier rating when the underlying service has unresolved gaps.

Keep the picture current as the business changes. A new integration, acquisition or outsourced activity can alter a dependency without looking like a major security project. Build a review into those changes and revisit the service map when responsibilities or operating requirements move.

This connects cyber resilience with commercial planning. Growth adds customers, transactions and expectations; recovery arrangements need to be considered alongside that ambition. Relentica’s Cyber Security, Risk & Resilience capability connects strategy, governance and practical delivery, including business continuity and leadership exercises.

Start with one critical service. Bring its business owner, technology lead and relevant partners together, map the dependencies, then test the most consequential assumption. That creates a concrete basis for deciding what needs to improve and who will deliver i