Auftragsverarbeitungsvertrag (AVV)

Auftragsverarbeitungsvertrag (AVV / DPA)

Bearbeitung von Personendaten im Auftrag des Kunden

Parteien

Dieser Auftragsverarbeitungsvertrag («AVV») ist ein eigenständiger Vertrag zwischen dem Auftragsbearbeiter und dem Kunden. Er regelt sämtliche Bearbeitungen von Personendaten, die LogSheet im Auftrag des Kunden vornimmt, und kommt zustande, wenn der Kunde ein Unternehmenskonto registriert und ihn bei der Anmeldung annimmt, wie nachstehend unter «Abschluss dieses AVV» beschrieben.

In diesem AVV bezeichnet «Hauptvertrag» die Dienstleistungsbeziehung zwischen den Parteien, in deren Rahmen LogSheet dem Kunden die LogSheet-Web- und iPhone-Anwendungen zur Verfügung stellt — begründet mit der Registrierung eines Unternehmenskontos und fortdauernd, solange dieses Konto genutzt wird. Vereinbaren die Parteien später gesonderte Nutzungsbedingungen oder einen Abonnementsvertrag, werden diese Teil des Hauptvertrags und dieser AVV gilt daneben weiter. Bei Widersprüchen in datenschutzrechtlichen Fragen geht dieser AVV vor.

1. Gegenstand, Rollen und Dauer

1.1 Rollen. LogSheet ist eine mandantenfähige SaaS-Anwendung zur Erfassung von Arbeitszeit, Absenzen, Ferienanträgen und — optional — Kunden- und Projektzeiten. Hinsichtlich der Personendaten der Mitarbeitenden des Kunden sowie der in die Anwendung eingegebenen Geschäftskontakte des Kunden ist der Kunde Verantwortlicher und LogSheet Auftragsbearbeiter im Sinne von Art. 5 lit. j und Art. 9 des Bundesgesetzes über den Datenschutz vom 25. September 2020 («revDSG / nLPD / nFADP», in Kraft seit 1. September 2023) sowie, soweit anwendbar, Art. 4 Ziff. 8 und Art. 28 DSGVO.

1.2 Gegenstand. LogSheet bearbeitet Personendaten ausschliesslich zum Zweck der Bereitstellung, des Betriebs, der Absicherung und des Supports der LogSheet-Webanwendung (logsheet.ch) und der LogSheet-iPhone-App gemäss Hauptvertrag.

1.3 Nicht von diesem AVV erfasst. LogSheet handelt als eigenständiger Verantwortlicher und nicht als Auftragsbearbeiter für: (a) die Konto- und Abrechnungsbeziehung mit dem Kunden; (b) Supportanfragen über das integrierte Support-Widget und das Kontaktformular; (c) technische Fehlerdiagnosen zur Aufrechterhaltung des Betriebs; und (d) Besucher·innen der öffentlichen Website logsheet.ch. Diese Bearbeitungen richten sich nach der LogSheet-Datenschutzerklärung, nicht nach diesem AVV. Anhang A weist sie ausdrücklich aus.

1.4 Dauer. Dieser AVV tritt zum genannten Datum in Kraft und gilt so lange, wie LogSheet Personendaten im Auftrag des Kunden bearbeitet, d. h. für die Dauer des Hauptvertrags zuzüglich der Rückgabe- und Löschfrist gemäss Ziff. 12.

2. Art und Zweck der Bearbeitung

LogSheet führt im Auftrag des Kunden folgende Bearbeitungen durch:

Die Kategorien der Daten und der betroffenen Personen sind in Anhang A aufgeführt.

3. Weisungen des Verantwortlichen

3.1 LogSheet bearbeitet Personendaten nur auf dokumentierte Weisung des Kunden, einschliesslich hinsichtlich der Übermittlung in Drittstaaten. Hauptvertrag, dieser AVV sowie die Nutzung der Konfigurationsmöglichkeiten der Anwendung durch den Kunden (Rollen, Abteilungen, Absenz-Vertraulichkeitseinstellung, Aufbewahrungsentscheide, Exporte, Löschungen) bilden die dokumentierten Weisungen des Kunden.

3.2 LogSheet informiert den Kunden unverzüglich, wenn eine Weisung nach seiner Auffassung gegen das revDSG, die DSGVO oder eine andere anwendbare Datenschutzbestimmung verstösst. LogSheet kann die Ausführung dieser Weisung bis zu deren Bestätigung oder Anpassung aussetzen.

3.3 LogSheet nutzt die Daten des Kunden nicht für eigene Zwecke, verkauft sie nicht, verwendet sie nicht für Werbung und nutzt sie nicht zum Training von Machine-Learning- oder KI-Modellen. LogSheet darf aggregierte, nicht identifizierende Nutzungsstatistiken zur Kapazitätsplanung und Verbesserung des Dienstes erstellen.

3.4 Der Kunde sichert zu, dass er für die in LogSheet eingegebenen Daten über eine Rechtsgrundlage verfügt, seine Mitarbeitenden gemäss Art. 19 revDSG (bzw. Art. 13/14 DSGVO) informiert hat und die arbeitsrechtlichen Grenzen der Mitarbeiterüberwachung einhält, insbesondere Art. 26 ArGV 3, der Überwachungssysteme zur Verhaltenskontrolle untersagt.

