Has the Applicant experienced any partial or total network interruption lasting more than 8 hours?
This one is not about attacks. It asks how your business behaves when systems are unavailable, whatever the cause.
What the carrier is actually asking
The carrier is asking whether you have experienced a partial or total network interruption beyond a threshold, commonly eight hours, in the stated period. Cause is usually not limited: hardware failure, a provider outage, a failed change, or an attack all count.
Why it is underwritten
Business interruption cover is priced on how long you go down and what that costs. A history of extended outages, whatever the cause, indicates fragility that will apply equally in a cyber event. It also gives the underwriter a real data point about your resilience, rather than a plan.
Where the answer lives in Microsoft 365, Entra ID, and Azure
Outage history comes from operational records, so this is attested. The cloud estate can show availability configuration that supports whichever answer you give.
| Platform | Where the setting lives | What has to be true |
|---|---|---|
| Operations records | Incident and outage log for the period, with durations | Actual durations, including partial outages affecting a business unit. Attested |
| Provider records | Cloud and telecommunications provider outage notifications | Third-party outages that affected you, which count and are often forgotten |
| Azure | Availability zone and region design for critical workloads | Redundancy configuration, which is the forward-looking part of the answer |
| Network | Redundant connectivity at critical sites | Single points of failure identified, since a single circuit is the most common cause of a long site outage |
| Post-incident reviews | What was changed after each extended outage | Remediation, which turns a disclosed outage into evidence of learning |
An outage disclosed alongside what caused it and what changed afterwards reads as operational maturity. The same outage disclosed bare invites the underwriter to assume it could happen again tomorrow.
What a defensible yes requires
- The answer comes from operational records rather than memory.
- Partial outages affecting significant business functions are included.
- Provider-caused outages are included.
- Each disclosed outage has a cause and a remediation.
- Known single points of failure are identified, whether or not they have failed yet.
How this answer goes wrong
Only attack-related events are considered, so a two-day outage caused by a failed storage upgrade is omitted. The question does not usually limit cause, and that outage is exactly the resilience signal the underwriter is looking for.
Frequently asked
Does a planned outage count?
Usually not, if it was scheduled and communicated. A planned change that overran badly is a different matter and is worth disclosing with the explanation.
Does a provider outage count?
Yes, and it is worth disclosing with what you have changed since. Dependency on a single provider is a real exposure and carriers understand it.
Will disclosure raise our premium?
It can affect the business interruption terms. It also lets the carrier structure cover that matches your actual risk, which is the point of the exercise.
What if we cannot reconstruct the history?
Say what you can establish and how you established it. A qualified answer is defensible; an unqualified no that records contradict is not.
Related questions
Stop answering this from memory
Connect Microsoft 365, Entra ID, and Azure read-only. Insurance Posture reads the live configuration behind each application answer and shows you which ones you can prove before you sign.
Assess your posture