AVV-Grundlage und TOM-Verzeichnis

Der technische Ist-Zustand von Zeffio, auf dessen Grundlage Sie – bzw. Ihre Rechtsberatung oder Ihre Datenschutzbeauftragte – den eigentlichen Auftragsverarbeitungsvertrag (Art. 28 DSGVO) und das Verzeichnis der technischen und organisatorischen Massnahmen (Art. 32 DSGVO) erstellen können.

Entwurf, Stand 09.08.2026. Diese Seite wird mit der Software weitergeführt – ändert sich, was Zeffio verarbeitet oder wie, wird sie mitgeführt. Fragen zu diesem Dokument oder zum Datenschutz allgemein: hallo@zeffio.app.

Rahmenbedingungen, die den Aussagewert begrenzen

• Zeffio ist noch nicht im produktiven Grosseinsatz. Die folgenden Angaben beschreiben die Software, nicht eine über Jahre geübte Betriebspraxis.
• Die Anwendung weist sich selbst als Beta aus – sichtbar unten in der Navigation der App.
• Der Betrieb liegt bei einer einzelnen natürlichen Person (Angaben im Impressum). Es gibt aktuell keine Rollentrennung im Betrieb – dazu mehr unter «Was noch fehlt».

Zwei Verantwortlichkeiten

Unsere Datenschutzerklärung unterscheidet zwei Datenkreise, und diese Unterscheidung ist die Grundlage jedes Auftragsverarbeitungsvertrags:

• Ihre Kontodaten — Name, E-Mail, Anmeldungen, Einstellungen. Dafür sind wir als Betreiber verantwortlich.
• Ihre Geschäftsdaten — Ihre Kundinnen und Kunden, deren Kontakte, Ihre Rechnungen, Zeiten und Belege. Diese Daten geben Sie ein; Sie sind dafür verantwortlich (Art. 4 Nr. 7 DSGVO), wir verarbeiten sie in Ihrem Auftrag.

Der Auftragsverarbeitungsvertrag betrifft den zweiten Kreis: dort sind Sie Verantwortliche, Zeffio ist Auftragsverarbeiter. Diese Trennung ist im Datenmodell selbst verankert und wird serverseitig durchgesetzt: praktisch jede Geschäftstabelle trägt einen Mandantenschlüssel, nach dem jede Anfrage gefiltert und geprüft wird, bevor eine Zeile zurückgegeben oder verändert wird — nicht nur in der Oberfläche verhindert, sondern in jeder Serviceschicht verankert.

Unterauftragnehmer

Die massgebliche, laufend gepflegte Liste unserer Dienstleister führen wir an einer Stelle: in der Datenschutzerklärung unter «Auftragsverarbeiter». Wir duplizieren sie hier bewusst nicht — zwei getrennt gepflegte Listen laufen sonst irgendwann auseinander, und genau das wäre für einen Vertragsanhang das grössere Risiko als eine fehlende Kopie.

Diese Liste umfasst neben den unmittelbar sichtbaren Diensten (Hosting, Mailversand, optionale KI-Textvorschläge) auch die beiden Dienste, die nur bei entsprechender Einrichtung durch den Betreiber überhaupt zum Einsatz kommen (ausgelagerte Datenbanksicherung, Alarmierung bei fehlgeschlagener Sicherung) sowie den Transportweg für Zustellereignisse Ihrer versendeten Mails. Für einen belastbaren Vertragsanhang gehört zu jedem dieser Dienste zusätzlich eine eigene, dokumentierte Auftragsverarbeitungsvereinbarung mit uns — die steht noch aus (siehe «Was noch fehlt»).

Technische und organisatorische Massnahmen (Art. 32 DSGVO)

Gegliedert nach den vier in Art. 32 genannten Schutzzielen, ergänzt um Wiederherstellbarkeit und regelmässige Überprüfung. Jeder Abschnitt nennt auch, was nicht zutrifft — eine Massnahme, die nur teilweise oder nie greift, gehört nicht unkommentiert in ein TOM-Verzeichnis.

Vertraulichkeit

