On May 5, 2026 at 3:13pm, the threat actor's own bank called the City of Ocala's then-Fiscal Operations Manager, said the payee name did not match the account, and asked whether it should stop the payment. Ocala activated its Incident Response Plan on July 23. The eight-page investigation filed September 8 by Internal City Auditor Vincent Iovino counts eighty days between those two events, and puts the unrecovered loss at $277,799.81 — reduced to $27,799.81 after a $250,000 insurance payout.
Detection worked. Someone outside the organisation spotted the fraud within five days and offered to undo it. Everything downstream of it failed.
How the money left
The vendor's email account was compromised — MS-ISAC confirmed the compromise sat inside the vendor's system, not the City's. The attacker interposed itself, directed the vendor to send banking details to a spoofed address resembling the City's, and returned a fraudulent EFT Authorization form. It went into accounts payable without a verification call. $492,056.44 was transferred on April 30, a date from Ocala-News rather than the report.
The control that should have caught it already existed. Procurement SOP 870 required a call to the vendor phone number on file and said changes "would not be processed without verification." SOP 870 was rewritten in 2019, after a business email compromise that cost the City more than $740,000, per the Ocala Gazette. The auditor's CAUSE section says why it did not fire: the procedure "had not been posted on the City's intranet, which prevented employees from locating or following it." The employee required to run it had been in the role 24 days.
The plan was fine. It had no trigger.
Appendix A cites NIST CSF 2.0 ID.IM-02 and states the root condition in a sentence: "no process had existed to activate the City's Incident Response Plan in response to real-time losses." A second sits beside it: "employees working outside their designated roles."
Five inflection points, none producing an activation. No reversal request followed the May 5 call; a week went by while the Fiscal Operations Manager worked the payee-name question himself. The May 13 bank claim alert reached the Finance Director at 1:29am with no amount and no reason attached. The June 10 police report carried the subject header "Fraud Attempt" and the detective's narrative records him saying no funds were lost. On June 16 an Interim Procurement Director, 11 days in post, filed a $492,056.44 loss with the FBI; asked later why she told no one, she said she had been told the money was coming back.
The report also records a second $492,056.44 payment sent to the threat actor's account, which failed only because that account had closed — a fact one person knew and withheld.
The auditor names the mechanism. The City was computing Risk = Likelihood × Anticipated Impact rather than real-time impact, and anticipated impact was whatever the person closest to the mistake said it was.
Define the trigger as an event, not a judgment
Most plans detail what happens after activation and leave activation itself to whoever holds the facts first — the person with the strongest reason not to activate.
Write the trigger as observable facts. Not "when the loss is material" — that is the judgment call that failed here. Write events: a bank contacts you about a payee-name mismatch; a vendor disputes receiving a payment your ledger shows as sent. Any one of those, known to anyone, starts the plan; assessment happens inside it, where more than one person is looking. It is the construction behind the NCUA rule whose 72-hour clock starts on reasonable belief rather than confirmation: the clock has to start before anyone knows how bad it is, or it never starts.
Name who declares, then trace their reporting line. The useful tabletop question is not "would we detect this." Ocala detected it on day five. It is: who may declare, and does that person report to whoever would have to admit the mistake? Here the facts sat with the Fiscal Operations Manager, and his supervisor was excluded from the thread. Add a path that bypasses the chain — one named person outside Finance and Procurement whom any employee can notify directly, whose notification alone activates the plan.
The cost is false alarms; budget for them. A mechanical trigger fires on events that turn out to be nothing, and each one burns hours across several departments. That cost is why activation gets left to judgment in the first place. Two tiers make it workable: a notify tier that is one message to a fixed list, and full activation above it.
If you cannot change reporting lines, move the trigger outside the organisation. Ask your bank in writing to route payee-mismatch alerts to a distribution list rather than one individual. Ocala's escalation depended on one person forwarding one phone call. The same dependency appears with outsourced IT, where the question to put to a provider is who on your side gets told.
What to check this week
- Find the sentence in your plan that says what starts it. If it names a judgment rather than an event, there is no trigger.
- Identify who is authorised to declare. If they report into the function most likely to cause an incident, add a second path.
- Ask someone hired this month to find the procedure your last incident produced. Time them. Ocala's was never posted to the intranet.
- Ask your bank where a payee-mismatch alert goes. Ocala's reversal request went in over a week late.
North InfoSec runs AI-assisted penetration testing and security assessments, including incident response readiness reviews and tabletop facilitation. northinfosec.com