Privacy Policy — RiskLink Radar
Last updated 30 September 2026
RiskLink ("we", "us") operates RiskLink Radar ("Radar"), a cyber risk monitoring platform for insurance brokers at radar.risklink.io. This policy explains what information we hold, why, who can see it, and the choices available. Questions and requests: support@risklink.io.
1. Definitions
- Portal user — an individual with a Radar account: brokerage staff we have invited at a brokerage's request, and RiskLink personnel.
- Brokerage — an insurance brokerage granted access to Radar.
- Monitored organisation — a commercial client submitted by a broker for monitoring. Its staff do not use the portal; we hold information *about* it.
- Submitting broker / owner — the portal user who submitted a monitored organisation.
2. Information we collect
Account information — name, work email, role, brokerage; provided through the invitation you accepted. Radar has no self-registration.
Submission information — about each monitored organisation: legal name, public internet domains, industry, approximate annual revenue band, policy renewal date if provided, a business contact (name, work email, role), and documents the broker uploads (for example completed insurance applications).
Consent records — the exact confirmation wording a broker accepts when submitting a client, with time and identity (see section 5).
Breach-exposure records — where credentials belonging to a monitored organisation's staff accounts appear in third-party breach corpora or information-stealer logs, obtained from commercial and proprietary intelligence sources. We retain the account identifier (usually a work email address), a masked form of the credential showing at most its first characters and its length, its strength category, the source and date of the breach, and whether the exposure is recent. Full credentials are never retained: where a record is unlocked, the credential is masked in the moment it is read and only the masked form is stored. It is never written to our logs, our audit records, or any error message.
The same records may be found in unstructured sources — raw leak files and information-stealer logs, and posts on dark web forums and marketplaces that mention a monitored organisation. Where the source is unstructured text, an automated language-analysis service is used to identify candidate records within it. That service receives the retrieved text and returns structured candidates; credentials are masked before storage in every case, and the masking is re-applied by our own software to whatever the service returns. We do not retain the source text: what is kept is the structured record and a short, masked extract showing why the record was proposed. Candidates identified this way are marked as such and are reviewed by a person before they appear in any report or are shown to a broker. Where a dark web post is recorded, we retain its title, its source and a reference to it, and not a copy of its contents.
Scan-derived information — observations of the monitored organisation's *external, internet-facing* systems: public DNS records, publicly reachable services and their software versions, TLS certificates, email-authentication records, and similar information visible from the public internet. Scanning is non-intrusive: nothing is installed, no credentials are used, no private network is accessed. Findings are compiled into reports and a numeric risk rating.
Usage and audit records — sign-ins and privileged actions (invitations, access grants and revocations, status changes, report uploads, downloads of reports and documents, account and role changes, terms acceptance) recorded with actor, timestamp, and the internet address and browser identification the request was made from. Our authentication provider keeps its own separate record of sign-in attempts. Unsuccessful sign-in attempts are recorded in our application logs rather than in this record.
Briefing views — when a broker views a released broker briefing in the portal, we record when it was shown to them, which of its objections they expanded (by position, not content) and when they opened it to print. We use this to follow up with brokers and improve the briefings. It is visible only to RiskLink administrators, never to other brokers, and RiskLink's own views are not recorded.
Confirmed devices — when you sign in with your password on a browser we have not seen before, we email you a code to confirm it is you. Once you have answered it we keep a record of that browser so you are not asked again: a random identifier stored only as a one-way hash, a short description such as "Chrome on macOS", and when it was created and last used. We do not keep the identifier itself, so this record cannot be used to sign in. You can see your confirmed browsers and remove any of them at any time; a removed one is marked as removed rather than erased, so that the record of what had access remains.
Support correspondence — messages you send to support@risklink.io.
Technical data — standard web logs (IP address, browser type, timestamps) generated by our hosting providers in operating the service.
3. What we do not collect
No payment card data, no government identifiers, no consumer credit information, no biometric data, no data about individuals beyond the business-contact details above. We do not sell or rent information, do not use it for advertising, and do not train machine-learning models on your data.
4. Who can see what — the access model
Radar is built around per-broker confidentiality:
- A monitored organisation's record is visible to **the broker who submitted it, and to any portal user that broker explicitly grants access to** — a colleague at the same brokerage or a partner at another. Grants are revocable by the owner at any time; revocation is immediate.
- Other brokers cannot see it — including administrators and colleagues at the submitting broker's own brokerage, unless granted.
- Brokerages cannot see each other's activity in any form. Radar is designed not to reveal, even indirectly, whether another brokerage monitors a given organisation.
- RiskLink personnel can access records as necessary to provide the service — running scans, preparing and quality-checking reports, providing support, and maintaining security. RiskLink analyst staff are restricted to the specific clients assigned to them, and hold no access until an assignment is made. Access within RiskLink is limited to what is needed to provide the service. Privileged actions and file access are logged, including our own.
- Every grant, revocation, privileged action, and download of a report or document is recorded in an audit log retained independently of the records it concerns.
5. Consent for monitoring
Monitoring begins only after the submitting broker confirms, at submission, that the monitored organisation has authorised external scanning and that the broker is authorised to confirm this on its behalf. The confirmation's exact wording, time, and author are retained as the authority for that monitoring. A monitored organisation may verify or withdraw this authorisation at any time via its broker or support@risklink.io; withdrawal stops future scanning. Reports already delivered remain with the broker who commissioned them.
6. Automated risk ratings
Risk ratings are computed automatically from the count and severity of findings in a report, on a published 0–100 scale with letter bands. A rating is informational: it triggers no automated decision about any individual, and its inputs are visible to the broker alongside every report. Ratings are recomputed when a report is revised; prior ratings are retained as history rather than overwritten.
7. Where data lives, and our providers
Radar's database and file storage are hosted in Canada (AWS ca-central-1, via Supabase).
Our subprocessors — the providers that process information on our behalf — are listed below. Providers that supply us with information they already hold, and that receive no personal information from us, are not subprocessors and are not listed; where we describe such a source we call it a commercial or proprietary intelligence source.
| Provider | Purpose | Data involved | Location |
|---|---|---|---|
| Supabase | Database, authentication, file storage | All platform data | Canada (ca-central-1) |
| Anthropic | Identifying candidate exposure records within unstructured leak text | The retrieved source text and the monitored organisation's name and domains. Not used to train models. | USA |
| Vercel | Application hosting and delivery | Data in transit through the application; web logs | USA / global edge |
| Resend | Transactional email | Recipient address; email content (summaries and links — never report files) | USA |
| HubSpot | Meeting scheduling (only when you open "Book a meeting") | Your IP/browser data and what you enter in the booking form; no monitored-organisation data is sent to it | USA |
We will update this table before adding a subprocessor that processes personal information, and will notify brokerage administrators of material changes.
8. Cookies
Radar uses essential cookies only: session authentication and security. No advertising or cross-site tracking cookies. The optional meeting scheduler is served by HubSpot and may set its own cookies when you use that page; that page's use is governed by HubSpot's privacy policy.
9. Email
We send transactional email only — invitations, sign-in links, status notifications, report availability — as permitted for business relationships under Canada's Anti-Spam Legislation (CASL). We do not send marketing email. Reports are never attached; email links open the portal, which requires sign-in.
10. Security
Invitation-only access; per-record isolation enforced in the database (row-level security), so access rules apply uniformly to every path into the data; encryption in transit (TLS) and at rest (provider-managed); reports and documents retrievable only via short-lived signed links issued to authenticated, authorised users; privileged actions, sign-ins and file access audit-logged with the originating internet address; segregation between production and test environments; automated verification of the database's security posture. No security is absolute; section 13 describes our breach response.
11. Retention
| Record | Retained |
|---|---|
| Monitored-organisation records, reports, findings, ratings | While the broker relationship is active; history is the product (trend over time) |
| Consent records | For as long as related monitoring data exists, and thereafter as evidence of authority |
| Audit logs, including sign-in records and the addresses they were made from | Independently of the records they concern, for accountability |
| Disabled accounts | Access ends immediately; the record is retained for accountability, not deleted silently |
| Confirmed devices | Until you remove one, or your account is closed. A removed device is marked as removed and kept, so the record of what had access outlives the access |
| Support correspondence | Up to 2 years |
| Backups | Rolling schedule; deleted data leaves backups as they rotate |
Deletion or return of a monitored organisation's data can be requested via its broker or support@risklink.io. Deletion requests are fulfilled manually and logged; the audit record of the deletion itself is retained.
12. Your rights
Portal users, monitored organisations, and their business contacts may request access to, correction of, or deletion of personal information we hold, subject to our legal and accountability obligations. Write to support@risklink.io; we respond within 30 days, verify identity before disclosure, and explain any refusal with the reason and recourse. We comply with PIPEDA and applicable provincial privacy law, and you may complain to the Office of the Privacy Commissioner of Canada.
13. Breach notification
Where a breach of security safeguards creates a real risk of significant harm, we will notify affected brokerages, affected individuals, and the Privacy Commissioner as required by PIPEDA, without unreasonable delay, and will keep records of all breaches as the law requires.
14. Children
Radar is a business service; it is not directed at, and does not knowingly collect information from, anyone under 18.
15. Changes
Changes are posted here with an updated date; material changes are notified to brokerage administrators by email before taking effect.
Contact: support@risklink.io — RiskLink Inc., 3080 Yonge Street, Suite 6060, Toronto, Ontario M4N 3N1, Canada.