Data Processing Agreement (DPA)

1. Scope & Roles

This DPA applies to Scandora's processing of your document content, and of data derived from it, on your behalf. That processing happens on five paths:

• Managed AI — for document analysis and for document search and chat, your device asks the AI model provider directly, using a short-lived credential (five minutes) that Scandora's server issues; retrieval for search and chat runs on your device against an on-device index. To build that index, your device automatically sends the extracted text and the AI description of each indexed document, split into passages each headed by the document's title, type and date, to the model provider, which returns the search vectors kept on your device; for a search, only the search query is sent, and for a chat question, only the question and the passages your device selects are sent to the model provider. Managed AI is the only AI path in this version: a bring-your-own-API-key option is not part of this version (section 6 of our Terms). Document content and search passages never reach Scandora's own server on this path — Scandora only issues the short-lived credential — and the resulting AI request is covered by this DPA. Scandora does not operate a server-side AI gateway or a server-hosted search index.
• Cloud history sync — while you are signed in, each completed scan's history record is uploaded to Scandora's own server in Falkenstein, Germany, so your history is available on all your devices. It carries the record's metadata, the full text extracted from the document and a small preview thumbnail of the first page. This happens on every plan; it is not optional.
• Server-side DATEV export — when you run a DATEV export, the booking rows you export and the document images attached to them are sent to Scandora's own server in Falkenstein, Germany, assembled there into the DATEV EXTF ZIP and returned to you. The booking rows carry, per booking, the date, the gross amount, the debit/credit marker, the account and contra account, the DATEV BU key, the invoice number, the booking text, the recognition confidence and the document file name; the export header carries your Berater and Mandant number, the chart of accounts, the fiscal-year start, the exported date range and the name you set as the exporting user. Everything is processed for that one request and is not stored. This export is coming soon: it is designed for the Business and Enterprise plans and is not yet switched on. Until it is, the app shows it as coming soon and no export can be started, so no data travels this path yet; we describe it here because it is contracted for and will be switched on under this DPA.
• GoBD capture and change records — while you are signed in, every capture, metadata edit, export and deletion also writes a record to Scandora's own server in Falkenstein, Germany, so that a captured document and each later change to it stay traceable: a capture record (a SHA-256 checksum of the captured file, the capture source, a device description, the user and profile identifier and a server timestamp) and a change-log entry (the document identifier, the event — capture, edit, export or delete —, the user identifier, the acting profile, a server timestamp, for an export the destination you exported to, and, for an edit, the old and the new value of each metadata field that changed: title, labels, gross amount, invoice number, invoice date). Neither record holds a page image or the document text. This happens for every signed-in user on every plan; it is not optional, and the change log is append-only at database level — see section 2 for what that means for erasure.
• Cross-device import register — when you import a document from a connected cloud storage (Google Drive, Dropbox, OneDrive, Nextcloud, Trello) or from your device's file picker, Scandora records that one import centrally, so a second device cannot import the same file again. Unlike every other path above, this record is not stored on Scandora's own server: it is stored in Google Firestore, in the Frankfurt (europe-west3) region. It holds the source identity (the provider, an identifier of the source account, and the provider's file identifier and version marker — or, for a file you picked on the device, a SHA-256 fingerprint of that file's content), your account and profile identifier, the import status, the status and storage reference of each destination the import was delivered to, and a short-lived device lease. It holds no page image and no document text. The storage reference is the destination's file URL or the generated PDF's file path and can therefore contain the document's file name. It is written on every plan whenever you use an import; importing the same file again removes its entry, and account deletion erases every entry of the account.

If Scandora later adds a further path on which your document content is processed on your behalf, we inform you in text form before that extension takes effect and update sections 3 and 5 accordingly. You may object before it takes effect. If you object, we do not activate the new path for your account and this DPA continues unchanged for the paths listed above. Where we cannot provide the service to you without that path, we tell you when you object, and you may then terminate this DPA and the underlying contract with effect from the date the extension would have taken effect. You are never left using Scandora for your clients' data without a contract under Art. 28 GDPR in force. If you do not object, this DPA covers the new path from that date.

Your own account data — your email address, your name, your subscription and billing record — sits outside this DPA. For that data Scandora is the controller under its own contract with you, not your processor. The same is true of email correspondence; see the note under section 5.

Who is controller of the history record. The history record is covered by this DPA in full — the extracted document text, the preview thumbnail and the record's metadata (title, dates, page count, file size, labels, export destinations, extracted fields). You decide which documents are scanned and why they are kept, so Scandora stores that record as your processor and uses it for no purpose of its own. Section 8 of our Privacy Policy lists history metadata under Scandora's controller role; that describes use without a DPA, where the user is a data subject rather than a controller. For the records you process under this DPA, the processor role stated here applies.

