Data Processing Agreement

1. Conclusion, Scope and Order of Precedence

(1) The DPA comes into effect when an AppHighway app is installed through the Shopify App Store. By installing the app, the controller confirms that they have read this DPA and accept its contents as binding. Shopify displays the app's access rights before installation; the apps' terms of service reference this DPA.

(2) The DPA applies to all AppHighway apps the controller has installed; the app-specific details are set out in Annex 1. It applies from installation for as long as at least one app remains installed, and beyond that for the handover after uninstallation and — for E-Rechnung & GoBD — for the archive custody under Section 10 until that custody ends; it ends once deletion or return under Section 10 is complete.

(3) On data protection matters, this DPA takes precedence over the apps' terms of service. The controller remains responsible for the lawfulness of the processing and for safeguarding the rights of data subjects. The contract between the controller and Shopify International Ltd. governing use of the Shopify platform remains unaffected; Shopify is not a sub-processor of AppHighway (Annex 3).

(4) The controller warrants that they use the apps as a business. The DPA is based on Art. 28(3) GDPR; to the extent it does not contain a provision on a given point, the GDPR applies directly.

2. Subject Matter and Duration of the Processing

(1) The subject matter of the processing is the operation of each installed app for the controller's store: checking delivery addresses at checkout (Address Guard), creating, validating, delivering and archiving invoice documents (E-Rechnung & GoBD), and reconciling payouts against orders and creating accounting batches for the tax firm (DATEV Abgleich). The details for each app are set out in Annex 1.

(2) The processing continues for as long as the app remains installed in the store, plus the handover and deletion period described in Section 10 following uninstallation and — for E-Rechnung & GoBD — the archive custody regulated there until the last archive copy is deleted.

3. Nature and Purpose of the Processing, Categories of Data, Data Subjects

(1) Nature of the processing: collection via the Shopify API and Shopify webhooks, storage, retrieval, modification, organisation, transmission to recipients designated by the controller (buyers, tax firm), and deletion.

(2) Purpose: solely to provide the respective app function for the controller. The processor does not use the data for its own purposes, in particular not for advertising, profiling, product research or building its own data pools, and does not pass it on to third parties other than those listed in Annex 3.

(3) Categories of data and data subjects: customers of the store (buyers) and employees of the controller who operate the app. The categories of data processed per app are set out in Annex 1. Special categories of personal data (Art. 9 GDPR) are not subject to the processing; the controller does not transmit such data through the apps.

4. Instructions from the Controller

(1) The processor processes personal data only on the controller's documented instructions (Art. 28(3)(a) GDPR). This DPA, the controller's installation and configuration of the app (for example, the settings for invoice delivery, retention, tax rates or the booking mode) and the use of the functions offered in the dashboard all constitute instructions.

(2) The controller may issue further instructions in text form to support@apphighway.com, stating their store domain. The processor confirms receipt and carries out the instruction to the extent it falls within the apps' functionality; otherwise it explains why the instruction cannot be carried out.

(3) If the processor considers an instruction to be unlawful, it informs the controller without delay (Art. 28(3), third sentence, GDPR). It may suspend execution until the controller confirms or amends the instruction.

(4) Processing required by Union or Austrian law to which the processor is subject remains permissible; the processor informs the controller of such obligations before the processing, unless the law prohibits this.

5. Confidentiality

(1) The processor currently operates the apps alone, without employees. It undertakes to maintain confidentiality regarding all personal data it processes under this agreement (Art. 28(3)(b) GDPR). If persons are entrusted with the processing in the future, the processor binds them to confidentiality in writing before they take up the work and familiarises them with the instructions in this DPA; the obligation continues after the work ends.

(2) Access to production data is limited to what is required for operation, troubleshooting and support. For development and testing, the processor uses test stores and fictitious data, not the controller's production data. The countersignature of the run against production backups provided for in Annex 2 (recoverability) is given by a second person bound to confidentiality (for example the processor's tax advisor or a named data protection officer) who receives no access to the data and only confirms execution, log and deletion (version 1.11).

6. Security of Processing

(1) The processor implements the technical and organisational measures under Art. 32 GDPR described in Annex 2 and maintains them for the duration of the agreement. It may develop them further as long as the level of protection is not reduced; material changes are documented in Annex 2 with a date.

