Guide: assess your public website's technical posture in the context of Quebec's privacy law (Law 25)
The service is not legal advice and does not certify compliance with Quebec personal information protection rules (commonly called Law 25) or any other law. It provides a factual baseline for internal discussion.
Personal information protection in Quebec: what does “Law 25” mean?
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.
Who is this tool for?
The output is a shared factual baseline, not a final legal position.
How to read the results
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 (Content Security Policy) that is only partially optimized or a DMARC (Domain-based Message Authentication, Reporting and Conformance) 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.
Domain name analysis
This result describes the public identity of the domain name: which network announces it, what the registration databases show, and hints about where servers appear to run.
Operator network (apparent host)
The ASN (Autonomous System Number, the network's public identifier on the Internet) identifies the network that announces your site on the Internet. The description beside it usually matches your hosting provider or an intermediary—the right contact for connectivity or cloud tickets.
Registrant and contacts (WHOIS / RDAP)
The WHOIS directory (legacy domain listings) or the modern RDAP (Registration Data Access Protocol, standardized access to registration data) lists public fields such as apparent registrant and admin or technical contacts. Some lines may be redacted or generic depending on registrar policy.
Registrar (accredited registration company where the name is managed)
This is the company where the name is registered, renewed, and billed. It also controls transfer locks and move requests between registrars.
Creation and expiry dates
They show how long the name has existed and until when it remains paid. A soon expiry date is a reminder to renew to avoid losing the website or email.
Transfer lock (anti-hijack)
The line states whether the name is locked against an unwanted transfer to another registrar. Without a lock, a compromised account makes domain theft easier.
Country tied to the site's IP addresses
From the public IP (Internet Protocol) addresses seen for your site, the report shows an apparent country for hosting or transit. It helps map infrastructure, not prove a legal processing location.
CDN (content delivery network)
If a CDN (Content Delivery Network) is detected, content may be served from cached nodes in many countries; the report flags the visible delivery chain.
Signals outside Quebec
A section may flag items that appear linked to another country or region (hosting, transit, or classification) to support vendor and data-flow documentation.
Reading the colours Green is broadly reassuring. Amber means verify that line with your team or registrar (missing data or unclear situation). Red highlights something urgent to fix.
This block explains how the site's name is wired to the Internet: which addresses answer, who answers DNS (Domain Name System) queries, and whether anything looks inconsistent or abandoned.
Site addresses (DNS A and AAAA records)
A (address record, IPv4) and AAAA (address record, IPv6) records show which IP addresses the analyzed name points to. If only IPv4 is present, the report may show an informational note about IPv6 without lowering the score.
Name servers (NS)
NS (Name Server) records list the servers authoritative for your domain's DNS. They are usually your host, registrar, or managed DNS provider.
Aliases and subdomains (CNAME, etc.)
The report reviews common aliases (often a CNAME, Canonical Name alias) that point a name to another service (site, email, CDN). Poor aliases can cause loops or surprises when you change vendors.
Reverse DNS (PTR)
PTR (Pointer record for reverse DNS) checks sometimes compare an IP to a reverse hostname. Useful to spot mismatches between what you think you host and what reverse DNS advertises.
Orphan or suspicious records
The report flags names that seem to point nowhere, to old services, or that do not match the rest of the zone—cleanup and security hints.
DNSSEC (informational)
When DNSSEC (DNS Security Extensions) signatures are detected, the report may note it as information: it strengthens authenticity of DNS answers, but it is not required for every site.
Reading the colours “IPv6 recommended” or “DNSSEC seen” notes are mainly improvement hints. Items in amber or red deserve a quick review with whoever manages your DNS.
This block describes how your domain sends and receives email from public DNS (Domain Name System) data: which servers are used, spoofing protections, and optional extras.
Mail servers (MX)
MX (Mail Exchanger) records list which servers receive mail for your domain. If the list is empty or inconsistent, mail may be lost or misrouted.
Mail origin
The same approach for the domain's mail tools: MX hosts are resolved to IPs, apparent countries are shown, plus SPF hints (include, ip4:) for sending servers. The detected mail tool (Microsoft 365, Google Workspace, OVH, etc.) is listed. If an IP appears outside Canada, a warning reminds you to confirm the real origin with your provider — GeoIP describes the visible tool, not legal data residency.
SPF (who may send as you)
SPF (Sender Policy Framework) is a DNS-published list of servers allowed to send mail that shows your domain as the sender. It reduces forged email in your name.
DKIM (message signatures)
DKIM (DomainKeys Identified Mail) adds a cryptographic signature to outgoing mail so recipients can check integrity and match a public key published in your DNS.
DMARC (policy when SPF/DKIM fail)
DMARC (Domain-based Message Authentication, Reporting and Conformance) tells large providers what to do when SPF or DKIM fails (monitor only, quarantine, or reject). It makes SPF and DKIM actionable at scale. The record is published as a TXT at _dmarc.yourdomain.com (v=DMARC1 — there is no « DMARC2 »). Loi25 reads that public DNS record; it does not parse XML reports in your mailbox (rua / ruf).
Show more — DMARC tags, Loi25 checks, and RFC 9989
Main tags
- p=: domain policy (
none,quarantine,reject). - sp=: existing subdomains (defaults to
pif omitted). - np= (RFC 9989): non-existent subdomains — helps against spoofing (
np=rejectornp=quarantine). - rua= / ruf=: aggregate (RFC 9990) or failure (RFC 9991) report addresses.
- aspf / adkim: relaxed or strict alignment.
- pct, rf, ri: historic — tolerated but not recommended (RFC 9989).
What Loi25 checks
Record presence, p= policy, sp= and np= tags, and historic tag flags. An informational « RFC 9989 alignment » indicator (no score impact) highlights np=reject or np=quarantine, similar to the post-quantum TLS readiness test.
Standard evolution
RFC 7489 is replaced by RFC 9989 (protocol), 9990 (rua reports), and 9991 (ruf reports). Existing records remain valid. « DNS Tree Walk » replaces the Public Suffix List for the organizational domain — mainly for mail operators, not for Loi25's DNS read.
BIMI (verified logo, optional)
BIMI (Brand Indicators for Message Identification), when prerequisites are met, can show a verified logo beside messages in some clients—a trust layer, not a baseline requirement.
DANE / TLSA for mail (optional)
When the DANE (DNS-based Authentication of Named Entities) approach is used, TLSA (TLS Association in DNS) records can tie SMTP (Simple Mail Transfer Protocol) transport security to your DNS. The report mentions them if visible; full deployment also needs solid server configuration.
MTA-STS (transport TLS policy, optional)
MTA-STS (Mail Transfer Agent Strict Transport Security) lets your domain publish a policy that requires remote servers to deliver mail to you only over validated TLS, preventing cleartext downgrades. It relies on two public artefacts: a small DNS (Domain Name System) record at _mta-sts.<your-domain>, and a policy file served over HTTPS (HTTP secured with TLS, Transport Layer Security) at https://mta-sts.<your-domain>/.well-known/mta-sts.txt. The report shows whether the policy is present and its mode (enforce applies the rule, testing only observes). It complements DANE and is especially useful with providers (Microsoft 365, Google Workspace, etc.) that do not support inbound DANE. A RFC (Request for Comments) is a technical specification published by the IETF; RFC 8461 defines MTA-STS in detail: the _mta-sts TXT format, the mta-sts.txt policy file, enforce / testing / none modes, max_age caching, etc.
TLS-RPT (TLS failure reports, optional)
TLS-RPT (TLS Reporting) asks sending servers to deliver JSON reports whenever a TLS connection to your mail fails or does not match your MTA-STS or DANE policy. In practice you publish a DNS record at _smtp._tls.<your-domain> pointing to a reporting endpoint (typically mailto:tls-reports@your-domain). It is a steering tool: it lets you observe real traffic before flipping MTA-STS to enforce. RFC 8460 standardizes TLS-RPT: the DNS name _smtp._tls, the rua tag for report destinations, and the JSON report structure from sending servers.
Reading the colours Missing or incomplete SPF, DKIM, or DMARC means schedule hardening with your email provider—not proof an attack already succeeded. Colours show apparent urgency. The MTA-STS and TLS-RPT rows are flagged as optional: they harden the SMTP chain but do not change the base score.
TLS encryption validation
This block matches the report's « TLS check »: the certificate the browser sees and the HTTPS (HTTP secured with TLS, Transport Layer Security) connection negotiated for the tested session.
Match with the address visited
The report checks that the certificate covers the domain or subdomain the visitor requested (including common variants). A mismatch can trigger browser warnings.
Issuer and trust chain
It identifies the certificate authority (CA, Certificate Authority) that issued the certificate and checks that the chain (intermediate certificates) is complete. A broken chain can fail on some devices.
Validity and expiry date
It states whether the certificate is still valid and how many days remain before expiry. Near or past expiry is a priority issue to avoid outages.
TLS (Transport Layer Security) version negotiated for the tested session
It records the protocol version actually negotiated for the analyzed session (for example a modern version). This complements the certificate view.
Reading the colours Expired certificates, incomplete chains, or name mismatches often show as red; amber may mean a soon expiry date or something to confirm with your host.
This block matches the report's « TLS/SSL security analysis »: protocol versions and ciphers still offered, checks for known issues, and other hardening settings.
Protocols still enabled on the server
The report lists TLS (Transport Layer Security) and legacy SSL (Secure Sockets Layer) versions that the server is still willing to accept. Older versions kept for compatibility increase downgrade risk.
Cipher suites (encryption algorithms negotiated)
It summarizes the strength of algorithms offered to encrypt the session (modern vs obsolete choices). Weak choices make interception or tampering more plausible.
Known-vulnerability checks
Targeted checks look for historical TLS or configuration flaws that can be observed from the outside. A poor result mainly means update configuration, not confirmed breach.
Forward secrecy (PFS, perfect forward secrecy)
The report may note whether the setup favours exchanges that also protect past sessions if a long-lived key is compromised later.
TLS compression and renegotiation
Settings such as compression on the tunnel or renegotiation have had misuse in the past; the report notes what it observes.
Reading the colours Green is broadly reassuring for the tested configuration. Amber means schedule hardening (versions, ciphers). Red highlights weaknesses that usually need quick fixes.
Security headers
HTTP security headers block These are small lines added to the server's HTTP (Hypertext Transfer Protocol) response; the browser applies them to reduce certain risks (injection, clickjacking, information leaks, and more).
CSP (Content-Security-Policy)
States where the browser may load scripts, styles, or media from. A stricter policy limits the impact of injected malicious code.
HSTS (HTTP Strict Transport Security)
Asks the browser to prefer HTTPS (HTTP over TLS, encrypted browsing) when returning to your site and reduces clear-text bounce paths.
Framing protection (X-Frame-Options or CSP equivalent)
Reduces the risk of another site embedding your page in an iframe for clickjacking-style attacks.
X-Content-Type-Options
Stops the browser from sniffing content types when that behaviour is undesirable, limiting some abusive executions.
Referrer-Policy
Controls how much of the URL or context is sent to the next site when a visitor follows a link.
Permissions-Policy
Lets you disable or narrow access to sensitive browser features (camera, microphone, geolocation, and more).
Other useful headers (Cross-Origin, etc.)
The report may mention additional headers that shape cross-origin behaviour (rules for browser requests across different sites). Each table row is one directive seen or missing.
Technology fingerprint block
Visible software fingerprint
The report picks up public clues (headers, banners, signatures) suggesting a CMS (content management system, e.g. WordPress), server, or framework, sometimes with a version. It is what an external observer can infer, not an internal inventory.
What you will see in practice
- A header-by-header table: present, missing, value, recommendation.
- Alerts when a baseline protection is missing or too permissive.
- A list or summary of detected technologies and how much detail is exposed.
Reading the colours Amber often means tighten or complete a policy; red highlights a major gap; green means common controls look broadly in place, without removing the need for ongoing review.
Privacy policy
Finding the page or link
The report looks for a dedicated page or a clear link to a policy from the analyzed URL (Uniform Resource Locator, the web address) and common locations (footer, legal menu, etc.).
Text used for analysis
It extracts readable text from that page (within technical limits) so the analysis reflects what a visitor can actually read online.
Themes compared in the report
Text is compared to a theme checklist often used for transparency, for example:
- processing purposes and stated bases;
- categories of information and data subjects;
- access, rectification, and withdrawal of consent;
- contact details and the person responsible for personal information;
- processors or third parties and transfers outside Quebec;
- retention, security, and complaints.
Assisted reading
Part of the theme mapping is automated to speed up review; the goal remains to reflect published content, not to guess unstated intent.
Evidence in the report
For each theme, the report may show short excerpts or state that nothing convincing was found in the analyzed text.
Reading the colours Missing policy or major missing themes: often amber or red for follow-up with legal or communications. A strong score does not replace human validation or legal advice.
Admin — Accounts and integrations
Management console — overview
The management console (sign-in required) lets you track domains covered by your subscription, schedule analyses, and manage team members. After signing in via the team login page, the dashboard lists watched domains, upcoming scheduled scans, and category scores (domain, TLS, headers, cookies, policy).
Add a domain
Click "+ Add domain". Enter the domain name without http://, https://, or www. (e.g. example.com). Pick the day of the month (1–31) for the automatic monthly scan (runs around 2 a.m. Montreal time). Choose report preferences: full report every month, monthly report plus alerts on changes, email only when changes are detected (with a chosen check frequency), or disable automatic scans. Confirm to save the domain, subject to your plan limits.
Edit a domain
On each table row, "Edit" opens the edit dialog: the next 12 scheduled scans, change the monthly scan day, and the same report preference options as when adding. "Scan" runs an on-demand scan for that domain. When a report exists, the domain name may link to the latest results in a new tab.
Manage the team
The "Manage team" button at the top (for team administrators only) opens a dialog to: view members and roles, invite a colleague by email, see pending invitations, set up passkeys for faster sign-in, transfer ownership to another member, or permanently delete the organization account (all domains and reports). The domain and member counters in the header reflect your contract and seats in use.
API — Automated scans
Access — get an account
The API is not open to the public. To use it, you first need an active authentication token. The process:
- Go to the home page.
- Click the "Contact me" button.
- Briefly describe your need (tool used, estimated scan volume, intended use).
- A token will be sent to you once your request has been reviewed.
Authentication
Every request must include the token in the HTTP header:
Authorization: Bearer your_token_here
Step 1 — Submit a scan
POST https://loi25.certi360.com/api/v1/scan
JSON body to send:
{"url": "example.com", "test_type": "policy"}
The url field accepts a domain (example.com) or a full URL (https://example.com/privacy-policy).
The test_type field sets the scope:
complete— all tests (~5–10 min)domain— domain name, DNS, email (~60–90 s)tls— certificate and TLS configuration (~30–60 s)headers— security headers (~30 s)cookies— cookies and consent (~60–90 s)policy— privacy policy, assisted analysis (~up to 3 min)
The API responds in under a second with a scan identifier:
{"scan_id": "20260420T143022Z_a1b2c3d4", "status": "queued", "status_url": "/api/v1/scan/20260420T143022Z_a1b2c3d4"}
Step 2 — Poll the status
GET https://loi25.certi360.com/api/v1/scan/{scan_id}
Repeat every ~10 seconds. While the scan is running, the response contains:
{"status": "running", "progress": {"done": 0, "total": 1}}
When status is "done", the response includes the full results (results) and per-category scores (percentages).
Full curl example
Submit then poll until results are ready:
TOKEN="your_token_here"
BASE="https://loi25.certi360.com"
Submission:
curl -s -X POST "$BASE/api/v1/scan" \
-H "Authorization: Bearer $TOKEN" \
-H "Content-Type: application/json" \
-d '{"url":"example.com","test_type":"policy"}'
Polling (replace SCAN_ID with the value received above):
curl -s "$BASE/api/v1/scan/SCAN_ID" \
-H "Authorization: Bearer $TOKEN"
Python example
A blocking call that waits for the scan to finish:
import time, requests
TOKEN = "your_token_here"
BASE = "https://loi25.certi360.com"
hdrs = {"Authorization": f"Bearer {TOKEN}"}
r = requests.post(f"{BASE}/api/v1/scan", json={"url": "example.com", "test_type": "policy"}, headers=hdrs)
scan_id = r.json()["scan_id"]
while True:
time.sleep(10)
data = requests.get(f"{BASE}/api/v1/scan/{scan_id}", headers=hdrs).json()
if data["status"] in ("done", "failed"): break
print(data["percentages"])
Response codes
- 202 — scan accepted and queued (response to submission)
- 400 — missing or invalid parameter
- 401 — missing or incorrect token
- 429 — rate limit reached (30 scans/h per IP)
- 503 — API not yet configured, or global capacity exceeded
Limits and responsible use
- Applies only to publicly accessible websites — not intranets or password-protected pages.
- Results are factual and technical: they are not legal advice.
- Never include the token in versioned code or application logs.
To get started, click "Contact me" on the home page and describe your integration project.
Frequently asked questions
Why is the domain section in three parts?
To mirror your scan report: apparent identity and hosting, basic DNS records, then email-related settings (mail servers and common anti-spoofing protections).
Why are cookies explained in four steps?
The report follows a typical visit: first landing, consent banner or preference centre, effect of reject or accept, then a short internal navigation to see whether the choice still appears respected.
Does the TLS section use sub-tabs?
Yes. Like the domain name section, the panel shows two tiles: TLS check (certificate and HTTPS connection), then TLS/SSL security analysis (configuration), matching the two blocks in the report.