Legal
Privacy statement
What OrigoPass does with personal data, written against what the software actually does — including the one place where we cannot delete anything, and why.
Last updated 2026-11-12
Who is responsible
Twenty9 Solutions, trading as OrigoPass
E-mail: info@origopass.eu
This statement covers the public website www.origopass.eu, the passport pages we host (including those on our customers’ own domains), the readiness check, and the OrigoPass console.
For the product data inside a passport, the manufacturer who publishes it is responsible. They decide what is in it; we host and seal it on their instructions. Where that role matters, it is called out below.
If you only read the website
We use no analytics, no tracking pixels and no advertising cookies. Public pages carry no JavaScript at all. Our web server keeps ordinary access logs (IP address, time, requested page, browser string) to keep the service running and to investigate abuse; they are kept for 90 days and are not used to profile anyone.
We set only cookies that are strictly necessary for something you asked for, so there is no consent banner — there is nothing to consent to:
- __Host-bpsess — the session, when you sign in to the console or open a form (it carries the protection against forged form submissions). It ends when you close the browser, and after 30 minutes without activity.
- bp_lang — only when you choose a language in the language menu, to keep showing that language. One year.
- bp_access — only when you open an access link a manufacturer gave you, so you can see the restricted passport data it covers. Until the grant expires, at most 30 days.
None of them is shared with anyone or used to recognise you anywhere else. If you arrive through one of our ads, we do not store the click.
If you scan a product passport
Nothing personal is recorded. We count how often a passport was opened per day, as a number per passport — no IP address, no device, no visitor identity, nothing that could be traced back to you.
If you ask a manufacturer for access to restricted passport data (repair, dismantling or composition data under Article 77 of the Battery Regulation), that request is personal data:
| What | Why | Legal basis | How long |
|---|---|---|---|
| Your name, organisation, e-mail address and the reason you give | So the manufacturer can decide on your request and reach you about it | Legitimate interest of the manufacturer (Art. 6(1)(f)) and, for them, a legal obligation under the Battery Regulation | As long as the access grant is valid, and then as part of the manufacturer’s compliance record |
| The fact that a granted link was used, and when | So a manufacturer can see who saw restricted data — this is the accountability the regulation asks for | Legitimate interest (Art. 6(1)(f)) | For the life of the grant record |
If you use the readiness check
Answer the questions and leave the e-mail field empty and nothing is stored at all — the score is calculated while you wait and shown on the page.
| What | Why | Legal basis | How long |
|---|---|---|---|
| Your e-mail address, your company name if you give one, your answers and your score | To send you the report you asked for | Your request (Art. 6(1)(b) — steps at your request) | Until you erase it; we review and clear inactive entries at least once a year |
| Whether you ticked “you may contact me once about this result” | So we only contact you if you said we may | Consent (Art. 6(1)(a)), which you may withdraw at any time | With the record above |
Every report we send carries a link that erases that record immediately — no login, no confirmation screen, no questions. You can also write to us and we will do it.
We do not sell, rent or share this data. It is kept in an ordinary database table, deliberately outside the sealed register, precisely so it can be deleted.
If your company is a customer
| What | Why | Legal basis | How long |
|---|---|---|---|
| Account data of each user: username, e-mail address, role, and a hash of the password (never the password itself) | To give access to the console and to keep roles apart | Performance of the contract (Art. 6(1)(b)) | While the account exists; removed when the account is deleted, except in the audit register (see below) |
| Company and billing data: company name, address, KvK and VAT number, contact name, billing e-mail address | To provide the service and to invoice it | Contract (Art. 6(1)(b)) and legal obligation (Art. 6(1)(c)) for tax records | Invoices and their data: 7 years, as Dutch tax law requires |
| Sign-in records: who signed in and when, plus a one-way reference to the address used (a keyed hash, not the address itself) | To detect and investigate unauthorised access, and to make every change in the register traceable to someone | Legitimate interest in security (Art. 6(1)(f)) and the integrity obligation of an audit register | Permanent — see “The register that cannot forget” |
| Failed sign-in attempts and rate-limit counters (IP address, username) | To stop brute-force attempts | Legitimate interest in security (Art. 6(1)(f)) | Automatically deleted after 24 hours |
If a customer asks you for data as a supplier
A manufacturer can send you a personal link asking you to fill in specific product data. We then process your company name and e-mail address on their behalf, so we can deliver the request and their answer to it. The values you submit are product data, not personal data, and they become part of their passport once they accept them. The register records that a request was made, to which company, for which fields, and whether it was accepted or refused — with the reason.
The register that cannot forget
OrigoPass exists to make product records provable. That only works if records can be added but never edited or deleted — the database itself refuses. This is the core of the product, and it has a consequence we will not hide:
- The username of whoever performed an action is part of every sealed record, forever. That is what makes a passport auditable at all: an unattributable change proves nothing.
- Sign-in records carry a one-way reference to the address that was used — a keyed hash, so the chain can show that two sign-ins came from the same place without the address itself being written into something that can never be deleted. The key sits on the server, not in the register.
- Records are copied to our standby servers, so the same information exists there.
If you ask us to erase your data, we will erase it everywhere we can — account, leads, requests, contact data — and we will tell you plainly that the sealed records naming your username remain, because removing them would break the proof that every other record depends on. We rely on Article 17(3)(b) and (e) GDPR for that: processing necessary for a legal obligation and for the establishment or defence of legal claims. Nothing in the chain contains passport content about consumers; it is operational data about who did what.
Practically: use an account name you are comfortable seeing in an audit trail. A customer’s administrator chooses these names.
Who else sees any of this
Nobody, beyond the parties we need to run the service:
- Contabo GmbH (Germany) — hosting of the main server, in the European Union.
- TransIP B.V. (the Netherlands) — hosting of the standby server, which holds a copy of the sealed register and serves the passport pages when the main server is down.
- Hetzner Online GmbH (Germany) — off-site storage of our nightly backups, in the European Union. The backups are encrypted before they leave our servers and Hetzner has no key, so it holds files it cannot read.
- Cloudflare, Inc. (United States) — the network in front of our servers: it protects them against attacks and sends visitors to the standby server when needed. Every request passes through it, so it processes the IP address and request data of each visit; it sets no cookies and runs no scripts on our pages. Its data centres are worldwide, so this is a transfer outside the EU, covered by Cloudflare’s certification under the EU–US Data Privacy Framework and the Standard Contractual Clauses in its data processing addendum.
- Mollie B.V. (the Netherlands) — payments. They receive what a payment needs; we never see or store your card details.
- The European Commission’s VIES service — we check a VAT number you enter against it.
- Our own mail server — e-mail is sent from our own infrastructure, not through a third-party marketing platform.
Everything we store — the database, the register, its standby copy and the encrypted backups — stays within the European Union. The one transfer outside it is Cloudflare’s network, described above. We do not use profiling or automated decision-making that produces legal effects.
How it is protected
- HTTPS everywhere, with HSTS; passwords stored only as hashes.
- Roles per user, four-eyes approval on rights changes, and API keys per brand that can be rotated in one click.
- Restricted passport data is only released through a grant the manufacturer approved, with an expiry date.
- A strict content security policy: no third-party scripts anywhere, and none at all on public pages.
- Every action in the register is attributable and verifiable by anyone through the public integrity check.
Your rights
You may ask us for access to your data, correction, erasure, restriction, or a copy in a portable format, and you may object to processing based on legitimate interest. Where we rely on consent, you can withdraw it at any time — withdrawal does not affect what happened before.
Write to info@origopass.eu. We answer within one month. If you think we handle your data wrongly, you can complain to the Dutch data protection authority, the Autoriteit Persoonsgegevens.
If your data reached us because one of our customers publishes passports, direct your request to them: for that data they decide, and we act on their instructions. We will point you to the right party if you are not sure.
Changes
When the software changes what it keeps, this page changes with it, and the date at the top moves. Material changes for existing customers are announced by e-mail.