Lawful-Basis Mapping
Status: Published · Last reviewed: 2026-04-16 · Next review: 2027-04-16 Regulatory reference: Articles 6 and 9 GDPR.
Every processing activity carried out by Syncflow is mapped below to its lawful basis under Art. 6 GDPR. Where consent is relied upon, it is freely given, specific, informed, and withdrawable. Where legitimate interests are relied upon, a balancing assessment is recorded.
1. Processing activities and their lawful basis
1.1 Operating the account
Purpose: Creating the account, authenticating the user on each sign-in, and providing access control.
Lawful basis: Art. 6(1)(b) — performance of the contract to which the data subject is a party (the Terms of Service).
1.2 Delivering the core task-management service
Purpose: Storing the user's tasks and crumbs, tracking progress, providing scheduling, reminders, exports, and templates.
Lawful basis: Art. 6(1)(b) — performance of the contract.
1.3 AI decomposition of tasks
Purpose: On the user's request, breaking a task into crumbs using an AI service. The feature is invoked task-by-task; there is no background or ambient AI processing.
Lawful basis: Art. 6(1)(b) — performance of the contract. The feature is part of the service the user contracts for.
1.4 Billing and subscription management
Purpose: Processing paid subscriptions, retrying failed payments, and maintaining accounting records.
Lawful basis: Art. 6(1)(b) for the contract itself, and Art. 6(1)(c) for the statutory accounting and tax-record obligations that apply to the controller.
1.5 Transactional email (sign-in links, verification, account notices)
Purpose: Sending the email messages required to operate the account. These are not marketing.
Lawful basis: Art. 6(1)(b) — performance of the contract.
1.6 Optional reminder email
Purpose: Sending an opt-in summary of the next crumb the user has to work on.
Lawful basis: Art. 6(1)(a) — consent. The user opts in through account preferences and can opt out at any time, after which no further reminders are sent.
1.7 Product analytics
Purpose: Aggregate usage analytics for understanding how the product is used overall.
Lawful basis: Art. 6(1)(a) — consent, captured through the cookie/consent preference panel before any analytics is initialised, where the applicable rules require it.
1.8 Security and abuse prevention
Purpose: Protecting the service against unauthorised access, credential stuffing, automated abuse, and misuse of paid or metered features.
Lawful basis: Art. 6(1)(f) — legitimate interests of the controller and of users in a safe service. A balancing assessment is recorded in §2.1 below.
1.9 Service diagnostics
Purpose: Keeping the service available and diagnosing faults.
Lawful basis: Art. 6(1)(f) — legitimate interests. A balancing assessment is recorded in §2.2 below.
1.10 Handling support requests
Purpose: Answering support messages the user sends us.
Lawful basis: Art. 6(1)(b) where the request relates to the contracted service; Art. 6(1)(f) otherwise.
1.11 Legal compliance and defence of claims
Purpose: Responding to lawful requests from authorities; establishing, exercising, or defending legal claims.
Lawful basis: Art. 6(1)(c) and Art. 6(1)(f).
1.12 Autopilot: carrying out the rules the user configured
Purpose: Evaluating the rules a user has built, and performing the actions those rules allow on that user's own tasks and crumbs: researching, planning, drafting, and, where the user has raised the limit themselves, completing an item and asking for approval.
Lawful basis: Art. 6(1)(b) performance of the contract. The feature is part of the service the user contracts for, it does nothing until the user builds a rule and switches it on, and the user sets the limits it operates under.
1.13 Autopilot: the run ledger
Purpose: Recording every decision Autopilot made, including the ones where it decided to do nothing, together with the facts the decision was based on. The record answers "why did my rule do this", supports investigation of a complaint or a security incident, and shows the user what was done on their behalf.
Lawful basis: Art. 6(1)(f) legitimate interests, bounded by a 90-day retention period (30 days for rules running in shadow mode). A balancing assessment is recorded in §2.3 below.
2. Legitimate-Interests Assessments
2.1 Security and abuse prevention (§1.8)
| Test | Assessment |
|---|---|
| Purpose test | Preventing account takeover and abuse is a legitimate interest of both the controller and of users who rely on the service being safe. |
| Necessity test | The processing is the minimum required to recognise abnormal authentication and usage patterns. |
| Balancing test | The data used is routine for any authenticated web service, is not used for profiling or advertising, and is kept only as long as needed to detect and respond to abuse. |
| Conclusion | Legitimate interests apply. |
2.2 Service diagnostics (§1.9)
| Test | Assessment |
|---|---|
| Purpose test | Keeping the service reliable is a legitimate interest shared with users. |
| Necessity test | Aggregate metrics alone are not sufficient to reproduce and fix user-reported faults. |
| Balancing test | Diagnostic telemetry is designed to minimise personal data: user-created content is excluded from it. Retention of diagnostic telemetry is short. |
| Conclusion | Legitimate interests apply. |
2.3 Autopilot run ledger (§1.13)
| Test | Assessment |
|---|---|
| Purpose test | A feature that acts on a user's own work is only acceptable if the user can find out what it did and why. The same record is what allows Syncflow to investigate a complaint, a runaway rule, or an attempt to abuse the feature. |
| Necessity test | The decision cannot be reconstructed after the fact from the task alone: the task has since changed, and the rule may have been edited or deleted. A snapshot of the facts as they stood is the minimum that answers the question. No other user's data is in it. |
| Balancing test | The record is the user's own content and the service's own decisions, it is visible to the user in the product, it is never used for profiling, advertising or training, and it is deleted after 90 days (30 for shadow runs) by a scheduled job rather than on request. |
| Conclusion | Legitimate interests apply, on the condition that the retention limit is enforced. |
3. Article 9 — Special categories of data
Syncflow does not solicit or process special-category data. The free-text fields within tasks and crumbs could, at the user's own volition, contain such data. The Privacy Policy warns users against placing sensitive information into task content. Residual risk is assessed in the DPIA.
4. Article 22 — Solely automated decisions
AI decomposition produces suggestions that the user reviews, edits, or discards. It does not produce a decision that has legal or similarly significant effects on the data subject within the meaning of Art. 22.
Autopilot is automated processing of the user's own task data, and by default it is not solely automated either: the standard setting completes work and then asks the user to approve it. A user may raise that setting themselves so that some actions complete without asking. Even then, the processing has no legal or similarly significant effect on the data subject: it organises, researches and drafts that person's own to-do list, at their own instruction, and every action is reversible and recorded. Art. 22 is therefore not engaged. The safeguards are documented in the DPIA addendum rather than relied on as an Art. 22(3) measure.
5. International transfers
Where a processing activity under any basis above involves transfer of personal data to a country outside the EEA and the UK, Syncflow relies on appropriate safeguards — principally the European Commission's Standard Contractual Clauses and, where relevant, the UK International Data Transfer Addendum — in combination with any available adequacy decision. Safeguards for each processor are summarised in the Processor Data Flows.
6. Right to object (Art. 21)
Where Syncflow relies on legitimate interests (§§1.8, 1.9, 1.13), users have the right to object to the processing. Objections should be submitted to the contact address in the Privacy Policy and will be handled within the timeframes set by GDPR.
7. Summary table
| # | Purpose | Lawful basis | User control |
|---|---|---|---|
| 1.1 | Account operation | Art. 6(1)(b) | Account deletion removes the basis |
| 1.2 | Core product service | Art. 6(1)(b) | Per-item deletion and account deletion |
| 1.3 | AI decomposition | Art. 6(1)(b) | Invoked per task; may be avoided by not using the feature |
| 1.4 | Billing | Art. 6(1)(b) + 6(1)(c) | Subscription cancellation |
| 1.5 | Transactional email | Art. 6(1)(b) | Account deletion |
| 1.6 | Reminder email | Art. 6(1)(a) | Opt-in; revocable in settings |
| 1.7 | Analytics | Art. 6(1)(a) | Consent panel |
| 1.8 | Security | Art. 6(1)(f) | Art. 21 objection right |
| 1.9 | Diagnostics | Art. 6(1)(f) | Art. 21 objection right |
| 1.10 | Support | Art. 6(1)(b) / 6(1)(f) | — |
| 1.11 | Legal compliance | Art. 6(1)(c) / 6(1)(f) | — |
| 1.12 | Autopilot execution | Art. 6(1)(b) | Rules are user-built; pause switch; per-rule off switch |
| 1.13 | Autopilot run ledger | Art. 6(1)(f) | Art. 21 objection right; deleted after 90 days (30 shadow) |