Data processing agreement

Version 2026-10-11Last updated 16 October 2026

This agreement on the processing of personal data on behalf of a controller (DPA) applies between Cloo GmbH as processor (“we”) and the customer who uses MIRA FIVE under our Terms of Service (the Terms), as controller.

Cloo GmbH
Reumtengrüner Str. 32B
08209 Auerbach
Germany
Managing directors: Yannick Seeger, Paul Otto
Register court: Amtsgericht Chemnitz, HRB 38181
info@cloo-gmbh.de

Conclusion of this DPA

This DPA forms part of the contract under the Terms. It applies from the first processing of customer data, also before an owner has accepted it in the app.

An owner of an organisation can document the acceptance of this DPA for the whole organisation in MIRA FIVE, in the settings or in the chat. Only an owner can do this. The owner warrants that they may act for the organisation. Electronic form is sufficient (Art. 28(9) GDPR). MIRA FIVE records the organisation, the version of the DPA, the person who accepted it, how they accepted it and the time.

When we publish a new version of this DPA, MIRA FIVE shows the new version as not accepted until an owner accepts it. The new version replaces the old one from that moment. Until then, the version that the organisation accepted last continues to apply.

On request, we send a countersigned version as a PDF. A message to hello@mirafive.io is enough. The terms organisation, project, source, owner, admin and member have the meaning given in the Terms.

1. Subject matter and duration

(1) We process personal data contained in customer data in order to provide MIRA FIVE under the Terms. Customer data is, as in the Terms, all data that the customer or its websites, apps, servers and connected platforms transmit to MIRA FIVE, and the data MIRA FIVE generates from it, such as events, visits, people and imports. It also includes the content of conversations with Mira (the agent in MIRA FIVE), as far as it contains such data. Annex 1 describes the subject matter, nature and purpose of the processing, the types of personal data and the categories of data subjects.

(2) The customer is the controller, we are the processor (Art. 28 GDPR). If the customer itself processes the data on behalf of a third party, section 10 also applies.

(3) Account data is not covered by this DPA. Account data is data about the members of an organisation and about the customer’s account, such as members’ names and email addresses, sign-ins and billing. We are the controller for it; our privacy policy applies.

(4) This DPA applies for the term of the contract under the Terms and afterwards until we have deleted the customer data under section 9.

2. Instructions

(1) We process customer data only on documented instructions from the customer. Documented instructions are:

this DPA,
the Terms,
the settings and actions of the customer and its members in the service, that is in the app, in the chat with Mira, through the REST API, through the MCP server and in the configuration of the tracking script and the events API. These include the chosen tracking mode, connected platforms, deletions and data subject requests. The retention period follows the plan the customer has booked.

(2) The owner or an admin of the organisation concerned gives further instructions in text form, for example by email to hello@mirafive.io. If they go beyond the agreed scope of the service, we may charge the reasonable additional effort after announcing it in advance. If we cannot carry out an instruction, we tell the customer without undue delay.

(3) If we believe an instruction infringes data protection law, we inform the customer without undue delay. We may suspend the instruction until the customer confirms or changes it.

(4) If Union or Member State law requires us to process data, we inform the customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

3. Obligations of Cloo

(1) We process customer data only within the scope of the instructions. We do not sell it, do not train AI models with it and do not use it for our own purposes. The exceptions are aggregated counts without personal reference, such as the number of events per organisation for billing, capacity planning and operations, and the logs used to defend against attacks and to run the service (Annex 1, IP address). We do not use the personal data of one customer for another customer. We pass customer data only to sub-processors under section 5 and to recipients the customer chooses itself.

(2) Persons we authorise to process customer data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. Only the managing directors have personal administrative access to the production systems. Automated systems (deployment, database migrations) use their own keys with restricted rights. The managing directors grant and remove access through our configuration management.

(3) We take the technical and organisational measures under Art. 32 GDPR described in Annex 2. We may adapt them to technical progress as long as the level of protection does not fall. We add material changes to Annex 2.

(4) The service includes tools with which the customer can fulfil data subject requests itself: export of all data about a person, erasure of a person and objection under Art. 21 GDPR. If the customer cannot fulfil a request with these tools, we assist on request with appropriate technical and organisational measures. If a data subject contacts us directly, we forward the request to the customer, as far as we can identify the customer, and do not answer it ourselves.

