Edition history

The question

How can an organisation benefit from professionally operated cloud services while retaining the ability to work when those services fail?

Incident snapshot: Microsoft updates issued around 14:00 CET on 13 November 2026. The incident remained open at that point. This volume does not claim a final duration or root cause.

1. The morning the normal route stopped working

An inbox becomes a loading animation. A calendar cannot be opened. Someone sends a message asking whether everyone else has the same problem, using a channel that may share the same dependency.

The first task is to establish what still works. The second is to decide which work cannot wait.

On 12 November 2026, Microsoft recorded the beginning of an Exchange Online incident at 17:17 CET. Its updates the following day described recovery progressing across regions, with intermittent access problems and delayed email remaining. The technical scope was uneven: most core Teams calling, meeting and chat functions remained available, while Exchange-dependent operations were affected; direct access to SharePoint files remained functional. A final root cause had not been published in the retrieved incident record.¹

The business effects were real. Workhorse announced that it was moving its quarterly results release and conference call from 12 to 16 November, explicitly attributing the postponement to disruption from the Microsoft outage. That is a documented consequence, without requiring the much broader claim that every affected company had lost access to all its data.²

Public discussion quickly turns such episodes into verdicts about procurement. People whose services are working describe the good decision they made. People whose services are failing question the subscription they bought. Others announce that the whole problem would disappear if everyone operated their own servers.

Each reaction begins with something understandable. A working alternative is useful. An expensive interruption deserves scrutiny. Local control can matter profoundly. The error comes when one observation is asked to settle a much larger question.

Being unaffected by a particular incident establishes that a particular failure did not stop your work at that moment. It does not establish your probability of interruption over a year, the independence of your recovery arrangements, or your ability to leave the service later.

There is room for an honest defence of major providers here. There is also room for a serious criticism of the dependencies they create. The two arguments belong in the same analysis.

2. Four nines is a precise claim

Reliability discussions often contain numbers that function more like compliments. A service is described as having four nines because it usually works, and because the difference between 99.9 and 99.99 looks small on a page.

That difference is a factor of ten in the unavailable share of time.

For a simple time-based measure of a defined service or function, availability is the measured period minus downtime, divided by the measured period. Using a 365-day year and a 30-day month produces the following mathematical equivalents. These are calculations, not a description of any particular contract.

Suppose a service experiences one complete 24-hour outage and absolutely no other interruption. In the year containing that outage, its time-based availability is 99.7260%. Spread that one day across five years and the average is 99.9452%. Spread it across ten years and it is 99.9726%.

To average 99.99%, one full day of downtime would have to be separated by approximately 27.4 years of otherwise uninterrupted operation. A good decade does not make a day-long outage compatible with an annual four-nines claim. Nor does it repair a monthly commitment: that 24-hour failure would mean 96.6667% availability in a 30-day month.

There is an equally important qualification. A reported incident lasting a day may affect different users at different times, or only particular features. Its headline duration cannot automatically be treated as a full day of downtime for every customer or every function.

Both kinds of precision are necessary. We should correct exaggerated assurances without inflating the outage.

3. The promise, the measurement and the working day

Three questions are easily collapsed into one: what does the contract promise, what has the provider measured, and what could the customer actually do?

An SLA defines a service commitment and consequences when it is missed. An SLO is an operational objective. An SLI is the measurement used to judge performance. Google's own reliability literature makes these distinctions, including the importance of measuring the experience that matters to users.³

The relevant contracts are more specific than a vendor's name.

Sources: current English Microsoft SLA, Google Workspace SLA, AWS Compute SLA and Google Compute Engine SLA, checked on 13 November 2026. These rows illustrate different contractual scopes; they are not a provider performance ranking. Google Compute Engine has additional tier, instance-family and regional exceptions.⁴⁵⁶⁷

Microsoft's October 2026 English SLA gives Exchange Online, the specified Teams service and SharePoint Online credit bands beginning below 99.9%. Its service definitions differ, and its credits do not compensate for lost revenue or operational losses. Google Workspace also commits to 99.9% monthly availability for covered services, using its own error-rate definition and credit conditions.⁴⁵

A service credit is meaningful contractual accountability. It cannot recover a missed deadline, recreate a market opportunity or remove a queue of unfinished work. Business continuity has to address those consequences separately.

