Skip to content
Glimpii Doku
Back to home

Data Processing Agreement

Last updated: 18 September 2026

This is a translation for convenience. The German version at glimpii-doku.de/auftragsverarbeitung is the legally binding text.

Preamble

This agreement (the "DPA") gives effect to the obligations under Art. 28 GDPR for the processing of personal data carried out in connection with the use of Glimpii Doku.

The Controller is the studio using Glimpii Doku. It determines the purposes and means of processing the data of its own customers and is the controller within the meaning of Art. 4 (7) GDPR in that respect.

The Processor is

Glimpii your lash studio assistant UG (haftungsbeschränkt)
Altenberger Straße 148
51381 Leverkusen
Germany

represented by Daniela Sciuto, e-mail: go@glimpii.com.

The Processor processes that data solely on documented instructions and is a processor within the meaning of Art. 4 (8) GDPR.

This DPA becomes part of the service agreement for Glimpii Doku when that agreement is concluded. It covers every processing operation the Processor carries out for the Controller within Glimpii Doku. It does not cover processing for which the Processor is itself the controller — such as the Controller's own contract, billing and contact data, and audience measurement on glimpii-doku.de. The privacy policy applies to those.

1. Subject matter and duration

1.1 The subject matter is the provision and operation of Glimpii Doku, a web-based application for hygiene and treatment documentation, including storage, processing and provision of the data entered by the Controller.

1.2 This DPA runs for the term of the service agreement. When the service agreement ends, so does this DPA; the obligations under section 10 (deletion and return) and section 4.2 (confidentiality) survive.

2. Nature of processing, data categories, data subjects

2.1 Nature and purpose of processing: collection, recording, organisation, storage, adaptation, retrieval, use, disclosure to the Controller, restriction, erasure and destruction of personal data, to the extent required to provide the contractually agreed service. The purpose is to enable the Controller to meet its documentation, evidentiary and retention obligations towards its customers and the authorities.

2.2 Categories of data subjects

  • the Controller's customers
  • the Controller's employees who use Glimpii Doku

2.3 Categories of personal data

  • Customer master data: name, telephone number, e-mail address
  • Health data under Art. 9 (1) GDPR: allergies and intolerances, contraindications, anamnesis and treatment notes
  • Treatment data: treatment type, date, products and disinfectants used, hygiene checks, treating person
  • Consent and signature data: name of the signing person, signature image, timestamp, checksum over the signed content
  • Employee account data: first and last name, e-mail address, form of address, role and job title within the studio
  • Log data: timestamp, acting person and type of change to records relevant to the documentation

2.4 Special categories of personal data

The Controller processes special categories of personal data under Art. 9 GDPR using Glimpii Doku. Both parties account for this through the measures set out in Annex 1.

3. The Controller's right to issue instructions

3.1 The Processor processes personal data only on documented instructions from the Controller, unless required to do otherwise by Union or Member State law. In that case the Processor informs the Controller of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest.

3.2 The Controller's use of Glimpii Doku — in particular creating, changing, exporting, anonymising and deleting records — constitutes an instruction for the purposes of this agreement. Any further instruction is given in text form to go@glimpii.com.

3.3 The Processor informs the Controller without undue delay if it considers an instruction to infringe data protection law. It may suspend the instruction concerned until the Controller confirms or amends it.

4. Obligations of the Processor

4.1 The Processor processes the data exclusively within the European Union. No transfer to a third country takes place; any such transfer requires the Controller's prior consent.

4.2 The Processor binds every person authorised to process the data to confidentiality, unless they are already under an appropriate statutory obligation of confidentiality. The obligation continues after their activity ends.

4.3 The Processor implements the technical and organisational measures required by Art. 32 GDPR. They are described in Annex 1.

4.4 The Processor has not appointed a data protection officer; the conditions of Art. 37 GDPR and § 38 BDSG are not currently met. The contact for data protection matters is Daniela Sciuto, go@glimpii.com.

4.5 The Processor maintains a record of all categories of processing activities under Art. 30 (2) GDPR and makes it available to the Controller on request.

