Agreement on the processing of personal data on behalf of the controller

Data processing agreement (Auftragsverarbeitungsvertrag, AVV) pursuant to Art. 28 (3) DSGVO (GDPR) Annex to the Allgemeine Geschäftsbedingungen (General Terms and Conditions) of Zirko

This is a courtesy translation. The German version of this agreement is the legally binding one; in case of any discrepancy between the German and the English version, the German version prevails.

Preamble

The Customer (hereinafter the "Controller" — Verantwortlicher) uses the Zirko software of the Provider Oliver Wagener (hereinafter the "Processor" — Auftragsverarbeiter). In doing so, the Processor processes personal data on behalf of the Controller.

This agreement sets out in detail the obligations arising from Art. 28 GDPR. It applies in addition to the main contract (the Allgemeine Geschäftsbedingungen / General Terms and Conditions) and takes precedence over it in matters of data protection.

The Controller remains responsible for the lawfulness of the processing (Art. 24 GDPR). This concerns in particular the question of the basis on which it enters the data of its customers and of its employees (Beschäftigte) into the software.

§ 1 · Subject matter, nature and purpose of the processing

The subject matter is the provision and operation of the Zirko software as software-as-a-service. The nature and purpose of the processing follow from the range of functions: customer and master data management, project management, scheduling and time tracking, the creation, output, dispatch and archiving of accounting documents (Belege) as well as the management of incoming documents.

In addition, there are three processing operations outside this basic operation: the automated messages (§ 7), sending via the Controller's mailbox (§ 7a) and the feedback sent from within the application (§ 8).

Details are set out in Annex 1.

§ 2 · Duration

The processing begins when the contract begins under the main contract and ends when the main contract ends. § 13 (deletion and return) applies beyond that.

§ 3 · Binding effect of instructions

(Art. 28 (3) (a) GDPR)

1. The Processor processes personal data exclusively on documented instruction from the Controller, including with regard to transfers to third countries — unless it is required to do so by Union law or the law of a Member State. In that case, the Processor informs the Controller of the legal requirement before processing, unless that law prohibits this on important grounds of public interest.
2. The Controller's use of the software's functions constitutes an instruction. This expressly includes the switches with which the Controller switches individual processing operations on and off (§ 7 (4)). Instructions going beyond the range of functions require text form (Textform within the meaning of § 126b BGB — a legible declaration on a durable medium naming the declaring person; an email suffices, no signature is required) sent to datenschutz@zirko.io.
3. Where an instruction would be unlawful. If the Processor is of the opinion that an instruction infringes the GDPR or other data protection provisions of the Union or of the Member States, it informs the Controller without undue delay (unverzüglich — without culpable hesitation, § 121 (1) BGB) (Art. 28 (3) sentence 3 GDPR). It is entitled to suspend execution until the instruction is confirmed or amended. If the Controller confirms an instruction that the Processor considers manifestly unlawful, the Processor may refuse execution definitively; this is not a breach of contract and gives rise to no obligation to pay damages. If the parties do not reach agreement, either of them may terminate the main contract for good cause (außerordentliche Kündigung aus wichtigem Grund, cf. § 314 BGB).
4. Instructions are to be followed only to the extent that they can be carried out technically. In particular, the Processor cannot alter or individually delete an issued invoice; this follows from the legally required unchangeability governed by § 6.
5. Instructions the Processor does not follow. Paragraphs 3 and 4 cover in particular:

• the alteration or individual deletion of an issued document (§ 6);
• the deactivation of the separation between businesses (Betriebe — the trade businesses using the software) or the release of one business's data to another;
• the analysis of the Controller's data for purposes of the Processor that are not provided for in this agreement;
• the transmission to a service provider that is not listed in Annex 2; excepted is the handover to the provider of a mailbox that the Controller has connected itself (§ 7a).

§ 4 · Confidentiality of the persons authorized to access the data

(Art. 28 (3) (b) GDPR)

