KI-gestützte Belegerkennung, Bankabgleich und Steuerberater-Übergabe in einer Plattform.
Kontorio
Rechtliches

Auftragsverarbeitungsvereinbarung (AVV)

Initialer Seed v0.1 — AVV nach Art. 28 DSGVO inkl. TOM-Anlage (Hetzner, AWS S3, Resend).

Version: v1Gültig ab: 15.6.2026SHA-256: 8c5e54b30507ccd6…

Kontorio — Vereinbarung zur Auftragsverarbeitung (AVV) nach Art. 28 DSGVO + TOM-Anlage

Version: v0.1 Entwurf
Stand: 21.05.2026
Dokumenttyp: Arbeitsentwurf / juristischer Strukturentwurf / technische Datenschutzgrundlage
Produkt: Kontorio
Geltungsbereich: Kontorio SaaS-Plattform, Portal, Admin-Bereich, Backend, Belegverarbeitung, OCR/KI, E-Mail-Belegimport, Buchhaltungsdaten, Nutzer- und Mandantendaten
Status: Nicht final. Vor Veröffentlichung und produktiver Verwendung zwingend durch Datenschutz-/IT-Rechtsberatung prüfen lassen.

0. Wichtiger Hinweis

Dieses Dokument ist ein Arbeitsentwurf für eine Auftragsverarbeitungsvereinbarung nach Art. 28 DSGVO einschließlich einer technisch-organisatorischen Maßnahmenanlage für Kontorio. Es ist auf den geplanten Kontorio-Stack und die bisherige Produktarchitektur zugeschnitten.

Dieser Entwurf ersetzt keine Rechtsberatung, keine Datenschutzberatung, keine steuerliche Beratung und keine GoBD-Prüfung. Vor produktiver Nutzung müssen insbesondere folgende Punkte fachlich und juristisch geprüft werden:

  • korrekte Unternehmensdaten des Anbieters,
  • vollständige Unterauftragsverarbeiterliste,
  • tatsächliche Hosting-, Datenbank-, Storage-, E-Mail-, KI-, Monitoring- und Banking-Anbieter,
  • Drittlandtransfers und Standardvertragsklauseln,
  • Datenschutz-Folgenabschätzung,
  • Lösch- und Aufbewahrungskonzept,
  • GoBD-Verfahrensdokumentation,
  • technische Umsetzung der TOMs,
  • tatsächliche Rollenverteilung zwischen Kunde, Kontorio, Steuerberater, Banking-Provider und KI-/OCR-Dienstleistern.

Merksatz: Eine AVV ist kein Feigenblatt. Wenn die Technik dahinter nicht stimmt, ist das Papier nur Tapete auf feuchter Wand.

1. Recherche- und Rechtsgrundlagenstand

Dieser Entwurf berücksichtigt insbesondere:

  • Art. 28 DSGVO: Auftragsverarbeiter, Mindestinhalte der Vereinbarung, Weisungsbindung, Unterauftragsverarbeiter, Unterstützungspflichten, Löschung/Rückgabe und Nachweispflichten.
  • Art. 32 DSGVO: Sicherheit der Verarbeitung, insbesondere Verschlüsselung, Pseudonymisierung, Vertraulichkeit, Integrität, Verfügbarkeit, Belastbarkeit und Wiederherstellbarkeit.
  • Art. 33/34 DSGVO: Meldung und Benachrichtigung bei Verletzungen des Schutzes personenbezogener Daten.
  • Art. 5 DSGVO: Grundsätze wie Rechtmäßigkeit, Zweckbindung, Datenminimierung, Richtigkeit, Speicherbegrenzung, Integrität und Vertraulichkeit.
  • Art. 25 DSGVO: Datenschutz durch Technikgestaltung und datenschutzfreundliche Voreinstellungen.
  • Art. 30 DSGVO: Verzeichnis von Verarbeitungstätigkeiten.
  • Art. 35 DSGVO: Datenschutz-Folgenabschätzung bei voraussichtlich hohem Risiko.
  • DSK-Kurzpapier zur Auftragsverarbeitung als Orientierung.
  • BfDI-Muster zur Auftragsverarbeitung als Strukturreferenz.
  • OpenAI Data Processing Addendum / Enterprise Privacy für die spätere KI-/OpenAI-Einordnung.
  • Kontorio-Projektentscheidungen zu Hetzner Backend, Vercel Frontends, Neon/PostgreSQL, Redis/BullMQ, AWS S3, Resend, OpenAI/OCR, Mandantentrennung, Audit und Supportzugriff.

Arbeitslinks für juristische Prüfung:

2. Dokumentstruktur

Dieses Dokument besteht aus:

  1. Hauptteil AVV — Vertragliche Regelungen zwischen Kunde und Kontorio.
  2. Anlage 1: Beschreibung der Verarbeitung — Gegenstand, Dauer, Art und Zweck, Datenarten, Betroffene.
  3. Anlage 2: Technisch-organisatorische Maßnahmen (TOMs) — Sicherheitsmaßnahmen nach Art. 32 DSGVO.
  4. Anlage 3: Unterauftragsverarbeiterliste — Arbeitsstand, noch final zu prüfen.
  5. Anlage 4: Lösch-, Rückgabe- und Aufbewahrungskonzept — Grundlogik für Vertragsende und laufenden Betrieb.
  6. Anlage 5: Incident-, Melde- und Eskalationsprozess — Datenschutzverletzungen und Security Incidents.
  7. Anlage 6: KI-/OCR-spezifische Zusatzmaßnahmen — OpenAI/OCR, Datenminimierung, Human Review.
  8. Anlage 7: Go-Live-Checkliste — Was vor produktivem Einsatz noch abgehakt werden muss.

Hauptteil: Vereinbarung zur Auftragsverarbeitung

3. Parteien

3.1 Auftraggeber

Der Auftraggeber ist der jeweilige Kunde, der Kontorio als SaaS-Plattform nutzt und im Rahmen des Hauptvertrags personenbezogene Daten in Kontorio verarbeitet oder durch Kontorio verarbeiten lässt.

Platzhalter Auftraggeber:
Name / Firma: [Kundendaten]
Adresse: [Kundendaten]
Vertreten durch: [Kundendaten]
E-Mail für Datenschutzkommunikation: [Kundendaten]

3.2 Auftragnehmer

Der Auftragnehmer ist der Betreiber der Kontorio-Plattform.

Platzhalter Auftragnehmer:
Firma: [Kontorio Betreiber-Gesellschaft eintragen]
Adresse: [Adresse eintragen]
Vertreten durch: [Vertretungsberechtigte Person eintragen]
E-Mail Datenschutz: [datenschutz@kontorio.de oder andere Adresse eintragen]
E-Mail Support: [support@kontorio.de oder andere Adresse eintragen]
Website: https://kontorio.de

3.3 Verhältnis zum Hauptvertrag

Diese AVV ergänzt den SaaS-Hauptvertrag, die AGB/Nutzungsbedingungen und die produktbezogenen Datenschutzinformationen von Kontorio. Bei Widersprüchen zwischen dieser AVV und sonstigen vertraglichen Regelungen gehen die datenschutzrechtlich zwingenden Regelungen dieser AVV vor, soweit die Verarbeitung personenbezogener Daten im Auftrag betroffen ist.

4. Gegenstand der Vereinbarung

Kontorio stellt dem Auftraggeber eine cloudbasierte Buchhaltungs- und Dokumentenplattform bereit. Im Rahmen der Nutzung verarbeitet Kontorio personenbezogene Daten, die der Auftraggeber, seine Nutzer, seine Mitarbeiter, seine Kunden, Lieferanten, Steuerberater oder sonstige Dritte in die Plattform einbringen oder die im Rahmen der Plattformnutzung entstehen.