4.6 The Processor does not use the Controller's data for its own purposes. In particular, treatment, customer and signature data are not used in the Processor's own analyses, in advertising, analytics or training procedures, and are not transferred to the Processor's customer relationship management system.

5. Technical and organisational measures

5.1 The measures in place at the time this agreement is concluded are set out in Annex 1.

5.2 The Processor may adapt the measures during the term provided the level of protection is not reduced. Material changes are documented in Annex 1; the version in force is available at glimpii-doku.de/auftragsverarbeitung.

6. Sub-processors

6.1 The Controller grants the Processor general authorisation under Art. 28 (2) sentence 2 GDPR to engage other processors.

6.2 The sub-processors engaged at the time this agreement is concluded are listed exhaustively in Annex 2 and are approved by the Controller.

6.3 If the Processor intends to add or replace a sub-processor, it notifies the Controller in text form to the e-mail address on file at least four weeks in advance. The Controller may object on data protection grounds within four weeks of receiving the notice. If it objects, the Processor may terminate the service agreement for cause with effect from the intended date of the change where the service cannot reasonably be provided without the sub-processor concerned.

6.4 The Processor concludes a contract with every sub-processor imposing the same data protection obligations as those it owes under this DPA. It verifies before engagement, and periodically thereafter, that the sub-processor provides sufficient guarantees within the meaning of Art. 28 (1) GDPR, and documents that verification.

6.5 Where a sub-processor fails to fulfil its data protection obligations, the Processor remains fully liable to the Controller for that sub-processor's performance.

6.6 Ancillary services the Processor obtains from third parties without those parties gaining access to the Controller's data are not sub-processing for the purposes of this section — for example telecommunications and maintenance services, and the Processor's own payment processing and customer relationship management, which process only the Controller's data as a contracting party and none of the data listed in section 2.3.

7. Assistance with data subject rights

7.1 If a data subject contacts the Processor directly to exercise rights under Chapter III GDPR, the Processor forwards the request to the Controller without undue delay and does not answer it itself.

7.2 The Processor assists the Controller by appropriate technical and organisational measures in fulfilling its obligation to respond to such requests. Glimpii Doku provides functions for access, rectification, anonymisation and deletion of individual records, and for exporting the treatment documentation as a PDF, which the Controller uses on its own.

7.3 The Processor erases, rectifies or restricts processing only on the Controller's instruction.

8. Assistance with security, breach notification and impact assessment

8.1 The Processor assists the Controller in complying with Art. 32 to 36 GDPR, in particular with the security of processing, notification of personal data breaches, and data protection impact assessments.

8.2 The Processor notifies the Controller of any personal data breach affecting the Controller's data that comes to its attention without undue delay and at the latest within 24 hours of becoming aware of it, in text form to the e-mail address on file. The notification states, as far as known, the nature of the breach, the categories of data affected, the approximate number of data subjects and records concerned, the likely consequences, and the measures taken and proposed.

8.3 Notification to the supervisory authority under Art. 33 GDPR and communication to data subjects under Art. 34 GDPR are the Controller's responsibility.

9. The Controller's audit rights

9.1 The Processor makes available to the Controller, on request, all information necessary to demonstrate compliance with the obligations under Art. 28 GDPR.

9.2 The Controller may verify compliance with this agreement. Verification is carried out primarily by obtaining a self-assessment, by presentation of Annex 1 and, where available, by presentation of certificates or audit reports from independent bodies.

9.3 Where those records are not sufficient in an individual case, the Controller may, on at least four weeks' notice and during normal business hours, carry out an on-site inspection or have one carried out by an auditor bound to confidentiality who is not a competitor of the Processor. The Processor may decline inspections that would unreasonably disrupt operations and offer a prompt alternative date.

9.4 The Processor permits and cooperates with inspections by the supervisory authority competent for the Controller.

10. Deletion and return on termination

10.1 The Controller may export its data from Glimpii Doku at any time during the term.

