Website privacy policy for an Ontario business: describe the site you actually run

A website privacy policy template knows nothing about your website. It does not know you added a booking widget last spring, that your contact form drops every enquiry into a Gmail inbox, or that the chat bubble in the corner sends each message to another company to write the reply. That is how a two-person accounting office ends up publishing a careful promise about the data its mobile app collects, without ever having owned a mobile app.

Under Canadian law, the privacy policy on your site has one job: tell visitors, in words they can follow, what the site collects, why, who else receives it and who to contact about it. I build and host websites for a living, so this is the builder's version: start with an inventory of what your site really does, then turn it into a policy a stranger can read in two minutes. It is general information from a web developer, not legal advice, and I say plainly where a lawyer belongs.

Which privacy law applies to an Ontario business website

For most private businesses in Ontario, the answer is the federal Personal Information Protection and Electronic Documents Act, known as PIPEDA. The Office of the Privacy Commissioner of Canada (the OPC) says in its summary of PIPEDA's requirements that the Act applies to private-sector organizations that collect, use or disclose personal information in the course of a commercial activity. The same page says Alberta, British Columbia and Quebec have their own private-sector laws in its place. Ontario is not on that list, so a law office in Hamilton, an accounting firm in Guelph, a garage in Brampton or a florist in Ottawa taking enquiries through a website is usually working under PIPEDA. "Personal information" in the Act means information about an identifiable individual, which covers the name, email address and phone number a visitor types into your form.

Health practices are the large exception. The OPC lists Ontario's Personal Health Information Protection Act as substantially similar to PIPEDA for personal health information. If you run a dental or medical practice and your booking form asks for the reason for the visit, read the Personal Health Information Protection Act, 2004 or ask a privacy lawyer which rules govern that form. For a vet clinic, the client's name and phone number are personal information whatever the dog's chart says.

What PIPEDA says a website privacy policy has to tell people

PIPEDA carries ten fair information principles in Schedule 1 of the Act. The one that produces the page called "Privacy policy" in your footer is Principle 8, openness. Clause 4.8.1 of PIPEDA's full text says people must be able to get information about your privacy practices "without unreasonable effort" and in a form that is "generally understandable". A 6,000-word wall of borrowed legalese meets neither test very well.

Clause 4.8.2 then lists what that information has to include. In plain English:

• The name or title, and the address, of the person accountable for your privacy practices, who takes complaints and questions.
• How someone can get access to the personal information you hold about them.
• What types of personal information you hold, with a general account of how you use them.
• A copy of any brochures or other material that explain your policies.
• What personal information you make available to related organizations, such as a subsidiary.

Three other clauses decide what goes into the policy too. Clause 4.1 says an organization must name an individual accountable for compliance, so "the management" is not an answer. Clause 4.2.3 says the purposes for collecting information should be given at or before the time of collection, which is why the short notice under the form matters as much as the long page in the footer. Clause 4.4 says you collect only what you need for the purposes you named. That one is the cheapest to follow: every field you delete from a form is a field you never have to explain or protect.

Start with an inventory of what your site collects

Before anyone drafts a sentence, list every place the site takes in information about a person. The list is usually longer than the owner expects, because some of the collecting happens out of sight. Here is the inventory I would walk through with a client.

Part of the site	What it usually collects	Who else may receive it
Contact or enquiry form	Name, email, phone, the message itself	Your email provider, plus any form service or CRM it feeds
Booking or scheduling widget	Name, contact details, appointment time, sometimes a reason for the visit	The booking company that runs the widget
Newsletter signup	Email address and the consent record	Your email marketing service
Analytics	Pages viewed, device and browser details, cookies or similar identifiers	The analytics provider, such as Google
Chat widget	The conversation, and often the page, IP address and browser	The chat company, and any AI provider that writes the replies
Payments	Name, billing details, card data	The payment processor
File uploads	Whatever the visitor attaches	Wherever the files are stored
Server and security logs	IP addresses, requested pages, browser type	Your host, and any security or bot-protection service in front of the site
Embedded maps, videos and fonts	The visitor's IP address and browser details, at minimum	The company serving the embed

Two rows on that table catch people out. The first is the embeds. A Google Map on your contact page or a YouTube video on your About page loads from someone else's servers, so the visitor's browser talks to that company the moment the page opens. The second is the chat widget. Many now pass each conversation to an AI model, and the visitor typing "my landlord changed the locks" has no idea where that sentence goes unless you tell them.

What that looks like on a real policy

Our own Exhibit A Media privacy policy is built from exactly this kind of inventory, and you can read it to see the shape. It names the company responsible and its Hamilton address. It says Stripe handles payments, that Google Analytics measures use only after a visitor accepts analytics, and that Cloudflare provides network delivery and bot protection. It says the site's AI chat assistant sends chat history to Anthropic to generate replies, and it asks visitors not to type confidential legal-matter details or health information into the chat. It even says the fonts are hosted with the site rather than fetched from a font service. That line exists because somebody checked.

Where to get the inventory

Your web developer should be able to produce this list in an afternoon, because they installed the parts. If nobody knows who installed the booking widget, you have a bigger question than privacy, the one in whether you actually own your website.

