What we hold, where it lives, and what we have not done yet

The register: the names of software you run, what you told us it is used for, the classifications a person at your organisation confirmed, and the evidence records you chose to attach. That is commercially sensitive — it is a map of your software estate — and it is the whole of what we store.

The free check stores nothing. Names pasted into the public page are matched and returned; the request ends and so do they. There is no account, so there is nothing to attach them to.

We do not connect to your systems. There is no agent, no integration, and no access to the data your AI systems operate on — only to the names of the systems themselves.

Passwords are hashed with bcrypt at cost 12 and never stored or logged in the clear. Sessions are 32 bytes of CSPRNG; only the SHA-256 of a session token is stored, so a dump of the session table yields nothing replayable.

Sign-in uses one message and one timing profile for “no such account”, “deactivated” and “wrong password”. Distinguishing them would turn the endpoint into a way of confirming which companies are worried about the AI Act, which is worth more to a competitor than the account.

Two-step verification is required for our platform administrators, who can see every organisation’s register: without it, an administrator account reaches only the set-up page. Every user can turn it on in Account. A sign-in then needs a code from an authenticator app, an emailed code or a single-use recovery code. The authenticator secret is encrypted, recovery codes are stored only as hashes, and each code works once.

Deactivation is enforced on the read path, not only where an administrator performs it — so a row changed by a restore, a direct fix or a race does not leave a working session behind.

Every query against the register is scoped to the caller’s organisation in thewhere clause, not checked after the fetch. Fetching by id and validating afterwards is one forgotten early-return away from cross-tenant disclosure, so the pattern is not used.

Read-only roles exist for exactly this: an auditor or external counsel gets a seat that can read the register and cannot change what it says.

Every state-changing action is recorded with the actor, the target and the time, and the entry survives the user who made it — the actor relation nulls rather than cascades, so deleting somebody cannot erase the record of what they confirmed. A deletion log that can itself be deleted is not a log.

Hosting is a server in a European Union data centre, with TLS for every request and nightly backups of the database and the evidence files that are verified by content rather than by file size — a truncated dump has a plausible size and a plausible timestamp, and every check built on those two reports healthy while holding an unusable file. Offsite copies are encrypted (AES-256) before they leave the server, with a key the storage provider never receives, and a restore drill proves they can be read back. The providers are named in the data processing terms.

Not in place: encryption at rest of the live database and evidence files beyond what the host and the storage provider apply themselves, and any certification. Until offsite storage is configured, the backups report it as unconfigured rather than as healthy.