The failure of a shared technology service does not need to take down a bank's core processing platform to threaten operational resilience. The Microsoft 365 disruption of 12–13 November 2026 is a timely test of how firms understand, manage and recover from dependencies embedded across their operations.
What happened?
On 12 November, users began reporting widespread problems accessing Microsoft 365 services, particularly Exchange Online and Outlook. Related functionality across Teams, SharePoint, Copilot and other services was also affected. Microsoft reported that multiple servers had unexpectedly become unavailable, placing additional pressure on remaining infrastructure. Remediation efforts initially progressed more slowly than expected; by 13 November, Microsoft reported encouraging signs of improved server stability. The incident remained developing at the time of writing.
Microsoft said it was not aware of malicious activity causing the incident. The final root cause should not be assumed until its post-incident analysis is available.
Financial services were affected
While early headlines concentrated on schools, government and healthcare, there are specific reports of banking disruption. In Hong Kong, the South China Morning Post reported that staff at Goldman Sachs and Nomura experienced email interruptions. Goldman Sachs employees reportedly used an alternative mailbox arrangement, while Nomura staff reported being unable to send or receive emails. In Thailand, Krungthai Bank confirmed email disruption and directed customers with urgent enquiries to telephone their relationship managers or contact centre.
These are confirmed reports of communications disruption—not evidence that payment systems, trading platforms or designated important business services failed, or that regulatory impact tolerances were breached. Those conclusions require further information about the affected services, duration, customer harm and workarounds.
Five lessons for operational resilience and TPRM
1. Concentration risk is not confined to core systems
Microsoft 365 can underpin internal communications, collaboration, calendars, document access, incident coordination and customer-facing workflows. A single provider can therefore be a common dependency across several important business services, even where it is not the platform delivering the service itself. Mapping should capture these supporting dependencies and their potential for correlated failure.
2. Loss of communications can become a business-service disruption
It matters whether a communications failure prevents time-critical approvals, delays customer instructions, impairs regulatory notifications or frustrates incident management. Firms should trace the consequences through to the actual delivery of their important business services rather than assume that an email outage is automatically either trivial or intolerable.
3. Duration is only one dimension of harm
UK impact tolerances are set by reference to the maximum tolerable level of disruption to an important business service. Duration is fundamental, but firms may also use relevant non-duration measures, such as the number or type of customers affected, transaction volumes, value at risk or other indicators of harm. Where multiple measures form genuine tolerance boundaries, reaching any applicable boundary can mean the service is no longer within tolerance—even if the time limit has not elapsed. But a high number of affected email accounts does not itself demonstrate an IBS tolerance breach. Firms need to connect metrics to the relevant business service and the harm they are designed to capture.
4. A workaround is only as resilient as its dependencies
Alternative mailboxes, telephone channels and manual procedures may help, but must be tested for capacity, security, recordkeeping, accessibility and independence. An apparent fallback that shares the same authentication or routing infrastructure may fail at the same time as the primary service. The key question is not whether a workaround exists on paper, but whether it can sustain essential activity in a severe yet plausible scenario.
5. Third-party oversight must look across the whole dependency chain
Traditional supplier-by-supplier assessments can miss the accumulation of exposure to one cloud or software ecosystem. Firms should understand dependencies shared across services, outsourced arrangements and sub-contracting chains, and the limits of their control and influence over systemic providers. Supplier assurance is valuable; it is not a substitute for testing the firm's own ability to continue delivering services during supplier disruption.
The disruption to healthcare, policing and emergency-service organisations illustrates how dependence on a common technology provider can create simultaneous vulnerabilities across otherwise unrelated sectors. For financial firms, the challenge is not simply whether a critical business application can fail, but whether the underlying communications, collaboration and information infrastructure needed to manage that failure will still be available.
The TPRM question: what technology does your third party depend on?
The Microsoft disruption also begs a question for third-party risk management: do firms know which email, cloud, identity, collaboration and document-storage platforms underpin the services delivered by their material third parties? A provider may have sound business continuity policies and contractual service commitments, but still be unable to deliver if a shared technology dependency fails.
For material arrangements, a proportionate assessment should establish which technology dependencies could materially affect service delivery, what would happen if they failed, whether the provider has a genuinely independent substitute and, where substitution is unrealistic, how it would maintain or recover critical activities. Evidence should include relevant scenario-testing results and limitations of proposed workarounds, not simply assurances that a continuity plan exists.
Concentration may be hidden across apparently separate suppliers. Two different service providers could both rely on Microsoft 365, Azure, a common identity platform or another shared cloud service. Having multiple suppliers does not necessarily provide diversification if a single upstream failure could disable them simultaneously. Firms should consider this cross-provider exposure when mapping resources supporting important business services and planning severe-but-plausible scenarios.
This does not require firms to inventory every application used by every supplier, or to treat every upstream technology as a regulated subcontractor. Contractual subcontracting arrangements and broader operational dependencies are not always the same thing. The objective is to identify material points of failure, obtain risk-based assurance and understand the firm’s own options if the provider cannot continue delivering.
A practical challenge for TPRM teams: If a critical technology platform used by several of our material third parties failed simultaneously, would we know which services were exposed, how they would be affected, and what genuinely workable alternatives or contingency arrangements were available?
A timely test of the FCA's latest expectations
Just one day before this outage began, the FCA published Operational resilience: demonstrating resilience in practice (11 November 2026). Its observations on mapping, impact tolerances, scenario testing, communications and evidence of resilience are especially relevant. The publication provides supervisory observations rather than new universal rules, but reinforces the expectation that firms demonstrate how their arrangements would work in practice.
See also our related analysis: Operational Resilience: The Regulatory Bar Keeps Rising.
Questions boards and risk teams should ask now
- Which important business services rely directly or indirectly on Microsoft 365 or another shared collaboration platform?
- What would happen if email, identity services, document access and collaboration tools failed together?
- Have we tested fallback channels under realistic demand, including customer communications and regulatory escalation?
- Could the scale of disruption or customer harm reach a non-duration tolerance before our time-based tolerance?
- Can our third-party oversight and management information identify correlated exposures across different suppliers and services?
- What evidence would demonstrate that the firm stayed within impact tolerances during a comparable event?
The ultimate resilience challenge: what can realistically be backed up?
For many firms, the uncomfortable reality is that maintaining a completely independent, immediately operational replacement for Microsoft 365—or another deeply embedded enterprise technology platform—is neither proportionate nor straightforward. Email, identity, calendars, documents, collaboration and workflows can all depend on shared infrastructure. Even a supposedly separate fallback may rely on the same identity provider, network or cloud services. A backup that fails alongside the primary service is not a credible backup.
The right question is not “Do we have a backup for everything?” It is “Which important activities must continue, what alternatives are feasible, and what will we actually do when no equivalent alternative exists?” This suggests two distinct planning decisions.
1. Where a genuine alternative is feasible, identify it and test it
For example, an independently accessible Zoom or Webex capability may provide an alternative to Microsoft Teams for crisis meetings, senior-management coordination or essential client calls. But firms should verify that the alternative can be accessed without Microsoft single sign-on, that meeting invitations and contact details remain available, that sufficient licences and capacity exist, and that staff know when and how to switch. A second product name on a continuity plan does not establish resilience.
2. Where full substitution is impractical, plan how to operate without the service
If Outlook and Exchange Online are unavailable, switching every employee to a separate enterprise email environment at short notice may be unrealistic. Instead, firms should identify priority communications and the processes that depend on them: crisis escalation, time-critical payments, customer support, vulnerable customers, regulatory notifications and contact with material suppliers. Options might include independently hosted emergency mailboxes for a small response team, pre-agreed telephone and secure messaging arrangements, alternative customer notification channels, locally accessible contact lists and manual procedures. Each workaround needs an owner, security and confidentiality controls, and a realistic limit on its duration and scale.
Shared drives: a compelling case for cross-provider continuity
Shared documents may be different from email. If a firm's critical procedures, records, working documents and operational information are all held in SharePoint or OneDrive, loss of access could quickly undermine important business services. For some firms, an extended shared-drive outage could be operationally catastrophic. In such cases, maintaining an independently accessible, near-current copy of essential information on a second platform—for example Google Drive—may be a proportionate and effective investment.
This is more than a conventional backup. Periodic backups support restoration after data loss, whereas cross-provider replication and an accessible secondary workspace can support continuity during a live outage. The case is strongest for information that staff need immediately to operate critical processes, make decisions, serve customers or meet regulatory obligations. Firms need not necessarily duplicate every file or every collaboration feature.
But two vendors do not automatically mean two independent solutions. Test whether staff can sign in to the alternative without Microsoft identity services; whether the right people can find, open and securely edit the right documents; and whether the network, devices, permissions, document formats and workflows still function. Define the acceptable replication lag and how to reconcile changes after recovery. Replication can also copy accidental deletions, corruption or malicious changes, so retain separately protected, versioned or immutable recovery copies.
For genuinely critical shared information, the question should be: could we keep operating tomorrow if our primary document platform became unavailable today? If the answer is no, cross-provider document continuity deserves serious consideration and realistic scenario testing.
Fallback communications: preserve the ability to contact the right people
In practice, continuity may depend less on replacing an entire email system and more on maintaining alternative ways to communicate with the people who matter most. Firms should identify which communications are time-critical, who needs to be reached, and which channel will remain usable if Microsoft 365 or another common platform fails.
- Regulators: maintain current supervisory and incident-reporting telephone numbers, escalation contacts and any approved alternative reporting channels outside the affected email environment. An outage does not automatically suspend notification obligations; follow the applicable regulator’s instructions and document attempts to notify.
- Customers: use pre-approved SMS, telephone, website or app notices, and public social media updates where suitable. Social media may be effective for general service-status messages, but not for sharing confidential account or personal information. Where the communication is not time-critical, a postal letter—or waiting until the primary channel is restored—may be proportionate, subject to applicable obligations.
- Critical suppliers and internal decision-makers: keep independently accessible contact lists, emergency telephone trees and alternative conferencing details for incident teams, the board, key service providers and other essential stakeholders.
These channels should be prioritised, secure, accessible and rehearsed. Keep necessary contact information available without relying on Outlook, SharePoint or Microsoft authentication; verify that backup channels have sufficient capacity; and define who can authorise their use. The objective is not to preserve every routine message during an outage, but to protect critical decisions, customer outcomes, regulatory communications and the continued delivery of important business services.
The same principle applies to SharePoint documents, Teams-based coordination and identity services. Identify what information must be available offline or through independent channels, the conditions for activating contingency arrangements, and the point at which reduced service becomes intolerable. Workarounds are not necessarily equivalent substitutes: firms must assess residual customer harm, transaction volumes, data protection, control degradation and the risk of breaching both duration and non-duration impact tolerances.
Practical next steps: revisit resource mapping and scenario testing
The Microsoft disruption is a timely prompt for firms to revisit their resource mapping and forthcoming operational resilience scenario-testing programmes.
1. Revisit resource mapping to identify common dependencies
Trace the technology resources supporting important business services (IBSs), including communications, document access, cloud infrastructure, identity and authentication. Look beyond individual applications and suppliers to identify common platforms, correlated exposures, single points of failure and dependencies across multiple IBSs. Mapping should reveal vulnerabilities, not simply inventory resources.
2. Include severe technology disruption in scenario testing
The maturity of scenario testing is demonstrated by moving beyond the obvious choices of disruption. Most firms will consider the failure of core banking, payment systems or market-data platforms such as Bloomberg. But how many deliberately test a severe but plausible outage of the everyday technology on which staff and processes depend: Outlook, Teams, SharePoint and OneDrive, potentially at the same time? These services may not themselves be designated as important business services, but their loss can undermine the people, information, coordination and controls needed to deliver several IBSs simultaneously.
Such a scenario should ask practical questions. How would teams communicate internally, with customers, third parties and regulators if email and Teams were unavailable? Could staff access essential procedures, customer information, contact lists and crisis plans if SharePoint and OneDrive were inaccessible? What happens to decision-making, approvals, incident coordination and time-critical operations? Could the scale of customer impact breach a non-duration impact tolerance before a duration threshold is reached?
Then test the Plan Bs, not just describe them: independently accessible copies of essential information, alternative communications channels, telephone contact trees, pre-agreed manual workarounds and reduced-service arrangements. Check whether alternative platforms rely on the same identity, connectivity or cloud dependencies, whether they have sufficient capacity, and whether staff can actually use them under pressure. Where meaningful substitution is not feasible, explicitly document the limitations and how the firm will prioritise essential services and manage harm.
Include prolonged or simultaneous loss of critical technology capabilities, such as email, collaboration, document storage and identity services, rather than assuming each fails independently. Assess impacts on IBS delivery and duration-based and relevant non-duration impact tolerances, including potentially immediate customer harm.
Test whether Plan Bs actually work: independently accessible contact lists and essential records, alternative communications, manual procedures, escalation and regulatory notifications. Verify capacity, security, accessibility and independence from the failed infrastructure.
Where full substitution is impractical or disproportionate, identify essential activities that must continue, feasible reduced-service arrangements, their limitations and how disruption and customer harm would be managed.
The objective is not to duplicate every technology platform. It is to understand the dependencies, expose vulnerabilities, test realistic alternatives and demonstrate whether important business services can remain within impact tolerances.
The other side of the bargain: systemic technology providers must be more resilient
There is a limit to how much resilience an individual firm can engineer around a widely shared technology dependency. If thousands of organisations rely on the same provider, requiring each to replicate the provider’s entire infrastructure is unlikely to be efficient or achievable. This is precisely why systemic third-party resilience matters, alongside each firm's own responsibility for continuity.
The UK Critical Third Parties (CTP) regime provides a framework for oversight of designated technology and other service providers whose disruption could threaten the stability of, or confidence in, the UK financial system. Designation is a specific regulatory decision; it should not be assumed simply because a provider is large or widely used. The regime does not transfer firms’ accountability for their important business services to the provider or the regulators.
At provider level, the expectation should be robust fault isolation, disciplined change management, resilient identity and control-plane services, credible recovery capability, transparent incident communications and tested fallback arrangements that reduce the likelihood of a common failure affecting many customers simultaneously. The aspiration should be for genuinely systemic, widespread disruptions to become exceptionally rare—perhaps a one-in-25- or one-in-50-year class of event—rather than a recurring feature of business as usual. These are illustrative ambitions, not statutory frequency thresholds or guarantees; even very rare events require effective containment and recovery.
Ultimately, this is a shared but asymmetric responsibility: financial firms must know what they can back up, what they cannot, and how they will respond; major technology providers must design and operate services resilient enough that customers are not routinely forced to activate those last-resort arrangements. Supervisory attention to concentration, substitutability and common points of failure is essential because an apparently local dependency can become a system-wide vulnerability.
Operational resilience is not a promise that suppliers will never fail. It is a demonstrable capability to continue delivering important business services despite those failures. The Microsoft incident is another reminder that seemingly peripheral technology can become critical through the processes and services that depend on it.
Editorial note (13 November 2026): This is an initial assessment of a developing incident. Reported impacts and Microsoft's technical findings may change as further information becomes available. No bank-specific IBS breach is asserted.