1. As at the date of this agreement, the Processor is run by a single person. Access to the Controller's data is therefore held by exactly one natural person: Oliver Wagener. This person is at the same time owner, developer and support.
2. This person's duty of confidentiality follows directly from this agreement and from Art. 28 (3) (b) GDPR; it continues to apply beyond the end of the activity.
3. As soon as further persons join — employees, freelancers, interns — the Processor commits them in writing to confidentiality and to the restrictions of this agreement before their first access. It keeps a list of these commitments and presents it to the Controller on request (§ 14).
4. Access for troubleshooting. Access to the Controller's content data for the purpose of investigating a reported error is a processing operation and therefore requires an instruction. The Processor accesses such data only if the Controller requests or approves it in the individual case. It records every such access with occasion, time, scope and accessing person, restricts it to the purpose of troubleshooting and ends it when the troubleshooting is concluded. It presents the record to the Controller on request in text form without undue delay (§ 14).

§ 5 · Technical and organizational measures

(Art. 28 (3) (c) in conjunction with Art. 32 GDPR)

1. The Processor takes the measures required by Art. 32 GDPR. The current state is described in Annex 3.
2. The measures are subject to technical progress. The Processor may change them as long as the level of protection is not reduced.
3. Alongside the measures taken, Annex 3 also describes their limits and the precautions with which the Processor compensates for them.

§ 6 · Unchangeability of issued documents

1. The Processor ensures that issued documents can no longer be altered and cannot be deleted after they have been issued. This is a requirement of tax law (GoBD — the German principles for the proper keeping and retention of books, records and documents in electronic form and for data access, an administrative instruction of the Federal Ministry of Finance; §§ 145–147 AO (Abgabenordnung — German Fiscal Code)) and at the same time a technical property of the software.
2. An issued document is corrected by means of a Storno — a second document that neutralizes the first — never by altering the first.
3. Relationship to Art. 17 GDPR: If a data subject requests the erasure of data contained in a document subject to statutory retention, this does not, pursuant to Art. 17 (3) (b) GDPR, lead to erasure but to the restriction of processing under Art. 18 (1) (b). The Processor marks the document accordingly and restricts its processing on the Controller's instruction in text form, without undue delay and free of charge.
4. The statutory retention obligation applies to the Controller, not to the Processor; how long it runs is determined solely by the law of the Controller's own country (§ 13 (4)). The Processor provides unchangeability and export during the term of the contract; it is not an archiving service provider and owes no retention beyond the end of the contract. The Controller arranges the export in good time; details are governed by § 13.

§ 7 · Automated messages

(only those automations that the Controller switches on — by default none is switched on)

1. What the function does. The software checks daily, according to fixed rules, whether there is an occasion for a message, and then sends it without further action. The rules are set by the Controller: it switches each automation on individually, sets the deadlines and lead times it works to and, where the message reaches a third party, maintains its text template.
2. Three groups of recipients. For each automation, the software records which group it writes to and shows this to the Controller at the automation itself. There is no fourth group; an automation that sends nothing is described in paragraph 6.

• the Controller, to its own business address — a reminder to itself; no third party learns of it;
• an employee of the Controller, to their own address, in the matter that concerns them. The Processor does not send a message about an employee to that employee's superiors — that would be automated performance monitoring;
• a customer of the Controller — follow-up messages, appointment reminders, notices about an expiring link and requests to provide documents via a time-limited link. Only here does a message leave the business, and only here is there a text template.

1. The upload link. If an automation asks the Controller's customer to provide documents, that customer receives a time-limited link restricted to a single matter. Whatever they upload through it belongs to the Controller's data holdings and is subject to this agreement like any other file placed there by the Controller. The Processor does not review it and does not analyze it.
2. The switch is an instruction, not consent. It is operated by the Controller in its role under Art. 24 GDPR, not by a data subject. It does not constitute consent within the meaning of Art. 6 (1) (a) GDPR.
3. Fixed rules, not a model. Neither the decision whether a message goes out nor its wording is produced by artificial intelligence. No language, text or speech recognition model is used for this purpose and nothing is transmitted to a provider of such a model.
4. No decisions about persons. An automation issues no document, changes no document, approves nothing and triggers no payment. It assesses no personal characteristics, builds no profile and carries out no creditworthiness or behavioral assessment. What it does is: send a message and record the dispatch. Whether, when and with what wording this happens has been decided in advance by the Controller, and it can switch off any automation at any time with immediate effect.

