Map fourth-party dependencies without an endless supplier list

A supplier sends a list of 80 subcontractors. Some host production systems. Others provide office catering or marketing support. The list is long, but it still does not explain what would happen to your payment service if a particular dependency failed.

Fourth-party mapping becomes useful when it follows the service you rely on. Start with the operation, trace the important dependencies and record the limits of your knowledge. Collecting every name in a provider's purchasing system is a different task.

CPS 230 includes fourth-party risk in service-provider management. The method below is an original working approach for a lean risk and technology team. It does not make every supplier-of-a-supplier individually material or promise exhaustive discovery.

Follow one service, not the whole corporate group

Consider a fictional bank, Banksia Mutual, that uses a managed service provider to operate a payment-processing application. The bank's review starts with that service, its agreed scope and the outcome it supports.

The direct provider uses an infrastructure host, a database support specialist and an identity service. Its corporate website also mentions a design agency and travel company. Those relationships may matter to the provider, but they do not all belong on the same critical-service dependency map.

The first question is functional: what does each downstream party do for this particular service? The second is consequential: what would stop, degrade or become inaccessible if that party failed or changed its service?

A dependency may be indirect but still important. An identity service might not process payments, yet staff may need it to operate recovery tools. Looking only for organisations that touch transaction data could miss that link.

Draw a small map with meaningful labels

For each connection, capture the service function, the direct provider's reliance, known location or configuration where relevant, and the evidence supporting the connection. Include an owner and a checked date.

Banksia's first map contains three branches:

• The infrastructure host runs the application environment. The provider supplies a current architecture extract, but recovery-region details remain unclear.
• The database specialist supports complex repairs. The provider says its own team can perform routine recovery, but has not demonstrated a specialist-free recovery.
• The identity service controls administrator access. The provider describes an emergency access process, but the last test did not include an identity-service outage.

These are fictional findings. Their value is in the distinction between a known dependency and an untested assumption about how it can be managed.

Use plain labels such as confirmed, reported but not verified, and unknown. Avoid colouring a dependency green simply because a document exists. A diagram can look reassuring while carrying little evidence.

Ask questions tied to failure modes

A generic request for “all fourth parties and their certifications” often produces a generic answer. Narrow questions make it easier for the supplier to respond and for your team to judge the answer.

For the infrastructure host, ask which services the application needs during normal operation and recovery. Does the recovery environment depend on the same account, management tools or network path? Request evidence at a level that supports the decision without unnecessarily exposing sensitive architecture.

For the database specialist, ask which tasks require its people, what happens if they are unavailable and whether the proposed alternative has been exercised. A contractual response commitment says little about whether another team can perform the work.

For the identity service, ask how authorised staff access essential tools during its outage. Request the result of a relevant test or a bounded demonstration. A process titled “emergency access” does not establish that it works for the system in question.

The Australian Signals Directorate's Cyber supply chain risk management provides a useful security lens for supplier dependencies. The operational map should also consider people, capacity and service delivery; cyber questions alone will not reveal every interruption pathway.

For a non-cyber example, the Business Continuity Institute's analysis of weather-related supply chain disruption explains why mapping must extend across supply-chain tiers and locations. Use that perspective to ask whether apparently separate dependencies share exposure to the same regional disruption.

Use a stopping rule that preserves uncertainty

A small team cannot investigate every downstream relationship to the same depth. Set an explicit scope for this review: dependencies whose failure could materially affect the selected operation, its recovery or the controls needed to run it.

That is an editorial scoping suggestion, not a replacement for the entity's obligations or materiality assessment. Record why a branch was investigated, deferred or excluded. Revisit the decision if the service or evidence changes.

For example, Banksia initially excludes the provider's travel company because the reviewed service is remotely operated and no critical on-site travel dependency has been identified. That conclusion changes if the recovery plan later reveals that specialist staff must fly to a facility to restore equipment.

Do not turn “not disclosed” into “not present”. If the supplier cannot provide a full picture, describe the limitation and ask what alternative evidence could support the decision. This might include an assurance report with relevant coverage, a service-specific dependency statement or a joint continuity walkthrough.

Keep accountability with the direct relationship

Banksia's contract is with its managed service provider. The map should identify who at that provider owns each downstream dependency and how changes or incidents reach the bank.

This avoids a common failure: the bank starts chasing a fourth party that has no established channel for answering it, while the direct provider treats the question as someone else's problem.

Agree the information needed from the direct provider, the evidence it can reasonably supply and the escalation route for important gaps. If direct engagement with a downstream party would help, arrange it deliberately through appropriate contractual and information-sharing channels.

APRA's CPG 230 guidance discusses reasonable steps to identify fourth parties supporting critical operations. It supports a risk-focused enquiry, not a claim that an incomplete supplier list proves the absence of downstream risk.

Turn the map into decisions

Banksia's most useful finding is the identity dependency. The recovery plan assumes administrators can log in, but the supporting exercise never removed the identity service.

The team records a specific action: the direct provider will demonstrate the approved emergency-access process in a controlled test covering the payment environment. The bank's technology owner will review the result and any limits. Until then, the recovery assumption remains unverified.

The infrastructure question goes to a separate owner because it needs architecture clarification. The database question requires a staffing and capability discussion. Keeping these actions separate prevents one broad “fourth-party review complete” status from hiding unfinished work.

If several branches share a platform, use the cloud-concentration scenario; if the chain changes, use the subcontractor-change review to revisit the affected assumptions.

Review the map when a relevant service, location, subcontractor, recovery design or control changes. Choose any routine review cadence according to risk and the pace of change. The immediate next step is smaller: take one critical service and ask the provider which downstream dependency its latest recovery test assumed would still be available.