• Verschlüsselte Übertragung für die Anwendung selbst (HTTPS), für den Mailversand und für alle Aufrufe an eingesetzte Fremddienste über deren eigene, serverseitig gehaltene Zugangsschlüssel.
• Die Datenbank ist von aussen nicht erreichbar — kein offener Netzwerkport, Zugriff nur aus dem internen Netz des Betriebs.
• Passwörter werden ausschliesslich als Hash gespeichert (bcrypt), nie im Klartext.
• Sitzungen als signierte, zeitlich befristete Zugriffstoken; einzeln einsehbar und widerrufbar in Ihren Kontoeinstellungen. Ein Widerruf beendet die Sitzung sofort; der Eintrag selbst (u. a. mit IP-Adresse und Browserkennung) bleibt bis zum Ablauf seiner Aufbewahrungsfrist bestehen — die noch nicht dokumentiert ist, siehe «Was noch fehlt». Ein Passwortwechsel oder ‑zurücksetzen widerruft automatisch alle übrigen Sitzungen.
• Optionale Zwei-Faktor-Anmeldung (TOTP) mit Wiederherstellungscodes, die als Hash gespeichert und beim Gebrauch verbraucht werden.
• Rollen- und Rechtemodell im Team: mehrere abgestufte Rollen mit granularen Berechtigungen, serverseitig durchgesetzt — inklusive automatischer Ausblendung sensibler Felder (z. B. Bankverbindung, interne Kostensätze) für Rollen ohne entsprechende Berechtigung.
• Vier-Augen-Prinzip optional aktivierbar für heikle Aktionen (Rechnungsversand, Storno, Periodenexport, Zahlungskorrekturen).
• Schutz gegen automatisierte Angriffe: Ratenbegrenzung pro Herkunfts-IP, unauffälliges Antwortverhalten bei Login-Versuchen auf unbekannte Adressen.
• Sicherheits-Header (u. a. gegen das Einbetten der Anwendung in eine fremde Seite) werden auf jeder Antwort der Anwendung und der Programmierschnittstelle gesetzt.
• Einschränkung: Auf Anwendungsebene ist keine Verschlüsselung ruhender Daten implementiert — Bankverbindung, Steuernummern, Belegdateien und das Geheimnis der Zwei-Faktor-Anmeldung (anders als die gehashten Wiederherstellungscodes) liegen unverschlüsselt in der Datenbank. Ob die zugrunde liegende Infrastruktur beim Hosting-Anbieter (Speicher, Datenträger) verschlüsselt ist, lässt sich aus unserem eigenen Code nicht belegen und ist eine Frage an den Hosting-Anbieter. Der optionale Transfer der Datenbanksicherung an ein externes Auslagerungsziel ist nur dann verschlüsselt, wenn er ausdrücklich als solcher (FTPS) eingerichtet wird — ohne diese Einrichtung ist ein unverschlüsselter Transportweg möglich.

Integrität

• Serverseitige Eingabevalidierung; unbekannte oder unerwartete Felder werden abgewiesen, nicht stillschweigend ignoriert.
• Geldbeträge mit einer fest benannten Obergrenze, in mehreren unabhängigen Schichten geprüft.
• Bereits versendete Belege werden nicht rückwirkend umgeschrieben — Adress- und Absenderangaben sind zum Versandzeitpunkt eingefroren; das ist Belegtreue, keine Weigerung, Fehler zu korrigieren.
• Belegnummern bleiben nach einer Löschung dauerhaft verbraucht und werden nie erneut vergeben.
• Änderungen an sicherheitsrelevanten Stammdatenfeldern (u. a. Bankverbindung, Adresse, Steuernummer) werden protokolliert. E-Mail-Adresse, Telefonnummer, Logo und Freitextfelder sind davon ausdrücklich ausgenommen und derzeit nicht protokolliert — auch nicht, wenn sie sich ändern.
• Änderungen an der Datenbankstruktur laufen ausschliesslich über nachvollziehbare, versionierte Migrationen, nie manuell.
• Einschränkung: Die Protokolltabellen sind gewöhnliche Datenbanktabellen ohne technischen Manipulationsschutz — kein erzwungenes „Nur-Anhängen“, keine Signatur. Die Protokollierung selbst ist „best effort“: Ein Fehler beim Schreiben eines Protokolleintrags unterbricht die eigentliche Aktion nicht, kann im Einzelfall aber dazu führen, dass ein Eintrag fehlt. Von einer lückenlosen Protokollierung darf nicht gesprochen werden.

Verfügbarkeit

• Automatisierte Gesundheitsprüfungen für alle Dienste; ein abgestürzter Dienst wird automatisch neu gestartet.
• Wiederkehrende Aufgaben (Vertragsabrechnung, Mahnwesen, Bereinigung) laufen zu festen, dokumentierten Zeiten.
• Einschränkung: Der Betrieb läuft aktuell auf einem einzelnen Server ohne Redundanz — keine Datenbankreplikation, kein automatisches Failover, keine zweite Verfügbarkeitszone. Ein Dienst, der zwar läuft, aber als «ungesund» erkannt wird (etwa weil er nicht mehr antwortet, ohne abzustürzen), wird dadurch allein nicht automatisch neu gestartet. Ein Ausfall des Servers ist ein Ausfall des Dienstes.