Third parties are where most template policies go wrong

A template cannot name the companies your site hands information to, because it has never seen your site. That gap matters under PIPEDA. Clause 4.1.3 says an organization is responsible for personal information it transfers to a third party for processing, and must use contractual or other means to protect it while the third party has it. Moving the data to a booking company does not move the responsibility.

The OPC's guidelines for obtaining meaningful consent set out what it expects here. Where third parties change often or are too numerous to list, the guidelines say organizations should at least specify the types of third parties information is shared with, and give more detail by other means, such as a layered page.

Some of the companies you rely on will insist on this in their own contracts. The Google Analytics terms of service say a site using Google Analytics must post a privacy policy, that the policy must give notice of the cookies or similar technology used to collect data, and that you must disclose the use of Google Analytics and how it collects and processes data. A policy that never mentions analytics on a site running it has a problem with Google as well as the OPC.

Consent belongs at the form, not only in the footer

Most visitors will never open your privacy policy page. They will see your form. That is why clause 4.2.3 puts the purpose "at or before the time of collection", and why the OPC guidelines ask organizations to emphasize the key elements.

For a contact form on a service business site, that means one or two plain sentences directly under the submit button. Something like: "We use these details to reply to your enquiry and, if you hire us, to run your file. We don't sell them. Our privacy policy explains who else handles them and how to ask for a copy." People read that notice. They do not read the footer.

Three of the OPC's principles translate directly into form design:

• Allow individuals to control the level of detail they get and when. On a website, that is the short notice at the form with a link to the full policy.
• Provide clear options to say yes or no. Under the guidelines, people cannot be required to consent to collection beyond what is necessary to provide the service.
• Make consent an ongoing process. If you add a chat widget next year, the policy and the notice change the same week.

Cookie banners belong under the same heading. The OPC guidelines say whether a choice should be opt-in or opt-out depends on factors such as how sensitive the information is and what people would reasonably expect. Whatever you choose, the policy should say what is set and how to decline it. A banner whose only button says "OK" gives the visitor nothing to decide.

Newsletter signups answer to a second law, CASL

The moment your site invites people to join a mailing list, a different statute enters the room. Section 6 of Canada's anti-spam legislation, usually called CASL, prohibits sending a commercial electronic message unless the recipient has consented, expressly or impliedly, and the message meets the prescribed content rules. Section 10 says that a request for express consent must set out, clearly and simply, the purpose of the consent and information identifying who is asking.

The CRTC, which enforces CASL, explained how that works on a form in Compliance and Enforcement Information Bulletin CRTC 2012-548. The bulletin says a consent request for commercial messages must not be bundled with a request to accept general terms and conditions, so a person can accept your terms while refusing your emails. It treats a separate tick box that the person must actively check as a compliant method. In practical terms:

• The newsletter box on your contact form starts unticked.
• It says what they are signing up for and who you are.
• Sending an enquiry does not quietly add anyone to your list.
• Your privacy policy says how people unsubscribe and what you keep after they do.

CASL governs whether you may send the email. PIPEDA governs what you do with the address.

When something goes wrong, keep a record of it

A privacy policy describes the plan for an ordinary day. PIPEDA also has rules for a bad one. Section 10.1 requires an organization to report to the Privacy Commissioner any breach of security safeguards involving personal information under its control where it is reasonable to believe the breach creates a real risk of significant harm to an individual. Section 10.3 requires a record of every breach, and the Breach of Security Safeguards Regulations say that record must be kept for 24 months after the organization determines the breach occurred.

The OPC's guidance on breach reporting sums it up as three obligations: report breaches that pose a real risk of significant harm, notify the affected people and relevant third parties, and keep records of all breaches, whether or not they present that risk.

On a website, the realistic breach is rarely a film-style hack. It is an old plugin nobody updated, a form that emails enquiries to a former employee's account, or three years of enquiries sitting in a mailbox nobody needs. Clause 4.5.3 of Schedule 1 says personal information that is no longer required should be destroyed, erased or made anonymous. Deleting old form submissions on a schedule is the least glamorous privacy measure you have, and one of the most useful.

That is why the work in what website maintenance should include belongs in the privacy conversation. A site nobody has patched in two years is a promise in the footer with nobody keeping it.

What a plain-English website privacy policy looks like

Once the inventory exists, the website privacy policy almost writes itself. This is the order I would use for a small service business, with each section kept short:

1. Who we are: the legal name of the business, the address, and the named person accountable for privacy, with a direct email.
2. What we collect, listed by the part of the site that collects it: forms, booking, newsletter, analytics, chat, payments, logs.
3. Why we collect it, one purpose per item, in the words you would use on the phone.
4. Who else receives it: the named service providers, or at least the types, and whether any of them use it for their own purposes.
5. Cookies and analytics: what is set, whether it waits for consent, and how to decline.
6. Emails: how newsletter consent works and how to unsubscribe.
7. How long we keep it, and how we delete it.
8. How to ask for a copy of your information or a correction.
9. How to complain, first to us and then to the Office of the Privacy Commissioner of Canada.
10. The date it was last updated.