There is one single automation that sends nothing at all — instead, it assigns. For each project status, the Controller can specify by name which of its employees are assigned to the project when that status occurs. The automation then enters exactly those persons and sends no message. It selects no one, checks no one and removes no one; it carries out a list that the Controller has written beforehand. Without that list it does nothing. It, too, is switched off by default.

1. Verifiable before and after it runs. For the automations, the software shows a dry run ("what would the next run do?") and a log of the runs carried out, with time, occasion and recipient; the log goes back 30 days and can be viewed by the Controller. It is at the same time the Controller's evidence under Art. 5 (2) GDPR of what has gone out in its name.
2. Who answers for the content. The Controller is responsible for the occasion, the group of recipients and the wording; the Processor does not check the text templates for their content. In particular, the Controller ensures that approaching its own customers is permissible under the law applicable at the recipient's seat (Sitz) and that those customers have been informed about the processing of their data (Art. 13, 14 GDPR). The Processor does not know the relationship between the two and therefore cannot assess it on the Controller's behalf.
3. Objection by a data subject. An objection under Art. 21 GDPR to receiving such messages is to be addressed to the Controller; if it reaches the Processor, § 9 (4) applies. The Controller can switch off the automation concerned or mark the individual recipient accordingly in its data.
4. The dispatch service provider is the same one used for all other emails sent by the software and is named in Annex 2. It receives the recipient address and the message content — nothing more, and nothing different from the dispatch of documents. The automation does not give rise to any additional sub-processor. Where the Controller has connected its own mailbox, the messages to the Controller itself and to its customers go out via that mailbox instead (§ 7a); messages to its employees always go via the dispatch service provider under Annex 2.
5. Payment reminders are not an automation within the meaning of this section. They form part of the basic operation under § 1 and follow the Controller's payment reminder settings. Paragraphs 5 to 8 apply to the payment reminder run accordingly.

§ 7a · Sending via the Controller's mailbox

(only if the Controller connects a mailbox — none is connected by default)

1. What the function does. The Controller can connect an email mailbox of its own to the software. Documents, payment reminders and the messages under § 7 to the Controller itself and to its customers then go out from that mailbox's address. Messages to the Controller's employees always go via the dispatch service provider under Annex 2, never via its mailbox. Google and Microsoft themselves file a copy of the sent message in the "Sent" folder; with the other providers the Processor files it there under paragraph 2. Only a user with the Admin role can connect, check and disconnect a mailbox.
2. Sending only. The Processor reads no message from the mailbox. It requests from the provider only what sending requires: with Google, the permission to send messages and the account's address; with Microsoft, the permission to send messages, the account's address and the use of this permission without signing in again. With all other providers it signs in to the outgoing mail server with the user name and password given by the Controller. If the Controller has also entered the IMAP server, the Processor then files the sent message in the "Sent" folder via IMAP; for this it reads the list of folder names, but no message. If filing fails, the message remains sent; no copy is then created in "Sent".
3. Credentials. The Processor stores refresh tokens and passwords in encrypted form (Annex 3, section 1). It uses them solely for sending under paragraph 1 and for checking the connection. They are not displayed in the software and are handed over to no one; § 4 (4) applies accordingly.
4. The mailbox provider is not a sub-processor. The Controller chooses the provider itself and has its own contractual relationship with it. Handing a message over to this provider is a transmission on the Controller's instruction (§ 3 (2)) to the Controller's own service provider; § 11 and Annex 2 do not apply to it. Whether a data processing agreement exists with this provider and on what basis it transfers data to third countries is a matter for the Controller in its relationship with the provider.
5. Obligations of the Controller. It connects only a mailbox it is entitled to use — a personal mailbox of an employee only with that employee's knowledge — and ensures that its contract with its provider permits sending via a connected application. It bears in mind that the copy of every message sent via the mailbox is accessible to everyone who reads the mailbox.
6. Fallback route. Even where a mailbox is connected, the Processor sends a message via the dispatch service provider under Annex 2 if, with its attachments, it exceeds the size the Processor permits for that provider's mailbox — when documents are dispatched, the software shows this before sending — or if it is certain that the message has not arrived at the mailbox provider. When documents are dispatched, this route is noted on the document. Where it is unclear whether the message has arrived, the Processor does not send it again.
7. No delivery report. For messages sent via the Controller's mailbox the Processor receives no delivery status; the dispatch is noted.
8. Disconnecting. When the Controller disconnects the mailbox, the Processor deletes the credentials immediately. With Google it additionally revokes the permission with the provider. With Microsoft, an individual permission cannot be revoked from outside without ending every sign-in of the person; the account holder removes the application there in their own account. When the holdings are deleted under § 13, the credentials are deleted as well.