4. Vertraulichkeit

4.1 LogSheet behandelt sämtliche unter diesem AVV bearbeiteten Personendaten vertraulich und gibt sie ausser an die in Anhang B genannten Unterauftragsbearbeiter oder aufgrund zwingender gesetzlicher Vorschriften nicht an Dritte weiter.

4.2 Der Zugriff auf Kundendaten in der Produktivumgebung ist auf diejenigen Personen beschränkt, die ihn für Betrieb und Support benötigen. Bei Inkrafttreten ist dies eine einzige Person: Ben Chaulet, Betreiber von LogSheet. Diese Person unterliegt einer Vertraulichkeitspflicht, die über das Ende der Tätigkeit hinaus fortbesteht. Künftige Mitarbeitende, Beauftragte oder Freelancer mit Zugriff werden vor Zugriffsgewährung schriftlich gleichwertig zur Vertraulichkeit verpflichtet.

4.3 Ist LogSheet gesetzlich zur Offenlegung von Kundendaten gegenüber einer Behörde verpflichtet, informiert LogSheet den Kunden — soweit rechtlich zulässig — vorgängig und beschränkt die Offenlegung auf das rechtlich Geforderte.

5. Sicherheit der Bearbeitung (TOM)

5.1 LogSheet trifft angemessene technische und organisatorische Massnahmen («TOM»), um ein dem Risiko entsprechendes Schutzniveau zu gewährleisten, gemäss Art. 8 revDSG und Art. 1–3 der Datenschutzverordnung (DSV) sowie, soweit anwendbar, Art. 32 DSGVO. Die geltenden Massnahmen sind in Anhang C beschrieben.

5.2 LogSheet berücksichtigt, dass die Daten besonders schützenswerte Personendaten im Sinne von Art. 5 lit. c Ziff. 2 revDSG (Daten über die Gesundheit) enthalten, da Absenzen als Krankheit erfasst werden können und die Freitextfelder für Bemerkungen und Genehmigungskommentare Gesundheitsangaben enthalten können. Anhang C beschreibt die hierfür spezifischen Massnahmen.

5.3 LogSheet kann die TOM jederzeit anpassen, sofern das Schutzniveau nicht sinkt. Wesentliche Reduktionen werden dem Kunden vorgängig mitgeteilt.

6. Beizug weiterer Auftragsbearbeiter

6.1 Allgemeine Genehmigung. Der Kunde erteilt LogSheet die allgemeine Genehmigung zum Beizug weiterer Auftragsbearbeiter. Die bei Inkrafttreten beigezogenen sind in Anhang B aufgeführt.

6.2 Bedingungen. LogSheet verpflichtet jeden weiteren Auftragsbearbeiter schriftlich auf im Wesentlichen gleichwertige Datenschutzpflichten wie in diesem AVV und haftet dem Kunden gegenüber vollumfänglich für deren Erfüllung.

6.3 Änderungen. LogSheet informiert den Kunden mindestens 30 Tage vor Aufnahme oder Wechsel eines weiteren Auftragsbearbeiters per E-Mail an die administrative Kontaktadresse des Kunden sowie durch Aktualisierung der öffentlichen Unterauftragsbearbeiter-Liste unter logsheet.ch/subprocessors, die das Datum ihrer letzten Änderung trägt (diese Adresse führt zum Abschnitt «Unterauftragsbearbeiter» der Datenschutzerklärung). Der Kunde kann innerhalb dieser Frist aus sachlichen, dokumentierten Datenschutzgründen widersprechen. Kommt keine Einigung zustande, kann der Kunde den betroffenen Teil des Hauptvertrags ohne Kostenfolge auf den Zeitpunkt des Wirksamwerdens der Änderung kündigen.

6.4 Verbindungen zu KI-Assistenten (durch die Nutzerin oder den Nutzer veranlasster Export). LogSheet bietet eine optionale Verbindung an, mit der eine berechtigte Person des Kunden Arbeitszeitdaten über eine reine Leseschnittstelle einem KI-Assistenten nach eigener Wahl des Kunden zugänglich machen kann. Die Verbindung wird pro Person eingerichtet, setzt deren Anmeldung und ausdrückliche Einwilligung voraus, beschränkt sich auf das Lesen von Daten und kann jederzeit durch die Person oder durch den Kunden widerrufen werden. Besteht eine solche Verbindung, so bleibt der Kunde Verantwortlicher und der Anbieter des KI-Assistenten handelt als Auftragsbearbeiter des Kunden und nicht von LogSheet: LogSheet wählt den Anbieter nicht aus, bestimmt die Zwecke der Bearbeitung nicht und übermittelt keine Daten ausser auf eine mit der Einwilligung dieser Person authentifizierte Anfrage hin. Der Anbieter ist damit kein Unterauftragsbearbeiter von LogSheet, erscheint nicht in Anhang B, und es obliegt dem Kunden, die erforderlichen Vereinbarungen mit ihm zu treffen.