Belastbarkeit

• Ratenbegrenzung pro Herkunfts-IP gegen Überlastung und automatisierten Missbrauch.
• Grössenbegrenzung für versendete Anhänge.
• Tageslimit für KI-gestützte Textvorschläge pro Konto — diese Funktion läuft ausschliesslich auf Ihren ausdrücklichen Klick, nie automatisch, und zeigt vor dem Absenden den Text, der übermittelt wird. Diese Vorschau ist nicht auf jedem Versandweg vollständig — an einzelnen Stellen wird mehr an den Dienst übertragen, als die Vorschau zeigt.
• Einschränkung: Weitergehende, im Code bereits vorbereitete Mengenbegrenzungen für den Mailversand (Tages- und Monatskontingente) sind aktuell nicht aktiv geschaltet. Wirksam bleiben in jedem Fall die Sicherheitsprüfungen — bestätigte Absenderadresse, Sperrlisten für unzustellbare Adressen.

Wiederherstellbarkeit

• Tägliche vollständige Datenbanksicherung, komprimiert, standardmässig mit einer Aufbewahrung von 14 Tagen.
• Die Wiederherstellung ist geprobt, dokumentiert und mit gemessenen Zeiten hinterlegt; die Übung wird in einem festen Turnus wiederholt.
• Einschränkung: Es gibt kein kontinuierliches Sicherungsverfahren — im Ernstfall sind bis zu 24 Stunden Datenverlust möglich. Die Sicherungsdateien sind komprimiert, aber nicht verschlüsselt.

Regelmässige Überprüfung

• Automatisierte Qualitätsprüfungen (Tests, Typprüfung) werden vor jedem Merge lokal ausgeführt.
• Ein dokumentiertes, turnusmässiges Verfahren prüft eingesetzte Softwarebausteine auf bekannte Schwachstellen.
• Die Erzeugung der deutschen E-Rechnung (XRechnung) wird gegen den unabhängigen KoSIT-Referenzvalidator geprüft. Die Schweizer QR-Rechnung wird gegen einen eigenen, unabhängig entwickelten Decoder geprüft, der den gedruckten Zahlteil zurückliest und gegen die Swiss Payment Standards prüft — das ist kein SIX-Validatorlauf, sondern eine Vorbereitung darauf.
• Einschränkung: Es gibt aktuell keinen automatisch erzwungenen Prüfnachweis pro einzelner Codeänderung und keine laufende automatisierte Sicherheits-Scan-Pipeline. Die genannten Verfahren sind dokumentiert und terminiert, aber manuell ausgelöst — sie ersetzen kein automatisches Prüftor.

Wie Zeffio Sie bei Betroffenenrechten unterstützt

Weil Sie im zweiten Datenkreis Verantwortliche sind, sind letztlich Sie es, der Auskunfts-, Berichtigungs- und Löschungsersuchen Ihrer eigenen Kundinnen und Kunden beantwortet. Zeffio stellt dafür folgende technische Mittel bereit:

• Auskunft und Datenübertragbarkeit (Art. 15, 20): Unter Einstellungen → Konto löschen gibt «Meine Daten herunterladen» sofort und ohne Wartezeit einen vollständigen Export Ihres Kontos als ZIP-Datei mit CSV-Dateien heraus.
  Einschränkungen, offen benannt: Für Teammitglieder (nicht die Kontoinhaberin oder den Kontoinhaber) ist dieser Export aktuell praktisch leer, weil er technisch an die anfragende Person statt an das gesamte Konto gebunden ist — arbeiten Sie im Team, ist eine vollständige Auskunft derzeit nur über den Kontoinhaber möglich. Ausserdem fehlen im Export einzelne Belegpositionen, das Mail- und Sicherheitsprotokoll, sowie bei Dateien der Inhalt selbst (nur Metadaten). Für eine vollständige Buchhaltungsübergabe mit Belegdateien steht daneben der separate Periodenexport zur Verfügung.
