Ontario Regulation 51/26: Cyber Security Obligations for Prescribed Entities

O. Reg. 51/26 is the cyber security regulation made under Ontario's Enhancing Digital Security and Trust Act, 2024. It came into force on July 1, 2026 and imposes concrete, dated obligations on prescribed entities — including Ontario's public hospitals. This guide covers who is caught, what is required, and how AI systems fall inside the perimeter.

Who is prescribed

O. Reg. 51/26 applies to prescribed entities — organizations the regulation specifically names into scope. That list includes Group A, B, and C public hospitals and the University of Ottawa Heart Institute. It is not a blanket rule for the broader health sector: independent clinics, long-term care homes, and retirement homes are not prescribed under it, and the obligations described below should never be presented to them as their legal duties. (Whether such organizations adopt equivalent practices voluntarily is a separate, often sensible, question.)

The threshold task for any Ontario health organization is therefore simple and non-delegable: confirm against the current regulation text whether you are prescribed. Everything else in this guide follows from that answer.

The obligations

The regulation's core requirements for prescribed entities, in force since July 1, 2026:

• A cyber security program. Not a policy document — a functioning program. In practice that means governance with executive ownership, risk assessment, technical and administrative controls, and the operational capability to detect and respond to incidents.
• Named contacts. Designated individuals identified for cyber security purposes. This sounds administrative; it is not. Named accountability is what turns an incident from an organizational scramble into a process, and regulators consistently treat missing contacts as a signal about program maturity.
• A biennial cyber security maturity assessment.A recurring, structured evaluation of the program's maturity every two years — which means the program must be assessable: documented scope, evidence of controls operating, and a baseline against which change can be measured.
• Summary submission within 30 business days. A summary of the maturity assessment must be submitted within 30 business days. The assessment cannot be an internal artefact that drifts; it feeds a dated, external reporting obligation.
• Critical-incident reporting within 72 hours of confirmation. Once a critical incident is confirmed, the reporting clock runs in hours, not weeks. The operative word is confirmation — your incident-response process needs a defined, documented point at which an event becomes a confirmed critical incident, because that determination starts the clock. An organization that cannot say when it confirmed an incident cannot demonstrate it reported on time.

What this means for AI systems

O. Reg. 51/26 is a cyber security regulation, not an AI regulation — but AI systems running inside a prescribed entity's environment are inside the cyber security program's scope like any other system. Three consequences are worth stating plainly.

Inventory. A cyber program cannot protect assets it has not enumerated, and a maturity assessment will expose an inventory that stops at traditional infrastructure. AI scribes, clinical decision-support tools, and AI features embedded inside procured platforms all process data, hold credentials, and expand the attack surface. If they are not in the asset inventory, the program has a gap that is now measurable — and reportable in summary form.

Access control. AI tools frequently hold broad data access — a scribe touches clinical conversations; an embedded model may read entire record sets. Least-privilege review, authentication standards, and vendor remote-access paths for AI systems belong inside the same control framework as any clinical system, and will be probed by any competent maturity assessment.

Incident paths. A compromise of an AI vendor, a data exposure through a model integration, or a poisoned update are cyber incidents. The 72-hour reporting duty does not care that the affected system was an AI tool. Vendor contracts therefore need breach-notice timelines compatible with your own clock: a vendor that notifies you in ten days has consumed your reporting window before you knew there was one.

First 90 days for a newly prescribed hospital

1. Confirm scope and assign ownership (weeks 1–2). Verify prescribed status against the regulation text, name the accountable executive, and designate the required contacts — actually communicated, not just minuted.
2. Baseline the program (weeks 2–6).Map existing security controls, policies, and incident processes against the regulation's requirements. Most hospitals have substantial pieces already; the gap is usually coherence and evidence, not absence.
3. Build the asset inventory — AI included (weeks 3–8). Enumerate systems, data flows, and vendor access, explicitly sweeping for AI tools and embedded AI features. This is the single artefact the most downstream obligations depend on.
4. Rehearse the incident clock (weeks 6–10).Define what "confirmation" of a critical incident means in your process, who decides it, and how the 72-hour report gets drafted and submitted. Run one tabletop exercise against that definition.
5. Plan the maturity assessment (weeks 8–12). Select the assessment approach, schedule it, and work backwards from the 30-business-day submission window so the deadline is planned rather than discovered.

Relationship to EDSTA, 2024

The Enhancing Digital Security and Trust Act, 2024 is the enabling statute, in force since January 29, 2025. EDSTA establishes the framework — public-sector accountability, oversight, and the authority to make regulations on cyber security and on AI use — but its duties apply as prescribed by regulation. O. Reg. 51/26 is the cyber security regulation made under that authority. Notably, EDSTA also contemplates AI-specific duties for public-sector entities; where those have not yet been prescribed, they are not yet obligations, and honest compliance planning tracks the distinction rather than assuming future rules into existence. The practical posture: meet O. Reg. 51/26 now, and build your AI governance so that further regulations under EDSTA land on prepared ground.

References