Early losses from the PHP2Shell vulnerabilities aren't from confirmed breaches but from organizations pulling systems offline as a precaution. Marsh Re's October report highlights that business interruption is the main loss driver, especially for online retailers relying on web access. Whether these losses are recoverable depends on policy wording, triggers, waiting periods, sublimits, and how precautionary shutdowns are treated.
This checklist is for coverage counsel and brokers reviewing a program before a voluntary shutdown becomes a disputed claim. Each item has a done/not-done state and a description of what good looks like.
Prerequisites
Before you start, gather:
- The full policy form, all Cyber Endorsements, and any manuscript wording
- The most recent Underwriting Questionnaire and any Application Fraud Warranty language
- Your client's asset inventory, including appliances and embedded software
- The incident response plan and shutdown decision authority matrix
Checklist
1. Locate the Business Interruption Coverage trigger. Identify whether coverage responds to a security failure, a system failure, or both, and quote the exact trigger language. A written summary of what event must occur before the clock starts is essential.
2. Determine whether a voluntary shutdown can satisfy that trigger. Confirm in writing whether a precautionary outage with no confirmed intrusion qualifies. Many forms require an actual or suspected security event, with "suspected" doing significant work. Look for explicit wording that covers a shutdown taken on reasonable belief of imminent compromise.
3. Check the definition of "interruption" or "suspension." Understand whether the policy requires a "necessary" or "unavoidable" suspension, and who decides. A standard tied to a reasonable, documented decision by the insured is preferable.
4. Confirm the waiting period and how it's measured. Record the waiting period in hours and whether it runs from the start of the outage or from discovery. Precautionary shutdowns are often short, and a waiting period can consume the entire loss. A waiting period shorter than your realistic remediation window is ideal.
5. Identify sublimits and retentions for business interruption. Map every sublimit that could cap a web-outage loss against the client's projected hourly revenue exposure. Ensure the limit can withstand a realistic multi-day outage scenario.
6. Review the period of restoration. Determine when it ends: at system restoration or when revenue recovers. Language that includes an extended recovery period for lost customers is beneficial.
7. Check Contingent Business Interruption Coverage. Confirm whether an outage at a vendor, hosting provider, or managed IT provider triggers coverage, and whether a precautionary shutdown by that vendor counts. Named dependent-provider coverage without a requirement for the vendor to suffer a confirmed breach is ideal.
8. Search for patching and unpatched-vulnerability conditions. Read every exclusion, condition, and warranty for language tying coverage to patch status or timelines. Coalition has stated its policy contains no clause barring coverage if a client skips a patch, but confirm other carriers' terms individually. Look for no patch-based exclusion or a clearly defined grace period.
9. Review Insurer Consent Requirement provisions. Know whether shutting down systems, incurring mitigation costs, or engaging vendors requires prior insurer approval. A carve-out allowing urgent protective action without waiting for consent, paired with prompt notice, is preferable.
10. Verify mitigation and duty-to-minimize-loss wording. Ensure that the costs of a precautionary shutdown can be framed as loss mitigation. Express recognition that reasonable steps to prevent a covered loss are themselves covered is crucial.
11. Map the Hostile Act Exclusion, War Exclusion, and State-Backed Cyber-Attack Exclusion against likely attribution. Consider how attribution claims could affect the loss. Dream reported artifacts of a China-nexus campaign that chained PHP2Shell with a Linux kernel flaw, so attribution questions aren't theoretical. Exclusion language with clear attribution standards and a defined process for disputing them is ideal.
12. Confirm First Notice of Loss timing. Know the deadline and whether a precautionary shutdown with no confirmed breach should be noticed as a circumstance. On a Claims-Made Policy, early notice of circumstances can lock in coverage. A calendar trigger in the incident plan, tied to the shutdown decision, is beneficial.
13. Document the shutdown decision contemporaneously. Ensure your client's playbook requires a written record of who decided, on what intelligence, and when. CISA's addition of both flaws to its Known Exploited Vulnerabilities catalog is the kind of external evidence that supports reasonableness. A decision log that would persuade a skeptical adjuster is ideal.
14. Check for embedded and appliance exposure. Ensure the asset inventory covers PHP inside network and management appliances, not just public websites. Beazley Security's Francisco Donoso warned that firms focused on websites may overlook PHP embedded in the appliances that protect their networks. An inventory that matches what you told the underwriter is crucial.
Common Mistakes
- Assuming a shutdown is covered because a breach is plausible. A plausible threat and a policy trigger aren't the same thing.
- Reading the waiting period in isolation. It interacts with the sublimit and the period of restoration.
- Ignoring small and mid-sized client segments. Marsh Re warned that smaller firms may face longer remediation tails, so losses could migrate toward them.
- Treating Underwriting Questionnaire answers as settled. If patching cadence or asset inventory answers were optimistic, an Application Fraud Warranty dispute can follow a claim.
- Waiting until claim stage. Cowbell's Simon Hughes advises checking now how your policy treats a voluntary shutdown and what waiting period applies.
Next Steps
Run items 1 through 5 first for every client with web-dependent revenue; they decide most outcomes. Where wording is silent or adverse, seek clarification or an endorsement in writing before renewal, and prioritize clients without fast patching cycles. Marsh Re places PHP2Shell between acute catastrophe and routine patching, closer to routine for now but with a credible path to catastrophe. The time to learn how your policy treats a voluntary shutdown is before you need it.
