Einreichungspaket „Hilferuf“-Push – LIA, TIA & Subprozessoren
Produkt: Accidents@School – Das Unfallbuch
Stand: 27.08.2025
Geltung: Push-Benachrichtigungen für Hilferufe (Expo / APNs / FCM)
Teil A – Legitimate-Interest-Abwägung (LIA) für Hilferuf‑Push
Verantwortlicher: jeweilige Schule/Schulträger
Auftragsverarbeiter: ClassyMade GmbH (Hosting/Betrieb), Expo (Push-Relay), Apple APNs / Google FCM (Plattformdienste)
Verarbeitung: Versand generischer Push-Hinweise „Es gab einen Hilferuf“ an berechtigte Rollen derselben Schule (primär Schulsanitätsdienst).
Datenkategorien (Push‑Pfad): Geräte‑Push‑Token (Expo/APNs/FCM), technische Zustellmetadaten (Zeit, Ticket/Receipt, Status, Fehlercode).
Besondere Kategorien: keine im Push (keine Gesundheits-/Unfalldaten, keine Namen/Standorte).
Betroffene: Mitglieder Schulsanitätsdienst, ggf. Lehrkräfte (Eskalation), Hilferuf auslösende Person.
A1. Zwecktest (Zulässigkeit & Legitimität)
- Schnelle Alarmierung zur Gefahrenabwehr/Ersthilfe im Schulbetrieb (Schutz von Leben/Gesundheit).
- Organisations- & Arbeitssicherheitsinteressen der Schule (präventiv, reaktiv).
- Funktion ist Bestandteil des vertraglich zugesagten Leistungsumfangs der App.
A2. Erforderlichkeitstest (Notwendigkeit & Datenminimierung)
- Generische Payload ohne Personen-/Gesundheitsdaten („Es gab einen Hilferuf“).
- Kein Versand von Detaildaten im Push; Abruf erst nach Login über gesicherte API (Pull‑Prinzip).
- Versand nur an berechtigte Rollen derselben Schule (SSD; Eskalation zeitverzögert an Lehrkräfte).
- Token-Purge bei Logout/Deinstallation; Auto‑Purge nach 90 Tagen Inaktivität.
- Rate‑Limits & Missbrauchsprävention auf dem Hilferuf‑Endpunkt.
A3. Abwägungstest (Interessenabwägung)
Aspekt
Betroffeneninteresse
Gegenmaßnahmen
Bewertung
Informationsgehalt Push
Risiko der Offenlegung sensibler Inhalte
Push ohne Inhalte; nur generischer Hinweis; data bleibt leer
Niedrig
Personenbezug über Token
Pseudonyme Token könnten einzelnen Personen zugeordnet werden
Token verschlüsselt gespeichert (AES‑GCM, KMS), getrenntes Mapping, RBAC, keine Klar‑Tokens in Logs
Niedrig
Drittlandtransfer
US‑Dienste (Expo/APNs/FCM) könnten Logs verarbeiten
SCC, ggf. DPF (sofern zertifiziert), TIA dokumentiert, minimierte Payload
Niedrig‑Mittel
Fehladressierung
Push an falsche Empfänger
Mandantentrennung (School‑ID), strikte Rollenprüfung, Token‑Cleanup
Niedrig
Ergebnis: Die berechtigten Interessen der Schule (Sicherheit/Vitalinteressen) überwiegen, da die Verarbeitung streng datensparsam erfolgt und umfangreiche Schutzmaßnahmen greifen.
Review‑Zyklus: jährlich oder bei Änderung des Push‑Flows/Anbieters.
Teil B – Transfer Impact Assessment (TIA) – Kurzblätter
Hinweis: Einheitliches Schema; „DPF, sofern zertifiziert“ und SCC sind als Standard vorgesehen. Inhalte werden nicht übertragen.
B1. Expo (Push Relay)
Rolle: Unterauftragsverarbeiter (Relay)
Sitz/Region: USA (weltweit verteilte Infrastruktur)
Zweck: Weiterleitung von Push‑Nachrichten an APNs/FCM
Datenkategorien: Expo‑Push‑Token, Zustell‑Metadaten (Tickets/Receipts, Status, Fehlercodes)
Inhalte: keine Personen-/Gesundheitsdaten (Body generisch, data leer)
Rechtsinstrumente: SCC (Controller‑to‑Processor/Processor‑to‑Processor), DPF sofern zertifiziert
Technische Maßnahmen: TLS, Token‑Minimierung, kurze Speicherung von Receipts
Öffentlich‑rechtlicher Zugriff: möglichkeitstheoretisch in den USA; Risiko reduziert durch Pseudonymisierung (Token), keine Inhalte
Bewertung: Restrisiko niedrig–mittel; akzeptabel mit SCC/DPF + Minimierung
Entscheidung: Transfer zulässig; zusätzliche Kontrollen: jährliches TIA‑Review, Vertrags‑/Zertifikatsprüfung
B2. Apple APNs
Rolle: Infrastrukturanbieter / Empfänger, teils eigener Verantwortlicher (Betriebs-/Sicherheitslogs)
Sitz/Region: USA / global
Zweck: Zustellung von Push an iOS‑Geräte
Datenkategorien: APNs‑Device‑Token, Zustell‑Metadaten
Inhalte: keine (generischer Text, data leer)
Rechtsinstrumente: SCC (soweit anwendbar), DPF sofern zertifiziert
Technische Maßnahmen: TLS, store‑and‑forward ohne langfristige Inhaltsablage
Öffentlich‑rechtlicher Zugriff: möglichkeitstheoretisch; Risiko minimiert (pseudonyme Token, keine Inhalte)
Bewertung: Restrisiko niedrig–mittel
Entscheidung: Transfer zulässig bei SCC/DPF + jährlichem Review
B3. Google FCM
Rolle: Infrastrukturanbieter / Empfänger, teils eigener Verantwortlicher (Betriebs-/Sicherheitslogs)
Sitz/Region: USA / global (regionale Pop‑Standorte)
Zweck: Zustellung von Push an Android‑Geräte
Datenkategorien: FCM‑Registration‑Token, Zustell‑Metadaten
Inhalte: keine (generischer Text, data leer)
Rechtsinstrumente: SCC (soweit anwendbar), DPF sofern zertifiziert
Technische Maßnahmen: TLS, keine dauerhafte Inhaltsablage
Öffentlich‑rechtlicher Zugriff: möglichkeitstheoretisch; Risiko minimiert (pseudonyme Token, keine Inhalte)
Bewertung: Restrisiko niedrig–mittel
Entscheidung: Transfer zulässig bei SCC/DPF + jährlichem Review
Teil C – Subprozessoren‑Kurzblatt (Push & Betrieb)
Anbieter
Rolle
Region
Daten (Push‑Kontext)
Rechtsin-strumente
Aufbewahr-ung (Push)
Sicherheits-zusagen/TOMs
Kontakt/Info
Expo
Push‑Relay (Unterauftrags-verarbeiter)
USA/global
Expo‑Token, Tickets/Receipts, Status, Fehlercode
SCC, DPF (sofern zert.)
Kurzzeitig (Receipts)
TLS, Minimierung, keine Inhalte
www.expo.dev (DPA/Docs)
Apple APNs
Infrastruktur-anbieter / Empfänger
USA/global
APNs‑Device
‑Token, Zustell‑Logs
SCC (so weit anwendbar), DPF (sofern zert.)
Kurzzeitig (Betriebslogs)
TLS, Store‑and
‑forward
developer.apple.com
Google FCM
Infrastruktur-anbieter / Empfänger
USA/global
FCM
‑Registration ‑Token, Zustell‑Logs
SCC (so weit anwendbar), DPF (sofern zert.)
Kurzzeitig (Betriebslogs)
TLS, Store‑and
‑forward
firebase.google.com
Hetzner
Hosting (AV)
EU/EWR
keine Push‑Inhalte; Anwendungs‑/API‑Traffic
AV‑Vertrag (EU)
n/a
ISO 27001, TLS, phys. Sicherheit
www.hetzner
.com
AWS (SES)
E‑Mail (AV)
EU (eu‑central‑1)
n/a (nicht Push)
AVV (EU)
n/a
TLS, ISO
aws.amazon
.com
Uptime Kuma
Monitoring
EU (self‑hosted)
n/a (nicht Push)
interne Richtlinie
n/a
Zugriffsschutz, TLS
–
Hinweis: Für nicht‑Push‑bezogene Dienste (z. B. AWS SES) ist die Verarbeitung in den jeweiligen Dokumenten (VVT/AVV) beschrieben; obenstehende Tabelle dient der Vollständigkeit des Prüfpakets.
Teil D – Technischer Nachweis der Datenminimierung (Beispiele)
Minimal‑Payload (Expo):
{ "to": "ExponentPushToken[xxxxxxxxxxxxxxxxxxxxxx]", "title": "Accidents@School", "body": "Es gab einen Hilferuf", "priority": "high", "ttl": 60, "sound": "default" }
Serverseitige Policy (Pseudocode):
assert(!payload.data, 'Push data payload must be empty'); assert(/^(Es gab einen Hilferuf)$/.test(payload.body)); assert(recipients.every(r => r.role === 'Schulsanitätsdienst' || (isEscalation && r.role === 'User')));
Logging‑Maskierung (Beispiel):
PUSH_SENT school=ABC recipients=SSD count=4 ticket=abc123 token=ExponentPushToken[****ZENSIERT****]
Teil E – Token‑Policy (Kurzfassung)
- Speicherung von Expo‑Tokens verschlüsselt (AES‑GCM; Key im KMS).
- Löschung bei Logout/Deinstallation; Auto‑Purge nach 90 Tagen Inaktivität.
- Keine Klar‑Tokens in Logs; Admin‑Zugriff ausschließlich per RBAC.
- Jährliches Policy‑Review und Stichproben‑Audit.
Teil F – Review & Pflege
- Gültigkeit: bis zur Änderung des Push‑Flows/Anbieters oder maximal 12 Monate.
- Verantwortlich für Updates: Backend‑Entwicklung (in Abstimmung mit Datenschutzkoordination).
- Versionierung: Änderungen werden im Changelog der Datenschutzdokumentation vermerkt.