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)]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
| 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. |
| Data categories received | The content of the task the user chooses to decompose (title, description, 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 | The feature is invoked on a per-task basis. Users who do not invoke the feature have no task content sent to any AI provider. |
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. |
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.
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.