Map and Manage Third-Party Website Dependencies

Build one maintained register around representative website journeys, then populate it in two passes. First, observe browser requests across meaningful states and interactions. Second, reconcile those observations with architecture, configuration, procurement, contract, supplier and stakeholder records. The result should connect each external reliance to its purpose, scope, owners, provider chain, information flow, measured cost, failure effect, fallback, monitoring and next review trigger. That shared record gives web, business, security, privacy and procurement partners enough context to make explicit decisions instead of managing an unexplained list of domains.

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

For this register, count 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 outside service may be proxied through an organization-owned hostname, while a same-company service may have a distinct owner or failure boundary. This is therefore a map of journey reliance, not a source-code package inventory or a simple count of external domains.

Begin with browser evidence from representative journeys rather than one convenient home-page load. Capture the relevant devices, consent choices, signed-in or transactional states and interactions that reveal deferred scripts, embedded components and tag-manager descendants. In the network log, retain the resource type, initiator, status, size, duration, waterfall position, blocked behaviour and downstream request relationships. Third-party scripts can add network, execution and rendering work, but record those effects as contextual observations instead of assuming a standard penalty.

• Repeat captures for important states, including consent accepted, declined or not yet decided where applicable.
• Follow initiator chains so a familiar container does not hide the services it activates.
• Review HAR files before sharing them; captures can contain sensitive headers or other operational data.
• Limit collection, storage and distribution, even when an available sanitization option has been used.

How do you uncover dependencies that browser captures cannot show?

Run a second discovery pass through the records and people responsible for the platform and its suppliers. Check domain registration, DNS, certificate issuance and renewal, edge services, hosting, the CMS, identity, search, forms, transactional delivery, server-to-server integrations, observability and status communications. These services may never appear as distinct browser requests, yet the journey can still rely on them. Reconcile what the browser showed with architecture material, configuration, procurement systems, contracts and provider discussions.

Trace upstream relationships in proportion to their possible effect on priority journeys. A supplier map can record the provided service, its importance, information flows, assurance contacts, assessment status, subcontractors and shared downstream providers. The goal is not to diagram every commercial relationship. It is to expose provider chains or concentration points whose loss could materially change the journey, then connect each dependency to someone who can confirm its purpose, operation, contract, assurance status or removal authority.

• Ask the business owner what user or operational need the service supports.
• Ask the technical operator how it is configured, invoked and monitored.
• Ask procurement or vendor management who supplies it and when its commercial terms change.
• Ask qualified security and privacy partners which assurance and information-flow questions remain open.

What should the dependency register record?

Give each dependency one decision-ready row linking identity and scope, purpose and accountability, observed evidence, and lifecycle action. Identify the provider, relevant endpoints, entry point, downstream services, environments, pages, components, journey steps, states, devices and activation conditions. Name the accountable business owner, technical operator, appropriate security or privacy partner, procurement contact and approval authority. A maintained supplier record can combine these fields with contract, assurance and subcontractor information instead of scattering the evidence among separate teams.

Bind every performance observation to a named journey, device, network condition, cache state and date. Record available request counts, transferred and decoded sizes, connection and request timing, blocking, main-thread work, rendering and interaction effects without manufacturing a universal score. Resource Timing can provide useful timing and size fields, although cross-origin policy and platform conditions may limit detail. For information flows, document actors, data, destinations, purpose and activation. Use minimization, purpose limitation and transparency as review questions, not as a declaration of Canadian legal compliance.

How should you test what happens when a dependency fails?

Use a safe test environment or explicitly approved browser tooling, define the expected usable state, and change one observed request or component at a time. Do not create an unapproved production outage. Where relevant and safely reproducible, examine delayed, failed, denied-consent, empty-response or stale-data conditions. Observe content, navigation, forms, validation, authentication, confirmations, alternate contact paths, accessibility, timeouts, errors and monitoring. Blocking a request can reveal failure behaviour, but it cannot reproduce every provider, server-side or production condition.

1. Choose a representative journey and state what must remain usable.
2. Apply one authorized condition while leaving unrelated dependencies unchanged.
3. Record the visible symptom, operational signal, recovery action and actual fallback behaviour.
4. Classify the tested outcome as critical, degraded, optional or measurement-only for that journey and condition.

Consider a hypothetical scheduling widget. A browser capture reveals its iframe and initiated requests at the booking step; supplier records identify the 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 detect the loss. The team records a degraded outcome, the missing signal and the tested alternate path. These four labels support shared triage; they are not a universal continuity or risk standard.

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

How do you choose the right disposition for a dependency?

Choose retain, replace, isolate, defer, self-host or remove 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 standard. Record the evidence, conditions, decision owner and review trigger beside the disposition. For the scheduling example, retaining the widget could be conditioned on adding journey-level monitoring, preserving the tested accessible alternate route and reviewing the decision when relevant evidence changes.

• Retain it when it has a current purpose, accountable ownership and accepted effects for the journey.
• Replace it when the capability remains necessary and a verified alternative improves an unacceptable cost, control, support, data practice, failure pattern or concentration concern.
• Isolate it when reduced access or blast radius is appropriate. Direct third-party JavaScript executes in the page context; iframe isolation depends on origin, sandbox and permission configuration.
• Defer it when an optional embed need not load before meaningful content or interaction. A facade can postpone an iframe, but the placeholder and activated experience still need functional, consent and accessibility testing.
• Self-host it only when the organization can lawfully and operationally own licensing, delivery, updates, integrity, privacy, maintenance and support.
• Remove it when no owner can defend a current purpose, it duplicates another capability or its accepted value no longer justifies its observed cost and risk.

Select technical controls with qualified review. Sandboxing, Content Security Policy, compatible integrity checks, server mediation or separation from a critical path may constrain particular integrations, but they do not eliminate supplier risk. Subresource Integrity verifies expected bytes for supported resources when delivery is compatible; it does not validate every API response, iframe, external service or business behaviour. Moving files onto organization-controlled hosting likewise changes delivery responsibility without removing maintenance or upstream software risk.

How do you keep the dependency map current?

Make the register part of normal website operations by attaching reviews to events that change the evidence. Useful triggers include releases, tag-manager changes, new components, procurement or renewal activity, vendor changes and deprecations, incidents, privacy reviews and approved periodic journey checks. For each trigger, refresh observed use, ownership, assurance or contract status, the last decision, open actions and the next review event. Third-party guidance supports identifying, measuring and auditing integrations, but it does not establish one suitable cadence for every organization.

1. Select one priority journey during the first week.
2. Capture its major states and reconcile browser evidence with known platform and supplier records.
3. Create initial rows, assign provisional owners and flag unresolved information flows or provider chains.
4. Plan one authorized failure exercise and define the expected usable state before running it.
5. Set approval conditions so new dependencies arrive with purpose, ownership, fallback, monitoring and review triggers.

Connect monitoring to user-visible symptoms and missing operational evidence, because supplier or endpoint availability does not prove that the journey and its fallback still work. Set fallback expectations and recovery commitments according to impact rather than imposing identical requirements on every dependency. Start with enough evidence to make ownership and failure behaviour visible, then expand proportionately. Bring qualified security, privacy, legal, procurement, accessibility and continuity partners into decisions within their remit, and require explicit authorization for destructive resilience work, production fault injection and binding recovery commitments.