(5) Taking into account the nature of the processing and the information available to us, we assist the customer with its obligations under Art. 32 to 36 GDPR: security of processing, notification and communication of breaches, data protection impact assessments and prior consultation of the supervisory authority.

(6) We keep a record of processing activities under Art. 30(2) GDPR.

(7) We inform the customer without undue delay of inspections, measures and requests for information by authorities, as far as they concern customer data and informing the customer is legally permitted.

(8) Members of the customer can ask Mira questions about the customer’s data. To answer, MIRA FIVE sends the question of the member, the instructions of the agent, a short note about the project (its name, website domains and the names of its apps and servers) and the results of the reads that Mira runs to a Claude language model (made by Anthropic). Amazon Web Services EMEA SARL runs this model for us in Amazon Bedrock, in AWS data centres in the European Union (Annex 3). The results of the reads are compact aggregates, such as counts, rankings and labels. Every text that comes from tracked data, such as a page path, a page title, a referrer, a campaign name, an event name or a search query, is marked as data, so the model does not read it as an instruction. When a member asks about people, the results can contain the user IDs of the customer, the traits it stored (contact traits as keyed hashes unless the customer chose otherwise), visit times and revenue. When a member asks about advertising or search data, the results can contain spend, clicks, campaign and keyword names and search queries. We never send passwords, tokens or keys of connected platforms, links to export files or raw imported rows to the model. We configure Amazon Bedrock so that AWS writes no prompt and no answer to durable storage (zero data retention). Anthropic, the maker of the model, has no access to the prompts and answers and does not receive them, because Amazon Bedrock runs the models in accounts that only AWS operates. We do not train AI models with the data and do not allow anyone else to do so. The processing for the AI stays in the European Union. A change to the customer’s setup that Mira proposes takes effect only after a member confirms it with a click, and it runs with the rights of that member.

(9) If the customer connects Google Ads or Google Search Console, we handle the data from Google as the Google API Services User Data Policy requires. MIRA FIVE’s use of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. We use this data only to show the customer its own reports and to answer its questions in the chat. To answer, it can reach the AI model of Mira for that answer only, with zero data retention (paragraph 8). We never use Google user data to create, train or improve an AI or machine-learning model, and it is not stored with any model. We never sell it and never use it for advertising.

4. Obligations of the customer

(1) The customer is responsible for the lawfulness of the processing. In particular, it ensures

that there is a legal basis for collection and that any required consent has been obtained, including under § 25 TDDDG for access to the end device,
that it chooses a tracking mode for each project that matches the legal basis and consent (Annex 1), and that it reports the consent of its visitors to the tracking script correctly,
that it informs data subjects under Art. 13 and 14 GDPR,
that it transmits only the personal data it needs for its purposes.

(2) The customer does not transmit special categories of personal data (Art. 9 GDPR) or data relating to criminal convictions and offences (Art. 10 GDPR) to MIRA FIVE. It transmits direct identifiers such as names and email addresses only if it has a legal basis and needs them, and only as traits when identifying a person (identify). It never transmits them in URLs, page titles, event names or freely chosen event properties. The customer does not enter such data in the chat with Mira unless it needs to.

(3) The customer answers data subject requests itself. Before an export or erasure, it verifies the identity of the requesting person; the app asks for this confirmation. Data collected without consent contains no identifier that belongs to a person, and it cannot be attributed to a named person.

(4) The customer is responsible for the actions of its members and for the API keys, MCP connections and platform connections it sets up.

(5) If the customer notices errors or irregularities in the processing, it informs us without undue delay.

5. Sub-processors

(1) The customer gives us general written authorisation to engage sub-processors (Art. 28(2) GDPR). The sub-processors listed in Annex 3 are deemed approved. The current list is available at Sub-processors.

(2) Before we add or replace a sub-processor, we inform the customer at least 30 days in advance. The notice states the name, address, service and place of processing. We send it by email to the owner of each of the customer’s organisations and update the list. If we have to replace a sub-processor at short notice to keep the service or its security intact, we inform the customer without undue delay; the right to object under paragraph 3 remains.

(3) The customer may object to a change in text form within 14 days of receiving the notice, on reasonable data protection grounds. We then look for a solution together with the customer. If we find none, the customer may terminate the contract for the organisations concerned with effect before the new sub-processor is engaged. We refund, pro rata, any fee already paid for the time after the end of the contract. If the customer does not object in time, the change is deemed approved.

