Data processing 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, reading uploaded spreadsheets to take over audit objects, calculating risk ratings, plan proposals and key figures under fixed, traceable rules, generating board reports as PDF and Excel, 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, risk-based planning of internal audit with an inventory of audit objects, risk rating, annual plan, submission to a board and key figures, reporting to executive management and supervisory bodies, 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), planning data (audit objects with short code, name, description, responsible function, classification, organisational unit, effort estimate and mandatory interval in immutable versions; risk ratings with level per factor, comment and result; overrides of the risk class with reason; the customer’s risk model; annual plans in immutable versions with numbered plan items, capacity as a sum of auditor days without reference to individuals, and reasons; submission to a board, resolution or rejection with the board’s function, date and reference; acknowledgements by members of the leadership view; actual effort per audit in auditor days; board reports as a frozen snapshot with the generated PDF and Excel files; in each case with the acting person and time) and import data (checksum of an uploaded spreadsheet and the rows read from it; the file itself is not stored).
• 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; members of executive management and of supervisory bodies of the customer to whom the customer sets up read-only access to the leadership view, even if they are not employed by it; persons named in audit objects, planning texts or uploaded spreadsheets, for example persons responsible for audited areas or contacts at service providers.
• 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.
• Planning, key figures and leadership view: The customer can maintain an inventory of its audit objects, fill it by hand or by uploading spreadsheets, rate the objects under its own risk model, derive an annual plan from them, submit it to a board and record the board’s resolution. The application retrieves no data from other systems for this and uses no language model; rating and plan proposal follow fixed rules. Key figures, the leadership view and board reports do not evaluate by person and do not name staff of internal audit; Annex 1 sets out the details. The customer decides to whom it sets up the leadership view, whether it switches on the display of effort per audit and to whom it passes on board reports. In free-text fields of the planning, in particular titles of plan items and names of capacity lines, it enters functions instead of names. Whether the use with regard to its employees is subject to co-determination is checked by the customer; the provider provides a description and a draft wording for this.
• 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. Instructions also include setting up and ending access to the leadership view, uploading, adopting, discarding and reversing an import, generating board reports, the plan export, the full export of the planning and the export of the inventory of audit objects, and switching on the display of effort per audit, which the application permits only after a notice on co-determination has been confirmed. The customer instructs the deletion of individual free texts of the planning under § 7(6) 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. 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. Versions of audit objects, risk ratings and annual plans are immutable; a correction is made by a new version, and the earlier one remains readable. The provider deletes individual free texts of the planning that name a person on instruction under § 7(6).