Observed performance is a different evidence category again. Microsoft's published worldwide table reports 99.927% for Q4 2024, 99.954% for Q4 2025, 99.526% for Q1 2026 and 99.994% for Q2 2026. These are provider-reported aggregates, with stated coverage exclusions; they are neither an independent audit nor the experience of every tenant. The current page does not fully specify the aggregation methodology. They nevertheless refute a universal floor of 99.99%.⁸

Google has separately claimed 99.99% Workspace uptime for the elapsed portion of 2025 in an October 2025 marketing announcement. That is a dated vendor claim, not a current audited comparison with Microsoft's differently presented data.⁹

The customer needs a further measurement: can an authorised employee complete the important task, using the actual device, network, credentials, application and counterparties involved? A healthy provider dashboard and an unusable business process can coexist.

4. The honest case for professional operations

The strongest argument for managed services concerns the work that must happen continuously to keep a system dependable.

Someone must monitor capacity, maintain equipment, evaluate patches, renew certificates, test recovery, handle failed changes, cover absences, investigate alerts and preserve the knowledge needed when the original administrator leaves. These obligations exist whether the equipment sits in an office, a Swiss data centre or a hyperscaler's region.

A large provider can spread specialist operations, spare capacity and engineering investment across many customers. That creates an economic reason to expect strong capabilities that a small organisation may struggle to fund alone. It is an argument about resources and operating design, not proof that every cloud service outperforms every internal system.

Microsoft's reliability documentation describes redundant facilities and networks, controlled updates, recovery capabilities and a division of responsibility that changes between software, platform and infrastructure services. It also makes customers responsible for selecting and configuring relevant reliability features and designing their workloads appropriately.¹⁰

This distinction matters when people say they have moved to the cloud. Buying a managed email service transfers different responsibilities from renting a virtual machine and installing an email server on it. The latter still requires substantial administration. An unchanged maintenance problem can survive a change of hosting address.

The concern about neglected patches and equipment has a legitimate foundation. NIST treats patch management as preventive maintenance and a continuing cost of doing business. Its process includes prioritisation and verification, rather than an instruction to install every change immediately without considering the consequences.¹¹

Industry research also points towards operational discipline. In Uptime Institute's 2025 survey, 87% of the 98 respondents answering the relevant question after an impactful outage believed better management, processes or configuration could have prevented it. That is a retrospective judgement by a subset of a mixed industry sample, not a measured fraction of all failures caused by careless in-house administrators.¹²

An October 2026 Uptime analysis found fewer reported outages among facilities with greater power and cooling redundancy. It explicitly cautioned that the relationship could not be separated from operational maturity, maintenance, equipment condition and other design choices.¹³

The evidence supports asking who will do the work and how it will be funded. It does not support accusing an entire category of operators of incompetence.

An experienced internal team with adequate staffing, carefully bounded requirements, redundant facilities and practiced recovery can operate excellent infrastructure. A poorly designed cloud application can fail frequently. A capable regional managed provider is another option. Treating all of these as two camps hides the choices that actually determine the outcome.

5. Why a universal cloud versus on-premises multiplier fails

A credible comparison would need the same workload, service boundary, measurement period, failure definition and level of business impact. It would also need to distinguish planned maintenance from unexpected interruption and account for the architectures and staffing being compared.

Without those controls, it is easy to compare the availability of one provider component with the availability of an entire company's working environment. Or to compare the public incident record of a global platform with local outages that never become news. Neither comparison establishes an availability advantage of a particular size.

The research reviewed for this volume did not identify a contemporary, representative study supporting a universal claim that self-managed infrastructure is a fixed number of times less available. That finding leaves room for substantial advantages in individual cases; it prevents those cases being presented as a population-wide ratio.

Uptime's 2026 public outage summary illustrates the denominator problem. About two-thirds of publicly reported outages in its nine-year record involved third-party providers, a category combining cloud and internet companies, telecommunications and colocation. The same summary reports declining per-site outage frequency. Counts of visible incidents and rates per site answer different questions. Neither figure supplies an automatic ranking of cloud against internal operations.¹⁴

Even within large clouds, architecture and placement affect the result. Uptime modelled potential effects of 2024 provider incident reports across 116 regions. In the worst affected zone, it estimated approximately 25 hours of downtime for a single-zone application, falling to about ten with two zones and five with two regions. These were conservative modelled exposures, including possible subset and control-plane impacts and excluding operating-system or application-code failures. They were not measured results for every customer.¹⁵