(4) We contractually bind every sub-processor to data protection obligations equivalent to those in this DPA, in particular to sufficient guarantees for appropriate technical and organisational measures (Art. 28(4) GDPR). We are liable to the customer for our sub-processors’ compliance with their obligations as for our own conduct.

(5) The following are not sub-processing:

ancillary services in which the service provider has no access to customer data,
recipients the customer chooses itself: programs and AI assistants it connects through the REST API or the MCP server, and platforms such as Google, Meta, Microsoft or Stripe that it connects to MIRA FIVE. Data that flows to them leaves MIRA FIVE on the customer’s instruction. The customer is responsible for these recipients.

6. Place of processing and transfers to third countries

(1) Subject to paragraphs 2 and 3, we process customer data in the European Union: the service on a server of Hetzner Online GmbH in Nuremberg, Germany, the encrypted backups and the stored files at AWS in Frankfurt, Germany, and the AI models in Amazon Bedrock in AWS regions in the European Union. Our own tool server in Falkenstein, Germany, holds error reports and monitoring data, which contain no user data.

(2) Some sub-processors process data outside the European Union. Cloudflare, Inc. handles all traffic to our hosts at its edge network, including the IP addresses of visitors. Its transfer basis is the EU-U.S. Data Privacy Framework, with the standard contractual clauses of its Data Processing Addendum as fallback. AWS stores data in the European Union only. Access from the USA for support and operations cannot be ruled out; the transfer basis is the EU-U.S. Data Privacy Framework and the standard contractual clauses of the AWS Data Processing Addendum. The processing for the AI stays in the European Union (section 3(8)). A transfer to a third country only takes place if the conditions of Art. 44 et seq. GDPR are met, for example through an adequacy decision of the European Commission, including the EU-U.S. Data Privacy Framework, or through standard contractual clauses. We announce new transfers under section 5.

(3) If the customer sends us personal data from customer data by email, it is stored in our mailboxes at Google Workspace, and Google LLC in the USA may process it (Annex 3). The customer avoids this by sending such data only when a request requires it.

7. Notification of breaches

(1) We notify the customer of a personal data breach affecting customer data without undue delay, at the latest within 48 hours of becoming aware of it. The notification goes by email to the owner of the organisation concerned and, where needed, also to its admins.

(2) As far as known, the notification contains the information under Art. 33(3) GDPR:

the nature of the breach, where possible with the categories and approximate number of data subjects and records concerned,
a contact point for further information,
the likely consequences,
the measures taken or proposed, including measures to mitigate adverse effects.

We provide missing information as soon as it becomes available.

(3) We take the necessary measures without undue delay to secure the data and to mitigate adverse effects for the data subjects.

(4) Notifying the supervisory authority and communicating with data subjects is the customer’s responsibility; we assist under section 3(5). A notification or assistance is not an acknowledgement of fault or liability.

8. Evidence and audits

(1) We provide the customer with the information it needs to demonstrate compliance with the obligations under Art. 28 GDPR: this DPA, the measures in Annex 2, the list of sub-processors and answers to questionnaires to a reasonable extent.

(2) The customer may audit compliance with this DPA, including on site. It may carry out the audit itself or appoint an auditor who is bound to confidentiality and is not our competitor. It announces the audit at least 30 days in advance in text form. Audits take place during our business hours without disrupting operations. As a rule, one audit per calendar year is permitted. Further audits are permitted if there is a concrete reason, such as a breach under section 7, or if a supervisory authority requires one; where there is a concrete reason, a reasonable shorter notice period is sufficient.

(3) We do not operate our own server rooms. On-site audits take place at our business premises. For the data centres, we refer to the evidence that the hosting provider and the other sub-processors publish, such as their certifications. Hetzner Online GmbH is certified under ISO/IEC 27001:2022 for its hosting services and data centres, including Nuremberg and Falkenstein. Cloudflare holds ISO/IEC 27001 and SOC 2 Type II certifications. AWS holds ISO/IEC 27001 and SOC 2 certifications.

(4) Each party bears its own costs. We bear our own effort for audits up to one working day per calendar year. Beyond that, we may charge it reasonably after announcing this in advance, unless the audit reveals a material breach of this DPA by us.

9. Rectification, restriction and erasure; return

