Technisch-Organisatorische Maßnahmen (TOM)
gemäß Art. 32 DSGVO · pflegeanruf.de
1. Beschreibung der Verarbeitung
pflegeanruf.de ist eine mandantenfähige SaaS-Plattform, die es ambulanten
Pflegediensten (APDs) und stationären Pflegeeinrichtungen ermöglicht, eingehende Telefonate durch einen
KI-Agenten entgegennehmen zu lassen. Das System empfängt strukturierte Gesprächsdaten (Transkripte,
Metadaten) per Webhook, speichert diese und stellt sie den berechtigten Mitarbeitern des jeweiligen
Pflegedienstes zur Auswertung bereit.
Betroffene Personengruppen
- Anrufer (u. a. Pflegebedürftige, Angehörige, Ärzte, Behörden)
- Mitarbeiter der Pflegedienste (Nutzer des Systems)
- Administratoren der Pflegedienste (Tenant-Admins)
Kategorien personenbezogener Daten
- Rufnummern der Anrufer (optional, pseudonymisiert)
- Gesprächstranskripte (ggf. mit Gesundheitsbezug = besondere Kategorie nach Art. 9 DSGVO)
- KI-generierte Zusammenfassungen und Sentiment-Analysen
- Nutzer-E-Mail-Adressen und Rollen (Systemnutzer der APDs)
Verarbeitungsstandort
- Server: Dedizierter Linux-Server (Produktionsumgebung) bei Hetzner Online GmbH, Standort Deutschland
- Datenbank: PostgreSQL (lokal auf demselben Server, Docker-Container)
- KI-Telefonie: smao GmbH, Berlin (eigener AVV; Unterauftragsverarbeiter gem. Art. 28 DSGVO)
- Kein Drittlandtransfer durch pflegeanruf.de selbst; für smao-seitige Drittlandtransfers siehe AVV
Anlage 2
Hinweis zu ElevenLabs: ElevenLabs Inc. (USA) wird durch smao ausschließlich zur
Generierung synthetischer Stimmen (Text-to-Speech für Ansagetexte) eingesetzt. Es werden dabei keine
personenbezogenen Daten der Anrufer übermittelt – kein datenschutzrelevanter Transfer von
Kundendaten.
2. Technische Maßnahmen
2.1 Zutrittskontrolle
Schutz gegen unbefugten
physischen Zutritt zu Datenverarbeitungsanlagen
| Maßnahme |
Umsetzung |
Status |
| Physische Serverzugangssicherung |
Server in gesichertem Rechenzentrum von Hetzner Online GmbH mit Zutrittsprotokollierung und
ISO 27001-Zertifizierung |
Implementiert |
| Serverraum-Zutrittskontrolle |
Zugang ausschließlich autorisiertem Rechenzentrumspersonal des Providers; kein physischer
Zugriff durch Entwicklungsteam |
Implementiert |
| Remote-only Serverbetrieb |
Serverbetrieb ausschließlich remote via SSH; kein lokaler physischer Zugang durch
pflegeanruf.de |
Implementiert |
2.2 Zugangskontrolle
Schutz gegen unbefugte
Systemnutzung
| Maßnahme |
Umsetzung |
Status |
| SSH-Key-only Authentifizierung |
Passwort-Login per SSH deaktiviert (PasswordAuthentication no); ausschließlich
Ed25519/RSA-4096-Schlüssel |
Implementiert |
| Root-Login deaktiviert |
PermitRootLogin no in /etc/ssh/sshd_config |
Implementiert |
| Brute-Force-Schutz (SSH) |
Fail2ban: Sperre nach 3 Fehlversuchen für 1 Stunde |
Implementiert |
| Firewall (UFW/iptables) |
Nur Ports 22 (SSH), 80 (HTTP→Redirect), 443 (HTTPS) und 8181 (Admin-API, IP-beschränkt)
geöffnet |
Implementiert |
| SSH-Session-Timeout |
Automatische Trennung inaktiver Sessions nach 5 Minuten
(ClientAliveInterval 300) |
Implementiert |
| Minimale SSH-Schlüssel |
Nur Ed25519 und RSA-4096; DSA-Keys entfernt; MaxAuthTries 3 |
Implementiert |
| Rate-Limiting Login-Endpunkt |
Schutz des Web-Login-Endpunkts gegen Brute-Force |
Ausstehend |
2.3 Zugriffskontrolle
Steuerung, wer auf welche Daten
zugreifen darf
| Maßnahme |
Umsetzung |
Status |
| Rollenbasiertes Zugriffssystem (RBAC) |
4-stufiges Rollenmodell: PlatformAdmin, TenantAdmin, User, ReadOnly – jeder Endpunkt ist
rollengeschützt |
Implementiert |
| Mandantentrennung (Row-Level-Security) |
Alle Datenbanktabellen enthalten tenant_id; jede Query wird per
WHERE tenant_id = <jwt_tenant_id> gefiltert; architekturell erzwungen
|
Implementiert |
| JWT-Authentifizierung (HMAC-SHA256) |
Zustandslose Tokens; tenant_id und role sind im Token enthalten,
nicht in Request-Parametern; kein PII im Payload |
Implementiert |
| Getrennte JWT-Secrets |
JWT_SECRET_KEY (Dashboard) und JWT_SECRET_KEY_ADMIN (Admin-Panel)
sind kryptographisch unabhängig – kompromittiertes Dashboard-Token gewährt keinen
Admin-Zugriff |
Implementiert |
| HTTP-only Cookies |
Authentifizierungs-Cookies als HttpOnly und Secure gesetzt – kein
JavaScript-Zugriff möglich |
Implementiert |
| 404 statt 403 bei Fremdressourcen |
Nicht-existierende oder fremde Datensätze liefern 404 Not Found – keine
Preisgabe der Existenz fremder Daten |
Implementiert |
| Admin-API IP-Beschränkung |
Admin-Panel (Port 8181) nur über VPN/SSH-Tunnel oder IP-Whitelist erreichbar |
Implementiert |
| Zwei-Faktor-Authentifizierung (2FA) |
2FA für Admin-Zugänge |
Ausstehend |
2.4 Weitergabekontrolle
Schutz gegen unbefugte
Übertragung und Bekanntmachung von Daten
| Maßnahme |
Umsetzung |
Status |
| TLS-Verschlüsselung (HTTPS) |
Nginx erzwingt HTTPS über TLS 1.2+; automatische Weiterleitung von HTTP nach HTTPS |
Implementiert |
| HSTS-Header |
Strict-Transport-Security: max-age=31536000; includeSubDomains – verhindert
Downgrade-Angriffe |
Ausstehend |
| CORS-Whitelist |
Nur explizit freigegebene Produktionsdomains per CORS zugelassen |
Implementiert |
| Webhook-Signaturprüfung |
Eingehende Webhooks per HMAC-SHA256 verifiziert inkl. Zeitstempel-Prüfung
(Replay-Prävention, 60-Sek.-Fenster) |
Implementiert |
| Replay-Protection (Redis-Cache) |
Redis-backed Signature-Cache für vollständige Replay-Abwehr |
Ausstehend |
| Keine sensitiven Daten in Logs |
Tokens, Signaturen, Passwörter werden niemals geloggt |
Implementiert |
| Datenbankisolation |
PostgreSQL und Redis nur über internes Docker-Netzwerk erreichbar; kein externer Port
geöffnet |
Implementiert |
| Request-Size-Limiting |
Maximale Payload-Größe für Webhook-Requests (5 MB) |
Ausstehend |
2.5 Eingabe- und Verarbeitungskontrolle
Nachvollziehbarkeit und
Richtigkeit der Datenverarbeitung
| Maßnahme |
Umsetzung |
Status |
| Pydantic-Schema-Validierung |
Alle eingehenden API-Requests durch Pydantic-Modelle validiert; fehlerhafte Payloads werden
mit 400 Bad Request abgelehnt |
Implementiert |
| ORM / Prepared Statements |
Ausschließlich SQLAlchemy ORM mit Prepared Statements; kein String-Interpolation in
SQL-Abfragen (SQL-Injection-Schutz) |
Implementiert |
| Einwilligungspflicht (Consent) |
Webhook-Payload muss consent_given=true enthalten; dreifache Prüfung (Schema,
API-Layer, Handler) – ohne Einwilligung keine Datenspeicherung |
Implementiert |
| Audit-Logging |
Jede Webhook-Verarbeitung mit Zeitstempel, Tenant-ID und Gesprächs-ID protokolliert |
Implementiert |
| DSGVO-sicheres Logging |
E-Mail-Adressen in Logs maskiert (u***@example.com); keine Rufnummern oder
IP-Adressen in Logs |
Implementiert |
| Fehler-Responses ohne Stacktrace |
Produktionsfehler liefern generische Fehlermeldungen; Details nur intern geloggt |
Implementiert |
| Debug-Modus deaktiviert |
DEBUG=False in Produktionsumgebung |
Implementiert |
| Webhook Rate-Limiting |
Begrenzung eingehender Webhooks je Mandant (konfigurierbar) |
Geplant |
2.6 Verfügbarkeitskontrolle
Schutz vor Datenverlust und
Sicherstellung der Verfügbarkeit
| Maßnahme |
Umsetzung |
Status |
| Automatische Datensicherung |
Tägliche PostgreSQL-Dumps per Cron-Job (2:00 Uhr UTC); 30-Tage-Aufbewahrung lokal |
Implementiert |
| Off-site Backup (Hetzner Storage Box) |
Tägliche Übertragung auf geografisch getrennten Speicher (Hetzner Storage Box oder
gleichwertig, EU) |
Implementiert |
| Backup-Monitoring |
Backup-Logs täglich auf Erfolg geprüft |
Implementiert |
| Backup-Integritätsprüfung |
Backups nach Erstellung auf Vollständigkeit geprüft |
Implementiert |
| Quartalsweiser Wiederherstellungstest |
Quartalsweiser Restore-Test; Ergebnis dokumentiert |
Implementiert |
| Health-Check-Endpunkte |
GET /api/health prüft Datenbank- und Redis-Konnektivität |
Implementiert |
| Container-Orchestrierung |
Docker Compose mit restart: unless-stopped für alle Services |
Implementiert |
| Docker-Log-Rotation |
Max. 100 MB pro Log-Datei, max. 3 Dateien pro Container (daemon.json) |
Implementiert |
| Monitoring & Alerting |
Uptime-Monitoring (z. B. UptimeRobot) mit E-Mail-/Slack-Alert bei Ausfall |
Implementiert |
2.7 Mandantentrennung (Trennbarkeit)
Getrennte Verarbeitung von Daten
unterschiedlicher Mandanten
| Maßnahme |
Umsetzung |
Status |
| Logische Datentrennung |
Alle Tabellen (conversations, transcripts, users)
enthalten tenant_id als NOT-NULL-Pflichtfeld |
Implementiert |
| Erzwungene Tenant-Filterung |
Datenbankabfragen ohne tenant_id-Filter architekturell ausgeschlossen;
tenant_id ausschließlich aus verifiziertem JWT |
Implementiert |
| Tenant-spezifische Webhook-Secrets |
Jeder Mandant hat ein eigenes HMAC-Webhook-Secret; kein gemeinsames Shared Secret |
Implementiert |
| Fehler-Isolation |
Fehlerzustände eines Mandanten beeinflussen keine anderen Mandanten (Docker-Isolation,
separate DB-Verbindungen) |
Implementiert |
| AVV-Flag im System |
Jeder Mandant muss dpa_signed=true im System haben; consent_given
auf Tenant-Ebene |
Implementiert |
2.8 Verschlüsselung und Pseudonymisierung
| Maßnahme |
Umsetzung |
Status |
| Passwort-Hashing (Bcrypt) |
Bcrypt mit 12 Runden; Klartext-Passwörter werden niemals gespeichert |
Implementiert |
| Kryptographisch sichere Secrets |
JWT-Schlüssel, Webhook-Secrets und DB-Passwörter als 32-Byte-Zufallsstrings
(OpenSSL rand -hex 32) |
Implementiert |
| HMAC-SHA256 mit Constant-Time-Vergleich |
Webhook-Authentifizierung; Constant-Time-Vergleich verhindert Timing-Angriffe |
Implementiert |
| Rufnummern-Pseudonymisierung |
Anrufer-Rufnummern optional und nur auf Anforderung gespeichert; Hash-basiertes
Pseudonymisierungskonzept vorhanden |
Teilweise |
| Keine Audio-Speicherung |
Sprachaufnahmen werden nicht gespeichert; ausschließlich Texttranskripte nach
KI-Verarbeitung |
Implementiert |
| Verschlüsselung in Transit |
TLS 1.2+ für alle externen API-Verbindungen; interne Docker-Kommunikation über isoliertes
Bridge-Netzwerk |
Implementiert |
2.9 Rate-Limiting und DoS-Schutz
| Maßnahme |
Umsetzung |
Status |
| Webhook Rate-Limiting |
Begrenzung eingehender Webhooks je Mandant (konfigurierbar) |
Geplant |
| Login Rate-Limiting |
Schutz des Login-Endpunkts gegen Brute-Force |
Ausstehend |
| Request-Size-Limiting |
Maximale Payload-Größe für Webhook-Requests (5 MB) |
Ausstehend |
| Replay-Protection |
Timestamp-basierte Replay-Prävention (60-Sek.-Fenster); Redis-backed Signature-Cache |
Teilweise |
3. Organisatorische Maßnahmen
3.1 Datenschutzorganisation
| Maßnahme |
Umsetzung |
| Verantwortlicher |
Gerrit Brinkhaus, pflegeanruf.de, Frankfurt am Main |
| Datenschutzbeauftragter (DSB) |
Nicht gesetzlich erforderlich gem. § 38 BDSG; Datenschutzverantwortlicher intern: Gerrit
Brinkhaus |
| AVV mit Mandanten |
Mit jedem Mandanten (APD/Pflegeeinrichtung) wird ein AVV gem. Art. 28 DSGVO abgeschlossen;
dpa_signed-Flag im System |
| Unterauftragnehmer-Übersicht |
Dokumentierte Liste aller Unterauftragsverarbeiter gem. Anlage 2 des AVV (Hetzner, smao,
weitere) |
| Datenschutz-Folgenabschätzung (DSFA) |
Gem. Art. 35 DSGVO erforderlich wegen systematischer Verarbeitung von Gesundheitsdaten – vor
Produktivbetrieb mit Echtdaten durchzuführen |
3.2 Zugang und Berechtigungsmanagement
| Maßnahme |
Umsetzung |
| Minimalprinzip (Need-to-know) |
Mitarbeiter erhalten ausschließlich die Rechte, die ihre Aufgaben erfordern |
| Sofortige Sperrung bei Ausscheiden |
Deaktivierung von Nutzerkonten und Widerruf von SSH-Schlüsseln bei Mitarbeiterausscheiden
|
| Regelmäßige Rechteprüfung |
Überprüfung der Nutzerzugänge und Rollen mindestens halbjährlich |
| Passwort-Richtlinie |
Starke Passwörter verpflichtend; Initial-Passwörter werden beim ersten Login geändert |
| Zwei-Faktor-Authentifizierung |
2FA für Admin-Zugänge empfohlen; technische Umsetzung ausstehend (siehe offene Maßnahmen)
|
| Geheimhaltungsvereinbarungen |
Alle Mitarbeiter mit Systemzugang haben NDA / Vertraulichkeitsverpflichtungen unterzeichnet
|
3.3 Sensibilisierung und Schulung
| Maßnahme |
Umsetzung |
| Datenschutzschulung |
Jährliche DSGVO-Pflichtschulung für alle Mitarbeiter mit Datenzugang |
| Sicherheitsschulung |
Training zu sicherem Umgang mit Zugangsdaten, Phishing-Prävention und Incident Reporting
|
| Einarbeitung neuer Mitarbeiter |
Datenschutz- und Sicherheitsunterweisung vor erstem Systemzugang |
| Meldepflicht Sicherheitsvorfälle |
Alle Mitarbeiter sind verpflichtet, Sicherheitsvorfälle sofort zu melden |
3.4 Privacy by Design / Default
| Maßnahme |
Umsetzung |
| Datensparsamkeit |
Keine Speicherung von Sprachaufnahmen; nur das für die Verarbeitung unbedingt Notwendige
wird gespeichert |
| Einwilligung als technische Pflicht |
consent_given=true ist technisch verpflichtend; keine Datenspeicherung ohne
explizite Zustimmung |
| Automatische Datenlöschung |
30-Tage-Aufbewahrungsfrist; automatisierte Löschung nach Ablauf (Celery-Scheduled-Task) |
| Auskunft und Löschung |
API-Endpunkt für Datenlöschung je Mandant; manuelle Löschung auf Anfrage möglich |
| Kein PII in Tokens |
JWT-Tokens enthalten keine personenbezogenen Daten außer internen Nutzer-IDs |
3.5 Umgang mit Datenpannen (Incident Response)
| Maßnahme |
Umsetzung |
| Incident-Response-Plan |
Dokumentiertes Verfahren: Erkennung → Bewertung → Eindämmung → Meldung → Nachbereitung |
| Meldepflicht Behörden (Art. 33 DSGVO) |
Bei Datenpanne mit Risiko: Meldung an Aufsichtsbehörde innerhalb 72 Stunden; interne Meldung
innerhalb 24 Stunden |
| Betroffenenbenachrichtigung (Art. 34) |
Bei hohem Risiko: Information betroffener Personen |
| Eskalationsmatrix |
Klar definierte Ansprechpartner je Schweregrad (DevOps, DSB, Geschäftsführung) |
| Vorfallsdokumentation |
Jeder Sicherheitsvorfall wird vollständig dokumentiert und archiviert |
| Kommunikationsregel |
Keine öffentliche Kommunikation über Vorfälle ohne Abstimmung mit DSB und Geschäftsführung
|
3.6 Backup und Wiederherstellung
| Maßnahme |
Umsetzung |
| Backup-Frequenz |
Täglich, automatisiert um 2:00 Uhr UTC |
| Aufbewahrung lokal |
30 Tage rollierend auf dem Produktionsserver |
| Aufbewahrung off-site |
Tägliche Kopie auf geografisch getrenntem Speicher (Hetzner Storage Box, EU) |
| Wiederherstellungstest |
Quartalsweiser Restore-Test; Ergebnis dokumentiert |
| Recovery Time Objective (RTO) |
Angestrebt: < 4 Stunden bei Serverausfall |
| Recovery Point Objective (RPO) |
Maximal 24 Stunden Datenverlust (entspricht Backup-Frequenz) |
| Backup-Integrität |
Backups nach Erstellung auf Vollständigkeit geprüft |
3.7 Unterauftragsverarbeiter
| Dienstleister |
Zweck |
Verarbeitungsort |
Drittland? |
AVV |
| Hetzner Online GmbH |
Hosting, Server, Backup |
Deutschland (EU) |
Nein |
Ja |
| smao GmbH |
KI-Telefonie, Transkription |
Deutschland/EU (eigener AVV) |
Nein (smao-seitig: SCCs) |
Ja |
| ElevenLabs Inc. |
Stimmgenerierung (synthetisch) – KEIN Transfer pers. Daten |
USA |
Kein pers. Datentransfer |
n.a. |
| Backup-Speicher |
Off-site Datensicherung |
EU (Hetzner Storage Box) |
Nein |
Ja |
| Monitoring-Dienst |
Verfügbarkeitsüberwachung |
EU bevorzugt |
Ggf. |
Erforderlich |
3.8 Wartung und Patch-Management
| Maßnahme |
Umsetzung |
| Betriebssystem-Updates |
Regelmäßige Sicherheitsupdates (apt upgrade); kritische Patches innerhalb 24
Stunden |
| Docker-Image-Updates |
Regelmäßige Aktualisierung der Basis-Images (PostgreSQL, Python, Redis) |
| Abhängigkeits-Scanning |
Regelmäßige Prüfung auf bekannte Schwachstellen in Python-Paketen (pip audit /
Dependabot) |
| Webhook-Secret-Rotation |
Empfehlung: quartalsweise Rotation aller Webhook-Secrets |
| SSL-Zertifikat-Erneuerung |
Automatisch via Let's Encrypt (certbot auto-renew); Ablauf wird überwacht |
| Penetrationstest |
Jährlicher Penetrationstest durch unabhängigen Dienstleister empfohlen |
4. Besondere Maßnahmen für den Pflegebereich (Art. 9 DSGVO)
Da Telefontranskripte im Pflegekontext regelmäßig Gesundheitsdaten enthalten, gelten gem. Art. 9 DSGVO
erhöhte Anforderungen:
| Maßnahme |
Begründung |
Umsetzung |
| Einwilligung auf Gesprächsebene |
Art. 9 Abs. 2 lit. a DSGVO: explizite Einwilligung des Anrufers erforderlich |
Webhook-Pflichtfeld consent_given=true; Einwilligung wird durch smao-KI-Dienst
beim Anrufer eingeholt (Ansage) |
| AVV auf Mandantenebene |
Pflegedienste sind als Auftraggeber (Verantwortliche) zu behandeln |
dpa_signed-Flag im Mandantensystem; schriftlicher AVV obligatorisch vor
Aktivierung |
| Minimale Speicherdauer |
Gesundheitsdaten nur so lange wie unbedingt nötig |
30-Tage-Löschfrist; auf Anforderung vorzeitige Löschung möglich |
| Zugriffsbeschränkung |
Keine Weitergabe von Gesprächsinhalten an unberechtigte Dritte |
Rollenbasiertes Zugriffsmodell (RBAC); Tenants sehen ausschließlich ihre eigenen Daten |
| Keine Audio-Speicherung |
Datensparsamkeit bei besonders sensiblen Daten |
Sprachaufnahmen werden nicht gespeichert; nur Texttranskripte nach KI-Verarbeitung |
| DSFA (Art. 35 DSGVO) |
Pflicht bei systematischer Verarbeitung sensibler Daten |
Vor Produktivbetrieb mit Echtdaten durchzuführen – noch ausstehend |
5. Offene Maßnahmen und Handlungsempfehlungen
Die folgenden Maßnahmen sind noch nicht vollständig umgesetzt. Die transparente Auflistung ist
Bestandteil des aktiven Risikomanagements. Kritische und hohe Maßnahmen sind vor Aufnahme des
Produktivbetriebs mit Echtdaten umzusetzen.
| Priorität |
Maßnahme |
Aufwand |
Frist |
Verantwortlich |
| KRITISCH |
Rate-Limiting auf Login-Endpunkt |
15 Min. |
Sofort |
Gerrit Brinkhaus |
| KRITISCH |
Replay-Protection via Redis (Signature-Cache) |
4 Std. |
Sofort |
Gerrit Brinkhaus |
| HOCH |
Request-Size-Limiting für Webhooks (5 MB) |
30 Min. |
< 1 Woche |
Gerrit Brinkhaus |
| HOCH |
HSTS-Header in Nginx/App-Layer |
10 Min. |
< 1 Woche |
Gerrit Brinkhaus |
| HOCH |
Zwei-Faktor-Authentifizierung für Admin |
1–2 Tage |
< 1 Monat |
Gerrit Brinkhaus |
| MITTEL |
Datenschutz-Folgenabschätzung (DSFA) |
Extern |
< 1 Monat |
DSB / extern |
| MITTEL |
Jährlicher Penetrationstest |
Extern |
< 3 Monate |
Extern |
| MITTEL |
Webhook Rate-Limiting (je Mandant) |
4–6 Std. |
< 1 Monat |
Gerrit Brinkhaus |
| NIEDRIG |
Hash-basierte Rufnummern-Pseudonymisierung |
1 Tag |
< 3 Monate |
Gerrit Brinkhaus |
6. Bestätigung und Überprüfung
Dieses Dokument beschreibt den Stand der technischen und organisatorischen Schutzmaßnahmen für
pflegeanruf.de zum oben genannten Datum. Es ist:
- Jährlich oder bei wesentlichen Systemänderungen zu aktualisieren
- Bestandteil aller Auftragsverarbeitungsverträge mit Mandanten (APDs/Pflegeeinrichtungen)
- Bei Datenschutzaudits und behördlichen Kontrollen vorzulegen
| Funktion |
Name |
Datum |
Unterschrift |
| Verantwortlicher / Geschäftsführung |
Gerrit Brinkhaus |
|
|
| Datenschutzbeauftragter (DSB) |
Intern – Gerrit Brinkhaus |
|
|
| Technischer Leiter |
Gerrit Brinkhaus |
|
|
7. Referenzdokumente
| Dokument |
Beschreibung |
GOLIVE_THREAT_ANALYSIS.md |
Risikoanalyse vor Produktivbetrieb |
WEBHOOK_SECURITY_EVALUATION.md |
Detailbewertung Webhook-Sicherheit |
AUTH_SEPARATION.md |
Authentifizierungstrennung Dashboard / Admin |
SSH_SECURITY_HARDENING.md |
SSH-Härtungsmaßnahmen |
ARCHITECTURE.md |
Systemarchitektur |
PRODUCTION_RUNBOOK.md |
Betriebshandbuch |
| AVV pflegeanruf.de |
Auftragsverarbeitungsvertrag gem. Art. 28 DSGVO |
| Hetzner TOM |
Technisch-organisatorische Maßnahmen der Hetzner Online GmbH |
| smao AVV |
AVV der smao GmbH (separat abgeschlossen) |
Stand: März 2026 · Version 1.0 · pflegeanruf.de · Klassifizierung: Vertraulich
