Seven Canadian frameworks, each with its real status, who it covers, and whether it prescribes technical controls or only sets duties. Checked against the statutes and regulations themselves, not vendor summaries.
Three of these are not laws at all, and one of the most talked about is not yet in force. Knowing which is which is most of the work. At the end we show the three pieces of evidence you will be asked for if any of it touches an AI system, and where those come from.
Status table ·
What this means for you ·
The seven frameworks ·
Where SecuritAI fits ·
The control mapping ·
Questions
“Has controls” is the column most references get wrong. A law can be fully in force and still prescribe no technical control at all, which changes what you can be audited against.
| Framework | Status | Who it covers | Has controls |
|---|---|---|---|
| Bill C-8 / CCSPA | Part 2 not in force | Federally regulated critical infrastructure | No, duties only |
| Ontario Bill 194 | In force | Ontario broader public sector | No, points to a framework |
| PIPEDA | In force | Private sector, commercial activity | No, duties only |
| PHIPA | In force | Ontario health information custodians | No, duties only |
| CPCSC | Not a law | Defence suppliers to Canada | Yes, 98 requirements |
| ITSG-33 | Not a law | Federal departments and their suppliers | Yes, a control catalogue |
| NIST CSF 2.0 | Not a law | Voluntary, anyone | Outcomes, not controls |
Here is the short version, without the legal language.
Almost none of these laws tell you which security products to buy. They tell you to have a program, manage your risks, protect the data, and be able to prove all three. The proving is the part people underestimate. A regulator or an auditor does not want to hear that you take security seriously. They want to see the document, the test result and the log.
That is normally fine, because most organisations know how to evidence a firewall, a backup or an access review. It stops being fine the moment part of the job is done by an AI system, because the usual evidence does not exist for it. Nobody has a penetration test for a chatbot. Nobody has an access log for a prompt.
So if you run AI anywhere near a regulated process, there are three questions you will eventually be asked about it, whichever of these laws applies to you:
If you cannot answer those three today, that is the gap, and it is the same gap under every law in the table above.
Status: Royal Assent June 15, 2026. The Telecommunications Act amendments in Part 1 are in force. The Critical Cyber Systems Protection Act in Part 2 is not, and waits on an order of the Governor in Council that had not been made as of August 17, 2026.
Covers: designated operators in six federally regulated sectors: telecommunications, interprovincial and international pipelines and power lines, nuclear energy, federally regulated transportation, banking, and clearing and settlement.
Requires: a cyber security program within 90 days of designation, supply chain risk mitigation, incident reporting to the Communications Security Establishment, and compliance with cyber security directions.
Controls: none. The Act names no standard and defers the detail to regulations that have not been made.
Watch out: obligations attach only once your class is designated by order, so the 90 day clock does not start at Royal Assent. Any vendor selling Bill C-8 compliance today is selling against duties that are neither in force nor defined.
Status: in force. The Act came into force January 29, 2025. O. Reg. 51/26 (Cyber Security) and O. Reg. 52/26 came into force July 1, 2026.
Covers: five categories of Ontario broader public sector body only: colleges and universities, Group A, B and C public hospitals, the University of Ottawa Heart Institute, children’s aid societies, and school boards.
Requires: named senior contacts reported to the Ministry CISO, a cyber security maturity assessment within one year and every two years after with a summary filed inside 30 business days, and reporting of critical incidents within 72 hours.
Controls: none in the regulation. It requires an assessment against “industry standards or best practices endorsed by” the Ministry CISO. NIST CSF 2.0 is what the Ministry endorses in its guidance, and other frameworks need CISO approval.
Watch out: there are no fines. The Act creates no offence and no monetary penalty, and section 13 says non compliance does not invalidate a decision. Anyone quoting a Bill 194 fine is inventing it. The Ministry also gives its assessment tool away free.
Status: in force. Privacy provisions since 2001, applying to all commercial activity since 2004, with mandatory breach reporting since November 1, 2018.
Covers: private sector organizations handling personal information in commercial activity, in provinces without substantially similar legislation.
Requires: the ten fair information principles, and reporting breaches to the Privacy Commissioner and affected individuals where there is a real risk of significant harm.
Controls: none prescribed. Safeguards must be appropriate to the sensitivity of the information. Having safeguards is mandatory; the choice of method is left to you.
Watch out: a data mobility framework is enacted and not yet in force, so PIPEDA is a moving target.
Status: in force since November 1, 2004.
Covers: Ontario health information custodians, meaning practitioners, hospitals, pharmacies, labs and their agents.
Requires: safeguards for personal health information, notice to affected individuals on unauthorised access, and reporting to the Information and Privacy Commissioner.
Controls: none prescribed generally, though O. Reg. 329/04 requires digital health assets to meet Ontario Health interoperability specifications, which can carry privacy and security requirements.
Watch out: the Commissioner can levy administrative penalties directly, capped at $50,000 for an individual and $500,000 otherwise, on top of prosecution. And there is no such thing as PHIPA certification for an organization: Ontario Health certifies digital health assets against interoperability specifications, which is not the same claim.
Status: not legislation. It is a Public Services and Procurement Canada procurement program. Level 1 became available to suppliers on April 1, 2026.
Covers: suppliers bidding on Government of Canada defence contracts that involve protected information.
Requires: certification at the level the contract specifies.
Controls: yes, and this is the important difference. The controls come from the Cyber Centre publication ITSP.10.171, which contains 98 numbered security requirements across 17 families. PSPC states that Level 1 involves 13 of them, Level 2 involves 98, and Level 3 involves 200. Note that ITSP.10.171 itself never mentions CPCSC or any level: the tiering is PSPC’s, laid on top of a flat standard.
Watch out: there is no mutual recognition agreement with the United States. PSPC says the controls align with CMMC, but acceptance of a CMMC certificate is case by case. PSPC also states that Levels 2 and 3 are still under development, so nobody can be Level 2 certified today and those two figures can move.
Where to go: our sister company runs the CPCSC programme itself, control sets by level, evidence and readiness. See SecuritComply’s CPCSC page, including a free Level 1 readiness check against the 13 controls. SecuritAI covers only the AI layer inside that programme.
Status: not legislation. Guidance from the Canadian Centre for Cyber Security.
Covers: federal departments and agencies, and in practice the suppliers who must meet their requirements.
Controls: yes. Annex 3A is a full security control catalogue derived from NIST SP 800-53.
Watch out: Annex 3A has been superseded by ITSP.10.033, effective March 31, 2026. Material citing Annex 3A alone is now dated.
Status: not legislation, and not Canadian. Voluntary guidance published February 2024, still current.
Covers: anyone who chooses it. It matters in Canada because Ontario’s Ministry endorses it as the assessment framework for Bill 194.
Controls: outcomes rather than controls. Six functions, 22 categories and 106 subcategories.
Watch out: nobody is “CSF 2.0 certified”. NIST does not certify or accredit anyone against it. Counting subcategories from the NIST reference spreadsheet also gives 185, because that export still bundles the retired 1.1 identifiers.
Most Canadian cyber law sets duties and leaves the controls to you. That is not a gap, it is the design, and it means the same underlying control set can evidence several laws at once. The mapping below is ours, offered as a working interpretation. It is not a statutory requirement and no regulator has endorsed it.
| Duty | Where it comes from | Controls that evidence it |
|---|---|---|
| Security program, documented | CCSPA, Bill 194, PIPEDA | ISO 27001 clauses 4 to 10, CPCSC L1 and L2, ITSG-33 |
| Risk assessment on a cycle | Bill 194 | NIST CSF ID.RA, ISO 27001 clause 6.1 |
| Incident detection and reporting | CCSPA 72h, Bill 194 72h, PIPEDA, PHIPA | ISO 27001 A.5.24 to A.5.28, NIST CSF DE and RS |
| Supply chain and third party risk | CCSPA | ISO 27001 A.5.19 to A.5.23, NIST CSF GV.SC |
| Safeguards proportionate to sensitivity | PIPEDA, PHIPA | ISO 27001 Annex A, CPCSC control set |
| Access control and logging | All of the above, indirectly | ISO 27001 A.5.15 to A.5.18, A.8.15, ITSP.10.171 |
| AI systems inside the above scope | Any program covering AI | Adversarial testing evidence, runtime request logs, agent tool access limits |
The last row is the one most programs miss. Everything above it, an organisation already knows how to evidence. AI is the row where the usual evidence does not exist yet.
We do not make you compliant. No product does, and anyone who says otherwise is selling you something. What we do is produce the three pieces of evidence about your AI that the questions above ask for.
What did you test it against?
AI red teaming. We attack your AI the way a real attacker would, across the OWASP LLM Top 10, and hand you a written findings report with what broke, how, and what to fix. That report is the artifact you put in front of an auditor when they ask question one.
What stops an attack live?
The AI firewall. It sits in front of your model and inspects every prompt going in and every response coming back, blocking prompt injection, jailbreaks and data leakage in real time. Testing proves yesterday was fine. This is the control that covers today.
Where is the record?
The audit log. Every prompt, every response, every block, with a timestamp, exportable. This is what an incident report is built from when a law gives you 72 hours, and what you show when someone asks what the AI actually did in March.
SecuritAI covers the AI layer. It does not write your policies, run your risk register, manage your evidence for every other control, or certify you against anything. We are a security platform, not an audit firm and not an accredited certification body, and we cannot sign off on your compliance.
If what you need is the whole program rather than the AI part of it, that is SecuritComply, our compliance platform, which handles the policies, controls and evidence across frameworks like ISO 27001, SOC 2 and CPCSC. Same company, different job.
Say you are an Ontario hospital. PHIPA applies to you today, and Bill 194 applies if you are a Group A, B or C hospital. You have put an AI assistant in front of patient scheduling. Your maturity assessment is due, and the assessor asks how that assistant is secured.
Without an answer to the three questions, the honest response is that it is covered by the same controls as the rest of the application, which is true and will not satisfy anyone, because none of those controls read language. With them, you hand over a red team report showing it was tested for prompt injection and data leakage, a description of the runtime control that blocks those attacks, and a log showing every request it has handled. That is not compliance. It is the evidence compliance is made of.
This is the part most vendors skip. Below is exactly which control each of our three artifacts is evidence for, using the real identifiers, so you can check the claim rather than take it.
These are examples, not the full list. We have published only the mappings we are confident enough to defend in an audit conversation, and cut everything that was arguable. Plenty of other controls can be mapped depending on how your programme is structured, what your assessor expects, and where the AI system actually sits. Ask us and we will work through your own control set with you.
And every row is partial evidence for the AI component, never coverage of a whole control. A.8.15 Logging, for example, also requires you to protect and retain those logs, and that part is yours. Rows marked partial cover materially less than the control asks for, and we have marked them rather than let you find out later. Your assessor decides what satisfies a control. We are a security platform, not an audit firm.
| Control | Title | Evidenced by | Scope |
|---|---|---|---|
| A.8.29 | Security testing in development and acceptance | Red team report | Direct |
| A.8.12 | Data leakage prevention | AI firewall | Direct |
| A.8.15 | Logging | Audit log | Partial, you own retention and protection |
| A.8.16 | Monitoring activities | Firewall and log | Direct |
| A.8.8 | Management of technical vulnerabilities | Red team report | Partial, identification and guidance only |
| A.5.26 | Response to information security incidents | Audit log | Partial, supplies the timeline |
| Subcategory | Outcome | Evidenced by | Scope |
|---|---|---|---|
| ID.RA-01 | Vulnerabilities in assets are identified and recorded | Red team report | Direct |
| ID.IM-02 | Improvements are identified from security tests | Red team report | Direct |
| DE.CM-09 | Computing hardware, software and runtime environments are monitored | Firewall and log | Direct |
| PR.PS-04 | Log records are generated and made available | Firewall and log | Direct |
| RS.AN-03 | Analysis establishes what took place during an incident | Audit log | Direct |
| RS.AN-07 | Incident data and metadata are collected, integrity preserved | Audit log | Partial, log tamper protection is yours |
Reasonable question, because the name gives nothing away. ITSP stands for IT Security Publication, the numbering the Canadian Centre for Cyber Security uses for its guidance. It is not legislation, and nobody certifies you against an ITSP directly. Two of them matter here, and they are the Canadian equivalents of the two American documents you may already know:
ITSP.10.171 is the control set behind CPCSC, so it is what a defence supplier is actually assessed against. It plays the role NIST SP 800-171 plays in the United States. It has no legal force on its own, and gets its teeth from procurement: it binds you when a Government of Canada contract requires CPCSC certification. Revision 2, dated October 28, 2025, contains 98 numbered security requirements in 17 families.
One detail worth knowing, because it is the difference between reading the Canadian standard and assuming it copies the American one. NIST SP 800-171 Revision 3 has 97 requirements. ITSP.10.171 has 98. The two are otherwise one for one, down to the same 33 withdrawn slots, and the single Canadian addition is 03.14.09, Dedicated administration workstation, which requires administrative work to be done from a hardened machine with no internet access. It exists because it draws on a Cyber Centre control that has no NIST equivalent. Anyone quoting 97 for Canada has taken the American number.
ITSP.10.033 is the federal control catalogue, the Canadian counterpart to NIST SP 800-53. It replaced ITSG-33 Annex 3A on March 31, 2026, so anything citing Annex 3A alone is now out of date. It applies to federal departments and flows down to the suppliers who build for them.
So: a real control catalogue, yes. A framework you certify against, no. That distinction is the same one running through this whole page.
Level 1 is 13 controls across six categories: access control, identification and authentication, media protection, physical protection, system and communications protection, and system and information integrity. It contains no audit and accountability controls and no security assessment controls, so only two rows can honestly appear here. Both are genuine Level 1 controls, and the other eleven are ones our evidence does not touch.
| Control | Title | Evidenced by | Scope |
|---|---|---|---|
| 03.13.01 | Boundary protection | AI firewall | Partial, AI application path only, not your network boundary |
| 03.14.01 | Flaw remediation | Red team report | Partial, identification only, not your patch cadence |
Logging requirements from the 98 in ITSP.10.171, in a family that Level 2 reaches. They are not CPCSC Level 1 controls. Other families map too, and we have listed only the ones we read directly off the published standard.
| Control | Title | Evidenced by | Scope |
|---|---|---|---|
| 03.03.01 | Event logging | Audit log | Direct |
| 03.03.02 | Audit record content | Audit log | Direct |
| 03.03.03 | Audit record generation | Audit log | Direct |
| 03.03.07 | Time stamps | Audit log | Direct |
The Canadian control catalogue that supersedes ITSG-33 Annex 3A, effective March 31, 2026.
| Control | Title | Evidenced by | Scope |
|---|---|---|---|
| CA-08 | Penetration testing | Red team report | Direct, for the AI system |
| CA-02 | Control assessments | Red team report | Partial, the AI system’s controls only |
| SI-10 | Information input validation | AI firewall | Direct |
| SI-15 | Information output filtering | AI firewall | Direct |
| SI-04 | System monitoring | Firewall and log | Direct |
| AU-02 | Event logging | Audit log | Direct |
| AU-03 | Content of audit records | Audit log | Direct |
| AU-08 | Time stamps | Audit log | Direct |
| AU-12 | Audit record generation | Audit log | Direct |
We deliberately do not put statutes in a mapping table. A statute imposes a duty on your organisation, not on a system, so a tidy row implying a product satisfies a legal obligation would be misleading and it is not our place to give that opinion. What we can say plainly:
Where PIPEDA principle 4.7 requires safeguards proportionate to sensitivity, testing and a runtime control are two of the safeguards you can point to for the AI system. Where PIPEDA section 10.1 and PHIPA section 12 require you to report a breach and keep records of it, the audit log is where the facts of an AI related incident come from. Where Ontario O. Reg. 51/26 section 7 gives you 72 hours to report a critical incident, the log is what you build the report from. And the CCSPA duties are not in force and reach only designated operators, so nothing there applies to most readers today.
None of that is legal advice, and your counsel or your assessor is the one who decides what satisfies a duty.
The tables above are examples chosen because we can defend every one of them. Your programme will have controls we have not listed, in frameworks we have not shown, and the AI system will sit somewhere specific in your architecture that changes what maps and what does not. Send us your control list and we will go through it with you and tell you honestly which rows our evidence supports and which it does not.
Partly. Bill C-8 received Royal Assent on June 15, 2026. Its Telecommunications Act amendments are in force. The Critical Cyber Systems Protection Act it creates is not, and comes into force on a date set by order of the Governor in Council, which had not been made as of August 17, 2026. No organisation is under CCSPA obligations today.
No. The Act sets four outcome based duties and names no technical control, no standard and no framework. The specifics are left to regulations that have not been made yet. Any control mapping you see, including ours, is an interpretation rather than a legal requirement.
No. The Enhancing Digital Security and Trust Act and its regulations create no offence, no fine and no administrative penalty, and section 13 provides that non compliance does not invalidate a decision. The obligations are real, but the pressure comes from oversight, boards and insurers rather than from a statutory fine.
Not in the regulation itself, which asks only for an assessment against industry standards or best practices endorsed by the Ministry’s Chief Information Security Officer. NIST CSF 2.0 is what the Ministry endorses in its implementation guidance, and using a different framework requires CISO approval.
CPCSC and ITSG-33. CPCSC draws on the Cyber Centre publication ITSP.10.171, which contains 98 numbered security requirements in 17 families. PSPC states that Level 1 involves 13 of them and Level 2 involves all 98. ITSG-33 Annex 3A is a full control catalogue derived from NIST SP 800-53, now superseded by ITSP.10.033 as of March 31, 2026. PIPEDA, PHIPA, Bill 194 and the CCSPA all set duties instead and leave the control choice to you.
We cover the AI layer, not the whole programme. If an AI system sits inside a regulated process you will be asked what you tested it against, what protects it while it runs, and where the record is. SecuritAI produces those three things: a red team findings report, a runtime firewall that blocks prompt injection and data leakage, and an exportable log of every prompt and response. We do not write your policies, run your risk register or certify you, and no product can make you compliant.
No. Neither has a certification scheme. There is no CCSPA control set to certify against yet, and PHIPA has no organisational certification. Ontario Health certifies digital health assets against interoperability specifications, which certifies a product feature and not an organisation’s compliance.
Every status on this page was checked against the primary text on August 17, 2026. Consolidations carry their own currency dates, so recheck before relying on any of this for a filing.
This page is a reference, not legal advice. SecuritAI is a security platform, not a law firm and not an accredited certification body.