How to Map and Manage Third-Party Website Dependencies

Build one maintained register around representative website journeys, then populate it in two passes. First, observe the requests and components activated as people move through meaningful states. Secondly, reconcile that browser evidence with architecture, configuration, procurement, contracts, supplier records and the colleagues who operate the service. The result should connect every material reliance to its purpose, owners, provider chain, information flow, measured cost, failure effect, fallback, monitoring and next review trigger. That shared record turns a scattered technical inventory into evidence that web, security, privacy, procurement and business owners can use together.

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

A third-party website dependency is an externally controlled reliance whose change, delay, unavailability, compromise or data practice could materially affect an in-scope journey. It may be code, content, infrastructure, a credential, a data source, a hosted service or a supplier relationship. A different origin is useful discovery evidence, but it is not the definition: an outside service may be proxied through your own hostname, while an internal-looking origin may have a distinct owner and failure boundary. This is therefore a journey-reliance map, not a source-code package inventory.

Begin with representative browser sessions and preserve the context of every observation. Capture the journey’s main pages, interactions, consent choices, authenticated or transactional states, relevant devices and any components that activate later. One initial load records only what that particular session triggered. In the network log, retain resource type, initiator, status, transfer and decoded size where available, duration, waterfall position, blocked behaviour and downstream request relationships. Third-party scripts can add network, execution and rendering work or initiate further resources, but the practical cost must be measured in the stated conditions.

• Trace tag-manager descendants and interaction-triggered requests rather than recording only the container or first domain.
• Note when consent, authentication, device characteristics or journey state changes what appears.
• Treat HAR files and request exports as potentially sensitive operational evidence.
• Limit collection and sharing, use available sanitisation and inspect each capture before attaching it to a register or ticket.

How can you uncover dependencies that browser captures do not show?

Use a second discovery pass across platform, operational and supplier evidence to find dependencies that never appear in the browser. Review domain registration, authoritative DNS, certificate issuance and renewal, edge services, hosting, the CMS, identity, search, forms, transactional delivery, server-to-server integrations, observability and status communications. Procurement systems, contracts, architecture materials, configuration records and provider discussions can expose services or provider relationships absent from a page capture. No browser session, scanner, contract list or diagram should be treated as complete by itself.

Trace upstream providers in proportion to the journey’s importance. A supplier map can record the service delivered, its importance, information flows, assurance contacts, assessment status, subcontractors and shared downstream services that create concentration risk. The aim is not to chart every commercial relationship. Prioritise chains whose loss or change could affect a critical journey, then connect each service to the people who can confirm its purpose, operation, contract position, assurance status or removal authority.

• Ask the business owner which user need the service fulfils.
• Ask the operator where it is configured and how it is monitored.
• Ask procurement which contract, renewal and supplier contacts apply.
• Ask the provider about material subcontractors or shared upstream services where the journey warrants that depth.

What should a useful dependency register record?

A useful register gives each dependency one decision-ready row spanning identity, scope, purpose, accountability, observed behaviour and lifecycle. Record the provider, service class, useful domains or endpoints, initiator, downstream services, environments, pages, components, journey steps, devices, states and activation conditions. Add the accountable business owner, technical operator, relevant security or privacy partner, procurement contact and the authority able to approve change or removal. This prevents a familiar domain name from standing in for actual ownership.

Keep performance observations tied to a named journey, device, network condition, cache state and date. Available evidence may include request counts, transfer and decoded sizes, connection and request timing, blocking, main-thread work, rendering and interaction effects; Resource Timing detail can be limited by cross-origin policy and platform conditions. For information flows, record actors, data sent and received, destination, purpose and activation condition, alongside the reviewed privacy or contract record. Use those fields to support qualified privacy or legal review, never to declare compliance.

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. Do not create an unapproved production outage. Define the expected usable state before the exercise, then observe the whole journey rather than merely checking the supplier endpoint. Where relevant and safely reproducible, examine delayed, failed, denied-consent, empty-response or stale-data conditions. Browser request blocking can reveal visible behaviour, but it cannot reproduce every latency pattern, malformed response, server-side fault or production condition.

• Check content, navigation, forms, validation, authentication and confirmations.
• Test keyboard use, labels, focus behaviour, error communication and alternate contact paths.
• Record timeouts, visible symptoms, operational signals, recovery actions and whether the intended fallback works.
• Classify the named outcome as critical, degraded, optional or measurement-only, using your organisation’s impact criteria.

Consider a hypothetical scheduling widget. The browser capture reveals its iframe and initiated requests at the booking step; supplier records identify the owner and provider chain; the register records the assumed information flow for review. In an authorised test, the team blocks the widget. Page content and an accessible alternate contact route remain usable, instant scheduling disappears, and existing monitoring does not detect the loss. The team records a degraded outcome for that journey, carries the monitoring gap into the decision and preserves the tested alternate route. An HTTP 200 response alone would not have demonstrated any of this.

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?

Choose a disposition by comparing documented purpose and ownership with observed cost, information flow, failure behaviour, fallback and journey importance. These six options are a practical decision framework, not a universal risk standard. In the scheduling example, a retain decision could be conditional on adding journey-level monitoring, keeping the tested accessible contact route and assigning a review trigger. Record who made the decision, the evidence considered, any conditions still open and the event that should bring the dependency back for review.

• Retain when the dependency serves a documented purpose, has accountable ownership and its observed effects are accepted for the journey.
• Replace when the capability remains necessary but a verified alternative improves unacceptable cost, control, support, data practice, failure behaviour or concentration risk.
• Isolate when less access or blast radius is appropriate. Direct scripts execute in the page context; iframe isolation depends on origin, sandbox and permission configuration.
• Defer an optional embed when it need not load before meaningful content or interaction. A facade and the activated experience still need consent, keyboard, labelling, accessibility and functional testing.
• Self-host only when the organisation can lawfully and operationally own licensing, delivery, 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 the observed cost and risk.

Controls require the same disciplined qualification. Content Security Policy, iframe boundaries, sandboxing, compatible integrity checks, server mediation or separation from a critical path may reduce or constrain exposure, but none eliminates supplier risk. Subresource Integrity verifies expected bytes only for supported resources under compatible delivery conditions; it does not validate every API response, iframe, service or business behaviour. Technical and security specialists should review suitability and functional trade-offs before implementation.

How do you keep the dependency map current?

Keep the map current by attaching reviews to normal operating events rather than relying on a forgotten annual spreadsheet. Suitable triggers include releases, tag-manager changes, new components, procurement and renewal activity, supplier change or deprecation notices, incidents, privacy reviews and approved periodic journey checks. For each trigger, update the last observed use, current contract or assurance position, last decision, decision owner, open actions and next review event. Review depth and fallback expectations should reflect impact rather than a universal cadence.

1. Choose one priority journey during the first week.
2. Capture its meaningful states and reconcile browser evidence with known supplier records.
3. Create initial register rows and assign provisional business and technical owners.
4. Agree one authorised failure exercise and the usable state it will test.
5. Set entry conditions for new dependencies covering purpose, ownership, information flow, expected cost, failure, fallback, monitoring and review.

Connect monitoring to user-visible symptoms and known measurement gaps, because supplier availability is only one piece of evidence. Expand the map from the first journey in proportion to business impact and operational value. Bring security, privacy, legal, procurement, accessibility and continuity partners into decisions within their remit. Penetration testing, destructive resilience work, production fault injection, supplier assurance, jurisdiction-specific interpretations and binding recovery commitments require qualified owners and explicit authorisation.