Is this guide legal advice?

No. It explains in plain language what the technical report observes on a public website (domain, encryption, headers, cookies, policy). Legal and compliance decisions remain with your organization.

What do green, amber, and red mean?

They are reading aids: green means observed items are broadly favourable, amber highlights checks or hardening to plan, red flags marked gaps to prioritize. The percentage summarizes observable technical checks, not a legal attestation.

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.

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

Loi25.certi360.com offers a guided readout of your public website: domain name, secure connection, settings visible to the browser, cookies, and privacy policy wording. The goal is to help you see what a typical visitor can observe.

The service is not legal advice and does not certify compliance with Quebec's privacy law (Law 25) or any other law. It provides a factual baseline for internal discussion.

What is Quebec's privacy law (Law 25)?

Quebec's privacy law (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.

Who is this tool for?

The service is aimed at any organization that wants a structured technical readout of its public website: IT (information technology) 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.

How to read the results

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 (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

Same three-part layout as your scan report: domain identity, basic DNS (Domain Name System, the directory that maps names to technical addresses), then email.

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 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.

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 with mail that fails SPF or DKIM (monitor only, quarantine, or reject). It makes the previous controls actionable at scale.

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

Same two-part layout as your scan report: certificate and connection (the site served over HTTPS, HTTP secured with TLS—Transport Layer Security), then configuration strength (protocol versions and ciphers offered to the browser).

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.

Security headers

The report combines security headers sent with the HTTP (Hypertext Transfer Protocol) response and visible technology hints about the site's stack.

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.

Admin — Accounts and integrations

For organizations with a client account: two complementary tools — the management console (domain and team tracking) and the API (technical integrations). Access is granted on request via Contact me on the home page.

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

The public API v1 lets an external tool or application trigger scans and retrieve results programmatically, without going through the web interface.

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.

Open the analyzer