That is a more useful finding than declaring one hosting category universally superior. The infrastructure offers capabilities; the application and operating model determine which of them become effective protection.

A practical procurement comparison therefore asks: what service can this organisation realistically maintain over the next several years, including weekends, staff turnover, equipment renewal and the recovery exercise? The imagined perfectly maintained internal system should not be compared with a real provider's worst day. Equally, a provider's best marketing number should not be compared with the least competent internal installation someone remembers.

6. Excellent average reliability can concentrate failure

Imagine eight organisations. Each loses one day of service during a 30-day period. In the first scenario, the failures happen on different days. In the second, all eight fail on the same day.

The total is identical: eight organisation-days of interruption. Each organisation has the same time-based availability in both scenarios. The maximum number unable to work simultaneously changes from one to eight.

This is an illustration, not a measurement of actual providers. It shows what an average omits.

When failures coincide, a firm's customer, bank, supplier and adviser may be impaired together. A functioning internal system cannot force an unavailable counterparty to respond. Repair contractors and support channels may face simultaneous demand. Critical deadlines may arrive while everyone is trying to find another route.

This is why a large provider outage can deserve public attention even if the affected service usually performs very well. The interruption concentrates inconvenience and can concentrate financial or operational harm. The same number of failed minutes can have different consequences depending on when they occur, how long the longest interruption lasts and who else fails at the same time.

FINMA's 2025 annual report directly addresses this distinction. It warns that growing dependence on major public-cloud providers can cause simultaneous failures at multiple financial institutions, impair critical functions and, in an extreme case, threaten financial-market stability. That is a warning about concentrated exposure, not a statement that cloud services necessarily fail more frequently than internal systems.¹⁶

The defence of providers therefore has a boundary. High everyday availability can justify buying a service. It cannot justify treating the consequences of its failure as negligible.

An organisation should examine at least its total interruption, its longest interruption and its ability to operate during a shared disruption. These measures describe different aspects of the risk. An annual percentage cannot do all three jobs.

7. The dependency beneath the logo

Provider diversification can reduce exposure to a particular supplier. Whether it produces a working alternative depends on the underlying dependencies.

Google's June 2025 incident is instructive. A defective code path in Service Control was activated by a policy change that propagated globally. The impact reached multiple Google Cloud and Workspace products. Regional distribution did not prevent a shared control mechanism from spreading failure.¹⁷

Cloudflare's incident report for the same date describes a failure of third-party storage underpinning Workers KV. Services depending on KV were disrupted, while products including DNS, proxy and WAF were not directly affected. Its report does not name the storage supplier. The mechanism alone establishes the point: a service can inherit a dependency that is not obvious from the brand the customer bought.¹⁸

AWS's October 2025 Northern Virginia incident began with a race condition in DynamoDB DNS management and propagated into dependent services and recovery processes. The impact was not the loss of all AWS regions or all running virtual machines. Other-region DynamoDB replicas could still serve requests, while replication involving the affected region lagged.¹⁹

These examples demonstrate mechanisms, not equal failure rates. They establish neither that all providers are interchangeable nor that switching providers is pointless. They show why supplier choice must be accompanied by an understanding of failure scope.

Ask what the fallback needs before it can do anything useful. Does it use the same identity service? Are its recovery codes available? Does a backup administrator need a mailbox at the failed provider to reset access? Are the files truly stored locally, or are they placeholders that download only when opened? Can the emergency phone system make a call without the collaboration service? Does the alternative's management portal depend on the same network gateway?

These are engineering questions. A second subscription cannot answer them by itself.

Google's SRE guidance explicitly warns against calculating the availability of redundant deployments as though their failures were automatically independent. Shared control planes, failure domains and other common dependencies can invalidate that arithmetic.²⁰

The same discipline applies to running systems locally. A local application can still require cloud authentication, externally held decryption keys, remote licensing, an internet connection or a hosted management service. Ownership of the machine answers a different question from whether it remains usable during a supplier failure.

8. A second environment and a substitute service

A consultancy can make a sensible choice to keep its internal work on one platform while using another for customer projects. During an outage in the customer environment, its own calendar, documents and coordination may remain available. That separation can create useful breathing room.

It does not automatically transfer the customer's service into the consultant's environment. A working internal document editor cannot recreate missing permissions, retrieve files that were never copied, receive the customer's email or reproduce the client's approval workflow.

