Data processing agreement

What we process, and why

Article 28(3) asks a controller and processor to write these five things down.

Subject matter and purpose. We relay mentions of your Slack app into the operator channel you pick, and carry operator replies back to whoever asked. We put your data to no other use.

Nature of the processing. We receive Slack events, decide whether each one qualifies for relay, send message and file content to Slack's API, and store the routing details that tie the two threads together.

Duration. As long as your account and the bot exist. Delete the bot or the account and the routing details go with it.

Categories of data subject. Members and guests of your Slack workspace who mention your app, plus the operators who answer them.

Types of personal data. Message and file content while it passes through, which can hold anything your people write. We store Slack channel and thread identifiers, the Slack user id of the person who mentioned the app, a permalink to the original message, and timestamps. Message and file content stays out of storage; how long we keep it lists every row we do keep.

We do not ask for special category data and do not knowingly handle any. Since we carry whatever your people write, health or similar details could pass through a relay. If that is a live prospect in your workspace, you assess it under Articles 9 and 35 before you route those channels.

What we commit to

We handle your personal data only on your documented instructions (Art. 28(3)(a)). Your instructions are this agreement, the terms of service, the settings you choose in the app, and anything further you send us in writing that we accept. We put it to no purpose of our own. We do not sell it and we do not train models on it.

If one of your instructions looks like it breaches the GDPR or another data protection law, we tell you and wait, instead of carrying it out (Art. 28(3), final paragraph). If a law forces us to go beyond your instructions, we tell you first, unless that same law forbids us from telling you.

A duty of confidentiality binds everyone who can reach your data, and it outlasts their involvement (Art. 28(3)(b)). One person operates BotFerry, so that duty covers a single named individual today, whose access reaches only what running and repairing the service needs.

Sub-processors

You authorise the sub-processors on our sub-processors page, which forms part of this agreement and which we keep current (Art. 28(2)). Written terms bind each of them to the data protection obligations we owe you, and we answer to you for what they do with your data (Art. 28(4)).

We give you at least 30 days notice by email before we add or replace one. Object on data protection grounds inside that window and we will work through it with you; if we cannot settle it, you may end the affected part of the service and we refund the unused part of your current period.

Slack sits differently from the rest. Your workspace belongs to Slack already, under your own agreement with them, and no relay reaches your operators without a call to Slack's API. An objection to Slack leaves nothing for BotFerry to do, so treat it as an objection to the service.

International transfers

The application and its database run in France, inside the EEA. Several sub-processors sit in the United States, and the sub-processors page names the safeguard covering each one.

When data leaves the EEA we rely on the European Commission's Standard Contractual Clauses (Art. 46(2)(c)), and on the EU–US Data Privacy Framework on top of them where that provider holds a certification (Art. 45). We keep the Clauses in force even where the Framework covers a provider, because the Framework is under legal challenge and we would rather not lean on it alone. You are the data exporter under those Clauses; we or the sub-processor are the importer, and Module Three governs onward transfers.

Picking an EU sending region from a US provider does not end a transfer. If that provider's staff and logs sit outside the EEA, your data stays reachable from there, so we count it as a transfer on the sub-processors page instead of calling the service EU-only.

Security measures

We take the measures Article 32 requires, matched to the risk. What that means in this system:

• We never write message or file content to long-term storage, so no conversation archive exists for anyone to steal.
• We encrypt your Slack bot token and signing secret at rest with libsodium, under a key we hold outside the database.
• We verify every webhook against your app's Slack signing secret before acting on it.
• We serve all traffic over HTTPS, and store sign-in codes as hashes.
• Activity log entries carry a type, a reason and a timestamp. They never carry message content, and a nightly job deletes them after 90 days.
• Our hosting provider keeps the database and its backups inside the EEA, encrypted at rest.

We review these measures and may change them, so long as the protection they give never falls below what this section describes.

Personal data breaches

When we learn of a personal data breach touching your data, we tell you without undue delay (Art. 33(2)). The 72-hour window belongs to you as controller, not to us, and it opens when we tell you, so we will not hold the news back while we investigate.

Our notice sets out what we know at that moment: what happened, which categories of data it reached and roughly how many records, the likely consequences, and the steps we are taking. Where we cannot give you all of it at once, we send what we have and follow up. You decide whether to notify your supervisory authority and the people affected (Art. 33(1), Art. 34), and we give you what you need to decide.

Helping with requests and assessments

If one of your people asks us directly to show, correct, export or delete data we hold for you, we send them to you and tell you it happened. The answer is yours to give as controller (Art. 28(3)(e)).

We help you answer with whatever we hold, and for relayed data that is a short list: identifiers and timestamps, no content. Most requests resolve to rows we can hand over or delete for you the same day.

We also help with your obligations under Articles 32 to 36, covering security, breach notification, and a data protection impact assessment or prior consultation if you run one (Art. 28(3)(f)).

Audits and evidence

We give you the information you need to show that we meet Article 28 (Art. 28(3)(h)). We answer security questionnaires and send documentation, our sub-processor list and our security description within 30 days of a written request, once a year, and more often where a breach or a supervisory authority makes it necessary. We host an on-site audit where a supervisory authority requires one, at your cost, on 30 days' notice, under confidentiality.

One person runs BotFerry, which is the reason for that limit. An open on-site audit right would take the time that goes into the service you pay for. Tell us before you subscribe if your compliance function needs more than the paragraph above, and we will say yes or no while it still costs you nothing.

When processing ends

Delete a bot and we delete the routing details for its threads. Delete your account and we erase your account data and everything we hold for you, seven days later, leaving you that week to change your mind (Art. 28(3)(g)).

Ask us in writing to return or delete the data we hold for you at any point and we do it within 30 days, unless a law requires us to keep it. Two items outlast deletion, both named in the privacy policy: the invoices Stripe holds as tax records it cannot alter, and a one-way card fingerprint that stops one card claiming the money-back guarantee twice. Neither holds data you control under this agreement.

Changes

We update this agreement when the service changes, when our sub-processors change, or when the law does. If a change cuts your protection or hands you a new obligation, we email you at least 30 days before it takes effect and you may end the agreement instead of accepting it. The date at the top shows when this text last moved, and we keep the full history of these documents.

Send questions, instructions, or a request for a signed copy on your own paper to support@botferry.com. A signature adds nothing legally, since this text already binds us both, so we will ask what your procurement process needs before we redraft anything.