(2) The controller has reviewed the measures before installation and considers them adequate for the protection needs of the data processed. The controller informs the processor if the protection needs increase materially, for example because the controller wishes to process data through the apps that is not covered by Annex 1.

7. Sub-processors

(1) The controller grants general authorisation (Art. 28(2) GDPR) to engage the sub-processors named in Annex 3. A contract is in place with each sub-processor imposing on them the same data protection obligations that this DPA imposes on the processor (Art. 28(4) GDPR).

(2) If the processor intends to engage or replace a sub-processor, it informs the controller at least 30 days before deployment by e-mail to the store e-mail address on file with Shopify (alternatively to the contact address on file there), and updates Annex 3. The controller may object to the change within this period for good cause. If the parties cannot reach agreement, the controller may terminate the contract by uninstalling the app; Section 10 applies accordingly.

(3) Ancillary services the processor obtains from third parties that do not involve processing the controller's personal data (for example, domain registration or source code management without production data) do not constitute sub-processing.

8. Assistance with Data Subjects' Rights

(1) The processor assists the controller with appropriate technical and organisational measures in responding to requests from data subjects under Art. 15 to 22 GDPR (Art. 28(3)(e) GDPR). To that end, it implements Shopify's mandatory data protection webhooks: customers/data_request (access), customers/redact (deletion of customer data) and shop/redact (deletion of all store data after uninstallation).

(2) E-Rechnung & GoBD stores an access request and shows the controller in the dashboard which invoices relate to the customer, so that the controller can respond within the one-month period (Art. 12(3) GDPR). A deletion request leads to deletion of the data unless a statutory retention obligation prevents it; issued invoices are retained until the retention period expires (Art. 17(3)(b) GDPR, § 147 AO, § 14b UStG or § 132 BAO, as applicable), while a draft not yet issued is handled according to the rule chosen in the dashboard. DATEV Abgleich records access and erasure requests (request, customer and order identifiers from the webhooks) and shows the controller in the “Privacy requests” dashboard the orders concerned and the matches in the stored data (booking memo list, clarification items, list of open advance payments, document-field mappings, exclusion lists); the processor assists within 14 days of receipt, the one-month period entered by the controller (Art. 12(3) GDPR) is monitored and an overrun is reported to the processor. The controller can set a restriction of processing (Art. 18 GDPR) per request; the controller thereby chooses the effect on the revenue export: in mode “continue booking” (default) the order keeps being exported because the export carries only the order number and amounts and the controller's record-keeping duty persists (§ 146 AO, § 22 UStG; permitted under Art. 18(2) GDPR for reasons of important public interest in taxation together with Art. 23(1)(e) GDPR) — every export run lists the order as a notice; in mode “hold export” revenue and refund postings of that order are suspended until the restriction is lifted and carried as a clarification item with amount. All other processing of the restricted data (display of customer data, notifications) is suspended in both modes; refunds and settlements of revenue already booked continue to be processed in mode “continue booking”. Lifting the restriction requires that the controller has informed the data subject beforehand (Art. 18(3) GDPR); the processor records that confirmation (version 1.13). Accounting records are not deleted because of § 147 AO (Art. 17(3)(b) GDPR); the result of the check is recorded with person and note. Handled requests are deleted three years after the end of the calendar year of handling — a period the controller instructs with this DPA as evidence of handling (Art. 5(2), Art. 28(3)(a) GDPR; it follows no limitation period, cf. section 10 (1)); requests with an active restriction of processing are not deleted while the restriction persists. Open requests survive the shop/redact webhook (with the controller's last known contact address) and are completed with the controller via support; an open request still unhandled three years after the end of the calendar year of shop/redact is closed as unanswerable and deleted (version 1.13).

(3) If a data subject contacts the processor directly, the processor refers them to the controller and does not answer the request itself, unless instructed to do so by the controller.

9. Assistance with Security, Notification Duties and Data Protection Impact Assessments

