DSGVO-/DSG-Audit — Zeiterfassung Gartenhotel Maria Theresia

Stand: 19.05.2026 Geprüfter Stand: Migrationen 001–016 + aktueller Code (Phase 1 In-App-Notifications integriert). Geltungsbereich: Anwendung „Stundenerfassung" für Mitarbeiter:innen der Gartenhotel Maria Theresia GmbH, Hall in Tirol. Verantwortlicher i. S. v. Art. 4 Z 7 DSGVO: Gartenhotel Maria Theresia GmbH (Arbeitgeber).

---

1. Executive Summary

Das Projekt erfüllt die technischen Datenschutzgrundlagen auf einem überdurchschnittlich guten Niveau für ein KMU: durchgängige Row-Level-Security, Einwilligungs-Flow für Geodaten, EU-Hosting, Datenminimierung beim GPS, separater Schutz von Gesundheitsdaten (Krankenstand). Die organisatorischen Pflichten und die Selbstbedienungs-Rechte der Betroffenen sind dagegen erst teilweise umgesetzt. Vor Produktivbetrieb sind drei Themen kritisch zu klären: (a) Auftragsverarbeitungsvertrag mit Supabase, (b) Betriebsvereinbarung zur Geodaten-Erfassung gem. § 96 ArbVG, (c) Selbst-Auskunft/Datenexport für Mitarbeiter:innen.

Risiko-Einstufung: mittel. Sofortmaßnahmen sind administrativer Natur, keine technischen Showstopper.

---

2. Bewertung im Detail

Legende: ✓ erfüllt · ⚠ teilweise / verbesserungswürdig · ✖ fehlt

2.1 Rechtsgrundlagen (Art. 6, 9 DSGVO)

Punkt	Status	Befund
Rechtsgrundlage Zeiterfassung	✓	§ 26 AZG (rechtliche Verpflichtung, Art. 6 Abs. 1 lit. c) korrekt in `app/datenschutz/page.tsx` benannt.
Rechtsgrundlage Planung	✓	Vertragserfüllung Art. 6 Abs. 1 lit. b.
Rechtsgrundlage GPS-Stempel	⚠	Aktuell „berechtigtes Interesse / Vertragserfüllung". Für Mitarbeitermonitoring gilt Einwilligung nicht als gültige Grundlage (kein freier Wille im Beschäftigtenverhältnis). Saubere Grundlage: Betriebsvereinbarung gem. § 96 Abs. 1 Z 3 ArbVG (kontrollwürdige Datenermittlung).
Sensitive Daten — Krankenstand	✓	Tabelle `abwesenheiten` speichert nur Zeitraum + Status, keine Diagnose. RLS strikt auf Betroffene + Admin/Manager. Verschlüsselt auf Datenbank-Ebene (Supabase Postgres).
SV-Nummer	✓	Eigene Spalte `mitarbeiter.sv_nummer`, RLS-geschützt. Validierung über `lib/validierung.ts`.

2.2 Informationspflichten (Art. 13, 14 DSGVO)

Punkt	Status	Befund
Datenschutzerklärung vorhanden	✓	`/datenschutz` enthält 8 Abschnitte (Verantwortlicher, Zweck, Daten, Speicherdauer, Empfänger, Rechte, Geodaten, AZG-Eckwerte).
Verantwortlicher konkret benannt	⚠	Aktuell generisch „der jeweilige Arbeitgeber". Vor Deploy: konkret „Gartenhotel Maria Theresia GmbH, Anschrift, FN" eintragen.
Datenkategorien aufgelistet	✓	Stammdaten, Arbeitszeiten, GPS-Punkte, Signaturen, IP/User-Agent.
Speicherdauer	✓	7 Jahre gem. § 132 BAO.
Empfänger / Datenfluss	⚠	Erwähnt Supabase Irland, aber: Supabase Inc. ist eine US-Firma — EU-US-Drittlandtransfer mit Standardvertragsklauseln (SCC) muss explizit benannt sein.
Betroffenenrechte erklärt	✓	Auskunft/Berichtigung/Löschung/Einschränkung/Datenübertragbarkeit/Widerspruch + Beschwerderecht bei dsb.gv.at.
Datenschutzbeauftragte:r	✖	Keine Kontaktangabe. Bei < 250 MA grundsätzlich nicht zwingend, aber ein Ansprechpartner sollte genannt sein.
Cookie-Hinweise	✖	App nutzt Session-Cookies (Supabase Auth). Aktuell kein Cookie-Banner. Für rein technisch notwendige Cookies nicht zwingend (Art. 5 Abs. 3 TKG / ePrivacy), aber kurzer Hinweis im Datenschutz wäre sauber.

