1. Parties
This agreement is between [Customer legal name, registration number, address] (the Customer) and [Operator legal name, registration number, address] (the Processor). It supplements the Terms of Service and forms part of the agreement between the parties.
2. Scope — and the carve-out that defines it
Scope carve-out
This agreement covers only the contact data of the Customer's own employees who use the system. It never covers the Customer's end-customers or clients, because the Processor never handles that data.
In scope. The account, authentication and billing data described in Annex 1: the names, work email addresses, roles and account activity of the individuals the Customer authorises to use the service, and the Customer's billing contact.
Out of scope. Everything about a Subject. The Processor does not receive the Subject's identity, the underlying documents, or the facts attested. What the Processor holds are random pairwise tags with no derivable relationship to any person, produced without the Processor ever evaluating an identifier in the clear. Raw material moves directly between the parties to a matching, never through the Processor's servers.
What follows from that. The Customer does not need to list the Processor as a processor of the Customer's own end-customer or client personal data, because the Processor does not process it. The Customer remains controller of that data throughout, and its own obligations towards those people are unaffected by this agreement.
If material ever arrives in error. If the Customer sends the Processor personal data outside the scope above — in a support message, for example — the Processor will not use it, will tell the Customer, and will delete it. Sending such material does not extend the scope of this agreement.
3. Roles of the parties
For the data in Annex 1, the Customer is the controller and the Processor is the processor. The Processor is an independent controller for its own limited purposes: invoicing, securing the service, and complying with its own legal obligations. Those purposes are described in the privacy notice and are outside the instructions in section 4.
4. Processing on documented instructions
The Processor processes the in-scope personal data only on the Customer's documented instructions, which are: this agreement, the Terms of Service, and the Customer's use of the service through the interface. The Processor does not process the data for any other purpose.
The Processor tells the Customer if, in its opinion, an instruction infringes applicable data protection law, and may suspend that instruction until it is resolved. Where law requires the Processor to process beyond the Customer's instructions, it informs the Customer first unless that law forbids it.
5. Confidentiality
The Processor ensures that every person authorised to process the in-scope data is bound by an appropriate obligation of confidentiality, and that access is limited to those who need it to run the service.
6. Security measures
The Processor implements appropriate technical and organisational measures for the risk, described in Annex 2. The Processor may change a measure, provided the overall level of security is not reduced.
7. Sub-processors
The Customer gives general authorisation for the Processor to engage sub-processors. The current list is published on the sub-processor page and kept in step with the infrastructure actually in use.
The Processor notifies the Customer before adding or replacing a sub-processor. The Customer may object on reasonable data protection grounds within [notice period] days; if the parties cannot resolve the objection, the Customer may terminate the affected service without penalty.
The Processor imposes on each sub-processor obligations equivalent to those in this agreement, and remains liable to the Customer for the sub-processor's performance.
8. Assistance to the Customer
Taking into account the nature of the processing and the information available to it, the Processor assists the Customer with: security of processing, breach notification and communication, data protection impact assessments, and prior consultation with a supervisory authority.
The Processor's assistance is bounded by what it actually holds. For anything concerning a Subject, the Processor holds nothing that can be searched or produced — that is a property of the architecture, not a refusal to assist.
9. Data subject requests
If the Processor receives a request from a data subject about in-scope data, it forwards the request to the Customer without undue delay and does not respond to it itself, unless authorised by the Customer or required by law.
The Processor assists the Customer, by appropriate technical and organisational measures, in fulfilling requests for access, rectification, erasure, restriction, portability and objection, insofar as the request concerns in-scope data.
A request from a Subject is a different matter. The Processor cannot locate a Subject in its records, because nothing in them points at a person. Such requests belong with the Part A that published the attestation.
10. Personal data breach
The Processor notifies the Customer without undue delay after becoming aware of a personal data breach affecting in-scope data, with the information the Customer needs to meet its own notification duties. The Processor does not notify a supervisory authority or data subjects on the Customer's behalf unless instructed to.
The Processor maintains separate incident-handling tracks for key compromise, log leak, and denial of service, and exercises them.
11. Return and deletion
On termination, and at the Customer's choice, the Processor deletes or returns the in-scope personal data, and deletes existing copies, unless law requires it to keep them. Records the Processor must keep for accounting or to defend claims are kept for the required period and then deleted.
For matching material, deletion is by destruction of the relevant key. Once the key is destroyed the material cannot be read again, even with full database access and every other key, while the append-only proofs for those entries still verify. Deletion in one domain's log does not affect another domain's log.
12. Audit
The Processor makes available the information needed to demonstrate compliance with this agreement, and allows and contributes to audits, including inspections, conducted by the Customer or an auditor it mandates.
Audits take place on reasonable notice, no more than once a year unless a breach or a supervisory authority requires otherwise, during business hours, and without disturbing the Processor's operations or the confidentiality of other customers' data. The Customer bears its own costs.
The Processor may satisfy an audit request with an existing third-party report or certification where one covers the matters in question. No such report exists at the date of this draft, and none is claimed here.
13. International transfers
The Processor does not transfer in-scope personal data outside the region agreed in the order form except on the safeguards required by applicable data protection law, and it identifies the safeguard used for each sub-processor on the published list.
Region is a contractual offer, not a property of the protocol. Any regional commitment is made in the order form, not in the specification.
14. No key recovery
Basis of the carve-out
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.
This is stated here, and not only in the terms, because it is the technical fact the carve-out in section 2 rests on. The Processor cannot restore a key, decrypt on request, or act for a Subject, because the key material never passed through it. There is no recovery form, no support ticket that reinstates a key, no escrow copy, no backup key, and no administrative override.
The Customer must not represent to anyone — its own employees, its clients, or a supervisory authority — that the Processor can recover a key or act on a Subject's behalf. The remedy for a lost key is a fresh qualified eID signing at Part A, which establishes a new binding.
15. Term, liability and order of precedence
This agreement runs for as long as the Processor processes in-scope personal data for the Customer, and its surviving obligations continue after that.
Liability under this agreement is subject to the limitation of liability in the Terms of Service, except where applicable data protection law does not permit it to be limited.
On matters of personal data, this agreement prevails over the Terms of Service. On all other matters the Terms of Service prevail.
Annex 1 — Description of the processing
| Subject matter | Provision of the matching service to the Customer. |
|---|---|
| Duration | The term of the agreement, plus any statutory retention period. |
| Nature and purpose | Account administration, authentication, authority to act for the Customer entity, service communications, invoicing, security and abuse prevention. |
| Categories of data subject | The Customer's own employees and authorised representatives who use the system, and the Customer's billing contact. No other category. |
| Categories of personal data | Name; work email address; role or job title; the entity the person acts for and the confirmation of their authority; authentication and security events; account activity metadata; billing contact details and invoice records. |
| Special category data | None. The Customer must not submit special category data or criminal offence data under this agreement. |
| Data about Subjects | None. See section 2. |
| Frequency | Continuous, for the duration of the account. |
Annex 2 — Technical and organisational measures
- Encryption in transit and at rest for account data.
- Matching keys wrapped at rest, never present unwrapped in application memory when idle, with attestable destruction.
- Key scope per participant, domain and epoch, so a key never spans more than the scope it was created for.
- Append-only log: an entry cannot be deleted, altered or spliced without the next consistency proof failing.
- Deletion by key destruction, per epoch and per domain, with a mandatory retention policy on every adapter — an adapter without one is refused, not warned about.
- Access control limiting production access to what running the service requires, with authentication events logged.
- Segregation of billing from matching, such that a billed event cannot be joined to a Subject even with full access to the billing tables.
- Uniform negative responses, so that a no reveals nothing about which case applied, and rate budgets that do not leak existence.
- Automated absence testing: high-entropy markers are seeded into every field that must never reach the Processor, and every store the Processor writes to is scanned for them; one hit stops the build.
- Separate incident tracks for key compromise, log leak and denial of service, exercised rather than only written.
- Incident-response lookup trail retained 30 days, then irreversibly deleted.
Annex 3 — Sub-processors
The current sub-processor list is published on the sub-processor page and is incorporated into this agreement by reference. This template does not reproduce it: a list copied into a signed annex goes stale, and a stale annex is worse than a pointer to the maintained one.
Categories used: infrastructure hosting; payment and invoicing; business communications. The named entity, country of processing, and transfer safeguard for each are on that page.
16. Signature
This template is unsigned. Signature blocks for the Customer and the Processor — name, title, date — are added when the reviewed version is issued. There is no electronic signature flow on this page, and none should be inferred.
17. Bracketed fields
- [Customer legal name, registration number, address] (section 1).
- [Operator legal name, registration number, address] (section 1).
- [notice period] for sub-processor objection (section 7).
- The governing law and venue, which follow the Terms of Service.
18. What a human has to decide
- Signature. This template is unsigned. Signature is required before it is used with a customer.
- The carve-out, specifically. The scoping pattern in section 2 is drawn from a precedent about passive encrypted storage. This service is an active broker between two parties, which is structurally different and, as far as the operator is aware, untested by any supervisory authority. That difference is the single most important thing for a lawyer to look at.
- The exact carve-out wording of the vendor the pattern is named after is not held in this repository. It was not reproduced or paraphrased, and it should not be reconstructed from memory. If the reviewing lawyer wants to compare, the source document has to be obtained.
- The named legal entities on both sides.
- The liability cap figure that section 15 inherits from the terms.