Für jede solche Verbindung gelten zwei Schutzmassnahmen. Erstens pseudonymisiert LogSheet die Daten, bevor sie die Plattform verlassen: Namen natürlicher Personen werden durch ihre Initialen zusammen mit einem stabilen, nicht umkehrbaren Code ersetzt, E-Mail-Adressen und Telefonnummern werden maskiert, und die Firma des Kunden wird durch einen Code ersetzt. Der Anbieter erhält somit Arbeitszeitdaten, die keiner identifizierten natürlichen Person unmittelbar zugeordnet werden können, und LogSheet übermittelt die Identifikatoren nicht, die dies ermöglichen würden. Zweitens erhalten Administratorinnen und Administratoren individuell zuordenbare Arbeitszeitaufzeichnungen nur für Zeiträume, welche die betroffene Person freigegeben hat; für alle übrigen Zeiträume stehen ausschliesslich aggregierte Zahlen über mindestens drei Personen zur Verfügung. Der Kunde bleibt dafür verantwortlich, seine Mitarbeitenden über die Nutzung einer solchen Verbindung zu informieren, soweit sein eigenes Rechtsumfeld dies verlangt.

7. Unterstützung bei den Rechten betroffener Personen

7.1 LogSheet unterstützt den Kunden unter Berücksichtigung der Art der Bearbeitung mit geeigneten technischen und organisatorischen Massnahmen bei der Erfüllung seiner Pflicht, Gesuche zur Ausübung der Rechte nach Art. 25–29 revDSG (Auskunft, Berichtigung, Löschung, Datenherausgabe/Portabilität, Widerspruch) und, soweit anwendbar, nach Kapitel III DSGVO zu beantworten.

7.2 Richtet eine betroffene Person ein solches Gesuch direkt an LogSheet, beantwortet LogSheet es nicht materiell, sondern leitet es unverzüglich an den Kunden weiter und verweist die betroffene Person an den Kunden als Verantwortlichen.

7.3 Was die Anwendung bereits bietet. Der Kunde kann die meisten Gesuche selbst erfüllen, ohne Mitwirkung von LogSheet:

• Auskunft / Portabilität: Monats- und Jahresexporte nach Excel, Lohn-CSV-Exporte, Archivansicht und der Jahreskalender je Mitarbeitende·r.
• Berichtigung: Administrator·innen können Einträge und Anstellungsparameter für jeden nicht gesperrten/genehmigten Monat korrigieren; ein gesperrter Monat kann von einer Administration wieder geöffnet werden.
• Löschung: Administrator·innen können Einträge löschen und Konten deaktivieren; Mitarbeitende können ihr eigenes Konto in der iPhone-App löschen (siehe Ziff. 7.4).

7.4 Selbstständige Kontolöschung und ihre bewussten Grenzen. Die LogSheet-iPhone-App bietet die Kontolöschung direkt in der App. Wird sie ausgelöst:

• wird das Firebase-Authentication-Konto gelöscht und alle Refresh-Tokens werden widerrufen — die Person kann sich nirgends mehr anmelden;
• werden ihre identifizierenden Profildaten (Anzeigename, E-Mail-Adresse, Geburtsdatum, Personalnummer) aus dem Benutzerdokument entfernt und durch eine Markierung «Deleted employee» ersetzt;
• bleiben ihre Zeiterfassungen, Tageseinträge und Kundenarbeitseinträge bewusst erhalten, verknüpft mit einer Kennung, die im System keiner Person mehr entspricht, zusammen mit den Anstellungsparametern (Pensum, Wochenplan, Ferienanspruch), ohne die diese Datensätze nicht mehr interpretierbar wären.

Grund dafür ist, dass diese Datensätze die Arbeitszeitdokumentation des Kunden darstellen, die dieser gesetzlich aufbewahren muss (Art. 73 Abs. 2 ArGV 1: fünf Jahre) und die daher nicht zur Löschung durch Mitarbeitende steht. Eine weitergehende Löschung kann nur der Kunde als Verantwortlicher anweisen. LogSheet stellt gegenüber betroffenen Personen nie mehr Löschung in Aussicht, als tatsächlich erfolgt.

7.5 Unterstützung, die über die genannten Selbstbedienungsfunktionen hinausgeht, wird auf Anfrage in angemessenem Umfang geleistet; unverhältnismässigen Aufwand kann LogSheet nach vorgängiger Mitteilung in Rechnung stellen.

8. Unterstützung bei weiteren Pflichten des Verantwortlichen

LogSheet unterstützt den Kunden unter Berücksichtigung der Art der Bearbeitung und der ihm zur Verfügung stehenden Informationen bei:

• der Sicherheit der Bearbeitung (Art. 8 revDSG / Art. 32 DSGVO) — durch Anhang C und die angemessene Beantwortung von Sicherheitsfragebogen;
• Datenschutz-Folgenabschätzungen (Art. 22 revDSG / Art. 35 DSGVO) und der vorgängigen Konsultation der Aufsichtsbehörde — durch Bereitstellung der erforderlichen technischen Informationen;
• der Meldung von Verletzungen der Datensicherheit (Art. 24 revDSG / Art. 33–34 DSGVO) — gemäss Ziff. 9.

9. Verletzungen der Datensicherheit

9.1 Meldung an den Kunden. LogSheet meldet dem Kunden jede Verletzung der Datensicherheit, die dessen Personendaten betrifft, unverzüglich und in jedem Fall innerhalb von 48 Stunden nach Kenntnisnahme, per E-Mail an die administrative Kontaktadresse des Kunden und, wenn ein schnellerer Kanal angezeigt ist, telefonisch.