Die Verarbeitung umfasst insbesondere:

  • Nutzerverwaltung und Authentifizierung,
  • Mandanten-/Firmenverwaltung,
  • Rollen- und Rechteverwaltung,
  • Belegupload,
  • Belegimport per E-Mail,
  • Speicherung von Belegen und Dokumentversionen,
  • OCR- und KI-gestützte Extraktion und Klassifizierung,
  • Buchungsvorschläge und Statusverarbeitung,
  • Banktransaktionsverarbeitung nach späterer Aktivierung entsprechender Banking-Module,
  • Export- und Steuerberater-Workflows,
  • Protokollierung und Audit-Logs,
  • Support- und Fehlerdiagnose,
  • technische Betriebs-, Sicherheits- und Monitoringprozesse.

Kontorio handelt dabei, soweit der Auftraggeber über Zweck und Mittel der Verarbeitung seiner Mandanten-, Beleg-, Buchhaltungs-, Bank-, Mitarbeiter-, Kunden-, Lieferanten- und Steuerdaten entscheidet, als Auftragsverarbeiter im Sinne von Art. 4 Nr. 8 DSGVO.

Kontorio kann für eigene Zwecke daneben eigene Verantwortlichkeit besitzen, insbesondere bei:

  • Vertragsverwaltung,
  • Abrechnung,
  • Kundenkommunikation,
  • Missbrauchsabwehr,
  • interner Sicherheit,
  • gesetzlichen Nachweispflichten,
  • eigener Website-Nutzung.

Diese eigenen Verantwortlichkeitsbereiche werden in den Datenschutzhinweisen gesondert beschrieben und sind nicht Kern dieser AVV.

5. Dauer der Verarbeitung

Diese AVV gilt für die Dauer des Hauptvertrags zwischen Auftraggeber und Auftragnehmer. Sie endet grundsätzlich mit vollständiger Beendigung des Hauptvertrags und Abschluss der vereinbarten Löschungs- oder Rückgabeprozesse.

Soweit gesetzliche Aufbewahrungs-, Nachweis-, Sicherheits-, Missbrauchsabwehr- oder Dokumentationspflichten bestehen, dürfen bestimmte Daten nach Maßgabe des geltenden Rechts und des vereinbarten Lösch- und Aufbewahrungskonzepts länger gespeichert werden.

Für buchhaltungs- und steuerrelevante Daten ist besonders zu beachten: Kontorio stellt technische Speicher-, Export- und Archivfunktionen bereit. Die rechtliche Verantwortung für Vollständigkeit, Richtigkeit, Aufbewahrungspflichten und steuerliche Bewertung verbleibt beim Auftraggeber, soweit nicht ausdrücklich anders vereinbart.

6. Art und Zweck der Verarbeitung

6.1 Zwecke

Die Verarbeitung erfolgt zu folgenden Zwecken:

  1. Bereitstellung der Kontorio-SaaS-Plattform.
  2. Verwaltung von Kundenkonten, Firmen, Mandanten und Nutzern.
  3. Authentifizierung, Session-Verwaltung, Rollen und Berechtigungen.
  4. Belegaufnahme über Upload, E-Mail-Import und spätere Schnittstellen.
  5. Speicherung, Versionierung und Wiederauffindbarkeit von Dokumenten.
  6. Extraktion von Daten aus Belegen mittels OCR und optional KI.
  7. Erstellung von Buchungsvorschlägen und Aufgabenstatus.
  8. Unterstützung bei Belegprüfung, Zahlungsabgleich, Buchhaltungs- und Exportprozessen.
  9. Steuerberater-Zugänge und Freigabe-/Review-Prozesse.
  10. Technische Protokollierung, Sicherheitsüberwachung, Fehlerbehebung und Missbrauchsabwehr.
  11. Support, soweit vom Auftraggeber angefragt oder freigegeben.
  12. Erfüllung gesetzlicher, vertraglicher und technischer Nachweispflichten.

6.2 Art der Verarbeitung

Die Verarbeitung umfasst insbesondere:

  • Erheben,
  • Erfassen,
  • Organisieren,
  • Ordnen,
  • Speichern,
  • Anpassen,
  • Auslesen,
  • Abfragen,
  • Verwenden,
  • Offenlegen durch Übermittlung an berechtigte Nutzer oder Unterauftragsverarbeiter,
  • Abgleichen,
  • Verknüpfen,
  • Einschränken,
  • Löschen,
  • Vernichten,
  • Exportieren,
  • Protokollieren.

7. Weisungsbindung

7.1 Grundsatz

Kontorio verarbeitet personenbezogene Daten des Auftraggebers ausschließlich auf dokumentierte Weisung des Auftraggebers, sofern Kontorio nicht durch Unionsrecht oder nationales Recht zu einer Verarbeitung verpflichtet ist.

Die Weisungen ergeben sich insbesondere aus:

  • dem Hauptvertrag,
  • dieser AVV,
  • den Produktkonfigurationen des Auftraggebers,
  • Rollen- und Rechtevergaben durch den Auftraggeber,
  • aktiver Nutzung der Plattformfunktionen,
  • Supportfreigaben,
  • schriftlichen oder elektronisch dokumentierten Einzelweisungen.

7.2 Weisungen innerhalb der Plattform

Als Weisungen gelten insbesondere Handlungen berechtigter Nutzer des Auftraggebers innerhalb der Plattform, zum Beispiel:

  • Upload eines Belegs,
  • Aktivierung einer E-Mail-Empfangsadresse,
  • Einladung eines Nutzers oder Steuerberaters,
  • Zuweisung von Rollen,
  • Start eines Exports,
  • Freigabe eines Belegs,
  • Bestätigung oder Änderung eines Buchungsvorschlags,
  • Aktivierung einer Integration,
  • Lösch- oder Exportanfrage,
  • Freigabe eines Supportzugriffs.

7.3 Unzulässige Weisungen

Kontorio informiert den Auftraggeber, wenn Kontorio der Ansicht ist, dass eine Weisung gegen Datenschutzrecht, Sicherheitsvorgaben oder gesetzliche Pflichten verstößt. Kontorio darf die Ausführung einer offensichtlich rechtswidrigen oder sicherheitsgefährdenden Weisung aussetzen, bis die Weisung geklärt ist.

Beispiele:

  • Aufforderung zur Offenlegung von Daten eines fremden Mandanten,
  • Umgehung von Rollen- oder Zugriffskontrollen,
  • Löschung gesetzlich aufzubewahrender Daten ohne geklärten Rechtsgrund,
  • Deaktivierung notwendiger Sicherheitsprotokollierung,
  • Speicherung von echten Secrets im Frontend oder in unsicheren Kanälen,
  • Übertragung von Rohbelegen an KI-Dienste ohne Zweck, Rechtsgrundlage und Dokumentation.

8. Vertraulichkeit

Kontorio verpflichtet alle mit der Verarbeitung personenbezogener Daten befassten Personen auf Vertraulichkeit, soweit sie nicht bereits einer gesetzlichen Verschwiegenheitspflicht unterliegen.

Die Vertraulichkeitspflicht umfasst insbesondere:

  • Nutzer-, Firmen- und Mandantendaten,
  • Belege und Dokumentinhalte,
  • Bank- und Transaktionsdaten,
  • steuerliche Daten,
  • personenbezogene Daten in OCR-/KI-Ergebnissen,
  • Supportinformationen,
  • Logs und Auditdaten,
  • Zugangsdaten, Secrets und technische Konfigurationsinformationen.

Kontorio stellt sicher, dass interne Mitarbeiter und beauftragte Dienstleister nur in dem Umfang Zugriff erhalten, der für ihre jeweilige Aufgabe erforderlich ist.

9. Sicherheit der Verarbeitung

