<!-- https://edi-service.eu/en/data-processing-agreement/ · avv-2026-10-18 · edi-service.eu, fokus it solutions · lang=en -->

# Data Processing Agreement (DPA) edi-service.eu

Version `avv-2026-10-18` (English translation) · valid from 18 October 2026 for all contracts concluded on or after that date

This is a convenience translation. **Only the German version is legally binding**; in case of any discrepancy the
German version prevails.

Agreement pursuant to Art. 28 GDPR between the Customer as named in the order ("Controller") and fokus it solutions,
owner Jens Musleh, Herrenberger Str. 62, 71069 Sindelfingen, Germany ("Processor").

---

## § 1 Subject matter and delimitation

1. This Agreement applies only **insofar** as the Processor processes personal data on behalf of the Controller in
   performing the contract for edi-service.eu (Terms, License Agreement, SLA).
2. **Processing on behalf takes place** in the case of:
   a) **Documents in onboarding:** The Controller uploads documents of its trading partners (EDI guidelines, cover
      letters, sample messages, public certificates) to the central system (app.edi-service.eu/onboarding/) and
      answers questions. The central system stores them encrypted, evaluates the text and generates the
      implementation specification from it.
   b) **Setup via the configuration API:** Via the access released by the Controller (tunnel, token with scopes), the
      setup service of the central system reads and writes the configuration of the instance (partners, identifiers,
      channels, mappings, sample messages for test runs). Personal data may become visible in the process, for example
      contact persons of trading partners in the configuration or names in sample messages.
   c) **Support:** where the Controller sends the Processor data containing personal data for a request (for example
      an affected message or an excerpt from the log).
3. **Not processing on behalf** are:
   a) the ongoing business messages: They are processed on the Controller's server. The central system does not
      receive them; reading message contents is technically excluded for the central system's access,
   b) the operation of the software on the Controller's server: The Controller operates the server, database and
      backup itself; the Processor has no SSH or root access there,
   c) the license usage report: It contains only counters and technical identifiers, no personal data,
   d) the data from the order, customer portal and contract handling (company, contact persons, billing data): Here the
      Processor is itself the controller; the privacy policy on edi-service.eu applies.
4. **The Controller's AI provider:** Texts from the documents are sent for evaluation to the AI provider with which the
   Controller has itself concluded a contract. The call runs via the Controller's instance using the Controller's
   access. The AI provider is **not** a sub-processor of the Processor; the Controller governs its relationship with
   the AI provider in its own contract.

## § 2 Nature, purpose, data, data subjects, duration

| Item | Content |
|---|---|
| Purpose | Setup of the Controller's EDI connections (implementation specification, partners, channels, mappings, tests), support |
| Nature of processing | Storing (encrypted), text evaluation, anonymising, transmitting to the Controller's instance, erasure |
| Types of data | Names, functions, business e-mail addresses and telephone numbers of contact persons; companies and addresses; contents of sample messages (for example delivery and invoice addresses, articles, quantities, prices), insofar as they relate to persons |
| Data subjects | Employees and contact persons of the Controller and its trading partners; persons named in sample messages or guidelines |
| Special categories (Art. 9 GDPR) | not envisaged; the Controller does not upload such data |
| Duration | Term of the main contract; documents in onboarding at most until the erasure deadline under § 7 |

## § 3 Instructions

1. The Processor processes the data only on documented instructions from the Controller (Art. 28(3) sentence 2(a)
   GDPR). The instructions result from the main contract, the settings in onboarding (for example the level of
   anonymisation) and the releases in the dashboard. The Controller issues further instructions in text form.
2. If the Processor considers an instruction to be unlawful, it informs the Controller without undue delay.
3. The Processor does not transfer data to third countries. The Controller is responsible for transfers to its AI
   provider (§ 1(4)).

## § 4 Confidentiality

The Processor uses only persons who are bound to confidentiality (Art. 28(3) sentence 2(b) GDPR). Only the owner has
access to the systems of the central system.

## § 5 Technical and organisational measures

The Processor takes the measures under Art. 32 GDPR described in **Annex 2**. It may replace them with equivalent or
better measures and notifies material changes.

## § 6 Sub-processors

1. The Controller grants general authorisation for the sub-processors listed in **Annex 1**.
2. The Processor informs the Controller in text form at least 30 days in advance of any intended addition or
   replacement. The Controller may object for good cause within this period; if no agreement is reached, it may
   terminate the main contract effective on the date the change takes effect (Art. 28(2) GDPR).
3. The Processor imposes the same data protection obligations on sub-processors (Art. 28(4) GDPR).

## § 7 Erasure and return

1. **Documents in onboarding** are deleted automatically 30 days after upload (original and extracted text). The
   Controller can delete them itself at any time before then.
2. Each customer has its own data key for its documents. Once all documents of a customer have been deleted, the
   Processor destroys this key. As a result, copies of the documents in backups can no longer be read either.
3. Metadata for traceability (file name, type, size, checksum, timestamps) and the implementation specification
   generated from the documents are retained. The specification contains no access credentials. The Processor deletes
   the specification and metadata 90 days after the end of the contract, or earlier at the Controller's request.
4. Logs of the setup service contain no business data (tool, result, status, duration, sizes, checksum of the
   arguments).
5. **Backups:** The database of the central system is backed up nightly (7 generations). The virtual machines are
   backed up daily at 01:00, encrypted (14 daily, 8 weekly and 6 monthly generations), and the file system of the
   central system additionally every 15 minutes (encrypted; generations of the last 3 days as well as 7 daily,
   12 monthly and yearly generations). All backups are mirrored, encrypted, to backup storage in the same data centre
   park. The Processor does not restore deleted data from backups, except for recovery after an outage.