9.2 Inhalt. Die Meldung beschreibt, soweit bekannt: Art der Verletzung; Kategorien und ungefähre Zahl der betroffenen Personen und Datensätze; wahrscheinliche Folgen; getroffene oder vorgeschlagene Massnahmen zur Behebung und Abschwächung; sowie eine Kontaktstelle. Sind Angaben nicht sofort verfügbar, werden sie ohne weitere unangemessene Verzögerung schrittweise nachgeliefert.

9.3 Rollen. Der Kunde beurteilt als Verantwortlicher, ob die Verletzung voraussichtlich zu einem hohen Risiko für die Persönlichkeit oder die Grundrechte der betroffenen Personen führt, und meldet sie gegebenenfalls so rasch als möglich dem Eidgenössischen Datenschutz- und Öffentlichkeitsbeauftragten (EDÖB / PFPDT / FDPIC) nach Art. 24 Abs. 1 revDSG und/oder innert 72 Stunden der zuständigen EU-Aufsichtsbehörde nach Art. 33 DSGVO, und informiert die betroffenen Personen, soweit erforderlich. LogSheet nimmt diese Meldung nicht namens des Kunden vor, ausser bei ausdrücklicher schriftlicher Weisung.

9.4 Zusammenarbeit und Dokumentation. LogSheet arbeitet bei Abklärung und Behebung mit dem Kunden zusammen und dokumentiert Sachverhalt, Auswirkungen und Abhilfemassnahmen.

10. Auditrechte

10.1 LogSheet stellt dem Kunden alle zum Nachweis der Einhaltung dieses AVV erforderlichen Informationen zur Verfügung, in erster Linie in Form der Anhänge dieses AVV, seiner Sicherheitsdokumentation sowie der Zertifizierungen und Auditberichte seiner Unterauftragsbearbeiter (insbesondere die ISO/IEC-27001-, 27017-, 27018- und SOC-2/3-Berichte von Google Cloud, verfügbar über das Google-Cloud-Compliance-Portal).

10.2 Reichen diese Unterlagen nicht aus, kann der Kunde — auf eigene Kosten, höchstens einmal pro Kalenderjahr (ausser nach einer Verletzung der Datensicherheit), mit schriftlicher Ankündigung von 30 Tagen, während der Geschäftszeiten und unter Wahrung der Vertraulichkeit — ein Audit durchführen oder eine·n unabhängige·n Prüfer·in beauftragen, die·der kein Wettbewerber von LogSheet ist. Das Audit darf den Betrieb nicht stören und die Vertraulichkeit der Daten anderer Kunden nicht beeinträchtigen.

10.3 Audits in den Rechenzentren der Unterauftragsbearbeiter sind ausgeschlossen; an ihre Stelle treten deren Zertifizierungen und Auditberichte. LogSheet hat keinen physischen Zugang zur Google-Cloud-Infrastruktur.

11. Internationale Übermittlung und Datenstandort

11.1 Primärer Speicherort. Die Anwendungsdaten des Kunden — Benutzerprofile, Zeiterfassungen, Tageseinträge, Absenzen, Kunden-/Projektdaten, Rechnungen, Benachrichtigungen, Sicherungen — werden in Google Cloud Firestore in der Multiregion `nam5` — den Vereinigten Staaten gespeichert (am 29. Juli 2026 in der Firebase-Konsole bestätigt). Die Cloud Functions, die diese Daten bearbeiten, laufen in der Region `europe-west6` (Zürich, Schweiz): die Verarbeitungslogik ist damit schweizerisch, die Datenbank selbst nicht. Die Übermittlung von Personendaten in die USA stützt sich auf die Zertifizierung von Google LLC nach dem Swiss–U.S. Data Privacy Framework und dem EU–U.S. Data Privacy Framework sowie auf die Standardvertragsklauseln mit Schweizer Zusatz im Google Cloud Data Processing Addendum.

11.2 Nicht regionsgebundene Dienste. Folgende Komponenten werden von Google auf globaler Infrastruktur bereitgestellt und sind nicht auf die Schweiz beschränkt:

• Firebase Authentication (identitytoolkit.googleapis.com) — speichert E-Mail-Adresse, Passwort-Hash, Konto-Kennung (UID) und Anmeldezeitstempel. Google bietet für diesen Dienst keine Schweiz-/EU-Residenzoption; die Bearbeitung kann in den USA erfolgen.
• Firebase Hosting — die statische Webanwendung wird über Googles globales CDN ausgeliefert; Serverprotokolle können ausserhalb der Schweiz bearbeitet werden.
• App Check (reCAPTCHA v3 im Web, Apple App Attest auf iOS) — Attestierungs-Tokens sowie, bei reCAPTCHA, IP-Adresse und Interaktionssignale.
• Google Analytics for Firebase — nur öffentliche Website, einwilligungsgesteuert; siehe Ziff. 11.5.

11.3 Rechtsgrundlage. Übermittlungen in die USA sind gedeckt durch (i) den Angemessenheitsbeschluss des Bundesrates zur Anerkennung des Swiss–U.S. Data Privacy Framework (Google LLC ist nach dem EU–U.S. DPF und dessen Schweizer Erweiterung zertifiziert) und ergänzend durch (ii) die Standardvertragsklauseln mit Schweizer Zusatz im Cloud Data Processing Addendum von Google, dem LogSheet beigetreten ist. Der Kunde nimmt dies zur Kenntnis.