§ 8 · Feedback sent from within the application, including screenshots and screen recordings

1. What the function does. Signed-in users of the Controller can send feedback to the Processor from within the application. The following is recorded automatically in the process: business, role, page visited, version of the application and time. The content of the page is not recorded automatically.
2. Screenshot and screen recording are voluntary and switched off by default. The user decides whether to attach a recording, sees it before sending and can discard it. The current browser tab is pre-selected, not the entire screen.
3. Content of a recording. A screenshot of this application shows data of the Controller's customers: names, addresses, amounts, possibly bank details. A screen recording shows them in motion. Anyone sending such a recording transmits personal data to the Processor.
4. Purpose limitation. The Processor uses feedback exclusively to investigate and remedy the reported error in the software used by the Controller. There is no disclosure to third parties; there is no use for advertising.
5. Retention. Attachments (image, video) and free text are deleted after 90 days. The period is set when the feedback is received. The Processor owes the deletion once the period has expired; it evidences it to the Controller on request in text form without undue delay.
6. End of the investigation. Once the investigation of the reported error is complete, the Processor deletes the recording without waiting for the period under paragraph 5 to expire. All that remains is the Processor's description of the error, not the recording. If a user deletes their user account, the feedback is separated from their person; this separates it from the person of the reporter and not from the names of third parties appearing in the free text or on a recording — for those, the periods under paragraph 5 apply.
7. Classification. This processing is processing on behalf of the controller: under paragraph 4, its purpose does not go beyond the task entrusted to the Processor of keeping the software operational for the Controller; the Processor pursues no purpose of its own with it (Art. 28 (10) GDPR). It is triggered by the Controller's user in the individual case, and that is an instruction within the meaning of § 3 (2). All obligations of this agreement apply to it.
8. Switching it off for a business. At the Controller's request in text form, the Processor switches off the feedback function for that Controller's business.

§ 9 · Assistance with the rights of data subjects

(Art. 28 (3) (e) GDPR)

1. The Processor assists the Controller by appropriate technical and organizational measures in fulfilling its obligation to respond to requests from data subjects (Art. 12 to 23 GDPR).
2. What the Controller can do itself without any action by the Processor. This agreement lists these individually:

1. What the Controller needs the Processor for:

1. Requests from data subjects that reach the Processor directly are not answered by it. It forwards them to the Controller without undue delay and informs the data subject that it is not the controller.
2. The assistance under paragraph 3 is provided free of charge, to the extent that it is not occasioned by fault on the part of the Controller and does not obviously exceed the customary scope.

§ 10 · Assistance with security, notification obligations and impact assessment

(Art. 28 (3) (f) GDPR)

1. The Processor assists the Controller in complying with the obligations under Art. 32 to 36 GDPR, taking into account the nature of the processing and the information available to it.
2. The Processor notifies the Controller of personal data breaches without undue delay after becoming aware of them (Art. 33 (2) GDPR), at the latest within 24 hours, in text form to the address stored by the Controller. The notification contains, to the extent available: the nature of the breach, its cause, the categories concerned and the approximate number of data subjects and records concerned, the likely consequences as well as the countermeasures taken and proposed. Missing information is supplied subsequently without undue delay; the initial notification does not wait for completeness. The notification to the supervisory authority and the communication to data subjects are made by the Controller; the Processor supplies it with the information available to it for that purpose — in good time for the Controller to be able to meet the time limit applicable to it.
3. Controllers established in Japan. There, the notification to the supervisory authority and the communication to the data subjects are incumbent on the Processor itself (Art. 26 (1) and (2) APPI) — Japanese law does not recognize the division of roles of Art. 33 GDPR. Both obligations cease to apply to it as soon as it has notified the Controller (Art. 26 (1) second half-sentence APPI). The Processor undertakes to take this route: its notification under paragraph 2 is at the same time the notification within the meaning of that provision. Without it, both sides would have to report the same incident separately. For the Controller's report to the Commission, its own time limits then apply — without undue delay (速報) and 30 days, in the case of unauthorized access 60 days (規則第8条 (2)), in each case running from when it becomes aware.
4. Data protection impact assessment (Art. 35) and prior consultation (Art. 36). The Processor makes available to the Controller the information the Controller needs for this: this agreement including its annexes, the description of the technical and organizational measures (Annex 3), the list of sub-processors (Annex 2) as well as the description of the data flows. It expressly points out that the time tracking and the scheduling of employees may, in many businesses, trigger an impact assessment and the involvement of an employee representative body (in Germany typically a works council, Betriebsrat); the Processor does not prepare it for the Controller, but supplies the building blocks for it.
5. The Processor notifies the Controller without undue delay if a supervisory authority takes measures against it that concern the Controller's data.

