Last updated: 3 September 2026
Who is responsible
Register Radar is operated by its founder, an individual based in Spain, who is the person responsible for the data described on this page. Operator details are on the legal notice. For anything in this policy, write to contact@registerradar.com — the founder answers.
What we store, and where
| Data | Where it lives | Why |
|---|---|---|
| Watch subscriptions: your RTO code, your email, an optional name, the day you signed up, and which page on this site you signed up from | Supabase (Postgres), EU region (Paris) | To run the scope watch you asked for. The page you came from is the only measure we have of whether the site brings anyone — it is never combined with anything else and never leaves us |
| Sign-in accounts: your verified email and provider (Google or email link) — plus one internal row per account (your account id, your email, when we first saw you sign in, and whether the founder was told) so a first sign-in is noticed exactly once | Supabase Auth, EU — the internal row in Supabase (Postgres), EU region. No passwords exist — we never store any | To show you your watches when you sign in, and to tell the founder a new account exists — once, and never again for the same account. Both deleted with your account |
| If you turn on two-step verification (it is optional and off unless you turn it on): the authenticator secret is created and held by Supabase Auth, never in our own tables. What we do store, in our database, is one row for your account with a one-way HMAC of each unused recovery code — never the code itself, which is shown to you once and not kept anywhere — plus how many codes you have used, how many failed recovery attempts have been made and when the last one was | Supabase Auth, EU, for the factor. The recovery row in Supabase (Postgres), EU region — the HMAC is computed with a server key the database does not hold | So a lost phone does not lock you out of your own account, and so nobody can sit there guessing recovery codes. Deleted with your account, and replaced from scratch whenever you generate a new set |
| Correspondence | Zoho Mail, EU data centre | Normal business email |
| Billing details, if you become a paying customer | Stripe. We never see or store card numbers | Payment processing |
| Paid engine only: the results file you upload | Nowhere. It is processed in memory and discarded when the request finishes — it never touches disk or storage | To compute your per-learner report |
| Paid engine only: each learner reference (opaque, from your own system) with its computed result | Supabase (Postgres), EU region. The unit-by-unit detail behind each result is encrypted before it is written (see below); the reference itself and the summary counts stay readable | It is the report you paid for |
| Paid engine only: a SHA-256 fingerprint of the file, row counts, detected columns, and the validation report | Supabase, EU — the validation report is encrypted before it is written | So you can prove which file produced which report |
| Paid engine only: the transition actions you record per learner reference (credit recorded, assessment scheduled, notes…), each with its date | Supabase, EU — notes are free text and are encrypted before they are written; deleting the upload deletes its whole action log | It is your evidence trail for the transition — the record you show an auditor |
| Paid engine only: a line per overnight decision about your transitions — your address, the two product codes, and whether we re-ran it, skipped it (with the reason) or aborted | Supabase, EU — no learner data of any kind, only the decision and its reason | So a job that stops working cannot pass for a quiet night, and so you can be told why a transition was not pre-run |
| For each free scope check: the RTO code, how the check arrived (typed, a followed link, or the homepage example), and a pseudonymous fingerprint of the IP it came from — a one-way HMAC computed with a server key the database does not hold, never the address itself. Once the fingerprint is 90 days old it is cleared by the nightly clean-up pass; the code, date and channel stay | Supabase (Postgres), EU region | The code and channel tell us which providers are finding us — and whether a check was a person typing or a mail scanner opening a link. The fingerprint, while it lasts, tells one visitor checking several centres apart from several visitors checking one centre each; once it is cleared the row can no longer be grouped with any other |
For each page view: the path, the referring site's host, the country Vercel infers, whether the link you opened carried an RTO code and, if it carried one, its campaign label (the src in the address — both come from the address you opened, nothing else), and a pseudonymous fingerprint of the IP it came from — the same one-way HMAC used for scope checks, computed with a server key the database does not hold, never the address itself. Once the fingerprint is 90 days old it is cleared by the nightly clean-up pass; the path, date and country stay | Supabase (Postgres), EU region | So that "forty people read this page" and "one mail-security gateway opened a link in our email and crawled six pages" stop being the same number — a distinction our own traffic figure could not make before 2 September 2026. While it lasts, the fingerprint groups views from one origin; it is never joined to your account, your email or anything you typed, and no cookie or third-party analytics is involved |
| Questions you send from your account, and our replies | Supabase, EU — encrypted before they are written, with a key the database does not hold | So your thread is there when you come back, instead of scattered across two inboxes |
| Every decision made by the door of our own private operations panel: when, what was decided, the path that was asked for, the browser's user-agent string, a pseudonymous fingerprint of the IP it came from — the same one-way HMAC used everywhere else here, never the address — plus a fingerprint of the browser and the id of the owner's sign-in session | Supabase (Postgres), EU region | So that an entry into the panel cannot happen without leaving a trace, so a sign-in from an unfamiliar device raises an email, and so repeated failures from one origin are slowed down. In normal use the only person in this table is the site owner; if someone else probes the panel's sign-in endpoint, that attempt is recorded too — which is the point of it. Rows are deleted once they are 90 days old |
| For each message you send us — through the contact form or from your account — how we are handling it: whether it has been read, answered or archived, what kind of message we filed it as, the RTO code we associated with it, and any internal note we wrote about it and the copy of the reply we sent, both encrypted with a key the database does not hold | Supabase (Postgres), EU region | So a message is not answered twice or lost, and so the reply we sent you is the reply we have on file. It holds no text you wrote — that stays in the rows above. Deleted with your account, together with the message it is about |
| Paid review documents — your email, the RTO code and the generated document | Supabase, EU region | They are the record of something you paid for. They survive account deletion as an accounting record — the deletion email says so at the moment you delete |
| Evidence links you create from your account: your email, the RTO code the link shows, when you created or revoked it, how many times it was opened and when it was last opened | Supabase (Postgres), EU region | So the link keeps working for whoever you sent it to, and so you can see it was used and revoke it. Deleted with your account — any link you had shared stops resolving, which is what closing an account should mean |
| The contact form: your name, email, RTO code and the message you wrote | Supabase (Postgres), EU region — stored as written, not encrypted | So a question does not get lost in an inbox. Deleted with your account |
| If someone adds your address as a recipient of their scope watch: that address and the RTO code | Supabase (Postgres), EU region | To send you the alerts you were told you would get. One click in any of them removes it, and you do not need an account |
| Which report requests came from your address, which page on this site you asked from — and, if you ask for a free result by email, that your address asked for one | Supabase (Postgres), EU region | So we can tell a returning user from a new one. Deleted with your account |
| If you ask to be told when the next article is out: your email address and that you asked from the articles page | Supabase (Postgres), EU region | To send you that one email when there is one. Every article carries a one-click link that deletes the address; also deleted with your account |
| A count of emails we have sent to your address, with timestamps — and, for the free result email, an anonymised fingerprint of which result went out (a hash, not the codes) | Supabase (Postgres), EU region | So nobody can use us to flood someone else's inbox, and so the same result is not sent to you twice in a day. Deleted with your account |
| If you turn any email off or on: your address and which switches you set | Supabase (Postgres), EU region | So we respect the choice instead of asking again. No row exists until you change something. Deleted with your account |
| If you tell us who you are in Settings: your address and the role you declared — an RTO that delivers training, or a consultant working with client RTOs | Supabase (Postgres), EU region | So the plan page uses the right words for your situation. It changes nothing about price or access. No row exists until you choose. Deleted with your account |
| That your account proved it has a mailbox at a given RTO, how it was proved and when | Supabase (Postgres), EU region. We store a one-way HMAC of the one-time code, never the code, and never the official address it was sent to | So the paid engine only shows a centre's data to someone who belongs to it. Deleted with your account |
| Which Stripe subscription covers which RTO code | Supabase (Postgres), EU region. No email and no card data — the subscription id and the RTO code | So a paying centre gets what it paid for. It is a billing record and is kept as one — see how long we keep things |
| Learner names, dates of birth, USIs, emails, phone numbers, addresses | Nowhere, ever. A file containing any of these is rejected before any row is measured or stored | We refuse to receive them |
How stored results are protected
Supabase encrypts everything at rest (AES-256); that protects against a stolen disk, not against someone reading the database with valid credentials. So the unit-by-unit detail behind each per-learner result, and the validation report, are also encrypted inside our database, with a key the database does not hold — it lives only on our server, and without it those records are just bytes. That is real protection against a database leak. It is not absolute protection — nothing is — and we would rather tell you its limits than oversell it. The file fingerprint, the row counts and the opaque reference itself stay readable on purpose: they are the audit trail, and none of them means anything outside your own system.
What we never store
The free enrolment cross on /cross runs entirely in your browser. The file is never uploaded; only public training-product codes are sent to our server to be checked against the national register. That promise is unchanged, word for word.
The paid engine does receive a file — and refuses to receive your learners. We don't ask you to trust that we won't look at names: a file containing a name, an email, a phone number, a date of birth, a USI or an address is rejected outright, the message says which column, and not one row of it is kept. What we accept is a reference that only means something inside your own system — we never receive anything that could translate it back to a person.
- No cookies for visitors, no third-party analytics, nothing that follows you to another site. We keep first-party, cookieless page counts — the path you visited, the referring site's host, the country Vercel infers, and a pseudonymous fingerprint of your IP: a one-way HMAC computed with a server key the database does not hold, never the address, cleared once it is 90 days old. No visitor cookies, no device fingerprinting, no advertising identifiers, nothing shared with anyone. The one cookie this domain sets is the operations panel's own session cookie, which only the site owner ever receives — it is named and explained below. Within this site and while it lasts, that fingerprint does let us tell one visitor reading six pages apart from six visitors reading one each — which is exactly what it is for, and the only thing it is used for. On the free cross your enrolment file still never leaves your browser.
- If you sign in, your session token is kept in your browser's localStorage — strictly necessary for the sign-in to work, and it never leaves your device except to authenticate you.
- To stop abuse we count requests per origin for sixty seconds. What is stored is not your IP address: it is a one-way HMAC of it, computed with a server key that is not in the database, so it cannot be turned back into an address. It records nothing else — no page, no account, no content — and it is used for nothing but that count. Rows older than two minutes are swept out by later requests as they come in — not by every request, by about one in fifty — so nothing there is kept on purpose, and on a quiet day the last visitor's rows simply wait for that traffic to arrive. Without it, anyone could walk the national register through our servers and get us blocked from the source this whole service depends on.
- We hold no phone numbers or personal details beyond what the public register itself publishes.
Cookies — and what stays in your browser
This site sets no cookies for visitors. None. Not ours, not anyone's — no analytics cookies, no advertising cookies, no "performance" cookies. That is why there is no cookie banner: there is nothing for you to consent to, and we will not put up theatre. There is exactly one cookie on this domain and you will never receive it: __Host-rr_admin, the session cookie of the private operations panel, issued only to the site owner after two-step verification and valid for twelve hours. It is signed and carries five things — the owner's own address, the id of their sign-in session, a fingerprint of the browser it was issued to, when that two-step check was last passed, and when it expires. It measures nothing, it is never sent to anyone else, and there is nothing of yours in it. If you are reading this, you do not have it.
What does exist for you is a handful of values kept in your browser and only there. None is ever used to track you, and only two ever travel to our servers: the session token, sent to authenticate your own requests, and the pending RTO code, sent once to create the watch you asked for. The rest never leave your device, and you can clear them all from your browser at any time:
| Key | What it holds | How long |
|---|---|---|
rr_theme | Your light/dark choice — written only when you press the theme toggle, never before | Until you clear it or choose again |
rr_session | Your sign-in token (Supabase Auth) — strictly necessary for signing in to work | Until you sign out or delete it |
rr_cross_watch | If you ask to watch an RTO right before signing in: that public RTO code, so the request survives the sign-in email round-trip. Nothing from any file — only the code | One hour, then it deletes itself |
rr_msg_borrador | The unsent draft of a message you are writing in your account | Dies when the tab closes |
rr_welcome | A one-off "just signed in" flag so the welcome note shows once | Consumed and deleted on first use |
rr_admin_tab | Admin only — which tab of the founder's internal dashboard was open last, on the founder's own browser. Visitors never get this key | Until cleared |
rr_admin_pruebas | Admin only — whether the founder's internal dashboard is showing test traffic alongside real traffic, on the founder's own browser. Visitors never get this key | Until cleared |
This list is exhaustive, and a test in our codebase fails if the code ever writes a browser key this page does not name.
Why we may have emailed you first
If we contacted your organisation, it is because training.gov.au publishes your organisation's public contact details, and our email contained specific, verifiable data about your own scope (legitimate interest, B2B). Reply "stop" once and we never contact you again.
Legal bases
- Consent — when you start a watch or create an account.
- Contract — when you buy paid work from us.
- Legitimate interest — one-time B2B outreach to publicly listed organisational contacts, with immediate opt-out.
Where we rely on consent, you can withdraw it at any time — reply "stop" to any email, use the one-click link every email carries, or write to us — and withdrawing it means we delete the data, not archive it. Withdrawal does not affect the lawfulness of anything done before it.
How long we keep things
- Watch subscriptions: until you say "stop" — then the row is deleted.
- Accounts: until you ask us to delete yours.
- Paid uploads: the file itself is never kept — it is gone when the request finishes. The computed results stay until you delete that upload from your account; deleting the account deletes them all. No copies.
- Paid review documents: kept after account deletion as an accounting record — the one declared exception to "nothing else survives".
- One-time verification codes: the code itself is unusable after minutes, and the record of it is wiped 48 hours later by the nightly job. The count of codes sent to a centre's official mailbox is deleted on the same 48-hour sweep.
- Proof that your account belongs to an RTO: it expires 12 months after it was given. People change jobs, and we would rather re-check than keep something we know goes stale.
- Billing records, including which subscription covered which RTO: kept for as long as accounting and tax law requires us to keep them, and then deleted.
- Correspondence: for as long as is reasonable for normal business records.
Your rights
Under the GDPR you can ask for access, correction, deletion, portability, or object to processing — email contact@registerradar.com and it gets done, not queued. You can also complain to the Spanish supervisory authority, the AEPD.
Who processes data for us
- Supabase — database and sign-in (EU region)
- Vercel — website hosting
- Zoho Mail — email (EU data centre)
- Stripe — payments
- Cloudflare — DNS
International transfers
Everything we store lives in the EU: Supabase in Paris, Zoho in an EU data centre. Three of our processors are US companies — Vercel (hosting), Stripe (payments) and Cloudflare (DNS). Each of the three publishes its certification under the EU-U.S. Data Privacy Framework, the EU-recognised safeguard for transfers to the US (you can look any participant up on the official list at dataprivacyframework.gov), and each also offers EU standard contractual clauses as the fallback if a certification ever lapses.
Australia has no EU adequacy decision — and the only personal data that ever travels there is an email to the very person it is about, at their own address: the alerts and reports you asked for, an alert a colleague at your centre asked us to send you (each carries the one-click link that removes your address), or the one first B2B email described above. Where you asked for it, sending it is performance of your request (GDPR arts. 6(1)(b) and 49(1)(b)); and in every case the mail goes to you and to no one else — we hand personal data about you to nobody else in Australia.
For Australian readers
We are a Spanish operator, so the law that binds us is the GDPR — which in most respects demands more of us than the Australian Privacy Principles would. We do not claim to be an APP entity. What matters for your compliance is simpler: we refuse to receive your learners' identities at all (see above), so using Register Radar never puts learner personal information in a foreign supplier's hands.
If this policy ever changes, the date at the top changes with it — and nothing in it will ever quietly start storing more than it says.