(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. The head of audit can download the data of the planning (audit objects with all versions, risk ratings, risk models, annual plans with all versions, submissions, resolutions and acknowledgements, and board reports) at any time outside the trial, including during the read-only period, as a full export of the planning.

(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. Planning data (audit objects, risk ratings, risk model, annual plans, actual effort, board reports) belong to no individual audit. They are not subject to the retention periods and the deletion run of audits and remain stored until the customer account is deleted. If an audit is deleted, only its identifier, dates and figures remain in the planning so that plan fulfilment and the audit interval of earlier years remain traceable; the application then shows the audit as deleted. The application deletes the rows read from an uploaded spreadsheet 30 days after the decision on the import (adoption, discarding or expiry); an import on which no decision is made within seven days expires. Checksums and figures of the import remain.

(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.

(6) On the customer’s instruction in text form, the provider replaces individual free texts of the planning with a deletion note, for example where a text contains the name of an employee. Covered are the name, description and responsible function of a version of an audit object, comments on risk ratings, reasons for overrides, retirements, plan versions, withdrawals, deviations and the discarding of a plan year, titles of plan items, names of capacity lines, and the function of the board and the reference of a resolution. The instruction comes from a person authorised to represent the customer or from the customer’s head of audit and identifies the text unambiguously. The provider carries out the deletion without delay, at the latest within five working days, with a dedicated, logged operating command and confirms it in text form. The customer’s tamper-proof log retains the time, table, row identifier, affected field, the category of the reason for deletion (a fixed selection, no free text) and the checksum of the deleted text so that earlier plan states remain traceable; the text itself no longer exists afterwards. Board reports and the plan export contain none of these free texts: they name plan items only by item number and short code of the audit object, and reasons only with a note that one exists; the deletion therefore does not need to cover them. The submission PDF “Annual plan” names object names from the latest version of the object and titles of manual items; it is not stored but generated from the current state on every retrieval. Texts of the risk model (names and explanations of factors and levels) are configuration of the customer, are not covered by this deletion and should not contain personal names. The checksum of a plan version includes free texts only through their own checksum and remains valid after a deletion. Plan exports, full exports, submission PDFs and board reports that were generated or downloaded before the deletion are not affected. From the backups, the deleted text disappears within the period under paragraph 3. The provider also records each deletion, without the text, in a journal outside the database, which it keeps for 90 days; after a restore of the database from an older backup it uses the journal to repeat the deletion.

§ 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. Members of the leadership view sign in like all users with password and one-time code; the second factor is mandatory for all roles. They see only key figures, adopted and submitted plan versions, audits with number, status, plan item identifier, quarter of closing, number of findings per risk and the flag whether the audit has been deleted, open findings with number, audit number, risk, organisational unit, age range, status and the flag “overdue”, and board reports; they do not see audits themselves, titles of audits and findings, working papers, evidence, tasks or names of auditors. The leadership view reads exclusively through defined database functions without person fields. Members of the leadership view receive no reminders and no escalations. An access to the leadership view cannot be combined with the audited unit role. The administration role sees audit objects, the annual plan, the submission PDF “Annual plan” and the settings of the planning (and thus whether the display of effort per audit is switched on) read-only, and no key figures.
• No evaluation per person: key figures, the leadership view and board reports do not aggregate data by person or filter by person; automated tests reject any such query. Plan items have no responsible person; capacity is a sum without reference to individuals. Key figures on effort, special audits and lead times show a field only from three audits; smaller fields are combined or hidden, a combination itself appears only from three audits, and totals and shares are calculated only over displayed fields; the effort key figure always hides plan items without a quarter. If the customer has fewer than three memberships with the role auditor or quality assurance, where a membership with the role head of audit never counts and every existing membership counts, including that of an invited person who has not yet signed in (there is no blocked status), the leadership view and the board report do not show these key figures or the plan fulfilment by auditor days. The leadership view and the board report name audits only by number, plan items only by item number and short code of the audit object, closings only as a quarter and the age of open findings only in ranges. The application shows the actual effort of an individual audit only in the entry form of the head of audit (right to edit the planning, no separate right), in the full export of the planning and, if the customer switches it on after confirming a notice on co-determination, in a key figure for the head of audit only; switching it on and off is recorded in the log. Auditors and quality assurance also see it in sums: planned and actual effort per quarter and risk class and the actual effort of special audits, in each case only from three audits per field.
• 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. Audit objects, risk ratings, planning data, key figures and board reports are not transmitted to the language model. Board reports and the plan export contain no names of internal audit staff, no titles of audits, findings or plan items, no names of audit objects and no reasons; plan items appear with item number and short code of the audit object, reasons only as a note that one exists. The board report names neither board nor resolution reference; as free texts it contains the names of the organisational units for open high-risk findings and the names of the factors of the risk model. The submission PDF “Annual plan”, which auditors, quality assurance, head of audit and administration can retrieve, by contrast names object names and titles of manual items; it is generated from the current state on every retrieval. Generating and downloading a board report are recorded in the log with a checksum; what happens to downloaded reports and exports is the customer’s responsibility.
• 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. Risk ratings and key figures are calculated by the database itself under fixed rules with whole numbers, the plan proposal by the application under fixed rules without randomness, also with whole numbers; no external service is involved; versions are immutable and their checksums are in the hash chain. Ratings, overrides, plan versions, submission, resolution, acknowledgement, changes to the settings, imports and board reports are in the hash chain with identifiers, codes, figures and checksums, without free text: reasons only as a checksum bound to table, field and row, comments on ratings not at all, and the actual effort per audit only as a checksum without the numeric value. Free texts enter the checksum of a plan version only through their own row-bound checksum. The plan export contains no free texts and a verification script with which the customer can recalculate plan versions and the log without the application.
• 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.
• Import from files: audit objects can be taken over only from spreadsheets that a user uploads; there are no connections to other systems and no credentials for them. Each file is limited to 5 MiB and 5,000 rows. Every file is scanned with the same virus scanner as evidence before it is read, and the scan fails closed: if the scanner cannot be reached, does not respond in time or its signatures are too old, the application does not accept the file. It rejects infected files and Office files with macros: macros in older Office files are detected by the virus scanner, macros in Excel files (xlsx) by the check for impermissible components that every Excel file passes before it is read; reading runs in a separate, limited process. The uploaded file is held temporarily only for the duration of reading and deleted afterwards, also on abort; only its checksum remains permanently. A daily run deletes the rows read 30 days after the decision on the import; deletion is permitted only to the owner role of the database with its own marker. Adopting an import retires no audit objects and reactivates none; if an import is reversed, the application retires the objects newly created by it. Logs of the application contain no content for imports; they name the tenant identifier, duration, figures and error codes. Exports neutralise formula characters in cells.
• 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. Board reports are held as part of the database and are therefore included in backup, restore and deletion of the customer account; at most ten board reports can be generated per day for each customer account.
• 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. The application deletes planning data and board reports together with the customer account; the deletion run of audits does not cover them (DPA § 7(3)). Rows read from an import are deleted 30 days after the decision on the import. The provider replaces individual free texts of the planning, on the customer’s instruction, with a deletion note using a dedicated, logged operating command (DPA § 7(6)); the command works only with the owner role of the database and only on a fixed list of permitted fields, and logs and the deletion journal do not contain the deleted text; the journal is held outside the database, kept for 90 days and serves only to repeat deletions after a restore. Logs of the overall planning export contain no content; they state the tenant identifier, figures and error codes.
• 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.