Data processing agreement

Last updated: 14.10.2026

This is a translation. The German Auftragsverarbeitungsvertrag is the binding version and prevails.

This agreement applies between the customer as controller and the provider of Eigenlaut named in the imprint as processor. It forms part of the contract for the use of Eigenlaut under our terms of service and is concluded with it, electronically and without a signature (Art. 28(9) GDPR): when the person carrying out the setup accepts the terms and this agreement, before the provider first reads data from the customer's Google Workspace.

Purpose and scope

This agreement ensures that the provider processes personal data that it processes for the customer with Eigenlaut only as Art. 28(3) and (4) of the General Data Protection Regulation (GDPR) require. It applies to the processing described in the annex Description of the processing.

It does not cover data the provider processes as a controller in its own right: the sign-in and member list of the customer area, the audit log for the security of the service, billing through Stripe and communication with the customer. The privacy policy applies to those. Nor does it cover the self-hosted edition of Eigenlaut: whoever runs it processes the data themselves.

Interpretation and precedence

Terms have the meaning the GDPR gives them. This agreement is to be read in the light of the GDPR and must not be read so as to restrict rights or obligations under the GDPR. If a provision of the terms of service or of another agreement contradicts this agreement, this agreement prevails as far as the protection of personal data is concerned.

Description of the processing

The subject matter, nature and purpose of the processing, the types of personal data, the categories of data subjects and the duration are set out in the annex Description of the processing.

Instructions

The provider processes the data only on documented instructions from the customer, including for transfers to a third country, unless Union or member state law requires it to process; in that case it informs the customer of that requirement beforehand, unless the law prohibits this.

The customer's instructions are this agreement, the terms of service and the settings the customer makes in the customer area: the connected organisation, templates, rules, campaigns, schedule, sending addresses, starting and cancelling transfer runs, members and deleting the organisation. The customer gives further instructions in text form to contact@eigenlaut.app.

If the provider considers an instruction to infringe the GDPR or other data protection provisions, it informs the customer without delay and may suspend carrying it out until the customer confirms or changes it.

Purpose limitation

The provider processes the data only for the purposes in the annex Description of the processing. It does not use them for its own purposes, does not pass them on, does not sell them and does not train models with them. For billing it uses only the number of managed mailboxes, a figure without personal reference.

Duration

The provider processes the data only for the term of the contract for the use of Eigenlaut and afterwards only as far as deletion under the section Deletion and return requires.

Security of processing and confidentiality

The provider takes at least the technical and organisational measures in the annex Technical and organisational measures to ensure the security of the data (Art. 32 GDPR). It may adapt them to the state of the art as long as the level of protection does not fall; it documents material changes.

The provider grants access to the data only to people who need it to perform, manage and monitor this agreement, and only to the extent necessary. These people are committed to confidentiality or are under a statutory obligation of confidentiality.

Special categories of personal data

Eigenlaut is not intended to process special categories of personal data (Art. 9 GDPR) or data relating to criminal offences (Art. 10 GDPR). The customer does not use directory fields containing such data in templates, rules or campaigns.

Documentation and audits

