How FlowTux handles GDPR and EU data protection

FlowTux processes tickets, linked code context, and the personal data of the people who file and resolve issues. For customers in the European Union and EEA, that processing falls under the General Data Protection Regulation. This is how we structure the product to meet it, and where the responsibility stays with you.

Short version: you are the data controller for the support data you put into FlowTux, and FlowTux is your processor. Our obligations to you are set out in a Data Processing Agreement you can sign before going live. This post is an explanation of how the product works, not legal advice — your DPO or counsel owns the assessment.

Compliance conversations usually start with the obvious categories — names, emails, and the account identifiers of the people filing tickets — and those are the easy part, because you can see them in a schema.

The harder categories arrive inside the content. A stack trace can carry a user email in a variable. A screenshot pasted into a ticket can contain another customer's order. A support conversation about a leave request can include health information nobody intended to write down, which is special-category data under Article 9 and needs a stronger basis than the rest of the queue.

This is worth mapping before rollout rather than after an incident, because it decides your retention and redaction settings. Mark the fields that carry sensitive content as sensitive so they are excluded from analytics and AI prompts, keep attachments on a shorter retention clock than ticket text if your categories warrant it, and decide deliberately whether tickets from HR-shaped categories belong in the same workspace as engineering ones.

FlowTux processes ticket and identity data to deliver the service you asked for — triage, routing, resolution, and reporting — and for nothing else. Your support content is not used to train foundation models, and it is not sold or repurposed for advertising. That is a contractual commitment in the DPA rather than a policy we can quietly revise.

The lawful basis for the underlying processing is yours to determine as controller. In practice most internal support processing rests on contract performance for employee-facing work or legitimate interests for operating a service desk, documented in your own record of processing. What we can tell you is the scope: what the system reads, what it stores, how long, and where — the inputs your assessment needs.

The rights are familiar: access, rectification, erasure, restriction, portability, and objection. The operational question is whether your tooling can actually deliver them without an engineering ticket each time, because a right that requires a support escalation is a right you will fulfil late.

Workspace admins can export a user's ticket history, correct or redact fields, and issue a deletion that propagates through derived artifacts as well as the primary record. That last part is the one teams underestimate: a modern support system holds the same personal data in several derived forms — search indexes, the codebase map, analytics aggregates, and backups — and a deletion that only clears the ticket row leaves copies behind. Backups are handled on the documented retention window rather than being rewritten in place, which is standard practice and worth stating plainly rather than implying instant erasure everywhere.

Two practical notes. Erasure requests conflict with retention obligations more often than people expect — an access-request ticket may be evidence you are required to keep — so decide the precedence rule in advance. And portability applies to data the individual provided, not to your internal notes about them, which is usually the difference between a straightforward export and a redaction exercise.

We maintain Article 30 records for the processing we carry out and publish a current sub-processor list rather than describing it in prose. As of today that list is Google Cloud Platform for application hosting and infrastructure — Google LLC for the United States region and Google Cloud EMEA Limited for workspaces created in the EU region — Microsoft Azure for infrastructure in India, and Meta Platforms for WhatsApp message delivery, which applies only if you enable WhatsApp notifications. Each is bound by equivalent data-protection terms. The authoritative version is on the DPA page, which renders from the same source as the security page, so the two cannot drift apart.

Systems you connect yourself — Slack, GitHub, Sentry, Jira, PagerDuty, Notion, Microsoft Teams — are not our sub-processors. You have your own relationship and your own DPA with each of those vendors, and their regions are their own. This distinction gets blurred in a lot of vendor documentation and it matters for your record of processing.

If a breach affecting your data occurs we notify you without undue delay, so you can meet your own 72-hour obligation to the supervisory authority. The clock that regulators care about is yours, not ours, which is why the commitment is framed around giving you time rather than around our internal process.

Where data leaves the EEA, transfers rely on Standard Contractual Clauses together with supplementary technical measures — encryption in transit and at rest, access controls, and logging. EU customers who need data to stay in region can pin the workspace to the EU at creation, where hosting is provided by Google Cloud EMEA Limited and backups remain within the same regional boundary.

Pinning reduces transfer exposure; it does not eliminate every cross-border question, and claiming otherwise would be misleading. Support access for troubleshooting, the systems you connect yourself, and optional integrations like WhatsApp each have their own path. Data residency and cross-border transfers works through what stays and what moves in each case.

Is customer data used to train models? No — not foundation models, and not shared models across customers. The codebase map and ticket history that make triage useful are per-workspace context, not training data, which is a distinction worth being precise about because the two get conflated constantly.

Is this automated decision-making under Article 22? Triage decisions — category, priority, routing, a suggested fix — do not normally produce legal or similarly significant effects on a person, which is the threshold Article 22 sets. The judgement is yours to make against your own categories, and it is exactly why autonomy is set per category and why every step is written to an auditable timeline. If a category ever did carry significant effects for an individual, it should not be running autonomously.

How is oversight evidenced? Suggest and approve modes keep a human in the loop, and the ticket timeline records what the system decided, what it read, and what it was uncertain about. The EU AI Act and support automation covers the transparency and oversight obligations that sit alongside GDPR.

We are not SOC 2 certified. The Type II audit is in progress and we do not present it as finished — if a vendor comparison shows us with a badge there, it is wrong. GDPR compliance is also not a certification anyone issues; what exists is a DPA, Standard Contractual Clauses, a published sub-processor list, region pinning, and the controls above, which is what a reviewer should be assessing.

And nothing here is legal advice. It is a description of how the product handles data, written so your DPO can do the assessment properly rather than reverse-engineering it from a marketing page.