6. After the end of the main contract, the Processor deletes all remaining personal data from the processing on behalf
   in accordance with the deadlines of this section, unless there is a statutory retention obligation (Art. 28(3)
   sentence 2(g) GDPR). A return is generally not necessary because the originals are held by the Controller; on
   request, the Processor provides the specification as a file.
7. The central system's access token to the instance is stored only in sealed form. The Controller revokes it in the
   dashboard; the Processor removes it at the end of the contract.

## § 8 Assistance to the Controller

1. The Processor assists the Controller with requests from data subjects (Art. 28(3) sentence 2(e) GDPR), for example
   by deleting documents on instruction, and with the obligations under Art. 32 to 36 GDPR (point (f)).
2. The Processor reports **personal data breaches** to the Controller without undue delay, where possible within
   24 hours of becoming aware of them, with the information available to it.
3. The Processor provides the information necessary to demonstrate compliance and allows audits (point (h)),
   primarily through self-disclosure and documents (this DPA, security reports). On-site audits take place after
   notification with reasonable notice during business hours. Each party bears its own costs of the audit.

## § 9 Liability, final provisions

Art. 82 GDPR applies, supplemented by the liability rules of the Terms. In the event of conflict, this DPA takes
precedence in data protection matters. German law applies.

---

## Annex 1: Sub-processors

| Sub-processor | Service | Location |
|---|---|---|
| Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany | Data centre and rented server on which the virtual machines with the central system and the reverse proxy run; storage space for the encrypted backups | Falkenstein data centre park (Vogtland), Germany |

There are no further sub-processors. The central system and the reverse proxy run on the Processor's own virtual
machines; it uses no external analytics or AI services.

## Annex 2: Technical and organisational measures

Basis: Art. 32(1) GDPR (encryption, confidentiality, integrity, availability, recovery, regular review). Described are
the measures of the central system (containers on a virtual machine of the Processor).

### 1. Confidentiality

| Measure | Implementation |
|---|---|
| Data minimisation | The central system does not receive ongoing business messages; the access to the instance excludes reading message contents |
| Encryption of stored documents | Original and text per file with AES-256-GCM, own nonce, binding to customer, document and purpose; a separate data key per customer, wrapped with the onboarding key; the key is stored as a file only with the services that need it, not in the database |
| Encrypted working state | Answers and information recognised from documents are stored encrypted; the admin role cannot see them |
| Access token to the instance | stored only in sealed form (X25519, HKDF-SHA256, AES-256-GCM); only the setup service can decrypt it |
| Access to onboarding | one link per role with a random token, valid for 14 days, revocable, stored only as SHA-256; session with `__Host-` cookie, `HttpOnly`, `SameSite=Strict`, 2 hours idle, at most 12 hours, CSRF token |
| Access to the customer portal | invitation link from the order (single use, 14 days, stored only as a hash), then password (scrypt) and optionally TOTP; re-authentication before critical actions |
| Admin access | admin view bound only locally and reachable via SSH forwarding; passwords with scrypt, sessions stored only as hashes, CSRF token, log of admin actions |
| Separation of services | Ordering, customer portal, license service, onboarding, setup service and admin in separate containers, each with its own database role and minimal privileges |
| Tenant separation | Tunnel per customer with exactly one permitted port; verification of the instance by signed challenge before each use; setup session bound to exactly one instance |
| Anonymisation before AI | default: e-mail, telephone and, in EDIFACT, contact and name segments replaced by placeholders; stricter level selectable; also enforced for later AI calls of the agent |
| Transmission | encrypted end to end: HTTPS with a valid certificate up to the Processor's reverse proxy, from there TLS in the internal network up to the central system |

### 2. Integrity

| Measure | Implementation |
|---|---|
| Checking of uploaded files | Type determined by content, size limits (10 MB per file, 20 files per partner, 60 MB per customer), no ZIP archives, DOCX only with strict checking, no macros, XML without DTD, private keys rejected |
| Isolated text extraction | PDF and DOCX in a container without network, without secrets and without database, with memory, CPU and time limits |
| Documents control nothing | Contents are treated as untrusted data; AI results are only proposals, checked against the schema |
| Logs | Events in onboarding without contents; tool calls of the setup service append-only, with a checksum instead of arguments; the instance logs every request from the central system with originator, old and new value |
| Signed software | Installer and platform packages signed with separate keys that are not stored in the containers; updates only upwards |

### 3. Availability and recovery

| Measure | Implementation |
|---|---|
| Backup | nightly backup of the central system's database, keys of the central system in a separate encrypted key backup; restore tested; retention under § 7(5) |
| Monitoring | health checks of all services of the central system |
| Consequences of an outage for the Controller | The instance continues to work without the central system (license key 14 days plus 7 days of grace); only the customer portal, setup and onboarding are affected |

### 4. Restriction of outbound connections

The containers of the central system can reach neither the host nor the internal network nor the internet; a dedicated
firewall table on the host enforces this.

### 5. Regular review

Security review of every change before it is merged into the main line, white-box audit at every milestone involving
code and full audit for major changes.

### 6. Organisational

Only the owner has access to the systems. Secrets are stored only in files with restricted permissions. Test and
sample data contain no customer data. A deputy receives access only after a documented handover and a written
commitment to confidentiality.
