Mapping Third-Party Dependencies

Mapping third-party dependencies records every outside supplier a service relies on, what that supplier provides, and what happens to the service if the supplier fails, degrades, or changes its service. A firm may own the service and its customer relationship, but it rarely owns every component underneath it. Cloud hosting, payment processing, identity checks, messaging, and specialist data are commonly supplied from outside. The map should name each supplier in the chain of the service, describe its role in plain language, and note the recovery route if it becomes unavailable. A supplier listed only in a procurement file is not mapped; a supplier linked to the service it supports is.

Include any supplier whose failure would stop, degrade, or materially slow the service, and any supplier whose service is needed for recovery itself, such as a backup provider or a communications platform. Exclude suppliers that merely support the wider business without touching the service, because a map cluttered with irrelevant vendors hides the critical ones. For each included supplier, record the service it provides, the part of the firm's service that depends on it, and the contract or arrangement that governs it. That link between supplier and service is the point. A procurement register answers who the firm pays. A service map answers what breaks when a supplier fails.

Beyond the name, the map needs operational facts: how the supplier is contacted during an incident, who in the firm owns the relationship, what service levels or exit arrangements exist in broad terms, and whether an alternative exists. It should also note concentration. If several services, or several steps within one service, depend on the same supplier, that concentration should be visible, because a single supplier incident then becomes a multi-service incident. The map should not reproduce contract detail, but it should point to where that detail lives, so responders can find it without searching through unrelated files during a disruption.

A supplier failure changes recovery in two ways. First, the firm cannot simply restart its own systems and expect the service to return; it must wait for, work around, or replace the supplier's contribution. Second, the firm may have limited visibility into the supplier's own incident, its cause, and its expected recovery. The map should therefore record the workaround for each critical supplier dependency, the point at which the workaround is authorised, and the criteria for returning to normal. It should also record how customer impact is assessed when the supplier's information is incomplete, because waiting for perfect information before acting can prolong harm to customers.

Some of the most important suppliers are invisible to customers and sometimes to the service team itself. A supplier may provide a component inside another supplier's platform, a data feed inside a processing chain, or a network service underneath a cloud platform. Those are fourth-party dependencies, covered in a companion guide, but the third-party map should still flag where a direct supplier depends heavily on another provider, so the chain is not mistaken for a single link. Visibility does not require the firm to control the deeper supplier, but it does require the firm to know the chain exists and to ask its direct supplier how that deeper dependency is managed and recovered.

Test by removing a supplier in rehearsal and following the map. Can responders name the affected customers, the workaround, and the owner who will contact the supplier? Does the contact route work, and does the supplier's incident communication reach the right team? If the rehearsal reveals that the supplier was replaced months ago, that the contact is out of date, or that no workaround exists, the map has done its job by exposing the gap. Under DORA in the EU, third-party ICT risk has its own register and oversight expectations, and under FCA and PRA policy in the UK, outsourcing and third-party risk are addressed separately; these guides label each regime where it is used, rather than merging them.