Technical and Organisational Measures

Annex 1 to the data processing agreement under Art. 32 GDPR. Georg Flossmann, trading as “leanframe”, Ickelsamerstraße 35, 81825 Munich, Germany. Version of 1 November 2026.

This English version is provided for information only. The German version is legally binding.

1. Confidentiality

Physical access to data centres

The servers are located in data centres of Hetzner Online GmbH in the EU that are certified to ISO/IEC 27001. Only data centre staff have access, with access control and video surveillance.
leanframe does not operate its own servers in office premises.

Access to systems

Servers can only be reached through an encrypted VPN and with an SSH key; passwords are disabled for SSH. The database cannot be reached from the internet.
Firewalls at the data centre and on every server allow only the connections that are needed.
The portal works without passwords: sign-in with a one-time code or link by email that expires after 15 minutes. Sessions expire after inactivity.
Every user can set up a passkey (device with fingerprint, face or PIN; only the public key is stored) and sign in with it without email. Each business can require passkeys for admins or for all users; the email code alone is then not enough. New passkeys and resets are logged and reported to the user by email.
The operator area additionally requires a passkey, confirmed at least every 12 hours.
Requests are rate-limited per address to prevent guessing of credentials.

Access to data

Each business is separated in the database by row level security. The application only ever sees the data of the signed-in business.
Roles in the portal (owner, staff) determine who may see and change what. Only owners may manage the subscription and payment.
leanframe only accesses a business’s data through support access: with a stated reason, time-limited, visible in the portal, reported by email and can be ended by the business at any time.
Credentials for services are stored encrypted and are known only to the owner of leanframe.
With Google and Microsoft, the customer signs in with the provider (OAuth 2.0 with PKCE); leanframe only receives a revocable access token, never the password, and only requests the permissions needed (mailbox, calendar or contacts; contacts only once the customer switches on the address book, with separate consent). In the address book leanframe only reads and writes contacts in the group “leanframe” that it created itself; syncing runs in a separate background job, not in the web process.
Confidential questionnaire answers (e.g. health data, Art. 9 GDPR) are additionally encrypted per answer with AES-256-GCM (separate derived key, bound to the business and the answer). Only admins and individually authorised staff can see them, only after clicking “Show”; every view and export is logged. They are never sent to an AI model, an email, a webhook, an appointment export or a log file.
Customer credentials (access tokens from Google/Microsoft, passwords or app passwords for mailboxes and iCloud) are stored encrypted with AES-256-GCM, bound to the customer; the key is kept separate from the database. They are never displayed or returned.

Separation

Data of different businesses is logically separated (see above). Development and testing use test data, separate from production.

2. Integrity

Transfer

All connections are encrypted with TLS (HTTPS with HSTS). Database connections only run in the private network.
Backups are encrypted with AES-256 before they are stored.
Emails are sent via a delivery service with SPF, DKIM and DMARC.
Connections to the customer’s mailbox are encrypted only (IMAP over TLS, SMTP with TLS or STARTTLS) with certificate verification. Senders of incoming emails are checked via DKIM; without confirmation the assistant only replies after the customer approves.
Webhooks are only sent to HTTPS addresses with a valid certificate, never to internal networks; every message is signed with a secret of the customer (HMAC-SHA256). Exports are only available to the customer’s admins.

Input control

Changes to appointments are logged with time and acting person. The history can only be added to, not changed.
Actions from the operator area and support access are recorded in a separate log.

3. Availability and resilience

The database is backed up continuously: transaction logs on an ongoing basis, a differential backup daily and a full backup weekly, stored in a separate object storage (Hetzner, Finland). Every night, a copy of these encrypted backups is transferred to a second object storage with a different provider (Scaleway, France). The copy has its own credentials, is versioned and is protected by an object lock: for 14 days after it is written, no file can be deleted or changed, not even with the server's credentials.
Restoring backups is tested regularly.
Monitoring immediately reports outages, missing backups, error rates and slow responses.
Load limits per business and per address protect against abuse and overload.

4. Deletion and data minimisation

Chat transcripts and emails from the connected mailbox are deleted after an adjustable period, confirmation and reminder emails after 30 days, sign-in emails after one day. For permanently undeliverable addresses only address, type and date are kept for the sending block (adjustable, default 90 days); the content is deleted after 30 days. For appointment emails, subject, time and a checksum of the text are kept as proof of which text was sent.
Contacts from abandoned bookings that are not used anywhere else are anonymised after 7 days. All deletion periods also apply to paused and closed businesses that are not yet deleted.
Customers can be deleted in the portal on request. Appointments are then only kept anonymously for statistics.
Aftercare: evidence of ended consents is deleted 3 years after withdrawal or deletion, the log of aftercare emails after 3 years, unsubscribe links after 2 years. The application can only add to the evidence, not change it. Unsubscribe links are only stored as a hash (SHA-256); the path of the one-click unsubscribe is not logged. Clicks on the review link are not recorded.
Questionnaires: confidential answers are deleted after an adjustable period (default 3 years after the customer's last appointment, 1 month to 10 years), immediately on withdrawal unless the business has marked a legal retention duty (then locked until the period ends, no longer shown or used); other answers after an adjustable period from the last appointment (default 24 months). Evidence of consent and the viewing log after 3 years; the application can only add to them, not change them.
The AI model only receives the data needed for the conversation at hand, never confidential questionnaire answers. Chat messages the business marks as confidential are no longer sent to the model in later rounds; in the portal they are only visible to authorised people and only on click (logged).
Staff only change other staff members' appointments with a separate permission granted by an admin.
Calendar subscription links per staff member are only stored as a hash (SHA-256), contain only service, time, location type and the customer's first name, their path is not logged; a new link invalidates the old one immediately.

5. Regular review

Every code change goes through automated tests, including tests of the separation between businesses, and a check of dependencies for known vulnerabilities.
Servers and software are updated at least monthly, security updates promptly.
A backup is made before every change to the database.
These measures are reviewed on significant changes, at least annually.

6. Processor control

Everyone with access to data has undertaken confidentiality in writing; for customers bound by professional secrecy (Section 203 StGB) also secrecy about third-party secrets with information about the criminal liability (Section 203(4) StGB), likewise subprocessors.
Sub-processors are only used in accordance with Art. 28 GDPR and are listed in Annex 2.
leanframe processes data only within the customer’s instructions.