Map and Manage Third-Party Website Dependencies

Build one maintained dependency register around representative user journeys, then populate it in two passes. First, observe browser-visible requests across meaningful states and interactions. Second, reconcile those observations with architecture, configuration, procurement, contracts, supplier records and stakeholder knowledge. The result should connect each reliance to its purpose, owners, provider chain, information flow, measured cost, failure effect, fallback, monitoring and next review trigger. That shared record matters because an apparently owned experience can depend on widgets, tag-manager descendants, identity services, APIs, infrastructure and upstream suppliers that different teams understand only in fragments.

What counts as a third-party website dependency, and how can you find it?

Count any externally controlled code, content, service, infrastructure, credential, data source or supplier relationship whose behaviour can materially affect an in-scope journey. A different origin is useful discovery evidence, but it is not the definition. An external service may be proxied through a first-party hostname, while a same-company service can have a separate owner and failure boundary. This is therefore a map of journey reliance, not an inventory of source-code packages or a judgement based solely on domain names.

Start with representative browser journeys rather than a homepage scan. Capture major page states, interactions, devices, consent choices and authenticated or transactional paths where authorised. The network log can expose status, resource type, initiator, size, duration, waterfall position, blocked behaviour and request relationships. Capture the context as well as the request: a script may activate only after consent, an iframe after interaction, or an API after form submission. Third-party scripts can add network, execution and rendering work, but the effect must be measured in that defined context.

• Name the journey step, state, device, network condition, cache state and capture date.
• Trace initiators and descendants, including resources launched through a tag manager or embedded component.
• Treat HAR files as potentially sensitive operational evidence; limit collection and sharing, use available sanitisation and inspect the capture before distribution.

How can you uncover dependencies that browser captures cannot show?

Run a second discovery pass through the organisation’s platform and supplier evidence. Review domain registration, DNS, certificate issuance and renewal, content delivery and edge services, hosting, the CMS, identity, search, forms, transactional delivery, server-to-server integrations, observability and status communications. These services may be essential to a journey without appearing as an obvious third-party browser request. Procurement systems, contracts, architecture records, configuration and provider discussions can also expose provider relationships and subcontractors that a capture misses.

Reconcile the evidence instead of treating any source as complete. A supplier register may know the contract but not the pages affected; an architecture diagram may omit a newly added tag; a browser capture may reveal a widget but not its upstream platform. Give each finding a provisional journey link and a person who can confirm its purpose, operation, contract, assurance position or removal authority. Where records conflict, retain the uncertainty as an open action rather than silently choosing the most convenient version.

• Trace subcontractors and shared upstream services in proportion to journey importance.
• Prioritise provider chains whose concentration or loss could affect a critical business action.
• Avoid attempting to map every commercial relationship when it cannot materially improve a journey decision.

What should your dependency register record?

Record enough information to explain what the dependency does, where it appears, who can act and what happens when it misbehaves. Give each dependency one row, but allow multiple journey observations beneath it when conditions differ. Include the provider, service class, relevant endpoints, initiator, downstream services, environments, pages, components, states, devices and activation conditions. Then assign an accountable business owner, technical operator, relevant security or privacy partner, procurement contact and the authority that can approve change or removal.

Keep performance and information-flow evidence contextual. Resource Timing and browser tooling can provide timing, initiator and available size data, although cross-origin policy and platform conditions may limit detail. Bind every observation to its journey, device, network, cache state and date rather than creating a universal supplier score. For information flows, identify actors, data sent and received, destinations, purpose and activation condition. Use minimisation, purpose and transparency as review questions, while leaving Australian and other jurisdiction-specific determinations to qualified privacy or legal partners.

How should you test what happens when a dependency fails?

Test one controlled condition at a time in a safe environment or with explicitly approved browser tooling. Define the expected usable state before changing anything, and do not create an unapproved production outage. Where relevant and safely reproducible, examine delayed, failed, denied-consent, empty-response and stale-data conditions. Observe content, navigation, forms, validation, authentication, confirmations, alternate contact paths, accessibility, timeouts, errors and monitoring. Blocking a request can reveal visible failure behaviour, but it cannot reproduce every supplier outage or production interaction.