(1) During the term, the customer deletes customer data itself through the service: individual people, websites, apps, servers, projects or entire organisations. It can update a person’s traits by identifying the person again with new values. If rectification or restriction of processing is not possible with the service, we assist under section 3(4).

(2) Deletion works as follows:

Occasion	Deletion
Retention period of the plan expired (raw events: Free 30 days, Pro 90 days, Enterprise by contract, 90 days until agreed otherwise; other periods in Annex 1)	Deleted in batches by deletion jobs that run regularly. A raw event is deleted after its day has been rolled up into daily counts.
Change to a plan with a shorter retention period	The deletion job reads the retention period of the current plan, so it deletes the older data with its next runs.
Erasure of a person by the customer	At once, with further erasure runs after 1 and 31 days for late-arriving events.
Removal of a website, app or server, or deletion of a project or an organisation	Collection stops at once. A deletion job then removes the data in batches.
Export file for a person	Deleted 24 hours after it was created. The download link is valid for 15 minutes.
End of contract	Remaining customer data within 30 days.

Data that the customer or a person deletes is removed from the live database within 7 days. The deletion jobs usually finish within minutes. Backups follow paragraph 5.

(3) Customer data is returned (Art. 28(3)(g) GDPR) by the customer retrieving it itself before the end of the contract: through the app, the read-only REST API, the MCP server and the per-person export. We do not owe a bulk export of all analytics data in a standard format.

(4) After the end of the contract, we delete the remaining customer data within 30 days, unless Union or Member State law requires us to store it. If the customer deletes an organisation or its account itself, the periods in paragraph 2 apply.

(5) Our encrypted backups keep data for a short time only: a restore to a point in time is possible for 7 to 14 days, and older versions of backup files are removed after a further 21 days. So deleted data can remain in backups for up to 35 days. The backups are versioned and write-protected. We use backups only to restore the service after an outage or data loss. If we restore a backup, we delete previously deleted data again.

(6) On request, we confirm the deletion to the customer in text form.

10. The customer as processor

(1) If the customer itself processes the data on behalf of a third party, for example as an agency for its clients, we are a further processor of the customer. The customer warrants that its contract with the controller allows it to engage us on the terms of this DPA.

(2) The customer passes the controller’s instructions on to us. We act only on the customer’s instructions. The controller’s rights, such as rights to information and audits, are exercised through the customer.

(3) The customer informs the controller that it engages us as a further processor and obtains any required authorisation.

11. Liability

(1) Liability towards data subjects is governed by Art. 82 GDPR.

(2) Between the parties, the liability provisions of the Terms apply, including to recourse under Art. 82(5) GDPR, as far as legally permitted.

12. Final provisions

(1) If this DPA and the Terms conflict, this DPA prevails in matters of data protection.

(2) Changes to this DPA follow the change provision of the Terms. The customer agrees to an amended version in MIRA FIVE as described in the section “Conclusion of this DPA”. Changes of sub-processors follow section 5, adjustments of the measures follow section 3(3).

(3) German law applies. The place of jurisdiction follows the Terms.

(4) If a provision is invalid, the remaining provisions remain valid. It is replaced by a provision that meets the requirements of Art. 28 GDPR.

Annex 1: Details of the processing

Subject matter and purposes

MIRA FIVE measures and analyses the use of the customer’s websites, apps and servers for the customer. The processing serves to

collect and analyse page views, events, visits and paths through the website or app,
attribute channels, campaigns and ad clicks,
show people, goals and revenue,
import advertising, search and revenue data from platforms the customer connects,
answer the questions of the customer’s members in the chat with Mira and show the results as charts, tables and key figures,
provide the data to the customer through the app, the REST API and the MCP server,
handle data subject requests.

Nature of the processing

Collecting and receiving, enriching (country, region and city from the location of the request; device type, browser and operating system from the user agent), storing, aggregating, analysing, displaying, passing to a language model to answer a question (section 3(8)), transmitting to recipients the customer chooses, and deleting.

Data reaches MIRA FIVE through the script on the customer’s website, through the events API for apps and servers, through imports from platforms the customer connects (Google Ads, Google Search Console, Meta Ads, Microsoft Advertising, Bing Webmaster Tools, Stripe) and through the messages members write in the chat.

Categories of data subjects

visitors and users of the customer’s websites, apps and other online services,
the customer’s customers and users, as far as the customer identifies them (identify) or they appear in imported payments,
people whose search queries appear in the imports from Google Search Console and Bing Webmaster Tools (the imports hold no identifier of a person).