Both statements can be true: the separation was valuable, and the business process still needs a continuity design.

This also explains the difference between choosing Google as the main provider and preparing Google as a fallback for another main provider. Google now documents Workspace offerings for business continuity, including cold-standby and hot-standby arrangements. Their existence is evidence that an alternative can be deliberately prepared; it is not evidence that every organisation with two accounts already has equivalent protection.²¹

For some firms, a second collaboration platform will be proportionate. For others, it adds operating burden without solving the most important failure. Synchronisation can create further dependencies. Two permission systems need administration. Users need training. Records created during an incident must be reconciled. The alternative may be unaffordable to keep ready at the necessary scale.

The decision should follow the critical task. If the immediate need is to contact ten clients, access a current obligations list and record decisions for a few hours, a protected offline information pack and an approved independent communication route may provide more useful capability than a lightly configured duplicate suite.

If the need is to sustain a large regulated workflow for several days, the requirements will be different. Capacity, data freshness, confidentiality, recordkeeping and recovery procedures then become central to the design.

Choose the alternative that can sustain the required work, and measure the effort needed to keep it ready.

9. In defence of the ordinary fallback

Telephone and fax are easy comic material in a cloud outage. The technology appears to have travelled backwards just as the organisation expected it to become invisible.

Age is a poor test of whether a fallback serves its purpose.

NIST's contingency-planning guidance includes temporary manual processing among the ways to continue disrupted business activities. That is recognition of a limited operating mode, not an endorsement of every improvised workaround.²²

A telephone call may preserve an essential conversation. A paper list may preserve the next day's obligations. A deliberately prepared manual queue may prevent urgent requests from being lost. The questions are whether the route is available, whether the participants can be verified, whether the process is permitted, whether the volume is manageable and whether its results can be reconciled afterwards.

A fax service delivered through the same failed cloud infrastructure would not solve the relevant dependency. Nor would an unapproved channel that creates a confidentiality or recordkeeping problem. The useful attribute is its ability to support the required task under the actual failure conditions.

The FCA's November 2026 observations make a similar distinction. It criticises reliance on manual workarounds where firms have not shown that they can operate at the required scale or duration. It also calls attention to evidence that communication can work when usual channels are unavailable. The concern is demonstrated capability.²³

During this Microsoft incident, NHS Essex announced a temporary telephone route for professional referrals and urgent patient-related enquiries while email services were disrupted. That is a concrete example of an alternative channel being put to work.²⁴

It is reasonable to expect modern institutions to invest in recovery. It is also reasonable for their emergency mode to look simpler than their normal mode. A fallback has earned its place when it preserves essential outcomes within acceptable limits.

The most embarrassing backup is the impressive one that nobody can activate.

10. The work that remains after the provider returns

Service restoration and business recovery do not necessarily happen at the same moment.

Suppose an organisation can sign in again at noon. There may still be delayed messages, duplicate requests, unfinished approvals, uncertain transaction states and records created through alternative routes. Staff need to establish which actions succeeded, which must be repeated and which must never be repeated.

That is why a continuity plan needs a return path. Starting an alternative workflow is only part of the task. The organisation must preserve enough evidence to reconcile work safely when normal service resumes.

It also needs to distinguish interruption from loss or corruption of information. Replication can improve availability while faithfully copying an erroneous change. A backup can preserve earlier data while taking too long to restore for the current deadline. An export may be readable while omitting the permissions or metadata needed to operate the process.

Useful questions therefore include:

• How much interruption can this business process tolerate before the consequences become unacceptable?
• Within that limit, how quickly must the system or minimum operating mode be restored?
• How old may the available information be, and how much unrecoverable recent work is acceptable?
• At what volume can the fallback operate, and for how long?
• Who decides to activate it, who acts as deputy, and who confirms reconciliation?

NIST's continuity framework distinguishes maximum tolerable downtime, recovery time objectives and recovery point objectives. Those concepts help business owners specify what the technical arrangements must accomplish.²⁵

For an outage, a recent export and a prepared alternate channel might be adequate. For suspected corruption, the same export may be unsafe to trust. For loss of contractual or legal access to a provider, waiting a few hours may not be a credible response. A single recovery diagram should not conceal these different scenarios.

The practical worksheet at the end of this volume turns those questions into a small exercise. The aim is to discover a real gap while there is still time to close it.