10.2 After the service agreement ends, the Processor deletes all of the Controller's data unless the Controller requests their return in text form within 30 days of termination. Deletion takes place no later than 30 days after that period expires.

10.3 Backup copies are overwritten in the course of the regular retention cycles described in Annex 1 section 3 and expire no later than 30 days after deletion from the production system. Individual records are not deleted from within an existing backup; this is technically impossible and would destroy the integrity of the backup.

10.4 The Processor may retain documentation that serves to demonstrate lawful data processing beyond the end of the agreement, in line with the applicable retention periods. The same applies to data it is required by law to retain; it may hand such data to the Controller at the end of the agreement to relieve it of that duty.

10.5 The Processor confirms deletion to the Controller in text form on request.

11. Obligations of the Controller

11.1 The Controller is responsible for the lawfulness of processing and for safeguarding the rights of data subjects. In particular it ensures that a legal basis exists for processing the health data listed in section 2.3 — as a rule the data subject's explicit consent under Art. 9 (2) (a) GDPR — and that data subjects are informed in accordance with Art. 13 GDPR.

11.2 The Controller names a contact for data protection matters and keeps the e-mail address on file up to date. Notices under sections 6.3 and 8.2 are sent to that address.

11.3 The Controller administers its employees' accounts itself. It disables the accounts of departing employees without undue delay and does not disclose credentials to third parties.

11.4 The Controller does not enter personal data into free-text fields beyond what the purpose of treatment documentation requires.

12. Liability

12.1 Liability between the parties is governed by the service agreement, supplemented by Art. 82 GDPR.

12.2 Art. 82 GDPR remains unaffected in relation to data subjects.

13. Final provisions

13.1 Amendments and additions to this DPA must be made in text form. This also applies to any waiver of this form requirement.

13.2 Where this DPA and the service agreement including the general terms and conditions conflict, this DPA prevails for the processing of personal data on behalf of the Controller.

13.3 Should any provision of this DPA be or become invalid, the remaining provisions remain unaffected. The parties will replace the invalid provision with a valid one that comes closest to its commercial purpose.

13.4 German law applies.

Annex 1 — Technical and organisational measures (Art. 32 GDPR)

As of 18 September 2026. The measures below describe the actual state of the Glimpii Doku production environment.

1. Confidentiality

1.1 Physical access control

Glimpii Doku operates no data centres of its own. Servers, block storage and object storage are provided by Hetzner Online GmbH:

  • Processing and databases: Falkenstein data centre park, Germany
  • Backups: object storage in Helsinki, Finland

Hetzner is responsible for the physical security of these sites — access control, video surveillance, alarms, uninterruptible power supply and fire protection. Hetzner states that it operates its information security management system in accordance with ISO/IEC 27001. A data processing agreement with Hetzner is in place.

No personal data of the Controller is processed or stored on local media at the Processor's own premises.

1.2 System access control

  • Sign-in runs through a self-hosted identity service (Keycloak) at auth.glimpii-doku.com using OpenID Connect. The application itself stores no passwords.
  • Password policy: at least 12 characters, including at least one upper-case letter, one lower-case letter, one digit and one special character; the password must not equal the user name.
  • Passwords are stored only as a cryptographic hash and cannot be read by the Processor.
  • Protection against automated sign-in attempts: after five failed attempts the account is temporarily locked; the lock-out period increases stepwise up to 15 minutes.
  • The e-mail address must be confirmed before the first sign-in.
  • Session lifetime: an access token is valid for 15 minutes; a sign-in session ends after 8 hours of inactivity and after 24 hours at the latest.
  • Administrative access to the infrastructure is limited to named individuals and uses personal SSH keys. Access to the Kubernetes API and to SSH is restricted to approved IP addresses in the cloud firewall; only ports 80 and 443 are publicly reachable.

