Why was the City of Hamilton's cyber insurance claim denied?
Hamilton's insurer denied its full ransomware claim because a control its policy required was not fully in place. What that says about how carriers verify what you attest to.
The insurer refused the claim because multi-factor authentication was not in place across the city’s systems when the ransomware hit, and the policy said that losses with that absence as their root cause were not covered. Nothing in the denial, as reported, concerned the incident response plan. Nothing in it concerned whether any plan had ever been tested. The reason the story matters to somebody holding a renewal application is narrower than the headlines suggest, and it survives the narrowing. A control your carrier has written into your policy is a term of the deal, and the day it gets checked is the day you claim.
What did the insurer actually say?
The operative wording is one clause, and it reaches us secondhand. Reporting the city’s staff report, no coverage was available under the policy for any losses where the absence of multi-factor authentication was the root cause of the cyber breach (Global News, Ontario city facing full $18.3M cyberattack bill after insurer denies claim, 2025). Neither report published the policy itself, so that is the clause as the city described it rather than as it is printed in the contract.
Two things in that sentence do the work. The first is that the exclusion is conditional rather than absolute. It does not say cyber losses are uncovered when multi-factor authentication is missing. It says losses are uncovered where the absence of it was the root cause, which is a causation test, and causation tests get argued.
The second is who applied it. Public reporting of the city’s staff report says the determination that the missing control was a root cause came from the insurance company (CBC News, Insurance won't cover $5M in City of Hamilton claims for cyberattack, 2025). The same report is described as saying the gap was not the only reason the attackers succeeded. So the position is not that one missing control caused everything. It is that one missing control was enough to reach the wording.
The city’s acting chief information officer told reporters that, contrary to the insurer’s finding, the breach would’ve happened even with multi-factor authentication in place (CBC News, Insurance won't cover $5M in City of Hamilton claims for cyberattack, 2025). The city also obtained a third-party review of the denial, and did not pursue further legal action after learning that the insurer had acted on the coverage terms (Global News, Ontario city facing full $18.3M cyberattack bill after insurer denies claim, 2025). That is what a causation test looks like in practice. It gets argued, and then the wording decides it.
None of the reporting we read names the insurer. What is public is the clause, and that is the part you can hold against your own policy.
What happened in February 2024?
| When | What happened |
|---|---|
| the fall of 2022 | The city’s insurer required multi-factor authentication, and staff were aware of the requirement in the policy |
| The year after | A pilot rollout began |
| Early in the year of the attack | The city was preparing to implement multi-factor authentication fully |
| 25 February 2024 | Ransomware. Roughly 80 percent of the network disabled, and a ransom demand of about 18.5 million dollars, which the city refused |
| 31 July 2025 | News reports of a staff report heard by the city’s general issues committee the day before make the denial public. None of the claims were covered, and the cost falls on the city |
Read the first three rows together, because they are the uncomfortable part. This is not an organization that had never heard of the control. It knew, it had started, and it was partway through. The gap between knowing and finishing ran well over a year, and the attack landed inside it.
That is the ordinary shape of a control program in a real organization. It is also, on these facts, the shape that a causation clause is written to catch.
What did the attack cost, and who paid?
Two figures circulate and they are not the same figure.
By July 2025, the city had spent about 18.3 million dollars on immediate response, system recovery and third-party expert support, of which roughly 14 million went to external experts helping with its response, redesign and future strategies (Global News, Ontario city facing full $18.3M cyberattack bill after insurer denies claim, 2025). That is the cost of the event.
The claims the city put to its insurer came to about 5 million dollars, and none of them were covered (CBC News, Insurance won't cover $5M in City of Hamilton claims for cyberattack, 2025). That is the cost of the denial.
The second number is much smaller than the first, and the gap between them is not a discrepancy in the reporting. They measure different things. The reporting does not say why the claims came to so much less than the spend. Whatever the reason, the denial took away the part that was meant to come back.
The ransom itself, about 18.5 million dollars, was demanded and refused (Global News, Ontario city facing full $18.3M cyberattack bill after insurer denies claim, 2025). Refusing is now the common choice. Among one large carrier’s policyholders hit by ransomware, 86 percent refused to pay in the most recent full year reported (Coalition, 2026 Cyber Claims Report, 2026). Refusal is not what cost Hamilton its coverage.
Was the denial about incident response testing?
No, and the distinction is worth holding onto, because this story is going to be retold badly.
The control at issue was multi-factor authentication. The reporting, and the staff report as reported, describe a policy clause about multi-factor authentication being applied to the loss. In the coverage we read there is no mention of the incident response plan, no mention of a business continuity plan, and no mention of any exercise or test of either.
A different story circulates that attaches a refused cyber claim to an untested incident response plan. It is not this case, and the record on the case it refers to is set out on the page about what carriers accept as proof, with the docket number.
Hamilton does not need the embellishment. What it demonstrates is the mechanism, and the mechanism applies to every control on the form.
What does a renewal application ask you to attest to?
More than most applicants read carefully.
Take the incident response question, since it is the one we spend our time on. Cowbell’s Prime 250 form asks whether the organization has an incident response plan, tested and in-effect, setting out action items and responsibilities (Cowbell Cyber Risk Insurance Renewal Application, Prime 250, 2021). Beazley’s Canadian form splits the same ground into two tick boxes, Have a plan and Tested in last year (Beazley Cyber Application, Canada, 2026).
Then read the declaration you sign underneath. On Cowbell’s full application, an undersigned authorized officer declares that the statements are true, accurate and complete, and the notice closes by saying that misrepresentation of any material fact may be grounds for rescission (Cowbell Cyber Risk Insurance Application, Prime 250, 2020).
So the form collects two different kinds of exposure. Controls written into the policy can knock out a specific loss, which is what happened to Hamilton. Answers that turn out to have been materially wrong can put the whole policy at risk. Neither is a question about whether you are a careful organization. Both are questions about what you can show.
How would a carrier verify a “tested” answer?
Here is the part of Hamilton that does transfer, and it is not the control.
Multi-factor authentication is self-evidencing. Whether it was on, where, and for whom, is recorded in configuration and in sign-in logs, and it can be reconstructed after the fact by people who were not there. Nobody needs the city’s account of it. That is why the question of who was covered by it could be settled in a claim review at all.
A tested incident response plan is not like that. Testing leaves no technical residue. Run a genuinely good exercise and take no notes, and nine months later there is nothing for anyone to find. The plan file does not change. No log records that eleven people sat in a room and argued about when to call the carrier’s hotline.
Which means the evidence has to be manufactured deliberately, at the time, by somebody willing to put a date on it. A dated report naming the scenario, the people by role, the decisions they made and the findings that came out is the whole of it. Confirmation from somebody independent of your response is what makes that record hard to dispute a year later, when the reader has an incentive to dispute it.
The honest summary is that you are more exposed on the questions that leave no trace than on the ones that do. Hamilton’s control could be checked. Yours, on this one, cannot be checked. It can only be evidenced or not.
What should a mid-market organization take from it?
Three things, and none of them is that you should be frightened of your carrier.
Read your own policy for conditions, not just for limits. The clause that decided this is a single sentence, as reported, inside a document most people open once. Anything phrased as a requirement rather than a coverage is a term you are carrying.
Treat the gap between starting a control and finishing it as a live exposure. Hamilton knew about the requirement, began work and got caught in the middle. A partial rollout is a reasonable engineering position and a weak insurance position, and nobody tells you that at the point you decide to phase it.
Assume every declared control is checkable after a loss, and work out now which of yours would survive being checked. For most controls the answer is in your systems. For incident response testing the answer is in a filing cabinet or it is nowhere.
If you want a structured version of that exercise, the renewal readiness checklist below is the same question asked twelve times.
Questions
Did Hamilton's insurer deny the claim because the city had not tested its incident response plan?
No. The reported reason was multi-factor authentication. The policy excluded losses where the absence of multi-factor authentication was the root cause of a breach, and the insurer determined that it was. Nothing in the news coverage of the staff report that we read mentions the incident response plan, business continuity, or the testing of either.
Was this a rescission, or a coverage denial?
A coverage denial. The reporting describes a policy term about multi-factor authentication being applied to the loss, not a finding that the city misrepresented anything on its application. Those are different mechanisms with different consequences, and the difference matters if you are reading the story as a warning about your own answers.
Why do two different numbers appear in coverage of the same story?
Because they measure different things. The larger figure is what the city had spent by July 2025 on response, recovery and outside help. The smaller one is the value of the claims it put to its insurer and had refused. An organization can spend far more than it claims for.
Does this mean a carrier will check every control we declare?
It means a carrier can, and that the moment it becomes worth doing is after a loss. Underwriting is done on your word at the front end. Adjusting is done on the evidence at the back end. Any control that sits in your policy or your application is available to be looked at then.