Datenschutzerklärung

Stand: [AUSFÜLLEN: Datum der letzten anwaltlichen Freigabe, Format TT.MM.JJJJ] · Version [AUSFÜLLEN: z. B. 1.0.0]

1. Datenschutz auf einen Blick

1.1 Allgemeine Hinweise

Die folgenden Hinweise geben einen einfachen Überblick darüber, was mit Ihren personenbezogenen Daten passiert, wenn Sie diese Webanwendung nutzen. Ausführliche Informationen finden Sie in der ausführlichen Datenschutzerklärung weiter unten.

1.2 Wer ist verantwortlich?

Siehe Abschnitt 2.

1.3 Welche Daten erfassen wir?

Siehe Abschnitt 3.

1.4 Was tun wir mit Ihren Daten?

Siehe Abschnitt 5.

1.5 Welche Rechte haben Sie?

Siehe Abschnitt 11.

2. Verantwortlicher und Datenschutzbeauftragter

2.1 Verantwortlicher gemäß Art. 4 Nr. 7 DSGVO

[AUSFÜLLEN: Vollständiger Firmenname]
[AUSFÜLLEN: Straße + Hausnummer]
[AUSFÜLLEN: PLZ + Ort]
Telefon: [AUSFÜLLEN: +49 (Vorwahl) Nummer]
E-Mail: [AUSFÜLLEN: datenschutz@ics-group.eu]

2.2 Datenschutzbeauftragter (falls bestellt)

[AUSFÜLLEN, sofern gemäß Art. 37 DSGVO bestellungspflichtig — prüfen]: Name, postalische Anschrift, E-Mail des DSB.
Bestellungspflichtig, wenn die Kerntätigkeit in der umfangreichen Verarbeitung besonderer Datenkategorien (Art. 9) besteht oder die Verarbeitungstätigkeit Risiken für Betroffene birgt. Diese App verarbeitet u. a. Gesundheitsdaten (Art. 9 — siehe /requests sick/parental_leave), eine DSB-Bestellung wird daher EMPFOHLEN, sofern kein internes Datenschutz-Team die Funktion übernimmt.

3. Erhobene Daten und Rechtsgrundlagen

Die folgende Tabelle führt alle Datenkategorien, Verarbeitungszwecke und Rechtsgrundlagen gemäß Art. 13(1)(c) DSGVO auf.

