1. The split that this notice turns on
There are two entirely different kinds of data around SealRelay, and almost every question people ask has a different answer depending on which one they mean.
| Account data | Matching data | |
|---|---|---|
| Whose data | The people at our customers who use the system — their own employees. | The Subject an attestation is about. |
| What it is | Name, work email, role, the entity they act for, authentication events, billing contact. | Identity, documents, facts about a person or entity. |
| Do we hold it | Yes. It is ordinary personal data and this notice covers it. | No. We never receive it. |
| What we do hold instead | — | Random pairwise tags that carry no derivable relationship to the person. |
| Who is responsible for it | We are, as controller, for our own account and billing use. | Part A, always. Not us. |
The rest of this notice is about the left-hand column. The right-hand column is covered only to explain why it is not ours.
2. Who is responsible
The operator of SealRelay is the controller for the account, billing and technical data described in section 3. The operator’s registered name and contact address are stated when this notice takes effect; this draft states neither.
Where the operator processes a customer's own employee contact data on that customer's instructions, the operator acts as a processor, and the data processing agreement governs that processing. That agreement covers employee contact data only, for the reason set out in section 4.
3. What we hold, and why
Account and organisation data
The legal entity's details, and for each person who uses the system: name, work email address, role, and the confirmation that they are authorised to act for the entity. We use this to run the account, to know who may act for whom, and to contact the customer about the service.
Authentication and security events
Sign-in events, credential changes, and failed attempts, so that we can secure the account and investigate incidents.
Billing data
The billing contact, the counts of billable events per account, and invoices. See section 7 for why this cannot be linked back to any Subject.
Technical and operational logs
Request metadata needed to run and defend the service: timestamps, account identifiers, rate-budget counters, error codes, and coarse network information. These are keyed to the customer account, never to a Subject.
The incident-response lookup trail
A trail of lookup events, kept for 30 days and then irreversibly deleted. It exists so that abuse and incidents can be investigated. It records that an account made lookups; it does not record who the lookups were about, because we do not have that.
What you send us in support
If you write to us, we hold what you wrote. Do not send us Subject identities or documents; we do not want them and have nowhere legitimate to put them.
4. What we never receive
The matching core never sees the Subject's raw identity. This is architectural, not a policy we could relax:
- Routing and consent tokens are random values, not hashes of an identifier. A hash of a low-entropy identifier can be brute-forced back; a random value has no mathematical relationship to the person at all.
- Matching happens over blinded values. The platform never evaluates an identifier in the clear.
- The underlying facts and documents move directly between the parties. They never pass through our servers.
Concretely, we never receive: names of Subjects, national identity numbers, dates of birth, addresses, document contents, organisation numbers, or serial numbers. This is tested rather than asserted: test data is seeded with unique high-entropy markers in every field that must never reach us, and every place we could have written something — database dumps, every log, backups, captured network traffic, temporary files, crash dumps, metrics — is scanned for those markers. A single hit stops the build.
The practical consequence for a customer: you do not need to name us as a processor for your own end-customer or client data, because we never handle it.
5. Lawful basis
- Performance of a contract — running the account, providing the service, invoicing.
- Legitimate interests — securing the service, preventing abuse, investigating incidents, and keeping records we need to defend claims. We have weighed this against the interests of the people concerned; the data involved is work contact data and operational metadata, not data about the Subjects the service is used to ask about.
- Legal obligation — accounting and tax records.
We do not rely on consent for account data, and we do not use it for advertising, profiling, or automated decisions with legal effect. We do not sell personal data.
6. How long we keep things
| Data | Kept | Then |
|---|---|---|
| Account and organisation data | For the life of the account | Deleted after termination, apart from what accounting law requires us to keep |
| Authentication and security events | As needed to secure the account | Deleted |
| Billing records and invoices | The period accounting law requires | Deleted |
| Incident-response lookup trail | 30 days | Irreversibly deleted |
| Support correspondence | As long as needed to handle the matter | Deleted |
| Matching material tied to an epoch | Until the epoch's retention policy expires | The epoch key is destroyed; the payloads become unreadable |
Deletion by key destruction. For matching material, deletion means destroying the key rather than overwriting rows. Once the epoch key is gone, the data cannot be read again even with full database access and every other key. What survives is the append-only proof structure: the inclusion and consistency proofs for those entries still verify, so the log's integrity is intact while the content is unrecoverable. Deletion in one domain's log does not affect any other domain's log.
The retention policy is a mandatory field on every adapter. An adapter without one is refused, not warned about.
7. Blind billing
We charge per live lookup, and a yes costs the same as a no, so the amount cannot reveal the answer. Beyond that, the billing records are built so that a billed event cannot be joined to a Subject even by us, with full access to our own billing tables.
The consequence is worth stating plainly, because it cuts both ways: we cannot give you a per-Subject breakdown of your invoice, and we cannot give one to anyone else who asks for it either.
8. Sub-processors
We use sub-processors for hosting and ordinary business operations. The current list is published on the sub-processor page and kept in step with the infrastructure actually in use. This draft does not reproduce the list, because publishing an out-of-date list is worse than pointing at the live one.
Customers are notified before a new sub-processor is added, and may object as set out in the data processing agreement.
9. International transfers
Where account data is transferred outside the region in which it is collected, the transfer is made on the safeguards required by applicable data protection law, and the safeguard used for each sub-processor is stated on the sub-processor page.
Region is a contract offer, not a property of the protocol. If a customer needs its account data to stay in a particular region, that is agreed in the order form.
10. Security
Matching keys are held wrapped at rest and are never present unwrapped in application memory when idle. Key destruction is attestable. The log is append-only: an entry cannot be deleted, altered, or spliced without the next consistency proof failing.
Access to production systems is limited to what running the service requires. Incident handling is split into separate tracks for key compromise, log leak, and denial of service, rather than one generic runbook.
We do not name a hardware brand, a certification level, or an availability figure here. Those are either operational detail that should not be a commitment in a privacy notice, or decisions that have not been made.
11. Your rights, and the honest limits
If we hold your personal data as controller, you may ask for access, correction, deletion, restriction, portability, and you may object to processing based on legitimate interests. You may complain to your data protection authority.
Two limits, stated plainly rather than buried:
- If you are a Subject, we almost certainly cannot help you. We do not hold your identity and cannot find you in our records, because there is nothing in them that points at you. A request about an attestation goes to the Part A that published it. Sending us an identity document would give us data we do not otherwise have, and we would not be able to match it to anything.
- Deletion has a boundary. We can destroy keys and delete account data. We cannot delete a copy that Part B already fetched, and we do not rewrite the append-only log — participant status is recorded as a lifecycle event, never as an erasure.
12. No key recovery
Consistent with the terms
There is no key recovery. If the Subject loses their key, SealRelay cannot restore it, and no one at SealRelay can act on their behalf.
We say this in the privacy notice as well as in the terms because it is the reason several answers above are so short. We cannot restore access, we cannot decrypt on request, and we cannot act for a Subject, because the key material never passed through us. There is no recovery form, no escrow copy, no backup key, and no administrative override.
The remedy for a lost key is a fresh qualified eID signing at Part A, which creates a new binding. Old tokens are not recovered; they become irrelevant, because a fresh consent supersedes an old one.
13. Changes to this notice
If we change this notice materially, we tell customers in writing before the change takes effect. The version and date sit at the top of the page.
14. Contact
The contact address for privacy questions is stated when this notice takes effect. This draft deliberately states none — an address published before it is watched would be a channel nobody is reading.
15. Open in this draft
- The named controller entity and its registered address (section 2).
- A privacy contact channel (section 14).
- The sub-processor list and the transfer safeguard per sub-processor (sections 8 and 9).
- Statutory retention periods for accounting records, which follow the jurisdiction chosen in the terms.
- The data protection impact assessment is a light internal one for the pilot phase, to be upgraded at the first paying customer. What upgrade means is decided then, not here.