• Berichtigung (Art. 16): Stamm- und Geschäftsdaten sind jederzeit direkt änderbar. Änderungen an sicherheitsrelevanten Feldern werden protokolliert, mit den oben unter «Integrität» genannten Ausnahmen (E-Mail, Telefon, Logo, Freitext). Bereits versendete Belege werden bewusst nicht rückwirkend umgeschrieben.
• Löschung (Art. 17): Einzelne Daten löschen Sie selbst; bei Rechnungen entscheidet der nachweisbare Zustellstatus, nicht ein blosser Status-Vermerk, ob eine Löschung möglich ist. Das ganze Konto lässt sich unter Einstellungen → Konto löschen mit Passwortbestätigung unmittelbar und endgültig löschen — ausser für einen Demo-Zugang oder für die Kontoinhaberin bzw. den Kontoinhaber eines Teams mit weiteren Mitgliedern; dort ist die Selbstlöschung bewusst gesperrt.
  Was eine Löschung nachweislich nicht erreicht: ein bereits geschriebenes Datenbank-Backup (standardmässig bis zu 14 Tage, ausgelagerte Kopien ohne dokumentierte Rotation), die E-Mail-Adresse der gelöschten Person im Server-Betriebsprotokoll (ohne dokumentierte Aufbewahrungsfrist), sowie bestimmte anonymisierte Restspuren — etwa Zeiteinträge, die eine Person in einem fremden Team erfasst hat, bleiben dort mit ihrem Freitext bestehen, verlieren aber den Personenbezug.
• Einschränkung der Verarbeitung (Art. 18): Dafür gibt es aktuell kein eigenes technisches Merkmal. Das Archivieren von Kundendaten ist ausdrücklich nur eine Sichtbarkeitsfunktion für Listen, keine Verarbeitungseinschränkung.
• Widerspruch (Art. 21): Kein technischer Schalter innerhalb der Anwendung; wenden Sie sich in einem solchen Fall an hallo@zeffio.app.
• Rückgabe bei Vertragsende: Der Kontoexport (mit obiger Einschränkung) und der Periodenexport stehen jederzeit selbständig zur Verfügung. Eine vertraglich zugesicherte Löschfrist nach Vertragsende gibt es noch nicht — nur die sofortige Selbstlöschung des Kontos.

Schweiz: revDSG neben der DSGVO

Der Betrieb von Zeffio liegt laut Impressum bei einer natürlichen Person mit Sitz in Basel — Schweizer Recht gilt darum zusätzlich zur DSGVO, nicht ersatzweise. Die Abschnitte oben sind an der DSGVO entlang geschrieben; hier die Stellen, an denen das revidierte Schweizer Datenschutzgesetz (revDSG, seit 1.9.2023 in Kraft) von der DSGVO abweicht.

• Meldefrist bei Datenschutzverletzungen: Die DSGVO kennt eine feste Frist von 72 Stunden. Das revDSG verlangt Meldung «so rasch als möglich» — eine unbestimmte, aber nicht beliebig dehnbare Frist. Praktisch ändert das aktuell nichts: ein Verfahren für Datenschutzverletzungen existiert noch nicht (siehe «Was noch fehlt»), sollte beim Bau aber beide Massstäbe von Anfang an tragen.
• Besonders schützenswerte Personendaten, geprüft: Das revDSG zieht diese Kategorie weiter als die DSGVO — zusätzlich zählen genetische und biometrische Daten, die eine Person eindeutig identifizieren, sowie Daten über verwaltungs- und strafrechtliche Verfolgungen und Sanktionen. Gegen unser Datenmodell geprüft: Zeffio hat kein biometrisches Merkmal (das Geheimnis der Zwei-Faktor-Anmeldung ist ein geteiltes kryptografisches Geheimnis, kein körperliches Merkmal) und kein Feld für Sanktionsdaten. Es wurden keine solchen Daten gefunden.
• Datenschutz-Folgenabschätzung: Das revDSG kennt einen eigenen Auslösetatbestand, unabhängig von der entsprechenden DSGVO-Pflicht. Unsere Verarbeitung — gewöhnliche Rechnungs- und Projektdaten, kein Profiling, keine systematische Überwachung — spricht gegen eine Pflicht; das ist eine Einschätzung, keine förmliche rechtliche Prüfung.
• Übermittlung ins Ausland: Der EDÖB führt eine eigene Liste von Staaten mit angemessenem Datenschutzniveau, historisch weitgehend, aber nicht zwingend deckungsgleich mit der EU-Liste. Für unsere Unterauftragnehmer in Frankreich ist nicht formell geprüft, ob die aktuelle EDÖB-Liste sie weiterhin als angemessen führt.
• Aufbewahrungspflicht (Art. 958f OR): Das Schweizer Obligationenrecht verlangt eine zehnjährige, unveränderliche Aufbewahrung der Geschäftsbücher und Belege — ein eigenständiges Gesetz, keine Ausprägung der GoBD. Der technische Befund dazu ist derselbe wie bei den fehlenden Aufbewahrungsfristen unten: es gibt aktuell keine Mindestaufbewahrungsdauer und keine Sperre gegen zu frühes Löschen, für keinen Datensatz.
• Aufsichtsbehörde: Für die Schweiz ist das der Eidgenössische Datenschutz- und Öffentlichkeitsbeauftragte (EDÖB), bereits in der Datenschutzerklärung genannt.