2.3 Betroffenenrechte (Art. 15–22 DSGVO)

Recht	Status	Befund
Auskunft (Art. 15)	⚠	Mitarbeiter:in sieht eigene Daten im Mein-Wochenplan/Mein-Bereich. Echte „Datenkopie aller Verarbeitungen" als Download fehlt.
Berichtigung (Art. 16)	✓	`/meine-daten` erlaubt Mitarbeiter:innen, Stammdaten (Name, E-Mail, Telefon, SV-Nr) selbst zu korrigieren.
Löschung (Art. 17)	✖	Kein Self-Service. Mitarbeiter:in muss sich an Admin wenden. Logisch korrekt bei laufenden Aufbewahrungsfristen, aber Anfrage-Flow ist nicht abgebildet.
Einschränkung (Art. 18)	✖	Kein UI-Mechanismus.
Datenübertragbarkeit (Art. 20)	✖	Kein CSV/JSON-Export der eigenen Daten. Größte UI-Lücke.
Widerspruch (Art. 21)	⚠	Einwilligung Geodaten ist widerrufbar (`einwilligung_geodaten`-Feld). Aber: kein UI-Button „Widerrufen".
Keine automatisierte Entscheidung	✓	AZG-Live-Check ist beratend, jede Genehmigung erfolgt durch Admin manuell.

2.4 Technische und organisatorische Maßnahmen (Art. 32 DSGVO)

Punkt	Status	Befund
Row-Level-Security	✓	33 Policies in `schema.sql` + weitere in 11 Migrationen. Jede Tabelle hat passende Policies.
Verschlüsselung in Transit	✓	Supabase erzwingt TLS 1.2+ für API/Postgres.
Verschlüsselung at Rest	✓	Supabase Postgres ist AES-256-encrypted at rest (Supabase-Standard).
Auth	✓	Supabase Auth (E-Mail + Passwort + Magic Link).
2FA / MFA	✖	Aktuell keine 2FA. Für Admin-Rollen empfohlen. In `CLAUDE.md` als offener Punkt erfasst.
HTTP-Security-Header	✖	Aktuell keine HSTS / CSP / X-Frame-Options / Referrer-Policy konfiguriert. Sollte in `next.config.mjs` über `headers()` ergänzt werden.
Server-Action-Origins	✓	`next.config.mjs` setzt `experimental.serverActions.allowedOrigins` explizit (CSRF-Hardening).
Audit-Log	⚠	Tabelle `audit_log` existiert (`schema.sql`, Migration 003). Einige Trigger schreiben rein (z. B. neue Dokument-Version, AUVA-Sync). Aber: nicht jede sensible Mutation loggt sich ein. Bestehende Lücken: kein Logging beim Genehmigen/Ablehnen von Abwesenheiten/Überstunden, kein Logging bei Mitarbeiter-Stammdatenänderungen, kein Logging bei Geodaten-Einwilligungs-Widerruf.
Backups / Recovery	⚠	Supabase Pro-Plan macht automatische tägliche PITR-Backups (7 Tage Retention im Free, 30 Tage Pro). Kein eigenes Recovery-Drill-Dokument.
Datenpannen-Prozess (Art. 33/34)	✖	Kein dokumentierter Prozess „Wer meldet wann an dsb.gv.at und an die Betroffenen?".