1. Select a representative journey and write down what must remain usable.
2. Block or degrade one observed request or component under an authorised test plan.
3. Record the user-visible symptom, operational signal, recovery action and whether the intended fallback works.
4. Escalate destructive resilience testing, production fault injection, penetration testing and supplier assurance to qualified owners with explicit authorisation.

Consider a hypothetical scheduling widget. A browser capture reveals its iframe and initiated requests at the booking step; supplier records identify the accountable owner and provider chain; the team documents the assumed information flow, then safely blocks the widget. Page content and an accessible alternate contact route remain usable, but instant scheduling disappears and existing monitoring does not notice. The team records the journey as degraded, carries the missing signal into the action list and makes any retention decision conditional on monitoring and preservation of the tested alternate path.

Classify the observed outcome as critical, degraded, optional or measurement-only for the named journey and condition. These labels are an editorial triage aid, not a universal continuity standard. Measurement-only does not mean irrelevant: completion may remain available while attribution, experimentation or operational evidence becomes incomplete. Likewise, an endpoint response or HTTP 200 does not establish that content, forms, accessibility and fallback still work together as a usable business journey.

A dependency map earns its keep when it shows not only what the website calls, but what users and operators experience when that reliance fails.

How do you choose whether to retain, replace, isolate, defer, self-host or remove it?

Choose a disposition from documented purpose, ownership, information flow, measured cost, journey criticality, failure behaviour and fallback evidence. The six options below are a practical synthesis, not a universal standard. Record the decision, its owner, conditions, unresolved questions and the event that will reopen it. For the scheduling example, retaining the widget is defensible only as the team’s explicit decision: monitoring must be added, the accessible alternate route preserved and a review trigger assigned.

• Retain when a current purpose and accountable owner are clear, and observed cost, information flow and failure behaviour are accepted for the journey.
• Replace when the capability remains necessary but a verified alternative improves an unacceptable issue involving cost, control, support, data practice, failure behaviour or concentration.
• Isolate when reduced access or blast radius is appropriate. Directly included scripts execute in the page context; iframe isolation depends on origin, sandbox and permission configuration.
• Defer when an optional embed need not load before meaningful content or interaction. A facade and its activated experience still need consent, keyboard, labelling, accessibility and functional testing.
• Self-host only when the organisation can own licensing, updates, integrity, delivery, privacy, maintenance and support. Moving the bytes does not remove upstream software risk.
• Remove when no owner can defend a current purpose, the dependency is unused or duplicative, or its accepted value no longer justifies observed cost and risk.

Apply technical controls with qualified review. Sandboxing, Content Security Policy, compatible integrity checks, server mediation or separation from critical paths may reduce particular exposures, but they can constrain functionality and do not eliminate supplier risk. Subresource Integrity checks expected bytes for supported resources under compatible delivery; it does not validate every API response, iframe, external service or business behaviour. The register should state which control is actually implemented, what it covers and what residual reliance remains.

How do you keep the dependency map current?

Make register maintenance part of normal website operations and trigger review when relevant evidence changes. Useful triggers include releases, tag-manager changes, new components, procurement and renewal events, supplier change or deprecation notices, incidents, privacy reviews and approved periodic journey checks. Do not impose one cadence on every dependency. For each triggered review, update last observed use, current contract or assurance status, the last decision, decision owner, open actions and the next event that should reopen the record.

1. Choose one priority journey during the first week and capture its major states.
2. Reconcile browser observations with known platform and supplier records.
3. Create initial rows, assign provisional owners and mark unresolved evidence plainly.
4. Plan one authorised failure exercise and connect monitoring to the user-visible symptom.
5. Add approval conditions for new dependencies before they enter a critical journey.

Start small enough to finish, then expand in proportion to journey impact. Monitoring a supplier or endpoint is useful, but it does not replace checking the journey and its fallback. Bring security, privacy, legal, procurement, accessibility and continuity partners into decisions within their remit. Require explicit authorisation for destructive resilience work, production fault injection, penetration testing and supplier assurance, and qualified judgement for jurisdiction-specific interpretations or binding recovery commitments. A useful register makes ownership and failure behaviour visible before the next release, renewal or incident forces the question.