Members of the customer’s organisation are data subjects of account data, not of this DPA (section 1(3)).

Tracking modes

The customer chooses the tracking mode for each project. The default is hybrid.

Mode	Script	Storage on the end device	Identifiers
`hybrid` (default)	Full script (`s.js`)	Nothing before and without consent to statistics. With consent: one identifier (`mira_id`) in the local storage (localStorage) of the customer’s domain.	Without consent: a daily visitor identifier derived on our server (see below). With consent: the identifier `mira_id` in addition.
`cookieless`	Script without storage and consent code (`c.js`)	None.	A daily visitor identifier derived on our server.
`persistent`	Full script (`s.js`)	The identifier `mira_id` from the first visit, as long as the visitor has not refused. A refusal or a Global Privacy Control signal stops it.	The identifier `mira_id` and the daily visitor identifier.

No mode sets a cookie. The identifier mira_id is a random value. It is not derived from device properties. It is renewed 395 days after it was created, and visits do not extend it. There is no session identifier on the device; MIRA FIVE builds visits on the server. The persistent mode also uses the local storage (localStorage), not a cookie.

Without consent, the visitor identifier is a daily value. It is the first 16 characters of a hash of a random salt, the project ID and a keyed digest of the IP address and the user agent. The salt is random for each project and each day, and we delete it at the end of that day. So the same person counts as one visitor within that day and one project, and MIRA FIVE cannot recognise the person on the next day. Data without consent never joins a named person, not even through the daily value.

If the browser sends a Global Privacy Control signal, the full script forwards it. The collector then treats the visit as refused, unless the website reports an explicit consent, and it counts a page view without identifiers and without marketing values. A Do Not Track signal is not read. The script does not read form fields. Requests from bots are discarded. The customer can switch the automatic events (engaged time, scroll depth, web vitals, outbound links, downloads, form submissions) off with data-auto="false".

Types of personal data

Category	Content
Pseudonymous identifiers	The daily visitor identifier (without consent); the identifier `mira_id` (with consent to statistics); the customer’s user ID and the link between the browser and the user ID (with consent to statistics only)
Usage data	Event name and time; page path with identifiers replaced by `:id`, page title and host; referrer as host only; custom event properties (at most 30 keys and 1 KiB, strings up to 256 characters); visits derived from these with entry channel, campaign, entry and exit page, number of views and revenue; engaged time, scroll depth and web vitals; outbound link host, download path, form ID and name, not-found pages
Campaign and click data	UTM parameters, `ref` and `via` values, the Google campaign ID; click identifiers (`gclid`, `fbclid`, `msclkid` and similar): without marketing consent only the fact that one was present, with marketing consent the value
Device and browser data	Device type, browser and version, operating system and version, language, time zone and screen class. The user agent itself is not stored.
Approximate location	Country, and where the request carries it, region and city
Revenue data	Amount and currency of revenue events that the script or a server reports (not verified); from a connected Stripe account, per payment: IDs, time, currency, amount, refunded and disputed amounts and how the visitor was found. No names, addresses or card data.
Traits	User ID and traits that the customer sends when it identifies a person, only with consent to statistics. Contact data (email address, phone number) is stored as a keyed hash unless the customer chooses to store it as given.
Search terms	Terms from the site search; a term with an `@` sign or six digits in a row is replaced by “(hidden)”. Form labels that look personal are replaced by “(no name)”.
Advertising and search data	From connected platforms, per account and day: ad spend and clicks by campaign, ad group and keyword; search queries, pages, countries and devices from Google Search Console and Bing Webmaster Tools. We also keep the rows exactly as the platform sent them, so that we can rebuild the figures.
Chat content	The messages of members, the answers of Mira and the results of the reads that Mira runs, including the cards shown
IP address	Only transiently, see below

IP address

MIRA FIVE never stores visitors’ IP addresses in its database and its programs never write them to a log. The IP address is used only:

in memory, to derive the keyed digest for the daily visitor identifier, and to find the country (from the IP network, using the DB-IP Lite country database held in memory, never the full address),
by Cloudflare, which receives all requests to our hosts, passes the visitor IP to the collector and adds the region and city to the request, and whose security rules block IP addresses that send too many invalid requests (Annex 3),
in logs of the server. The reverse proxy on our server can write access logs (IP address, time, request, status code). They stay in the container logs, which are rotated by size and kept for a few days at most. System logs that contain IP addresses (SSH sign-ins, blocked firewall packets) are kept for up to five weeks. The application itself does not log IP addresses.