§ 11 · Sub-processors

(Art. 28 (2) and (3) (d) GDPR)

1. The Controller grants the Processor general written authorization to engage further processors (Art. 28 (2) sentence 2 GDPR).
2. The sub-processors engaged as at the date of this agreement are listed in Annex 2 and are thereby authorized.
3. The Processor contractually binds every sub-processor to a level of protection corresponding to this agreement and is liable for the sub-processor's conduct as for its own.
4. The Processor notifies intended changes — addition or replacement — in text form at least 30 days in advance. The Controller may object within 14 days of receipt for important reasons relating to data protection. If it objects and the change cannot be avoided, either party is entitled to terminate the main contract by extraordinary termination for good cause with effect from the date the change takes effect.
5. Ancillary services such as telecommunications, postal services, maintenance of end devices or audits by professional advisers bound by professional secrecy (Berufsträger — auditors, tax advisers, lawyers) do not constitute processing by a sub-processor. Nor is the provider of a mailbox that the Controller has connected under § 7a a sub-processor.

§ 12 · Place of processing and transfers to third countries

1. The processing takes place in the European Union, unless Annex 2 states otherwise for individual services.
2. The Controller's content data (Nutzdaten) — database and files — is processed in the European Union (Frankfurt region); the server functions that access it also run there.
3. Transfers to third countries take place only to the extent provided for in Annex 2, and only on the basis of an adequacy decision (Art. 45 GDPR) or of appropriate safeguards (Art. 46 GDPR), in particular the standard contractual clauses of the European Commission.
4. Controllers established in Japan. Paragraphs 1 to 3 describe the export out of the European Union. For the Japanese Controller, the opposite direction is the relevant one, and it is unproblematic: Germany is one of the countries that the Personal Information Protection Commission has determined to be equivalent (個人情報保護委員会 告示第1号). Its handing over of the data to the Processor is therefore not a transfer to a third party abroad requiring consent under Art. 28 APPI; Art. 27 APPI applies, and the engagement falls there under the exception of Art. 27 (5) no. 1. Its obligation to supervise the party it has engaged (Art. 25 APPI) remains in place — this agreement and Annex 3 are the basis on which it does so.

§ 13 · Deletion and return after the end of the contract

(Art. 28 (3) (g) GDPR)

1. After the end of the main contract, the Processor deletes the personal data or returns it, at the Controller's choice.
2. The Controller can export its data itself throughout the entire term of the contract. After the end of the contract, a period of 30 days is available to it during which access is read-only and export remains possible. At the Controller's request in text form, which must be received before that period expires, the Processor extends it once by 30 days. The extension serves solely the Controller's export.
3. After that period expires, the data is deleted. The Controller may bring the deletion forward at any time. Backup copies: Insofar as deletion from backup copies is possible only with disproportionate effort, the Processor instead blocks the data against any further processing; it is deleted definitively when the retention period of the backup copy concerned expires, at the latest after 30 days.

Statutory retention obligation and the end of the contract

