There is a very good reason banks worry about concentration risk. One supplier can make everything fit together beautifully. Then something goes wrong, and several parts of your business stop working together.
That is the question the Microsoft outage puts in front of us. Not simply, "When will my email come back?" but, "How much of my company have I put behind the same door?"
When I was working on building a bank, these were the sorts of questions we had to take seriously. What happens when a supplier fails? What can we still do? How long have we got before customers are harmed?
It can look like paperwork until the day you need it. Then it becomes the difference between an inconvenient morning and a business that cannot function.
First, what Microsoft has actually said
In its public update at 12:58:36 UTC on 13 November 2026, Microsoft reported continuing recovery across affected regions, with intermittent access issues and email delays still possible. It described problems with Exchange Online and dependent features across several Microsoft 365 services. It said it had no evidence of malicious activity and would publish a post-incident report after mitigation.
That is not the same as every Microsoft service being down. Microsoft said most core Teams calling, meetings and messaging remained functional, as did direct access to SharePoint files. Its public Azure panel reported no detected Azure issues at the time checked. These are provider-reported status statements, not a guarantee about every customer's experience. Microsoft service health.
So I am not going to guess whether this was DNS, a certificate, a deployment or something else. Nor does an outage, by itself, prove Microsoft had no redundancy or failed to follow a particular rule.
We can leave the final technical explanation to the incident report and still learn something important from the disruption.
The risk is what fails together
Think about it. Your email, calendar, files, meeting arrangements and AI assistant might look like separate tools. But if several depend on the same underlying service, you have not really bought five independent ways of working.
You have bought useful integration, along with a shared dependency.
That is what I mean by concentration risk here: one failure can interrupt several things you rely on. It is not necessarily one server in one building. It can be a shared service, identity system, control system or supplier further down the chain.
Consider an illustrative example. You buy an application from another company, but sign in through the same identity provider as your main office suite. If that sign-in route fails, can you still use the supposedly independent application? What if your recovery instructions and emergency contacts sit behind it too?
Different invoices are not necessarily different failure points.
The regulators have been asking this already
The PRA's SS2/21 explicitly addresses concentration and vendor lock-in: repeated reliance on the same or connected providers, shared subcontractors, difficult-to-replace services and geographical concentration. The current version is November 2024; the March 2026 update takes effect in March 2027. SS2/21, especially paragraph 5.24.
For firms within its operational-resilience rules, the FCA required mapping and testing by 31 March 2025 so important business services could operate within their impact tolerances. That means identifying services whose disruption could cause intolerable harm and setting the maximum disruption they can tolerate. FCA operational resilience.
Notice the starting point. It is the service your customer needs, not whether a particular office application is available.
Can somebody make an urgent payment? Can they reach you? Can your team access the information needed to help them? That is the business conversation I would want to have.
There is also direct oversight of designated critical third parties. Since 13 July 2026, the FCA lists Amazon Web Services EMEA SARL, Google Cloud EMEA Limited, Microsoft Ireland Operations Limited and Oracle Corporation UK Limited. Oversight targets systemic services, not every activity of those businesses, and does not replace a financial firm's own responsibilities. FCA critical-third-party regime.
Being important enough to regulate does not make a supplier impossible to interrupt.
Being small is not a blanket opt-out
I know the practical problem. If you are building a small bank, you cannot expect a global technology company to rewrite its entire contract for you.
But SS2/21 says that if a material outsourcing provider cannot or will not contractually support compliance, the firm should make the PRA aware. It allows proportionate choices: its core-banking cloud example permits a non-significant firm a less resilient but still robust option. That is not a blanket small-bank exemption. Paragraphs 6.5 and 10.5-10.7.
The FCA likewise says the approach should reflect the nature, scale and complexity of the firm. Responsibility for the relevant regulatory obligations cannot be delegated to a supplier. FCA outsourcing guidance.
For me, the useful question is: what have we accepted, what have we done about it, and who has signed off the remaining risk?
Three clouds are not automatically the answer
The PRA does not prescribe one cloud-resilience recipe or preferred form of stressed exit. Options include different regions, hybrid arrangements, backup vendors or bringing services in-house. Continuity and exit plans need testing. SS2/21, chapter 10.
The NCSC also warns that multi-cloud has security implications and ineffective failover can reduce availability. It generally recommends using multiple data centres or regions within a single service where possible. NCSC cloud resilience guidance.
That is an important counterweight to "just use Microsoft, Google and AWS". More suppliers mean more systems to secure, maintain and understand. A second region might address a local outage without addressing a shared service failure. A second provider might address some supplier risks without fixing a common login dependency.
Government cloud guidance makes the trade-off explicit: integration can bring real value, while portability and switching can involve substantial engineering and cost. It recommends managing that balance, not pretending all lock-in can disappear. Managing technical lock-in.
I would rather see a modest fallback that has actually worked in a test than an impressive multi-cloud diagram nobody knows how to operate.
UK control matters. A UK postcode is not enough.
I do think Britain should have stronger domestic options for hosting, email and AI. I want us to have choices about where important parts of our businesses run.
But physical location, legal jurisdiction, ownership and operational control need separate questions. The NCSC notes that data can sit in a local region while the authentication service is replicated worldwide. A local address is not the whole dependency map. NCSC location and jurisdiction guidance.
Proton Mail, for example, is Swiss-based, not a UK-sovereign email service. Proton's own description.
It might be a candidate for a different supplier strategy, but that still needs assessment of the features, records, support and controls your business requires. Moving everything into another single supplier could simply move the concentration.
And a copy of your old emails is not a replacement for sending and receiving new ones. I would want tested access to essential records, a separate way to contact people and a clear plan for operating during an interruption. Not a hurried change to email routing while everybody is already under pressure.
Our agents should have an approved alternative too
This is where I think agentic systems could help us build a more flexible way of working.
I would separate three things: the model doing the reasoning; the agent workspace organising tasks, tools and permissions; and the company data and services it uses. The workspace is often called the harness. It is the environment around the model, not the model itself.
My proposed design is to control that workspace locally or through an independently operated host, keep business records recoverable, and let an approved routing layer choose between tested models. If the normal model service is unavailable, we should have a defined alternative, not a frantic search for somewhere else to paste company information.
There are existing building blocks. OpenHands documents both provider-connected models and local model servers. That demonstrates a configuration option, not proof of seamless, safe failover or suitability for a regulated business. OpenHands model documentation.
I am not saying every commercial agent application lets you swap its model. Open-source software can give you more control over the design, but somebody still has to secure it, maintain it and prove recovery works.
The approved backup might be a different hosted service or a locally run model with a narrower job. Perhaps it can still search an available document collection or draft something for review. It may not be allowed to send messages or change records.
A different model also means different behaviour. I would test the task, tool use, privacy terms, capacity and failure handling beforehand. If an action times out, check whether it happened before trying again. Sending the same payment or email twice is not a successful recovery.
And if no approved route is suitable, the agent should stop and hand the problem back. "I cannot safely do this right now" is a useful capability.
Useful models, not a competition over parameter counts
Mistral's published Ministral 3 family includes 3-billion, 8-billion and 14-billion-parameter models for local and edge uses, under Apache 2.0. Those are actual examples, not a claim that any laptop can run every configuration or match a frontier hosted service. Mistral's announcement.
Cosine's Lumen Sovereign is a different case: its current page describes a planned model, with a commercial-launch milestone in Q1 2027. It should not be listed as a generally available fallback today. Cosine's roadmap.
I care much more about whether the backup can do the particular job safely than whether its parameter count sounds impressive. Nor should we invent sizes for proprietary models whose developers have not disclosed them.
A local harness calling an external model is also not an entirely local AI system. And a working model cannot read an unavailable mailbox. The whole pathway has to work.
A small business does not need to build a second bank
Most small companies cannot afford to duplicate everything. Fair enough. Start with the work that must continue, rather than trying to copy the whole office.
I would begin with securely held contact details, recoverable copies of essential records, a pre-arranged independent communication route, and one short exercise: assume the main supplier is unavailable and try to carry out a critical task.
Do the people involved know where to go? Can they sign in without the failed system? Are the records current enough? Who tells customers what is happening?
For a board, I would put six questions on the table:
- What must keep working? Name the customer service, not just the application.
- What fails together? Include identity, networking, hosting and suppliers behind suppliers.
- How long can we tolerate disruption? Set a business limit and understand the harm beyond it.
- What is the minimum workable fallback? Include manual arrangements where they are realistic.
- Who can activate it? Give somebody clear authority and usable instructions.
- When did we last prove it? Ask for the result, the gaps and the owner of the fixes.
Keep that in the operational-risk register and make the plan accessible when the normal tools are not. Do not confuse a recovery-time target with proof that you can meet it.
Convenience is valuable. So is being able to continue.
This is not an argument that Microsoft is uniquely unreliable, or that every company should abandon it. It is an argument against treating the size of a supplier as your own continuity plan.
The bigger opportunity, including for UK technology businesses, is to make practical alternatives easier to use: independent communications, recoverable data, locally controlled workspaces and models we have already approved for the jobs we need.
Once urgent responsibilities are covered, perhaps go outside and touch grass while the engineers work on the outage. But when everything comes back, ask the question.
Next time this supplier stops, what can we still do?
Related thinking: What If the US Switched Off Britain's AI? and My Next Operating System Might Be an Agent.
Sources and notes
Evidence checked on 13 November 2026. Incident details reflect Microsoft's 12:58:36 UTC update, not a concluded root-cause report. Regulatory requirements depend on the firm and arrangement; this is not legal advice. The resilience architecture and practical questions are proposals. Vendor model documentation and future roadmaps are not reliability guarantees.
- Microsoft service health status.
- PRA SS2/21: Outsourcing and third party risk management, current November 2024 version.
- FCA: Operational resilience.
- FCA: Critical Third Parties, Strengthening UK Financial Services.
- FCA: Outsourcing and operational resilience.
- NCSC Cloud Security Principle 2: Asset protection and resilience.
- GDS and CDDO: Managing technical lock-in in the cloud.
- Proton Mail: Security features.
- OpenHands: LLM overview in official documentation repository.
- Mistral AI: Introducing Mistral 3.
- Cosine: Lumen Sovereign.