A customer who sends events through its own proxy passes the IP address of the visitor to us in a header; we use it in the same way.

Special categories

Processing of special categories of personal data is not intended and not permitted under section 4.

Retention

Data	Retention
Raw events	Free 30 days, Pro 90 days, Enterprise by contract (90 days until agreed otherwise)
Visits	180 days
Daily counts without a person (including unique visitors as sketches of daily identifiers)	25 months
People and the links between browsers and people	25 months after the last event
Goal conversions, attribution rows and imported payments	25 months
Imported advertising and search data, including the raw rows	25 months
Daily salt for visitor identifiers	Until the end of the day it belongs to
Rejection samples (host, bundle ID)	14 days
Chat history	Until the member deletes the thread, or the organisation or project is deleted; private chats of a member who leaves the organisation are deleted. There is no fixed maximum.
Chat stream data, finished chat runs	15 minutes after a run, 30 days
Export file for a person	24 hours
Records of data subject requests	The key of the person (a hash) as long as it is needed to evidence how the request was handled; the objection list as long as the project exists
Audit of calls through the API, MCP and chat (who, what, outcome, duration; never the input or the result)	90 days
Audit of actions by our staff	365 days
Error reports	14 days, in our own error monitoring (Sentry) on our own server in Falkenstein, Germany
Encrypted backups	Point-in-time restore for 7 to 14 days, older versions of backup files removed after a further 21 days (up to 35 days in total)

Place of processing

Germany: the service on a server of Hetzner Online GmbH in Nuremberg; encrypted backups and stored files at AWS in Frankfurt; AI models in Amazon Bedrock in AWS regions in the European Union. Processing outside the European Union as described in section 6. Details in section 6 and Annex 3.

Annex 2: Technical and organisational measures

These measures under Art. 32 GDPR apply to the entire service. They are grouped by protection goal: confidentiality, integrity, availability and resilience, and the process for regularly testing, assessing and evaluating the measures.

Physical access control (confidentiality)

We do not operate our own server rooms. The production server is in the data centre of Hetzner Online GmbH in Nuremberg, our tool server is in the data centre of Hetzner Online GmbH in Falkenstein, and the backups are in the data centres of AWS in Frankfurt. The providers secure physical access. Hetzner’s hosting services and data centres are certified under ISO/IEC 27001:2022.
Data at rest on the servers is protected by the physical and access controls of the data centre. The disks of the servers are not encrypted at the operating-system level. Backups are encrypted before they leave the server.

System access control (confidentiality)

Cloudflare receives all requests to the app, the API and the collector, and passes them to our server through a tunnel. The server accepts traffic from the tunnel only. No service publishes a port to the internet.
The containers run with a read-only root file system, without extra Linux capabilities, without the right to gain new privileges, with memory limits and as a user without administrator rights.
The database cannot be reached from the internet; the services communicate over a private network.
Cloudflare rules block IP addresses that send many rejected requests to the collector and let only the permitted methods and path through.
Sign-in uses Google, a six-digit code by email (valid for 5 minutes and stored only as a hash) or a passkey. There are no passwords.
Sessions last at most 30 days and are renewed when used. The session cookie is not readable by scripts. Calls from the browser to the application need the session and a protection header against cross-site request forgery. The REST API and the MCP server never accept a cookie.
Requests are rate-limited. The limits for sign-in use keyed hashes of the IP address and the email address, with at most five codes per address in 15 minutes.
The servers accept SSH only with keys, on a non-standard port. Password sign-in and direct root sign-in from the internet are not possible. A firewall denies all incoming traffic except the web ports and SSH. An intrusion-prevention system (CrowdSec) blocks attacking IP addresses.
Security updates of the operating system install automatically every day. Container images are pinned to versions and scanned for known vulnerabilities every week.
Administration interfaces sit behind Cloudflare Access. Only the managing directors can sign in.
Only the managing directors have personal administrative access to the production systems. Automated systems (deployment, database migrations) use their own keys with restricted rights. The managing directors grant and remove access through our configuration management.

Data access control (confidentiality)