11.4 Ausgehende E-Mail. Transaktions-E-Mails (Verifizierung, Passwortzurücksetzung, Willkommensnachricht, Erinnerungen, Digests, Betriebsmeldungen) werden über das authentifizierte SMTP-Relay der Hostpoint AG (Rapperswil-Jona, Schweiz) aus dem Postfach info@logsheet.ch mit implizitem TLS über Port 465 versandt. Der Nachrichteninhalt — Empfängeradresse, Anzeigename und Gegenstand der Benachrichtigung — durchläuft Schweizer Infrastruktur und wird dort gespeichert. Die Weiterleitung zum Mailanbieter der Empfänger·innen liegt ausserhalb der Kontrolle von LogSheet.

11.5 Analyse. Google Analytics for Firebase läuft nur auf der öffentlichen Website logsheet.ch, ausschliesslich nach Annahme des Cookie-Banners, und nie in der iPhone-App (der Mobile-Build ersetzt das Analysemodul durch ein bewusst wirkungsloses Modul). Innerhalb der authentifizierten Anwendung bearbeitet kein Analyse- oder Werbe-SDK Daten. In keiner der beiden Anwendungen ist ein SDK für Werbung, Attribution oder Session-Replay vorhanden — geprüft anhand der Abhängigkeitsmanifeste aller drei Pakete (Web, functions/, TimeSheetApp/).

11.6 iCal-Feed. Aktiviert eine·r Mitarbeitende·r den optionalen Kalenderfeed, werden Absenzereignisse über einen Cloud-Functions-Endpunkt (europe-west6) via HTTPS ausgeliefert, authentifiziert durch ein nicht erratbares Token in der Abonnement-URL. Der Feed enthält den Namen der Mitarbeitenden und deren Absenzen, bezeichnet nach den in Anhang A aufgeführten Kategorien. Nach dem Abonnieren liegt eine Kopie dieser Daten beim gewählten Kalenderanbieter (z. B. Apple, Google, Microsoft), ausserhalb der Kontrolle von LogSheet und des Kunden und ausserhalb des Anwendungsbereichs dieses AVV. Das Token kann jederzeit in der Anwendung ungültig gemacht und erneuert werden.

12. Rückgabe und Löschung nach Vertragsende

12.1 Nach Beendigung des Hauptvertrags kann der Kunde seine Daten innerhalb von 30 Tagen über die Excel-, CSV- und PDF-Exportfunktionen der Anwendung selbst exportieren. Auf schriftliches Verlangen innerhalb derselben Frist stellt LogSheet zusätzlich einen Export der Mandantendaten in einem strukturierten, gängigen und maschinenlesbaren Format bereit.

12.2 Nach Ablauf dieser Frist löscht LogSheet die Personendaten des Kunden innerhalb von 90 Tagen auch aus den aktiven Systemen, soweit nicht schweizerisches oder EU-Recht eine weitere Aufbewahrung verlangt. Restkopien in den automatischen Sicherungen von Google Cloud werden im ordentlichen Sicherungszyklus überschrieben.

12.3 Der Kunde nimmt zur Kenntnis, dass er als Arbeitgeber gesetzlichen Aufbewahrungspflichten für Arbeitszeitaufzeichnungen unterliegt (fünf Jahre nach Art. 73 Abs. 2 ArGV 1, zehn Jahre für buchhaltungsrelevante Unterlagen nach Art. 958f OR) und dass es ihm obliegt, diese Aufzeichnungen vor der Löschung zu exportieren und aufzubewahren.

12.4 Auf Verlangen bestätigt LogSheet die Löschung schriftlich.

13. Haftung, anwendbares Recht und Sonstiges

13.1 Die Haftung zwischen den Parteien richtet sich nach dem Hauptvertrag und, soweit dort nichts vereinbart ist, nach schweizerischem Recht. Keine Bestimmung dieses AVV beschränkt die Rechte betroffener Personen gegenüber einer der Parteien nach anwendbarem Datenschutzrecht.

13.2 Dieser AVV untersteht schweizerischem Recht unter Ausschluss der Kollisionsnormen und des CISG. Gerichtsstand ist Luzern, vorbehältlich zwingender Gerichtsstände.

13.3 Soweit die DSGVO auf die Bearbeitung des Kunden anwendbar ist, gilt dieser AVV auch als Vereinbarung nach Art. 28 Abs. 3 DSGVO; die Parteien schliessen die EU-Standardvertragsklauseln ab, soweit gesetzlich erforderlich.

13.4 Änderungen bedürfen der Schriftform (elektronische Form genügt). Die Unwirksamkeit einer Bestimmung berührt die übrigen nicht.

Abschluss dieses AVV

Dieser AVV steht für sich und wird elektronisch abgeschlossen; für die Bindungswirkung ist keine Unterschrift erforderlich. Der Kunde schliesst ihn bei der Registrierung seines Unternehmenskontos ab: Das Registrierungsformular hält fest, dass die registrierende Person im Namen des Unternehmens die Datenschutzerklärung und diesen Auftragsverarbeitungsvertrag annimmt, und verweist auf beide. LogSheet hält das Datum dieser Annahme beim Konto fest.

