A cloud or SaaS service can stop sales, payments, customer service, and payroll in one afternoon.
The hard part is this: the loss you feel is not always the loss your policy covers.
A short Azure or AWS outage, a SaaS supplier failure, a misconfiguration, ransomware, or client claims can all trigger different responses.
A cloud or SaaS failure is not automatically covered by cyber insurance in the UK.
Whether a policy responds depends on the wording, the trigger, and the cause of the loss.
That cause may be a cyber event, a third-party service failure, or a plain technical fault.
The key is to compare cyber, business interruption, E&O, and parametric cover side by side.
What actually decides cloud outage cover?
Cloud exclusions usually turn on one thing: the cause of the downtime.
If the policy needs a security failure or system failure, a plain SaaS outage may not fit.
You usually need proof of ransomware, unauthorised access, or another attack that brought the service down.
The first thing to check is the trigger.
Some wordings cover loss from a cyber event only.
Others add contingent business interruption, which is cover for disruption caused by a third party you rely on.
That matters for England-based SMEs using payment tools, booking platforms, or cloud accounting.
A SaaS outage is usually covered only when the policy links it to a defined insured event, such as ransomware, malicious intrusion, or a named system failure trigger.
Which wording words matter most?
The wording words that matter most are the ones that define the trigger and the exclusions.
Look for network interruption, system failure, security failure, non-damage business interruption, and third-party dependency.
Those words show whether the insurer may pay for lost trading time.
You should also check for exclusions that mention hosted services, cloud platforms, service providers, utility supply, or scheduled maintenance.
If the wording says the loss must come from a cyber event, a simple availability issue may be left outside cover.
Your whole business can stop, but the policy may still say no.
Proof of cause matters because the insurer usually wants evidence that the outage came from something covered.
If the provider says “service disruption” but you cannot show attack logs or forensic findings, the claim can be pushed back or refused.
That is one reason records matter from the first hour.
According to the National Cyber Security Centre, good incident records help when you need to reconstruct what happened after a cyber event.
For claims, that means timestamps, provider status pages, support tickets, and any forensic note should be saved straight away.
NCSC incident management guidance explains that approach clearly.
The wording details matter as much as the headline cover.
Look for the insuring clause to see whether it covers hosted services, third-party service failure, or only your own network.
Then check whether system failure is broad enough to include configuration errors, software crashes, and cloud instability.
A waiting period can also change the result.
If the policy only starts after 12 hours, a short AWS or Azure outage may never trigger payment.
It is also worth checking whether the wording excludes maintenance windows, degradation, capacity shortfall, or failures by a named service provider.
In many UK policies, one sentence decides the claim.
The mistake is often hiding in plain sight.
Which policy usually responds in each outage scenario?
The right policy depends on what caused the outage and who is claiming.
Cyber insurance often responds first for a cyber incident.
E&O may respond when your client says you failed to deliver.
Property business interruption may help only in narrow cases.
Parametric cover pays when a pre-set outage threshold is met.
| Scenario |
Most likely policy type |
Typical trigger |
Common exclusion risk |
Practical chance of pay-out |
| AWS or Azure outage with no cyber attack found |
Parametric or contingent business interruption |
Measured outage duration or named third-party failure |
No cyber event, provider maintenance, external service exclusion |
Low to medium unless wording is broad |
| SaaS vendor hacked and service stops |
Cyber insurance |
Security failure, malware, ransomware, unauthorised access |
Third-party system exclusion, waiting period, no interruption extension |
Medium to high if the wording matches the event |
| Your team misconfigures cloud settings |
Cyber insurance or E&O |
Accidental error, negligent act, system failure |
Intentional act exclusion, poor change control exclusion |
Medium, but wording must include human error |
| Client sues for SLA breach or lost income |
E&O |
Failure to perform, service promise not met |
Contractual liability, penalty clauses, pure financial loss limits |
Often better than cyber, if the contract wording fits |
A useful rule is simple: ask which policy answers the first loss.
Cyber insurance usually responds when there is a defined security failure, malicious intrusion, ransomware, or another covered cyber event.
E&O insurance is more likely to respond when a customer alleges failure to perform, missed SLA commitments, or negligent service delivery.
Property BI is often narrower in the UK for cloud events.
It may require physical damage or a specific non-damage business interruption extension.
Parametric cover sits apart again, because it pays when a pre-agreed trigger is met.
That could be a three-hour outage on a named platform.
In practice, many SMEs need to know which policy pays lost profit, which pays defence costs, and which does not respond at all.
A short outage can also create a client claim.
That split is why dual review matters.
Does AWS or azure downtime fit cyber cover?
AWS or Azure downtime fits cyber cover only if the outage followed a covered security event.
It can also fit if the wording expressly includes third-party failure.
A bare service outage, with no malware, attack, or intrusion found, is often treated as a service issue.
This is where contingent business interruption becomes useful.
It is cover for your loss when a supplier, platform, or outsourced host fails.
The extension is not automatic.
Many SMEs do not have it.
E&O may beat cyber insurance when the loss becomes a client dispute.
If your customer says you missed a service level agreement, failed to deliver a booking system, or caused downstream loss of income, the claim can look like negligence.
That matters more than the cloud outage itself.
A short outage can lead to a client claiming lost sales.
The cyber insurer may point to the absence of a covered security event.
The E&O policy may carry the defence or settlement, subject to contract exclusions.
That split is common.
A useful way to read a policy is to ask which cover answers the first loss.
Cyber insurance usually responds when there is a defined security failure, malicious intrusion, ransomware, or another covered cyber event.
E&O insurance is more likely to respond when a customer alleges failure to perform, missed SLA commitments, or negligent service delivery.
Property BI is often much narrower in the UK for cloud events.
Parametric cover pays when a pre-agreed trigger is met, such as a three-hour outage on a named platform.
The practical test is this: read the trigger before you read the price.
That simple order often saves a bad surprise later.
A cheaper policy that never pays is not cheap.
How exclusions change the result in real claims
Exclusions change the result because they draw the line between a paid loss and an uninsured one.
If the wording excludes third-party outages, maintenance windows, wear and tear, or faults without a cyber event, the insurer can refuse even when your whole business stopped trading.
That is harsh, but it is common.
The most common mistake is to read the schedule and ignore the exclusions page.
The schedule may look broad.
The exclusions can quietly remove cloud provider failure, hosting disruption, or interruption without a verified cyber cause.
Which exclusions are red flags?
The main red flags are exclusions for external service failure, infrastructure failure, planned maintenance, and lack of available capacity.
If you see wording that says the insurer will not pay for “unavailability” or “degradation” unless caused by a covered cyber event, the policy is narrower than it first appears.
That wording often catches buyers out.
You should also watch for exclusions that remove cover for consequential loss unless there is direct loss from the cyber incident.
That sounds technical.
It simply means the insurer may not pay your lost sales unless the policy ties them tightly to a covered trigger.
A case like this comes up often.
A retailer loses three hours of online orders after a cloud platform outage, but there is no attack log.
The insurer treats it as a supplier failure, not a cyber event.
The claim stalls unless there is contingent business interruption or a broad non-damage extension.
This works in theory, but in practice the proof hurdle is what kills many claims.
If the provider will only say “service disruption”, the insurer may ask for more.
That can leave the SME stuck between the two.
What to check before you buy or claim
Before you buy or claim, check the exact words that define the trigger, the exclusions, the waiting period, and the sub-limits.
If the policy needs a cyber event, a network interruption, or a security failure, make sure your main SaaS risk can pass that test.
Do not assume the broker’s summary is enough.
Here is a short checklist you can use when reviewing a wording in England:
- Check whether the trigger is a security failure, system failure, or simple outage.
- Check whether third-party cloud or SaaS providers are named or excluded.
- Check whether losses from SLA breach, lost profit, and refunds are covered.
- Check the waiting period, because some policies only start after 8, 12, or 24 hours.
- Check whether manual workarounds and extra staff costs are included.
- Check whether the policy needs forensic proof before business interruption pays.
If your business depends on one or two cloud tools to trade, do not buy on the basis of the premium alone.
Ask the broker to show you, in writing, exactly which outage scenarios are covered and which are not.
That written answer matters more than a sales call.
Cloud outage exclusions: does your policy cover SaaS downtime? If you cannot answer that from the wording alone, ask for the exact trigger clause and the full exclusions list before you renew or claim.
If your business relies on cloud tools to trade, do not wait for a renewal date to test the wording.
Ask your broker for the exact outage clauses, compare cyber, E&O, business interruption, and parametric cover side by side, and get the insurer’s position in writing before you assume you are safe.
When an outage hits your own customers, the claim can move beyond your internal loss and into contract exposure.
If your SaaS tool goes down and clients cannot trade, they may seek refunds, service credits, or compensation for lost revenue under SLAs.
That is often where E&O insurance becomes relevant.
The claim is then about failure to deliver, not only downtime.
Businesses that sell critical software or payment tools should also think about downstream claims.
A single third-party service failure can create both a trading loss and a liability dispute.
That is why one policy is rarely enough on its own.
The best choice is the one that matches your real exposure, not the one with the broadest headline.
If you depend on AWS, Azure, or a single SaaS platform, the wording has to say so clearly.
If it does not, the insurer may still say no.
Which cover should you choose?
Cloud downtime is not one risk, and that is the trap.
A cyber policy may pay for a hacked SaaS platform.
E&O may carry a client claim.
Business interruption may help only with the right extension.
Parametric cover may pay when the outage lasts long enough.
Cyber insurance
Cyber insurance is the best fit when the outage follows a real cyber event.
That includes malware, ransomware, unauthorised access, or a covered system failure.
It is weaker when the outage is only a supplier lapse or a platform problem.
Pros
It can cover incident response, recovery costs, and some business interruption loss.
It also fits claims where there is a clear cyber trigger.
That makes it a good first check for hacked SaaS or cloud compromise.
Contras
It often fails when the outage is just availability loss.
Many policies still need a security event or system failure.
That leaves plain provider downtime outside cover.
Para quién es
It suits SMEs that face hacking risk, data loss, or malicious access.
It also fits firms with cloud tools that hold customer data or payment flows.
If that is your main fear, start here.
Para quién NO es
It is not the best fit if your main risk is supplier downtime with no attack.
It is also weak if you need cover for SLA claims from clients.
If that is your main pain, look wider.
Elige esto si: your main fear is a hacked cloud or SaaS platform.
E&O insurance
E&O insurance fits when the cloud outage turns into a client complaint.
If a customer says you failed to deliver a service, missed an SLA, or caused loss, E&O may answer better.
That is especially true for software firms, agencies, and managed service providers.
Pros
It can respond to claims about service failure and missed promises.
It may also help with defence costs.
That matters when the dispute is contractual rather than technical.
Contras
It may exclude penalties, pure contractual fines, or liabilities you accepted in a contract.
It is not a full substitute for cyber cover.
It also does little for your own lost trading income.
Para quién es
It suits firms that sell software, support, hosting, or managed services.
It also suits businesses that can be sued by clients for poor delivery.
If client claims worry you, this is the one to test first.
Para quién NO es
It is not ideal if your main problem is your own downtime and lost sales.
It is also weak for direct recovery after a cyber attack.
If you just want help after a hack, cyber cover is still needed.
Elige esto si: your biggest risk is a client claiming you let them down.
Parametric cover
Parametric cover pays when a set trigger happens.
That trigger may be a named platform outage lasting a fixed time.
It does not need the same proof of fault as a standard claim.
Pros
It can pay faster than traditional cover.
It also avoids some arguments about who caused the outage.
That can help when AWS, Azure, or another platform fails without a clear cyber event.
Contras
It only pays if the trigger is written well.
If the outage misses the threshold by minutes, you may get nothing.
It can also pay less than the real loss.
Para quién es
It suits firms that depend on one platform and can define outage risk clearly.
It works best when downtime is frequent and measurable.
It is useful when speed matters more than full indemnity.
Para quién NO es
It is not ideal if your losses are hard to measure.
It is also weak if the trigger is too narrow.
If your risk is broad and messy, this may disappoint.
Elige esto si: you want fast pay-out for a clearly measured outage.
Contingent business interruption
Contingent business interruption helps when a supplier or platform fails and you lose income.
It is the right idea for cloud and SaaS reliance.
The catch is that many policies limit it hard.
Pros
It matches third-party dependency more closely than standard property BI.
It can help when your cloud host or SaaS provider fails.
That makes it one of the most useful extensions for SMEs.
Contras
It is often capped, narrow, or buried in the wording.
It may still need a named insured event or proof of a covered cause.
Many policies do not add it at all.
Para quién es
It suits firms that depend on a single cloud host, booking tool, or payment platform.
It is also useful for businesses with low tolerance for downtime.
If your revenue stops when the platform stops, check this first.
Para quién NO es
It is not enough if the policy excludes third-party failures outright.
It also may not help with client liability claims.
If that is your issue, you need more than BI.
Elige esto si: your trading income depends on a third-party cloud service.
The right cover depends on the cause.
That is the honest answer.
If you cannot tie the outage to the policy trigger, assume the claim is weak.
Which one usually wins in practice?
Cyber insurance usually wins first for attacks and malware.
E&O often wins when the fight is about service delivery.
Parametric cover wins when speed and certainty matter most.
Contingent business interruption wins when the wording actually includes third-party cloud failure.
The best choice is not the broadest brochure promise.
It is the wording that fits the way your business actually stops trading.
If that sounds unglamorous, that is because claims are decided on wording, not hope.
The key insight is simple.
If your loss came from a real cyber event, cyber cover may help.
If it came from a supplier outage, you need a third-party extension or parametric trigger.
If the complaint is from a client, E&O may be the better route.
If your policy does not name cloud or SaaS risk clearly, treat that as a warning.
This issue does not need a separate cover search if your business does not rely on cloud or SaaS to make money, if the outage caused no measurable financial loss, or if your policy already excludes third-party failures, scheduled maintenance, or downtime without a cyber event.
Common questions
Does cyber insurance cover cloud outages?
Cyber insurance covers cloud outages only when the outage is linked to a covered cyber event or a specific extension.
A simple provider failure, with no security incident proved, is often excluded.
If the wording needs a cyber trigger, pure downtime may fail the test.
Does insurance cover SaaS downtime?
It can, but only if the wording includes downtime, system failure, or contingent business interruption.
Many standard policies do not pay for pure SaaS unavailability.
Check the trigger and the exclusions before you assume cover.
What is excluded from cyber insurance?
Common exclusions include planned maintenance, third-party service failure, contract penalties, and outages without a covered cyber trigger.
The exact list depends on the wording.
A policy can look broad and still miss your real risk.
What should I do right after a provider outage?
Save the status page, screenshots, emails, tickets, and any logs straight away.
Those records help prove cause, which can matter more than the length of the outage.
If you wait, proof can vanish.
Is parametric cover better for repeated downtime?
It can be, because it pays when a set trigger is met, such as four hours of outage.
It does not need you to prove fault, but the trigger must match your risk closely.
If the trigger is wrong, the cover is weak.
Can I claim if my client loses money because my SaaS was down?
Maybe, but that is often an E&O issue rather than a cyber issue.
If the client claim is based on SLA breach or failure to deliver, the E&O wording may respond better.
The contract wording matters a lot here.
Which regulator or body should I look at for guidance in the UK?
The Financial Conduct Authority, the NCSC, and the ICO are the main bodies worth checking for guidance in the UK.
For data handling, UK GDPR and the Data Protection Act 2018 still matter if the outage involved personal data.
That is especially true after a breach.
