Annex 1 to the Data Processing Agreement

Technical and Organisational Measures (TOMs) pursuant to Art. 32 GDPR

Date: 25 October 2026 · Version: ab-2026-10-25
Processor: Sat-iTec AB, Simeå 8097, 82167 Vallsta, Sweden (Org.nr 559375-4335)
Sub-processor for operations: Sat-iTec Systemhaus GmbH (group company), operation of the platform in Germany (EU)
Platform: ChatiTec (hosting: own data centre in Augsburg, Germany, own Proxmox infrastructure)

Taking into account the state of the art, the costs of implementation and the nature, scope, context and purposes of processing as well as the risk of varying likelihood and severity for the rights and freedoms of natural persons, the processor implements the technical and organisational measures described below in order to ensure a level of security appropriate to the risk (Art. 32 GDPR).

Implementation: The measures are implemented by Sat-iTec AB together with its sub-processor Sat-iTec Systemhaus GmbH, which operates the platform and the data centre in Germany (see Annex 2). Physical and infrastructure measures (in particular sections 1.1 and 3) as well as operations, backups and patch management are carried out by Sat-iTec Systemhaus GmbH. Sat-iTec AB is responsible towards the Controller for all measures and has contractually obliged the sub-processor to implement them pursuant to Art. 28(4) GDPR.

1. Confidentiality (Art. 32(1)(b) GDPR)

1.1 Physical access control (physical access to processing facilities)

• Operation in a data centre in Augsburg with access protection (e.g. mantraps/turnstiles and locking systems, logging of entries, video surveillance).
• Servers in locked racks; access only for authorised personnel on a need-to-know basis.
• Visitors are accompanied and logged.

1.2 System access control (protection against unauthorised use of systems)

• Authentication via individual user accounts; no shared accounts for administrative tasks.
• Passwords are hashed with Argon2 (memory- and compute-intensive, salted hashing method).
• Two-factor authentication (TOTP 2FA) available/enforceable for accounts.
• JWT-based session tokens with rotation (short validity period, renewal/invalidation).
• Rate limiting to fend off brute-force and abuse attempts.
• Automatic locking/time-out of inactive sessions.

1.3 Data access control (authorisation-based access to data)

• Role and authorisation concept (least privilege); separate administrator and user roles.
• Logging of security-relevant access in the audit log.
• Provider secrets (API keys of external AI providers) are stored encrypted with Fernet; no plain text in configuration or repository.
• Regular review and revocation of authorisations that are no longer required.

1.4 Separation control (tenant separation/purpose limitation)

• Separate database VM (data storage on a separate virtual machine, separated from application services).
• Logical separation of the data of different customers/tenants.
• Separation of production, test and development environments.

1.5 Pseudonymisation and anonymisation

• PII tokenisation before every transmission to external AI providers: personal data and professional secrets are automatically detected and replaced by placeholders.
• Anonymisation is enforced by default (PII_FORCE_FOR_EXTERNAL=true); sending identifying plain-text data to external providers is prevented at system level.
• Re-mapping of the placeholders is possible exclusively locally on the infrastructure in Germany and is Fernet-encrypted.
• Purely local models (Ollama/vLLM) are available as a transfer-free alternative without any external data outflow.

2. Integrity (Art. 32(1)(b) GDPR)

2.1 Transfer control (transport)

• Transport encryption by means of TLS (certificates via Let's Encrypt) for all connections to the platform.
• External transmissions take place exclusively in encrypted form and exclusively in anonymised form.

2.2 Input control (traceability)

• Audit log for logging security-relevant events (e.g. logins, administrative changes).
• Time-stamping and – where necessary – attribution to the triggering user accounts.
• Protection of logs against unauthorised alteration.

3. Availability and resilience (Art. 32(1)(b) and (c) GDPR)

• Data backup: daily full backup of the database with automatic plausibility check; retention 14 days; in addition, backup of the systems in a physically separate fire compartment as an unalterable online backup (immutable backup, protection against deletion and encryption by malware); key material is stored separately from the backups.
• Restore procedures and regular testing of the ability to restore (Art. 32(1)(c) GDPR).
• Operation on Proxmox virtualisation with separate virtual machines for application, database and data backup.
• Protective measures against overload and attacks (including rate limiting, monitoring).
• Uninterruptible power supply and air conditioning provided by the data centre.
• Protection against malware (hardening, prompt patch management).

4. Encryption (Art. 32(1)(a) GDPR)

• Transport: TLS for all external connections.
• Secrets: Fernet encryption of the provider API keys and of the local PII mapping data.
• Passwords: Argon2 hashing (no reversible storage).
• Encryption of stored content at application level: chat content, placeholder mappings and memory entries are encrypted with Fernet (AES-128-CBC + HMAC-SHA256), with keys derived per tenant.

5. Process for regularly testing, assessing and evaluating (Art. 32(1)(d) GDPR)

• Data protection management process with regular review of the effectiveness of the TOMs.
• Regular patch and vulnerability management; prompt installation of security-relevant updates.
• Sub-processor control: contractual commitment and monitoring of sub-processors, including the group company Sat-iTec Systemhaus GmbH (see Annex 2).
• Written confidentiality undertakings of the employees of Sat-iTec AB and Sat-iTec Systemhaus GmbH covering personal data and all customer content, including content subject to the customer's professional secrecy (see § 3 of the DPA); awareness-raising/training.
• Incident response process for personal data breaches (detection, assessment, notification pursuant to § 7 of the DPA).
• Regular internal security reviews of the application and configuration as well as prompt installation of security updates.

6. Data protection by design and by default (Art. 25 GDPR)

• Data minimisation through anonymisation enforced by default before external processing.
• Option of fully local operation without external transfer as a privacy-friendly default setting for processing operations requiring particular protection.
• Deactivation of providers with increased third-country concerns (DeepSeek deactivated by default).

Date: 25 October 2026 · Version: ab-2026-10-25 – The measures are reviewed regularly and adapted to the state of the art.