Die Person, die das Konto registriert, sichert zu, dass sie zum Abschluss dieses AVV im Namen des Kunden befugt ist.

Ein gegengezeichnetes PDF-Exemplar sowie eine Fassung mit den Angaben des Kunden sind auf Anfrage unter info@logsheet.ch erhältlich.

Anhang A — Kategorien der Daten und der betroffenen Personen

Bildet das tatsächlich von der Anwendung gespeicherte Datenmodell per 29. Juli 2026 ab (Firestore-Collections `users`, `timesheets` mit Subcollections, `projectTimesheets`, `customers`, `projects`, `invoices`, `notifications`, `archives`, `icalTokens`, `holidays`, `announcementAssignments`, `officeTaskAssignments`).

A.1 Kategorien betroffener Personen

A.2 Kategorien von Personendaten — Bearbeitung durch LogSheet als Auftragsbearbeiter

A.3 Kategorien von Personendaten — Bearbeitung durch LogSheet als Verantwortlicher (ausserhalb dieses AVV)

A.4 Häufigkeit und Umfang

Fortlaufende Bearbeitung während der Dauer des Hauptvertrags. Umfang: ein Datensatz je Mitarbeitende·r und Arbeitstag, zuzüglich Monatszusammenfassungen und wöchentlicher Sicherungsmomentaufnahmen.

Anhang B — Weitere Auftragsbearbeiter (Unterauftragsbearbeiter)

Stand 29. Juli 2026. Geprüft anhand von `firebase.json`, `.firebaserc`, `src/firebase.js`, `functions/index.js` und den Abhängigkeitsmanifesten aller drei Pakete.

Hinweise

• Kein Zahlungsdienstleister. LogSheet bindet keinen Zahlungsanbieter ein (weder Stripe noch PayPal). Die Planverwaltung erfolgt intern (free / enterprise mit Besitzstandsregel); eine allfällige Fakturierung erfolgt ausserhalb der Anwendung.
• Kein SDK für Analyse, Werbung, Attribution, Session-Replay, Fehlerverfolgung oder CRM über die beschriebene Google-Analytics-Messung hinaus. Geprüft: weder Sentry, PostHog, Mixpanel, Amplitude, Segment, Intercom, Crisp, Hotjar, Clarity, Meta-/LinkedIn-/TikTok-Pixel, Plausible noch Matomo in einem der drei Abhängigkeitsmanifeste.
• Die iPhone-App enthält überhaupt keine Analyse — der Mobile-Build löst das Analysemodul auf ein bewusst wirkungsloses Modul auf.
• Die öffentliche Website bindet zwei statische Badge-Bilder ein (Product Hunt, PostYourStartup). Beide werden von der eigenen Domain von LogSheet ausgeliefert; ihre Anzeige löst keine Anfrage an einen Drittanbieter aus und gibt keine Besucher-IP-Adresse preis.

Anhang C — Technische und organisatorische Massnahmen (TOM)

Art. 8 revDSG und Art. 1–3 DSV; Art. 32 DSGVO, soweit anwendbar. Jede nachstehende Massnahme entspricht etwas, das per 29. Juli 2026 tatsächlich im Code oder im Firebase-Projekt umgesetzt ist. Bekannte Lücken und geplante Verbesserungen werden hier bewusst aufgeführt statt weggelassen.

C.1 Vertraulichkeit — Zugriffskontrolle

Mandantentrennung. Jedes Dokument trägt eine companyId, und jeder Lese- und Schreibzugriff wird durch Firestore-Sicherheitsregeln geprüft, die sie mit derjenigen der aufrufenden Person vergleichen. Collection-Group-Abfragen über Tageseinträge und Kundenarbeitseinträge werden auf Regelebene nach companyId gefiltert; ein Client, der den Filter weglässt, wird abgewiesen statt mit fremden Mandantendaten bedient. Die Regeldatei gilt als Schnittstellenvertrag und ist durch eine automatisierte Testsuite (30 Tests) abgedeckt, die vor jeder Auslieferung bestehen muss.

Rollenmodell. Drei Rollen (user, admin, super_admin) sowie ein Delegationsmechanismus: Eine Administration kann einzelnen Mitarbeitenden Zugriff nur auf bestimmte Admin-Bereiche gewähren, wahlweise beschränkt auf eine oder mehrere Abteilungen und nur lesend (settings.viewableDepartments). Die Abteilungsbeschränkung wird in den Sicherheitsregeln durchgesetzt, nicht nur in der Oberfläche, und liest die Abteilung der Zielperson live aus deren Benutzerdokument statt aus einem clientseitig gelieferten Wert.

Serverseitige Autorität. Sensible Vorgänge laufen in Cloud Functions mit dem Admin-SDK und prüfen die Berechtigung serverseitig erneut: Firmenerstellung, Anlegen von Mitarbeitendenkonten, Domain-Verifizierung, Bereinigung verwaister Konten, Kontolöschung, Ausstellung von iCal-Tokens. Ein Client kann sie nicht durch Manipulation der Oberfläche auslösen.

Minimalprinzip im Betrieb. Produktivzugriff ist auf den Betreiber beschränkt (Ziff. 4.2). Administrationsskripte lesen ihre Zugangsdaten aus .env, die nicht im Git-Repository liegt.

C.2 Vertraulichkeit — Pseudonymisierung und Datenminimierung