1. The statutory retention obligation applies to the Controller — not to the Processor. How long it runs is determined solely by the law of the Controller's own country. It is an obligation owed by the business itself to its own tax authorities. It does not oblige the Processor to retain the Controller's data, and still less does it entitle it to do so.
2. The Processor therefore retains no data of the Controller for the purpose of fulfilling the Controller's statutory retention obligations. When the contract ends, the purpose for which the data was collected ceases to exist — the operation of the software (Art. 5 (1) (e) GDPR).
3. The Controller's duty. It must export its documents subject to statutory retention before the period under paragraph 2 expires and retain them itself for as long as the law of its own country requires. After that period, the Processor no longer has them at its disposal.
4. Relationship to § 6. § 6 applies during the term of the contract: as long as a document is held by the Processor, it is unchangeable and cannot be deleted individually. § 13 governs what happens after the contract: the entire holdings are then deleted; an individual document is not removed from them.
5. Statutory retention obligations of the Processor for its own bookkeeping — the invoices for the Zirko subscription — remain unaffected; they do not concern the Controller's content.
6. The Processor confirms the deletion in text form on request.
7. No right of retention. A right of retention of the Processor (Zurückbehaltungsrecht pursuant to § 273 BGB) over the Controller's personal data and over the associated data media is excluded, including in the case of outstanding claims under the main contract. This corresponds to the provision of the main contract under which read access to the documents and their export are also preserved during a suspension for non-payment (AGB § 8 (5)).

§ 14 · Audit and evidence rights

(Art. 28 (3) (h) GDPR)

1. The Processor makes available to the Controller all information necessary to demonstrate compliance with Art. 28 GDPR and allows for audits.
2. Evidence provided by the Processor. It maintains no data centers of its own and no premises in which the Controller's data would be held; that data is held with the providers named in Annex 2. The following is provided:

1. On-site audits are permissible with at least four weeks' prior notice, during usual business hours and without disrupting operations, provided that the evidence under paragraph 2 is not sufficient and the Controller gives reasons. They do not extend to the premises of the sub-processors insofar as the Processor has no right of entry there; in that respect it obtains the available evidence for the Controller.
2. The auditing person is bound to confidentiality and may not be a competitor of the Processor.
3. The evidence under paragraph 2 is provided free of charge.

§ 15 · Final provisions

1. Amendments to this agreement require text form.
2. In the event of conflicts between this agreement and the main contract, this agreement takes precedence in matters of data protection.
3. Should a provision be invalid, the validity of the remaining provisions remains unaffected.
4. The law of the Federal Republic of Germany applies, to the exclusion of the UN-Kaufrecht (the United Nations Convention on Contracts for the International Sale of Goods, CISG). Mandatory provisions (provisions from which no derogation is permitted by agreement) of the law of the Controller's place of establishment (Sitz) remain unaffected; individual countries are deliberately not listed here, because such a list would never be complete and the Controller would otherwise draw an inference to the contrary (Umkehrschluss).
5. Also unaffected is law that applies to the Processor itself by operation of law and is therefore not open to choice at all. For Controllers established in Japan, this is in particular the 個人情報保護法 (APPI), which under its Art. 171 also applies to providers outside Japan that process data of persons in Japan.

Annex 1 · Subject matter of the processing

Categories of data subjects

• Employees of the Controller (office and field)
• Customers of the Controller as well as their contact persons and invoice recipients — in the case of private customers, natural persons. This also includes the recipients of automated messages and the persons who provide documents via an upload link (§ 7)
• Suppliers of the Controller and their employees
• Third parties who are depicted in site photos or named in project messages — as well as third parties who appear in a file provided via the upload link
• Holders of a connected mailbox (§ 7a) — the Controller itself or the person whose mailbox it connects

Categories of personal data

Processing activities