Kontorio trifft geeignete technische und organisatorische Maßnahmen nach Art. 32 DSGVO. Die Maßnahmen sind in Anlage 2 beschrieben.

Die Maßnahmen berücksichtigen insbesondere:

  • Art, Umfang, Umstände und Zwecke der Verarbeitung,
  • Sensibilität von Buchhaltungs-, Beleg-, Bank- und Steuerdaten,
  • Risiko unbefugter Offenlegung,
  • Risiko falscher Mandantenzuordnung,
  • Risiko von Datenverlust,
  • Risiko durch KI-/OCR-Verarbeitung,
  • Risiko durch E-Mail-Belegimport,
  • Risiko durch Supportzugriffe,
  • Stand der Technik und Implementierungskosten.

Kontorio überprüft und verbessert die TOMs regelmäßig. Wesentliche Änderungen werden dokumentiert und dürfen das bisherige Schutzniveau nicht unangemessen absenken.

10. Mandantentrennung und Zugriffskontrolle

Kontorio verarbeitet Kundendaten mandantenbezogen. Ein Nutzer erhält nur Zugriff auf Firmen/Mandanten, für die eine gültige Mitgliedschaft, Rolle und Berechtigung besteht.

Grundsätze:

  • User ist Login-Identität.
  • Tenant ist Firma/Mandant.
  • Membership ist Zugriff.
  • Subscription ist Abrechnung je Firma.
  • Backend-Guards prüfen Session, User, Tenant, Membership, Rolle, Permission und Ressourceneigentum.
  • tenantId wird nicht blind aus dem Frontend oder Request-Body vertraut.
  • Frontend-Menüs sind Komfort, aber keine Sicherheitsbarriere.
  • Admin-Zugriff auf Beleginhalte ist nur mit gesonderter Berechtigung, Supportfreigabe, Zweckbindung und Audit zulässig.

Diese Regeln sind Kernbestandteil der Kontorio-Sicherheitsarchitektur und keine kosmetische Tabellenfilterei.

11. Unterauftragsverarbeiter

11.1 Einsatz von Unterauftragsverarbeitern

Kontorio darf Unterauftragsverarbeiter einsetzen, soweit diese zur Erbringung der Plattformleistungen, zum Betrieb, zur Speicherung, Kommunikation, Sicherheit, Fehleranalyse, OCR/KI-Verarbeitung oder sonstigen vertraglich vorgesehenen Leistungen erforderlich sind.

Kontorio stellt sicher, dass Unterauftragsverarbeiter vertraglich verpflichtet werden, ein angemessenes Datenschutzniveau einzuhalten und mindestens gleichwertige Datenschutzpflichten zu übernehmen, soweit sie personenbezogene Daten im Auftrag verarbeiten.

11.2 Informationspflicht und Widerspruch

Kontorio informiert den Auftraggeber über die jeweils eingesetzten Unterauftragsverarbeiter. Neue Unterauftragsverarbeiter oder wesentliche Änderungen werden rechtzeitig bekanntgegeben, zum Beispiel über:

  • Unterauftragsverarbeiterliste im Portal,
  • E-Mail an den hinterlegten Verantwortlichen,
  • Vertrags-/Datenschutzbereich,
  • Changelog oder Benachrichtigungssystem.

Der Auftraggeber kann aus wichtigem datenschutzrechtlichem Grund widersprechen. Wird ein Widerspruch nicht gelöst und ist der Unterauftragsverarbeiter für die Leistungserbringung erforderlich, können die Parteien das betroffene Modul oder den Vertrag nach Maßgabe des Hauptvertrags beenden.

11.3 Drittlandtransfers

Soweit personenbezogene Daten in Drittländer außerhalb der EU/des EWR übertragen werden oder ein Zugriff von dort möglich ist, stellt Kontorio geeignete Garantien nach Art. 44 ff. DSGVO sicher, insbesondere durch:

  • Angemessenheitsbeschluss,
  • EU-Standardvertragsklauseln,
  • Transfer Impact Assessment,
  • zusätzliche technische und organisatorische Maßnahmen,
  • Dokumentation im Vendor-Dossier.

Dies betrifft besonders KI-, Monitoring-, Kommunikations-, Cloud- oder Supportanbieter mit Konzern- oder Dienstleisterbezug außerhalb der EU/des EWR.

12. Unterstützungspflichten von Kontorio

Kontorio unterstützt den Auftraggeber nach angemessenem Maß und soweit möglich bei der Erfüllung seiner datenschutzrechtlichen Pflichten, insbesondere bei:

  • Auskunftsanfragen betroffener Personen,
  • Berichtigung,
  • Löschung,
  • Einschränkung der Verarbeitung,
  • Datenübertragbarkeit,
  • Widerspruchs- und Beschwerdeprozessen,
  • Datenschutz-Folgenabschätzungen,
  • Konsultation der Aufsichtsbehörde,
  • Nachweis technischer und organisatorischer Maßnahmen,
  • Meldung von Datenschutzverletzungen,
  • Export oder Rückgabe von Daten.

Kontorio kann für aufwändige Unterstützungsleistungen eine angemessene Vergütung verlangen, soweit die Unterstützung nicht bereits Bestandteil des vereinbarten Leistungsumfangs ist und der Aufwand durch den Auftraggeber verursacht wurde.

13. Betroffenenrechte

Kontorio unterstützt den Auftraggeber bei der Bearbeitung von Betroffenenrechten, soweit Kontorio personenbezogene Daten im Auftrag verarbeitet.

Kontorio beantwortet Anfragen betroffener Personen zu Auftraggeberdaten grundsätzlich nicht eigenständig, sondern leitet diese an den Auftraggeber weiter, sofern die Anfrage eindeutig einem Auftraggeber zugeordnet werden kann.

Ausnahmen gelten, wenn Kontorio selbst Verantwortlicher ist, zum Beispiel bei eigenen Vertrags-, Abrechnungs-, Support- oder Website-Daten.

14. Datenschutzverletzungen und Sicherheitsvorfälle

Kontorio informiert den Auftraggeber unverzüglich, wenn Kontorio eine Verletzung des Schutzes personenbezogener Daten feststellt, die Daten des Auftraggebers betrifft.

Die Information soll, soweit verfügbar, enthalten:

  • Art des Vorfalls,
  • betroffene Systeme,
  • betroffene Datenkategorien,
  • betroffene Personen oder Personengruppen,
  • vermutete Ursache,
  • Zeitpunkt der Feststellung,
  • bereits ergriffene Maßnahmen,
  • empfohlene Maßnahmen für den Auftraggeber,
  • Ansprechpartner für Rückfragen,
  • Einschätzung, ob eine Meldung nach Art. 33/34 DSGVO erforderlich sein kann.

Kontorio dokumentiert Sicherheitsvorfälle intern und unterstützt den Auftraggeber bei notwendigen Meldungen an Aufsichtsbehörden oder Betroffene.

15. Löschung und Rückgabe

Nach Beendigung des Hauptvertrags löscht oder gibt Kontorio personenbezogene Daten des Auftraggebers nach Wahl und Weisung des Auftraggebers zurück, soweit keine gesetzlichen, vertraglichen oder berechtigten Aufbewahrungspflichten entgegenstehen.

Kontorio stellt geeignete Exportmöglichkeiten bereit, zum Beispiel:

  • Belegexport,
  • Datenexport,
  • Audit-/Protokollexport nach Berechtigung,
  • Rechnungs-/Buchungsdatenexport,
  • DATEV- oder CSV-Export, soweit implementiert.

Nach Ablauf definierter Rückgabe- und Übergangsfristen werden Daten gelöscht oder anonymisiert, soweit keine Aufbewahrungspflichten bestehen.

