Testing and defence led by a published security researcher with five CVEs, including a CVSS 9.1 Mirai botnet kill-switch.
All security →SOC 2, ISO, and the Canadian privacy stack, run end to end with an independent auditor.
All frameworks →Original research, free tools, and plain-language guides on security and compliance, from a published security researcher.
Read the blog →The Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024 binds Ontario public sector entities, not their suppliers. It still changes what you will be asked for in every Ontario public sector bid from here on.
Bill 194 became the Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024 when it received Royal Assent in November 2024. It does two things. Schedule 1 enacts the Enhancing Digital Security and Trust Act, 2024, which gives the province authority to impose cyber security requirements, artificial intelligence requirements and requirements about the digital information of individuals under 18 on public sector entities, largely through regulations and directives rather than in the statute itself. Schedule 2 amends the Freedom of Information and Protection of Privacy Act to add an information security duty, privacy impact assessments, and breach notification to the Information and Privacy Commissioner of Ontario. None of it binds you as a supplier. All of it reaches you through procurement, because an institution that must assess a system before deploying it, report breaches, and account for AI use has to get most of the answers from the vendor.
Bill 194 was introduced in the Ontario Legislature in 2024 and received Royal Assent in November of that year as the Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024. The name of the bill is still what everyone calls it, which is why procurement documents and vendor questionnaires refer to "Bill 194" rather than to either of the statutes it produced.
It has two schedules and they do different jobs. Schedule 1 enacts a new statute, the Enhancing Digital Security and Trust Act, 2024, which applies to public sector entities and creates authority in three areas: cyber security, artificial intelligence, and the digital information of individuals under the age of 18. Schedule 2 amends the existing Freedom of Information and Protection of Privacy Act, Ontario's public sector privacy statute, to strengthen how institutions handle personal information.
The critical structural point, and the one that confuses people reading the statute for the first time, is that Schedule 1 is largely enabling legislation. It does not itself contain a list of controls. It gives the government the power to make regulations requiring public sector entities to have a cyber security program, to comply with cyber security standards, to report incidents, to comply with requirements about the use of artificial intelligence, and to publish information about that use. The substance lands in regulations and in government directives issued under the authority the Act creates.
That means the honest answer to "what does Bill 194 require of my product" is: it depends on which entity is buying, which regulations and directives are in force at the time, and what that entity's own procurement office has translated them into. What does not change is the shape of the questions, and that shape is predictable enough to prepare for.
The Act applies to public sector entities, and that term is defined by reference to Ontario's existing access and privacy statutes plus some additions. In practice the population is the institutions covered by the Freedom of Information and Protection of Privacy Act, which is the provincial ministries, agencies, boards, commissions, colleges and universities; the institutions covered by the Municipal Freedom of Information and Protection of Privacy Act, which is municipalities, police services boards, transit commissions, conservation authorities and local boards; plus school boards and children's aid societies, which are named because the provisions about individuals under 18 are aimed squarely at them.
Note what is not obviously in that list. Hospitals sit in a slightly different place: they are FIPPA institutions for some purposes, but personal health information they hold as health information custodians is governed by PHIPA rather than FIPPA. If you sell clinical software to an Ontario hospital, PHIPA is still your primary statute and Bill 194 is an additional layer on the institutional side.
You, the vendor, are not a public sector entity, and nothing in the Act imposes a duty on you directly. This is the same structure as almost every regulatory flow-down in Canada: the obligation belongs to the buyer, the buyer has to be able to demonstrate compliance, and the only way it can demonstrate compliance for a system it did not build is to extract commitments and evidence from the company that did.
The practical consequence is that you should never answer a questionnaire by saying Bill 194 does not apply to you. It is true and it is unhelpful. The useful answer states that you understand the institution carries the obligation, names the specific things you can provide to help them meet it, and attaches them.
The cyber security part of the Enhancing Digital Security and Trust Act is built around three ideas: that public sector entities should have a cyber security program, that they should meet standards the government sets, and that they should report incidents.
A program in this context means the ordinary components: governance and accountability for cyber risk, roles, education and awareness for staff, oversight by the institution's leadership, and periodic reporting. The Act also contemplates requirements to prepare and submit reports, and the government has separately maintained cyber security expectations for the broader Ontario public service and its agencies for years. If you have seen the Ontario government's GO-ITS technology standards series referenced in a tender, that is the older instrument through which the province has expressed security requirements for its own systems and the systems supplied to it.
Incident reporting is the piece with the sharpest vendor consequence. If an institution has to report a cyber security incident to a central body within a defined window, and the incident is happening inside your service, then your notification clock has to be shorter than theirs. This is exactly the mechanism that has already reshaped financial sector vendor contracts through OSFI expectations, and the drafting problem is identical. An institution will open at notification of any incident immediately. That is unworkable, because your monitoring generates events constantly and almost none of them are incidents.
The defensible position is to define the trigger and then commit to a real clock: notification without undue delay and in any event within a stated number of hours of confirming a security incident affecting the institution's data or the services you provide to them, with an initial report containing what is known, what is not yet known, containment actions taken, and the time of the next update. Institutions accept this regularly, because it is what their own process actually produces.
What will not survive contact with a serious buyer is a notification commitment your incident response process has never been exercised against. If your plan says four hours and you have never run a tabletop, the first real event will discover that nobody knows who declares an incident. Running one exercise, writing down what it found, and fixing the gaps is a small piece of work that converts a paper commitment into a defensible one.
The Act creates authority to impose requirements on public sector entities that use artificial intelligence systems. The recurring themes in the statute and in the surrounding policy work are transparency about where AI is being used, accountability through a named human, risk management proportionate to the use, and in some cases disclosure to the public.
The reason this reaches vendors who do not consider themselves AI companies is that the definition of an AI system in this context is broad, and most modern software contains something that qualifies. A scheduling optimizer, a fraud scoring model, a document classifier, a chat assistant embedded in a support widget, a resume screening feature, a recommendation ranking: all of these are machine-based systems producing outputs that influence decisions. If the institution has to publish or account for its use of AI, it has to know that your product contains one.
The failure mode is discovering this in the middle of a bid. A procurement questionnaire asks whether the solution uses artificial intelligence, someone in sales answers no because the product is not marketed as AI, and the security review later surfaces a third-party model in the stack. That is a credibility problem that costs more than the honest answer would have.
What to have ready: an inventory of every AI or machine learning component in your product, including third-party models and APIs, saying what each does, what data it processes, whether that data leaves your environment, whether customer data is used for training or improvement by you or by the model provider, and what human review sits between the output and any consequential decision. Say plainly which decisions the system makes and which it merely informs.
Two contractual commitments are worth pre-clearing internally because they come up almost every time. First, that the institution's data will not be used to train models, yours or anyone else's, without written consent. Second, that you will notify before introducing a new AI component or a new model provider into the service. Both are commitments you can meet if you know your own stack, and both are extremely awkward to give retroactively.
If you want to formalize this, ISO 27001 plus an AI management system is the direction of travel, and our AI governance assessment is a free way to see where the gaps are before a buyer finds them.
The third subject area in the Enhancing Digital Security and Trust Act deals with digital information relating to individuals under the age of 18, and it is aimed at school boards and children's aid societies. The authority is to make regulations governing the collection, use, retention, disclosure and disposal of that information, and to require reporting about it.
If you sell education technology into Ontario school boards, or case management software into the child welfare sector, this is the part of the Act most likely to change your product requirements rather than just your paperwork. The obvious pressure points are data minimization, retention limits, the use of student or client information for product improvement or analytics, advertising and profiling, and any transfer of information outside the institution.
The practical preparation is the same discipline as elsewhere: know precisely what you collect about minors, why, how long you keep it, who can see it, and what leaves your environment. Education technology procurement in Ontario was already asking these questions before Bill 194 because school boards are MFIPPA institutions with their own privacy obligations. The Act raises the profile and adds reporting.
A specific thing to check: whether any analytics, error reporting, session replay or advertising SDK in your web or mobile client transmits information about a minor to a third party. This is the single most common finding in education technology reviews and it is usually a surprise to the engineering team, because those tools were added years earlier for entirely reasonable reasons.
Schedule 2 amends the Freedom of Information and Protection of Privacy Act, and this is the part with the most concrete near-term effect on vendors, because it creates duties that institutions discharge partly through their suppliers.
The amendments introduce an obligation on institutions to have measures in place to protect the personal information in their custody or control, an obligation to conduct a privacy impact assessment before collecting personal information or where an existing collection changes, a duty to notify the Information and Privacy Commissioner of Ontario of theft, loss or unauthorized use or disclosure of personal information in prescribed circumstances, a duty to notify affected individuals in defined cases, and annual reporting of breach statistics to the Commissioner. The IPC also gains stronger review and order powers over these areas.
The privacy impact assessment requirement is the one that lands in your inbox. A PIA is an institutional document, written by the institution, but roughly two thirds of its content is facts about your system: what personal information is collected, from whom, for what purpose, on what legal authority, where it is stored, who can access it, what safeguards exist, what subprocessors are involved, how long it is retained, how it is disposed of, and what the risks are.
If you can hand the institution a complete, accurate, current data flow description and a controls summary on the first request, you shorten their PIA by weeks and you become easy to buy from. If they have to extract it from you question by question over two months, you become the reason the project slipped. Vendors underestimate how much goodwill this specific artifact buys. Our assessment builder covers the same ground for private sector impact assessments and produces a usable starting structure.
Breach notification to the IPC has the same clock consequence as the cyber security reporting above. The institution has a duty; your contract will compress your obligation to notify them so that they can meet theirs. Read the number, check it against your process, and negotiate it against confirmation rather than suspicion.
This is the part to state carefully, because Ontario has been bringing the pieces into force in stages and the picture at the time you read this may have moved.
Royal Assent was on 25 November 2024. The Schedule 2 amendments to FIPPA were brought into force ahead of most of Schedule 1, in two steps: the whistleblower protections on 29 January 2025, and the substantive privacy duties on 1 July 2025. From that second date an institution has to protect personal information, conduct privacy impact assessments and report privacy breaches. The Enhancing Digital Security and Trust Act in Schedule 1, which carries the cyber security program and the artificial intelligence provisions, is still waiting on proclamation, so its obligations are not yet in force
For a vendor, this staging has a simple implication: the privacy side is live and the cyber and AI side is arriving through directives and procurement templates rather than through a single dated switch. You will see it first as new clauses and new questionnaire sections, not as an announcement.
Before you commit to a specific date or a specific requirement in a bid response, check the current status of the regulations and any applicable government directive. Ontario publishes its statutes and regulations on the provincial e-Laws site and the Information and Privacy Commissioner of Ontario publishes guidance as the pieces come into effect. Citing a requirement that is not yet in force, or missing one that is, both damage credibility with a procurement office that follows this closely.
Ontario public sector procurement has a recognisable shape, and Bill 194 mostly makes the existing shape heavier rather than introducing a new one.
Provincial procurement often runs through Vendor of Record arrangements, which are pre-qualified supply arrangements you compete to get onto, followed by second-stage competitions among the qualified suppliers. Getting onto a VOR is itself a review, and the security schedule at that stage is where a lot of the work happens. Broader public sector bodies, including municipalities, school boards and colleges, run their own competitive processes with their own templates, and they vary considerably in sophistication.
Whatever the vehicle, expect some combination of the following. A security schedule attached to the agreement with specific control obligations. A privacy schedule dealing with FIPPA or MFIPPA obligations, records in the institution's custody or control, and access request cooperation. A requirement to support or supply input to a privacy impact assessment. A threat and risk assessment, either performed by the institution or required from you. Vulnerability assessment or penetration test results with a remediation status. Hosting location and subprocessor disclosure. Incident notification terms. Audit rights. Insurance certificates. Business continuity evidence. Increasingly, an AI declaration.
Two Ontario-specific quirks are worth knowing. First, records you hold on behalf of an institution may be in the institution's custody or control for access-to-information purposes, which means a member of the public can file a request that ultimately requires you to produce material. Your contract will oblige you to cooperate and you should make sure someone internally owns that. Second, institutions are subject to the Commissioner's order-making powers, so a privacy complaint about your system can end with a binding order directed at your customer that only you can implement.
Our guide to selling software to the Canadian public sector goes through the full document set across federal, provincial and municipal buyers.
The following list is what removes round trips. Every item on it is something a serious Ontario public sector buyer will ask for, and every item takes longer to produce reactively than proactively.
A current data flow description covering every category of personal information, where it is collected, where it is stored, which subprocessors can reach it, and the retention period for each. A subprocessor register with the purpose, location and status of each entry. A controls summary mapped to whichever framework you run, so the institution can tie your answers to something recognized. Evidence of an independent assessment: a SOC 2 Type II report, an ISO 27001 certificate, or at minimum a recent penetration test with remediation status.
An incident response plan with the public sector notification path and clock written into it, and evidence you have exercised it. A business continuity and disaster recovery position with stated recovery objectives and evidence of a tested restore, not a policy stating that backups are taken. A retention and disposal schedule with evidence that disposal produces a record. An AI component inventory as described above. Proof of cyber liability insurance with limits. A named security contact who is a person rather than an inbox.
On residency, have a clear answer. Ontario has no general statutory requirement that public sector data be stored in Canada, but institutional policy frequently requires it and the safest position in a bid is Canadian hosting with the region named. If part of your stack cannot be in Canada, say which part, why, what the data is, and what protections apply, rather than leaving the reviewer to discover it. Our data residency guide covers how to answer that honestly.
The single highest-leverage item on this list is the data flow description, because it feeds the privacy impact assessment, the threat and risk assessment, the security schedule and the AI declaration simultaneously. Write it once, keep it current, and send it unprompted.
There is no Bill 194 certification and there will not be one. Nothing in the Act creates an attestation a vendor can obtain, and any firm offering you a Bill 194 certificate is selling you something that does not exist.
What the Act does is raise the evidence bar for a set of controls you probably already have or already need. If you run a SOC 2 or ISO 27001 program, the overlap is high: access control, logging, encryption, incident management, vendor management, business continuity, change management, and risk assessment all serve both. The gaps that Bill 194 exposes tend to be the specifically public sector ones: the privacy impact assessment input, the access-to-information cooperation obligation, records custody and control, and the AI inventory.
If you also sell into Ontario health care, run one control set that satisfies PHIPA, the institutional security schedule and the audit framework together rather than three parallel efforts. If you sell to federally regulated financial institutions as well, the OSFI expectations cover much of the same territory with different vocabulary. The mapping exercise is unglamorous and it is the difference between answering the ninth questionnaire in two days and answering it in two weeks.
The other thing worth building is a standing answer set: the questionnaire responses, the artifacts, and the named owner for each, kept current on a schedule rather than reconstructed per bid. Public sector procurement is slow and repetitive, which makes it exactly the environment where that investment pays back.
Answering "Bill 194 does not apply to us". Correct and useless. The institution knows it applies to them. They are asking what you can give them.
Declaring no AI when the product contains a model. The definition is broad, the review will find it, and the credibility cost exceeds the disclosure cost.
Accepting an immediate incident notification clause. It creates a contractual breach every time your monitoring fires. Negotiate the trigger to confirmation and the clock to something your on-call process can actually hit.
Treating the privacy impact assessment as the institution's problem. Two thirds of its content is facts about your system. Whoever holds those facts controls the timeline.
Untested continuity and incident plans. Public sector reviewers increasingly ask for the test record rather than the document, and an untested plan reads as an unmet commitment.
Ignoring records custody and control. Access-to-information requests can reach material you hold for an institution. Somebody at your company should know that before the first one arrives.
Assuming the requirements are static. The substance of the Act lands in regulations and directives. Check the current position before quoting a specific obligation in a bid.
| Institutional obligation | What the vendor is asked for | Where it comes from |
|---|---|---|
| Cyber security program and standards | Controls summary mapped to a recognized framework, independent report or certificate, penetration test with remediation status. | Enhancing Digital Security and Trust Act, 2024, through regulations and government directives. |
| Cyber security incident reporting | Contractual notification clock shorter than the institution's own, an incident response plan, and evidence it has been exercised. | Enhancing Digital Security and Trust Act, 2024. |
| Artificial intelligence accountability and transparency | AI component inventory, data used, training commitments, human review points, notice before adding a new model or provider. | Enhancing Digital Security and Trust Act, 2024. |
| Digital information about individuals under 18 | Data minimization position, retention limits, third-party SDK disclosure, no secondary use for analytics or advertising. | Enhancing Digital Security and Trust Act, 2024, aimed at school boards and children's aid societies. |
| Privacy impact assessment before collection | Complete data flow description, purposes, subprocessors, safeguards, retention and disposal, in writing and current. | FIPPA, as amended by Schedule 2 of Bill 194. |
| Breach notification to the IPC and to individuals | Vendor notification clause with a defined trigger and clock, plus a named contact and a written incident timeline. | FIPPA, as amended by Schedule 2 of Bill 194. |
| Measures to protect personal information | Encryption, access control, logging, vendor management and the evidence that each operates. | FIPPA, as amended by Schedule 2 of Bill 194. |
Not directly. The Strengthening Cyber Security and Building Trust in the Public Sector Act, 2024 binds Ontario public sector entities: FIPPA and MFIPPA institutions, school boards and children's aid societies. Private companies encounter it as suppliers. Because the institution has to demonstrate it meets its obligations for systems it did not build, the requirements arrive as procurement terms, security schedules, questionnaires and privacy impact assessment requests.
No. The Act creates no attestation, certificate or registry for vendors, and none is planned. What buyers accept as evidence is the usual set: a SOC 2 Type II report, an ISO 27001 certificate, a recent penetration test with remediation status, and specific artifacts such as a data flow description, a subprocessor register and an AI component inventory. Any offer of a Bill 194 certificate is a marketing invention.
Schedule 1 enacts the Enhancing Digital Security and Trust Act, 2024, which creates authority to impose cyber security requirements, artificial intelligence requirements and requirements about the digital information of individuals under 18 on public sector entities, mostly through regulations and directives. Schedule 2 amends the Freedom of Information and Protection of Privacy Act to add an information security duty, privacy impact assessments before collection, breach notification to the Information and Privacy Commissioner of Ontario and to affected individuals, and annual breach reporting.
Probably, if it contains any machine learning or model-driven component that produces outputs influencing a decision. That includes scoring, ranking, classification, optimization and assistant features, whether the model is yours or a third party API. The safe approach is to inventory every such component, describe what it does and what data it processes, and disclose it, rather than answering no because the product is not marketed as AI. Reviews find these components, and the credibility cost of a late discovery is higher than the disclosure.
The Act does not impose a general data residency rule. Residency requirements in Ontario public sector deals come from institutional policy and procurement templates rather than from this statute. In practice many institutions require Canadian hosting anyway, so the safest bid position is a Canadian region named explicitly, with any component that cannot be hosted in Canada identified along with what data it touches and what protections apply.
The assessment belongs to the institution, but most of its content is factual detail about your system: what personal information is collected, from whom, for what purpose, where it is stored, who can access it, which subprocessors are involved, what safeguards apply, and how long it is retained. Vendors who maintain a current data flow description and controls summary and send them on the first request routinely cut weeks out of the institution's timeline. Vendors who supply it piecemeal become the reason the project slipped.
They cover different information. PHIPA governs personal health information held by health information custodians in Ontario, including hospitals in their custodian capacity. FIPPA, as amended by Bill 194, governs personal information held by provincial institutions, and MFIPPA covers the municipal sector. A hospital can be subject to both regimes for different information. If you sell clinical software, PHIPA remains your primary statute and the Bill 194 obligations sit alongside it on the institutional side.
A current, accurate data flow description covering every category of personal information, its purpose, its storage location, the subprocessors that can reach it and its retention period. It feeds the institution's privacy impact assessment, the threat and risk assessment, the security schedule and the AI declaration at the same time, and it is the artifact whose absence causes the most delay in an Ontario public sector review.
traztech Workspace has every control of whichever frameworks apply to you, written in plain English, with somewhere to attach the proof. Free to use, with no card and no trial clock.
No credit card, no trial clock, no locked features. We make money when someone wants help closing the gaps, not from the Workspace.
| traztech Workspace | Other GRC platforms | |
|---|---|---|
| Licence cost | $0. Free forever, no card, no paid tier | $7,500 to $50,000 a year, on an annual contract |
| Control library, evidence register, policy templates, risk register, vendor questionnaires, readiness scoring | Included | Included |
| What it costs inside an engagement with us | $0. You need a workspace either way | Unchanged. The subscription sits on top of the fee |
| What it does to your audit quote | $11,000 off a five-figure quote on one engagement, for a documented readiness position | Nothing. The audit firm prices your readiness, not your tooling |
Pricing in the right column is what compliance automation platforms are publicly reported to charge; none of them publish a number, so treat it as a range rather than a quote. The $11,000 came off the audit firm's own number once the readiness position was documented (the engagement). Where a paid platform is the better buy, and the fuller comparison, is on the Workspace page.
We build the artifact set a public sector review asks for, and run the framework work behind it, so one control set answers the security schedule, the privacy assessment and the AI declaration.
Book a strategy callWant the human version?
Jacob sends a few short, practical notes on getting security and compliance right without the months of pain. No fluff, unsubscribe in one click. Reply anytime; it reaches him directly.
From Jacob Masse, founder of traztech. No spam, unsubscribe in one click.
Track record
Five published CVEs. CVE-2024-45163 (CVSS 9.1) is a flaw in the Mirai botnet itself, which gave defenders a way to shut down attacker infrastructure. CVE-2026-42626 takes HP ENVY 5000 printers offline from any unauthenticated device on the same network.
At Humera, a venture-backed US security company, Jacob built the compliance programme in-house from nothing: no report, no policies, no documented controls. It ended in a Type II attestation across 76 controls with zero exceptions, on a team of 15.