Collection · recording · organization · storage · adaptation · retrieval · consultation · use · disclosure by transmission (dispatch of documents on instruction; dispatch of automated messages to the Controller, its employees and its customers under § 7, where the automation concerned is switched on — in each case via the dispatch service provider under Annex 2 or via the Controller's mailbox under § 7a) · alignment · restriction · erasure.

Processing operations that do not take place:

• no profiling;
• no assessment of personal characteristics and no automated decision about persons. The automations under § 7 follow rules that the Controller sets itself and can switch off at any time; they send messages and take no decision — no creditworthiness or behavioral assessment, no suspension, no formation of a contract, no payment. The one automation that, instead of sending, assigns employees to a project selects no one: it enters the list that the Controller has stored by name for each project status (§ 7 (6)). The Processor takes no decision within the meaning of Art. 22 GDPR and will not introduce one without amending this agreement;
• no use of artificial intelligence. No third party's language, text or speech recognition model is integrated — neither for reading out incoming documents nor for reports, quotes or messages. The character recognition (OCR) of incoming invoices runs entirely in the user's browser;
• no use of the data for the Processor's own purposes.

Annex 2 · Sub-processors and recipients

Services used

Envisaged, not currently in use

No data flows to these services. Before any of them is put into operation, a data processing agreement will first be concluded in each case and this list will be supplemented.

Expressly not

Authorized within the meaning of § 11 (2) are the services listed above as being used. Any further service will be used only after a notification pursuant to § 11 (4).

Annex 3 · Technical and organizational measures (Art. 32 GDPR)

1 · Confidentiality

Physical access control (Zutrittskontrolle). Only the data centers of the providers used are relied upon (Annex 2). The Processor operates no servers of its own.

System access control (Zugangskontrolle). Sign-in via a managed authentication service with hashed passwords; credentials for the services used are held exclusively in server environments and are protected against accidental publication by an automatic check on every change.

Data access control and tenant separation (Zugriffskontrolle und Mandantentrennung).

• Every table in the database is protected by row-level security rules; each rule binds to a business or to a user.
• This property is checked automatically: a check runs on every change before publication and aborts if a table or a rule steps out of line.
• References between tables are composite (business + record), so that a reference to another business fails structurally and not only at a check in the application code.
• Five roles with graduated rights; permissions are decided on the server. Pay-related data is restricted to office roles.
• Database functions with elevated rights check membership themselves and run with a fixed search path.

Separation control (Trennungskontrolle). Tenant separation as described above; file stores are not public, carry the business in the path and have their own access rules. Test and production environments are separate; automated tests abort if they point at the production database.

Credentials for the Controller's mailboxes (§ 7a). Refresh tokens and passwords are stored encrypted with AES-256-GCM. The key is held exclusively in the server environment, not in the database. Every encrypted value is bound to the business and the record and cannot be opened in another record; the key can be rotated without interruption. The table can be read and written only by the server functions — neither a browser nor a signed-in user has access to it, not even to the fields without a secret. Connecting, checking and disconnecting are open only to the Admin role; business and role are taken from the session. Signing in with Google and Microsoft uses PKCE and a state value held in an encrypted cookie readable only by the server and valid for ten minutes.

2 · Integrity

Transfer control (Weitergabekontrolle). Transmission exclusively via TLS. Third-party services are addressed on the server side; their access keys never reach the browser. The character recognition of incoming documents runs entirely on the user's device; the program components required for it come from our own server, not from a third-party network. Error reports to the service provider contain an exhaustive allow list of technical fields without content data (Annex 2).

Connections to mailboxes (§ 7a). Outgoing mail and IMAP servers are addressed exclusively in encrypted form, with at least TLS 1.2 and a check of the certificate against the server name; without encryption the software does not sign in. Before every connection the server name is resolved, and only publicly reachable addresses are contacted; the permitted ports are limited. A message for which it is unclear whether it has arrived at the provider is not sent again.

A guard before every automated message (§ 7). Whether an automation is switched on and its occasion has arisen is decided by the server from settings, data and log — not by the user interface and not by the request. The daily run can be reached without signing in and therefore carries a secret from the environment which is compared in constant time; if it is missing, the run does nothing instead of sending when in doubt. Exactly one value comes from the request: whether it is a dry run. The check is designed to fail closed: if a query fails, no dispatch takes place.

Security headers (Sicherheitsköpfe). Every response carries a Content-Security-Policy as well as HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options and Cross-Origin-Opener-Policy.

Input control (Eingabekontrolle). Who created a record is captured bound to the session and cannot be set freely. Documents carry dispatch, payment and dunning notes with a timestamp; the timestamp of the output is set by the database, not by the caller. For feedback (§ 8), a trigger sets business, role, time and deletion periods from the session, and the insert right is restricted to individual columns; bypassing the user interface cannot set these fields.

Unchangeability. Issued documents are locked by database triggers: only dispatch, payment and dunning notes, the Storno and two data protection fields are permitted. The lock works on the allow-list principle — whatever is not expressly permitted is locked, including fields added in the future. Numbered documents are protected against deletion, and this at database level, so that the lock also applies to administrative access. The sent version of a document dispatched as a draft is filed unchangeably before sending; no session can alter or delete it, and it is removed only together with the business's holdings (§ 13).

Correctness of the output. A generated document PDF is checked for its content before it is stored: if the document number is not in it, the operation counts as failed and nothing is stored.

Uploads. Server-side checking of type and size. Image formats that can execute program code (SVG) are not accepted.

3 · Availability and resilience

Backups within the scope of the services of the providers used (Annex 2). Recoverability via their restore functions. Every schema change is versioned and repeatable.

4 · Procedures for review and evaluation

Automated checks on every change: tenant separation, server/client boundary, credentials, migrations, language keys, column names, VAT rates, licenses. Extensive automated test suites run on every version. Before it is reported as finished, every module goes through a fixed review chain consisting of code review, security review, testing, remediation and re-review, as well as end-to-end test runs against the running application.

5 · Data minimization in the product

Address suggestions store no provider identifiers, raw responses or query times; caching takes place only in the browser for the duration of the session. Error messages contain no document data, but machine-readable codes. In the case of the automated messages under § 7, only what the message needs goes out: the recipient address, the wording from the Controller's template and the reference the message concerns. The log of a run stays with the business concerned; the run's response to the scheduler carries only counts, no recipients and no document numbers.

Sending only with the Controller's mailbox (§ 7a). The software requests from the provider only the permission to send and reads no message; with IMAP it reads only the list of folder names in order to find the "Sent" folder. It stores a failure on the connected mailbox only as a code, without the free text of the third-party server.

No location data of employees. The software does not collect the location of a device — neither in time tracking nor otherwise. It is also technically prevented from doing so: the Permissions-Policy of every response (section 2) blocks the browser's location function (geolocation=()), and the table of time entries has no coordinate column. The "Einsatzort" on a time entry is the planned site address from the assignment or project planning. The Processor does not evaluate the behavior or the performance of individual employees.

6 · Limits of the measures

The Processor names the limits of the above measures and the precautions with which it compensates for them.

• An automatic deletion run exists for the archive of employees who have left; it runs daily and logs every pass. For documents, for the quarantine of incoming files, for generated export archives and for the attachments of feedback (§ 8), deletion is not automatic; the Processor owes it once the period has expired and evidences it in text form on request.
• The final deletion of a business covers the database and the file stores and is logged. If the daily run does not remove the files marked for deletion, it reports a failure instead of success, and the Processor removes them itself without undue delay; a backlog of more than two days is treated as an incident.
• The restriction of processing under § 6 (3) is set by the Processor, not by the Controller itself. It sets it on the Controller's instruction in text form, without undue delay and free of charge.
• Uploaded files are not scanned for malware. Files are checked server-side for type and size, image formats that can execute program code are not accepted, and file stores are not public (sections 1 and 2).
• Support access to content data is governed organizationally, not enforced technically. It takes place exclusively at the request or with the approval of the Controller in the individual case and is recorded under § 4 (4) with occasion, time, scope and accessing person.
• Two-factor authentication for user accounts is not offered. Sign-in runs via a managed authentication service with hashed passwords; permissions are decided on the server side and are limited to five graduated roles (section 1).
• The bulk download of individual documents is limited to 500 documents and 40 MB per archive. The full export in partial archives is available for the complete holdings; it is the route for the return under § 13.
• The Processor does not carry out its own measurement of availability and therefore does not commit to any availability rate (AGB § 6 (2)). Backups and recoverability follow the services of the providers named in Annex 2 (section 3).
• The feedback function (§ 8) cannot be switched off by the Controller itself. The Processor switches it off for the Controller's business at the Controller's request in text form (§ 8 (8)).
• When sending via providers other than Google and Microsoft (§ 7a), the mailbox password is held by the Processor in encrypted form. Such a password technically permits more than sending at the provider; the restriction to sending is here a commitment of the Processor and not a limit enforced by the provider. Compensation: encryption and purpose limitation under § 7a (3), an app password created specifically for this where the provider offers one, and immediate deletion on disconnecting.
• With Microsoft the Processor cannot revoke an individual permission. On disconnecting it deletes the access token immediately; the account holder removes the permission itself in their Microsoft account (§ 7a (8)).