The provider makes available to the customer all information necessary to demonstrate compliance with this agreement and with Art. 28 GDPR. This includes the annex on technical and organisational measures, the description of the access model and the stored data on eigenlaut.app, and the evidence of the sub-processor (Cloudflare's certifications and audit reports).

The customer may carry out audits, including inspections, or have them carried out by an auditor bound to confidentiality. It announces them in text form at least 30 days in advance, carries them out during normal business hours without avoidable disruption of operations and bears its own costs. The provider runs no data centres of its own; an audit therefore usually takes place on the basis of documents. Without a specific reason, such as a personal data breach, the customer may request an audit at most once per calendar year.

Sub-processors

The customer gives the provider general authorisation to engage the sub-processors in the annex Sub-processors. If the provider intends to add or replace a sub-processor, it informs the customer in text form at least 14 days in advance. The customer may object to the change within this period for a material data protection reason. If no agreement is reached, either party may terminate the contract for the use of Eigenlaut with effect from the time of the change.

The provider imposes on each sub-processor by contract essentially the same data protection obligations as this agreement imposes on the provider, and is liable to the customer for the sub-processor's performance of them.

Google is not a sub-processor of the provider. The Google Workspace data sits in the customer's Google Workspace, which the customer has agreed with Google itself. The provider reads and writes it through Google's interfaces on the customer's behalf; Google processes it for the customer, not for the provider. The service account through which access runs is in a Google Cloud project of the provider; there Google processes for the provider only the provider's authentication to the interfaces and usage figures of the interfaces.

Stripe is not a sub-processor for this processing. No Google Workspace data goes to Stripe, only details for billing the contract, for which the provider is responsible itself (privacy policy).

Transfers to third countries

Transfers to a country outside the European Economic Area take place only on the customer's instructions and only if the conditions of Chapter V GDPR are met. With this agreement the customer instructs the transfers that are necessary when the authorised sub-processors are used; their legal basis is set out in the annex Sub-processors.

Assistance to the customer

If the provider receives a request from a data subject, it forwards it to the customer without delay and does not answer it itself unless the customer instructs it to. It assists the customer with appropriate technical and organisational measures in answering such requests (Art. 12 to 22 GDPR). The customer can fulfil many rights itself: it changes directory data in Google Workspace, sees the results of transfer runs in the customer area, and removes all data by deleting the organisation.

The provider also assists the customer with the security of processing, notification and communication of breaches, data protection impact assessments and prior consultation of the supervisory authority (Art. 32 to 36 GDPR), as far as it can contribute and taking into account the information available to it.

Notification of personal data breaches

If the provider becomes aware of a personal data breach affecting the customer's data, it notifies the customer without delay, at the latest 48 hours after becoming aware of it, by e-mail to the organisation's administrators. The notification contains, as far as known:

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

What is not yet known, the provider reports as soon as it is available. It documents the breach and assists the customer with its notification to the supervisory authority and its communication to data subjects (Art. 33 and 34 GDPR).

Non-compliance and termination

If the provider breaches this agreement, the customer may instruct it to suspend the processing until the breach is remedied. The customer may terminate the contract for the use of Eigenlaut without notice, as far as it concerns the processing, if the provider does not remedy a material or persistent breach within one month of the suspension, does not comply with a binding decision of a court or supervisory authority, or does not follow an instruction the customer has confirmed after a notice from the provider. The provider may terminate the contract for good cause if the customer insists on an instruction that infringes data protection law.

Liability is governed by the terms of service; Art. 82 GDPR remains unaffected.

Deletion and return

The customer can delete all of its organisation's data itself at any time: in the customer area under "Delete organisation". The provider then deletes all of the organisation's data from its database at once. The only exceptions are data the provider keeps as a controller in its own right (privacy policy): the record of who accepted the terms and this agreement, when and in which version, and the trial record (a check value of the customer number at Google and the end of the trial) against repeated trials until 365 days after the trial ended.

If the contract for the use of Eigenlaut ends (when the trial ends without a subscription or when the subscription ends, terms) and the customer has not deleted the data itself, the provider deletes it 30 days after the end of the contract with the next daily deletion job, unless the customer takes out a subscription by then. Until then the customer can download the audit log and the results of transfer runs in the customer area and view and copy its templates, rules and campaigns. No further return is necessary: the directory data and signatures are in the customer's Google Workspace; the provider holds no originals of them.

Deleted data may remain in the database's version history (Cloudflare D1 "Time Travel") for up to 30 days and then disappears automatically; server logs after at most 7 days. The provider's statutory retention obligations remain unaffected. After the end of the contract the customer withdraws the provider's service account's access in the Google Admin console.

Annex: Parties

Controller: the customer, with the name and address given when ordering; the contact persons are the administrators of its organisation in the customer area. Activity: use of Eigenlaut for its own organisation's e-mail signatures.

Processor:

Justus-Constantin Weidhaus
Hauptstraße 52
96191 Viereth-Trunnstadt
Deutschland
E-mail: contact@eigenlaut.app

Activity: operating Eigenlaut as a hosted service. No data protection officer is appointed because the law does not require one.

Annex: Description of the processing

Categories of data subjects:

• users of the customer's Google Workspace organisation, mainly employees whose signatures Eigenlaut sets or for whom a preview is shown,
• people the customer names in templates or campaigns itself.

Categories of personal data:

• from the Google directory, the fields the customer's templates use: first and last name, e-mail address and other sending addresses, job title, department, phone and mobile number, work location and custom fields the customer created, as well as organisational unit, group memberships, whether the account is suspended or archived and whether the person is a super administrator,
• from Gmail, the current signature of each sending address,
• the signatures generated from them,
• per transfer run and address, the result,
• content the customer enters in templates, campaigns and company details.

No e-mail content, no calendars, no files, no IP addresses.

Nature of the processing: reading directory data through Google's interfaces, choosing the template under the customer's rules, generating the signature, comparing it with the existing signature, writing the signature into Gmail (the "signature" field only), preview in the customer area, recording the result, deletion according to retention periods.

Purpose: consistent e-mail signatures for the customer's organisation according to its templates and rules, including time-limited campaigns, and checking them before transfer.

Storage and retention:

Duration: the term of the contract for the use of Eigenlaut, then until deletion under the section Deletion and return.

Annex: Technical and organisational measures

The measures describe what Eigenlaut actually does.

Tenant separation

• Each organisation is a separate tenant. Every database query for a tenant's data is bound to the tenant ID from the signed-in session, never to a value from the request; automated tests check that a member of one organisation cannot retrieve another's templates, runs and members.
• A Google Workspace organisation can be connected to only one tenant (unique Google customer ID).
• The service account acts only on behalf of (a) the super administrator confirmed by the tenant's setup check, (b) the signed-in person during that check and (c) addresses returned by this tenant's Google directory. No interface accepts an arbitrary address from a request.

Minimal access rights at Google

• Domain-wide delegation for three scopes only: read users, read group members, Gmail settings; the customer sees them before authorising and can withdraw them at any time.
• No access to e-mail content, calendars or files, no write access to the directory.
• In Gmail only the "signature" field is changed (partial update), no other settings.
• Directory queries request only the fields templates use; of custom fields, only the schemas templates name, and their other fields are discarded at once.

Access control to the customer area

• Sign-in only with a Google Workspace account through "Sign in with Google" (OpenID Connect with PKCE, state check in constant time, one-time value, binding to the browser); the sign-in token is checked with Google's public keys (signature, issuer, audience, expiry, verified e-mail address, Workspace domain). Personal Google accounts are rejected.
• Session keys of 256 random bits, stored in the database only as a SHA-256 hash; cookie with the __Host- prefix, Secure, HttpOnly, SameSite=Lax; valid for at most 12 hours; signing out deletes the session.
• Protection against cross-site request forgery: changing requests must be JSON and come from the same origin.
• Rate limiting per IP address (without storing the address) and per tenant for previews.

Authorisation and roles

• Three roles: administrator (everything), editor (templates, rules, company details, previews, test runs), viewer (read only). Live transfers, schedule, members, billing, setup and deleting the organisation for administrators only.
• Members only with addresses in the tenant's domain. Role and membership are re-read on every request; whoever is removed loses access with the next request, and their sessions are deleted.
• The provider itself has an operator view with its own access key (at least 32 characters, constant-time comparison, rate limiting). Only the provider has access to the accounts at Cloudflare, Google Cloud and Stripe, each with two-factor authentication.

Input control

• Audit log of every change, every sign-in and every transfer run with time, acting person, action and target, without signature content; kept for 400 days; visible to administrators and exportable as CSV (formula injection in spreadsheet programs is prevented).
• For each run, the result per address (updated, unchanged, skipped, failed with a reason).

Transfer control and encryption

• All connections encrypted (HTTPS with HSTS); Google's and Stripe's interfaces only over HTTPS.
• Data in Cloudflare D1 is encrypted at rest according to Cloudflare (AES-256-GCM).
• Secrets (the service account key, OAuth and Stripe secrets, the operator key) are kept as encrypted Worker secrets at Cloudflare, never in the source code or the database, and are never logged or returned. If a secret is missing, the function that needs it is switched off.
• Notifications from Stripe are accepted only with a valid signature (HMAC-SHA256, at most 5 minutes old).

Integrity of the signatures

• Templates are checked on saving; active content (scripts, forms, embedded objects, event attributes, javascript: addresses) is rejected, not merely cleaned.
• Previews run in an isolated frame (sandbox) and never in the customer area itself.
• Before a live transfer the customer can start a test run without changes; at most one run per tenant runs at a time (database rule).

Data minimisation and storage limitation

• Directory data is not stored permanently (annex Description of the processing); IP addresses are stored nowhere.
• Error responses from Google and Stripe are reduced to a code before they are stored or logged.
• Server logs without IP addresses and without per-request invocation logs, at most 7 days.
• A daily deletion job removes expired sessions, results after 90 days, runs and the audit log after 400 days, and organisations never connected after 30 days, organisations without a subscription 30 days after the end of the contract.

Availability, resilience and recovery

• Operation on Cloudflare's global network; database and queue in Cloudflare's EU jurisdiction.
• The database can be restored to any point in the last 30 days (Cloudflare D1 "Time Travel"); after a restore, deletions made in the meantime are repeated.
• Transfer jobs are retried up to five times on temporary errors from Google, first after 30 seconds, then with the interval doubled each time or after the wait Google names (at most 24 hours); stuck runs are marked as failed at the latest 3 hours after their last progress.

Regular review

• Before every release of a new version, type checks and automated tests run, including tests of the security requirements (tenant separation, sessions, signature checks, template checks); new versions go to a test address first.
• Dependencies are checked for known vulnerabilities every month.
• Reporting channels for security vulnerabilities and a procedure for security incidents are documented (the provider's security policy).

Annex: Sub-processors

Cloudflare in turn uses sub-processors; Cloudflare publishes the list at https://www.cloudflare.com/gdpr/subprocessors/. The contractual basis is the Cloudflare Customer Data Processing Addendum: https://www.cloudflare.com/cloudflare-customer-dpa/