• Controller: you (the business customer / your Steuerberater's client).
• Processor: Scandora — Farhad Sanaei seresht (sole proprietor, trading as "Scandora"), Burgunderweg 19G, 22453 Hamburg, Germany. See our Imprint.
• Sub-processors: the hosting provider of Scandora's EU server (Hetzner), the underlying model provider (Google Gemini / Vertex AI) and Google Firebase, which stores the import register — see section 5.

2. Subject, Nature, Purpose & Duration

Processing lasts for as long as you use Scandora and ends when the underlying contract ends. Per path:

• Managed AI — your device sends document images, extracted text, prompts, search queries and, for chat, the on-device-selected passages, and, when a document is indexed for search, its extracted text and AI description, split into passages each headed by the document's title, type and date, directly to the AI model provider using the short-lived credential described in section 1. Scandora's server never receives or stores that content, even transiently; the model provider processes it to produce AI analysis results (e.g. titles, labels, extracted fields, the search vectors of the on-device index, search and chat answers) and, apart from the abuse monitoring described below, does not retain it beyond the request either. The retired opt-in AI search index no longer accepts new data — search now runs on your device instead (section 1). Any data that remained in it from before this change is erased within 30 days of account deletion, and, where no other retention period applies, after 30 days without account activity.
• Cloud history sync — the processor stores the history record described in section 3 to keep your scan history available across your devices. Retention: on the Free plan each record is erased 180 days after it was stored; on a paid plan no record is erased while the subscription is running, and the window starts when the subscription ends — 90 days (Pro), 180 days (Business). A subscription taken up again inside that window leaves the records in place. Records that were already stored when this deletion was switched on run their window from that switch-on date. A record you delete is erased with that deletion; when the account is deleted, every record of that account is erased with it, at the latest within 30 days.
• Server-side DATEV export (coming soon — not yet switched on, see section 1) — the processor receives the booking rows you export and the document images attached to them, assembles the DATEV EXTF ZIP and returns it to you. This is transient: neither the rows nor the images are stored.
• GoBD capture and change records — the processor stores these records as evidence that a captured document is unaltered and that every later change to it is traceable. They are not erased when you delete the history record or your account: the change log is append-only at database level, so single entries cannot be deleted, and the capture records are kept alongside it so that a document's origin stays verifiable. What an account deletion does do is replace the identifiers in them: the user and profile identifiers are replaced by a stand-in value, and the edited metadata values and the exported file names are removed with the account, while the checksum, the timestamps and the hash chain stay, so the records survive without the identifiers they were written with. We do not present the result as anonymous data: each entry's chain fingerprint was computed before that replacement, and the capture record's checksum still matches the document itself, so anyone holding that document or the replaced identifiers can still tie an entry to a person. Why we keep them, plainly: no German law requires us to store them. The GoBD record-keeping and unalterability duties (§ 146(4), § 147 AO, § 239(3) HGB) bind you or your business, not us, and § 257 HGB binds merchants, which Scandora — run as an unregistered sole proprietorship (Kleingewerbe) — is not. We therefore do not rely on Art. 28(3)(g) GDPR, which lets a processor keep data past the end of the contract only where Union or Member State law requires that storage. We keep these records for our own evidence purpose and are the controller for that retention (Art. 6(1)(f) GDPR): a document captured with Scandora should stay verifiable for as long as you may have to produce it. They are written on every plan and cannot be switched off — we therefore do not present that retention as an instruction you gave us. How long: we keep both records for ten years, the period German law sets for a trader's own books and records (§ 147(1) No. 1, (3) AO), counted from the end of the calendar year in which the record was made (§ 147(4) AO), and delete them once that period has expired. That period is a cap we set ourselves, not a duty we are under — section 11 of our privacy policy says the same. The delete-or-return duty in section 4 and the erasure measures in section 7 do not reach these two records while that period runs. One limitation, stated plainly: today nothing removes these rows by age. The change log is append-only at database level, so its entries cannot be deleted at all, and no routine yet deletes the capture records when the period expires, so the records currently stay beyond it. Building that deletion step is on our list; we do not warrant a date-certain erasure that we could not carry out. What we cannot do for them: the database rejects every deletion of a change-log entry, and every change to one except a change that carries our account-deletion marker, leaves the chain values and the timestamps untouched and marks the entry as redacted — only the account-deletion routine sets that marker, and a marked entry is no longer checked against its own fingerprint, so a change made through that one path is not flagged as tampering. The capture record's checksum and timestamp are write-once, so we cannot rectify a single entry or erase one, and we do not promise you an earlier erasure that we could not carry out. If your own retention duty ends sooner, tell us in text form: we then use the records for that evidence purpose only and for nothing else (Art. 18 GDPR) and note your objection (Art. 21 GDPR). If you do not want these records written at all, Scandora cannot be used for those documents; you may terminate this DPA and the underlying contract in accordance with that contract. See section 8.
• Cross-device import register — the processor stores one register entry per import, in Google Firestore (Frankfurt), so the same source file is not imported twice across your devices. The entry is kept for the life of your account: importing the same file again deletes its entry, and account deletion erases every entry of the account. It carries no document content — the field list is in section 3.

Abuse monitoring. Google may keep prompts sent through managed AI that its automated safety systems flag for up to 90 days, in the Google Cloud region used for managed AI (europe-west3, Frankfurt), only for abuse monitoring; Google does not use them to train models.

3. Data Categories & Data Subjects

Categories of data:

• Document images and the text extracted from them, plus the prompts and questions you submit about a document, the search queries you enter, and, for chat, the on-device-selected passages, and, when a document is indexed for search, its extracted text and AI description, split into passages each headed by the document's title, type and date — sent by your device directly to the model provider, not to Scandora (managed AI).
• The history record stored on Scandora's own server: the full text extracted from the document (OCR text, stored up to a 400,000-character cap) and a small base64 preview thumbnail of the first page, together with the record's metadata — title, creation date, page count, file size, labels, the destinations you exported to, and the fields the AI extracted (e.g. amount, invoice number, invoice date).
• The DATEV export payload (transient; the export is coming soon and not yet switched on, see section 1): the booking rows — per booking the date, gross amount, debit/credit marker, account and contra account, DATEV BU key, invoice number, booking text, recognition confidence and document file name — the export header (Berater number, Mandant number, chart of accounts, fiscal-year start, exported date range, the name set as the exporting user), and the document images attached to those bookings. A booking text or an invoice number can identify your own clients.
• The GoBD capture and change records: per capture, a SHA-256 checksum of the captured file, the capture source (camera, network scanner or file upload), a device description, the user and profile identifier and a server timestamp; per document event, the document identifier, the event type (capture, edit, export, delete), the user identifier, the acting profile, a server timestamp, for an export the destination you exported to, and, for an edit, the old and the new value of each metadata field that changed (title, labels, gross amount, invoice number, invoice date). No page image and no document text.
• The import-register entry: the source provider, an identifier of the source account, the provider's file identifier and version marker or — for a file picked on the device — a SHA-256 fingerprint of that file's content, your account and profile identifier, the import status, the status and storage reference of each destination the import was delivered to, and a short-lived device lease. No page image and no document text; the storage reference is the destination's file URL or the generated PDF's file path and can therefore contain the document's file name.

All of these may contain special categories of personal data (Art. 9 GDPR) where you submit such documents.

Categories of data subjects: persons you determine, whose data appears in the processed documents (e.g. your clients, customers, employees).

4. Processor Obligations

• Process only on your documented instructions — unless Union or Member State law to which we are subject requires otherwise; in that case we inform you of that legal requirement before we process on that basis, unless the law prohibits us from telling you on important grounds of public interest (Art. 28(3)(a) GDPR).
• Inform you immediately if, in our opinion, an instruction infringes the GDPR or other data-protection provisions of the Union or of a Member State (Art. 28(3), final subparagraph GDPR).
• Bind authorised personnel to confidentiality.
• Implement the technical and organisational measures in section 7.
• Assist you with data-subject requests and with your obligations under Art. 32–36 GDPR.
• Delete or return the data at your choice on termination (Art. 28(3)(g) GDPR). The GoBD capture and change records described in section 2 are outside that duty: we keep them as controller for our own evidence purpose, for the ten-year period stated there — a cap we set ourselves, not a storage duty imposed on us — and the change log cannot be deleted entry by entry at all.
• Make available the information needed to demonstrate compliance and allow for audits.

5. Sub-Processors

You authorise the following sub-processors for the processing described in section 1. This list is the authoritative one for the processing Scandora performs as your processor. Section 7 of our Privacy Policy serves a different purpose: it lists every recipient of personal data, including the providers we use as controller for our own purposes, such as email (see the note below this table); where the two describe the same provider, this DPA governs the processor-side processing. We inform you of intended changes and grant a right to object. We impose on every sub-processor the same data-protection obligations that this DPA imposes on us (Art. 28(4) GDPR).

The model provider (Google) acts as Scandora's sub-processor on the managed AI path, which your device calls directly with a short-lived credential — Scandora's server does not see or store the document content on this path. Hetzner hosts the servers on which the history records and the GoBD capture and change records are stored; it has no access to the application's data for its own purposes. Google Firebase is a separate role from the model-provider role above: it holds only the import register, and no document content.

Outside this DPA's scope — email. Two email flows touch your data but sit outside this DPA, because there we act as controller for our own contract with you, not as your processor. Neither carries the document content processed under this DPA:

• Mail we send you — order confirmations and account/lifecycle messages leave the domain through Brevo (Sendinblue SAS, France; sending and storage in the EU, with USA/India access inside Brevo's own chain under the EU Standard Contractual Clauses).
• Mail you send us — messages to support@, privacy@ or [email protected] are routed by Cloudflare into an ordinary Google consumer mailbox, for which no Art. 28 processor agreement is available. A message you send through the website contact form reaches the same mailbox — our own server relays it to [email protected] through Brevo, and Cloudflare forwards it on. Our reply leaves through Brevo and normally quotes your message.

Both are listed in section 7 of our Privacy Policy. If you would rather not send contract or personal data by email, use the postal address in our Imprint.

6. International Transfers

Where a sub-processor processes data outside the EU/EEA (e.g. the USA), transfers are safeguarded by the EU Standard Contractual Clauses and/or the provider's certification under the EU–US Data Privacy Framework. Managed AI is called by your device directly, using a short-lived credential Scandora's server issues; the AI call itself is processed in Germany when the Frankfurt regional service (Vertex AI europe-west3) is used, and is not a third-country transfer for that leg, and it does not pass through Scandora's own server at all. Scandora's OAuth components and the credential-issuing endpoint run on Scandora's own server in Falkenstein, Germany. Most of the data stored under this DPA — the history records and the GoBD capture and change records — stays on Scandora's own servers in Falkenstein, Germany. The one exception is the cross-device import register, which is stored in Google Cloud Firestore in the europe-west3 (Frankfurt) region. Both locations are in Germany, so neither store is a third-country transfer; for the remaining Google Cloud processing around it (control plane, support access) the EU Standard Contractual Clauses and/or Google's DPF certification apply.

7. Technical & Organisational Measures (TOMs)

• Encryption in transit (TLS) on every connection between the app, our servers and our sub-processors.
• Per-user encryption (AES-256-GCM) of the integration and AI credentials you store. For the remaining data stored under this DPA we do not claim encryption at rest as a measure; it is protected by the access, separation and hosting measures listed here.
• Role-based access control and logging.
• Pseudonymisation of the user identifier (Firebase UID).
• Managed AI is called by your device directly with a short-lived credential; Scandora's server never receives or stores the document content on that path.
• Stored records are held per user and per profile and are readable only with that user's authenticated token; deleting a history record removes it, and account deletion erases every history record and every import-register entry of the account. The GoBD capture and change records are retained as described in section 2 and are not covered by that erasure; the account deletion replaces the identifiers in them instead, so no retained entry still stores the deleted account's identifiers.
• The OAuth components, the credential-issuing endpoint and all data stored under this DPA are hosted on Scandora's own server in Falkenstein, Germany, with two exceptions that both stay in Germany: the AI model call goes to Google's europe-west3 (Frankfurt) region, and the import register is stored in Google Cloud Firestore in the same europe-west3 region.
• Regular updates, recoverability and resilience of systems.
• A process for regularly testing the effectiveness of the measures.

8. Controller & Data-Subject Rights

You remain in control of the data. Data subjects have the rights under Art. 15–22 GDPR (access, rectification, erasure, restriction, portability, objection). Scandora assists you in fulfilling them. To exercise rights or raise questions, contact [email protected].

Where that assistance is limited. For the GoBD capture and change records described in section 2, the append-only design allows only part of it: we can give access (Art. 15), restrict further use (Art. 18), export the entries (Art. 20) and note an objection (Art. 21), but we cannot rectify (Art. 16) or erase (Art. 17) a single entry while the retention period stated in section 2 runs — and, as section 2 says plainly, today nothing removes these rows once it expires either. Deleting the account replaces the identifiers in every one of its entries, but the entries stay personal data: each chain fingerprint was computed before that replacement, and the capture record's checksum still matches the document itself. For every other record covered by this DPA — history records, managed-AI content — the assistance is unrestricted.

9. Download & Conclude the DPA

Download the signable template, complete the party fields, sign, and return one copy to [email protected]:

• Scandora DPA template (PDF)
• Scandora DPA template (DOCX)

The signable template includes the controller/processor party fields, a sub-processor annex, the TOMs, and signature blocks. Its Annex 1 names the same sub-processors as section 5 above — Hetzner Online GmbH (Falkenstein, Germany), Google (Gemini API / Vertex AI) (Frankfurt, Germany — Vertex AI europe-west3 for AI analysis, search and chat, called directly by your device; remaining Google Cloud processing on the basis of the EU Standard Contractual Clauses / DPF) and Google (Firebase / Cloud Firestore) (Frankfurt, Germany — europe-west3, import register only) — as the authoritative processor-side list, for the same five paths. Both downloads are generated from one source file, so they always carry the same text, and both carry the version stamp Fassung / Version: 2026-10-03 (Rev. 8) so you can tell which revision you signed.

10. Contact

1. Anwendungsbereich & Rollen

Dieser AVV gilt für die Verarbeitung Ihrer Dokumentinhalte und daraus abgeleiteter Daten durch Scandora in Ihrem Auftrag. Diese Verarbeitung erfolgt auf fünf Wegen:

• Verwaltete KI (Managed AI) — für die Dokumentanalyse sowie für die Dokumentensuche und den Dokument-Chat fragt Ihr Gerät den KI-Modellanbieter direkt an, mit einer kurzlebigen Zugangsberechtigung (fünf Minuten), die der Server von Scandora ausstellt; die Suche und der Abruf für den Chat erfolgen auf Ihrem Gerät gegen einen geräteseitigen Index. Um diesen Index aufzubauen, sendet Ihr Gerät automatisch den extrahierten Text und die KI-Beschreibung jedes indexierten Dokuments, in Passagen aufgeteilt, jeweils mit einer Kopfzeile aus Titel, Typ und Datum des Dokuments, an den Modellanbieter, der daraus die auf Ihrem Gerät gespeicherten Suchvektoren berechnet; bei einer Suche wird nur die Suchanfrage gesendet, und bei einer Chat-Frage werden nur die Frage und die von Ihrem Gerät ausgewählten Textpassagen an den Modellanbieter gesendet. Verwaltete KI ist der einzige KI-Weg dieser Version: Eine Mitbring-Funktion für eigene API-Schlüssel ist nicht Bestandteil dieser Version (Abschnitt 6 unserer AGB). Dokumentinhalte und Suchpassagen erreichen auf diesem Weg zu keinem Zeitpunkt den eigenen Server von Scandora — Scandora stellt lediglich die kurzlebige Zugangsberechtigung aus —, und die daraus resultierende KI-Anfrage unterfällt diesem AVV. Scandora betreibt weder ein serverseitiges KI-Gateway noch einen serverseitig gehosteten Suchindex.
• Cloud-Verlaufssynchronisation — solange Sie angemeldet sind, wird der Verlaufseintrag jedes abgeschlossenen Scans auf den eigenen Server von Scandora in Falkenstein, Deutschland, hochgeladen, damit Ihr Verlauf auf allen Ihren Geräten verfügbar ist. Er enthält die Metadaten des Eintrags, den vollständigen aus dem Dokument extrahierten Text und ein kleines Vorschaubild der ersten Seite. Das geschieht in jedem Tarif; es ist nicht optional.
• Serverseitiger DATEV-Export — wenn Sie einen DATEV-Export ausführen, werden die Buchungssätze selbst und die dazugehörigen Dokumentbilder an den eigenen Server von Scandora in Falkenstein, Deutschland, gesendet, dort zur DATEV-EXTF-ZIP-Datei zusammengestellt und an Sie zurückgegeben. Die Buchungssätze enthalten je Buchung das Datum, den Bruttobetrag, das Soll-/Haben-Kennzeichen, Konto und Gegenkonto, den DATEV-BU-Schlüssel, die Rechnungsnummer, den Buchungstext, den Erkennungs-Konfidenzwert und den Dokumentdateinamen; der Exportkopf enthält Ihre Berater- und Mandantennummer, den Kontenrahmen, den Beginn des Wirtschaftsjahres, den exportierten Zeitraum und den von Ihnen gesetzten Namen der exportierenden Person. Alles wird nur für diese eine Anfrage verarbeitet und nicht gespeichert. Dieser Export ist in Vorbereitung: Er ist für die Tarife Business und Enterprise vorgesehen und noch nicht freigeschaltet. Bis dahin weist die App ihn als demnächst verfügbar aus und es lässt sich kein Export starten, sodass auf diesem Weg noch keine Daten fließen; wir beschreiben ihn hier, weil er Teil der beauftragten Leistung ist und unter diesem AVV freigeschaltet wird.
• GoBD-Erfassungs- und Änderungsaufzeichnungen — solange Sie angemeldet sind, schreibt jede Erfassung, jede Metadatenänderung, jeder Export und jede Löschung zusätzlich einen Datensatz auf den eigenen Server von Scandora in Falkenstein, Deutschland, damit ein erfasstes Dokument und jede spätere Änderung daran nachvollziehbar bleiben: einen Erfassungsnachweis (SHA-256-Prüfsumme der erfassten Datei, Erfassungsquelle, Gerätebeschreibung, Nutzer- und Profilkennung, Server-Zeitstempel) und einen Änderungsprotokolleintrag (Dokumentkennung, Ereignis — Erfassung, Bearbeitung, Export oder Löschung —, Nutzerkennung, handelndes Profil, Server-Zeitstempel, bei einem Export das von Ihnen gewählte Exportziel und, bei einer Bearbeitung, der alte und der neue Wert jedes geänderten Metadatenfeldes: Titel, Labels, Bruttobetrag, Rechnungsnummer, Rechnungsdatum). Keiner der beiden Datensätze enthält ein Seitenbild oder den Dokumenttext. Das geschieht für jede angemeldete Person in jedem Tarif; es ist nicht optional, und das Änderungsprotokoll ist auf Datenbankebene reine Anfügung — was das für die Löschung bedeutet, steht in Abschnitt 2.
• Geräteübergreifendes Importregister — wenn Sie ein Dokument aus einem verbundenen Cloud-Speicher (Google Drive, Dropbox, OneDrive, Nextcloud, Trello) oder über die Dateiauswahl Ihres Geräts importieren, hält Scandora diesen einen Import zentral fest, damit ein zweites Gerät dieselbe Datei nicht erneut importiert. Anders als bei allen übrigen Wegen liegt dieser Datensatz nicht auf dem eigenen Server von Scandora, sondern in Google Firestore in der Region Frankfurt (europe-west3). Er enthält die Quellidentität (den Anbieter, eine Kennung des Quellkontos sowie die Dateikennung und die Versionsmarke des Anbieters — oder, bei einer über die Dateiauswahl gewählten Datei, einen SHA-256-Fingerabdruck ihres Inhalts), Ihre Konto- und Profilkennung, den Importstatus, Status und Speicherreferenz jedes Ziels, an das der Import ausgeliefert wurde, sowie eine kurzlebige Gerätereservierung. Er enthält kein Seitenbild und keinen Dokumenttext. Die Speicherreferenz ist die Datei-URL des Ziels oder der Dateipfad der erzeugten PDF und kann daher den Dateinamen des Dokuments enthalten. Er wird in jedem Tarif bei jedem Import geschrieben; ein erneuter Import derselben Datei entfernt seinen Eintrag, und die Kontolöschung löscht sämtliche Einträge des Kontos.

Nimmt Scandora später einen weiteren Weg hinzu, auf dem Ihre Dokumentinhalte in Ihrem Auftrag verarbeitet werden, informieren wir Sie vor dessen Wirksamwerden in Textform und passen die Abschnitte 3 und 5 entsprechend an. Sie können vor dem Wirksamwerden widersprechen. Widersprechen Sie, schalten wir den neuen Weg für Ihr Konto nicht frei, und dieser AVV gilt für die oben genannten Wege unverändert fort. Können wir Ihnen die Leistung ohne diesen Weg nicht erbringen, teilen wir Ihnen das auf Ihren Widerspruch hin mit; Sie können dann diesen AVV und den zugrunde liegenden Vertrag zu dem Zeitpunkt kündigen, zu dem die Erweiterung wirksam geworden wäre. Sie nutzen Scandora zu keinem Zeitpunkt ohne einen wirksamen Vertrag nach Art. 28 DSGVO für Daten Ihrer Mandanten. Widersprechen Sie nicht, gilt dieser AVV ab diesem Zeitpunkt auch für den neuen Weg.

Ihre eigenen Kontodaten — Ihre E-Mail-Adresse, Ihr Name, Ihr Abonnement- und Abrechnungsdatensatz — liegen außerhalb dieses AVV. Für diese Daten ist Scandora Verantwortlicher aufgrund seines eigenen Vertrags mit Ihnen und nicht Ihr Auftragsverarbeiter. Dasselbe gilt für die E-Mail-Korrespondenz; siehe den Hinweis unter Abschnitt 5.

Wer ist Verantwortlicher für den Verlaufseintrag. Der Verlaufseintrag unterfällt diesem AVV vollständig — der extrahierte Dokumenttext, das Vorschaubild und die Metadaten des Eintrags (Titel, Datumsangaben, Seitenzahl, Dateigröße, Labels, Exportziele, extrahierte Felder). Sie entscheiden, welche Dokumente gescannt und warum sie aufbewahrt werden; Scandora speichert den Eintrag daher als Ihr Auftragsverarbeiter und nutzt ihn für keine eigenen Zwecke. Abschnitt 8 unserer Datenschutzerklärung führt Verlaufs-Metadaten unter der Verantwortlichenrolle von Scandora auf; das beschreibt die Nutzung ohne AVV, bei der die Nutzerin oder der Nutzer betroffene Person und nicht Verantwortlicher ist. Für die von Ihnen nach diesem AVV verarbeiteten Einträge gilt die hier festgelegte Auftragsverarbeiterrolle.

• Verantwortlicher: Sie (der Geschäftskunde / der Mandant Ihres Steuerberaters).
• Auftragsverarbeiter: Scandora — Farhad Sanaei seresht (Einzelunternehmen, Geschäftsbezeichnung „Scandora“), Burgunderweg 19G, 22453 Hamburg, Deutschland. Siehe unser Impressum.
• Unterauftragsverarbeiter: der Hosting-Anbieter des EU-Servers von Scandora (Hetzner), der zugrunde liegende Modellanbieter (Google Gemini / Vertex AI) sowie Google Firebase, das das Importregister speichert — siehe Abschnitt 5.

2. Gegenstand, Art, Zweck & Dauer

Die Verarbeitung dauert an, solange Sie Scandora nutzen, und endet mit Beendigung des zugrunde liegenden Vertrags. Je Weg gilt:

• Verwaltete KI — Ihr Gerät sendet Dokumentbilder, extrahierten Text, Prompts, Suchanfragen sowie, für den Chat, die auf dem Gerät ausgewählten Textpassagen sowie, wenn ein Dokument für die Suche indexiert wird, dessen extrahierten Text und KI-Beschreibung, in Passagen aufgeteilt, jeweils mit einer Kopfzeile aus Titel, Typ und Datum des Dokuments, direkt an den KI-Modellanbieter, unter Verwendung der in Abschnitt 1 beschriebenen kurzlebigen Zugangsberechtigung. Der Server von Scandora erhält oder speichert diese Inhalte zu keinem Zeitpunkt, auch nicht vorübergehend; der Modellanbieter verarbeitet sie, um KI-Analyseergebnisse zu erzeugen (z. B. Titel, Labels, extrahierte Felder, die Suchvektoren des geräteseitigen Index, Antworten bei Suche und Chat), und bewahrt sie, abgesehen von der unten beschriebenen Missbrauchsüberwachung, ebenfalls nicht über die Anfrage hinaus auf. Der stillgelegte Opt-in-KI-Suchindex nimmt keine neuen Daten mehr auf — die Suche läuft stattdessen auf Ihrem Gerät (Abschnitt 1). Verbliebene Daten aus der Zeit vor dieser Umstellung werden innerhalb von 30 Tagen nach Kontolöschung gelöscht und, soweit keine andere Frist gilt, nach 30 Tagen ohne Kontoaktivität.
• Cloud-Verlaufssynchronisation — der Auftragsverarbeiter speichert den in Abschnitt 3 beschriebenen Verlaufseintrag, damit Ihr Scan-Verlauf auf allen Ihren Geräten verfügbar bleibt. Aufbewahrung: Im Free-Tarif wird jeder Eintrag 180 Tage nach seiner Speicherung gelöscht; in einem kostenpflichtigen Tarif wird kein Eintrag gelöscht, solange das Abonnement läuft, und die Frist beginnt mit dessen Ende — 90 Tage (Pro) bzw. 180 Tage (Business). Wird innerhalb dieser Frist erneut ein Abonnement abgeschlossen, bleiben die Einträge erhalten. Einträge, die bei der Aktivierung dieser Löschung bereits gespeichert waren, laufen ab diesem Aktivierungsdatum. Ein von Ihnen gelöschter Eintrag wird mit dieser Löschung entfernt; bei Löschung des Kontos werden sämtliche Einträge dieses Kontos mitgelöscht, spätestens innerhalb von 30 Tagen.
• Serverseitiger DATEV-Export (in Vorbereitung — noch nicht freigeschaltet, siehe Abschnitt 1) — der Auftragsverarbeiter erhält die exportierten Buchungssätze und die dazugehörigen Dokumentbilder, stellt die DATEV-EXTF-ZIP-Datei zusammen und gibt sie an Sie zurück. Das geschieht vorübergehend: Weder die Buchungssätze noch die Bilder werden gespeichert.
• GoBD-Erfassungs- und Änderungsaufzeichnungen — der Auftragsverarbeiter speichert diese Aufzeichnungen als Nachweis, dass ein erfasstes Dokument unverändert ist und jede spätere Änderung nachvollziehbar bleibt. Sie werden weder beim Löschen des Verlaufseintrags noch bei Kontolöschung entfernt: Das Änderungsprotokoll ist auf Datenbankebene reine Anfügung, einzelne Einträge lassen sich nicht löschen, und die Erfassungsnachweise werden daneben aufbewahrt, damit die Herkunft eines Dokuments überprüfbar bleibt. Was eine Kontolöschung sehr wohl bewirkt, ist die Ersetzung der Kennungen darin: Nutzer- und Profilkennung werden durch eine Ersatzkennung ersetzt, und die geänderten Metadatenwerte sowie die Namen exportierter Dateien werden mit dem Konto entfernt; Prüfsumme, Zeitstempel und Hash-Verkettung bleiben erhalten, sodass die Aufzeichnungen ohne die Kennungen fortbestehen, mit denen sie geschrieben wurden. Das Ergebnis geben wir nicht als anonyme Daten aus: Der Verkettungs-Fingerabdruck jedes Eintrags wurde vor dieser Ersetzung berechnet, und die Prüfsumme des Erfassungsnachweises passt weiterhin zum Dokument selbst; wer dieses Dokument oder die ersetzten Kennungen besitzt, kann einen Eintrag daher weiterhin einer Person zuordnen. Warum wir sie aufbewahren, offen gesagt: Kein deutsches Gesetz verpflichtet uns zu ihrer Aufbewahrung. Die Aufzeichnungs- und Unveränderbarkeitspflichten nach den GoBD (§ 146 Abs. 4, § 147 AO, § 239 Abs. 3 HGB) treffen Sie bzw. Ihr Unternehmen, nicht uns, und § 257 HGB bindet Kaufleute, was Scandora — betrieben als nicht im Handelsregister eingetragenes Kleingewerbe — nicht ist. Wir stützen uns daher nicht auf Art. 28 Abs. 3 lit. g DSGVO, der dem Auftragsverarbeiter eine Aufbewahrung über das Vertragsende hinaus nur dort erlaubt, wo das Unionsrecht oder das Recht eines Mitgliedstaats die Speicherung vorschreibt. Wir bewahren diese Aufzeichnungen zu unserem eigenen Nachweiszweck auf und sind für diese Aufbewahrung Verantwortlicher (Art. 6 Abs. 1 lit. f DSGVO): Ein mit Scandora erfasstes Dokument soll so lange überprüfbar bleiben, wie Sie es vorlegen müssen könnten. Sie werden in jedem Tarif geschrieben und lassen sich nicht abschalten — wir stellen diese Aufbewahrung daher nicht als eine von Ihnen erteilte Weisung dar. Wie lange: Wir bewahren beide Aufzeichnungen zehn Jahre auf — die Frist, die das deutsche Recht für die eigenen Bücher und Aufzeichnungen eines Gewerbetreibenden vorsieht (§ 147 Abs. 1 Nr. 1, Abs. 3 AO) —, gerechnet ab dem Schluss des Kalenderjahres, in dem die Aufzeichnung entstanden ist (§ 147 Abs. 4 AO), und löschen sie nach deren Ablauf. Diese Frist ist eine von uns selbst gesetzte Obergrenze und keine uns treffende Pflicht — Abschnitt 11 unserer Datenschutzerklärung sagt dasselbe. Die Lösch- oder Rückgabepflicht aus Abschnitt 4 und die Löschmaßnahmen aus Abschnitt 7 erfassen diese beiden Aufzeichnungen während dieser Frist nicht. Eine Einschränkung, offen gesagt: Heute entfernt nichts diese Datensätze nach Fristablauf. Das Änderungsprotokoll ist auf Datenbankebene reine Anfügung, seine Einträge lassen sich überhaupt nicht löschen, und noch keine Routine löscht die Erfassungsnachweise nach Ablauf der Frist; die Aufzeichnungen bleiben daher derzeit darüber hinaus bestehen. Diesen Löschschritt zu bauen, steht auf unserer Liste; eine datumsgenaue Löschung, die wir nicht ausführen könnten, sagen wir nicht zu. Was wir dafür nicht leisten können: Die Datenbank weist jede Löschung eines Änderungsprotokolleintrags zurück und jede Änderung daran mit einer einzigen Ausnahme: einer Änderung, die unsere Kontolöschungs-Kennzeichnung trägt, die Verkettungswerte und die Zeitstempel unangetastet lässt und den Eintrag als geschwärzt kennzeichnet — diese Kennzeichnung setzt allein die Kontolöschungs-Routine, und ein so gekennzeichneter Eintrag wird nicht mehr gegen seinen eigenen Fingerabdruck geprüft, sodass eine über diesen einen Weg vorgenommene Änderung nicht als Manipulation ausgewiesen wird. Prüfsumme und Zeitstempel des Erfassungsnachweises sind einmalig beschreibbar; wir können daher einen einzelnen Eintrag weder berichtigen noch löschen und versprechen Ihnen keine frühere Löschung, die wir nicht ausführen könnten. Endet Ihre eigene Aufbewahrungspflicht früher, teilen Sie uns das in Textform mit: Wir nutzen die Aufzeichnungen dann ausschließlich zu diesem Nachweiszweck und zu keinem anderen (Art. 18 DSGVO) und vermerken Ihren Widerspruch (Art. 21 DSGVO). Wollen Sie diese Aufzeichnungen überhaupt nicht, kann Scandora für diese Dokumente nicht genutzt werden; Sie können diesen AVV und den zugrunde liegenden Vertrag nach dessen Bestimmungen kündigen. Siehe Abschnitt 8.
• Geräteübergreifendes Importregister — der Auftragsverarbeiter speichert je Import einen Registereintrag in Google Firestore (Frankfurt), damit dieselbe Quelldatei nicht auf mehreren Ihrer Geräte doppelt importiert wird. Der Eintrag wird für die Dauer Ihres Kontos aufbewahrt: Ein erneuter Import derselben Datei löscht ihn, und die Kontolöschung löscht sämtliche Einträge des Kontos. Dokumentinhalte enthält er nicht — die Feldliste steht in Abschnitt 3.

Missbrauchsüberwachung. Prompts, die über die verwaltete KI gesendet werden und die Googles automatische Sicherheitssysteme markieren, kann Google bis zu 90 Tage lang in der für die verwaltete KI genutzten Google-Cloud-Region (europe-west3, Frankfurt) speichern, ausschließlich zur Missbrauchsüberwachung; Google nutzt sie nicht zum Trainieren von Modellen.

3. Datenkategorien & Betroffene

Datenkategorien:

• Dokumentbilder und der daraus extrahierte Text sowie die Prompts und Fragen, die Sie zu einem Dokument stellen, die Suchanfragen, die Sie eingeben, und, für den Chat, die auf dem Gerät ausgewählten Textpassagen sowie, wenn ein Dokument für die Suche indexiert wird, dessen extrahierter Text und KI-Beschreibung, in Passagen aufgeteilt, jeweils mit einer Kopfzeile aus Titel, Typ und Datum des Dokuments — von Ihrem Gerät direkt an den Modellanbieter gesendet, nicht an Scandora (verwaltete KI).
• Der auf dem eigenen Server von Scandora gespeicherte Verlaufseintrag: der vollständige aus dem Dokument extrahierte Text (OCR-Text, gespeichert bis zu einer Obergrenze von 400.000 Zeichen) und ein kleines Base64-Vorschaubild der ersten Seite, zusammen mit den Metadaten des Eintrags — Titel, Erstellungsdatum, Seitenzahl, Dateigröße, Labels, die von Ihnen gewählten Exportziele und die von der KI extrahierten Felder (z. B. Betrag, Rechnungsnummer, Rechnungsdatum).
• Die Daten eines DATEV-Exports (vorübergehend; der Export ist in Vorbereitung und noch nicht freigeschaltet, siehe Abschnitt 1): die Buchungssätze — je Buchung Datum, Bruttobetrag, Soll-/Haben-Kennzeichen, Konto und Gegenkonto, DATEV-BU-Schlüssel, Rechnungsnummer, Buchungstext, Erkennungs-Konfidenzwert und Dokumentdateiname —, der Exportkopf (Beraternummer, Mandantennummer, Kontenrahmen, Beginn des Wirtschaftsjahres, exportierter Zeitraum, Name der exportierenden Person) sowie die zu diesen Buchungen gehörenden Dokumentbilder. Ein Buchungstext oder eine Rechnungsnummer kann Ihre eigenen Mandanten identifizieren.
• Die GoBD-Erfassungs- und Änderungsaufzeichnungen: je Erfassung eine SHA-256-Prüfsumme der erfassten Datei, die Erfassungsquelle (Kamera, Netzwerkscanner oder Datei-Upload), eine Gerätebeschreibung, die Nutzer- und Profilkennung und ein Server-Zeitstempel; je Dokumentereignis die Dokumentkennung, die Ereignisart (Erfassung, Bearbeitung, Export, Löschung), die Nutzerkennung, das handelnde Profil, ein Server-Zeitstempel, bei einem Export das von Ihnen gewählte Exportziel und, bei einer Bearbeitung, der alte und der neue Wert jedes geänderten Metadatenfeldes (Titel, Labels, Bruttobetrag, Rechnungsnummer, Rechnungsdatum). Kein Seitenbild und kein Dokumenttext.
• Der Importregistereintrag: der Quellanbieter, eine Kennung des Quellkontos, die Dateikennung und die Versionsmarke des Anbieters oder — bei einer über die Dateiauswahl gewählten Datei — ein SHA-256-Fingerabdruck ihres Inhalts, Ihre Konto- und Profilkennung, der Importstatus, Status und Speicherreferenz jedes Ziels, an das der Import ausgeliefert wurde, sowie eine kurzlebige Gerätereservierung. Kein Seitenbild und kein Dokumenttext; die Speicherreferenz ist die Datei-URL des Ziels oder der Dateipfad der erzeugten PDF und kann daher den Dateinamen des Dokuments enthalten.

All diese Daten können besondere Kategorien personenbezogener Daten (Art. 9 DSGVO) enthalten, soweit Sie solche Dokumente übermitteln.

Kategorien betroffener Personen: von Ihnen bestimmte Personen, deren Daten in den verarbeiteten Dokumenten enthalten sind (z. B. Ihre Mandanten, Kunden, Mitarbeitenden).

4. Pflichten des Auftragsverarbeiters

• Verarbeitung nur auf Ihre dokumentierte Weisung — es sei denn, wir sind nach dem Unionsrecht oder dem Recht eines Mitgliedstaats, dem wir unterliegen, zu einer anderen Verarbeitung verpflichtet; in diesem Fall teilen wir Ihnen diese rechtliche Anforderung vor der Verarbeitung mit, sofern das Recht diese Mitteilung nicht wegen eines wichtigen öffentlichen Interesses verbietet (Art. 28 Abs. 3 lit. a DSGVO).
• Unverzügliche Information an Sie, wenn eine Weisung nach unserer Auffassung gegen die DSGVO oder andere Datenschutzbestimmungen der Union oder der Mitgliedstaaten verstößt (Art. 28 Abs. 3 Unterabs. 2 DSGVO).
• Vertraulichkeitsverpflichtung der befugten Personen.
• Umsetzung der technischen und organisatorischen Maßnahmen in Abschnitt 7.
• Unterstützung bei Betroffenenanfragen und bei Ihren Pflichten nach Art. 32–36 DSGVO.
• Löschung oder Rückgabe der Daten nach Ihrer Wahl bei Vertragsende (Art. 28 Abs. 3 lit. g DSGVO). Die in Abschnitt 2 beschriebenen GoBD-Erfassungs- und Änderungsaufzeichnungen fallen nicht unter diese Pflicht: Wir bewahren sie als Verantwortlicher zu unserem eigenen Nachweiszweck für die dort genannte, von uns selbst gesetzte Zehnjahresfrist auf — keine uns treffende Speicherpflicht — und das Änderungsprotokoll lässt sich überdies überhaupt nicht Eintrag für Eintrag löschen.
• Bereitstellung der zur Nachweisführung erforderlichen Informationen und Ermöglichung von Überprüfungen.

5. Unterauftragsverarbeiter

Sie genehmigen die folgenden Unterauftragsverarbeiter für die in Abschnitt 1 beschriebene Verarbeitung. Für die Verarbeitung, die Scandora als Ihr Auftragsverarbeiter durchführt, ist diese Liste maßgeblich. Abschnitt 7 unserer Datenschutzerklärung verfolgt einen anderen Zweck: Er listet sämtliche Empfänger personenbezogener Daten auf, einschließlich der Anbieter, die wir als Verantwortlicher für eigene Zwecke einsetzen, etwa E-Mail (siehe den Hinweis unter dieser Tabelle). Soweit beide denselben Anbieter beschreiben, gilt für die auftragsverarbeitende Seite dieser AVV. Wir informieren über beabsichtigte Änderungen und räumen ein Widerspruchsrecht ein. Wir erlegen jedem Unterauftragsverarbeiter dieselben Datenschutzpflichten auf, die dieser AVV uns auferlegt (Art. 28 Abs. 4 DSGVO).

Der Modellanbieter (Google) ist Unterauftragsverarbeiter von Scandora auf dem Managed-AI-Pfad, den Ihr Gerät direkt mit einer kurzlebigen Zugangsberechtigung anfragt — der Server von Scandora sieht oder speichert die Dokumentinhalte auf diesem Weg nicht. Hetzner betreibt die Server, auf denen die Verlaufseinträge und die GoBD-Erfassungs- und Änderungsaufzeichnungen gespeichert sind; ein Zugriff auf die Anwendungsdaten zu eigenen Zwecken erfolgt nicht. Google Firebase steht in einer von der Modellanbieterrolle getrennten Rolle: Dort liegt ausschließlich das Importregister, keine Dokumentinhalte.

Außerhalb des Anwendungsbereichs dieses AVV — E-Mail. Zwei E-Mail-Flüsse betreffen Ihre Daten, liegen aber außerhalb dieses AVV, weil wir dort als Verantwortlicher für unseren eigenen Vertrag mit Ihnen handeln und nicht als Ihr Auftragsverarbeiter. Keiner der beiden enthält die unter diesem AVV verarbeiteten Dokumentinhalte:

• E-Mails, die wir Ihnen senden — Bestellbestätigungen sowie Konto- und Lifecycle-Nachrichten verlassen die Domain über Brevo (Sendinblue SAS, Frankreich; Versand und Speicherung in der EU, mit Zugriff aus den USA und Indien innerhalb der Kette von Brevo auf Grundlage der EU-Standardvertragsklauseln).
• E-Mails, die Sie uns senden — Nachrichten an support@, privacy@ oder [email protected] werden von Cloudflare in ein gewöhnliches Google-Verbraucherpostfach weitergeleitet, für das kein Auftragsverarbeitungsvertrag nach Art. 28 DSGVO verfügbar ist. Eine Nachricht aus dem Website-Kontaktformular landet im selben Postfach — unser eigener Server sendet sie über Brevo an [email protected], und Cloudflare leitet sie von dort weiter. Unsere Antwort verlässt die Domain über Brevo und zitiert Ihre Nachricht in der Regel.

Beide sind in Abschnitt 7 unserer Datenschutzerklärung aufgeführt. Wenn Sie uns Vertrags- oder personenbezogene Daten nicht per E-Mail senden möchten, nutzen Sie die Postanschrift in unserem Impressum.

6. Drittlandübermittlungen

Soweit ein Unterauftragsverarbeiter Daten außerhalb der EU/EWR (z. B. USA) verarbeitet, sind Übermittlungen durch die EU-Standardvertragsklauseln und/oder die Zertifizierung des Anbieters unter dem EU–US Data Privacy Framework abgesichert. Die verwaltete KI wird von Ihrem Gerät direkt angefragt, mit einer vom Server von Scandora ausgestellten kurzlebigen Zugangsberechtigung; der KI-Aufruf selbst wird in Deutschland verarbeitet, wenn der Frankfurter Regionaldienst (Vertex AI europe-west3) genutzt wird, ist für diesen Schritt keine Drittlandübermittlung und läuft zu keinem Zeitpunkt über den eigenen Server von Scandora. Die OAuth-Komponenten und der Endpunkt zur Ausstellung der Zugangsberechtigung von Scandora laufen auf dem eigenen Server von Scandora in Falkenstein, Deutschland. Der überwiegende Teil der nach diesem AVV gespeicherten Daten — die Verlaufseinträge und die GoBD-Erfassungs- und Änderungsaufzeichnungen — verbleibt auf den eigenen Servern von Scandora in Falkenstein, Deutschland. Die einzige Ausnahme ist das geräteübergreifende Importregister, das in Google Cloud Firestore in der Region europe-west3 (Frankfurt) gespeichert wird. Beide Orte liegen in Deutschland; keiner der beiden Speicher ist damit eine Drittlandübermittlung. Für die übrige Google-Cloud-Verarbeitung um diesen Speicher herum (Kontrollebene, Supportzugriff) gelten die EU-Standardvertragsklauseln und/oder die DPF-Zertifizierung von Google.

7. Technische & organisatorische Maßnahmen (TOM)

• Verschlüsselung in der Übertragung (TLS) auf jeder Verbindung zwischen App, unseren Servern und unseren Unterauftragsverarbeitern.
• Verschlüsselung der von Ihnen hinterlegten Integrations- und KI-Zugangsdaten pro Nutzer (AES-256-GCM). Für die übrigen nach diesem AVV gespeicherten Daten führen wir keine Verschlüsselung im Ruhezustand als Maßnahme an; sie sind durch die hier genannten Zugriffs-, Trennungs- und Hosting-Maßnahmen geschützt.
• Rollenbasierte Zugriffskontrolle und Protokollierung.
• Pseudonymisierung der Nutzerkennung (Firebase-UID).
• Die verwaltete KI wird von Ihrem Gerät direkt mit einer kurzlebigen Zugangsberechtigung angefragt; der Server von Scandora erhält oder speichert die Dokumentinhalte auf diesem Weg zu keinem Zeitpunkt.
• Gespeicherte Einträge werden je Nutzer und Profil getrennt gehalten und sind nur mit dem authentifizierten Token dieses Nutzers lesbar; das Löschen eines Verlaufseintrags entfernt ihn, und die Kontolöschung löscht sämtliche Verlaufseinträge und sämtliche Importregistereinträge des Kontos. Die GoBD-Erfassungs- und Änderungsaufzeichnungen werden nach Abschnitt 2 aufbewahrt und von dieser Löschung nicht erfasst; die Kontolöschung ersetzt stattdessen die Kennungen darin, sodass kein aufbewahrter Eintrag mehr die Kennungen des gelöschten Kontos enthält.
• Die OAuth-Komponenten, der Endpunkt zur Ausstellung der Zugangsberechtigung sowie sämtliche nach diesem AVV gespeicherten Daten werden auf dem eigenen Server von Scandora in Falkenstein, Deutschland, gehostet, mit zwei Ausnahmen, die beide in Deutschland bleiben: Der KI-Modellaufruf geht in die Google-Region europe-west3 (Frankfurt), und das Importregister wird in Google Cloud Firestore in derselben Region europe-west3 gespeichert.
• Regelmäßige Updates, Wiederherstellbarkeit und Belastbarkeit der Systeme.
• Verfahren zur regelmäßigen Überprüfung der Wirksamkeit der Maßnahmen.

8. Rechte des Verantwortlichen & der Betroffenen

Sie bleiben Herr der Daten. Betroffene Personen haben die Rechte aus Art. 15–22 DSGVO (Auskunft, Berichtigung, Löschung, Einschränkung, Datenübertragbarkeit, Widerspruch). Scandora unterstützt Sie bei deren Erfüllung. Zur Ausübung von Rechten oder bei Fragen wenden Sie sich an [email protected].

Wo diese Unterstützung begrenzt ist. Für die in Abschnitt 2 beschriebenen GoBD-Erfassungs- und Änderungsaufzeichnungen lässt die reine Anfügung nur einen Teil davon zu: Wir können Auskunft erteilen (Art. 15), die weitere Verwendung einschränken (Art. 18), die Einträge herausgeben (Art. 20) und einen Widerspruch vermerken (Art. 21), einen einzelnen Eintrag jedoch während der in Abschnitt 2 genannten Aufbewahrungsfrist weder berichtigen (Art. 16) noch löschen (Art. 17) — und, wie Abschnitt 2 offen sagt, entfernt sie heute auch nach Fristablauf nichts. Die Kontolöschung ersetzt die Kennungen in jedem Eintrag des Kontos, die Einträge bleiben aber personenbezogene Daten: Jeder Verkettungs-Fingerabdruck wurde vor dieser Ersetzung berechnet, und die Prüfsumme des Erfassungsnachweises passt weiterhin zum Dokument selbst. Für alle übrigen von diesem AVV erfassten Daten — Verlaufseinträge, Inhalte der verwalteten KI — ist die Unterstützung uneingeschränkt.

9. AVV herunterladen & abschließen

Laden Sie die unterschreibbare Vorlage herunter, füllen Sie die Parteienfelder aus, unterschreiben Sie und senden Sie ein Exemplar an [email protected]:

• Scandora-AVV-Vorlage (PDF)
• Scandora-AVV-Vorlage (DOCX)

Die unterschreibbare Vorlage enthält die Parteienfelder (Verantwortlicher/Auftragsverarbeiter), eine Anlage der Unterauftragsverarbeiter, die TOM und Unterschriftsfelder. Ihre Anlage 1 nennt dieselben Unterauftragsverarbeiter wie Abschnitt 5 oben — Hetzner Online GmbH (Falkenstein, Deutschland), Google (Gemini API / Vertex AI) (Frankfurt, Deutschland — Vertex AI europe-west3 für KI-Analyse, Suche und Chat, von Ihrem Gerät direkt angefragt; übrige Google-Cloud-Verarbeitung auf Grundlage der EU-Standardvertragsklauseln / des DPF) und Google (Firebase / Cloud Firestore) (Frankfurt, Deutschland — europe-west3, ausschließlich Importregister) — und bezeichnet diese Liste als die für die auftragsverarbeitende Seite maßgebliche, bezogen auf dieselben fünf Wege. Beide Dateien werden aus einer Quelldatei erzeugt und tragen daher stets denselben Text und den Versionsstempel Fassung / Version: 2026-10-03 (Rev. 8), sodass erkennbar bleibt, welche Fassung unterzeichnet wurde.

10. Kontakt

Maßgeblich ist die deutsche Fassung dieses Auftragsverarbeitungsvertrags.