Google Cloud us-west1 disruption exposes the depth of shared dependencies
Primary / Google Cloud Service Health / 2026-08-20
Signals / Third-party risk
Dependencies that look internal when they fail
The exploded third-party page behind the weekly brief. It translates vendor, model-provider, cloud, processor, and outsourcing signals into ownership and evidence questions.
Curated memory
Still material
These signals remain live after editorial review. Most stay for up to 90 days; exceptional structural anchors can remain for six months with a recorded reason.
Agentic AI suppliers create permission and audit-log questions
FCA one-year review: third-party vulnerability identification still needs more work despite mapping progress
ICT risk governance should connect supplier access, monitoring, and continuity
Material outsourcing still needs audit, subcontracting, and exit evidence
FSB consults on sound practices for AI adoption, including third-party and vendor concentration risk oversight
Signal → Implication → Decision
Turn the lead signal into an owner decision
This framework turns the current lead signal into the implication and decision a senior owner should be able to act on.
External providers can create internal-looking failure, especially where custody, cloud, processors, model providers, or DLT dependencies sit behind customer journeys.
Decide which critical dependencies need exit evidence, assurance rights, concentration limits, and tested customer-impact playbooks.
Why it made the weekly brief
The editorial judgement
Third-party risk matters when the external provider effectively becomes part of the firm's control environment, customer journey, or regulatory evidence base.
Outsourced does not mean externally owned
The customer, supervisor, and board will often experience a vendor failure as the firm's failure. The weekly brief should make that accountability visible.
Procurement, technology, resilience, legal, compliance, data, and business owners
Third-party risk cuts across contract terms, control assurance, incident response, data lineage, exit planning, and customer impact.
Criticality, ownership, concentration, control rights, and exit practicality
Good assurance should show who owns the dependency, what rights exist, what evidence is available, and how the firm would operate during failure.
Third-party evidence checklist
What the reader should ask for
This checklist gives a third-party or resilience owner enough prompts to test the current evidence pack.
- Which providers support important business services, regulated activities, customer journeys, or produce evidence a regulator would ask for?Map
- Who is the accountable internal owner for each provider, and who owns the failure response?Govern
- Are audit, information, incident, data return, subcontracting, and exit rights contractually clear and practically usable?Legal
- What evidence proves the provider's control is operating, and how fresh is it?Assure
- Could the firm exit, substitute, degrade gracefully, or operate manually within the tolerance window?Recover
Archive and source trail
How this topic should compound over time
Third-party risk is cumulative: the value comes from seeing repeated dependency patterns across providers, services, and regulatory expectations over time.
Processors, model providers, and AI tools
Included in weekly signals and control lessons.
Provider incidents, regulatory expectations, and assurance signals
The weekly brief carries the linked sources used to build this dependency view.
FCA outsourcing and resilience expectations
Use as the standing UK reference for accountability, criticality, and resilience evidence around material suppliers.