2.5 Datenminimierung & Speicherbegrenzung (Art. 5)

Punkt	Status	Befund
GPS nur am Stempelpunkt	✓	Kein Background-Tracking. Position wird nur beim Klick auf „Dienst beginnen/beenden" einmalig abgerufen und gemeinsam mit Zeitstempel in `zeiterfassung` gespeichert (Spalten `start_geo_lat/lng`, `ende_geo_lat/lng`).
Geofence-Auswertung als Boolean	✓	`start_im_geofence`/`ende_im_geofence` werden mitgespeichert — Admin kann prüfen, muss aber nicht die rohen Koordinaten anfassen.
Kein Aufzeichnen privater Standorte	✓	Stempelvorgänge passieren ausschließlich am Hotel; bei Abweichung weiterer Datentyp „außerhalb" — keine Wohnort-Spuren.
Krankenstand: keine Diagnose	✓	`abwesenheiten.typ in ('urlaub','krankenstand')`, kein Diagnose-Feld.
7-Jahre-Aufbewahrung	⚠	In der Datenschutzerklärung benannt. Kein automatisierter Löschjob (nach 7 Jahren) implementiert. Manuell sicherstellen oder Cron-Job ergänzen.
Logout-Sessions	✓	API-Route `/api/auth/logout` löscht Session korrekt.

2.6 Auftragsverarbeitung & Drittlandtransfer (Art. 28, 44 ff.)

