What this is, and how it fits
This addendum forms part of the Platform Terms between XEX and an operator. It applies where XEX processes personal data on the operator’s behalf, and it is intended to satisfy Article 28(3) of the UK and EU GDPR and equivalent obligations elsewhere.
Where this addendum and the platform terms conflict on data protection, this addendum prevails. Where it conflicts with a standard contractual clause incorporated under it, the clause prevails.
This is a working draft. The transfer mechanism, the choice of standard contractual clause modules, the liability allocation between the parties, and whether the relationship is in fact controller-to-processor rather than joint control all require counsel — see also the open question recorded in Privacy Policy.
Roles
| Data | Controller | Processor |
|---|---|---|
| Members of the operator's programme | The operator | XEX |
| The operator's own console users | XEX (account, sign-in, roles, audit) | — |
| Visitors to xex.to | XEX | — |
| Platform identity index (a non-reversible handle plus the email it was verified against) | XEX | — |
The last row is deliberate and is not processing on the operator’s instructions: it exists so that one person is not asked to complete identity verification separately in every workspace, which is a platform purpose, and XEX is the controller of it.
Processing on documented instructions
XEX processes member personal data only on the operator’s documented instructions, which consist of: this addendum, the platform terms, the operator’s configuration of its workspace (its plan, its packages, its rails, its verification provider, its tracking destinations, its country policy), and its use of the console and the API.
XEX will tell the operator if it believes an instruction breaches data protection law, and may decline to act on it. Where XEX must process for its own legal obligation, it will tell the operator unless the law prohibits it.
Confidentiality of personnel
Access to member personal data is limited to personnel who need it to provide the platform or to support the operator. Those individuals are bound by confidentiality obligations that survive their engagement, and their console actions are recorded in an audit log that cannot be edited or deleted.
Security
XEX implements the technical and organisational measures in Annex II, having regard to the state of the art, the cost of implementation and the risk to data subjects. Annex II also states what is not in place, which is part of the same assessment.
Sub-processors
The operator gives a general authorisation for XEX to engage the sub-processors listed in Sub-processors, and any successor or additional sub-processor notified in accordance with this section.
- 01XEX will give at least [[ To be supplied — sub-processor notice period ]] notice before a new sub-processor begins processing, by updating the sub-processors page and notifying the operator.
- 02The operator may object on reasonable data-protection grounds within the notice period. The parties will discuss it in good faith; if it cannot be resolved, the operator may terminate the affected service without penalty for the unused portion of any prepaid fee.
- 03XEX remains liable for a sub-processor's performance of these obligations as if it were its own.
- 04Each sub-processor is engaged under terms that are materially no less protective than this addendum.
Assistance with data-subject requests
The console exposes a member’s data to the operator directly, and exports it as CSV, so an operator can answer an access or portability request without asking XEX and without waiting on it.
Where XEX receives a request from a member, it will not answer it itself: it will tell the member that the operator is the controller and pass the request to the operator, and it will assist the operator in responding, taking into account the nature of the processing.
The ledger and the audit log are append-only, enforced in the database. An erasure instruction is executed by removing or redacting identifiers, not by deleting financial or audit records — those are the operator’s own compliance evidence, and destroying them selectively would defeat the purpose they exist for. XEX will say so in response to an instruction rather than accepting it and quietly not performing it.
Breach notification and assistance under Articles 32 to 36
XEX will notify the operator without undue delay after becoming aware of a personal data breach affecting the operator’s data, with the information available to it, and will supplement it as more becomes known.
XEX will provide the operator with reasonable assistance for data protection impact assessments and prior consultations, taking into account the nature of the processing and the information available to XEX.
Return and deletion
On termination, the operator may export its data from the console for [[ To be supplied — export window ]]. After that, XEX will delete or return member personal data, except where retention is required by law, or where data sits in the append-only records described above, in which case it is retained and remains subject to this addendum for as long as it exists.
Audits and information
XEX will make available the information necessary to demonstrate compliance with this addendum and will allow for and contribute to audits, including inspections, conducted by the operator or an auditor it mandates — on reasonable notice, no more than once a year unless a breach or a regulator requires otherwise, during business hours, subject to confidentiality, and without access to another tenant’s data.
No audit report is offered in place of this right, because none exists: XEX does not hold a SOC 2 report and has not commissioned a third-party penetration test.
International transfers
Where member personal data is transferred out of the UK or the EEA, the transfer is made under [[ To be supplied — transfer mechanism ]] and with the supplementary measures identified in the accompanying assessment.
Hosting region, sub-processor locations, the applicable module of the standard contractual clauses and the UK addendum are all unresolved. They cannot be inferred from the codebase and are not guessed at here.
Annex I — description of the processing
| Item | Description |
|---|---|
| subject matter | Provision of compensation-plan infrastructure to the operator: computing what the operator's plan owes its members, recording it, and instructing the operator's own systems to settle it. |
| duration | For the term of the platform terms, plus any retention described in this addendum. |
| nature and purpose | Collection, structuring, storage, computation, consultation, disclosure to the operator, transmission to the operator's own payment and verification providers, restriction, redaction and deletion. |
| categories of data subject | Members of the operator's programme; the operator's own console users; where the operator sells to retail customers, those customers. |
| types of personal data | Identifiers and contact data (identity reference, account reference, display name, email); programme data (position, sponsor, rank, purchases, ledger entries, claims, disputes, terms acceptance with time and IP); verification outcome and a non-reversible identity handle; country and last-seen IP address; payment intent metadata; marketing attribution and consent flags; authentication data (passkey credentials, one-time-code secrets); audit records. |
| special-category data | None. The platform is not built to hold it, and the acceptable use policy prohibits putting it there. Identity documents are never received or stored. |
| frequency | Continuous, for as long as the workspace is in use. |
Annex II — technical and organisational measures
Each measure below is a property of the system rather than an intention. Where something is not in place, it is listed at the end rather than omitted.
Tenant isolation
Every query in the data layer takes a workspace identifier; there is no call site that can omit one. Cross-tenant access is therefore not prevented by policy — it is not expressible.
Immutable audit
Operator actions are written to an append-only audit log whose immutability is enforced by a database trigger that raises on any update or delete, not by application code that could be bypassed.
Access control and separation of duties
Six console roles (owner, comp_admin, finance, compliance, support, marketing) plus read-only. A section a role may not see renders an access notice rather than data. Plan versions and payout runs require approval by a different operator, refused both in the application and in the database.
Authentication
Passkeys and time-based one-time codes for operators and members; sessions are carried in HttpOnly, Secure, SameSite=Strict cookies that expire with the credential they hold.
Key management
API keys and webhook secrets are per workspace and carry a key identifier with overlapping validity, so rotation does not require an outage. Credentials an operator stores for its own payment rails are sealed at rest, and the rail configuration refuses to store a credential belonging to the platform.
Egress control
Destination URLs configured by an operator (webhooks, connectors) are checked against server-side request forgery and egress rules before anything is sent. Outbound events are delivered through a transactional outbox with signature verification available to the receiver.
Data minimisation in identity verification
Verification stores a decision, a provider session reference and a non-reversible handle. No document, image or extracted document field is received or retained.
Not in place
No SOC 2 report. No third-party penetration test. No published availability commitment and no measurement of one. No bug-bounty programme. These are stated because an annex that lists only strengths is not an assessment.
Annex III — sub-processors
The authorised sub-processors, and what each one does, are listed at Sub-processors. That page is the operative list; this annex incorporates it by reference so that a change to the list is a change to one document rather than to two that can disagree.