(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 (Art. 28(3)(f) GDPR).

(2) If the processor becomes aware of a personal data breach affecting the controller's data, it notifies the controller without undue delay and at the latest within 48 hours of becoming aware, by e-mail to the store e-mail address on file with Shopify (alternatively to the contact address on file there). The notification includes, to the extent known, the nature of the breach, the categories of data affected and the approximate number of data subjects, the likely consequences, and the measures taken or proposed; further information follows without undue delay. This enables the controller to meet its own 72-hour deadline towards the supervisory authority (Art. 33(1) GDPR).

(3) For a data protection impact assessment or a prior consultation, the processor provides, on request, the description of the processing, the procedural documentation and the deletion concept for the relevant app.

10. Deletion and Return after the End of Processing

(1) When an app is uninstalled, the ongoing processing for that app ends; the handover and the archive custody (E-Rechnung & GoBD) and the availability of the log package (DATEV Abgleich) under this section remain part of the engagement and are governed by the version of this DPA in force at uninstallation, which the app records together with the end of the contract, the outcome of the handover and the scope of the handed-over archive export, without stored contact data (the store domain remains as the reference; any remaining personal reference is to be assessed separately); every uninstallation is logged immutably as its own cycle, and for the remaining stock the version of the last one applies. The processor returns or deletes the data under the following rules (Art. 28(3)(g) GDPR); retention beyond these periods is not guaranteed. The record also notes the scope of the handed-over archive export (number of documents, latest issue date and a check value over the list of documents). This evidence is deleted once no document with files, no draft and no handover package of the store remains (invoice number, amounts and chain link remain as number evidence) and ten years have passed since the end of the calendar year of the last logged event — the period the controller instructs with this DPA for the evidence of this processing (Art. 28(3)(a) GDPR), measured by the controller's own retention duty for the procedural documentation of its bookkeeping (§ 147 (1) no. 1, (3) AO), which does not bind the processor itself (version 1.9). Longer limitation or evidence periods (such as § 1489 ABGB under the agreed Austrian law or § 199 BGB) do not justify any further retention by the processor; any evidence beyond that is for the controller to keep with the documents handed over to it (version 1.8).

(2) Address Guard: There is no data to return. The store session is deleted on receipt of the app/uninstalled webhook, and any remaining store data is deleted on the shop/redact webhook, which Shopify sends 48 hours after uninstallation.

(3) E-Rechnung & GoBD: The controller is responsible for retaining issued invoices themselves. On uninstallation, the app creates the archive export (all issued invoices as PDF and XML, including verification logs) and a handover package of open drafts, and sends an e-mail to the store's invoice e-mail address with a signed download link. The periods in this paragraph run from receipt of the shop/redact webhook, which Shopify sends 48 hours after uninstallation; the store session is already deleted on the app/uninstalled webhook, the settings on receipt of shop/redact. Both packages remain available until day 28 (and, once the link has expired, also via the dashboard after a reinstallation); the handover counts as completed once the download of the archive export has been logged, a provision by support has been documented or a waiver has been declared — not by the sending of the e-mail alone —, and the processor retries a failed build daily and arranges a substitute provision before expiry. Drafts and handover packages are deleted from day 29, at the latest on day 30 after the shop/redact belonging to this uninstallation and never before 31 days have passed since the package was built (a webhook of an earlier uninstallation does not shorten the period); if day 30 falls before those 31 days have passed, the lower bound prevails — Shopify's platform deadline is no statutory upper limit. Issued invoices with their verification chain are not deleted by the app on its own during ongoing use; after the end of the contract the archive custody with the deletion regulated below applies. With this DPA the controller instructs the processor (Art. 28(3)(a) GDPR; choice under point (g): return as archive export and custody of the copy) to keep the issued invoices with their files and verification chain after the end of the engagement as an archive copy: for the duration of the controller's statutory retention period, at most for as long as the processor operates the service, with access for the controller via a reinstallation of the app or via support, and — once the handover is complete and only for documents covered by the handed-over archive export (before every deletion the app checks that the stock up to the recorded issue date comprises exactly the recorded number and — via the check value of the list of documents — exactly the same documents, otherwise no deletion takes place) — with automatic deletion of a document's files and buyer data no earlier than 90 days after its statutory standard retention period expires (German profile: 31 December of the year of issue plus eight years, or ten years for all issued and still stored documents once an institution within the meaning of § 1 (1b) KWG, an undertaking supervised under § 1 (1) VAG or an investment firm under § 2 (1) WpIG has selected this in the settings — a later withdrawal of the setting does not shorten the period (Art. 97 § 19a (3) EGAO; version 1.9); Austrian profile: 31 December of the calendar year following the year of issue plus seven years, because § 132 (1) BAO lets the period start only at the end of a deviating financial year and the app does not know the financial year; for documents that belong together — invoice, cancellation, correction, rectification, replacement invoice — after the latest expiry of the document chain), while the invoice number, the amounts and the link in the verification chain are kept so that the number sequence and the verification chain remain verifiable without gaps. Without a completed handover the app deletes nothing; the documents then remain stored until the controller instructs otherwise in text form. A suspension or extension of the retention period (§ 147 (3) sentence 5 AO, e.g. during an audit or an objection; § 132 (1) BAO for pending proceedings) is indicated by the controller before uninstallation by a deletion hold on the document or afterwards in text form; the app cannot detect it itself. The controller may instruct an earlier deletion in text form at any time. After the end of the engagement, requests of data subjects for access, rectification or erasure concerning documents of the archive copy are addressed by the controller to the processor's support, which implements the restriction or deletion under Section 8. Availability beyond the operating period of the service is not promised — the authoritative copy is the controller's archive export. Details are set out in the app's deletion concept, which the processor provides on request. Return and availability (choice of the controller under Art. 28(3)(g) GDPR): With this DPA the controller chooses the return of its documents in the form of the archive export. If the archive export has not been downloaded seven days before the expiry date, the app reports this to the processor (escalation). The processor then keeps the archive export available beyond day 28, reminds the controller 14 days after the escalation at the invoice e-mail address saved on uninstallation with a new download link and the deletion date, and deletes the archive export on the earlier of “30 days after that reminder” and “60 days after the escalation”, but never before 14 days after the reminder have passed; the reminder names the date so determined as the deletion date, that date applies and is not brought forward by later events — not even by a documented unreachability. Without a handed-over reminder the availability ends no later than 60 days after the escalation. A reminder is handed over only while at least 14 days remain until the absolute limit of 120 days after the first escalation; after that the availability ends at that limit or by a documented decision of the processor with secured retention. If the app finds on retrieval that the archive export file is damaged, it verifies the chain of the document store and rebuilds the archive export once; for the 60-day limit the rebuild counts as a new escalation, and the controller is reminded again with a new deletion date. If the verification chain is flawed or the failure recurs, no automatic rebuild takes place and the processor clarifies the provision with the controller. No later than 120 days after the first escalation every automatic availability ends. If the reminder cannot be sent, the attempt is repeated daily until it succeeds, the upper limit is reached or the controller has made a declaration. The controller may at any time instruct immediate deletion or waive the download in text form; a documented provision by other means, a waiver or unreachability after documented attempts end the availability period. Drafts, sessions and settings are not covered by this availability period and are deleted at the times stated above; the handover package is deleted from day 29, its data record only when the availability period of the archive export ends. The saved e-mail address is used only for the handover and the reminders under this section and is deleted together with that data record once the handover purpose has been achieved.

(4) DATEV Abgleich: During the term, the controller downloads the created accounting batches, the document-field mapping lists and the log export (change log of the settings, all clarification items with their resolution notes, the list of export runs, the list of open advance payments with their releases and the document-field mappings as CSV). On the app/uninstalled webhook, the store session is deleted and the app creates a log package from the entire data set (since version 1.11 a ZIP with the log export, the stored accounting batches and mapping lists and a checksum list), which it stores separately from the other data; settings, export runs, clarification items, the change log, the list of open advance payments and the stored export files are deleted on the shop/redact webhook, which Shopify sends 48 hours after uninstallation. The log package stays retrievable for 30 days after receipt of shop/redact, but at least 32 days after it was built, via a reinstallation of the app in the dashboard or via support, and is deleted by the app's deletion run (every six hours) afterwards; when the log package is built, the app informs the controller once by e-mail to the store's contact address saved during use about how to retrieve it and the deletion date — without a deliverable address, retrieval via reinstallation or support remains (version 1.11). If building the log package fails, the app retries it in the deletion run, alerts the processor and defers the deletion of the source data on the shop/redact webhook until a package has been built; if only the storage fails, the finished log export remains as a fallback copy in the processor's database and is retrievable like the package — 30 days after receipt of shop/redact the source data is then deleted, and the processor informs the controller once by e-mail to the store's contact address saved during use about the fallback copy and how to retrieve it; the fallback copy remains retrievable for 30 days from that notice (if it cannot be delivered, the period runs from the information of the controller recorded by the processor). If generating the export fails as well, the source data is not deleted by lapse of time: the processor informs the controller, generates the log manually and hands it over or obtains the controller's consent to the deletion; only a recorded decision triggers the deletion — with outcome (handover with file and checksum, consent to deletion, or unreachability after at least two documented contact attempts via different channels at least 14 days apart, the first at least 30 days earlier; version 1.11), date and channel of the information, the recorded result of the check of the controller's retention obligations (§ 147 AO; consent does not override them), person and reason. The controller decides on a retention obstacle: if the controller instructs retention (instruction in text form with date and channel, Art. 28(3)(a) and (g) GDPR), the source data is not deleted but retained for the controller — at most until the end of the controller's statutory retention period and no longer than ten years from the instruction; the processor resubmits the retention for review annually and deletes after a new instruction of the controller or after handing over a manually generated log. If the controller instructs deletion despite an obstacle affirmed by the controller, the deletion is recorded as the controller's decision and carried out. An obstacle may be affirmed only on the basis of a documented statement of the controller; the processor does not decide on an obstacle of the controller itself. If the controller is unreachable and an obstacle is affirmed on that basis, the controller hereby instructs, for that case, the retention of the source data until the end of the tenth calendar year after the year of uninstallation and its deletion thereafter (standing instruction, Art. 28(3)(a) GDPR). The maximum duration of any retention is ten calendar years from the instruction; after its end the processor reminds the controller monthly for 90 days and then deletes the source data with a decision record unless a new instruction has been given (version 1.13; version 1.12 left the deletion on hold without an end point in the case of unreachability, version 1.11 allowed retention as a decision of the processor). This decision record is kept separately from the failure record and deleted like the record under para. 1, ten years after the end of the calendar year of the decision. A held deletion is reported to the processor again every 30 days; a decision must be taken no later than 120 days after the hold (version 1.10). The alert to the processor and the information of the controller are sent via the sub-processor Brevo (Annex 3).

(5) Backups kept to restore the service are overwritten after the period stated in Annex 2; processing from backups occurs only to restore the service. In the object storage for documents and export files, an object deleted or overwritten by the app remains available as a previous version for 30 days and is then released for permanent removal (Annex 2, availability); the deletion deadlines in this section refer to the deletion by the app; the provider carries out the permanent removal of the previous version asynchronously after the 30 days have elapsed, usually within a few days — no fixed latest date is promised for it —, and until then the previous version, too, is processed only to restore the service (version 1.14; clarification on the deletion execution in version 1.15). Statutory retention obligations of the processor, for example for its own billing records, remain unaffected; they do not concern the controller's customer data.

(6) On request, the processor confirms the deletion in text form. The confirmation states the deletion by the app with its date and points out which copies still exist afterwards and when they lapse: database backups (Annex 2, at most 30 days) and previous object versions in object storage (paragraph 5, 30 days plus execution by the provider); this also applies to deletions based on customers/redact (version 1.15).

11. Evidence and Audits

(1) The processor provides the controller with all information necessary to demonstrate compliance with the obligations under Art. 28 GDPR (Art. 28(3)(h) GDPR). This includes, on request, the procedural documentation and deletion concept for the relevant app, the description of the technical and organisational measures, the list of sub-processors, and confirmation of deletion.

(2) The controller may audit compliance with this DPA once a year, and more often where there is a specific reason. The audit is carried out primarily by answering written questions and submitting documents; an on-site audit is possible with at least 14 days' notice during ordinary business hours. The processor may charge reasonable costs for audits that go beyond answering written questions, unless the audit uncovers a material breach.

(3) The processor cooperates with audits by the competent supervisory authority and informs the controller of audits concerning the controller's data, to the extent legally permitted.

12. Place of Processing and Third-Country Transfers

(1) Processing takes place in data centres within the European Union (Annex 3): hosting server and databases at Hetzner in Germany, object storage for documents and export files at AWS in Frankfurt (region eu-central-1), object storage for the database backups at AWS in Stockholm, Sweden (region eu-north-1). Both object storage locations have been evidenced since version 1.14 and are promised (Annex 2); version 1.13 had left the backup location open. No transfer to third countries is envisaged. Should a sub-processor process data in a third country, the processor ensures appropriate safeguards under Chapter V GDPR beforehand (for example, EU standard contractual clauses) and informs the controller under Section 7.

13. Liability

(1) The parties' liability towards data subjects is governed by Art. 82 GDPR. As between the parties, each party is liable for damage it causes through a breach of the GDPR or of this DPA attributable to it. The liability provisions of the apps' terms of service apply in addition to the liability between the parties, to the extent they do not conflict with Art. 82 GDPR.

14. Term, Amendments, Final Provisions

(1) The DPA runs for as long as an AppHighway app remains installed in the store and ends once deletion or return under Section 10 is complete — for E-Rechnung & GoBD including the archive custody until the last archive copy is deleted. For the duration of the archive custody, Sections 5 (confidentiality), 6 (security), 7 (sub-processors), 9 (assistance) and 11 (evidence) continue to apply; the confidentiality obligations continue to apply thereafter as well.

(2) The processor notifies amendments to this DPA at least 30 days before they take effect, by e-mail to the store e-mail address on file with Shopify (alternatively to the contact address on file there), and publishes the new version with a version number and date on this page. If the controller does not object within this period, or continues to use the app afterwards, the new version applies. If the controller objects, the previous version continues to apply until uninstallation; amendments required by law or by a supervisory authority's requirements take effect even without consent.

(3) Austrian law applies. Mandatory provisions of the GDPR take precedence. Should a provision of this DPA be invalid, the remaining provisions remain in force; the invalid provision is replaced by the applicable statutory rule. This DPA is published in German and English; the German version prevails.

Annex 1 — Subject Matter of the Processing per App

These details describe what data each app actually stores and where. Data an app only reads via the Shopify API without storing it is marked "read only".

Annex 2 — Technical and Organisational Measures (Art. 32 GDPR)

As of October 2026. These measures apply to all apps unless stated otherwise.

• Physical and access control: operation in Hetzner Online GmbH data centres (ISO 27001) in Germany; access to servers and provider accounts only by the operator, with two-factor authentication and personal credentials; no sharing of credentials.
• Authorisation control: each app runs with its own database and its own set of keys for application operation (database credentials, API keys); the database backups of all apps, however, are stored in a shared backup area under one backup key of the processor (availability, below). A separation of backup access per app will not be set up (version 1.14; listed as a planned measure up to version 1.13): the backup key is held solely by the processor's operations platform, the apps themselves have no access to the backup area, and separate keys per app would not move this trust boundary. It is deliberately accepted that, should this one backup key be lost, the backups of all apps would be affected; the storage in separate folders per database is an organisational arrangement, not an access separation, and server-side encryption (encryption, below) does not replace an access restriction (clarification in version 1.15). Databases are not publicly reachable. Store access tokens are stored server-side and never exposed to the browser. Dashboards are reachable only through the Shopify-authenticated merchant session (App Bridge, session token); webhooks are verified using Shopify's HMAC signature.
• Separation control: all data is tagged with the store domain; every query is scoped to that store. Files are stored per store in their own path within the private storage area. Test and development environments are separated from production and do not use production data; the only exception is the documented restore test (recoverability, below).
• Encryption: transmission exclusively over TLS (HTTPS); object storage with server-side encryption (the provider's default encryption; on AWS S3 applied to every new object since January 2023 and not switchable off); database backups are stored daily locally on the hosting server at Hetzner and additionally in a shared, non-public storage area (bucket) of AWS object storage in the eu-north-1 region (Stockholm, Sweden) under its server-side default encryption (SSE-S3); location and encryption of the backup area have been evidenced since version 1.14 and are promised (version 1.13 had left the location open; version 1.12 had been published on 7 October 2026 without this evidence); the storage area is used for all apps with a single access key of the processor and is under his sole access; encryption of the backup files beyond that, for example before upload with a key of the processor's own, is not guaranteed (version 1.11). The object storage for documents and export files in Frankfurt is likewise encrypted server-side (SSE-S3, version 1.14). Document download links are signed and time-limited.
• Integrity: issued invoices are archived as an immutable record with a checksum chain (E-Rechnung & GoBD); exports cannot be altered after the fact, and corrections are made through new runs with a log (DATEV Abgleich). All processing steps are logged and traceable in the controller's dashboard.
• Availability and resilience: daily backups of each app's database (locally on the hosting server and in object storage, each retained for 30 days and then overwritten; alert to the processor if a backup is missing for more than one day; version 1.11); object storage with redundant storage; the object storage for documents and export files keeps object versions since 9 October 2026: a deleted or overwritten object remains restorable as a previous version for 30 days and is then released for permanent removal by a lifecycle rule, which the provider executes asynchronously (version 1.14; clarification in version 1.15); there is no backup of the object storage against the loss of the storage area itself (replication); alerts of the operations platform — missing or failed backup, failed deployment, resource status — are delivered to the processor via a messenger channel, and delivery has been evidenced (version 1.14); operational monitoring and automatic restart of services; separate services per app, so that an outage of one app does not affect the others.
• Recoverability: infrastructure and configuration are documented and reproducible; a restore test from the backups (Art. 32(1)(d) GDPR) is documented as a trial run with a production-equivalent procedure, the run against the production backups is still outstanding before the general release of the apps; thereafter it is repeated annually. The test takes place in an isolated environment accessible only to the processor; production data is processed there exclusively for this purpose and deleted immediately after the test; every run is logged. The run against production backups is carried out by a named person of the processor on an encrypted volume without access by third parties — including AI services or other tools with data egress —, countersigned by a second person; backup copy, test instances and object copies are deleted immediately after the run, checksums, logs and check reports remain (counters, chain values, document index of the test data without buyer data), and the deletion is recorded (version 1.9; scope of the evidence clarified in version 1.12). Deletions are additionally recorded in a deletion journal outside the database so that they are re-applied after a restore (version 1.12). In the restored copy the store access tokens (sessions) are deleted immediately after the restore, and the test instance gets no outbound network access; before writes are released after a real restore, documents, number ranges and export runs created after the backup time are reconciled from object storage, the mail provider's delivery log and Shopify (restart), so that no invoice number is assigned twice (version 1.11).
• Input control: changes to settings are logged with time and store account (DATEV Abgleich: change log; when receivable accounts are approved, additionally with the name of the confirming person); deletions carried out on instruction are documented with the time.
• Sub-processing control: a data processing agreement under Art. 28 GDPR is in place with every sub-processor; the list in Annex 3 is kept up to date.
• Deletion control: deletion under the periods in Section 10 by automated runs of the apps (E-Rechnung & GoBD daily, DATEV Abgleich every six hours) and Shopify webhooks; a deletion concept is documented for each app.
• Secure development: version control with review before every release (type checking, automated tests, dependency review); secrets held exclusively in the hosting environment's configuration, never in source code.
• Organisation: a data protection and deletion concept for each app, procedural documentation (E-Rechnung & GoBD), a data breach process with notification under Section 9, and an annual review of these measures.

Annex 3 — Sub-processors

As of October 2026. All sub-processors process the data within the European Union; the object storage locations have been evidenced since version 1.14 (Annex 2).

• Hetzner Online GmbH, Industriestr. 25, 91710 Gunzenhausen, Germany — hosting of the applications, databases and the validation service (data centres in Germany). Affected: all apps.
• Amazon Web Services EMEA SARL, 38 Avenue John F. Kennedy, L-1855 Luxembourg — object storage (S3) in the eu-central-1 (Frankfurt) region for invoice documents, archive and handover packages, and export files; object storage (S3) in the eu-north-1 region (Stockholm, Sweden) for the daily database backups of all apps (location evidenced, version 1.14; Annex 2). Affected: E-Rechnung & GoBD, DATEV Abgleich (documents, export files, backups) and Address Guard (backup of the session database; version 1.11).
• Brevo (Sendinblue SAS), 7 rue de Madrid, 75008 Paris, France — sending transactional e-mail: invoice delivery to buyers (only where enabled by the controller) and notifications to the controller, for example at the end of the contract. Affected: E-Rechnung & GoBD (invoice delivery, notifications to the controller) and DATEV Abgleich (operator alerts about the log package to the processor itself and the one-off information of the controller when the log package is built and in the fallback path — version 1.11; fallback path since version 1.10 — no e-mails to buyers; version 1.9).
• Not a sub-processor: Shopify International Ltd. (Dublin, Ireland) is the platform the controller itself uses under its own contract; the apps read and write data on the controller's behalf through the controller's Shopify account. The contract between the controller and Shopify governs Shopify's own processing.