Notice what is missing: a paragraph about "our commitment to your privacy" and three pages on data the business does not hold. If a sentence does not describe something your site does, cut it.

The policy also has to stay true. Every time someone adds a pixel, a chat bubble or a form, the inventory changes and so does the page. Put a line in the contract with whoever maintains the site: nobody installs a third-party script without updating the privacy policy in the same change. It is a dull rule, which is why it works.

Who should write the policy

Your developer owns the facts: the inventory, the list of third parties, what loads before consent and what waits. You own the purposes and the decisions: why you want each field, how long you keep enquiries, who in the office answers privacy questions. A lawyer owns the judgment calls: whether health privacy law applies, how professional confidentiality rules interact with your intake forms, and anything involving sensitive information or information leaving Canada.

For a garage or a florist with a contact form and analytics, a clear policy built from an accurate inventory may be enough. For a law firm, a paralegal practice, a dental or medical clinic, or anyone collecting sensitive details through the site, have a lawyer who practises privacy law review it. I spent 33 years as an Ontario paralegal, and that taught me to tell when a question has stopped being a website question.

Keep an eye on the statute itself too. The federal Justice Laws page for PIPEDA, current to 19 October 2026, lists a 2026 amendment (S.C. 2026, c. 3) adding a data mobility framework as not yet in force. That is a reason to put a review date on your policy rather than a reason to panic about it.

When you hire or interview a developer, ask for the inventory up front. It is one of the questions in how to choose a web developer that tells you quickly whether they know what they installed. If your site also has to meet Ontario's accessibility rules, the same developer conversation can cover the AODA website requirements. Both get easier when one person can say exactly what the site does.

If you would like a second pair of eyes on what your site actually collects, book a 30-minute call with us. We will go through the inventory with you in plain English. We won't draft legal advice, and we will tell you when it is time to call a lawyer.

Common questions

Does my small business website need a privacy policy?

If your Ontario business website collects personal information in the course of commercial activity, such as names and emails through a contact form, PIPEDA expects you to make your privacy practices readily available in an understandable form. The website privacy policy is the usual way to do that. Some third-party tools, including Google Analytics, also require a posted privacy policy in their own terms, so most business sites with a form or analytics need one.

Which privacy law applies to a business in Ontario?

For most private businesses in Ontario, the federal Personal Information Protection and Electronic Documents Act applies to personal information collected in the course of commercial activity. Ontario has no general private-sector privacy law of its own. Ontario's Personal Health Information Protection Act governs personal health information, so dental, medical and other health practices should check which law covers the health details their website forms collect.

Can I use a free privacy policy template?

A template can give you headings, but it cannot know what your site collects or which companies receive the data. Start with an inventory of every form, widget, analytics tool, embed and payment service on the site, then edit the template until every sentence describes something your site really does. Delete anything that describes tools you do not use, and have a privacy lawyer review it if you handle sensitive information.

Do I have to mention Google Analytics in my privacy policy?

Yes, if your site uses it. The Google Analytics terms of service say sites using the product must post a privacy policy, give notice of the cookies or similar technology used to collect data, and disclose the use of Google Analytics and how it collects and processes data. Say whether analytics waits for the visitor's consent, and explain how a visitor can decline or opt out.

Can my contact form add people to my newsletter?

Not automatically. Canada's anti-spam legislation requires consent before you send commercial electronic messages, and the CRTC says a request for that consent must not be bundled with general terms and conditions. Use a separate, unticked checkbox that the visitor actively checks, say what they are signing up for and who is sending it, and give every message a working unsubscribe link.

How often should I update my website privacy policy?

Update it whenever the website changes what it collects or who receives it, such as when you add a booking widget, chat tool, tracking pixel or new form. Review it at least once a year even if nothing obvious changed, and show the last-updated date on the page. A policy that describes last year's website gives visitors an inaccurate account of where their information goes.

Sources

• Office of the Privacy Commissioner of Canada, PIPEDA requirements in brief (accessed 9 November 2026)
• Personal Information Protection and Electronic Documents Act, S.C. 2000, c. 5, Justice Laws Website, current to 19 October 2026 (accessed 9 November 2026)
• Office of the Privacy Commissioner of Canada, Provincial laws that may apply instead of PIPEDA (accessed 9 November 2026)
• Personal Health Information Protection Act, 2004, S.O. 2004, c. 3, Sched. A, Ontario e-Laws (accessed 9 November 2026)
• Office of the Privacy Commissioner of Canada, Guidelines for obtaining meaningful consent (accessed 9 November 2026)
• Google Analytics Terms of Service (accessed 9 November 2026)
• Canada's anti-spam legislation, S.C. 2010, c. 23, Justice Laws Website (accessed 9 November 2026)
• CRTC, Compliance and Enforcement Information Bulletin CRTC 2012-548 (accessed 9 November 2026)
• Breach of Security Safeguards Regulations, SOR/2018-64, Justice Laws Website (accessed 9 November 2026)
• Office of the Privacy Commissioner of Canada, What you need to know about mandatory reporting of breaches of security safeguards (accessed 9 November 2026)