Data Processing Agreement (DPA)

Deutsche Fassung

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

The customer accepts this DPA together with the Terms when signing up in MIRA FIVE. When the documents change, the customer also agrees to the new version in MIRA FIVE. Electronic form is sufficient (Art. 28(9) GDPR). 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.

Last updated: 28 September 2026

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. 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 dashboard, through the API, through the MCP server and in the configuration of the tracker and SDKs. These include the chosen collection 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 (Annex 1, IP address). We pass customer data only to sub-processors under section 5 and to recipients the customer chooses itself; we share the IP addresses of detected attackers with CrowdSec (Annex 3).

(2) Persons we authorise to process customer data have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality. Only named administrators have access to the production systems.

(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.

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 collection mode for each source that matches the legal basis and consent (Annex 1),
• 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.

(3) The customer answers data subject requests itself. Before an export or erasure, it verifies the identity of the requesting person; the dashboard asks for this confirmation. Data collected without consent contains no identifier and cannot be attributed to a 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 API or the MCP server, and platforms such as Google, Meta or Microsoft 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 paragraph 3, we process customer data in the European Union: the service in Germany, the encrypted backups in Finland.

(2) 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) At present, a transfer is only possible for support messages. 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 provided by Hetzner Online GmbH, in particular the ISO/IEC 27001 certification of its data centres.

