Last updated: 10 October 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: the emails you send us and our replies — including what you write in the contact form, which also reaches our mailbox, and our reply to it | Zoho Mail, EU data centre, as ordinary email — readable, not encrypted by us | Normal business email |
| Working files of replies: for each address that answers one of our emails, a plain-text file with the full text of what it sent (or the mailbox's summary, marked as such, when the full text could not be read). When we answer from our own reply script, our answer is added to the same file — and the file is rewritten whenever the incoming message is read again, so it is not a complete record of what we sent | The operator's own computer, in Spain — not in any repository | To read the reply and decide how to answer it, which can mean pasting it into Claude (see who processes data for us), and to count how many real conversations our emails produce. Kept as correspondence — see how long we keep things |
| 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. Deleted with your account |
| 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. If you wrote to us without one, ask at contact@registerradar.com and we delete both by hand |
| 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, what your message is about, the message you wrote and when it arrived | Supabase (Postgres), EU region — stored as written, not encrypted | So a question does not get lost in an inbox. Deleted with your account. If you wrote to us without one, ask at contact@registerradar.com and we delete it by hand |
| 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. Without an account, ask at contact@registerradar.com and we delete it by hand |
| 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_canasta_sonido | Whether the sound effects of the file drop area in your account are on — written only when you press its sound button, never before | Until you clear it or choose again |
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.
What we hold about a centre we wrote to is what the register publishes — its RTO code, name and scope, and the contact name, role and email address listed for it on training.gov.au (or published on the organisation's own website) — plus a log of what we sent and any reply, and we use it to write to that centre about changes to training products in its own scope (superseded products, above all), which the Spam Act 2003 allows on inferred consent (Schedule 2, clause 4 — in short, an address conspicuously published in connection with a role, and a message relevant to that role). To object, reply "stop" or write to contact@registerradar.com: the address and its domain go on a do-not-contact list that is only ever added to and is checked before every outreach email goes out — the opt-out the Spam Act requires, and the one Australian Privacy Principle 7 asks of direct marketing where it applies.
Legal bases
- Consent — when you start a watch or create an account.
- Contract — when you buy paid work from us.
- Legitimate interest — B2B outreach to publicly listed organisational contacts (a first email and at most two follow-ups), 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 — though a deleted row can live on for up to 30 days in our nightly database backup, which then expires by itself, and the data may also remain in one-off local copies of the same tables, taken on 30 August 2026 and 2 September 2026, kept on the operator's own computer with no set deletion date. 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, and it is gone from the nightly database backup within 30 days, and the data may also remain in one-off local copies of the same tables, taken on 30 August 2026 and 2 September 2026, kept on the operator's own computer with no set deletion date.
- 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. Apart from the nightly database backup, where they last up to 30 days and then expire by themselves, and one-off local copies of the same tables, taken on 30 August 2026 and 2 September 2026, kept on the operator's own computer with no set deletion date, we keep no other copy.
- Paid review documents: kept after account deletion as an accounting record.
- What survives an account deletion: any paid review documents you bought, which stay in our books as an accounting record; the billing records of any monthly service — your customer record and invoices at Stripe, and which subscription covered which RTO — kept for as long as accounting and tax law requires; the emails we have exchanged, which stay in our mailbox as business correspondence, and our working files of any replies; if we first wrote to your centre, our log of that outreach and any reply — and, if you asked us to stop, your address on our do-not-contact list, which is never deleted; copies in our nightly database backup, for up to 30 days; one-off local copies of the same tables, taken on 30 August 2026 and 2 September 2026, kept on the operator's own computer with no set deletion date; working notes about people — contacts the national register publishes for centres, and people who replied to our emails — in our code and documentation repositories on GitHub and in their history, until that history is rewritten; the logs of our mailbox check on GitHub from before 10 October 2026, which show the address and subject of each recent email, until they expire after 90 days; and the reports that check published to our repository on GitHub from before 10 October 2026, which stay reachable there until they are purged. Nothing else does.
- The nightly database backup: a copy of fifteen of our database tables, made every night and kept for 30 days, after which each copy expires by itself. It is not encrypted by us. Anything deleted from the database is gone from the nightly backups within those 30 days.
- Local copies of the database: one-off local copies of the same tables, taken on 30 August 2026 and 2 September 2026, kept on the operator's own computer with no set deletion date. Rows deleted from the database since then are still in them, and nothing makes them expire.
- 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.
- Centres we wrote to first (see "Why we may have emailed you first"): the log of what we sent and any reply is only ever added to — a "stop" goes on the do-not-contact list and the log entry is kept, not erased — and we have set no date for deleting it, because it is what keeps us from writing to the same address twice and what shows a "stop" was honoured. The do-not-contact list itself is never deleted and no address is ever removed from it: it is the record that guarantees we do not write again.
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
- GitHub — hosts our private code and documentation repositories; runs our scheduled jobs, which read the database and the mailbox, and keeps their logs for 90 days — the mailbox check logs only the domain of each sender and a category for each message (a person, a stop request, a contact-form message, an automatic reply, a bounce, a system message or one of our own, with anything doubtful counted as possibly a person); and keeps the nightly backup of the database — the tables with your email address among them — not encrypted by us, for 30 days, after which it expires by itself. Also on GitHub, and kept after an account deletion: working notes about people — contacts the national register publishes for centres, and people who replied to our emails — in our code and documentation repositories on GitHub and in their history, until that history is rewritten; the logs of our mailbox check on GitHub from before 10 October 2026, which show the address and subject of each recent email, until they expire after 90 days; and the reports that check published to our repository on GitHub from before 10 October 2026, which stay reachable there until they are purged.
- Anthropic — Claude, the AI assistant the operator works with: it receives the text of the emails and messages we are working on, pasted in or read from our working files and repositories, which can include names and email addresses
International transfers
Our database lives in the EU, with Supabase in Paris; our email too, with Zoho in an EU data centre; and our working files on the operator's own computer in Spain. Five of the services that receive personal data are US companies. GitHub (our repositories, our scheduled jobs and the 30-day database backup) and Anthropic (the AI assistant the operator works with) receive what is described under who processes data for us. 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.