Punkt	Status	Befund
Hosting in EU	✓	Supabase Region eu-west-1 (Dublin, Irland).
AVV / DPA mit Supabase	✖	In `CLAUDE.md` als ToDo vor Deploy gelistet — Supabase bietet einen Standard-DPA an: https://supabase.com/legal/dpa. Muss vom Verantwortlichen elektronisch akzeptiert werden (über das Supabase-Dashboard → Settings → Billing → DPA).
Standardvertragsklauseln (SCC)	⚠	Supabase Inc. (US-Firma) liefert SCC als Teil des DPA-Pakets. Sobald DPA akzeptiert ist, ist SCC enthalten. Muss in der eigenen Datenschutzerklärung ergänzt werden („Drittlandtransfer in die USA aufgrund Konzernstrukturen der Supabase Inc., abgesichert durch EU-Standardvertragsklauseln nach DSGVO Art. 46 Abs. 2 lit. c").
Weitere Unterauftragsverarbeiter	⚠	Falls später Resend (E-Mail) oder Web-Push-Anbieter dazukommen: zusätzliche AVV nötig.

2.7 Verarbeitungsverzeichnis (Art. 30 DSGVO)

Punkt	Status
Schriftliches Verzeichnis	✖	Nicht vorhanden. Pflicht ab dem ersten verarbeiteten Datensatz, in der Praxis spätestens bei 250 MA. Für Hotelbetriebe wird's i. d. R. trotzdem geführt — siehe Vorlage in Kapitel 5 dieses Dokuments.

2.8 Datenschutz-Folgenabschätzung (Art. 35 DSGVO)

Punkt	Status	Befund
DSFA-Pflicht prüfen	⚠	Die Kombination Mitarbeitermonitoring + GPS + Gesundheitsdaten + automatisierte AZG-Auswertung kann eine DSFA auslösen (laut Liste der DSB Österreich: „systematische Überwachung Beschäftigter"). Empfehlung: kurze Pre-DSFA durchführen (ca. 1 Tag) — wenn das Ergebnis „geringes Risiko" ist, kann auf eine vollständige DSFA verzichtet werden, das Ergebnis aber dokumentieren.
Vollständige DSFA	✖	Nicht durchgeführt. Risiko: mittel (Hotelbetrieb, kleine MA-Zahl), aber dokumentierte Pre-DSFA reduziert Audit-Risiko.

2.9 Mitarbeiter-spezifische Pflichten (DSG + ArbVG)

Punkt	Status	Befund
Betriebsvereinbarung Geodaten	✖	Pflicht gem. § 96 Abs. 1 Z 3 ArbVG für Systeme zur „Kontrolle von Arbeitnehmern, die die Menschenwürde berühren". GPS-Stempelung fällt darunter. Auch bei nicht vorhandenem Betriebsrat: muss durch Einzelvereinbarung („Zustimmung des Arbeitnehmers in Schriftform" + Information) ersetzt werden.
Information an MA vor Inbetriebnahme	⚠	Datenschutzerklärung in App. Aber: schriftliche Vorab-Information mit Quittung („Ich wurde informiert über…") fehlt. Vorlage in Kapitel 5.
Mitbestimmung bei Schichtplänen	✓ (außerhalb DSGVO)	Wochenplanung im Tool, Mitarbeiter:in kann widersprechen via Feedback-Funktion (Aushilfen) oder Abwesenheits-Antrag.

2.10 Storage-Bucket-Sicherheit

Punkt	Status
Bucket `dokumente` privat	✓	Laut `CLAUDE.md` als privat angelegt. Nicht im Code als RLS-Policy versioniert — sollte ergänzt werden, damit eine Neueinrichtung der Storage-Settings reproduzierbar ist.
Zugriff über signed URLs	✓	Storage-Reads gehen über Service-Role im Server (z. B. `/api/auva-sync`). Keine öffentlichen Storage-URLs.

2.11 KI-Integration (Anthropic Claude)

Was ist integriert: lib/ki/anthropic.ts + app/(dashboard)/admin/ki/ — Chat-Assistent für Admin/Manager bei der Wochenplanung. Modell: claude-sonnet-4-6 über Anthropic-SDK.

Punkt	Status	Befund
Server-Only	✓	`'server-only'`-Direktive in `lib/ki/anthropic.ts` — API-Key kommt nie zum Browser.
Drei-fach-Gate	✓	KI-Aufruf nur wenn (a) Setting `ki.chat` aktiv, (b) Setting `chat_avv_bestaetigt`, (c) `ANTHROPIC_API_KEY` vorhanden. Schutzklemme wird in der Action und in der Library doppelt geprüft.
Rollenprüfung	✓	`requireRole(['admin','manager'])` vor jedem Aufruf — Mitarbeiter:innen sehen die KI nicht.
Pseudonymisierter Kontext	✓	Daten an Anthropic gehen ausschließlich als A-1, A-2, S-1, S-2 …. Keine Klarnamen, keine E-Mail, keine Telefonnummer, keine SV-Nummer, keine IBAN. Nur aggregierte Felder (Wochenstunden-Soll, geplante Stunden, Zusagequote, Urlaubsbilanz, Krankenstandstage-Summe, Schutzstatus-Flags).
Datenminimierung im Prompt	✓	Nur die aktuelle Woche + Urlaubsbilanz des laufenden Jahres + offene Rückmeldungs-Anfragen werden an die KI geschickt. Keine GPS-Punkte, keine Stempel-Historie.
Audit-Log KI-Anfragen	✖	KI-Aufrufe werden nicht in `audit_log` geschrieben. Bei einer DSGVO-Auskunft (Art. 15) kannst du dem MA nicht zeigen, wie oft sein:e Pseudonym verarbeitet wurde.
AVV / DPA mit Anthropic	⚠	Im Code als `chat_avv_bestaetigt`-Setting vorbereitet, muss aber elektronisch akzeptiert werden unter: https://www.anthropic.com/legal/dpa bzw. Anthropic Console → Settings → Legal.
SCC Drittlandtransfer USA	⚠	Anthropic ist US-Firma, Hauptverarbeitung in US-Regionen. DPA von Anthropic enthält SCC (Modul 2 Controller-Processor). Muss in `app/datenschutz/page.tsx` als zweiter Drittlandtransfer zusätzlich zu Supabase aufgeführt werden.
Kein Training mit Kunden-Daten	✓ (Anbieter-seitig)	Anthropic gibt vertraglich zu: Daten aus API-Aufrufen werden nicht zum Training der Modelle verwendet (Anthropic Commercial Terms, Stand 2026). Quelle: https://www.anthropic.com/legal/commercial-terms.
Transparenz für Betroffene	✖	Datenschutzerklärung erwähnt KI aktuell nicht. Mitarbeiter:innen wissen nicht, dass aggregierte Daten zu ihnen an einen Drittanbieter gehen.
Hinweis im UI auf KI	⚠	Admin sieht in `app/(dashboard)/admin/ki/` die KI-Seite, aber ein klarer „Hier antwortet eine KI, Vorschläge sind nicht bindend"-Banner sollte ergänzt werden (AI Act Art. 50 Transparenzpflicht).

EU AI Act (Verordnung 2024/1689)

Punkt	Status	Befund
Risikoklasse	✓ (KEIN Hochrisiko)	Annex III Z 4 lit. b AI Act stuft AI im Beschäftigungsbereich grundsätzlich als Hochrisiko ein, wenn das System für „Einstellung, Aufgabenzuweisung, Leistungsbewertung oder Beendigung" verwendet wird. Dein Setup macht das nicht: die KI gibt nur unverbindliche Vorschläge zur Schichtplanung. Jede Entscheidung trifft der Admin händisch. Damit greift Art. 6 Abs. 3 lit. a AI Act („narrow procedural task"-Ausnahme) — kein Hochrisiko-System. Voraussetzung: in der Datenschutzerklärung und in den Mitarbeiter-Informationen explizit festhalten: „Die KI gibt nur Vorschläge, jede Personalentscheidung trifft eine natürliche Person."
Transparenzpflicht (Art. 50)	⚠	Da nur Admin/Manager mit der KI interagieren (nicht Mitarbeiter:innen direkt), ist die strenge Endnutzer-Transparenz von Art. 50 hier abgemildert. Empfehlung: trotzdem im KI-UI ein Banner „🤖 Hier antwortet ein KI-System (Claude/Anthropic). Antworten können fehlerhaft sein." anzeigen.
KI-Kompetenz (Art. 4)	⚠	Seit 2.2.2025 wirksam: Betreiber müssen sicherstellen, dass Mitarbeiter:innen, die das KI-System nutzen, ausreichende KI-Kompetenz haben. Praktisch heißt das: kurze interne Schulung (1 Stunde reicht), dokumentiert.
Datenqualität (Art. 10)	n/a	Wir trainieren nicht selbst, wir konsumieren ein vortrainiertes Modell. Datenqualität ist Anthropic-Verantwortung.

DSGVO Art. 22 — automatisierte Entscheidung

Punkt	Status
Wird die KI für automatisierte Entscheidungen mit Rechtsfolge oder erheblicher Beeinträchtigung genutzt?	nein — KI gibt nur Vorschläge, Admin entscheidet. Wichtig: dieses Muster muss aktiv gehalten werden. Sollte später z. B. ein Auto-Approve-Feature für Aushilfen-Anfragen über die KI hinzukommen → DSFA-Pflicht + Mitbestimmung gem. § 96 Abs. 1 Z 3 ArbVG.
Information für Betroffene (Art. 13 Abs. 2 lit. f)	✖	Muss in Datenschutzerklärung ergänzt werden: „Wir setzen einen KI-Assistenten ein, der aggregierte und pseudonymisierte Daten verarbeitet. Es findet keine automatisierte Entscheidung im Sinne von Art. 22 DSGVO statt."

---

3. Quick Wins (≤ 1 Werktag)

Nr.	Maßnahme	Aufwand	Priorität
QW-1	Konkreter Verantwortlicher („Gartenhotel Maria Theresia GmbH, Anschrift, FN, UID, E-Mail Datenschutz-Kontakt") in `app/datenschutz/page.tsx` eintragen.	15 min	hoch
QW-2	Drittlandtransfer-Klausel zu Supabase Inc. + SCC in Datenschutzerklärung ergänzen.	30 min	hoch
QW-3	Supabase-DPA elektronisch akzeptieren (Settings → Billing → DPA).	10 min	kritisch
QW-4	HTTP-Security-Header in `next.config.mjs` ergänzen (HSTS, X-Frame-Options DENY, Referrer-Policy strict-origin-when-cross-origin, X-Content-Type-Options nosniff, Permissions-Policy für geolocation/camera).	1 h	hoch
QW-5	Audit-Log-Inserts bei den 4 sensiblen Mutationen ergänzen: Abwesenheits-Genehmigung, Überstunden-Genehmigung, Mitarbeiter-Stammdaten-Änderung, Einwilligungs-Widerruf.	2 h	mittel
QW-6	Datenexport-Endpoint `/api/meine-daten/export` (JSON-Dump aller Datensätze des/der Mitarbeiter:in) + Button in `/meine-daten`.	3 h	hoch (Art. 20!)
QW-7	Widerrufs-Button für Geodaten-Einwilligung in `/meine-daten`.	30 min	mittel
QW-8	Verarbeitungsverzeichnis (siehe Vorlage Kapitel 5) als statische `/docs/Verarbeitungsverzeichnis.md` einchecken.	1 h	hoch
QW-9	Betriebsvereinbarungs-/Einzelvereinbarungs-Vorlage Geodaten (Kapitel 5) ausdrucken, von allen Mitarbeiter:innen unterschreiben lassen.	1 Tag organisatorisch	kritisch vor Live-Gang
QW-10	Anthropic-DPA elektronisch akzeptieren (Anthropic Console → Settings → Legal/DPA).	10 min	kritisch
QW-11	KI-Abschnitt in `app/datenschutz/page.tsx` ergänzen (Anthropic als zweiter Drittlandtransfer USA, SCC, kein Training, kein Art. 22).	30 min	hoch
QW-12	Transparenz-Banner im KI-UI: „🤖 Hier antwortet ein KI-System (Anthropic Claude). Antworten können fehlerhaft sein und sind unverbindlich." (`app/(dashboard)/admin/ki/page.tsx` bzw. `KiChat.tsx`).	15 min	hoch
QW-13	Audit-Log-Insert bei jedem KI-Aufruf (`aktion='ki_chat'`, `details={anzahl_nachrichten, modell, prompt_tokens?, response_tokens?}`). KEINE Prompts/Antworten loggen — nur Metadaten.	30 min	mittel
QW-14	KI-Kompetenz-Schulung für Admins durchführen + dokumentieren (1 Std. interne Session, Protokoll).	1 h	mittel (AI Act Art. 4)

---

4. Empfohlene größere Maßnahmen

Nr.	Maßnahme	Aufwand	Priorität
M-1	Pre-DSFA durchführen (Mitarbeitermonitoring + GPS + Gesundheitsdaten). Vorlage der DSB Österreich: dsb.gv.at/dokumente.	1 Tag	hoch
M-2	Automatischer Löschjob: nach 7 Jahren (BAO-Frist) personenbezogene Daten löschen/anonymisieren. Implementierung als Supabase-pg_cron-Job mit Audit-Log-Eintrag pro gelöschtem Datensatz.	1 Tag	mittel
M-3	2FA für Admin-Rollen aktivieren (Supabase Auth unterstützt TOTP). Pflicht-Setup beim ersten Admin-Login.	1 Tag	hoch
M-4	Datenpannen-Reaktionsplan (Playbook): Wer meldet binnen 72 h an dsb.gv.at, wer informiert betroffene Mitarbeiter:innen, wie wird der Vorfall im audit_log dokumentiert. Als `docs/Datenpannen-Reaktionsplan.md`.	1 Tag	hoch
M-5	Storage-Bucket-Policies als SQL-Migration einchecken (statt nur über Supabase-Dashboard-Klicks gesetzt).	0,5 Tag	mittel
M-6	Backup-Recovery-Drill: einmal jährlich aus Supabase-PITR ein Restore-Test in eine Testumgebung. Ergebnis dokumentieren.	0,5 Tag/Jahr	mittel

---

4.1 KI-spezifische größere Maßnahmen

Nr.	Maßnahme	Aufwand	Priorität
KI-1	Verarbeitungsverzeichnis-Eintrag „KI-gestützte Wochenplanungs-Beratung" mit allen Pflichtfeldern + AI-Act-Klassifikation (kein Hochrisiko-System gem. Art. 6 Abs. 3).	1 h	hoch
KI-2	KI-Nutzungs-Richtlinie als `docs/KI-Nutzungsrichtlinie.md`: was darf rein in KI-Prompts (aggregiert, pseudonymisiert), was darf nicht (Klarnamen, SV-Nr, GPS, IBAN), wer ist nutzungsberechtigt, wie wird der Output behandelt (nur als Vorschlag), Schulungsnachweis.	1 Tag	hoch
KI-3	KI-Pre-DSFA: in `docs/Pre-DSFA.md` eigene Sektion zur KI-Verarbeitung — Eintrittswahrscheinlichkeit + Schadenshöhe für „Re-Identifikation aus pseudonymisierten Daten", „Halluzinierte Personalentscheidung", „API-Key-Leak".	0,5 Tag	hoch
KI-4	Output-Sanity-Check: vor jedem KI-Aufruf prüfen, dass der `systemPrompt` nicht versehentlich Klarnamen enthält (z. B. regex-Check auf gängige Vornamen-Patterns, Telefonnummer-Format, SV-Nummer-Format). Bei Treffer: Aufruf verweigern und Audit-Log-Eintrag `aktion='ki_blocked_pii_leak'`.	1 Tag	mittel
KI-5	Rate-Limit pro Admin (z. B. 50 Anfragen/Tag) gegen unbeabsichtigte Massendaten-Exfiltration. In `app/(dashboard)/admin/ki/actions.ts` ergänzen.	0,5 Tag	mittel
KI-6	Aufbewahrungs- und Löschpolicy für KI-Audit-Log: 3 Jahre, danach automatische Anonymisierung. In den später entstehenden Retention-Job (Maßnahme M-2) integrieren.	0,5 Tag	niedrig

5. Vorlagen / Beilagen

5.1 Verarbeitungsverzeichnis (Art. 30) — Minimalvorlage

`` Verantwortlicher: Gartenhotel Maria Theresia GmbH, Hall in Tirol Kontakt Datenschutz: [E-Mail] Verarbeitungstätigkeit: Personalplanung & Zeiterfassung Zweck: § 26 AZG-Aufzeichnung, Personalplanung, Lohnverrechnung Rechtsgrundlage: Art. 6 Abs. 1 lit. b (Vertrag), lit. c (§ 26 AZG) Betroffene Personen: Beschäftigte des Gartenhotel Maria Theresia Datenkategorien: Stammdaten, Arbeitszeiten, GPS-Punkte (nur bei Stempel), Krankenstandszeiten (ohne Diagnose), Signaturen Empfänger: intern (Geschäftsleitung, Lohnverrechnung), Behörden bei gesetzlicher Verpflichtung Drittlandtransfer: USA (Supabase Inc.), abgesichert durch SCC Löschfristen: Personalakten 7 Jahre nach Austritt (§ 132 BAO), Zeiterfassungen 7 Jahre, sonstige Daten 3 Jahre TOMs: TLS-Verschlüsselung, AES-256 at rest, Row-Level-Security, Audit-Log, RBAC, MFA für Admins, EU-Hosting ``

5.2 Einzelvereinbarung Geodaten-Erfassung (Vorlage)

``` Einwilligung zur Erfassung von Standortdaten beim Stempelvorgang

Zwischen Gartenhotel Maria Theresia GmbH (Arbeitgeber) und _________________ (Arbeitnehmer:in).

Der Arbeitgeber setzt die Anwendung „Stundenerfassung" ein. Beim Klick auf „Dienst beginnen" bzw. „Dienst beenden" wird einmalig die GPS-Position des Geräts abgerufen und gemeinsam mit Datum/Uhrzeit gespeichert. Eine fortlaufende Standortverfolgung findet nicht statt. Der Zweck ist die Verifikation, dass sich der/die Beschäftigte am Hotel befindet (Stempelung am Arbeitsort).

Rechtsgrundlage: § 96 Abs. 1 Z 3 ArbVG iVm Art. 6 Abs. 1 lit. b DSGVO.

Die Einwilligung kann jederzeit ohne Begründung über das Profil „Meine Daten" widerrufen werden. In diesem Fall ist eine Zeiterfassung nur am stationären Terminal des Betriebs möglich.

Ort, Datum: ___________________ Unterschrift: ___________________ ```

5.3 Datenpannen-Erstmeldung (Vorlage Art. 33)

Speicherort: docs/Datenpannen-Reaktionsplan.md. Kernpunkte:

`` 1. Erkennung → wer meldet intern an wen 2. Bewertung → Risiko-Stufe (gering / mittel / hoch) gem. Art. 33 3. Meldung DSB → online über dsb.gv.at, max. 72 h nach Kenntniserlangung 4. Information → bei hohem Risiko an Betroffene (Art. 34) 5. Dokumentation → Eintrag in audit_log (aktion='datenpanne') 6. Lessons learned → schriftlich, im docs/-Ordner ``

---

6. Code-Verweise (Stand 19.05.2026)

Datenschutzerklärung: app/datenschutz/page.tsx
Rechtliche Compliance-Seite: app/rechtliches/page.tsx
Einwilligungs-Flow Geodaten: components/Stempeluhr.tsx Z. 154–172
Selbst-Stammdaten: app/(dashboard)/meine-daten/
Audit-Log-Tabelle: supabase/schema.sql Z. 190
RLS-Hauptdefinitionen: supabase/schema.sql + supabase/migrations/003_rls_haertung_audit.sql
Server-Action-CSRF: next.config.mjs
DSGVO-Felder Mitarbeiter: supabase/schema.sql Z. 71–74 (einwilligung_geodaten, einwilligung_datenschutz + Zeitstempel)

---

7. Nächste Schritte (priorisiert)

Reihenfolge	Aktion	Wer	Wann
1	Supabase-DPA elektronisch akzeptieren	Geschäftsleitung	sofort
2	Konkreten Verantwortlichen in Datenschutzerklärung eintragen	Entwicklung	sofort
3	Einzelvereinbarung Geodaten an alle MA verteilen + unterschreiben lassen	Personalverwaltung	vor Live-Gang
4	Verarbeitungsverzeichnis ausfüllen	Geschäftsleitung	innerhalb 4 Wochen
5	Datenexport-Endpoint + Widerrufsknopf in `/meine-daten`	Entwicklung	innerhalb 4 Wochen
6	HTTP-Security-Header in `next.config.mjs`	Entwicklung	innerhalb 2 Wochen
7	Pre-DSFA durchführen + dokumentieren	Geschäftsleitung + Entwicklung	innerhalb 8 Wochen
8	Automatischer 7-Jahre-Löschjob	Entwicklung	innerhalb 12 Wochen
9	2FA-Pflicht für Admin-Rollen	Entwicklung	innerhalb 12 Wochen
10	Datenpannen-Playbook schreiben	Geschäftsleitung	innerhalb 6 Wochen

---

8. Disclaimer

Dieser Audit-Bericht ist eine technische und prozessuale Standortbestimmung auf Basis des aktuellen Codes und der dazugehörigen Dokumentation. Er ersetzt keine anwaltliche Datenschutzberatung und keine Prüfung durch eine zertifizierte Datenschutzbeauftragte. Bei rechtlichen Unsicherheiten — insbesondere zu Betriebsvereinbarung, DSFA-Pflicht, Drittlandtransfer und Auskunftsverfahren — ist eine spezialisierte Kanzlei oder die WKO-Servicestelle Datenschutz hinzuzuziehen.

DSGVO – Rechtliche Umsetzung