Map and Manage Third-Party Website Dependencies

Build one maintained dependency register around representative user journeys. Populate it in two passes: first observe browser-visible requests across meaningful states and interactions; then reconcile that evidence with architecture, configuration, procurement, contracts, supplier records and stakeholder knowledge. The result should connect every material reliance to its purpose, scope, owners, information flow, measured cost, failure effect, fallback, monitoring and next decision trigger. That shared record turns a scattered technical inventory into an operational view of what users and teams actually depend upon.

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

A third-party website dependency is any externally controlled code, content, service, infrastructure, credential, data source or supplier relationship that 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 may have a separate owner or failure boundary. This is therefore a map of journey reliance, not a source-code package inventory.

Begin with representative browser journeys rather than a single home-page load. Capture the states in which the dependency matters: before and after consent, following an interaction, on relevant devices and, where authorised, through authenticated or transactional steps. The browser network log can expose request status, type, initiator, size, duration, waterfall position, blocking and downstream relationships. These observations also show where a tag manager, iframe or script initiates resources that a domain-only list would obscure.

• Name the journey, state, device, network condition, cache state and observation date.
• Record initiators and descendant requests, not merely top-level domains.
• Repeat meaningful consent and interaction paths that activate different resources.
• Measure third-party cost in context instead of assuming a universal penalty.
• Treat HAR files and request logs as potentially sensitive operational evidence.

Keep capture access limited, use available sanitisation and inspect exports before sharing them or attaching them to tickets. HAR files can contain headers or captured data, and a sanitised export is not a guarantee that every remaining field is harmless. This precaution matters particularly on signed-in, form and transactional journeys. Preserve enough evidence for diagnosis, but avoid turning the dependency register into an unnecessary store of user, session or credential data.

How do you uncover dependencies that browser captures cannot show?

Use a second discovery pass across the website’s platform and supplier records. Check domain registration, authoritative DNS, certificate issuance and renewal, CDN and edge services, hosting, CMS, identity, search, forms, transactional delivery, server-to-server integrations, observability and status communications. Many of these services never appear as a recognisable browser request, yet their loss or change can still affect whether a journey starts, completes or can be supported.

Reconcile architecture diagrams and configuration with procurement systems, contracts, assurance records, renewal information and conversations with service owners and providers. No browser capture, scanner, diagram or contract list is complete alone. Supplier mapping can also expose subcontractors and shared upstream providers, but pursue that chain proportionately: prioritise concentrations whose disruption could affect a critical journey rather than attempting to document every commercial relationship.

• Ask the business owner to confirm the capability and affected journey.
• Ask the operator to confirm configuration, initiators and recovery actions.
• Ask procurement to confirm the provider, contract, renewal and supplier contacts.
• Ask security and privacy partners to confirm relevant assurance and information-flow questions.
• Record who has authority to change, accept or remove the dependency.

Join the two passes by service identity, not by hostname alone. A scheduling component, for example, may involve a visible iframe, requests initiated after interaction, an identity or API service, a contracted platform and upstream infrastructure. One register row can describe the business dependency while naming relevant endpoints and downstream services. That approach keeps the map readable without flattening a material provider chain into an unexplained collection of domains.

What should the dependency register record?

The register should hold enough evidence to explain what the dependency does, where it appears, who is accountable, what it exchanges, how it behaves and why its current disposition is justified. Give each dependency one stable record, then link it to the applicable pages, components, journey steps, states, devices, environments and activation conditions. Include the provider, useful endpoints, initiator, downstream services and the people authorised to approve change or removal.

Map information flows by actor, data sent and received, destination, purpose and activation condition, with references to the reviewed privacy or contract record. Use those fields to support qualified privacy and legal review, not to declare compliance. For performance, bind observations to a named journey, device, network, cache state and date. Resource Timing and browser evidence can expose timing and available size information, although cross-origin policies and platform conditions may limit detail.

Reliability fields should make the user consequence visible: journey-specific criticality, failure symptom, blast radius, timeout behaviour, fallback or alternate channel, monitoring signal, incident contact and last safe test. Complete the record with contract or renewal status, last observed use, last decision, decision owner, open action and next review trigger. Maintained supplier records can combine these operational fields with ownership, assurance, contract and provider-chain evidence.

How should you test what happens when a dependency fails?