Wie die übrige Seite: technische und rechtstextliche Angaben, keine Rechtsberatung. Eine förmliche revDSG-Prüfung durch eine dazu befugte Person steht noch aus.

Was noch fehlt

Dieser Abschnitt ist der wichtigste auf dieser Seite. Er beschreibt, was für einen belastbaren Auftragsverarbeitungsvertrag noch nicht vorhanden ist — und liegt in der Verantwortung des Betreibers und der jeweils zuständigen rechtlichen Prüfung.

• Es gibt noch keinen eigenständigen AVV-Vertragstext. Diese Seite ist die technische Grundlage dafür, nicht der Vertrag selbst. Die Vertragsinhalte nach Art. 28 Abs. 3 lit. a–h — Weisungsbindung, Vertraulichkeit der Beschäftigten, Unterstützung bei Betroffenenrechten, Meldepflichten, Löschung oder Rückgabe bei Vertragsende, Nachweis- und Prüfrechte — sind noch nirgends formuliert.
• Keine dokumentierten Auftragsverarbeitungsvereinbarungen mit unseren eigenen Unterauftragnehmern liegen öffentlich vor. Ebenso fehlt ein Verfahren, wie Sie über einen Wechsel des Unterauftragnehmers informiert würden und widersprechen könnten.
• Es fehlen die organisatorischen Dokumente rund um den AVV: kein Verzeichnis von Verarbeitungstätigkeiten (Art. 30), kein Verfahren für Datenschutzverletzungen (Art. 33/34 — keine Meldekette, keine Vorlage, kein benannter Ansprechpartner), keine Datenschutz-Folgenabschätzung, kein Datenschutzbeauftragter, kein Vertreter in der EU (Art. 27), keine dokumentierte Verpflichtung von Beschäftigten auf Vertraulichkeit.
• Keine Verschlüsselung ruhender Daten auf Anwendungsebene (siehe «Vertraulichkeit» oben). Bankverbindungen, Steuernummern, Belegdateien und das Geheimnis der Zwei-Faktor-Anmeldung liegen unverschlüsselt in der Datenbank.
• Datenbank-Sicherungen sind nicht verschlüsselt, nur komprimiert; und es gibt kein kontinuierliches Sicherungsverfahren — bis zu 24 Stunden Datenverlust sind im Ernstfall möglich. Eine gelöschte Person bleibt zudem so lange in bereits geschriebenen Sicherungen enthalten, wie diese aufbewahrt werden.
• Es gibt noch keine dokumentierten Aufbewahrungsfristen für mehrere Protokolltabellen (u. a. Sitzungs-, Sicherheits- und Mailprotokoll). Sie bestehen aktuell, solange das Konto besteht.
• Betreiberzugriff auf Produktionsdaten ist organisatorisch nicht geregelt. Der Betrieb liegt bei einer einzelnen Person (siehe «Rahmenbedingungen» oben); es gibt keine Rollentrennung, kein Vier-Augen-Prinzip und keine gesonderte Protokollierung für betreiberseitige Eingriffe in die Produktionsdaten.
• Kein automatisch erzwungener Prüfnachweis pro Codeänderung und keine laufende automatisierte Sicherheits-Scan-Pipeline (siehe «Regelmässige Überprüfung» oben). Die vorhandenen Verfahren sind dokumentiert und terminiert, aber manuell ausgelöst.
• Der Datenexport ist für Auskunft und Übertragbarkeit noch nicht vollständig — insbesondere für Teammitglieder praktisch unbrauchbar (siehe oben).
• Keine förmliche revDSG-Prüfung. Die obigen Abschnitte sind an der DSGVO entlang geschrieben; die sechs Abweichungspunkte unter «Schweiz: revDSG neben der DSGVO» sind benannt, aber nicht von einer dazu befugten Person rechtlich geprüft.