Details regelt Anlage 4.

16. Nachweise und Audits

Kontorio stellt dem Auftraggeber geeignete Informationen zur Verfügung, um die Einhaltung der Pflichten aus dieser AVV nachzuweisen. Dazu können gehören:

  • aktuelle TOM-Anlage,
  • Unterauftragsverarbeiterliste,
  • Sicherheits- und Datenschutzdokumentation,
  • Zertifizierungen oder Prüfberichte von Unterauftragsverarbeitern, soweit verfügbar,
  • Auditberichte oder Zusammenfassungen,
  • Dokumentation von Sicherheitsprozessen,
  • Nachweise über Backup-/Restore-Prozesse,
  • Informationen zu Incident Response und Supportzugriffen.

Vor-Ort-Audits beim Auftragnehmer oder bei Unterauftragsverarbeitern sind nur nach vorheriger Abstimmung, angemessener Frist, Wahrung von Geschäftsgeheimnissen, Sicherheitsanforderungen und Verhältnismäßigkeit zulässig. Kontorio kann statt einzelner Kundenaudits vorrangig standardisierte Nachweise, Zertifizierungen, Prüfberichte oder externe Auditdokumente bereitstellen.

17. Änderung der TOMs und Produktarchitektur

Kontorio darf technische und organisatorische Maßnahmen, Infrastruktur, Anbieter und Produktmodule weiterentwickeln, sofern das vereinbarte Datenschutzniveau nicht wesentlich unterschritten wird.

Wesentliche Änderungen werden dokumentiert. Bei Änderungen mit relevantem Datenschutzrisiko informiert Kontorio den Auftraggeber nach Maßgabe dieser AVV oder der Datenschutz-/Subprozessoreninformationen.

Beispiele wesentlicher Änderungen:

  • Wechsel des Haupt-Hostings,
  • Wechsel des Object-Storage-Anbieters,
  • Einführung neuer KI-/OCR-Anbieter,
  • Einführung produktiver Banking-Provider,
  • Änderung der Datenregion für Belege,
  • Einführung neuer Supportzugriffsmodelle,
  • grundlegende Änderung der Mandantentrennung.

18. Verantwortlichkeit des Auftraggebers

Der Auftraggeber bleibt Verantwortlicher für die Rechtmäßigkeit der Verarbeitung seiner Daten. Er ist insbesondere verantwortlich für:

  • Rechtsgrundlagen der Verarbeitung,
  • Information betroffener Personen,
  • Vollständigkeit und Richtigkeit der hochgeladenen Daten,
  • Zulässigkeit von Beleg-, Bank-, Mitarbeiter-, Kunden- und Lieferantendaten,
  • Rollen- und Rechtevergabe innerhalb seiner Organisation,
  • Einladung von Steuerberatern und externen Nutzern,
  • Prüfung von KI-/OCR- und Buchungsvorschlägen,
  • steuerliche und handelsrechtliche Einordnung,
  • gesetzliche Aufbewahrungspflichten,
  • Entscheidung über Löschung, Export und Archivierung.

Kontorio stellt Werkzeuge bereit. Kontorio wird dadurch nicht zum Steuerberater, Buchhalter, Wirtschaftsprüfer oder Verantwortlichen für die Buchhaltung des Auftraggebers.

19. Schlussbestimmungen

Sollten einzelne Bestimmungen dieser AVV unwirksam sein oder werden, bleibt die Wirksamkeit der übrigen Bestimmungen unberührt. Die Parteien werden die unwirksame Regelung durch eine wirksame Regelung ersetzen, die dem datenschutzrechtlichen und wirtschaftlichen Zweck möglichst nahekommt.

Änderungen und Ergänzungen dieser AVV bedürfen mindestens der Textform, sofern nicht gesetzlich eine strengere Form vorgeschrieben ist. Elektronische Zustimmung im Kundenkonto, Vertragsbereich oder per Signaturdienst kann ausreichen, sofern der Nachweis dauerhaft gespeichert wird.

Anlage 1 — Beschreibung der Verarbeitung

A1.1 Gegenstand

Bereitstellung und Betrieb der Kontorio-SaaS-Plattform für Buchhaltungs-, Beleg-, Dokumenten-, OCR-/KI-, Banking-, Steuerberater-, Export-, Audit- und Supportprozesse.

A1.2 Dauer

Für die Dauer des Hauptvertrags einschließlich Testphase, aktiver Vertragslaufzeit, Kündigungs-/Exportphase, gesetzlicher Aufbewahrungsfristen und technischer Lösch-/Backupfristen.

A1.3 Verarbeitungskategorien

Nutzer- und Accountdaten

  • Name,
  • E-Mail-Adresse,
  • Passwort-Hash,
  • Rollen,
  • Berechtigungen,
  • Einladungsstatus,
  • MFA-/Passkey-Metadaten,
  • Sessiondaten,
  • Login-Historie,
  • IP-Adresse,
  • User-Agent,
  • Spracheinstellungen,
  • Benachrichtigungseinstellungen.

Firmen- und Mandantendaten

  • Firmenname,
  • Rechtsform,
  • Anschrift,
  • Ansprechpartner,
  • Kundennummer,
  • Steuernummer,
  • Umsatzsteuer-ID,
  • Finanzamt,
  • Geschäftsjahr,
  • Gewinnermittlungsart,
  • Kontenrahmenauswahl,
  • Tarif-/Modulstatus,
  • Rechnungsdaten des Auftraggebers.

Beleg- und Dokumentdaten

  • Originalbelege,
  • Rechnungen,
  • Quittungen,
  • Lieferscheine,
  • Verträge,
  • Zahlungsnachweise,
  • Reisekostenbelege,
  • Bewirtungsbelege,
  • E-Mail-Anhänge,
  • Dateiname,
  • MIME-Type,
  • Dateigröße,
  • sha256-Hash,
  • Storage-Key,
  • Dokumentversionen,
  • Upload-Zeitpunkt,
  • Quelle des Uploads,
  • Verarbeitungsstatus.

OCR- und KI-Daten

  • extrahierter Text,
  • strukturierte Felder wie Lieferant, Kunde, Datum, Betrag, Netto, Brutto, Umsatzsteuer, Rechnungsnummer, IBAN,
  • Klassifizierungsvorschläge,
  • Buchungsvorschläge,
  • Confidence Scores,
  • Prompt-/Modellversionen,
  • Regelversionen,
  • Review-Entscheidungen,
  • Ablehnungs- oder Korrekturgründe,
  • Audit-Metadaten.

Buchhaltungs- und Steuerdaten

  • Kategorien,
  • Konten,
  • Buchungsvorschläge,
  • Buchungssätze,
  • Soll-/Haben-Zeilen,
  • Steuerregeln,
  • Umsatzsteuer-/Vorsteuerinformationen,
  • Zahlungsstatus,
  • Kostenstellen und Projekte, soweit aktiviert,
  • Exportdaten,
  • Steuerberaterkommentare,
  • Periodenstatus.

Bank- und Zahlungsdaten nach Aktivierung entsprechender Module

  • Bankverbindungen,
  • IBAN,
  • BIC,
  • Bankname,
  • Kontosalden,
  • Transaktionen,
  • Verwendungszweck,
  • Zahlungsdatum,
  • Betrag,
  • Gegenpartei,
  • Matching-Status,
  • Consent-Status,
  • Provider-IDs.

Hinweis: Kontorio soll keine eigenen Bankpasswörter speichern. Bankdaten werden über regulierte oder geeignete Anbieter und mit Consent verarbeitet, sobald Banking produktiv aktiviert wird.

