St Georges Strategy

Signals / Technology failure

Outages, change failure, data integrity, and recovery

The technology-failure page turns outages, cloud dependency, change risk, ICT incidents, and recovery expectations into practical control-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.

  1. Structural referenceReviewed 9 Jul

    Incident reporting should be connected to customer impact and remediation evidence

    Official expectations / FCA incident reporting
  2. Structural referenceReviewed 9 Jul

    ICT and security risk management should connect change, access, monitoring, and continuity

    Official expectations / EBA ICT risk guidelines
  3. Structural referenceReviewed 9 Jul

    Technology outsourcing needs exit, audit, data return, and subcontracting evidence

    Official expectations / FCA outsourcing and operational resilience
  4. 90-day windowReviewed 9 Jul

    ESAs' first DORA incident report finds a third of major ICT incidents have cross-border impact

    Primary / ESAs (EBA, EIOPA, ESMA) / 2026-06-03
  5. Structural referenceReviewed 9 Jul

    Critical third-party policy turns technology concentration into a systemic resilience question

    Official source / FCA critical third parties

Why it made the weekly brief

The editorial judgement

Technology failure matters when it moves from an internal incident into customer harm, regulatory exposure, market disruption, or evidence that recovery has not been tested.

So what

Availability is not the same as recoverability

A system can be up while a customer journey, payment flow, report, or control process is broken. The evidence test is the service outcome.

Who cares

COO, CIO, CTO, resilience, operations, product, compliance, and suppliers

The same failure can sit across change management, third-party risk, resilience, cyber, data, and customer communications.

Evidence needed

Service maps, change records, logs, recovery tests, and communications

Good assurance shows the firm knows what failed, who was affected, how it recovered, and what control changed.

Technology evidence checklist

What the reader should ask for

Technology-failure evidence should connect component events to service outcomes, owner decisions, recovery, and learning.