Data processing addendum

What this is

This addendum is the Article 28 contract between your organisation and us for the personal data we handle on your behalf. It forms part of the Terms of service and applies automatically from the moment you accept them, and there is nothing separate to sign. When an organisation is created, we record that its administrator accepted this addendum, together with its version and the date, so your own procurement records can point to it. If your organisation needs a signed copy on paper, write to us and we will provide one.

The parties

You, the organisation named on the account, are the controller. You decide what your bots read, remember and send, and why.

We, Botseon ApS, a Danish company, CVR 46714040, Skansevej 88, 3400 Hillerød, Denmark, are the processor for that content.

For our own account, billing and security data we are the controller in our own right, and the Privacy policy is the notice for it. That half is not covered by this addendum.

What we process, and for how long

Subject matter. Running the bots your organisation configures, and operating the service around them.

Duration. For as long as your organisation has an account with us, plus the deletion periods in Deletion and return below.

Nature and purpose. Storing, organising, retrieving, transmitting and, through the model providers listed on the Sub-processors page, generating text from your content, so that a bot can do the work a member asked for. Nothing else. We do not use your content for our own purposes, we do not use it to train models, and we do not share it between customers.

Types of personal data. Whatever your organisation's bots handle. In practice: names, e-mail addresses, phone numbers and other contact details; the content of messages, attachments and documents; what a bot remembers about a person (their role, their organisation, a stated preference, the language they write in, their timezone, their availability, how they relate to your work); files on a bot's computer; and the record of each run. Your bots may be connected to sources we cannot see in advance, so this list describes the shape of the data, not its limits.

Categories of data subject. Your members; the people your members correspond with; and anyone named in the content your bots read.

Special categories. Botseon is not built for special-category data under Article 9 or for criminal-offence data under Article 10. If your bots will handle it, tell us first so we can agree what is needed.

Our instructions

We process your content only on your organisation's documented instructions. Those instructions are this addendum, the Terms of service, and what your members configure in the product: the bots they create, the sources they connect, the rules they save, and the policies an administrator sets.

We process it outside those instructions only where EU or Danish law requires us to, and in that case we will tell you first unless the law forbids us from saying so.

If we think an instruction you give us breaks data protection law, we will tell you.

Confidentiality

Everyone we let near your content is bound to keep it confidential, by their employment contract or by a written undertaking, and that duty continues after they stop working with us. Access is limited to the people who need it to run the service or to answer a support request, and our support staff work from the EU.

What we do to keep it safe

These are the measures in place, as required by Article 32:

• Separation between organisations. Every row of data belongs to exactly one organisation, and the database refuses a read that crosses that line. The rule refuses by default: a query that does not prove which organisation it is for returns nothing at all.
• One write path. A bot never changes your data directly. Every change goes through a single validated path and is recorded in an audit log that can only be added to, never edited.
• Encryption. Data is encrypted in transit and at rest. The sensitive parts are encrypted under a key held separately for each organisation, so that destroying the key makes what it protected unreadable. Each organisation's key is itself stored in the database, encrypted under a master key that is kept outside the database.
• Approval before consequence. High-risk actions always stop and ask a person to approve them, and a run that has read untrusted content is restricted in what it may then do.
• Operational records in the EU. Error tracking is hosted in the EU with personal-data collection switched off; trace data is hosted in the EU with request bodies redacted for organisations on EU-only routing; operational logs are stored in the EU and hold identifiers, not content.
• Testing and review. Access control and isolation are covered by automated tests that run on every change.

We do not hold a certification such as ISO 27001 or SOC 2, and we do not claim one.

Where the data is, and transfers

Your content is stored in the EU on every plan. Two parts of the service can reach outside it, and both are named below: a model call, and a voice call while the call is running. The regions and the providers are listed on the Sub-processors page and in the Privacy policy.

Several of those providers are companies established outside the EEA even though the region they serve us is inside it. Where such a company can reach your data, that is a transfer under Chapter V of the GDPR, and it runs under the European Commission's Standard Contractual Clauses (Decision (EU) 2021/914), Module Three, processor to processor, where we act as your processor, and, where the provider holds one, an active EU–US Data Privacy Framework certification alongside them. The instrument for each provider is named in its row on the Sub-processors page.