1.3 Authorisation control

  • A role model applies within each studio: studio management and staff have different permissions. Actions with data protection relevance — in particular anonymising a customer record — are reserved to studio management.
  • The application accesses the database with a dedicated, restricted database user; an additional read-only account is capped at five concurrent connections.
  • Credentials and keys are held exclusively in a central secret store (HashiCorp Vault) and delivered from there into the runtime automatically. They are present neither in source code nor in container images.
  • Runtime secrets (Kubernetes Secrets) are stored encrypted in the cluster datastore.
  • The Processor's personnel are granted access only where required for operations and troubleshooting; the Processor currently has no personnel without such an operational role.

1.4 Separation control (tenant isolation)

  • All studios' data reside in one shared database and are logically separated: every record carries a studio identifier, and every query the application issues is bound to the studio identifier taken from the sign-in token, which cannot be influenced from the client device.
  • Production and test environments are fully separated and run on different clusters with different databases. Live data is not copied into the test environment.
  • At the network level the workloads are isolated from one another by network policies; only explicitly permitted connections are allowed.

1.5 Pseudonymisation

  • The application provides an anonymisation function for individual customer records: name, telephone number, e-mail address, allergy and note fields are removed irreversibly, while the treatment history is retained without any personal reference so that the Controller can continue to meet its documentation obligations.
  • In error and performance monitoring, browser version, language setting, screen size and the precise operating system version are stripped before transmission; the session identifier is purely temporary and is not stored on the device.

2. Integrity

2.1 Transfer control

  • All connections to the website and the application are available over TLS only. Unencrypted requests are redirected to HTTPS with a 301.
  • TLS 1.2 and 1.3 are permitted, with forward-secret AEAD cipher suites only (ECDHE with AES-GCM or ChaCha20-Poly1305).
  • Every response carries Strict-Transport-Security: max-age=31536000; includeSubDomains; preload, together with X-Content-Type-Options: nosniff, X-Frame-Options: DENY, Referrer-Policy: strict-origin-when-cross-origin, a restrictive Content-Security-Policy and a Permissions-Policy disabling camera, microphone and location access.
  • System messages are sent over an authenticated SMTP connection secured with STARTTLS.
  • Backups are transferred to object storage over TLS.

2.2 Input control (traceability)

  • The application maintains an append-only audit log that cannot be changed or deleted. It records creation and correction of treatment documentation, exports, creation and modification of a customer record, its anonymisation, completion of hygiene checks and deletion of module data — each with the acting person, timestamp and record affected. The Controller can view this log in the application.
  • Treatment documentation is not overwritten once completed. A correction creates a new record that supersedes the previous one and references it, so the original state remains traceable.
  • A cryptographic checksum is computed and stored over the signed content, which later proves that the signed document has not been altered.
  • The link to the signature page is valid for one hour, can be used once, and expires on signature.

2.3 Application security

  • Changes to source code and infrastructure are made exclusively through versioned merge requests in Git. Deployment to production is automated from the Git state using GitOps; manual intervention on running systems is not part of normal operations.
  • Policies are enforced as code (Kyverno). In production: only container images from approved registries, no unspecific latest tags, mandatory resource limits, and images from the main development branch only.
  • Containers run without root privileges, without privilege escalation and with dropped capabilities.
  • Every change to the application is scanned automatically for known vulnerabilities (Grype), covering the application's dependencies and the built container images. The result is reviewed before release.
  • The server operating system (Flatcar Container Linux) updates itself automatically; reboots are coordinated and carried out one node at a time so the service remains available. The Kubernetes version is rolled forward in a controlled manner by an upgrade controller.

3. Availability and resilience

  • The cluster control plane runs on three servers and the application workload on three more; the application itself runs in at least two instances and scales with load up to twenty. Instances are spread across the servers.
  • The application database (PostgreSQL, CloudNativePG) runs with three instances in production, with automatic failover.
  • Database backup: continuous archiving of the transaction logs plus a daily full backup at 04:00 UTC to Hetzner object storage in Helsinki. Retention: 30 days, which allows point-in-time recovery to any moment within that window.
  • Cluster configuration backup: hourly with 7 days' retention and daily with 30 days' retention.
  • Backups are deliberately held at a different site (Helsinki) from the production systems (Falkenstein).
  • Operation, load and errors are monitored continuously (Prometheus, Grafana, Loki, Tempo) and trigger alerts at defined thresholds.
  • Log data is collected centrally and deleted automatically after 7 days.