Roles per organisation: owner, admin and member with graduated rights. The service reads the membership from the database on every request. The role never comes from the cookie.
API keys belong to the organisation, and only owners and admins create them in the app. A key is stored only as a hash or fingerprint and is shown once. Access tokens for AI clients are valid for one hour, refresh tokens for 30 days.
A connection of an AI client through the MCP server can read by default. A connection can get write rights only when the customer chooses it, and destructive actions need an explicit confirmation.
A change that Mira proposes in the chat takes effect only after a member confirms it with a click. It runs with the rights of that member.
Staff access: platform staff (the founders) use an admin area that can read across customers. Every read and every write by staff is recorded in an audit log. There is no function that lets staff sign in as a customer.

Separation control (confidentiality)

Every query is limited to the project of the customer. The project comes from the authenticated context, never from the input. A project of another customer answers “not found”.
The daily visitor identifier is valid for one project only.
Each source has its own key for sending data.
Credentials for connected platforms (OAuth tokens and keys) are encrypted per project with AES-256-GCM and are bound to that project and connection.

Pseudonymisation and data minimisation (confidentiality)

The IP address of a visitor is never stored in the database, and the application never writes it to a log. The user agent is reduced to device type, browser and operating system; the user agent itself is not stored.
From page addresses, only the path (with identifiers replaced by :id), UTM parameters and click identifiers are kept. A referrer is reduced to its host. Click identifiers are stored as values only with marketing consent.
Without consent, the visitor identifier is a daily value, and the daily salt is deleted at the end of the day. Visits without consent never join a named person.
Contact traits (email address, phone number) are stored as keyed hashes by default.
Search terms and form labels that look personal are replaced.
The tracking script does not read form fields.
Texts that come from tracked data are marked as data when Mira reads them, so the model does not treat them as instructions.
Error monitoring runs as self-hosted Sentry on our own server in Falkenstein, Germany. Error reports are kept 14 days. The application removes user data, cookies, headers, request bodies and query strings before it sends a report.

Transfer control (integrity)

Cloudflare ends the encrypted connection (TLS) for the app, the API and the collector in the mode that checks the certificate of our server. The application and the website set HSTS.
Credentials for connected platforms (OAuth tokens and Stripe keys) are stored encrypted with AES-256-GCM. Stripe keys that a customer enters must be read-only keys. A secret key is refused.
Backups are encrypted on our server with AES-256 before they leave it. The key is held outside the backup storage. The backup bucket blocks public access, accepts encrypted connections only, encrypts its objects at AWS as well, and is versioned and write-protected.
Export files are available for 24 hours and then deleted. The download link is valid for 15 minutes.
Customer data goes only to sub-processors and to recipients the customer chooses itself. We send no visitor data to the platforms the customer connects.

Input control (integrity)

An audit log records every call through the REST API, the MCP server and the chat with the actor, the action, the outcome and the duration, but never the input or the result, for 90 days.
Actions by our staff are recorded in a separate audit log for 365 days.
The acceptance of this DPA and every data subject request are recorded with the person, the time and the outcome.

Availability and resilience

Continuous archiving of the database log, a full backup every week and a differential backup every day, to an encrypted repository on AWS in Frankfurt. The two latest full backups are kept, so that the data can be restored to a point in time within the last 7 to 14 days.
The services have health checks and memory limits. Prometheus, Alertmanager and Grafana on our own server in Germany monitor availability, load and errors. Alerts reach the managing directors as push notifications and by email.
Cloudflare rules, rate limits and limits on the number of events for each visitor and each hour protect against overload and attacks. Requests from bots are discarded.

Data protection management (review)

We review these measures at least once a year and whenever the service or the infrastructure changes materially.
Persons with access to customer data have committed themselves to confidentiality.

Incident response (review)

Error reports, metrics and the Cloudflare rules report anomalies. We assess them and notify breaches under section 7.

Data protection by default (review)

A new project starts in the hybrid mode: nothing is stored on the device of a visitor without consent.
The Global Privacy Control signal is respected.
The REST API and the MCP server give read access by default.
Retention is enforced automatically by regular deletion jobs.

Processor control (review)

We engage sub-processors only with a contract under Art. 28 GDPR (section 5).
We process customer data only on the customer’s instructions (section 2). Every action by our staff in the admin area is logged.

Annex 3: Sub-processors

The sub-processors, their services, their places of processing and the transfer bases are listed on the page Sub-processors. That list is part of this DPA. Section 5 governs changes to it.