A model call is the first. Your organisation starts on EU-only routing, and on that setting a model call is made only on a route that runs in the EU, or is refused. A model call leaves the EU only after the owner of your organisation has moved it off EU-only routing to the setting that allows providers outside the EU, which takes typing the organisation's name to confirm. The Sub-processors page says which routes that setting opens.

A voice call is the other one: while a call is running, the audio and the turn-by-turn transcript are handled by the voice providers named on the Sub-processors page, under the same instruments, and one of them is established in the United States. Everything we keep about the call is stored in the EU with the rest of your content. An administrator has to acknowledge a provider outside the EU before the first call that would use it, and an organisation set to EU-only routing gets a provider in the EU or no call.

Sub-processors

You give us general written authorisation to engage sub-processors. The current list is published on the Sub-processors page: one list, linked rather than copied, so there is only one thing to keep right.

Before a new sub-processor starts, we will notify your organisation and give you 30 days to object. If you object on reasonable data-protection grounds and we cannot offer you an alternative, you may terminate the affected part of the service and we will refund the unused part of what you have paid.

We impose the same data-protection obligations on each sub-processor that this addendum imposes on us, and we remain fully liable to you for their performance.

Helping you with your obligations

Data-subject requests. If someone contacts us directly about data your bots hold, we will tell them to contact you and will let you know. We will help you answer a request for access, correction, erasure, restriction, portability or objection, taking into account what the product can do. Today a member does both of the two that are self-service from Settings → General → Your data: taking a copy of their own data, and deleting their own account. Restriction is handled by hand; write to privacy@botseon.com.

Assessments. We will give you the information you reasonably need for a data protection impact assessment or a prior consultation with a supervisory authority. We hand customers a pre-filled DPIA template and an Article 14(5)(b) assessment template on request.

Breaches. If there is a personal data breach affecting your content, we will tell you without undue delay after we become aware of it, and our internal target is within 24 hours, with what we know about what happened, who is affected, what the likely consequences are, and what we are doing about it. We will follow up as we learn more. Notifying your supervisory authority and the people affected is yours to do, and we will help you do it.

Audits

We will make available the information you need to show that we are meeting this addendum, and we will answer a security questionnaire once in any twelve-month period.

You may audit us, or appoint an independent auditor who is not a competitor of ours to do it, once in any twelve-month period, on 30 days' written notice, during business hours, without disrupting the service, and under a confidentiality undertaking. More often than that if a supervisory authority requires it or if there has been a breach affecting your content. You bear the cost of the audit unless it finds a material failure on our part.

Deletion and return

A member can take a copy of their data from Settings → General → Your data for as long as the account is open.

When an organisation is deleted, its content is hidden immediately and permanently removed after a 7-day grace period: the encrypted content, the search indexes built from it, and any bot's computer volumes. At the same point the organisation's key is destroyed, which makes anything still encrypted under it permanently unreadable. Thirty days later we record a verification report of what remains; a non-zero count is raised as a failure and worked, not passed over.

An individual's erasure request is a different operation. It removes or overwrites that person's own rows with no grace period, and it destroys anything belonging to them alone, such as their bot's computer volume and its durable copies. It does not destroy the organisation's key, because that key is shared by everyone in the organisation and destroying it to erase one person would make everyone else's data unreadable. So personal content inside records that belong to other members, such as an audit-log or run-event entry another member's action produced which names the erased person, has the person's identity stripped out rather than being destroyed with the key, and remains technically decryptable under the organisation's key until the organisation itself is deleted.

We are saying that plainly rather than writing "erasure is complete", because it is the honest description. Erasing one person cryptographically would need a separate key per member, which the product does not have today; it is planned engineering work, not a promise this addendum makes.

If a backup is restored, the erasure is replayed against it.

Annexes

The list of sub-processors and the description of what is processed are annexes to this addendum, published on the Sub-processors page and in What we process above. Both are generated from a single internal register, so a change is made in one place.

Liability and precedence

Our liability under this addendum is as set out in the Terms of service, except where the GDPR provides otherwise. Where this addendum and the Terms of service disagree about personal data, this addendum wins.