Data Protection Impact Assessment
Status: Published · Version: 1.1 · Date of assessment: 2026-04-16 · Addendum A (Autopilot): 2026-09-18 · Next review: 2027-04-16 or on material change. Regulatory reference: Article 35 GDPR; ICO "Data Protection Impact Assessments" template (v1.3).
This DPIA covers the processing summarised in the Data Inventory, Lawful-Basis Mapping, and Processor Data Flows. A DPIA is not strictly required for Syncflow's processing under Art. 35(3) or the ICO's list of high-risk processing, but one has been completed voluntarily to document the position and to support future scaling. It follows the ICO's seven-step template.
Step 1 — Identify the need for a DPIA
Art. 35(3) triggers reviewed
| Trigger | Applies? |
|---|---|
| Systematic and extensive profiling with legal or similarly significant effects | No — Syncflow does not profile users. |
| Large-scale processing of special-category data | No. |
| Systematic monitoring of a publicly accessible area | No. |
ICO additional screening
| Criterion | Applies? | Notes |
|---|---|---|
| Innovative technology | Partial | Large-language-model decomposition is a novel experience for some users; mitigations are addressed below. |
| Automated decisions denying a service | No | AI output is advisory. |
| Large-scale profiling | No | |
| Biometric data | No | |
| Genetic data | No | |
| Matching or combining datasets | No | |
| Invisible processing | No | Disclosed in the Privacy Policy. |
| Tracking location or behaviour | Partial | Aggregate analytics only, consent-gated. |
| Targeting children or vulnerable individuals | No | |
| Risk of physical harm | No |
Conclusion: DPIA not mandatory under Art. 35(3) or ICO criteria. Conducted voluntarily.
Step 2 — Describe the processing
Nature
- The user signs up through an identity provider or through an emailed sign-in link.
- The user creates tasks and may ask the service to decompose a task into crumbs using an AI provider.
- Progress against crumbs is recorded as the user works.
- Optional features include a daily reminder email and aggregate product analytics.
- Paid subscriptions are administered by a payment processor.
Scope
- Data subjects: registered users of Syncflow.
- Data categories: as set out in the Data Inventory.
- Special categories: none processed by design.
- Geographic scope: global user base; processors located in the EEA, the UK, and the United States.
Context
- Relationship: direct SaaS contract with each user.
- User expectations: users expect to be able to store tasks and — when they invoke the feature — to have the task content processed by an AI provider for decomposition.
- Prior concerns on record: none.
Purposes
The complete list of processing purposes is given in the Lawful-Basis Mapping.
Step 3 — Consultation
Consultation with data subjects
The Privacy Policy provides a contact address for privacy matters. No formal sampling of users was undertaken for this version of the DPIA. The consultation channel remains open.
Consultation with processors
Each processor's current DPA has been reviewed.
Internal consultation
The product owner and the compliance owner reviewed the data flows and this assessment.
Supervisory-authority consultation
Not required under Art. 36(1) — residual risk does not meet the threshold.
Step 4 — Assess necessity and proportionality
| Question | Answer |
|---|---|
| Is the processing lawful? | Yes — see the Lawful-Basis Mapping. |
| Does it achieve its purpose? | Yes — each category of data supports a disclosed feature. |
| Is there a less intrusive way? | On-device LLM decomposition is not presently viable at the quality and latency required. The feature is strictly opt-in per task. |
| How is data quality and minimisation ensured? | Only the content needed for the chosen feature is transmitted to any processor. Diagnostic telemetry excludes user-created content. |
| How are subjects informed? | Through the Privacy Policy and the Data Privacy Plan, linked from this register. |
| How are subject rights supported? | A self-service data-export and account-deletion flow is provided; closure cascades deletion across every category of the user's data. |
| How is processor compliance ensured? | Each processor is bound by a DPA and the safeguards recorded in the Processor Data Flows. |
| International transfers? | Relying on Standard Contractual Clauses and the UK International Data Transfer Addendum as applicable. |
Step 5 — Identify and assess risks
Likelihood and severity are scored Low / Medium / High. "Overall" is the combined residual risk after mitigations in Step 6.
| # | Risk to the rights and freedoms of data subjects | Likelihood | Severity | Overall |
|---|---|---|---|---|
| R1 | A user places sensitive or special-category information into free-text task content that is then transmitted to an AI provider. | Medium | Medium | Medium |
| R2 | Compromise of a user's authenticated session or sign-in credential leads to impersonation. | Low | High | Medium |
| R3 | Misuse of a user-supplied integration credential leads to consumption of that user's own third-party quota. | Low | Medium | Low |
| R4 | Accidental inclusion of personal data in service diagnostics. | Low | Medium | Low |
| R5 | Analytics is initialised before valid consent is recorded for a given region. | Low | Medium | Low |
| R6 | A processor located outside the EEA or UK is compelled by local law to disclose personal data. | Low | Medium | Low |
| R7 | Data belonging to a closed account is not fully removed from all processors. | Low | High | Medium |
| R8 | Reminder email is delivered after the user has opted out. | Low | Low | Low |
| R9 | A registered passkey becomes unusable, preventing sign-in. | Low | Medium | Low |
| R10 | Billing identifiers are used for purposes beyond billing. | Low | Low | Low |
Step 6 — Identify measures to reduce risk
Mitigations are described at a high level so that this document does not become a map of Syncflow's internal controls.
| Risk | Mitigation summary | Residual |
|---|---|---|
| R1 | Clear in-product and Privacy-Policy guidance not to place sensitive information into task content; AI payloads exclude identifiers; the feature is opt-in per task; AI providers with data-use opt-outs are preferred. | Low |
| R2 | Credentials are held encrypted; sessions expire; user-initiated revocation is available; users are encouraged to use passkeys. | Low |
| R3 | User-supplied integration credentials are encrypted at rest, never displayed in full after save, and can be revoked by the user. | Low |
| R4 | Diagnostic telemetry is designed to exclude user-created content. | Low |
| R5 | Analytics is gated behind a consent decision in regions where consent applies. | Low |
| R6 | Standard Contractual Clauses in every relevant processor's DPA; data sent to AI providers is minimised; data-use opt-outs enabled where offered. | Low |
| R7 | Account-closure removes every category of the user's personal data; processor exit procedures are followed when a processor is retired. | Low |
| R8 | Reminder dispatch consults the current preference before sending. | Low |
| R9 | Alternative sign-in paths (email link) remain available for passkey recovery. | Low |
| R10 | Billing identifiers are accessed only by billing functions. | Low |
Mitigations are kept under review as part of the annual review of this DPIA.
Step 7 — Sign-off and outcomes
| Item | Outcome |
|---|---|
| Measures approved by | Compliance owner for Syncflow. |
| Residual risks | All residual risks assessed Low; no Art. 36 consultation required. |
| Subject-consultation responses | None received during the publication window. |
| DPO advice | Syncflow is not required to appoint a DPO under Art. 37; a compliance owner is designated. |
| Review responsibility | Compliance owner, annually and on material change. |
Triggers for re-assessment
- Engagement of any new processor;
- Extension of AI processing beyond on-demand task decomposition and Autopilot as described in Addendum A (in particular, any feature that sends messages on the user's behalf);
- Introduction of any special-category or criminal-offence data;
- Launch of features directed at children;
- Any personal data breach of note;
- Relevant ICO or EDPB guidance updates.
Addendum A: Autopilot (automated processing of the user's own tasks)
Added: 2026-09-18. This addendum extends the assessment above rather than replacing it; where it is silent, the main assessment applies.
A.1 What changed
Until now, AI processing happened only when a user pressed a button on one task. Autopilot lets a user write rules and have Syncflow act on their tasks without pressing anything: researching, planning, drafting, and, if the user raises the limit themselves, completing an item and asking for approval. Two things about the processing are genuinely new, and they are why this addendum exists.
1. It is no longer invoked per task. The user consents once, when they build a rule and switch it on, and the processing then recurs on its own. 2. It keeps a processing log. Every decision is recorded with a snapshot of the facts it was based on, which includes the user's own task and crumb text as it stood at that moment.
A.2 Article 22
Autopilot does not produce a decision with legal or similarly significant effects on the data subject. It acts on that person's own to-do list, at their own instruction. Art. 22 is not engaged. See the Lawful-Basis Mapping §4.
The human-in-the-loop design is nonetheless recorded here, because it is what keeps the feature proportionate rather than because Art. 22(3) requires it:
- Approval is the default. Out of the box the highest setting completes work and then asks the user before anything is treated as done.
- Unattended completion is opt-in and raised in one place. A user raises the limit deliberately, for their whole account, and the setting is recorded. A rule cannot raise it on its own; a rule can only tighten it.
- Some kinds of work are refused outright at the higher settings, including anything the user's own classification marks as physical, financial, health-related or personal.
- Nothing is sent on the user's behalf. Messages and emails are drafted, not sent. Sending is a separate phase that is not built and is not covered by this addendum.
- Work the user has started is never touched.
- Limits are hard. A daily action limit, a token limit, a per-item time limit and quiet hours apply to every run and cannot be overridden by a rule.
- Two stop switches. The user can pause everything from their settings; the operator can disable the feature service-wide.
- Every run is explainable. The user can see which rule fired, on what, why, and what it produced.
- A rule that keeps failing is parked rather than retried indefinitely.
A.3 New or changed risks
| # | Risk to the rights and freedoms of data subjects | Likelihood | Severity | Overall |
|---|---|---|---|---|
| R11 | Recurring processing sends more of the user's task content to an AI provider than the user expected when they built the rule. | Medium | Medium | Medium |
| R12 | The processing log accumulates snapshots of task text indefinitely, creating a second copy of user content with no end date. | Medium | Medium | Medium |
| R13 | An action taken without approval is wrong, and the user does not notice because they did not see it happen. | Medium | Low | Low |
| R14 | Text a user placed in a task is treated as an instruction by the model (prompt injection), causing Autopilot to do something the user did not write. | Medium | Medium | Medium |
| R15 | A brief handed to a local executor reaches a machine the user no longer controls, or one they did not intend. | Low | Medium | Low |
| R16 | AI-generated content overwrites something the user wrote. | Low | Medium | Low |
| R17 | User-written content reaches an operational log or an error report. | Low | Medium | Low |
A.4 Measures
| Risk | Mitigation summary | Residual |
|---|---|---|
| R11 | Rules are off until switched on, and can first be run in shadow mode, where they are evaluated and logged but execute nothing. Every run shows what was sent and what it cost. Hard daily limits cap the volume. A pause switch stops everything at once. | Low |
| R12 | The log is deleted after 90 days, and shadow runs after 30, by a scheduled job. The periods are published in the Tier Classification and are enforced in code rather than by policy. | Low |
| R13 | Approval is the default; unattended completion is opt-in, separately capped per day, and refused for sensitive kinds of work. Every action is recorded, shown in the product, and reversible. | Low |
| R14 | Task text is passed to the model as content rather than as instruction, with an explicit preamble to that effect; output from a local executor is treated as untrusted; nothing produced by the model is executed; rendered output is sanitised. | Low |
| R15 | A local client authenticates with a key the user minted and can revoke in one click, which stops any further work being handed over. Briefs contain the task at hand and nothing else. See Processor Data Flows §2.7. | Low |
| R16 | AI output is stored separately from the user's own text and is never written over it. Applying it to a crumb is a distinct, recorded step. | Low |
| R17 | Operational logging for this feature copies only an explicit list of known fields, so a value carrying user text is dropped rather than truncated, and error reports are assembled by hand rather than by an agent that attaches surrounding state. | Low |
A.5 Necessity and proportionality
The processing achieves a purpose the user asked for and cannot be achieved with less data: a rule about a user's tasks needs those tasks. The alternative of not keeping a processing log was considered and rejected, because a feature that acts on someone's work without being able to explain what it did is less protective, not more; the log is bounded instead. On-device execution is offered as the less intrusive option for users who want it, and is the reason §2.7 of the processor flows exists.
A.6 Outcome
Residual risks are assessed Low after the measures above. No Art. 36 consultation is required. Two items are flagged for the compliance owner rather than closed here:
- Provider error messages. A failing AI provider can echo part of a prompt back inside its error string, and that string is kept in operational diagnostics, bounded in length and scrubbed of credentials. Whether that trade is acceptable, or whether provider messages should be replaced by a code, is a decision for the compliance owner before launch.
- Assignments and executor registrations have no fixed retention period, only deletion on account closure. Whether they should acquire one is left open.
Change log
| Date | Change |
|---|---|
| 2026-04-16 | Initial publication. |
| 2026-09-18 | Addendum A: Autopilot, automated processing of the user's own tasks with human-in-the-loop defaults. |