11. Sovereignty has an operating cost

Availability, security, recoverability and sovereignty are related, but none can be substituted for all the others.

Availability asks whether a defined function can be used when required. Recoverability asks whether information and operations can be restored after disruption. Security includes protecting the system and information against misuse or compromise. Sovereignty concerns the authority and practical capacity to govern dependencies, make changes and sustain credible alternatives.

A provider can perform exceptionally well in ordinary operation while creating jurisdictional or strategic constraints an institution considers unacceptable. A locally owned system can offer greater direct control while lacking the staff or resilience needed to meet its service obligations. These are possible combinations, not contradictions.

This is why a sovereignty argument does not need an exaggerated reliability claim. An organisation may rationally accept a different cost or operating model to obtain control it values. It should state the trade explicitly, fund the resulting responsibilities and measure the service it receives.

The reverse is equally important. A decision to outsource can be responsible when it improves the service the organisation can actually sustain. Retaining accountability then means understanding what was delegated, preserving access to essential information, and maintaining proportionate recovery and exit capabilities.

The Basel Committee's operational-resilience principles discuss third-party dependency management, continuity arrangements, exit strategies and practical substitutability, including the possibility of bringing a service in-house. These are operational capabilities to assess, not conclusions supplied by a provider's nationality.²⁶

The relevant decision is broader than whether to own a server. It includes who can approve a change, who can operate a replacement, where necessary information resides, which legal and technical dependencies remain, and whether the alternative can become usable within the time available.

That capability can be built internally, obtained through a competent managed provider, or divided between several arrangements. It will always require continuing attention. An exit plan becomes less useful if the staff, formats and procedures needed to execute it have disappeared.

The Library's earlier volumes on self-sufficiency and the Exit Test examine that strategic capacity. This volume adds a more immediate test: what useful work survives the next interruption?

12. Reliability can make us forget recovery

There is a final complication. Reliability can itself encourage overdependence.

Google's SRE book describes how its highly reliable Chubby service acquired dependent systems that effectively assumed it would never fail. Google introduced controlled outages to expose those assumptions. The example shows how long periods of success can allow recovery capability to decay even among sophisticated engineers.³

The lesson for an ordinary organisation is to exercise a limited fallback in a controlled setting. It is not a reason to surprise users by disabling production systems. An agreed tabletop scenario, followed by a carefully bounded practical test, can expose inaccessible credentials, obsolete contact lists, missing local files and undecided authority without manufacturing a crisis.

This changes the question asked after the next outage. There will still be reasons to investigate provider performance. There will still be legitimate debates about architecture, contracts, competition and sovereignty. A costly incident deserves a precise account of its causes and consequences.

Alongside those questions, the organisation can ask something within its own authority: which essential tasks did we preserve, which failed, and what will we change before the next event?

A capable provider can reduce the amount of infrastructure an organisation must operate. It cannot decide which obligations the organisation must honour during an interruption. It cannot make an untested fallback usable merely by returning to service. It cannot preserve a choice that the customer has allowed to disappear.

The reliability bargain is worth making when those remaining responsibilities are understood and funded. Buy strong everyday service. Keep the information, authority and practiced alternatives needed for the moments when it fails.

The useful measure is the work that can still be done.

Appendix: Can we keep working?

A continuity exercise for a small Swiss professional-services firm

Working sheet · 13 November 2026 · Suggested duration: 60–90 minutes

Firm/team: ____________________ Exercise date: ____________________

Business owner: ____________________ Facilitator: ____________________

Participants and deputies: __________________________________________________

The objective is to demonstrate which critical outcomes the firm can still deliver when its main collaboration or identity service is unavailable. Choose two or three processes. Examples include informing clients, checking existing commitments, accessing essential records and preparing time-sensitive work. Separate preparation from transactions or approvals that require unavailable controls.

The timings and fields below are proposed practice, not regulatory thresholds. FINMA identifies concentration in outsourced services as a source of simultaneous disruption. The FCA’s November 2026 observations emphasise evidence of working continuity arrangements and tested communication channels.¹⁶²³

1. Define what must continue

Complete this table before discussing products. “Email is down” describes a system; “we cannot notify clients about an urgent deadline” identifies a business consequence.

For each process, record:

