Sub-processor terms

1. Who this applies to

1.1 Any third party that processes personal data on our behalf in providing FlowFinds, whether it processes customer content, account data, or both.

1.2 A vendor we use that never receives personal data — a public pricing feed, a package registry, a source of market data — is not a sub-processor, and this document does not apply to it. We say which is which on the sub-processor page rather than padding the list.

1.3 Where a vendor is an independent controller for its own purposes, such as a payment provider meeting its own regulatory obligations, that part of its processing is governed by its own terms, and we say so.

2. Before we engage a sub-processor

2.1 We assess whether the processing is necessary at all, and whether a narrower integration would send less data.

2.2 We review the vendor’s security posture, its incident history, its location and its own sub-processing chain.

2.3 We conclude a written data processing agreement meeting Article 28(3), including the transfer mechanism required if the vendor is outside the EEA.

2.4 We scope credentials to the minimum the integration needs, and hold them outside the application code.

3. What every sub-processor must agree to

• process personal data only on our documented instructions;
• bind its personnel to confidentiality and limit access to those who need it;
• apply appropriate technical and organisational security measures under Article 32, including encryption in transit;
• notify us of a personal data breach without undue delay, and in any event within 48 hours of becoming aware of it, with enough detail for us to meet our own 48-hour obligation to customers;
• assist us with data subject requests, impact assessments and regulator enquiries;
• not engage a further sub-processor without our authorisation, and to impose these same obligations on any it does engage;
• not use the data for its own purposes, not sell it, and not use it to train models;
• delete or return the data on termination, and confirm the deletion in writing;
• make available the information needed to demonstrate compliance, and submit to audit or provide an equivalent independent report;
• tell us of any legal requirement it becomes subject to that would prevent it meeting these obligations.

4. Data minimisation at the boundary

4.1 We send a sub-processor the least data its function requires. A payment provider receives an amount, a currency and a reference; it does not receive your product research. An email provider receives the message and its recipient; it does not receive your ledger.

4.2 Card numbers never reach us at all: payment card details are entered on the provider’s own hosted page, and what returns to us is a reference and a status.

4.3 Content sent to a model provider for inference is sent for that inference alone, under terms that prohibit its use for training.

5. Ongoing oversight

5.1 We review the sub-processor list at least annually, and whenever an integration changes what data it touches.

5.2 We remove a sub-processor whose function has ended rather than leaving it in place with live credentials.

5.3 A material failure to meet these obligations is grounds for termination and, where the risk requires it, for immediate suspension of the integration.

6. Notice, objection and our liability

6.1 We give customers at least 30 days’ notice before adding or replacing a sub-processor, as clause 5 of the data processing addendum provides, and a customer may object on reasonable data protection grounds.

6.2 We remain fully liable to our customers for the acts and omissions of every sub-processor. Naming a vendor here transfers no responsibility away from us.

6.3 Questions about a specific vendor, or a request for a copy of the transfer clauses relied on, go to [email protected].