Processor Data Flows
Status: Published · Last reviewed: 2026-04-16 · Next review: 2027-04-16 Regulatory reference: Articles 28 and 44–49 GDPR.
This document lists the third-party processors that may receive personal data as part of operating Syncflow, what they receive, and why. Each processor is bound by a data-processing agreement (DPA) and — where the processing involves transfer outside the EEA or UK — by appropriate transfer safeguards.
Controller: the operator of the Syncflow service. Processors: as listed below.
1. Summary
flowchart LR
User([User]) -->|Sign-in| IdP[Identity providers]
User -->|Tasks & crumbs| App[Syncflow service]
App -->|All stored data| DB[(Managed database)]
App -->|Profile pictures| Object[(Object storage)]
App -->|Aggregate usage events<br/>consent-gated| Analytics[(Analytics)]
App -->|Task content, on request| AI[(AI provider)]
App -->|Email + relevant task summary| Mail[(Email service)]
App -->|Billing reference| Billing[(Payment processor)]
App -->|Work brief, pulled by the user's own client| Local[User's own device]Autopilot adds no new processor. The AI providers it uses are the ones already listed in §2.3, chosen by the user; the job runner and the email service are already listed. The one new flow is the local executor in §2.7, which is not a processor at all: it is the user's own machine.
2. Processor register
2.1 Managed database — primary storage
| Attribute | Detail |
|---|---|
| Role | Processor (Art. 28). |
| Purpose | Persistent storage of the personal data described in the Data Inventory. |
| Data categories received | Account identity, authentication material, preferences, user-generated task content, progress telemetry, support correspondence, operational metadata. |
| Region | A managed-database region is selected by the controller. Data is encrypted at rest. |
| Sub-processors | The cloud-infrastructure providers identified in the processor's sub-processor list. |
| Transfer safeguards | Standard Contractual Clauses through the processor's DPA; UK Addendum where applicable. |
| Retention | Matches the retention of the data itself, as set out in the Tier Classification. |
2.2 Hosting and edge infrastructure
| Attribute | Detail |
|---|---|
| Role | Processor. |
| Purpose | Hosting the application; serving the web interface; storing profile pictures; optional aggregate usage analytics. |
| Data categories received | Transient request metadata during execution; profile pictures uploaded by users; aggregate usage events where the user has consented. |
| Region | The hosting provider's global edge network; profile-picture storage region is selected by the controller. |
| Sub-processors | As listed in the hosting provider's sub-processor list. |
| Transfer safeguards | Standard Contractual Clauses under the hosting provider's DPA. |
| Retention | Transient for request processing; profile pictures until the user replaces or removes them; analytics according to the provider's published retention schedule. |
2.3 AI provider — task decomposition and Autopilot
| Attribute | Detail |
|---|---|
| Role | Processor or, where the user has supplied their own third-party AI key, independent controller for the duration of the request. |
| Purpose | Producing a crumb breakdown from the task content the user submits, and carrying out Autopilot actions (research, plan, draft, complete) on the user's tasks and crumbs. |
| Data categories received | The content of the task the user chooses to decompose or automate (title, description, crumb text, acceptance criteria, and any user-written AI instructions). |
| Data deliberately excluded | Identifiers, email, billing data, authentication material, and other tasks. |
| Lawful basis | Art. 6(1)(b) — the feature is user-invoked. |
| Region | Provider-operated, generally United States. |
| Transfer safeguards | Standard Contractual Clauses through each provider's DPA; data-use opt-outs enabled where offered by the provider. |
| Retention | Governed by the provider's API data policy. Syncflow does not retain the request body after the response is stored against the user's task. |
| User control | Decomposition is invoked on a per-task basis. Autopilot sends task content to the provider only while a rule the user built is switched on; pausing Autopilot or switching the rule off stops it. Users who do neither have no task content sent to any AI provider. Where the user has supplied their own key, the request is billed to them and goes to the provider they chose. Syncflow does not send that key anywhere other than the provider it belongs to. |
2.4 Email service — transactional and reminder mail
| Attribute | Detail |
|---|---|
| Role | Processor. |
| Purpose | Delivering sign-in and verification emails, and — for users who have opted in — the daily reminder email. |
| Data categories received | The recipient's email address; for the reminder, a brief summary of the next crumb the user needs to work on. |
| Lawful basis | Transactional mail: Art. 6(1)(b). Reminder mail: Art. 6(1)(a) consent. |
| Region | Provider-operated. |
| Transfer safeguards | Standard Contractual Clauses under the provider's DPA. |
| Retention | Delivery metadata only, per the provider's logging policy. |
2.5 Payment processor — billing
| Attribute | Detail |
|---|---|
| Role | Independent controller for payment-processing activities (as set out in the processor's own DPA and under payment-services law); processor for controller-initiated billing operations. |
| Purpose | Creating and managing subscriptions, collecting payment, issuing invoices. |
| Data categories received | The user's email and the billing identifier issued by the processor. Card numbers are entered directly into the processor's hosted payment fields and never transit Syncflow. |
| Lawful basis | Art. 6(1)(b) for the contract and Art. 6(1)(c) for statutory financial-record obligations. |
| Transfer safeguards | Standard Contractual Clauses under the processor's DPA; EEA/UK entities used where available. |
| Retention | According to the processor's retention schedule and the statutory retention period for financial records. |
2.6 Identity providers — third-party sign-in
| Attribute | Detail |
|---|---|
| Role | Independent controllers as identity providers; processors for the token-exchange that happens on the user's behalf. |
| Purpose | Authenticating the user through a third-party account the user has chosen (for example, GitHub or Google). |
| Data categories exchanged | The user's name, email, avatar URL, and an identity-provider account identifier are returned after sign-in. |
| Lawful basis | Art. 6(1)(b) — the user has elected this sign-in method. |
| Region | Provider-operated. |
| Retention | Identity-linkage is held only as long as the user keeps that sign-in method enrolled; it is destroyed on account closure or when the user disconnects the sign-in method. |
2.7 Local executor: the user's own machine
Autopilot can hand a piece of work to a client running on the user's own computer, rather than to a cloud AI provider. The client is a program the user installed and authenticated with a key they minted themselves, and it pulls: Syncflow cannot call it, cannot see it, and only knows it exists because it checks in.
| Attribute | Detail |
|---|---|
| Role | Not a processor, and not a recipient in the Art. 28 sense. The destination is equipment under the user's own control, and the transfer happens because the user asked for it. In data-protection terms this is closer to an export by the data subject than to a disclosure to a third party. |
| Purpose | Carrying out an Autopilot action locally, so that the user's task content does not go to any AI provider at all. |
| Data sent | A brief: the task title and description, the crumb being worked on, the acceptance criteria, the user's own instructions, and the expected output format. |
| Data deliberately excluded | Any other user's data, the user's stored AI-provider keys, account identifiers beyond what the client authenticated with, billing data, authentication material. |
| How it is initiated | Only by a rule the user built and switched on, and only when the user has connected a local client. The client requests work; Syncflow never pushes it. |
| What Syncflow records | That a client checked in, under the name and identifier that client reports, and the result it submitted back. See the Data Inventory §10. |
| Transfer safeguards | None are required, because the recipient is the data subject's own equipment and no controller-to-processor transfer takes place. What happens to the content on that machine is outside Syncflow's control and within the user's. |
| User control | Connecting a local client is a deliberate act; the key it uses can be revoked in one click, which stops any further work being handed over. |
It is worth being exact in both directions, because both errors are real. Saying the local executor is a new processor would be wrong and would imply a DPA that cannot exist between Syncflow and its own user. Saying "your data never leaves your device" would also be wrong: the task content lives on Syncflow's servers first, and the brief is sent from there to the machine on request.
3. Data categories that never leave Syncflow
- Session material. Active session artefacts are held inside Syncflow's managed database and are not shared with any other processor.
- Passwords. Syncflow does not use passwords. Authentication is performed via identity-provider sign-in, email links, or passkeys.
- Passkey private keys. Passkeys use public-key cryptography; the user's device holds the private key. Syncflow never receives it.
- User-supplied integration credentials. Credentials the user enters for their own integrations are held encrypted at rest and are not shared with any other processor except the provider to which they authenticate. This includes the AI-provider key used by Autopilot: it is sent to that provider and to nowhere else, and it is never included in a brief handed to a local executor.
4. International transfers
Where any of the processors above carries out processing outside the EEA or UK, Syncflow relies on a combination of:
1. any applicable adequacy decision, 2. Standard Contractual Clauses incorporated into the processor's DPA, and 3. the UK Information Commissioner's International Data Transfer Addendum where the transfer originates in the UK.
A copy of each processor's DPA is available on request.
5. Register maintenance
- A new processor is engaged only after its DPA has been reviewed and an entry is drafted in this document.
- Removal of a processor triggers a review of all personal data previously transferred to it, and a request that any retained copies be purged in accordance with the processor's exit procedure.
- Changes to this register are recorded in the change log of the overview.