Adaptive Resilience Intelligence
Saskatchewan-built. Designed for organizations everywhere.
Saskatchewan-built. Designed for organizations everywhere.
© 2026 Prairnova Technologies Inc.
Saskatchewan, Canada
The public works director can't log into the SCADA monitoring tool. The finance clerk says her desktop is showing a ransom note instead of the budget spreadsheet she left open Friday. The CAO's phone starts ringing before coffee's even made. Someone asks the obvious question: who's actually in charge of this right now?
In a lot of municipal offices and small organizations across the prairies, that question doesn't have a clean answer. It's not incompetence. Nobody sat down beforehand and decided it. That gap, the one between "we have an IT guy" and "we have a tested incident response plan with named decision-makers," is where damage multiplies. Fast.
Deloitte Canada's 2023 cybersecurity research found that only 37% of Canadian organizations have a mature incident response plan. For a two-person municipal IT shop juggling patching, help desk tickets, and a fibre upgrade project, that number isn't surprising. It's just expensive. IBM's 2023 Cost of a Data Breach Report put the average breach cost in Canada at CAD $7.05 million, up 16% year over year. Most of that cost isn't ransom. It's downtime, legal exposure, notification costs, and the slow bleed of decisions made badly under pressure.
Executives tend to underweight this part. Technical recovery belongs to the IT team. But who talks to the media, who calls the lawyer, what gets shut down and what keeps running: those are leadership calls. They go badly when they're made for the first time mid-incident, with everyone staring at each other waiting for someone to blink first.
Incident command sounds like a technical term, but it's a governance question wearing a disguise. When something breaks, does the CAO make the call to shut down network access? Does the fire chief decide whether dispatch fails over to manual process? Three people thinking they're in charge, with none agreeing, burns the first critical hours on process arguments instead of containment. (Finding out your CAO doesn't know who has authority to cut the fiber link is a much easier conversation over coffee than at 2 a.m. on Sunday.)
Public Safety Canada's Cyber Incident Response Plan for Canadian Critical Infrastructure says this plainly: executive roles in operational continuity and stakeholder communication need to be defined ahead of time, not improvised. For a municipality that usually means naming a single incident lead (often the CAO or a deputy), a technical lead (your IT manager or contracted provider), and a communications lead, each with a named backup. Incidents rarely wait until everyone's at their desk.
PwC Canada's 2024 Global Digital Trust Insights survey flagged something municipal leaders should sit with: executives consistently underestimate legal and reputational fallout because they're too busy watching for systems to come back online. The moment personal information might be involved, resident tax records, employee files, utility billing data, you're potentially in breach notification territory under provincial privacy law (PIPA in Alberta, Law 25 in Quebec, and equivalent obligations under Saskatchewan's privacy framework for municipal bodies).
The decision that has to happen before an incident: who has authority to engage outside counsel immediately, without waiting for council's next scheduled meeting? Breach notification clocks don't care about committee cycles. If your procurement policy demands weeks for a new legal engagement, that policy needs an emergency carve-out. Decided now. In writing.
Bill C-26, the Critical Cyber Systems Protection Act, targets federally regulated critical infrastructure, so most municipalities aren't directly captured by it. Still, it's setting the tone for what regulators will expect next, and it's worth reading as a signal instead of waving it off as irrelevant. Add provincial privacy commissioner notification requirements on top, and most local governments already carry reporting obligations they've never fully mapped.
Here's the exercise: list every regulator, insurer, and oversight body that might need notifying (privacy commissioner, cyber insurance carrier, provincial ministry, sometimes policing services) and assign an owner to each one. Insurance gets missed the most. Many cyber policies have strict notification windows, sometimes 24 to 72 hours, and missing that window can void coverage entirely. That's not a technical footnote. That's a dollar-figure executive decision, and somebody needs their name on it.
This is where the Canadian Centre for Cyber Security's Top 10 IT Security Actions guidance earns its keep, and gets skipped constantly. CCCS recommends executives explicitly define acceptable levels of risk and disruption, because that number directly sets your recovery time objective (how long systems can stay down) and recovery point objective (how much data loss is survivable).
Plain version of the problem: if nobody's decided that payroll must run within 48 hours while the permit system can wait two weeks, your IT team guesses under pressure. They'll probably guess wrong, because they don't carry council's operational context. RTO and RPO aren't technical settings. They're business decisions wearing technical clothing, and they belong on a risk committee agenda, not buried in page nine of a vendor contract.
Residents find out fast now, usually through social media before any official word goes out. A vague or contradictory public statement does more reputational damage than the incident itself. Decide now who's authorized to speak publicly, what the holding statement says before all facts are confirmed, and how staff are told not to speculate on their personal accounts. None of this needs a communications department. It needs one paragraph, pre-drafted, sitting in a binder, or better, a shared folder two people can reach even when the network's down.
This isn't a prescriptive formula; every organization's risk profile differs. But it's a useful sketch of how the early hours and days tend to unfold once the groundwork above has actually been laid.
The first few hours usually boil down to triage: the incident lead confirms scope with the technical lead, makes the call on isolating affected systems, and triggers the pre-approved legal and insurance notifications. Nobody's debating who's in charge. That got settled months ago, over coffee, not adrenaline.
By day two, communications go out using the pre-drafted holding statement, tweaked for specifics. Legal counsel is already engaged and working through the breach assessment to pin down notification obligations under provincial privacy law.
The first week is where recovery grinds against the RTO priorities set in advance (payroll and emergency dispatch ahead of the online permit portal, say), and the risk committee gets a structured update instead of a panicked hallway briefing.
The weeks after bring a post-incident review, not to assign blame, but to check whether the decisions made in advance actually held and what needs adjusting before the next round.
Here's the part that rarely gets said out loud: even organizations with a written plan often struggle mid-incident, because the plan generates a flood of competing signals (alerts, logs, vendor notifications, staff reports) with no clean way to separate what matters right now from what's noise. That's not a failure of will. It's a volume problem. And volume problems don't fix themselves at 2 a.m.
This is the space where a capability like Adaptive Resilience Intelligence (ARI) earns its keep, not as another dashboard to babysit, but as a way to translate scattered technical evidence into a clear, prioritized picture leadership can actually act on. Instead of a risk committee trying to parse raw vulnerability scan output or conflicting vendor reports mid-incident, ARI is built to surface what's changed, what's improved, and what still needs executive attention, so decisions rest on evidence instead of gut instinct under stress. It doesn't replace any of the decisions above. It sharpens the information feeding them, and it gives leadership a way to check, over time, that resilience is genuinely improving instead of just feeling better on paper.
That last point matters more than people expect. A plan nobody's rehearsed isn't a plan. It's a document. NIST Special Publication 800-61 Rev. 2, still one of the most widely used incident handling frameworks even outside the US, says flatly that preparation and executive involvement in policy setting are what separate organizations that recover in days from the ones that take months.
For municipalities running lean IT teams, MISA Canada's ongoing discussions among municipal IT leaders keep surfacing the same tension: councils want cyber resilience, but budget cycles move annually while threats move daily. The honest answer isn't "spend more everywhere." It's deciding in advance which three or four decisions above get formalized this budget cycle, and which can wait another year. A documented incident commander structure and a pre-drafted communications template cost almost nothing and close a huge amount of early-hour risk. That's an easy win. A full tested incident response plan with external support takes longer and costs more, but it's the difference between a bad week and a bad year.
If your organization is trying to figure out where to start, a structured cybersecurity assessment is usually the fastest way to see which of these decisions are already made, which are assumed but untested, and which haven't been touched at all. That clarity alone tends to reset a budget conversation from vague anxiety into a prioritized list council can actually act on, instead of a wish list that dies in committee.
None of the decisions above require a large security team or a six-figure tooling budget. They require an afternoon with the right people in the room, a council willing to formalize who's in charge before there's a crisis, and a habit of treating incident response as an operational resilience question instead of a purely technical one. Prairnova's work with municipalities and lean public-sector teams keeps circling back to the same starting point: a practical cybersecurity solution isn't about buying more alerts. It's about making sure the handful of decisions that matter most in the first 48 hours are already settled before anyone has to make them under pressure. Building cyber resilience services and incident response capabilities around that principle is what turns a bad Tuesday morning into a manageable one, instead of a multi-million-dollar one.
Looking to evaluate your organization's digital resilience or discuss practical cybersecurity priorities for your team? Connect with the Prairnova advisory team to learn more.
Let's explore what's possible — together.
