The short answer
Yes. Any Canadian business website with a form needs HTTPS. The old excuse - no payments, no need - ignores that a contact form collects personal information, and PIPEDA requires safeguards appropriate to its sensitivity. HTTPS protects data in transit. It is table stakes, not a security programme.
Ask a small business owner why their site is still on plain http and you will usually get the same sentence: I do not take payments on my site, so I do not need a certificate. It sounded reasonable for years. It was never quite right, and today it is clearly wrong. The reasoning is worth walking through, because it explains what HTTPS is actually for - and, more usefully, what it is not for.
What TLS actually gives you
HTTPS is HTTP carried over TLS. The current version of the protocol states its goal plainly: to provide a secure channel between two communicating peers, offering three properties [1].
- Authentication. The server side of the channel is always authenticated [1]. You are talking to the machine that holds the key for that domain, not one that merely answers to the name.
- Confidentiality. Data sent over the channel after it is established is visible only to the endpoints [1]. Notably, TLS does not hide the length of what it transmits [1] - encryption is not invisibility.
- Integrity. Data sent over the channel cannot be modified by attackers without detection [1].
These are meant to hold even against an attacker with complete control of the network [1]. That last clause is the one that matters for a small business, because the network between your customer and your server is not yours. It includes a coffee shop wireless connection, a hotel network and a handful of intermediaries you will never meet.
The HTTP specification is equally direct about what the https scheme means. It identifies a resource on a server capable of establishing a TLS connection, and in that context "secured" means specifically that the server is authenticated as acting on behalf of the identified authority, and that all HTTP communication with that server has confidentiality and integrity protection [2].
Why the "no payments" argument died
The excuse assumed that the only sensitive thing a website could carry was a credit card number. But most small business sites move personal information every day without processing a cent.
A contact form carries a name, an email address and often a phone number and a description of somebody's problem. A booking form carries an address. A quote request for a roofing company carries where you live and what is wrong with your house. All of that is personal information collected in the course of commercial activity.
Canadian privacy law addresses this directly. Principle 7 of PIPEDA's Schedule 1 requires that personal information be protected by security safeguards appropriate to the sensitivity of the information [6]. Those safeguards must protect against loss or theft as well as unauthorized access, disclosure, copying, use or modification, and organizations must protect personal information regardless of the format in which it is held [6]. The Act goes on to list the methods of protection, and technological measures are named explicitly, with the use of passwords and encryption given as the examples [6].
The word doing the work is appropriate. Nothing in the statute says "install a certificate". It says the nature of the safeguards will vary with the sensitivity, amount, distribution and format of the information [6]. But when the accepted, standardised, effectively free way to protect data in transit is sitting there unused, it becomes very hard to argue your safeguards were appropriate to anything. The Privacy Commissioner publishes practical compliance material for organizations working through these obligations [8].
There is a second, entirely non-legal reason the excuse collapsed. Browsers stopped being neutral about it. Open your own site in any current browser and submit a form on a plain http page - you will be told, on the page, that the connection is not secure. You do not need to take anyone's word for this; go and look. Whatever you think of the risk, your customers are being shown a warning at the exact moment you are asking them to trust you.
What HTTPS does not protect - the honest part
This is where a lot of security writing goes soft, so let us be direct: HTTPS is table stakes, not security.
TLS protects the channel. It says nothing about what happens once data arrives. The HTTP specification makes the point itself: most security concerns related to HTTP semantics are about securing server-side applications - the code behind the HTTP interface - or securing how a browser processes received content, rather than the security of the protocol [2]. The specification then devotes pages to injection attacks, noting that data received in a request cannot be trusted and that this class of vulnerability is extremely common in spite of being easy to prevent [2].
So a site with a valid certificate and a form handler that pastes user input straight into a database query is still insecure. Perfectly, completely insecure - over an encrypted connection. The padlock has genuinely misled people into believing otherwise, and it is worth saying out loud to anyone who treats the certificate as the finish line.
The same limit shows up in the strict transport security specification, which lists what it does not remedy: phishing, and malware or browser vulnerabilities [3]. Malicious code running on a user's machine can compromise their session regardless of whether transport security is in place [3]. A certificate on your domain does not stop somebody registering a similar-looking domain and getting a certificate for that one too.
The cost argument is over
Certificates used to be a purchase, verified by a collection of ad hoc mechanisms and a certification authority's manual process. That changed when the industry standardised the exchange: there is now a published protocol a certification authority and an applicant can use to automate the process of domain verification and certificate issuance, including revocation [5].
Automation is why the price went to roughly nothing for ordinary websites, and why "we could not justify the cost" no longer survives a conversation with your host. Ask what is included before you buy anything.
The four ways it actually breaks
Having a certificate and having working HTTPS are different states. Four failure modes account for almost everything we see on small business sites.
Mixed content. A secure page that loads an image, stylesheet or script over an insecure connection. It is not cosmetic. Stylesheets and scripts can control the page that embeds them, so a single insecure embedding anywhere on a site can compromise the security of a page whose own markup you scrutinised carefully - because an attacker can inject code through the insecurely loaded resource [3]. This usually arrives when someone pastes in an old widget or a hard-coded http image path.
Expired certificates. Every certificate has a validity period expressed as two dates, notBefore and notAfter, and it is valid from one through the other inclusive [4]. Expiry is a designed feature, not a malfunction, which means renewal is an operational task somebody has to own. Automate it, then monitor it from outside your own server, because a renewal script that silently stopped running looks identical to one that is working right up until the morning it does not.
The http version left live. This is the subtle one. Resources served over http and over https have no shared identity - they are distinct origins with separate namespaces [2]. If your server still answers on port 80 with the real site rather than a redirect, you are running two copies of your website, and only one of them is protected. Redirect everything.
Long redirect chains. A request that goes from http to www to https to a final address passes through at least one insecure hop, which is exactly the window an active network attacker wants. Strict transport security exists to close it, by letting a site declare that browsers should interact with it only over secure connections [3]. Aim for one redirect that lands directly on the final secure address.
The breach obligation waiting behind all of this
If personal information does escape, Canadian law has requirements that apply whether or not you noticed. Where a breach of security safeguards creates a real risk of significant harm, it must be reported to the Privacy Commissioner and affected individuals notified, and the regulations set out exactly what those reports and notifications must contain [7].
The part small businesses miss is the record-keeping. An organization must maintain a record of every breach of security safeguards for 24 months after determining it occurred [7]. Not every reportable breach - every breach. That obligation exists regardless of severity, and the record must contain enough information for the Commissioner to verify compliance [7].
When you genuinely do not need it
Here is the concession. If your site is a truly static page - your name, what you do, a phone number, no forms, no logins, no analytics, no embedded map, no third-party fonts - then there is no personal information in transit for TLS to protect, and the privacy argument does not apply to you.
That site is rarer than owners think, because embeds collect data quietly. And the practical case still points the same way: your host almost certainly includes the certificate, browsers penalise plain http regardless, and going without saves you nothing. Correct on principle, pointless in practice.
Do this this week
Type your own domain four ways - with and without www, with http:// and with https:// - and confirm all four land on the same secure address. Then open a page with a form on it and check your browser is not flagging insecure content. If any of the four fails, or the form page shows a warning, send those exact URLs to whoever runs your hosting. It is a configuration fix, usually a short one, and it is the cheapest security work available to you.