Test failure in a safe environment or with explicitly approved browser tooling, changing one observed request or component at a time. Define the expected usable state before the exercise and do not create an unapproved production outage. Where relevant and safely reproducible, examine delayed, failed, denied-consent, empty-response and stale-data conditions. Request blocking can reveal visible failure behaviour, but it cannot reproduce every latency pattern, malformed response, server-side fault or production condition.

• Check content visibility, navigation, forms, validation and authentication.
• Check confirmations, timeouts, errors and alternate contact routes.
• Test keyboard use, focus, labels and other relevant accessibility behaviour.
• Compare the user-visible symptom with monitoring and incident signals.
• Record the recovery action and whether the intended fallback actually works.

Judge the whole journey, not the provider endpoint. An HTTP 200 response does not prove that a component rendered, accepted input, returned usable data or preserved an accessible fallback. Classify the observed outcome as critical, degraded, optional or measurement-only for the named journey and condition. These are shared editorial labels, not a universal risk standard; measurement-only failures can still matter when attribution, experimentation or operational evidence is required.

Consider a hypothetical scheduling widget. A browser capture reveals its iframe and initiated requests at the booking step; supplier records identify an owner and provider chain; the team documents the assumed information flow and safely blocks the widget. Page content and an accessible contact route remain usable, but instant scheduling disappears and existing monitoring misses the loss. The team records the journey as degraded, carries the monitoring gap forward and preserves the tested alternate route.

A dependency map earns its keep when it shows what users and operators experience when the reliance fails.

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

Choose a disposition by comparing documented purpose and ownership with observed cost, information flow, failure behaviour, fallback and journey criticality. The six options are practical decision lanes, not a universal standard. Record the evidence, decision owner, conditions and next trigger. For the scheduling example, a retain decision might be conditional on adding journey-level monitoring, preserving the tested accessible contact route and reviewing the choice when the supplier or journey changes.

• Retain when a documented purpose has accountable ownership and the 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 cost, control, support, data practice, failure pattern or concentration risk.
• Isolate when the capability is needed but its access or blast radius should be reduced, subject to technical and security review.
• Defer when an optional embed need not load before meaningful content or interaction, while preserving accessible activation and consent behaviour.
• Self-host only when the organisation can own lawful delivery, licensing, updates, integrity, privacy, maintenance and support.
• Remove when no owner can defend a current purpose, the dependency is unused or duplicative, or its accepted value no longer justifies its observed cost and risk.

Directly included third-party JavaScript can change outside the organisation’s release process and execute in the page context, although its capabilities depend on the integration and browser controls. Iframe separation depends on origin, sandbox and permission configuration. Content Security Policy, compatible integrity checks, server mediation or separation from critical paths may constrain exposure for some integrations, but each option brings functional trade-offs and does not eliminate supplier, privacy or availability risk.

Subresource Integrity can verify expected bytes for supported resources when delivery is compatible; it does not validate every API response, iframe, service or business behaviour. A facade can defer an optional iframe and its subresources until activation, but its keyboard behaviour, labelling, consent state and resulting experience still require testing. Self-hosting likewise moves delivery responsibility rather than removing licensing, updates, integrity, privacy, maintenance, support or upstream software risk.

How do you keep the dependency map current?

Keep the map current by making review part of normal website operations. Useful triggers include releases, tag-manager changes, new components, procurement or renewal events, supplier change and deprecation notices, incidents, privacy reviews and approved journey checks. Avoid imposing one cadence on every dependency. The appropriate trigger, fallback expectation and recovery commitment should reflect the affected journey, disruption impact, contract and availability of practical alternatives.

For each trigger, update last observed use, current contract or assurance status, the latest decision, its owner, open actions and the next event requiring review. Connect monitoring to user-visible symptoms and known measurement gaps rather than relying only on supplier or endpoint availability. Periodic browser observation remains useful because integrations, descendants and measured costs can change; supplier evidence remains necessary because the browser still cannot expose every platform or upstream reliance.

1. Select one priority journey and name its major states.
2. Capture browser-visible requests across those representative states.
3. Reconcile observations with known architecture, configuration and supplier records.
4. Create initial register rows and assign provisional business and technical owners.
5. Plan one authorised failure exercise and define the expected usable state.

Set approval conditions for new dependencies so purpose, ownership, information flow, expected cost, failure behaviour, fallback, monitoring and review triggers are considered before adoption. Expand the map proportionately from the first priority journey. Bring security, privacy, legal, procurement, accessibility and continuity partners into decisions within their remit, and require explicit authorisation for penetration testing, destructive resilience work, production fault injection, supplier assurance, jurisdiction-specific interpretations and binding recovery commitments.