(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, 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:

(3) Customer data is returned (Art. 28(3)(g) GDPR) by the customer retrieving it itself before the end of the contract: through the dashboard, 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 expire after six months at the most. Until then, they may contain deleted data. 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 (section 17) 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 (section 19); the customer agrees to an amended version in MIRA FIVE. 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 (section 20).

(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.

(5) The German version is authoritative. The English version is for information.

Annex 1: Details of the processing

Subject matter and purposes

MIRA FIVE measures and analyses the use of the customer’s websites and apps 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 and build segments,
• serve and evaluate feature flags and experiments,
• provide the data to the customer through the dashboard, REST API and MCP server,
• handle data subject requests.

Nature of the processing

Collecting and receiving, enriching (country and region from the IP address; device type, browser and operating system from the user agent), storing, aggregating, analysing, displaying, transmitting to recipients the customer chooses, and deleting.

Data reaches MIRA FIVE through the script on the customer’s website, through SDKs, through the collection API for server-side events, through imports from platforms the customer connects (Google Search Console, Google Ads, Meta Ads, Bing Webmaster Tools), and through customer lists the customer uploads.

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 it identifies them or uploads them in customer lists,
• people who have clicked on the customer’s Google ads.

Collection modes

The customer chooses the collection mode for each source.

Both identifiers are random values. They are not derived from device properties and apply only to the ingest key of one source; two sources do not recognise each other. Nothing is stored or sent before consent; withdrawal removes both identifiers. If the browser sends a Do Not Track or Global Privacy Control signal, the script transmits nothing. Server-side transmissions carrying such a signal are stored without identifiers. Browser transmissions whose user agent is missing or indicates a bot are discarded.

Types of personal data

Imports from Google Search Console and Bing Webmaster Tools contain no personal data about the people searching. Imports from Meta Ads contain totals per campaign and ad set only, no data about individual people.

IP address

MIRA FIVE never stores visitors’ IP addresses in the analytics database. The IP address is used only:

1. in memory, to determine country and region with a local geolocation database,
2. as a keyed hash (HMAC) for rate limiting, shortened to the /64 network for IPv6, for 1 to 60 seconds,
3. in the access log of the upstream web server, with host, path including query string, status and time, to detect attacks, for at most 14 days,
4. by the CrowdSec intrusion detection, if a request is recognised as an attack (Annex 3).

Special categories

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

Retention

Other periods:

Export files for a person

7 days

Web server access log

at most 14 days

Error reports

90 days

Records of data subject requests

as long as they are needed to evidence how the request was handled

Encrypted backups

at most 6 months

Place of processing

Germany (Nuremberg and Falkenstein), backups in Finland (Helsinki). 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. All servers are located in data centres of Hetzner Online GmbH in Germany and Finland that are certified under ISO/IEC 27001. Hetzner secures physical access.

System access control (confidentiality)

• Server login only with SSH keys on a non-standard port; login as root is restricted.
• A firewall allows only web traffic and SSH inbound. The CrowdSec intrusion detection blocks detected attackers.
• The databases cannot be reached from the internet; the services communicate over a private network.
• The storage of our administrators’ devices is fully encrypted.
• Passwords for MIRA FIVE have at least 12 characters with upper and lower case letters, numbers and symbols and are checked against known breached passwords; only the first five characters of a hash leave our servers in that check. Only a hash is stored.
• Optional two-factor authentication and passkeys.
• Sessions are stored encrypted on the server and end after 120 minutes of inactivity. Forms are protected against cross-site request forgery.
• Requests are rate-limited; rate limiting uses keyed hashes of the IP address.

Data access control (confidentiality)

• Roles per organisation: owner, admin and member with graduated rights.
• API keys are personal, can have an expiry date and are stored only as a hash. Access tokens for AI clients are valid for one hour, refresh tokens for 30 days.
• The REST API allows read access only. So does the MCP server, unless the customer explicitly allows changes to the setup for a connection; AI agents can never delete.
• Only named administrators have access to the production systems.
• There is no function that lets staff sign in as a customer. Internal tools run only on the command line, require the name of the person running them and a reason, and are recorded in the audit log.

Separation control (confidentiality)

• Every query is limited to the customer’s organisation and project.
• Each source has its own ingest key; identifiers apply only to that key.
• The public demo uses synthetic data only.

Pseudonymisation and data minimisation (confidentiality)

• The IP address is never stored in the analytics database. The user agent is reduced to device type, browser and operating system.
• Query strings and fragments are removed from page addresses and referrers; only UTM parameters and, with consent, click identifiers are kept.
• New website sources collect without consent and without identifiers by default. Identifiers are random values.
• Search terms are cleaned. Password fields, hidden fields and email fields are never captured.
• We run error monitoring ourselves. Request bodies, query strings, cookies, authentication data and database parameters are removed from error reports.

Transfer control (integrity)

• Connections to app.mirafive.io and events.mirafive.io use HTTPS with TLS 1.2 or higher only; requests over HTTP are redirected to HTTPS. The application sets HSTS.
• Credentials for connected platforms (OAuth tokens) are stored encrypted with AES-256; the details of data subject requests are also encrypted individually.
• Backups are encrypted on our server before they leave it.
• Export files are available for 7 days and then deleted; every download is logged.
• 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 append-only audit log records: deletions of projects and organisations, data subject requests and export downloads, every call through the API and MCP (channel, tool or route, credential name, outcome; never the arguments), changes to agent connections, feature flags, segments and experiments, and all actions by staff.
• The log stores only a keyed hash of the IP address and no user agent.

Availability and resilience

• Nightly encrypted backups at a separate location (Helsinki), kept as 7 daily, 4 weekly and 6 monthly snapshots. Data can be restored from them after an outage.
• Monitoring of availability, load and errors with alerting; we run error monitoring ourselves.
• Operating system security updates are installed automatically. Container images are scanned for vulnerabilities weekly.
• Firewall, intrusion detection and rate limiting protect against overload and attacks. Transmissions 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)

• Monitoring, error reports and intrusion detection report anomalies. We assess them and notify breaches under section 7.

Data protection by default (review)

• Collection without consent and without identifiers is the default for new website sources; automatic click capture is off by default there.
• Do Not Track and Global Privacy Control are respected.
• The REST API allows read access only, the MCP server by default as well.
• The retention period is enforced automatically every day.

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). Internal tools for staff interventions require a name and a reason and are logged.

Annex 3: Sub-processors

The following are not sub-processors: Sinch Mailjet (emails only to members, that is account data), Mollie (independent controller for payments), BunnyWay (only our websites mirafive.io and docs.mirafive.io), CrowdSec (IP addresses of detected attackers, for our own security), and platforms, API clients and AI assistants the customer connects itself. The current list is available at Sub-processors.