• Vertraulichkeit von Krankheitsabsenzen: Eine Einstellung auf Firmenebene verbirgt den Grund der Absenz einer Kollegin oder eines Kollegen vor den übrigen Mitarbeitenden; eine eingeschränkt lesende Person sieht «Abwesend» statt «Krank». Die eigene Zeile zeigt Mitarbeitenden stets den tatsächlichen Grund. Durchgesetzt über einen gemeinsam genutzten Hook in Web- und Mobile-App, sodass beide nicht auseinanderdriften können.
• Kontolöschung ist eine Markierung, keine Vollöschung: Identifizierende Felder werden entfernt und durch eine nicht identifizierende Markierung ersetzt, während die Arbeitszeitaufzeichnung — die der Arbeitgeber aufbewahren muss — an einer Kennung hängen bleibt, die keiner Person mehr entspricht (Ziff. 7.4). Das ist Pseudonymisierung durch Technikgestaltung.
• Fehlerprotokolle werden gekürzt: Fehlermeldung und Kontext auf 1 000 Zeichen, User-Agent auf 300 Zeichen begrenzt; identische Fehler werden innerhalb eines 60-Sekunden-Fensters entdoppelt, damit die Diagnose minimal bleibt.
• Keine Verhaltensüberwachung: Die Anwendung erfasst die Arbeitszeit so, wie Mitarbeitende sie eingeben. Es gibt keine Tastatur-, Bildschirm-, Standort- oder Aktivitätsüberwachung. lastActive ist ein einzelner Zeitstempel für die Präsenzanzeige in der Teamansicht.
• Keine Kontoenumeration: Passwortzurücksetzung und Anmeldehilfe antworten identisch, unabhängig davon, ob die Adresse existiert, und sind serverseitig ratenbegrenzt.

C.3 Vertraulichkeit — Verschlüsselung

• Übertragung: Durchgehend HTTPS/TLS. HSTS mit max-age=63072000; includeSubDomains; preload. Ausgehendes SMTP mit implizitem TLS über Port 465.
• Ruhende Daten: Alle Firestore- und Cloud-Functions-Daten werden von Google Cloud standardmässig verschlüsselt gespeichert (AES-256, von Google verwaltete Schlüssel).
• Passwörter: Ausschliesslich von Firebase Authentication gespeichert und geprüft (scrypt); LogSheet sieht und speichert nie ein Passwort. Bei Registrierung und Passwortänderung wird eine Stärke-Checkliste erzwungen.
• Geheimnisse: Das SMTP-Passwort liegt im Google Secret Manager und wird nur den Funktionen zugeführt, die es benötigen; keine Zugangsdaten im Repository. Früher fest im Code hinterlegte Skript-Passwörter wurden im Juli 2026 entfernt, bleiben aber bis zu ihrer Erneuerung in der Git-Historie sichtbar.

C.4 Vertraulichkeit — Härtung von Anwendung und Plattform

• App Check weist nach, dass Anfragen aus der echten Anwendung stammen: reCAPTCHA v3 im Web, Apple App Attest auf iOS. Die Erzwingung ist derzeit für Firebase Authentication (`identitytoolkit`) aktiviert und für Firestore deaktiviert (geprüft am 27. Juli 2026). Die Aktivierung für Firestore ist ein bewusst offener Entscheid, da sie hinter der Zwangsaktualisierungs-Schwelle der Mobile-App abgestimmt werden muss.
• Strikte Content-Security-Policy auf jeder Antwort, mit frame-ancestors 'none', object-src 'none', base-uri 'self', form-action 'self' und expliziter connect-src-Positivliste; ergänzt durch X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin und eine Permissions-Policy, die Kamera, Mikrofon, Standort, Zahlung und USB deaktiviert.
• Registrierungskontrolle: Selbstregistrierung ist nur für E-Mail-Domains möglich, deren Kontrolle die Firma nachgewiesen hat — per DNS-TXT-Eintrag oder Bestätigungsmail an ein Standardpostfach. Kostenlose und Wegwerf-Domains werden anhand einer Sperrliste mit über 12 000 Einträgen abgewiesen. Die Firmenliste ist nicht öffentlich lesbar; die Suche läuft über einen serverseitigen Aufruf.
• Ratenbegrenzung für Passwortzurücksetzung und Anmeldehilfe, je Adresse und serverseitig durchgesetzt.
• Der iCal-Feed ist durch ein 192-Bit-Zufallstoken (crypto.randomBytes(24)) geschützt, das Mitarbeitende jederzeit erneuern können; ein unbekanntes Token liefert 404 statt 401, sodass ein durchprobiertes Token nicht von einem Tippfehler zu unterscheiden ist. Der Feed ist konstruktionsbedingt eine Inhaber-URL: Wer die URL hat, kann sie lesen. Das liegt am iCal-Standard; der Punkt ist für Mitarbeitende dokumentiert und das Token ist erneuerbar.

C.5 Integrität