• Impact tolerance: When does interruption cause unacceptable harm? Include missed commitments, affected clients, transaction values or volumes where relevant.
• Recovery time objective (RTO): How quickly should the required service be restored and validated? Allow time for assessment, activation and checking before the maximum tolerable interruption is reached.
• Recovery point objective (RPO): How much committed information could be lost after recovery, expressed as a time interval where useful?
• Fallback freshness: How old may the accessible copy be? A stale client-contact list and a stale portfolio position have different consequences. This is a separate question from recoverable data loss.

Accepted degraded capacity: ______ cases / hour, for ______ hours, with ______ people.

Activities that must pause: __________________________________________________

2. Run the tabletop

For a 60-minute session, shorten the scenario discussion; retain the access demonstration and recovery review. Do not present an optimistic provider recovery estimate as evidence that the firm can continue.

3. Trace the whole fallback path

For every proposed alternative, answer “Can we use it if the main provider’s login fails?” Record evidence, not just a supplier name.

An independent backup copy provides recovery material; it does not establish that staff can use it within the required time. A second SaaS application may still depend on the original identity service, device management or a shared network component.

4. Change the scenario before choosing the response

Do not improvise transaction approvals, share credentials or move confidential material into personal accounts. Log requests, decisions, timestamps, responsible people and confirmations in the approved fallback record. Define how records will be retained and reconciled with the primary system.

NIST recognises temporary manual processing as a continuity option. The FCA cautions that manual workarounds need evidence of sufficient capacity and endurance.²³²²

5. Optional bounded access drill

Use a designated test device or account and a small, approved set of non-sensitive test records. Simulate the primary service’s absence by following an exercise rule that prohibits using it. This demonstrates the workflow, but does not by itself prove technical independence. Separately verify authentication and data paths, including a fresh authorised sign-in and session-renewal requirements. Record dependencies that remain untested. Do not disable production identity, alter live DNS, revoke real access or interrupt working services.

Ask a deputy to locate the instructions, access the fallback through its authorised route, open the test records and record a mock request. Then restore normal exercise conditions and reconcile that request into a test log. Note every dependency that required the facilitator’s help. A discussion-only result remains an assumption until demonstrated.

Record elapsed activation time, usable records versus required records, data age, successful authorised sign-ins, requests processed, missing audit entries and reconciliation time. The business owner should compare these results with the chosen process requirements, rather than an external benchmark.

6. Decide what investment is justified

A protected offline pack may be sufficient when a small, relatively stable set of records supports an acceptable temporary service and staff can securely maintain it. Provider diversification becomes more attractive when the business needs live collaboration, sustained transaction capacity or recovery within a time that the simpler fallback cannot achieve.

Before buying another platform, establish its independence, data currency, access controls, operating cost and reconciliation burden. Test whether the team can operate both arrangements. Basel’s resilience principles support assessing practical substitutes and exit arrangements for critical third parties.²⁶

Demonstrated capability: __________________________________________________

Assumptions still untested: ________________________________________________

Actions / owners / dates: __________________________________________________

Residual risk accepted by / review date: ____________________________________

Research note

Research completed on 13 November 2026 using provider incident reports and agreements, Uptime Institute research, NIST guidance, and Swiss and UK financial-sector supervisory material. Technical incident examples illustrate failure mechanisms; they do not form a comparative provider leaderboard. The 2026 Uptime annual analysis was reviewed through its public summary, not its gated full report. No universal cloud-versus-self-managed availability multiplier was established.

The Microsoft incident description is a dated interim snapshot. Microsoft has said it will publish a full post-incident report once mitigation is complete; that report, not this snapshot, will be the authority on the incident's duration and cause.¹ This volume contains no claim that every user or feature failed throughout the incident window. Calculations and synthetic figures are identified as such.

Related reading in the Library

• The Exit Test: the practical ability to leave a dependency.
• Sovereignty Is Not Self-Sufficiency: governing dependence while retaining agency.
• The first ten minutes of a supplier outage: the existing brief on what to do first when a supplier fails.

Sources

Sources were checked on 13 November 2026. Each numbered note carries its source ID (S01–S28).

Listed in the author’s source register but not cited in the text: S03 (Reuters, Hours-long Microsoft outage disrupts businesses governments globally, 12-13 November 2026, developing story, www.reuters.com); S16 (Google Cloud, 14 December 2020 authentication incident report, Report 18 December; correction 22 December 2020, status.cloud.google.com).