Data processing agreement Last updated: 5 October 2026 This English translation is provided for convenience. Only the German version is legally binding. Agreement under Article 28 GDPR between the customer as controller and Florian Stemmer, ProAuditMap, Huttengrundstraße 22, 36396 Steinau an der Straße, Germany, as processor (the provider). The customer expressly accepts it at registration together with the terms and conditions. The main contract is the contract for the free account and every subsequent contract for ProAuditMap; § 1 governs the duration of this agreement. § 1 Subject matter and duration The provider processes personal data on behalf of the customer in order to provide ProAuditMap under the main contract. This agreement applies from registration for as long as the provider processes such data: during the account without a plan and the reading period after it, during a paid contract, in the read-only period after the contract ends or after payment default, and during an archive plan. § 2 Nature and purpose of processing, types of data, data subjects Nature: storing, organising, displaying, changing on users’ instructions, receiving uploaded files and automatically scanning them for malware, drawing samples, transmitting for automated generation of drafts and wording suggestions, exporting, backing up and deleting. Purpose: creating, editing, releasing, exporting and archiving audit packages, carrying out audits with working papers, evidence, samples, review and closing, user administration and support. - Types of data: user master data (name, business e-mail address, role, membership), sign-in data (password hash, one-time code secret, session data), log data (who made which change when; for evidence, with checksum and the result of the malware scan, without file content and file names), content data (wizard inputs, audit packages, interview guides, organisation planning, communication drafts with names, functions and contact details entered by the customer), fieldwork data (working papers with test results, notes and reasons, reviews and closing), evidence (files of any content uploaded by the customer, with file name, media type, size and checksum) and populations and samples (lists from systems of the audited unit uploaded by the customer, such as user, permission or change lists, the row list generated from them and the items drawn with their results). - Data subjects: the customer’s users, staff and contacts of audited units and service providers, persons whose data are contained in evidence, populations or samples (above all staff of the audited unit, and also, for example, its customers, suppliers or business partners), and other persons the customer names in content. - Special categories of personal data (Articles 9 and 10 GDPR) are not intended. The customer does not enter or upload them. If a file that is needed for the audit purpose contains such data, the customer removes or redacts them before uploading. - Data minimisation: The customer alone decides which files it uploads and which texts it enters. It ensures that there is a legal basis for this and that only the personal data necessary for the audit purpose are included (Article 5(1)(c) GDPR), for example by using extracts, filters or redactions before uploading. The provider only scans files automatically for malware and does not take note of their content unless the customer instructs it to in an individual case, for example for support or a restore. - Roles: The provider is the controller for registration data, contact data for contract and billing, and the first administrator account. The customer organisation is the controller for all further user accounts in its account and for all content; the provider processes these on its behalf. Data for which the provider is itself the controller are not covered by this agreement; the privacy policy applies to them. § 3 Instructions (1) The provider processes the data only on documented instructions from the customer, including with regard to transfers to a third country, unless required to do so by Union or member state law; in that case it informs the customer of that legal requirement beforehand unless the law prohibits this. Instructions follow from the main contract, this agreement and the use of the application’s functions, for example the retention periods set, uploading and withdrawing evidence and drawing samples; the customer gives further instructions, for example to delete individual items of evidence under § 7(4), in text form. (2) If the provider considers an instruction unlawful, it informs the customer without delay and may suspend execution until confirmation. § 4 Confidentiality and security (1) The provider only uses persons who have committed themselves to confidentiality or are under a statutory obligation of confidentiality. (2) The provider takes the technical and organisational measures under Article 32 GDPR described in Annex 1. It may develop them further as long as the level of protection does not decrease. § 5 Sub-processors (1) The customer gives general authorisation for the use of sub-processors. Those used when the contract is concluded are listed in Annex 2. (2) The provider informs the customer in text form at least 14 days before adding or replacing a sub-processor. Within this period the customer may object for an important data protection reason. If the parties find no solution, the customer may terminate the main contract with effect from the change. (3) The provider imposes on each sub-processor by contract the same data protection obligations as set out in this agreement (Article 28(4) GDPR) and is liable for it as for its own conduct. (4) Processing outside the EU and EEA only takes place if the requirements of Articles 44 to 49 GDPR are met. The provider’s contracting party is Anthropic Ireland, Limited; the data processing agreement with Anthropic contains the European Commission’s standard contractual clauses (Modules 2 and 3) with addenda for Switzerland and the United Kingdom. According to Anthropic, the onward transfer to Anthropic, PBC in the USA is also safeguarded by standard contractual clauses. (5) We do not use content you process in ProAuditMap to train models. According to their contractual commitments, our sub-processors do not use it to train models either. § 6 Assistance to the customer (1) The provider assists the customer with appropriate measures in responding to requests from data subjects (Articles 12 to 22 GDPR). The customer’s users can view and correct content themselves according to their roles, and administrators can remove users; after the first payment the customer can also export it themselves. Evidence is immutable: users with the corresponding right can withdraw it, but it then remains stored until the retention period expires. The provider deletes individual items of evidence on instruction under § 7(4). Otherwise § 7(2) applies. Requests received by the provider are forwarded to the customer without delay. (2) The provider notifies the customer of a personal data breach without undue delay and at the latest within 48 hours of becoming aware of it, with the information under Article 33(3) GDPR as far as available. It assists the customer with notifications, communications to data subjects, a data protection impact assessment and prior consultation (Articles 32 to 36 GDPR). § 7 Deletion and return (1) After the service ends, the account remains readable for the periods set out in the terms: 30 days after the period of use without a plan expires, 90 days after the contract ends and, in the case of payment default, no more than 90 days from the switch to read-only. Customers that have paid at least once can export their data themselves during this time. (2) Every customer organisation may, until deletion, also during the trial and without any prior payment, request a complete export of its data in text form. The provider delivers it free of charge within 30 days and postpones deletion until then. This constitutes the return under Article 28(3)(g) GDPR; the customer thereby chooses between return and deletion. (3) After the period expires, the provider deletes all customer data, including copies, unless Union or member state law requires storage. On the customer’s instruction in text form, the provider also deletes the data before these periods expire. The data disappear from backups and encrypted copies no later than 40 days after deletion (for encrypted copies of evidence files subject to the review of a mass deletion under paragraph 5); details on evidence files are set out in paragraph 5. If the customer books an archive plan, this is an instruction to keep storing the data for its duration. On request the provider confirms deletion in text form. (4) On the customer’s instruction in text form, the provider also deletes individual items of evidence before the retention period expires, for example if a file was uploaded by mistake or contains more personal data than necessary for the audit purpose. The instruction comes from a person authorised to represent the customer or an administrator of the customer and identifies the evidence unambiguously. The provider deletes the file without delay, and within five working days at the latest, on the server and initiates deletion in the encrypted copy; it confirms the deletion in text form. The customer’s tamper-evident log retains the time, identifier and checksum of the evidence and the category of the reason for deletion (a fixed selection, no free text), so that earlier audit states remain traceable; the content of the file no longer exists afterwards, and the file name is replaced by a neutral placeholder (it remains only on express instruction). If the evidence belongs to a population (source file or row list created from it), the provider deletes both together and replaces the row values of the sample items derived from it and the column headings with placeholders; results, notes and checksums of the selection remain. The checksum of the deleted file remains in the immutable log (it allows no conclusion about the content but proves that the file existed). Exports and archive exports show the evidence as deleted. Replacing the file name changes the checksum of the affected working paper version; a review based on it thereby becomes invalid, and closing requires a new review. The customer assesses the consequences for its audit documentation. (5) The provider stores evidence files on the server and transfers them hourly, encrypted with age, to a copy on the Storage Box (Annex 2). When evidence is deleted, by the deletion run, after the end of the contract or on instruction, the provider removes the file on the server immediately and, as a rule, from the copy at the next hourly sync; if copies of deleted evidence still exist after that, the weekly reconciliation removes them. In the case of a mass deletion (more than 200 deleted files or more than 5% of the stock in one run), the provider only deletes the copies after its own review, to rule out errors; the times are then extended by the review. If a deletion is interrupted after the database entries have been removed, the next deletion run removes any files still present. In the daily snapshots of the Storage Box, the encrypted file then remains, as a rule, for up to ten days. Information on evidence in the database (such as file name, size and checksum) disappears from the backups together with the other database content under paragraph 3 no later than 40 days after deletion. Until then, the provider uses backups, copies and snapshots only for recovery after a failure. After a restore of the database, evidence files that were deleted after the state of the backup remain deleted: deletion markers held locally and in the encrypted copy prevent the file from being restored. The deletion records (category, replacement of the file name) are additionally held in the deletion marker and in a journal of tenant deletions outside the database; the provider applies them again after every restore: individual deletions on instruction are repeated (including replacement of the file name and the derived row values), a restored tenant that had already been deleted is deleted again, and the next deletion run removes the entries of deleted audits again. § 8 Evidence and audits (1) The provider makes available to the customer all information necessary to demonstrate compliance with Article 28 GDPR. (2) The customer or an auditor it appoints who is bound to confidentiality and is not a competitor of the provider may inspect compliance after four weeks’ notice during usual business hours, as a rule once a year and additionally for a specific reason. The inspection must not disrupt operations disproportionately. For data centres and sub-processors the provider may present current audit reports or certificates. § 9 Final provisions In case of conflict between this agreement and the main contract, this agreement prevails on data protection matters. Liability follows Article 82 GDPR and otherwise the main contract. German law applies. Enterprise customers may conclude a separately signed agreement. Annex 1: Technical and organisational measures The Audit trail page additionally describes versioning, the hash chain, the checksums of the evidence, release and retention. - Physical access: operation in data centres of Hetzner Online GmbH in Falkenstein (Vogtland), Germany, and, for encrypted backups and copies of the evidence, in the data centre of Hetzner Finland Oy in Helsinki, Finland, in each case with access control; both locations are within the scope of the ISO/IEC 27001 certification of the data centre operator. - System access: users sign in only with password and a one-time code from an authenticator app; a password can only be reset with a valid one-time code. The administration of the authentication service cannot be reached from the internet, only through an encrypted tunnel. The Storage Box can only be reached via SSH with a key; backups and copies of the evidence use a separate sub-account, distinct from the mirror of the timestamps; the operating scripts refuse to write or delete evidence copies via the main account. - Data access and separation: a separate database schema per customer, roles per user, membership and authorisation checked on every request; another customer’s account is not recognisable as existing from outside. Evidence files are held in a separate directory per customer and carry only a random identifier as their name; the original file name is held only in the database. Only users with the right to read evidence can see evidence and its file names. - Transfer: transmission only encrypted via TLS; security headers and content security policy in the browser; sub-processors receive only the content required for the purpose. Evidence files leave the server only as a copy encrypted with age; the key for decryption is neither on the server nor with the storage provider. Evidence, populations and samples are not transmitted to the language model. - Input control and integrity: immutable versions, log of all changes as a SHA-256 hash chain written by the database itself and checked daily; releases with a frozen basis. In addition, the chain state is given an RFC 3161 timestamp every day outside the database (timestamp services DigiCert and FreeTSA; only a hash value is transmitted, no content) and mirrored to a Storage Box that is only ever appended to. The timestamp proves when the state existed; there is no retention lock in the technical sense. Each item of evidence receives a SHA-256 checksum of the stored file on upload; it is checked again on download and on archive export. Upload, withdrawal, rejection by the malware scan and deletion on instruction are entered in the hash chain, without file content and without file names. - Protection against malware: every uploaded file is scanned with ClamAV before it is stored. The scanner runs in its own container on the same server in an internal network that only the application can reach; files and scan results are not transmitted to third parties. The container only downloads signature updates from the internet over an outgoing connection; there are no incoming connections. When in doubt, the scan rejects: if the scanner cannot be reached or its signatures are older than seven days, the application accepts no files. It rejects infected, encrypted or password-protected and executable files and deletes them immediately. Signatures older than 48 hours trigger an alert. - Availability and resilience: daily encrypted backup of the database with backup versions of the last 29 days on the Storage Box (the age limit applies, not a number; exception: if the most recent version is older than 29 days or lies in the future, nothing is deleted as protection against total loss, and the 40-day period may then be exceeded during a backup outage, in which case the operator is alerted) and, as a rule, up to ten days of snapshots (deleted data removed from the backups no later than 40 days after deletion); hourly encrypted copy of new evidence files to the Storage Box. Recovery point objective (RPO): at most 24 hours. Evidence files are in the copy after one hour at the latest, but after a restore the state of the database governs; for usable evidence the same maximum of 24 hours therefore applies. Files for which the restored database knows no evidence are kept blocked for 30 days, made available on the customer’s instruction and deleted afterwards. Monthly restore test including evidence, monitoring every five minutes, rate limiting, storage quotas per plan and an upload block when storage is running low. - Deletion: retention periods per customer, deletion only after confirmation by the customer, automatic deletion after the period of use without a plan expires, after a trial and after the contract ends, with a log. The deletion run covers evidence files, including withdrawn evidence, and row lists on the server and in the encrypted copy. The provider deletes individual items of evidence on the customer’s instruction with a dedicated, logged operating command (DPA § 7(4)). Residual copies: encrypted evidence files in snapshots as a rule for up to ten days, database content in backups for up to 40 days. A mass deletion is only carried out in the copy after review by the provider (protection against errors); an hourly alert reminds of this, and the release is valid for 24 hours. - Review: daily chain check, comparison of the evidence copy by checksum on every transfer, weekly reconciliation of the copies with the database and the deletion markers, monitoring of the signature age of the malware scan, of storage usage and of the copy backlog, monthly restore test including evidence (without plaintext on the disk), review of the measures after every material change. Annex 2: Sub-processors - Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany: hosting of application, database, authentication service, malware scan and evidence files in the data centre in Falkenstein (Vogtland), Germany; encrypted backups and encrypted copies of the evidence files on a Storage Box in a data centre in Helsinki, Finland (EU). Hetzner does not hold the key to these backups and copies. - Hostinger International Ltd., 61 Lordou Vironos str., 6023 Larnaca, Cyprus: sending the application’s e-mails (invitations, notices) with recipients’ name and e-mail address. - Anthropic Ireland, Limited, Ireland, with Anthropic, PBC, USA: automated generation of drafts and wording suggestions with a language model from the wizard inputs, for partial edits from the affected package content and, for the wording aid, from the text of the relevant field, for example the note or reason in a working paper. Evidence, populations and samples are not transmitted. Processing in the USA on the basis of standard contractual clauses (see § 5(4)); no use for training; according to Anthropic, inputs and outputs are deleted within 30 days, or kept up to two years if flagged for a possible breach of its usage policies. Stripe Payments Europe, Limited processes the customer’s contract and payment data under the provider’s responsibility or its own, not on behalf of the customer, and is therefore not listed here; see the privacy policy.