Is downtime at the wrong time keeping directors awake? Does a data breach expose the business to fines, notification costs and lost customers? This guide resolves the central question for subscription-based and SaaS businesses in England: how to decide between insuring downtime (loss of availability and lost recurring revenue) and insuring data breaches (privacy, notification, forensic costs and regulatory fines). It explains how these covers differ, how insurers define triggers, how to quantify losses for subscription models and what policy clauses commonly create gaps for SaaS firms.
Key takeaways: what to know in one minute
- Downtime cover protects revenue and SLA losses for subscription businesses by indemnifying lost MRR/ARR and extra costs to restore service; it does not usually pay GDPR fines.
- Data breach cover focuses on confidentiality and regulatory response: forensic, notification, legal costs, PR and potential privacy liability – not the same as indemnifying downtime.
- Policy wording matters more than premium: triggers (technology failure vs security breach), waiting periods, retroactive dates and contingent BI clauses change whether an outage caused by a cloud provider is covered.
- Quantify MRR impact using clear formulas: insurers expect evidence of actual lost recurring revenue, churn uplift and mitigation costs; illustrative models help underwriting and claims.
- SaaS firms may need both covers or a combined cyber policy with explicit contingent business interruption and cyber business interruption limits; excesses and sub-limits can materially change protection.
Is downtime cover worth it for UK SaaS?
For many UK subscription businesses, the question is pragmatic: will the insurer pay for lost recurring revenue and SLA penalties when systems are down? The answer depends on policy wording and the incident cause.
- What downtime cover typically pays: indemnity for lost gross profit or forecasted lost recurring revenue for the period of restoration, costs to procure temporary capacity (cloud failover), fees to honour SLA credits, and extra customer support costs.
- What it typically excludes: deliberate criminal acts by insured staff, contractual disputes, pre-existing defects, and in many policies loss caused by a third-party cloud provider unless contingent BI is included.
For a small SaaS with 20 employees and predictable MRR, even a single 24–72 hour outage can exceed several months of premium. When downtime impacts multiple customers simultaneously, reputational damage and churn may produce longer-term revenue hits insurers rarely indemnify unless supported by a BI calculation and documentary evidence.
Indicative scenarios (current at time of writing):
- Minor outage (4–8 hours): often covered under incident response services but not always triggering BI indemnity due to waiting periods.
- Major outage (24+ hours) with lost MRR: may trigger BI if policy wording includes cyber business interruption or contingent BI with supplier failure cover.
How to quantify subscription downtime: MRR, churn and LTV models
Insurers expect concrete calculations rather than high-level claims. Simple, defensible formulas make underwriting and claims faster.
- Baseline MRR method:
- Monthly MRR × downtime days in month ÷ days in month = immediate lost MRR
- Churn uplift method (captures revenue lost beyond outage)
- Estimated incremental churn rate × average customer lifetime value × number of affected customers = longer-term revenue loss estimate
- SLA penalty and remediation costs:
- Actual credits issued to customers + external costs to restore and reimburse (engineering overtime, temporary hosting)
Example: a SaaS with £25,000 MRR experiences a 3-day outage in a 31-day month.
- Immediate lost MRR = £25,000 × 3 ÷ 31 ≈ £2,419
- If churn uplift is estimated at 2% of customers with average LTV £1,200 and 250 customers: additional loss ≈ 0.02 × 250 × £1,200 = £6,000
- Total indicated loss ≈ £8,419 plus SLA credits and extra costs.
Keep records: uptime logs, status page timestamps, customer billing ledger, engineering incident reports and customer communications. These form the evidential base insurers require.
Data breach cover vs business interruption for microbusinesses
Microbusinesses (1–10 people) often confuse privacy liability with business interruption. Practical distinctions:
- Data breach cover (privacy/data breach response) typically pays for: digital forensic investigations, legal advice on notifications, regulatory communication, credit monitoring for affected individuals, public relations and defence costs in privacy claims.
- Business interruption (BI) cover for cyber/downtime pays for: lost gross profit, increased operational costs to maintain service, and sometimes contractual penalties or SLA credits.
For microbusinesses where founders are also operators, a severe data breach can cause both types of losses: immediate interruption while systems are contained, plus regulatory and remediation costs. Many insurers offer combined cyber policies, but microbusinesses should note sublimits apply: e.g., £100,000 for privacy response, £250,000 for BI. These may be insufficient where MRR is high or GDPR fines are probable.
Regulatory context: the Information Commissioner's Office (ICO) provides guidance on breach reporting and potential fines; insurers often exclude fines resulting from deliberate illegal acts and may cap coverage for regulatory penalties. See ICO for reporting thresholds and guidance.
How GDPR fines influence cyber cover limits?
GDPR fines can be material for SMEs handling sensitive personal data. Key points:
- Most UK cyber insurance policies do not cover regulatory fines or penalties imposed for wilful or criminal acts; coverage for statutory fines varies and is often limited or excluded. Insurers commonly cover the costs of responding to regulators (legal defence, notifications) rather than the fine itself.
- The ICO has discretion in issuing fines; many recent enforcement actions focus on failure to secure data or to implement adequate controls. That increases the frequency of claims where insurers will scrutinise the insured's security posture at inception.
- Insured limits should reflect potential regulatory exposure: for some SaaS firms that process special category data (e.g., health), consider higher limits for response and legal defence rather than assuming fines will be paid by insurer.
Practical step: include a clause in procurement and customer contracts that allocates responsibilities for regulatory responses and establishes clear liabilities with sub-processors and cloud vendors. Guidance from HM Government and the NCSC can support defence positions; link examples: HM Government, NCSC.
Ransomware response cover or downtime indemnity: which?
Ransomware incidents illustrate the divergence between response cover and downtime indemnity.
- Ransomware response cover (extortion and incident response) typically funds: forensic investigation, negotiated extortion payments (if covered), legal and PR expenses, and client notification. It is focused on security breach and extortion.
- Downtime indemnity is focused on availability losses—time systems are unavailable, replacement hosting, and lost revenue.
Which is more relevant depends on the incident. Ransomware that encrypts customer data and disrupts service may trigger both covers, but insurers often apply separate sub-limits and waiting periods.
Considerations for SaaS firms:
- Confirm whether ransom payments are covered and whether insurer approval is required before payment.
- Look for combined cover where extortion sub-limit and BI limit are not set so low they render cover ineffective.
Which policy exclusions leave SaaS firms exposed?
Common exclusions that create unexpected gaps for subscription businesses:
- Third-party cloud provider failures without a contingent business interruption clause. If AWS/GCP/ Azure has an outage, many policies will only respond if contingent BI is expressly included.
- Failure to patch or known vulnerabilities: insurers may deny claims if the vulnerability was known and unpatched at the time of underwriting or claim.
- Outages caused by code defects, poor change control or software bugs may be excluded unless policies include technology failure as a trigger.
- Contractual liability limitations: if customer contracts shift liability to the SaaS provider, insurers may limit cover for liquidated damages or contractual penalties unless explicit liability cover is purchased.
Helpful check: review policy definitions for terms like “failure of technology”, “security breach”, “system outage”, “supplier failure” and seek explicit wording for contingent business interruption and service provider failure.
Accept higher excess to cut SaaS cyber premiums?
A higher excess can reduce premium but increases retained risk. For many small SaaS businesses, this trade-off needs careful modelling.
- Use a break-even calculation: compare premium saving vs the probability-weighted cost of an outage you would have to self-fund.
- If the policy excess equals several days of MRR, contemplate whether the business can absorb that self-funded risk without jeopardising cashflow.
Example: a policy offers a £10,000 excess for BI. If monthly gross margin covers that for two months of planned buffer, higher excess may be acceptable. If the business cannot afford £10,000 unexpectedly, a lower excess may be prudent despite a higher premium.
How policy triggers work: outage vs security incident wording
Two common triggers determine whether an event is treated as a security incident or a technology failure:
- Security incident trigger: usually requires an unauthorised access, data breach, malware or malicious act. Triggers privacy response, extortion and liability elements.
- Technology failure trigger: covers unintended failures such as hardware faults, software defects or system misconfiguration. Triggers business interruption cover for loss of availability.
Insurers differ: some policies combine both under a single cyber policy; others segregate them with separate waiting periods. Read the policy schedule carefully and map it against likely incident types.
Aligning SLAs, cloud provider contracts and insurance
Insurance is part of a wider risk-transfer and resilience strategy. SaaS firms should align three documents:
- Customer SLAs: clearly defined uptime metrics and remedies.
- Contracts with cloud providers: SLAs, uptime credits, liability caps and evidence obligations.
- Insurance policy: explicit contingent BI or supplier failure extensions and proof-of-loss requirements.
If the cloud provider contract limits liability to service credits, insurers may expect that avenue to be exhausted before paying contingent BI. Ensure contract language supports transfer of risk and that indemnities are consistent.
Policy comparison: downtime cover vs data breach cover
| Feature |
Downtime (BI) |
Data breach (Privacy/Liability) |
| Primary trigger |
Loss of availability / technology failure |
Unauthorised access, data leak, malware |
| What it pays |
Lost gross profit, extra costs, SLA credits |
Forensics, notification, legal defence, PR |
| Common exclusions |
Supplier outages without contingent BI, code defects |
Regulatory fines (often excluded), wilful non-compliance |
| Typical sub-limits |
May be full BI limit or capped |
Often capped separately for notification/PR |
Downtime vs data breach: incident flow
🔍 **Detection** → 🛑 **Containment** → 🔧 **Remediation** → 📊 **Assessment** → 💷 **Claim/Response**
- 🔍 Detection: monitoring alerts, customer complaints.
- 🛑 Containment: isolate systems for breach; failover for downtime.
- 🔧 Remediation: forensics for breach; restore from backup for downtime.
- 📊 Assessment: quantify MRR loss and notification scope.
- 💷 Claim/Response: submit evidence to insurer; engage legal/PR if breach.
Strategic analysis: advantages, risks and common mistakes
Benefits / when to apply
- ✅ Buy downtime cover when MRR and SLA penalties are material and proof of loss can be produced quickly.
- ✅ Buy data breach cover if the business processes personal or sensitive data and regulatory exposure or notification costs could be significant.
- ✅ Consider combined cover or explicit contingent BI for third-party cloud outages in multi-tenant setups.
Errors to avoid / risks
- ⚠️ Assuming one policy covers everything—many standard cyber policies split or cap different exposures.
- ⚠️ Failing to check supplier failure wording—cloud outages are a common cause of unexpected denials.
- ⚠️ Under-quantifying longer-term churn effects—insurers prefer conservative, evidence-backed estimates rather than speculative future losses.
Frequently asked questions
What counts as lost revenue for SaaS BI claims?
Lost revenue is typically the lost gross profit attributable to subscription payments that would have been earned during the indemnity period; insurers expect billing and ledger evidence.
Can a cyber policy pay ICO fines in the UK?
Most policies exclude statutory fines for wilful or criminal conduct; some may cover limited regulatory defence costs but not the fine itself. Check policy wording.
Will an AWS outage be covered for my SaaS downtime?
Only if the policy includes contingent business interruption or supplier failure wording covering the relevant cloud provider; many standard policies exclude it.
Should microbusinesses buy both downtime and breach cover?
Microbusinesses often benefit from combined cyber policies with both BI and privacy response elements, but pay attention to sub-limits and waiting periods.
How long is the waiting period for downtime indemnity?
Waiting periods vary (commonly 8–72 hours); a short waiting period reduces uninsured exposure but increases premium.
Are ransom payments usually covered?
Some insurers offer extortion cover that can fund ransom payments subject to insurer approval and strict controls; coverage and limits differ widely.
How should SaaS firms document a claim?
Keep incident logs, uptime records, customer communications, billing reports, engineering timelines and costs; insurers will request these during claims assessment.
Your next step:
- Review current policy wording for triggers, contingent BI and sub-limits; flag any supplier failure exclusions.
- Build a simple MRR downtime model (monthly MRR × downtime days ÷ days in month) and estimate churn uplift to present to underwriters.
- Align SLA terms with cloud provider contracts and document runbooks, backups and incident logs to strengthen underwriting position.
