Data processing agreement Last updated: 6 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, setting up access for persons invited by the customer, sending notifications by e-mail, generating reports as PDF, 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, recording and tracking findings and measures, organising ongoing audits with assignments, due dates and reminders, requesting documents, obtaining statements from audited units, preparing and distributing audit reports, 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), finding data (findings with versions, risk and review, measures with responsible persons and due dates, due date change requests, implementation reports, verifications and risk acceptances with the function of the deciding body), data of audited units (first name, last name, e-mail address and organisational unit of the persons invited by the customer, their sign-in data including the one-time code secret, the acknowledgement of the privacy notice with time and text version, assignments, statements, documents supplied and log data on the retrieval and download of documents and reports), notification data (e-mail address, type of message and time of sending; messages to audited units contain only the name of the customer account, numbers and a link; reminders to the customer’s users additionally state, per task, the type, the audit number, for the user’s own tasks the line or finding number, and the due date, without titles, texts or names of other persons, unless the customer instructs the display of titles under Annex 1), report data (report versions, final reports as PDF with checksum and releases per person), task data (audit lead per audit, assignments of audit programme lines and reviews to individual users with an optional due date, milestones with due date and responsible person, each with time and assigning person and time and reason of the end), reminder data (one entry per task, stage and recipient with time; one note per recipient and day about the digest e-mail), display name and role of users in the selection for assignments, and notification settings of users (unsubscription from the daily digest e-mail with time and channel) and the record of an unsubscription via the link in the e-mail, without the e-mail address, notices of assignments (one entry per new assignment or due date change with recipient, type and identifier of the assignment and time). - Data subjects: the customer’s users; staff and contacts of audited units and service providers; persons whom the customer invites to the portal as an audited unit, even if they are not employed by the customer (for example staff of affiliated companies, service providers or suppliers); persons whose data are contained in evidence, documents supplied, populations, samples, findings, statements or reports (above all staff of the audited unit, and also, for example, its customers, suppliers or business partners); and other persons whom 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. - Audited units: The customer can invite persons as an audited unit to a separate part of the application (portal) that is kept apart from the other areas. The customer alone decides whom it invites, which findings and document requests it assigns, which evidence and final reports it releases to whom and when it ends the access. The customer is the controller for these persons; the provider processes their data only on the customer’s behalf and does not act as controller towards them. The customer ensures that there is a legal basis for the invitation and the processing and that the persons are informed under Articles 13 and 14 GDPR. For this purpose the provider provides a privacy notice as a template, displays it on the customer’s behalf when the portal is first opened, with the contact details stored by the customer, and logs the acknowledgement; the customer is responsible for its content. Audited units do not accept the terms and conditions and are not contracting parties of the provider. - Tasks and reminders: The customer can designate an audit lead per audit and assign audit programme lines, reviews and milestones to individual users with a due date. The application notifies the assigned users by e-mail when the assignment is made, reminds the responsible users of due dates by e-mail and, depending on the customer’s setting, escalates overdue tasks to the audit lead, to the head of audit or to no one; if no audit lead is designated or the audit lead is responsible themselves, the escalation goes to the head of audit. The application offers no analysis per person: no figures per user, no rankings, no exports per person, no list of late completions. The cross-audit overview shows only figures per audit and only if at least two persons are affected, not counting the person calling it up. Whether the use at the customer is subject to co-determination is checked by the customer; the provider provides a description and a draft wording for this. For new and existing customer accounts, reminders are switched off until the customer switches them on. - 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. Instructions also include, in particular, inviting and removing audited units, assigning findings and document requests, releasing evidence and final reports to individual persons and the settings for reminders to audited units; by issuing the invitation, the customer instructs the provider to set up access for the invited person and to send them the notifications described in Annex 1. Instructions also include the settings for tasks and reminders, in particular switching reminders on and off, lead time, timing and recipient of escalations, the display of titles in e-mails and the reply address. The provider implements a user’s unsubscription from the daily digest e-mail even if the customer does not wish it, including for e-mails already prepared but not yet sent; notices of overdue tasks are not affected. (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. Statements of audited units, implementation reports and report versions are immutable; a correction is made by an additional entry. Final reports cannot be deleted individually; they are deleted together with the audit. The customer can remove audited units itself at any time; their assignments and report releases end immediately. The provider deletes individual items of evidence on instruction under § 7(4). Otherwise § 7(2) applies. Requests received by the provider, including those from audited units, are forwarded to the customer without delay and are not answered by the provider itself. (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. The deletion run deletes statements, documents supplied, reports and final reports together with the audit to which they belong. The provider deletes entries in the application outbox, including the e-mail addresses of audited units, no later than 30 days after sending. If the customer removes an audited unit or its access ends and it has no further membership or open invitation, the provider deletes the sign-in data and sessions of the account it created for the invitation; name and e-mail address remain as long as audit documents refer to the person and are then replaced by a pseudonym. Access of audited units ends automatically if an invitation remains without acknowledgement for 14 days or if there has been no assignment or release for 180 days. The application deletes ended assignments, the designation of the audit lead and completed or ended milestones 90 days after the audit is closed or archived, but no later than 12 months after they ended, even if the audit is never closed; it deletes reminder data 180 days after it was created, once the task is completed or no longer applies; at the latest, the deletion run deletes all such data together with the audit. It deletes notices of assignments 180 days after creation, once the e-mail has been sent, and unsent ones after 30 days. When an audit is closed or archived, all assignments and open milestones of that audit end. The application deletes a user’s notification settings when the user is no longer a member of the customer account. The audit archive contains no due dates per person; it contains assignments only as log entries without the assigned person, with hash values for verifying the chain. Entries in the log under Annex 1 are retained under the rules of the log. (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. The same sign-in with password and one-time code applies to audited units; the invitation makes setting up both factors mandatory. The application rejects requests without the second factor. - 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. The audited unit role is exclusive: it cannot be combined with any other role, and an existing membership can never change between audited unit and an internal role; a change is only possible by removal and a new invitation. A new invitation of the same address does not inherit earlier assignments or releases. When an audited unit is removed, all assignments and report releases end in the same transaction. Responsible persons and due dates in an audit are visible only to users with functional access to audits; the team view is visible only to the audit lead of the respective audit, and the names of the responsible persons in it only if the audit lead has switched them on for that audit (default off); the administration role sees no responsible persons and due dates. The selection for assignments shows users who may assign only the display name and role of the functional members, no e-mail addresses. In the log, the administration sees neither the assigned person nor the line nor the line hash for assignments, audit leads and milestones, and does not see other users’ unsubscriptions at all. Only the head of audit can trigger the archive export of an audit. Read access to a user’s own tasks takes place through database functions to which the application passes the person exclusively from the sign-in; automated tests prevent analyses relating to individuals from entering the overview. - 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. Statements and documents supplied by audited units are not transmitted to the language model. Audited units have no wording aid. - 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. Assignments, the designation of the audit lead, milestones, changes to the settings and unsubscriptions are entered in the hash chain with identifiers and codes, without free text; due dates are not included, nor, for milestones, the responsible person, and a reply address only as a hash value. The quality evidence package contains no content of assignment entries and unsubscriptions. - 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. - Portal for audited units: a separate area of the application with its own interfaces that can only be reached with the right of the audited unit role; read access exclusively through defined database functions that only return items with an active assignment of the requesting person. Audited units see no drafts, working papers, reviews or internal notes, no evidence without express release and, instead of the names of the auditors, only “Audit team”. They receive final reports only after release per person. Other items and other customer accounts are not recognisable as existing. Uploads by audited units go through the same malware scan, extension and macro block and count towards the customer’s storage quota. Inputs by audited units are displayed in the interface and in the PDF only as text. Per customer account there are upper limits for the number of audited units and for invitations per day, as well as separate rate limits for write access in the portal. Retrieval and download of documents and final reports, the acknowledgement of the privacy notice, assignments and releases are entered in the hash chain, without texts, file names or addresses. Final reports are generated reproducibly; their checksum is entered in the hash chain. - Notifications: e-mails of the application are sent from a mailbox of the provider, never from mailboxes of the customer. Messages to audited units contain only the name of the customer account, numbers and a link. Reminders to the customer’s users state, per task, the type, the audit number, for the user’s own tasks the line or finding number, the due date and a link; line numbers only if they have the form of an identifier. They contain no texts or names of other persons, and escalations name neither the responsible person nor the line, the finding or a title, not even when the display of titles is switched on. Escalations only go to users who, at the time of sending, are still head of audit or active audit lead of the audit. Content in e-mails only on the customer’s express instruction: if the head of audit, after a notice of the risks, switches on the display of titles, reminders to the customer’s users additionally state the audit title and, for the user’s own tasks, the finding title, shortened to 60 characters and sanitised; titles never go to audited units. Links in e-mails contain no access key; the receiving person sees the content only after signing in with a second factor, and the application checks membership and authorisation again. The application only generates the text at the time of sending, checks again whether the membership is still active and the task still open, and otherwise does not send; the outbox contains only template, reference and recipient, no content. Reminders are sent bundled at most once a day per person and customer account, with at most 25 entries; per customer account an upper limit of 300 recipients per day applies. Notices about newly assigned items and e-mails on assignment are bundled per person and sent at most once an hour; e-mails on assignment per customer account at most up to 20 percent of the daily budget. A platform-wide daily budget applies: digest e-mails are only started up to 70 percent, other notifications up to 80 percent and mandatory e-mails up to 90 percent of the budget; the rest is reserved for e-mails of the authentication service. E-mails held back are generated again later or are dropped if their occasion has ceased to apply. The display name of the sender states the product before the name of the customer account; control and format characters, addresses and links are removed from the name. Logs of the application contain no e-mail addresses, no names of customer accounts and no titles. - Unsubscription and reply address: every daily digest e-mail that does not only contain escalations of overdue tasks carries an unsubscribe link and the headers for one-click unsubscription under RFC 8058. The link carries a purpose-bound value signed with a secret key (HMAC-SHA-256, truncated to 128 bits, with key identifier, valid for 90 days); the value opens no data and only affects the setting of the person concerned in this customer account. Opening the link changes nothing; only submitting the form or the unsubscription by the mail provider takes effect. The keys are held only in the configuration of the application and the background service, have at least 32 bytes and are rotated by prepending a new key; an old key remains valid for 90 days for verification only. A reply address of the customer only takes effect after the head of audit has confirmed it via a link sent to exactly this address; the confirmation value has at least 128 bits of randomness, is stored only as a hash value, is valid for seven days and can be redeemed once, and the confirmation requires signing in as head of audit of the customer account. A changed address must be confirmed again; until then the application uses no reply address. At most three confirmation e-mails per day are sent per customer account. Separate rate limits apply to unsubscription, confirmation of the reply address and writing assignments (unsubscription per IP address, confirmation per user, assignments per user and customer account). Logs contain at most the key identifier and the first eight characters of unsubscribe and confirmation values; the upstream server does not log requests to the unsubscribe path, and the other access logs contain no query parameters. - 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 e-mails of the application and of the authentication service to the customer’s users and to audited units invited by the customer (invitations, setting up access, notices about assigned items, reminders of due dates and escalations of overdue tasks, release of a final report, confirmation of a reply address) with name and e-mail address of the recipients, the name of the customer account and, for reminders to the customer’s users, with type, audit number, line or finding number and due date of the tasks and the number of open and overdue tasks in the subject line; titles only on the customer’s instruction under Annex 1. For sending e-mail, Hostinger uses further sub-processors under its data processing agreement (Annex 3), including MailChannels Corporation and Proofpoint, Inc.; sending logs with recipient address and subject may be stored there according to their terms. Hostinger deletes customer data 30 days after the end of the contract (section 11 of that agreement). - 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, a field of a finding or a section of a report. Evidence, populations, samples, statements and documents supplied by audited units 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.