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. 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, Nordio ApS, a Danish company, CVR 46714040, Skansevej 88, 3400 Hillerød, Denmark, trading as Botseon, 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 fails closed, so a query that does not prove which organisation it is for returns nothing.
• One write path. A bot never changes your data directly. Every change goes through a single validated path and is recorded on an append-only audit ledger.
• Encryption. Data is encrypted in transit and at rest. The sensitive parts are encrypted under a key held per organisation in an EU key store outside the database, so that destroying the key makes what it protected unreadable.
• Approval before consequence. High-risk actions always raise a card for a person to answer, 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 go to an EU sink 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. Model calls are the one part of the service where that is not yet true of every route: see One model route is outside the EU below. 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.

One model route is outside the EU: Anthropic's Claude models are served today by Anthropic PBC in the United States. That is the primary Claude route, not a fallback, and it runs under the same instruments. EU-resident Claude routes (Google Cloud Vertex AI, EU multi-region, and Amazon Bedrock, eu-central-1) are being enabled and carry no customer data until they are; we will notify your organisation before the route changes.

A transfer impact assessment has not yet been completed and dated for every transfer above. Our sub-processor register carries a field for each one and those fields are unstated today. We are working them, and we will say so on this page when they are done rather than implying they already are.

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 that is an export and an erasure, run from the command line by an administrator (botseon privacy export and botseon privacy erase); there is no self-service console in the web app yet. Restriction is handled by hand.

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 tenants 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

You can export your data yourself for as long as your account is open.

When an organisation is deleted, its content is hidden immediately and permanently removed after a 7-day grace period: encrypted blobs, embeddings, search entries 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.