Data processing agreement under Art. 28 GDPR

This English version is provided for convenience. The German version is binding.

Between the customer (controller) and Monib Asad Masud, c/o maexware solutions GmbH, z. Hd. Monib Asad Masud, Freiburger Straße 9, 79312 Emmendingen, Germany (processor).

1. Subject and duration. The processor operates the Atomixi service for the controller under the terms of use. This agreement covers all personal data the controller or its connected programs store in Atomixi and runs as long as the user agreement.
2. Nature and purpose. Storing, backing up, preparing for search (vectors computed on the processor's server), retrieving, delivering to the controller and the programs it connects, exporting and deleting, solely to operate the service for the controller.
3. Data and data subjects. The controller decides what it stores. Expected are names, contact and professional details and notes about customers, employees, business partners and other persons the controller deals with. Special categories under Art. 9 GDPR are stored only with a legal basis and after notice in text form.
4. Instructions. The processor processes data only on documented instructions: this agreement, the terms of use and the settings the controller makes in the service. Further instructions go in text form to info@atomixi.com. The processor says at once if it considers an instruction unlawful, and announces a legal duty to process otherwise in advance where the law allows.
5. Confidentiality. Only the processor and persons it engages who are bound to confidentiality have access to the servers. The controller's content is opened only at its request or under a legal duty.
6. Security. The processor takes the measures in Annex 1 (Art. 32 GDPR) and may replace them by equivalent or better ones, documenting the change.
7. Sub-processors. The controller authorises the sub-processors in Annex 2. New or changed sub-processors are announced by email at least 30 days in advance; the controller may object within that period for an important data protection reason and then terminate extraordinarily. Every sub-processor is bound to the same obligations by contract.
8. Assistance. The processor assists with data subject requests (Art. 12–23 GDPR); access, export, rectification and erasure the controller can perform in the service itself. It also assists with Art. 32–36 GDPR as far as it can contribute.
9. Personal data breaches. The processor notifies the controller of a breach affecting its data without undue delay and at the latest within 48 hours, with everything it knows at that time about nature, scope, consequences and countermeasures.
10. End of processing. After the user agreement ends the controller can export its data until deletion; the processor then deletes all data under clause 11 of the terms of use. Backups keep it until their periods expire (Annex 1) and it is used for nothing in that time.
11. Evidence and audits. The processor provides the information needed to demonstrate compliance with Art. 28 GDPR. On-site audits are possible with reasonable notice, at most once a year except after a breach under clause 9, at the controller's cost.
12. Liability. Art. 82 GDPR applies; otherwise the liability clause of the terms of use.

Annex 1: Technical and organisational measures

• Location and physical access. Server at netcup GmbH in a data centre in Germany; physical access is governed by netcup as operator of the data centre.
• Server access. Administrator sign-in only with an SSH key, password sign-in disabled; repeated failures are blocked by fail2ban.
• Service access. Passwords only as Argon2id hashes; sign-in only after a confirmed email address; every access key a random value of 256 bits stored only as SHA-256, with expiry and revocation per key; limits on sign-in attempts per sender and per account.
• Access control and separation. Every request passes one checkpoint; a space is given only to the account that owns it, otherwise the answer is "not found". A test calls every route as account A on the data of account B and expects a refusal each time. Keys can be restricted to single spaces and rights (read, write, delete).
• Browser protection. Origin and host checked before every handler; session cookie with the __Host- prefix; pages without inline script under a content security policy.
• Transfer. Connections only over TLS; backup copies outside the server only encrypted (GPG).
• Input control. The service records when an entry was created and changed and, for memories, their source; granted consents are logged with their time.
• Availability. Daily backup of the whole service, seven days on the server; encrypted copies on four storage media of our own in Germany, each checked against its checksum; copies deleted after 90 days.
• Data minimisation. Search queries not stored; no content in logs; filter against passwords, keys, card and ID numbers on storing.
• Testing. Before public operation a security test with negative tests for every key type, foreign and forged tokens, OAuth and separation.
• Organisation. Changes go live only through tested releases, each naming its source.

Annex 2: Sub-processors

Version: 20 October 2026