Stammdaten (Name, E-Mail, Abteilung, Rolle) Konto-Verwaltung, Authentifizierung Art. 6(1)(b) DSGVO (Vertrag) / § 26(1) BDSG Schichtpläne, Dienstzeiten, Kalender-Token Arbeitszeitorganisation Art. 6(1)(b) DSGVO / § 26(1) BDSG Abwesenheiten (Urlaub, Krank, Elternzeit) HR-Workflow, gesetzliche Aufzeichnungspflicht Art. 6(1)(c) DSGVO (ArbZG, EFZG, MuSchG) + § 26(3) BDSG für besondere Datenkategorien (Art. 9(2)(b)) Bradford-Faktor-Scores und Verlauf (#3198) Frühwarnsystem Krankheitsmuster (Aggregat) — siehe Abschnitt 9 Art. 6(1)(f) DSGVO (berechtigtes Interesse Personalplanung) + Art. 22-Hinweis (siehe Abschnitt 9) Bradford-Opt-Out und Appeal-Status (#3201, #3202) Ausübung des Widerspruchsrechts (Art. 22(3) DSGVO) Art. 22(3) DSGVO + EU AI Act Art. 14(5) Benachrichtigungs-Präferenzen (E-Mail, Teams, ServiceNow) Zustellung dienstlicher Mitteilungen Art. 6(1)(b)/(f) DSGVO — Widerspruch jederzeit möglich Audit-Logs, Sitzungs-IDs, IP-Adressen (gehasht), Bradford-Audit-Trail (#3199) Sicherheit, Forensik, gesetzliche Aufbewahrung, KI-Compliance Art. 6(1)(c) DSGVO i. V. m. § 32 BDSG + Art. 6(1)(f) (berechtigtes Interesse IT-Sicherheit) + EU AI Act Art. 12

4. Verschlüsselung besonderer Datenkategorien (Art. 9 DSGVO + § 26(3) BDSG)

Inhalte von Krankmeldungen (Diagnose-Hinweise im Kommentarfeld) und Elternzeit-Anträgen (Begründungen, die Familienplanung betreffen) werden als besondere Kategorien personenbezogener Daten gemäß Art. 9 DSGVO mit AES-256-GCM verschlüsselt persistiert. Der Schlüssel wird per HKDF aus AUTH_ENCRYPTION_KEY abgeleitet (eigener Salt pro Datensatz, keine direkte Schlüssel-Wiederverwendung). Der Zugriff auf die entschlüsselten Inhalte ist auf Mitarbeiter mit Admin-Rolle beschränkt (Compliance-Funktion gemäß § 26(3) BDSG).

Hinweis: Die Aggregat-Werte für den Bradford-Faktor (Anzahl Krankheits-Episoden, Anzahl Tage) werden aus Datenschutzgründen NICHT aus den verschlüsselten Kommentarfeldern abgeleitet, sondern ausschließlich aus der strukturierten Abwesenheits-Tabelle (Datenkategorie „Abwesenheiten" in Abschnitt 3).

5. Cookies, lokale Speicherung und Drittanbieter (ePrivacy / TTDSG §25)

Diese Webanwendung verwendet technisch notwendige Cookies sowie lokale Speicherung (localStorage) zur Authentifizierung, Sicherheit und UI-State-Erhaltung. Es werden keine Tracking-, Analyse- oder Marketing-Cookies gesetzt und keine Daten an Drittanbieter zu Werbezwecken übermittelt.

5.1 Cookies (Erstanbieter)

Die folgenden Cookies werden ausschließlich von dieser Webanwendung (Erstanbieter) gesetzt. Sie sind technisch erforderlich (§ 25(2) Nr. 2 TTDSG) und benötigen daher keine Einwilligung. Rechtsgrundlage ist Art. 6(1)(b) DSGVO (Vertragserfüllung — Login) bzw. Art. 6(1)(f) DSGVO (berechtigtes Interesse — Sicherheit).

authjs.session-token (prod: __Secure-authjs.session-token) JWT-Session-Token zur Authentifizierung des angemeldeten Nutzers. 12 Stunden (konfigurierbar via AUTH_SESSION_MAX_AGE_HOURS) Essenziell (§ 25(2) Nr. 2 TTDSG — für Login zwingend erforderlich) httpOnly — nicht per JavaScript lesbar (Schutz vor XSS-Diebstahl der Session) Art. 6(1)(b) DSGVO authjs.csrf-token (prod: __Host-authjs.csrf-token) Double-Submit-CSRF-Token für Schreib-Requests. Session (bis Browser-Tab geschlossen) Essenziell (§ 25(2) Nr. 2 TTDSG — für Schreib-Requests zwingend erforderlich) Per JavaScript lesbar — zwingend für CSRF-Schutz nach Double-Submit-Pattern (Client-JS liest den Cookie und schickt ihn als X-CSRF-Token-Header) Art. 6(1)(f) DSGVO (IT-Sicherheit) authjs.callback-url (prod: __Secure-authjs.callback-url) Speichert die Ziel-URL für die Weiterleitung nach erfolgreichem Login (Open-Redirect-Schutz). Session (bis Browser-Tab geschlossen) Essenziell (§ 25(2) Nr. 2 TTDSG — Teil des Login-Flows) httpOnly — nicht per JavaScript lesbar (Schutz vor XSS-Manipulation der Ziel-URL) Art. 6(1)(b)/(f) DSGVO

Hinweis (Cluster #3177 + #3180): Die Spalten Klassifikation und JavaScript-Zugriff wurden ergänzt, um die in TTDSG § 25(2) Nr. 2 geforderte Trennung zwischen essenziellen, funktionalen und analysebezogenen Cookies explizit zu dokumentieren. Derzeit sind alle drei Cookies als essenziell klassifiziert — es gibt keine funktionalen, analyse- oder marketingbezogenen Cookies. Der csrf-Token ist absichtlich nicht httpOnly, weil die NextAuth-CSRF-Defense (Double-Submit-Pattern) JavaScript- Zugriff benötigt; der Diebstahl via XSS ist akzeptabel, weil SameSite=lax + Sec-Fetch-Site-Check (withAuth) die Ausnutzung cross-site verhindern.

In Produktion werden Cookies mit den Prefixen __Secure- und __Host- (RFC 6265bis) ausgestattet. Diese erzwingen Secure-Attribut und beim CSRF-Cookie zusätzlich Path=/ ohne Domain-Attribut — als Schutz gegen Subdomain-Cookie-Injection. In lokalen Dev-Umgebungen (HTTP) entfallen die Prefixe.

5.2 Lokale Speicherung (localStorage)

Die Anwendung speichert UI-Präferenzen im localStorage des Browsers. Diese Einträge enthalten keine personenbezogenen Daten (ausschließlich anonyme UI-Konfiguration) und dienen der Wiederherstellung der Benutzeroberfläche nach einem Seiten-Reload. Rechtsgrundlage: Art. 6(1)(f) DSGVO (berechtigtes Interesse — benutzerfreundliche UI).

SHIFT_COUNT_KEY Anzahl und Anordnung der Schicht-Gruppen im Schichtplaner Funktional (UI-State) planning/page.tsx PLAN_VIEW_CONFIG_KEY Ansicht-Konfiguration (Wochen-/Monats-/Jahresansicht, Zoom) Funktional (UI-State) planning/page.tsx ics-column-visibility-* Spalten-Ein-/Ausblendung pro Bericht-Typ (anonym) Funktional (UI-State) components/reports/ColumnPicker.tsx SHIFT_GROUPS_KEY Gruppierungs-Auswahl im Schicht-Bericht Funktional (UI-State) components/reports/ShiftsReportTab.tsx ics-sidebar-collapsed Eingeklappt-Zustand der Sidebar-Navigation Funktional (UI-State) stores/ui-store.ts ics-tweaks-storage Power-User-Tweaks (anonyme UI-Flags, Theme-Mode) Funktional (UI-State) stores/tweaks-store.ts (Zustand persist) ics-consent Cookie-Consent-Auswahl (Zeitstempel + Auswahl: alle/essenziell/individual) Erforderlich (Cluster #3175+#3182 — Consent-Nachweis) components/legal/CookieConsentBanner.tsx

Hinweis (Cluster #3178): Alle localStorage-Einträge sind als funktional (UI-State) klassifiziert — sie speichern ausschließlich anonyme UI-Konfiguration ohne Personenbezug und ohne Drittanbieter-Zugriff. Daher fallen sie NICHT unter TTDSG § 25(1) (Speicherung von Informationen in Endgeräten), sondern unter Art. 6(1)(f) DSGVO (berechtigtes Interesse). Ein Consent-Gate ist nicht erforderlich; die Einträge können jederzeit über Cookie-Einstellungen (im Footer jeder Seite) oder durch manuelles Löschen des Browserspeichers entfernt werden.

5.3 Drittanbieter-Dienste

Es werden derzeit keine Drittanbieter-Cookies gesetzt und keine Daten an externe Tracking-, Analyse- oder Marketing-Dienste übermittelt. Schriften (Geist, Geist Mono, Inter, Atkinson Hyperlegible) werden über Next.js next/font/local vollständig lokal unter /public/fonts/{geist,geist-mono,inter,atkinson}/ ausgeliefert (Cluster #3151). Es findet kein Netzwerk-Aufruf zu fonts.googleapis.com oder fonts.gstatic.com statt — weder zur Build- noch zur Laufzeit. Der Build läuft komplett offline.

Falls in Zukunft Drittanbieter-Dienste eingebunden werden (z. B. Analytics, Error-Reporting, Payment, CDN), wird dieser Abschnitt im selben Pull-Request aktualisiert und das Cookie-Consent-Banner (siehe §5.5) erweitert die Auswahlmöglichkeiten entsprechend.

5.4 Cookie-Consent-Banner (Cluster #3175 + #3182)

Trotz der ausschließlich technisch-notwendigen Cookies und anonymisierten UI-State-Einträge (die nach § 25(2) Nr. 2 TTDSG keine Einwilligung erfordern) zeigt die Anwendung beim ersten Besuch ein Cookie-Consent-Banner mit drei gleichwertigen Auswahlmöglichkeiten:

• Alle akzeptieren — bestätigt die aktuelle Konfiguration (alle Cookies aktiv, da keine zusätzlichen Tracking-Cookies vorhanden sind).
• Nur essenzielle — bestätigt die Verwendung der für Login und Sicherheit erforderlichen Auth.js-Cookies und lehnt hypothetische zukünftige nicht-essenzielle Cookies ab.
• Einstellungen — öffnet eine Detailansicht aller Cookies und localStorage-Einträge mit individueller Auswahl.

Die Auswahl wird im localStorage-Schlüssel ics-consent (Format: JSON mit Zeitstempel + Auswahl + Policy-Version) gespeichert. Das Banner erscheint erneut, sobald der Nutzer über den Footer-Link Cookie-Einstellungen oder die Profilseite die Auswahl ändert (Widerrufsrecht, Art. 7(3) DSGVO + EDPB Guidelines 05/2020 §83).

Authentifizierungs-Cookies werden unabhängig von der Auswahl gesetzt, weil sie für den Login zwingend erforderlich sind (§ 25(2) Nr. 2 TTDSG). Eine Ablehnung des Banners blockiert daher nicht den Login — der Nutzer kann die Anwendung auch ohne aktive Consent-Bestätigung nutzen, verliert dann aber die UI-Präferenzen (Theme, Sidebar-Zustand, Spalten-Sichtbarkeit).

5.5 Cookie-Einstellungen (Widerruf, Art. 7(3) DSGVO)

Sie können Ihre Cookie- und Consent-Auswahl jederzeit über die folgenden Wege ändern oder widerrufen:

1. Footer-Link „Cookie-Einstellungen" auf jeder Seite (Login, Dashboard, Legal-Pages).
2. Profilseite unter /profile im Abschnitt „Datenschutz & Cookies".
3. Browser-Einstellungen — Löschen aller Cookies und localStorage-Einträge über die DevTools oder Browser-Datenschutzoptionen.

Beim Widerruf werden nur die UI-Präferenzen (Theme, Sidebar-Zustand, Spalten-Sichtbarkeit) auf die Standardwerte zurückgesetzt. Auth-Cookies bleiben so lange aktiv, bis die Session abläuft (12 h) oder Sie sich aktiv abmelden — ein Widerruf des Cookie-Consent berührt nicht die Laufzeit der JWT-Session.

5.6 Widerruf von Profil- und Benachrichtigungs-Einwilligungen (Cluster #3150, sec #3152)

Für die auf Ihrer Einwilligung beruhenden Verarbeitungen (Geburtstags-Anzeige im Dashboard und E-Mail-Benachrichtigungen für die vier Kategorien Schichtanträge, Schichtpläne, Zeiterfassung und Bradford-Faktor) können Sie Ihre Einwilligung jederzeit mit Wirkung für die Zukunft widerrufen (Art. 7(3) DSGVO, EDPB Guidelines 05/2020 §83 — „the withdrawal of consent shall be as easy as granting it"). Folgende Widerrufswege stehen zur Verfügung:

1. Profilseite unter /profile im Abschnitt „Sichtbarkeit" (Geburtstag) bzw. „Benachrichtigungen" (4 Toggle-Schalter plus E-Mail-Sub-Channel). Sofortige Wirkung — kein Bestätigungsdialog notwendig.
2. Header-Menü → „Datenschutz-Einstellungen" — öffnet die Profilseite mit vorausgewähltem Datenschutz-Tab. Funktional identisch mit Punkt 1, aber direkter Einstieg ohne Suchaufwand.
3. Programmatische Widerrufs-API POST /api/consent/withdraw mit JSON-Body { "scope": "all" | "birthday_display" | "notifications_email" }. Authentifizierung per Session-Cookie erforderlich. Rate-Limit 10/min pro Nutzer. Die API ist primär für künftige Magic-Link-Workflows gedacht (kontextbezogener Widerruf aus Direkt-Mail oder Datenschutz-Portal), nicht für Endnutzer.
4. One-Click-Unsubscribe-Header in jeder ausgehenden E-Mail-Benachrichtigung (RFC 8058) — entspricht dem Widerruf des Scopes notifications_email ohne Login-Pflicht (siehe PR #3190/#3191).

Beim Widerruf werden die jeweiligen Spalten in der Datenbank auf den Standardwert (false) zurückgesetzt. Bei scope=birthday_display werden die Granular-Toggles „Tag" und „Jahr" automatisch mit deaktiviert (Hierarchie: Geburtstag aus → Tag und Jahr zwingend aus). Bei scope=notifications_email werden alle vier Benachrichtigungs-Kategorien sowie der E-Mail-Sub-Channel gemeinsam deaktiviert.

Jeder Widerruf wird in der user_consent_log-Tabelle mit Zeitstempel, IP-Hash (HMAC-SHA256 mit AUDIT_HASH_SALT), User-Agent und optionalem Freitext als Grund auditierbar protokolliert (Art. 7(1) DSGVO — Nachweispflicht). Die Rechtmäßigkeit der bis zum Widerruf erfolgten Verarbeitung bleibt vom Widerruf unberührt (Art. 7(3) Satz 2 DSGVO).

Ein Widerruf hat keine Auswirkung auf die Funktion der Anwendung: Sie können sich weiterhin anmelden, Schichten bearbeiten und Anträge stellen. Lediglich die Geburtstags-Anzeige anderer Nutzer im Dashboard und/oder der E-Mail-Versand entfallen.

6. Empfänger der Daten

Personenbezogene Daten werden — soweit zur Erfüllung der genannten Zwecke erforderlich — an folgende Empfänger übermittelt:

• Andere Nutzer der Anwendung mit entsprechender Rolle (Schichtleiter sehen Schichtpläne ihrer Abteilung; Administratoren sehen alle Daten außer besonderen Datenkategorien).
• Auftragsverarbeiter gemäß Art. 28 DSGVO:
  • [AUSFÜLLEN, falls Cloud-Hosting durch Dritte]: Hosting-Anbieter, Rechenzentrum, Land
  • Microsoft Corporation (Microsoft Entra ID / MS Teams) für OIDC-Authentifizierung und optionale Benachrichtigungen — Drittlandtransfer in die USA auf Basis EU-US Data Privacy Framework (DPF, seit Juli 2023) bzw. EU-Standardvertragsklauseln.
  • Google LLC (Google Workspace OIDC) — siehe oben.
  • ServiceNow Inc. für optionale Ticket-Synchronisation — Drittlandtransfer USA, SCC als Garantie.
• Behörden nur bei gesetzlicher Verpflichtung (Finanzamt, Sozialversicherungsträger, Aufsichtsbehörden).

7. Drittlandtransfer (außerhalb EWR)

Sofern Daten in Drittländer (insbesondere USA) übertragen werden, geschieht dies auf folgenden Rechtsgrundlagen:

• EU-US Data Privacy Framework (DPF) für Empfänger mit DPF-Zertifizierung (geprüft auf dataprivacyframework.gov).
• EU-Standardvertragsklauseln (SCC, 2021/914) für alle übrigen Empfänger, mit zusätzlichen technischen und organisatorischen Maßnahmen (TOMs): Verschlüsselung at-rest und in-transit, Pseudonymisierung, keine Drittland-Subdienstleister ohne Vorab-Genehmigung.

[AUSFÜLLEN: Konkretes Land je Empfänger, Garantie-Typ, Link zur SCC/Zertifizierung]

8. Speicherdauer

Personenbezogene Daten werden gemäß den gesetzlichen Aufbewahrungsfristen und internen Löschkonzepten gespeichert und anschließend gelöscht oder anonymisiert:

• Stammdaten: Bis Beendigung des Beschäftigungsverhältnisses zzgl. 10 Jahre (§ 35 EStG i. V. m. § 147 AO für Lohnsteueranmeldungen).
• Schichtplanungsdaten: 5 Jahre (§ 35 EStG i. V. m. GoBD).
• Krankheits-/Abwesenheitsdaten (Art. 9): 5 Jahre nach Ausscheiden, getrennt von Stammdaten und nur eingeschränktem Zugriff (siehe art9-safeguards-Policy).
• Audit-Logs: 7 Jahre (§ 32 BDSG, GoBD).
• Bradford-Score-Verlauf (user_bradford_history, #3198): 5 Jahre (EU AI Act Art. 70).
• Bradford-Appeals (user_bradford_appeals, #3202): 5 Jahre (Art. 5(2) DSGVO — Nachweispflicht Widerspruchsverfahren).
• Bradford-Opt-Out-Status (#3201): Bis Beendigung Beschäftigungsverhältnis + 5 Jahre (Nachweis Art. 22(3)-Widerspruch).
• Sitzungs- und temporäre Daten: 30 Tage.

Nach Ablauf der Frist erfolgt entweder Löschung gemäß Art. 17 DSGVO oder Anonymisierung gemäß Art. 89 DSGVO.

9. Automatisierte Entscheidungsfindung und Profiling (Art. 22 DSGVO + EU AI Act)

Bradford-Faktor: Die Anwendung berechnet aus der Krankheitshistorie einen Bradford-Faktor-Score und benachrichtigt Vorgesetzte, wenn ein Schwellenwert überschritten wird. Es handelt sich um ein Frühwarn-System, das einen Menschen (Personalabteilung) informiert; es trifft KEINE automatisierten Entscheidungen mit Rechtswirkung oder ähnlich erheblicher Beeinträchtigung (Art. 22(1) DSGVO). Die Personalabteilung prüft jeden Fall manuell.

9.1 Verarbeitete Daten und Berechnungslogik

Verarbeitet werden ausschließlich aggregierte Abwesenheits-Daten: Anzahl der Krankheits-Episoden im laufenden Kalenderjahr, Anzahl der dadurch ausgefallenen Arbeitstage und Dauer der einzelnen Episoden. Die Berechnung folgt der Formel Anzahl Episoden² × Tage. Abwesenheiten, die unter das Allgemeine Gleichbehandlungsgesetz (AGG) fallen (z. B. nachgewiesene Schwerbehinderung, Mutterschutz, Pflegezeiten), werden nicht in den Score eingerechnet — die Anzahl ausgeschlossener Episoden wird im Audit-Log protokolliert (excluded_agg_count).

9.2 Schwellenwerte und Kategorien

Die folgenden Schwellenwerte kommen zur Anwendung (können von der Personalverantwortung über settings/bradford_thresholds konfiguriert werden; die hier angegebenen Werte sind die Standard-Konfiguration):

• OK (< Beobachtung-Schwelle): Keine Auffälligkeit.
• Beobachtung: Führungskraft wird informiert.
• Gespräch: Pflicht-Review durch Führungskraft + Personal.
• Maßnahme (≥ Aktion-Schwelle): Personalabteilung wird einbezogen.

Die aktuell gültigen Schwellenwerte sowie Ihre aktuelle Score-Position werden Ihnen im Profil dauerhaft angezeigt (#3204).

9.3 Pflicht-menschliche Review (EU AI Act Art. 14)

Vor jeder Eskalation in die Stufen „Gespräch" oder „Maßnahme" legt das System einen Pflicht-Review-Datensatz an (ai_system_reviews). Die Führungskraft MUSS die algorithmische Empfehlung im UI bestätigen oder überschreiben, bevor Maßnahmen ergriffen werden.

9.4 Ihre Rechte in Bezug auf automatisierte Bewertung (Art. 22(3) DSGVO)

Sie haben das Recht, der automatisierten Bewertungs-Vorbereitung zu widersprechen. Wir stellen Ihnen dazu zwei Wege zur Verfügung:

1. Globales Opt-Out (#3201): Unter Profil → Automatisierte Bewertung meiner Abwesenheiten können Sie der Berechnung widersprechen. In diesem Fall wird Ihr Bradford-Score nicht mehr berechnet und Ihre Führungskraft wird nicht automatisch benachrichtigt. Die Wechsel-Information wird mit Zeitstempel protokolliert.
2. Konkreter Einspruch / Appeal (#3202): Unter Profil → Aktueller Bradford-Faktor → Einspruch können Sie gegen eine konkrete Eskalation schriftlich Widerspruch einlegen. Ihre Führungskraft MUSS diesen Einspruch im Pflicht-Review berücksichtigen (EU AI Act Art. 14(5)).

Zusätzlich haben Sie gemäß Art. 15 DSGVO das Recht auf Auskunft über Ihren Bradford-Score-Verlauf; Sie finden ihn direkt im Profil.

10. Ihre Rechte als betroffene Person

Sie haben gegenüber dem Verantwortlichen folgende Rechte bezüglich Ihrer personenbezogenen Daten:

• Recht auf Auskunft (Art. 15 DSGVO) — inkl. Bradford- Score und Verlauf über das Profil
• Recht auf Berichtigung (Art. 16 DSGVO)
• Recht auf Löschung (Art. 17 DSGVO) — eingeschränkt durch gesetzliche Aufbewahrungsfristen
• Recht auf Einschränkung der Verarbeitung (Art. 18 DSGVO)
• Recht auf Datenübertragbarkeit (Art. 20 DSGVO) — für bereitgestellte Daten im CSV/JSON-Format
• Widerspruchsrecht (Art. 21 DSGVO) — insbesondere gegen Verarbeitung auf Grundlage von Art. 6(1)(f); für Bradford-Scores konkret über den Opt-Out (#3201)
• Recht auf Widerruf der Einwilligung (Art. 7(3) DSGVO) — sofern Verarbeitung auf Einwilligung beruht; die Rechtmäßigkeit der bis zum Widerruf erfolgten Verarbeitung bleibt unberührt
• Widerspruch gegen automatisierte Entscheidung (Art. 22(3) DSGVO) — siehe Abschnitt 9.4

11. Beschwerderecht bei der Aufsichtsbehörde

Unbeschadet eines anderweitigen verwaltungsrechtlichen oder gerichtlichen Rechtsbehelfs steht Ihnen das Recht auf Beschwerde bei einer Aufsichtsbehörde zu, insbesondere in dem Mitgliedstaat Ihres gewöhnlichen Aufenthaltsorts, Ihres Arbeitsplatzes oder des Orts des mutmaßlichen Verstoßes (Art. 77 DSGVO).

Zuständige Aufsichtsbehörde für unser Unternehmen:
[AUSFÜLLEN: Name und Adresse der zuständigen Landesdatenschutzbehörde, z. B. „Landesbeauftragte für den Datenschutz und die Informationsfreiheit [Land], [Adresse]"]

12. Pflicht zur Bereitstellung der Daten

Die Bereitstellung der Stammdaten, Schichtpläne und Abwesenheitsdaten ist für die Durchführung des Beschäftigungsverhältnisses erforderlich (§ 26(1) BDSG). Ohne diese Daten kann die Schichtplanung nicht durchgeführt werden.

13. Sicherheitsmaßnahmen und Rate-Limits (Art. 32 DSGVO + sec #3159)

Zur Absicherung gegen Brute-Force-Angriffe, automatisierte Missbrauchs- versuche und unbeabsichtigte Lastspitzen werden auf sämtlichen API-Endpunkten Rate-Limits (Sliding-Window) durchgesetzt. Diese werden in src/lib/rate-limit.ts zentral konfiguriert und sind nach Feature-Namespaces getrennt:

auth, login, mfa, reauth, password, delete Authentifizierungs- Brute-Force-Schutz (per IP und/oder Email-Hash) data-export DSGVO Art. 15 Export — Begrenzung auf wenige Aufrufe pro Stunde report Berichte (PDF/CSV/XLSX) — Schutz vor ressourcenintensiven Generierungen integration, sync, webhook ServiceNow / LDAP / OIDC- Synchronisationen und eingehende Webhooks swap, requests, time-entries Antragswesen und Zeiterfassungs-Mutationen (eigener Namespace für Time-Entries nach ArbZG §6) dashboard, planning, notifications, employees, models Mutationen an Stammdaten und Konfiguration admin Admin-Aktionen (Backup-Restore, Import, Konfigurations-Änderungen) public Unauthentifizierte Endpoints (z. B. OIDC-Provider-Liste) seating, kitchen, whistleblower Spezialisierte Namespaces (Seating-Desk-Locks, Küchendienst, anonyme Whistleblower-Meldungen nach HinSchG §6)

Bei Überschreitung eines Limits wird die Anfrage mit HTTP 429 (Too Many Requests) und einem Retry-After-Header abgelehnt. Rate-Limits werden in einer Redis-Datenbank gespeichert; bei Redis-Ausfall greift Fail-Closed (Anfrage wird abgelehnt), sofern das Feature nicht explizit via RATE_LIMIT_FAIL_OPEN_FEATURES auf Fail-Open konfiguriert ist.

Die konkreten Schwellenwerte (z. B. 20 Aufrufe pro 5 min für Abwesenheits-Anlage, 3 Aufrufe pro 5 min für LDAP-Test) sind in den jeweiligen Route-Handlern als Argumente an checkRateLimit() ersichtlich und können vom Betreiber per ENV-Variable angepasst werden.

---

Diese Datenschutzerklärung wurde automatisch auf den Pflicht-Stand gemäß Art. 13 DSGVO gebracht (sec #3026) und um die implementierten Features ergänzt: Bradford-Faktor (#3198, #3199, #3201, #3202, #3203, #3204), Cookie- und localStorage-Disclosure (#3173, #3174), Drittanbieter-Disclosure (#3181), Rate-Limit-Disclosure (#3159), Cookie-Klassifikation + httpOnly-Spalte (#3177, #3180), Consent-Banner + Widerruf (#3175, #3182) sowie dedizierte /cookies-Route (#3179). Der Betreiber ist verpflichtet, jede als [AUSFÜLLEN] markierte Sektion vor Go-Live mit den tatsächlichen Daten des Verantwortlichen, der Aufsichtsbehörde und der Subdienstleister zu füllen. Hinweis: Bußgeldrahmen bei Verstoß gegen Art. 13 DSGVO gemäß Art. 83(5)(b) DSGVO: bis zu 20 Mio. € oder 4 % des Jahresumsatzes.