Guide: assess your public website's technical posture in the context of Quebec Law 25

Quebec's Law 25 modernizes the province's personal information framework. It strengthens transparency, consent, security, and accountability obligations for organizations.

The main phases took effect in September 2022, September 2023, and September 2024. In 2022, several immediate obligations around governance and confidentiality incidents began to apply. In 2023, organizations were expected to make privacy notices easier to access, strengthen impact-assessment practices, and clearly designate the person responsible for personal information protection. In 2024, further expectations followed, including mechanisms related to portability and better circulation of information for individuals.

In practice, that means documenting data practices more carefully, explaining processing more clearly, overseeing vendors and hosts, and applying proportionate safeguards. Penalties can be significant: depending on the legal pathway, figures up to CA$25 million or 4% of worldwide turnover are part of the framework often discussed around the law.

The service is aimed at any organization that wants a structured technical readout of its public website: IT teams, privacy leads, consultants, or decision-makers. For an IT team, it can quickly surface technical gaps, external dependencies, and likely priority fixes. For a privacy lead, it provides a factual basis to document hosting, trackers, public-facing notices, and what a visitor can actually observe. For consultants and decision-makers, it helps frame the right questions, prioritize follow-up work, and track how a site evolves over time.

The output is a shared factual baseline, not a final legal position.

After a scan, each category shows a percentage and a colour: green when observed checks are broadly favourable, amber (orange / yellow) when some items need attention, and red when marked technical gaps are detected.

The percentage summarizes the observable checks that were run, not full legal compliance. A higher score mainly means fewer technical issues were seen in the tested areas; a lower score draws attention to concrete problems or missing public information.

A practical reading order is: red first (blocking or risky issues), amber next (hardening, documentation, incomplete settings), green last (maintenance and monitoring). For example, an expired certificate, no visible banner while non-essential trackers are active immediately, or no clearly found privacy policy would usually come before a CSP that is only partially optimized or a DMARC record still in monitoring mode. Conversely, a green result does not remove the need for follow-up, because a hosting change, marketing tag, or site redesign can quickly change what these tests observe. The detailed report then explains what was seen, often gives an example result, and helps separate urgent fixes from items that are mainly about internal documentation.

This group describes the site's domain infrastructure. In plain language, it looks at how the site is found on the Internet, who seems to host it, and how its email is protected.

What is examined:

• DNS — think of it as the Internet's directory: it links the site's name to technical addresses (A/AAAA, NS, CNAME) and helps show whether the setup looks coherent.
• Registry and network — WHOIS/RDAP show public registration information, while ASN helps identify which network or provider appears to operate the infrastructure.
• Email — MX points to mail servers; SPF, DKIM, and DMARC help reduce email spoofing; BIMI can add a validated logo in some tools.

Why this matters: the goal is to document where the site appears to be hosted, which technical partners are involved, and whether domain-level mail protection looks minimal, decent, or in need of work.

Example outcomes: IP addresses and related countries, missing DMARC, incomplete SPF, or signs of an international CDN. You may also see that the domain points to several services, that a record looks orphaned, or that a foreign provider is part of the chain.

For a non-technical reader, an amber or red result here usually means: “there are technical dependencies or settings that need better explanation or documentation,” not automatically “the site is unlawful.”

These checks assess the site's HTTPS connection. In simple terms, they show whether the route between the visitor and the site is properly encrypted and whether that encryption looks modern or outdated.

What is examined:

• Certificate — this is the site's HTTPS identity card; the test checks whether it is valid, matches the domain, and has not expired.
• TLS protocols — these are the security “versions” spoken between the browser and the server; if old ones are still active, risk increases.
• Cipher suites — these are the actual methods used to encrypt traffic; some are strong, others are old or discouraged.
• Hardening — the test also looks for signs of a weak setup, known historical vulnerabilities, or missing protections.

Why this matters: the goal is not only to check whether the browser shows a padlock, but to understand whether transport protection is strong enough for a site that may handle or expose personal information.

Example outcomes: a certificate expiring soon, TLS 1.0 still enabled, or a modern setup limited to TLS 1.2 and 1.3. The report can also say that the certificate is valid while the overall security posture still needs hardening.

For a non-technical reader, a weak result here usually means: “the secure connection exists, but it could be much safer,” or in red cases: “the connection protection is weak or broken and should be fixed quickly.”

These checks read the site's HTTP security headers. In practice, they are small instructions sent by the site to the browser to tell it how to behave more safely.

In plain language, the main terms mean:

• CSP — tells the browser where it is allowed to load code, images, or styles from, so malicious content has a harder time slipping in.
• HSTS — tells the browser to always come back through secure HTTPS instead of the non-secure HTTP version.
• X-Frame-Options — helps stop another site from displaying your page inside a misleading frame.
• X-Content-Type-Options — tells the browser not to guess a file type when the server has already declared it.
• Referrer-Policy — limits what information about the previous page is shared when a visitor clicks to another site.
• Permissions-Policy — lets the site limit access to browser features such as camera, microphone, or location.
• Technology and version hints — these are traces that can reveal which CMS, server, or framework seems to be in use, sometimes even with a version number.

Why this matters: the goal is to see whether the site gives the browser enough basic safety rules to reduce common attack paths, and whether it exposes technical details it does not need to reveal.

Example outcomes: missing HSTS, a CSP that is too permissive, or a table showing which headers are present, absent, or need work. These are often focused server or app changes, but they can make a real difference.

This area observes trackers placed in the browser and simulates a first visit to see what happens before and after a consent choice.

In plain language:

• First-party cookie — comes directly from the site being visited.
• Third-party cookie — comes from an external service such as analytics, advertising, or social media.
• Secure — the cookie should only travel over HTTPS.
• HttpOnly — the cookie is less accessible to code running in the page.
• SameSite — limits some uses of the cookie when navigation starts from another site.

What is examined:

• cookies and browser storage visible on load;
• presence of a banner or preference center;
• non-essential trackers loading before consent, then after reject or accept actions;
• whether refusal appears to remain active across navigation.

Why this matters: the goal is to see not only whether cookies exist, but when they appear, whether the user's choice appears respected, and whether the site offers a real way to accept, refuse, or change that choice later.

Example outcomes: no banner at all, analytics cookies present immediately, a cookie count comparison before and after “reject all,” or only essential cookies remaining after refusal. For a non-technical reader, this answers a simple question: “does the site seem to ask permission before placing trackers that are not strictly necessary?”

This test looks for a privacy policy, extracts the detected text, and compares it against a theme checklist commonly associated with Law 25. Part of the mapping is assisted by a language model, but the goal remains to read what the site actually publishes.

What is examined:

• whether a dedicated page or clear link exists;
• mentions about purposes, rights, contact details, the responsible person, third parties, and transfers outside Quebec;
• overall clarity of the wording, important dates, and items not found in the analyzed policy text.

Why this matters: the goal is to help a team quickly see whether the policy looks complete, understandable, and concrete enough to support transparency expectations, without pretending to replace a legal review.

Example outcomes: the policy URL used, themes covered or missing, and short supporting excerpts. The report may also say that no policy was detected, that a page exists but stays vague, or that an important theme is mentioned without practical contact details or useful explanation.

For a non-technical reader, this section mostly answers: “does the site clearly explain what it does with personal information, and how people can get help or exercise their rights?”