E-Mail-Belegimportdaten

  • Inbound-Mailbox-Adresse,
  • Absenderadresse,
  • Empfängeradresse,
  • Provider-Mail-ID,
  • Betreff,
  • technische Header, soweit erforderlich,
  • Anhänge,
  • Download-Status,
  • Quarantäne-Status,
  • Whitelist-/Allowed-Sender-Regeln,
  • Zustell- und Fehlerstatus.

Support- und Auditdaten

  • Supporttickets,
  • interne Notizen,
  • Supportfreigaben,
  • Supportzugriffszeitraum,
  • Admin-Aktionen,
  • Audit-Events,
  • Sicherheitsereignisse,
  • Logdaten,
  • Fehlerberichte,
  • Queue-/Jobstatus,
  • Webhookstatus.

A1.4 Betroffenengruppen

  • Nutzer des Auftraggebers,
  • Inhaber/Geschäftsführer,
  • Mitarbeiter des Auftraggebers,
  • Steuerberater und Kanzleimitarbeiter,
  • Kunden des Auftraggebers,
  • Lieferanten des Auftraggebers,
  • Ansprechpartner von Geschäftspartnern,
  • Zahlungspflichtige und Zahlungsempfänger,
  • Personen auf Belegen, Reisekosten, Bewirtungen, Lohnunterlagen oder sonstigen Dokumenten,
  • Support- und Administrationsnutzer.

A1.5 Besondere Kategorien personenbezogener Daten

Kontorio ist nicht dafür vorgesehen, besondere Kategorien personenbezogener Daten nach Art. 9 DSGVO gezielt zu verarbeiten. Solche Daten können aber unbeabsichtigt in Belegen, Notizen, E-Mails, Verträgen oder Lohn-/Reisekostenunterlagen enthalten sein.

Beispiele:

  • Gesundheitsdaten auf Apotheken- oder Arztrechnungen,
  • Gewerkschaftsbezug auf Beitragsunterlagen,
  • religiöse Hinweise bei Spenden oder Mitgliedsbeiträgen,
  • Daten über Beschäftigte,
  • sensible private Angaben in hochgeladenen Dokumenten.

Der Auftraggeber ist dafür verantwortlich, nur solche Daten in Kontorio zu verarbeiten, für die eine Rechtsgrundlage besteht. Kontorio setzt technische Schutzmaßnahmen ein, kann aber nicht verhindern, dass der Auftraggeber sensible Inhalte hochlädt oder per E-Mail einsendet.

Anlage 2 — Technisch-organisatorische Maßnahmen (TOMs)

A2.1 Grundsatz

Kontorio setzt ein mehrschichtiges Sicherheitskonzept um. Die Maßnahmen sind risikoorientiert und auf Buchhaltungs-, Beleg-, Bank-, Steuer- und Mandantendaten ausgerichtet.

Ziel ist nicht, eine schöne TOM-Liste für die Schublade zu schreiben. Ziel ist, dass die Architektur jeden Tag verhindert, dass Mandanten, Belege, Adminrechte und Jobs durcheinanderfliegen.

A2.2 Vertraulichkeit

A2.2.1 Zutrittskontrolle

Da Kontorio als Cloud-SaaS betrieben wird, erfolgt die physische Zutrittskontrolle im Wesentlichen durch die Rechenzentrums- und Cloudanbieter.

Maßnahmen:

  • Nutzung professioneller Hosting- und Cloudanbieter.
  • Keine eigene Serverhardware im Büro als Produktivsystem.
  • Zugriff auf Hetzner-Server ausschließlich per SSH-Key.
  • Root-Login nach initialer Einrichtung deaktiviert.
  • Passwort-Login auf Servern deaktiviert.
  • SSH nur für berechtigte Personen und nur über definierte IPs/VPN/temporäre Freigaben.
  • Agenten-/Deploy-Zugänge zeitlich begrenzt und rotierbar.
  • Produktionszugänge dokumentiert.

A2.2.2 Zugangskontrolle

Maßnahmen:

  • Persönliche Nutzerkonten.
  • Keine gemeinsam genutzten Admin-Konten als Standard.
  • Passwort-Hashing nach aktuellem Stand der Technik.
  • HttpOnly Secure Cookies für Browser-Sessions.
  • Serverseitige DB-Sessions statt JWT-only-Browsermodell.
  • Session-Widerruf möglich.
  • MFA für Admin-Zugänge verpflichtend bzw. production fail-closed.
  • Step-up-Authentifizierung für kritische Aktionen vorgesehen.
  • Rate Limits für Login, Registrierung, Upload, OCR/KI, Webhooks und Adminaktionen.
  • Brute-Force-Schutz.
  • Login- und Security-Events werden protokolliert.
  • Recovery-Codes nur gehasht speichern, soweit MFA-Recovery angeboten wird.

A2.2.3 Zugriffskontrolle

Maßnahmen:

  • Rollen- und Rechtemodell für Portal und Admin getrennt.
  • TenantMembership als zentrale Zugriffsvoraussetzung.
  • Backend prüft Session, Userstatus, Tenantstatus, Membership, Rolle, Permission und Ressourceneigentum.
  • Keine Sicherheitsentscheidung allein im Frontend.
  • Mandantenbezogene Ressourcenprüfung bei jedem Zugriff.
  • Belege gehören Tenant, nicht bloß User.
  • Mailboxen gehören Tenant, nicht User.
  • Adminrollen sind getrennt von Kundenrollen.
  • Supportzugriff nur bei Berechtigung, Zweck, Freigabe, Zeitlimit und Audit.
  • Read-only- und Supportrollen dürfen keine fachlichen Buchungen ausführen.
  • Billing-, Support-, Security- und Developer-Ops-Rechte werden getrennt.
  • Beleginhalte sind stärker geschützt als reine Status-/Metadaten.

A2.2.4 Datenzugriff durch Admins und Support

Grundsatz:

Admins verwalten die Plattform. Sie führen keine Buchhaltung des Kunden aus.

Maßnahmen:

  • Kein stiller Login als Kunde.
  • Kein Zugriff auf Beleginhalte ohne Permission.
  • Supportfreigabe durch berechtigten Kunden oder dokumentierter Notfallprozess.
  • Zeitlich begrenzter Supportzugriff.
  • Zweckbindung und Ticket-/Begründungspflicht.
  • Audit-Log für jeden Zugriff.
  • Bei Break-Glass-Zugriff zusätzlich Vier-Augen-Prinzip oder nachträgliche Compliance-Prüfung.
  • Technische Diagnose bevorzugt über Metadaten, Status, Fehlercodes und Logs statt über Inhalte.

A2.3 Integrität

A2.3.1 Eingabekontrolle und Audit

Maßnahmen:

  • Append-orientierte Audit-Logs für kritische Aktionen.
  • Protokollierung von Nutzer, Zeitpunkt, Tenant, Ressource, Aktion, IP/User-Agent, altem/neuem Wert, soweit angemessen.
  • Belegversionierung über DocumentVersion.
  • sha256-Hash für Originaldateien.
  • Dedupe tenant-scoped, keine globale UI-Offenlegung tenantübergreifender Hash-Treffer.
  • Statusmaschinen für Belege, E-Mail-Import, OCR-Jobs, KI-Vorschläge, Buchungsvorschläge, Exporte.
  • Keine stille Löschung von Belegen ohne dokumentierten Prozess.
  • Kritische Änderungen an Rollen, Rechten, Supportzugriff, Löschung, Export und Adminaktionen werden protokolliert.
  • Buchungsvorschläge, OCR-/KI-Ergebnisse und menschliche Freigaben werden unterscheidbar gespeichert.

A2.3.2 Verarbeitungskontrolle