• Die Firestore-Sicherheitsregeln sind der einzige Durchsetzungspunkt für Schreibvorgänge und durch eine automatisierte Testsuite abgedeckt.
• Monatssperre/-genehmigung: Ein genehmigter Monat ist eingefroren; der automatische Sicherungsjob überspringt genehmigte Monate ausdrücklich, sodass ein Archiv nicht unbemerkt überschrieben werden kann.
• Gespeicherte Feldnamen gelten als eingefrorener Vertrag zwischen Web- und iPhone-Client (Felder dürfen ergänzt, nie umbenannt werden), was stille Datenkorruption während der 24–48-stündigen App-Store-Verzögerung verhindert.
• Rechnungsnummern werden in einer Firestore-Transaktion vergeben; zwei Administrationen können nicht kollidieren.
• Erkennung stiller Fehler: Jeder abgewiesene Schreibvorgang wird erfasst, protokolliert und dem Betreiber per E-Mail gemeldet, damit ein Berechtigungs- oder Kontingentfehler nicht unbemerkt Daten von Mitarbeitenden verliert.

C.6 Verfügbarkeit und Belastbarkeit

• Google Cloud Firestore in nam5 bietet Multiregions-Replikation und automatische plattformseitige Sicherungen innerhalb dieser Multiregion (Vereinigte Staaten).
• Anwendungsseitige Sicherung: Eine geplante Cloud Function (snapshotWeeklyTimesheets, jeden Montag 03:00 Uhr Europe/Zurich) schreibt eine Momentaufnahme der Tageseinträge und Totale jedes nicht genehmigten Monats in eine backups-Subcollection. Die Momentaufnahmen sind je ISO-Woche idempotent. Administrationen können in der Oberfläche daraus wiederherstellen.
• Nutzer·innen können ihre eigenen und die Firmendaten jederzeit nach Excel, CSV oder PDF exportieren — eine unabhängige Offline-Kopie unter der Kontrolle des Kunden.
• Cloud Functions laufen mit begrenzter maximaler Instanzzahl, was Last- und Kostenausreisser eindämmt.

C.7 Regelmässige Überprüfung, Bewertung und Evaluierung

• Automatisierte Unit-Tests der gemeinsamen Fachlogik (npm run test:unit) und eine eigene Testsuite für die Firestore-Regeln (npm run test:rules), beide bei jedem Push und Pull Request in der CI ausgeführt, für Web- und Mobile-Paket getrennt.
• Statische Analyse (Lint) mit Nulltoleranz für Warnungen in der CI.
• Im Juli 2026 wurde ein dokumentiertes, rein lesendes Sicherheits- und Skalierbarkeits-Audit durchgeführt; der kritische Befund (eine zu weit gefasste Leseregel auf den Archiven) wurde behoben, die übrigen Befunde werden mit ausdrücklichen Entscheiden nachgeführt.
• Abhängigkeiten sind in Lockfiles fixiert und werden bewusst aktualisiert.

C.8 Organisatorische Massnahmen

• Der Datenschutz liegt in der persönlichen Verantwortung des Betreibers; einzige Kontaktstelle ist info@logsheet.ch.
• Vertraulichkeitspflichten gemäss Ziff. 4.2.
• Verträge mit Unterauftragsbearbeitern: das Google Cloud Data Processing Addendum; die Apple-Developer-Program-Vereinbarungen; und für die Hostpoint AG die in ihren Allgemeinen Geschäftsbedingungen enthaltenen Bestimmungen zur Auftragsbearbeitung, die den Anforderungen des revidierten DSG entsprechen und ohne gesonderte Unterzeichnung automatisch für das Konto gelten. Von jedem liegt eine datierte Kopie vor.
• Vorfallbehandlung: Betriebswarnungen (Datenbankfehler, Neuregistrierungen, Supporttickets) gehen per E-Mail an den Betreiber; die Behandlung von Verletzungen richtet sich nach Ziff. 9.
• Ein schriftliches Incident-Response-Handbuch sowie ein dokumentiertes Aufbewahrungs- und Löschkonzept liegen vor. Ein dokumentiertes Onboarding für künftige Personen mit Produktivzugriff ist ein offener Punkt; ein solches besteht heute nicht, da der Zugriff auf eine einzige Person beschränkt ist (Ziff. 4.2).

C.9 Besondere Massnahmen für besonders schützenswerte Daten (Gesundheit)

• Krankheitstage werden als Tageskategorie erfasst, nie als Diagnose. LogSheet fragt keine medizinischen Details ab, und die Oberfläche verlangt keine.
• Die firmenweite Absenz-Vertraulichkeitseinstellung beschränkt die Sichtbarkeit des Absenzgrundes auf die betroffene Person und autorisierte Administrationen (C.2).
• Freitextfelder für Bemerkungen und Genehmigungskommentare können Gesundheitsangaben enthalten. Der Kunde als Verantwortlicher muss seine Administrationen anweisen, dort keine medizinischen Details zu erfassen. Die Anwendung unterstützt diese Anweisung: Neben jedem Freitextfeld für Bemerkungen und Genehmigungskommentare wird dauerhaft ein Hinweis angezeigt, keine medizinischen oder anderen besonders schützenswerten Angaben zu erfassen.
• Für diese Daten gelten dieselben Zugriffs-, Verschlüsselungs-, Mandantentrennungs- und Aufbewahrungsmassnahmen wie für alle übrigen; es besteht kein separater oder schwächer geschützter Exportweg.

Ende des Dokuments. Mustervorlage — vor jeder Verwendung durch eine auf Schweizer Datenschutzrecht spezialisierte Anwaltskanzlei zu prüfen.