4. Procedures for regular review, assessment and evaluation (Art. 32 (1) (d) GDPR)

  • Every change to the application and the infrastructure goes through a merge request, in which security and data protection implications are considered explicitly.
  • The target state of the entire infrastructure is described in Git; deviations of the actual state are detected and reverted by the GitOps reconciliation.
  • The policies under section 2.3 are enforced mechanically on every deployment, not merely reviewed.
  • This annex is reviewed against the actual state of the production environment as required and at least annually, and updated accordingly.
  • Security incidents are handled and followed up under section 8 of this DPA.

5. Control of processing on behalf

The selection, engagement and supervision of sub-processors is governed by section 6 of this DPA. The sub-processors engaged and the services they provide are listed in Annex 2.

6. State of implementation

The Processor discloses which measures are not implemented as at the date of this annex, so that the Controller can assess its risk accurately:

  • Additional encryption of the storage media at operating system level, beyond the measures taken by the data centre operator, is not currently in place. Application data resides unencrypted on block storage inside the isolated cloud environment in Falkenstein; only the runtime secrets are stored encrypted (section 1.3).
  • Two-factor authentication for studio accounts is not currently offered.
  • The automated vulnerability scan described in section 2.3 is advisory: a finding does not fail the build, it is reported in the scan log and reviewed. Software bill of materials (SBOM) generation is configured but currently switched off.
  • The Processor holds no certification, and no penetration test by an independent body has been carried out to date.

Annex 2 — Sub-processors

As of 18 September 2026.

The Processor engages the following sub-processors. The list is exhaustive.

1. Hetzner Online GmbH

  • Address: Industriestr. 25, 91710 Gunzenhausen, Germany
  • Service: operation of servers, block storage and object storage; provision of the network infrastructure including load balancing
  • Data processed: all data listed in section 2.3 of the DPA, insofar as it is stored or transmitted
  • Place of processing: Falkenstein, Germany (processing and databases); Helsinki, Finland (backups)
  • Third-country transfer: none
  • Basis: data processing agreement under Art. 28 GDPR

2. Scaleway SAS

  • Address: 8 rue de la Ville l'Evêque, 75008 Paris, France
  • Service: delivery of system messages (transactional e-mail, smtp.tem.scw.cloud) — e-mail address confirmation, password reset, staff invitations, invoice confirmations
  • Data processed: e-mail address and name of the recipient, subject and body of the message, technical delivery data
  • Not processed: Glimpii Doku sends no messages to the Controller's customers. Customer, treatment and signature data are not transmitted to Scaleway.
  • Place of processing: France
  • Third-country transfer: none

3. No further recipients

Beyond the sub-processors named above, no data listed in section 2.3 of the DPA flows to third parties. In particular:

  • The identity service (Keycloak) is operated by the Processor itself on the infrastructure described in section 1. No external provider is involved.
  • Error and performance monitoring (Grafana Faro, OpenTelemetry) and all logging run on the same self-operated infrastructure. No external provider is involved.
  • Audience measurement and advertising trackers (Google Tag Manager, Google Analytics, Google Ads, Meta pixel, TikTok pixel) run on the glimpii-doku.de website only, only after the individual visitor has consented, and never in the studio application or on the signature page. They process none of the data listed in section 2.3 of the DPA. The Processor is the controller for them; details are in section 11 of the privacy policy.
  • Payment processing (Stripe Payments Europe, Ltd., Ireland) and customer relationship management (HighLevel LLC, USA) process only the Controller's contract and contact data as a contracting party of the Processor. They receive none of the data listed in section 2.3 of the DPA and are therefore not sub-processors for the purposes of this agreement. The Processor is the controller for those processing operations; details are in sections 7 and 10 of the privacy policy.
  • Google Cloud is not used for Glimpii Doku.