Maßnahmen:

  • Fachliche Daten liegen in Neon/PostgreSQL als Source of Truth.
  • Redis/BullMQ ist nur Ausführungsqueue, nicht fachliche Wahrheit.
  • Queue-Payloads enthalten nur IDs, keine PDFs, keine OCR-Volltexte, keine E-Mail-Bodies, keine sensiblen Inhalte.
  • Jobs sind idempotent; Retries dürfen keine doppelten Belege, Buchungen, Exporte oder E-Mails erzeugen.
  • Worker verarbeiten langsame Aufgaben getrennt von der API.
  • Dead-Letter-/Failed-Status für fehlgeschlagene Jobs.
  • Webhook-Signaturprüfung, insbesondere bei Resend-Webhooks.
  • Provider-IDs werden eindeutig verarbeitet, um doppelte Webhook-Verarbeitung zu verhindern.

A2.4 Verfügbarkeit und Belastbarkeit

A2.4.1 Systemarchitektur

Geplante Architektur:

  • Vercel für Portal/Admin-Frontends.
  • Hetzner für Backend-Maschinenraum.
  • Caddy als Reverse Proxy und HTTPS-Schicht.
  • NestJS API Container.
  • NestJS Worker Container.
  • Redis/BullMQ für Jobverarbeitung.
  • Neon/PostgreSQL als fachliche Datenbank.
  • AWS S3 eu-central-1 als Object Storage.
  • Resend für E-Mail-Versand und Inbound.
  • GitHub Actions/GHCR für CI/CD und Docker-Images.

A2.4.2 Backup und Wiederherstellung

Maßnahmen:

  • Datenbank-Backups nach definiertem Rhythmus.
  • Object-Storage-Versionierung, soweit aktiviert.
  • Keine Belege dauerhaft auf der Hetzner-Serverplatte.
  • Backup-/Restore-Skripte dokumentiert.
  • Restore-Tests regelmäßig durchführen.
  • Backup-Status überwachen.
  • Redis ist keine fachliche Wahrheit; Verlust einzelner Queue-Zustände darf nicht zum Verlust fachlicher Daten führen.
  • Fachliche Jobs müssen anhand von Datenbankstatus neu gestartet oder rekonstruiert werden können.

A2.4.3 Monitoring und Alarmierung

Maßnahmen:

  • Health-Endpunkt /api/v1/health.
  • Readiness-Endpunkt /api/v1/ready.
  • Monitoring von API, Worker, Redis, S3, Resend-Webhooks, Queue-Backlog, Backup-Status und Speicherplatz.
  • Sentry oder vergleichbares Fehlertracking.
  • JSON-Logs für Caddy/API/Worker.
  • Logrotate für Host-Logs.
  • Alerts bei API down, Worker down, Redis unavailable, Queue backlog hoch, S3 Fehler, Resend Webhook Fehler, Backup failed, Disk fast full, ungewöhnlicher Admin-Login.

A2.5 Trennungskontrolle

Maßnahmen:

  • Strikte Tenant-Isolation in Datenmodell, Services und Guards.
  • Eindeutige tenantId-Zuordnung für Dokumente, Mailboxen, Nutzerzugriffe, Buchungen, Jobs und Audit-Events.
  • Keine blind vertraute tenantId aus dem Body oder Frontend.
  • S3-Object-Prefixe nach Tenant, z. B. tenants/{tenantId}/....
  • Backend-Download statt öffentliche S3-URLs als Standard.
  • Presigned URLs nur kurzlebig und nach Backend-Prüfung.
  • Kein global sichtbarer Dedupe-Vergleich über Mandanten hinweg.
  • Admin- und Portalbereiche logisch und rechtlich getrennt.
  • Portalrollen und Adminrollen werden nicht vermischt.
  • Steuerberater ist Portalrolle bzw. berechtigter externer Nutzer, kein Betreiber-Admin.

A2.6 Verschlüsselung und Übertragungssicherheit

Maßnahmen:

  • HTTPS/TLS für externe Kommunikation.
  • Caddy übernimmt TLS und Security Header.
  • TLS/SSL für Datenbankverbindungen, soweit Anbieter/Setup dies erfordern.
  • S3 serverseitige Verschlüsselung, mindestens SSE-S3 oder vergleichbar; KMS später prüfen.
  • Secrets nicht im Frontend.
  • Keine Secrets im Repo.
  • Keine echten Secrets in Dokumentation, Tickets oder Chatverläufen.
  • .env nur serverseitig und geschützt.
  • API-Keys und Provider-Secrets rotierbar.
  • Webhook-Secrets für Resend und spätere Anbieter.
  • Signed/Presigned Uploads und Backend-vermittelte Downloads.

A2.7 Datenminimierung

Maßnahmen:

  • Frontends erhalten nur öffentliche Variablen wie NEXT_PUBLIC_API_URL.
  • Queue-Payloads enthalten nur IDs.
  • Logs enthalten keine Tokens, Beleginhalte, OCR-Volltexte oder E-Mail-Bodies.
  • KI-/OpenAI-Payloads werden minimiert.
  • Rohbelege werden nicht standardmäßig an OpenAI gesendet.
  • Banktransaktionsverarbeitung nur mit notwendigen Kandidaten und zweckbezogenem Kontext.
  • Technische Diagnose bevorzugt Status, IDs, Fehlercodes und Metadaten statt Inhaltsdaten.
  • E-Mail-Inbound speichert nur, was für Routing, Sicherheit, Dedupe, Verarbeitung und Audit erforderlich ist.

A2.8 Datenschutz durch Technikgestaltung und Voreinstellungen

Maßnahmen:

  • Standardmäßig keine automatische finale Buchung durch KI.
  • OCR/KI-Ergebnisse sind Vorschläge und werden als solche gekennzeichnet.
  • Human Review für fachlich relevante Buchungen, Sonderfälle, Unsicherheiten und sensible Fälle.
  • Admin sieht standardmäßig Status/Metadaten, nicht Inhalte.
  • Supportzugriff ist standardmäßig aus.
  • E-Mail-Import pro Tenant über eindeutige, zufällig ergänzte Adresse.
  • Kein Fallback über Firmenname, User-Mail oder ähnliche Adresse bei E-Mail-Routing.
  • Unbekannte oder mehrdeutige E-Mails gehen in Quarantäne.
  • Absenderregeln, Whitelists oder Members-only-Modus für E-Mail-Import.
  • Upload-Limits, MIME-Typ-Prüfung und Malware-Scan.

A2.9 Belastbare Entwicklungs- und Deploymentprozesse

Maßnahmen:

  • GitHub Actions baut und testet.
  • GHCR speichert Images.
  • Hetzner zieht Images; Produktivserver baut nicht.
  • Docker Compose startet Container.
  • Image-Tags versionierbar, SHA-Tags für Rollbacks empfohlen.
  • Migrationsprozess über separaten Migrate-Container.
  • Keine Builds auf dem Produktivserver.
  • Tests für Auth, Tenant-Isolation, Rechte, Upload/Download, Queue-Retry, OCR/KI, E-Mail-Inbound, Dedupe und Audit.
  • Keine direkte Einführung kritischer Anbieter oder Module ohne Planänderung, Test und Dokumentation.

Anlage 3 — Unterauftragsverarbeiterliste (Arbeitsstand)

Hinweis: Diese Liste muss vor Veröffentlichung anhand der tatsächlich eingesetzten Dienste, Vertragspartner, Regionen, DPAs, SCCs und Subprozessorenlisten final geprüft werden.

Anbieter Zweck Datenkategorien Region / Hinweis Status
Hetzner Online GmbH Backend-Server / Docker / API / Worker / Redis technische Betriebsdaten, IPs, Logs, ggf. temporäre Metadaten Deutschland/EU, je nach Serverstandort geplant / prüfen
Vercel Inc. / Vercel-Unternehmen Frontend-Hosting Portal/Admin/Website Zugriffsdaten, technische Frontend-Logs, ggf. IP/User-Agent Drittland-/EU-Konfiguration prüfen geplant / prüfen
Neon / Neon-Unternehmen PostgreSQL-Datenbank Nutzer, Tenants, Sessions, Documents-Metadaten, Audit, Billing, Status Region/Vertrag/DPA prüfen geplant / prüfen
Amazon Web Services EMEA SARL / AWS S3 Object Storage Belege, OCR-Artefakte, Exporte, Quarantäne-Dateien eu-central-1 geplant geplant / prüfen
Resend E-Mail-Versand und E-Mail-Inbound E-Mail-Adressen, Versand-/Empfangsdaten, Inhalte und Anhänge beim Inbound, Webhookdaten DPA/Subprozessoren/Region prüfen geplant / prüfen
OpenAI Ireland Ltd. / OpenAI KI-/LLM-Auswertung, Buchungsvorschläge, semantische Analyse minimierte strukturierte Felder, ggf. OCR-Auszüge, keine Rohbelege als Standard DPA, Drittlandtransfer, EU-Projekt/Endpoint prüfen optional / prüfen
Sentry oder vergleichbarer Dienst Fehlertracking / Monitoring technische Fehlerdaten, Stacktraces, User-/Tenant-IDs nur minimiert Region/DPA prüfen geplant / optional
Banking-Provider, z. B. finAPI/Qwist/Tink Kontoinformationen, Banktransaktionen, Consent Bankdaten, Transaktionen, Kontoinhaber, IBAN, Provider-IDs Anbieter noch final zu wählen Phase 2 / prüfen
Zahlungsanbieter, z. B. Stripe SaaS-Abrechnung Rechnungsdaten, Zahlungsstatus, Customer IDs DPA/Region prüfen optional / prüfen
DATEV / DATEV-nahe Schnittstellen Export / Steuerberaterübergabe Buchungsdaten, Belegreferenzen, Stammdaten Schnittstelle/Vertrag prüfen später / prüfen
ELSTER/ERiC / Finanzverwaltung Steuerliche Übermittlung Steuerdaten, Protokolle serverseitige Integration prüfen später / prüfen

A3.1 Anbieter, die nicht ohne neue Prüfung eingeführt werden dürfen

  • neuer Object-Storage-Anbieter,
  • neuer Datenbankanbieter,
  • neuer KI-/LLM-Anbieter,
  • neuer E-Mail-Inbound-Anbieter,
  • neuer Banking-Provider,
  • Anbieter mit produktivem Zugriff auf Beleginhalte,
  • Anbieter mit Drittlandverarbeitung ohne dokumentierte Garantien,
  • externe Support- oder Admin-Dienstleister.

Anlage 4 — Lösch-, Rückgabe- und Aufbewahrungskonzept

A4.1 Grundsatz

Daten werden nur so lange gespeichert, wie es für die vertraglichen Zwecke, gesetzliche Pflichten, Sicherheitsnachweise, Missbrauchsabwehr, Support, Abrechnung oder technische Wiederherstellung erforderlich ist.

Der Auftraggeber bleibt verantwortlich für steuer- und handelsrechtliche Aufbewahrungspflichten seiner Daten. Kontorio unterstützt technisch, übernimmt aber nicht automatisch die rechtliche Verantwortung für Vollständigkeit oder steuerliche Archivierung, soweit nicht ausdrücklich anders vereinbart.

A4.2 Laufender Betrieb

Datenart Standardlogik Bemerkung
Nutzerkonto solange Vertrag/Nutzung besteht Löschung/Deaktivierung nach Auftraggeberweisung
Firmen-/Tenantdaten solange Tenant aktiv ist Export/Löschung nach Vertragsende
Belege/Dokumente solange vom Auftraggeber gespeichert oder gesetzlich erforderlich Löschsperren und Export beachten
DocumentVersion grundsätzlich versionsorientiert keine stille Überschreibung des Originals
OCR-/KI-Ergebnisse solange für Prüfung, Audit, Buchhaltung oder Nachvollziehbarkeit nötig Retention-Matrix final definieren
Audit-Logs längerfristig, soweit für Nachweis erforderlich nicht vorschnell löschen
Supporttickets nach Support- und Nachweiszweck sensible Inhalte minimieren
E-Mail-Inbound-Rohdaten nur solange für Verarbeitung, Sicherheit, Nachweis erforderlich Anhänge in Storage, Payload minimieren
Queue-Daten kurzlebig keine fachliche Wahrheit in Redis
Backups nach Backup-Retention Restore-Test dokumentieren
Sicherheitslogs nach Sicherheits-/Nachweiszweck keine Inhalte loggen

A4.3 Vertragsende

Nach Vertragsende:

  1. Konto wird in Kündigungs-/Exportphase gesetzt.
  2. Auftraggeber erhält Möglichkeit zum Export, soweit technisch verfügbar.
  3. Nach Ablauf der Exportfrist werden aktive Daten gelöscht oder anonymisiert, soweit keine Aufbewahrungspflichten entgegenstehen.
  4. Backups werden nach Backup-Retention überschrieben oder gelöscht.
  5. Audit-/Sicherheits-/Abrechnungsdaten werden nur soweit erforderlich fortgeführt.
  6. Löschung/Rückgabe wird dokumentiert.

A4.4 Löschsperren

Löschung kann eingeschränkt oder verzögert werden bei:

  • gesetzlichen Aufbewahrungspflichten,
  • laufenden Streitigkeiten,
  • Sicherheitsvorfällen,
  • Missbrauchsprüfung,
  • offenen Zahlungen,
  • steuerlichen Nachweispflichten,
  • technischen Backup-Retention-Zyklen,
  • laufenden Supportfällen.

Anlage 5 — Incident-, Melde- und Eskalationsprozess

A5.1 Vorfallkategorien

Beispiele:

  • unbefugter Zugriff auf Mandantendaten,
  • falsche Mandantenzuordnung,
  • Datenleck in API, Storage, Logs oder E-Mail-Inbound,
  • kompromittierter Admin- oder Deploy-Zugang,
  • verlorene oder offengelegte Secrets,
  • fehlerhafte S3-Berechtigung,
  • fehlerhafte Webhook-Verarbeitung,
  • fehlerhafte KI-/OCR-Datenweitergabe,
  • Datenverlust,
  • Malware in Uploads,
  • unberechtigter Supportzugriff.

A5.2 Interner Ablauf

  1. Vorfall erkennen.
  2. Sofortmaßnahmen zur Eindämmung.
  3. Klassifizierung nach Schweregrad.
  4. Betroffene Tenants, Datenarten und Zeiträume ermitteln.
  5. Technische Ursache sichern und analysieren.
  6. Datenschutz-/Security-Verantwortliche informieren.
  7. Auftraggeber informieren, soweit dessen Daten betroffen sind.
  8. Unterstützung bei Art. 33/34 DSGVO-Prüfung.
  9. Maßnahmen umsetzen.
  10. Lessons Learned dokumentieren.
  11. Tests/Regression ergänzen.

A5.3 Kommunikationsgrundsatz

Keine Beschönigung, kein Verstecken, keine Salamitaktik. Erst intern sauber verifizieren, dann klar und rechtzeitig informieren.

Anlage 6 — KI-/OCR-spezifische Zusatzmaßnahmen

A6.1 Grundsatz

KI und OCR sind Assistenzkomponenten. Sie dienen der Extraktion, Klassifizierung, Plausibilisierung und Vorschlagserstellung. Sie ersetzen keine menschliche Prüfung, keinen Steuerberater, keine Buchhalterprüfung und keine Verantwortlichkeit des Auftraggebers.

A6.2 Datenminimierung

  • Rohbelege werden nicht standardmäßig an OpenAI oder vergleichbare LLM-Anbieter gesendet.
  • Primär werden OCR-Ergebnisse und strukturierte Felder verarbeitet.
  • Bankdaten werden nur als notwendige Kandidaten verarbeitet, nicht als vollständiger Kontoauszug, soweit vermeidbar.
  • Personenbezogene Details werden reduziert, pseudonymisiert oder weggelassen, soweit fachlich möglich.
  • Sensible Dokumente können blockiert, gesondert geprüft oder nur lokal/OCR-seitig verarbeitet werden.

A6.3 Vertragliche Anforderungen an KI-/OCR-Anbieter

Vor produktiver Nutzung eines KI-/OCR-Anbieters müssen geprüft und dokumentiert werden:

  • DPA/AVV,
  • Subprozessorenliste,
  • Datenregion,
  • Trainingsnutzung / Opt-in / Opt-out,
  • Retention und Abuse-Monitoring,
  • Drittlandtransfer,
  • SCCs und Transfer Impact Assessment,
  • Lösch-/Rückgabeprozess,
  • Security-Dokumentation,
  • Modell-/Promptversionierung,
  • Protokollierung.

A6.4 Human Review

Menschliche Prüfung ist erforderlich bei:

  • niedriger Konfidenz,
  • steuerlichen Sonderfällen,
  • Reverse-Charge-/Auslandssachverhalten,
  • unklarer Umsatzsteuer,
  • Belegen mit Beschäftigtendaten,
  • Lohn-/Payroll-Dokumenten,
  • sensiblen Daten,
  • ungewöhnlichen Beträgen,
  • erstmaligen Lieferanten,
  • Regeländerungen,
  • Export-/Festschreibungsprozessen.

A6.5 Audit für KI/OCR

Zu protokollieren sind mindestens:

  • Tenant,
  • Dokument,
  • Dokumentversion,
  • Hash,
  • OCR-Provider,
  • KI-Provider,
  • Modellversion,
  • Promptversion,
  • Regelversion,
  • Input-Minimierungslevel,
  • Ergebnis,
  • Konfidenz,
  • menschliche Entscheidung,
  • Zeitpunkt,
  • Nutzer/Systemakteur.

Anlage 7 — Go-Live-Checkliste

A7.1 Recht / Datenschutz

  • Unternehmensdaten im AVV-Entwurf ergänzt.
  • AGB mit AVV verknüpft.
  • Datenschutzerklärung App/Software mit AVV abgeglichen.
  • Datenschutzerklärung Website getrennt erstellt.
  • Unterauftragsverarbeiterliste final geprüft.
  • DPAs/AVVs mit Hetzner, Vercel, Neon, AWS, Resend, OpenAI, Sentry, Banking-Anbietern geprüft.
  • Drittlandtransfers geprüft.
  • SCCs / Transfer Impact Assessments geprüft.
  • VVT erstellt.
  • DSFA geprüft/gestartet.
  • Lösch- und Aufbewahrungskonzept finalisiert.
  • GoBD-Verfahrensdokumentation gestartet.

A7.2 Technik / Security

  • Keine Secrets im Frontend.
  • Keine Belege auf Serverplatte.
  • S3 Bucket private, Block Public Access, Verschlüsselung, Versionierung geprüft.
  • Redis nicht öffentlich erreichbar.
  • API nur über Caddy öffentlich.
  • Neon TLS/Region/Backups geprüft.
  • Resend Webhook-Signaturen aktiv.
  • Upload MIME/Size Policy aktiv.
  • Malware-Scan aktiv oder klar als offene Maßnahme markiert.
  • tenantId wird nie blind aus Body/Frontend vertraut.
  • Backend Guards für alle Ressourcen.
  • AuditLog für kritische Aktionen.
  • Supportzugriff mit Freigabe/Audit/Zeitlimit.
  • Admin-MFA production fail-closed.
  • Queue-Payloads nur IDs.
  • Jobs idempotent.
  • Restore-Test dokumentiert.

A7.3 KI/OCR

  • Keine Consumer-ChatGPT-Nutzung für Kundendaten.
  • OpenAI/API DPA abgeschlossen, falls produktiv genutzt.
  • Keine Rohbelege standardmäßig an OpenAI.
  • Payload-Minimierung dokumentiert.
  • Prompt-/Modellversionierung aktiv.
  • KI-Vorschläge als Vorschläge gekennzeichnet.
  • Human Review vor finaler Buchung.
  • KI-/OCR-Auditfelder implementiert.

A7.4 E-Mail-Belegimport

  • Eindeutige Adresse pro Tenant.
  • Kein Sammelpostfach belege@mail.kontorio.de für alle Mandanten.
  • Kein Fallback über Firmenname/User-Mail.
  • Quarantäne bei unbekannter oder mehrdeutiger Adresse.
  • Absenderregeln/Whitelist/Members-only implementiert.
  • Mailgröße, Anhanganzahl und MIME-Typen begrenzt.
  • Dublettenprüfung per sha256 tenant-scoped.
  • Alles ins AuditLog.

Anlage 8 — Offene Punkte für Anwalt / Datenschutzbeauftragten

  1. Genaue Betreiberfirma und Vertretungsdaten eintragen.
  2. Prüfen, ob Kontorio für alle Kernverarbeitungen Auftragsverarbeiter ist oder teilweise gemeinsam/allein Verantwortlicher.
  3. Steuerberaterzugang: Rollenmodell datenschutzrechtlich sauber einordnen.
  4. Banking-Provider: Rollenmodell prüfen, da PSD2-/Kontoinformationsdienste oft eigene Verantwortlichkeiten haben können.
  5. OpenAI/OCR: AVV-Kette, Drittlandtransfer, Retention, Trainingsnutzung und EU-Datenresidenz final bewerten.
  6. Vercel/Neon/Resend/Sentry: Drittlandtransfer und Subprozessorenlisten final prüfen.
  7. Beschäftigtendaten in Belegen: BDSG/DSGVO-Risiko bewerten.
  8. Lohnmodul später separat prüfen; nicht über diese AVV allein laufen lassen.
  9. DATEV-/ELSTER-Integration später separat mit Rollen, Pflichten und Protokollen prüfen.
  10. GoBD-Verfahrensdokumentation mit AVV und TOMs verzahnen.
  11. Löschfristen konkretisieren.
  12. Audit-/Log-Retention konkretisieren.
  13. Meldefrist- und Kommunikationsprozess für Datenschutzverletzungen finalisieren.
  14. TOMs gegen tatsächliche Infrastruktur testen.
  15. Prüfen, welche Inhalte Kunden im Portal als AVV akzeptieren können und wie Versionierung/Consent protokolliert wird.

Kurzfassung für Produkt-/Admin-UI

Für den späteren Vertrags-/Compliance-Bereich im Admin und Portal sollte Kontorio folgende Anzeigeelemente vorsehen:

  • Aktuelle AVV-Version.
  • Akzeptiert am / durch wen.
  • TOM-Version.
  • Unterauftragsverarbeiterliste mit Änderungsdatum.
  • Möglichkeit zum Download als PDF/Markdown.
  • Änderungsbenachrichtigung.
  • Widerspruchsprozess bei neuen Unterauftragsverarbeitern.
  • Datenschutzkontakt.
  • Export-/Löschanfrage starten.
  • Supportzugriff freigeben/widerrufen.
  • Audit der Zustimmungen.

Schlussnotiz

Dieser Entwurf ist bewusst ausführlich. Für die spätere öffentliche Vertragsfassung kann er gekürzt und juristisch geglättet werden. Für die Entwicklung ist die Detailtiefe aber richtig: Die TOMs müssen nicht nur im Vertrag hübsch aussehen, sondern direkt als technische Bauanleitung für Kontorio funktionieren.