Sicherheit & Nachweise
Alles, was Datenschutzbeauftragte, Kirchenkreise, Kommunen und Prüfer von einem Software-Anbieter sehen wollen – an einem Ort, ohne Anfrage.
Eigenes Rechenzentrum in Deutschland
Wir hosten selbst: eigene Hardware, ein eigener virtueller Server und eine eigene Datenbank je App – kein externer Hoster, keine Daten in fremden Clouds.
Verschlüsselung & Härtung
TLS 1.3 mit HSTS, Content-Security-Policy, sichere Cookies (Secure/HttpOnly/SameSite), Geheimnisse verschlüsselt gespeichert.
Zwei-Faktor & Rechte je Person
Betreiber-Zugänge nur mit 2FA; Kundenkonten über Karl-SSO mit optionaler 2FA; Rollen und Rechte je Mandant und Person.
Audit-Log in jeder App
Jede sicherheitsrelevante Aktion wird protokolliert und zentral überwacht; Aufbewahrung je Mandant einstellbar.
Tägliche Backups
Verschlüsselte Sicherungen je App mit mehreren Generationen, Wiederherstellung getestet, Monitoring mit Alarmierung.
KI nur auf Wunsch
KI-Funktionen sind standardmäßig aus; Aktivierung durch den Kunden, Kennzeichnung nach Art. 50 KI-VO, alternativer EU-Endpunkt möglich.
Status der Nachweise und Zertifizierungen
| Nachweis | Status |
|---|---|
| DSGVO Art. 28 – AVV mit Anhängen | verfügbar |
| Kirchliches Datenschutzrecht (DSG-EKD / KDG) – AVV-Zusatz | verfügbar |
| TOM · VVT · Lösch- und Notfallkonzept | veröffentlicht |
| Allianz für Cyber-Sicherheit (BSI) | Teilnehmer – bestätigt 09/2026 |
| BITMi „Software Hosted in Germany" / „Made in Germany" | Siegel erhalten 2026 |
| CyberRisikoCheck DIN SPEC 27076 (BSI-Verfahren) | durchgeführt 09/2026 |
| Trusted Cloud Label / EU Cloud Code of Conduct | geplant 2027 |
| NIS2 | nicht direkt betroffen (unter Schwellenwert) – Lieferketten-Nachweise auf dieser Seite |
Dokumentenversion 2026-09. Fragen, Prüfanfragen oder Sicherheitsmeldungen: info@somalu.eu.
Technische und organisatorische Maßnahmen (TOM)
Technische und organisatorische Maßnahmen (Art. 32 DSGVO, § 27 DSG-EKD, § 26 KDG)
1. Vertraulichkeit
Zutrittskontrolle: Betrieb im eigenen Rechenzentrum des Anbieters in Deutschland auf eigener Server-Hardware; Zutritt ausschließlich für den Betreiber und namentlich benannte Personen, verschlossener Serverraum, Zutritte werden dokumentiert; kein externer Hosting-Dienstleister hat physischen oder logischen Zugriff.
Zugangskontrolle: Jede App läuft auf einem eigenen virtuellen Server mit eigener Datenbank (Instanz-Isolation). Administrativer Zugang nur per SSH-Schlüssel, kein Passwort-Login; Betreiber-Konten mit Zwei-Faktor-Authentisierung (TOTP); Kundenkonten über das zentrale Single Sign-on (Karl-SSO) mit optionaler 2FA, Passwort-Hashing (bcrypt/Argon2), Rate-Limit und Sperre nach Fehlversuchen.
Zugriffskontrolle: Rollen- und Rechtesystem je Mandant (Administrator, Bearbeiter, Leser u. a.); Rechte werden je Person einzeln vergeben; Betreiber sieht Kundendaten nur nach ausdrücklicher Freigabe (Support-Sitzung) – bei Karl-Kasse und Karl-Pass technisch ausgeschlossen (Zero-Knowledge).
Trennungskontrolle: Strikte Mandantentrennung in jeder App (tenant_key auf jeder Tabelle); getrennte Datenbanken je App; Test-/Demo-Umgebungen getrennt vom Produktivbetrieb.
Pseudonymisierung/Verschlüsselung: Transportverschlüsselung TLS 1.2/1.3 mit HSTS; Geheimnisse (API-Schlüssel, Zugangsdaten) verschlüsselt gespeichert (libsodium/OpenSSL); Passwort-Manager (Karl-Pass) Ende-zu-Ende-verschlüsselt.
2. Integrität
Weitergabekontrolle: Datenübertragung ausschließlich über HTTPS; Sicherheits-Header (HSTS, Content-Security-Policy, X-Frame-Options, Referrer-Policy, Permissions-Policy); Cookies mit Secure/HttpOnly/SameSite; E-Mail-Versand über eigenes Mail-Gateway mit SPF/DKIM/DMARC.
Eingabekontrolle: Revisionssicheres Audit-Log in jeder App (wer hat wann was geändert), zentral ausgewertet im Betreiber-Sicherheitsmonitor; Aufbewahrung des Audit-Logs je Mandant konfigurierbar (Standard 365 Tage).
3. Verfügbarkeit und Belastbarkeit
Tägliche automatische Backups (Datenbank + Dateien) je App, verschlüsselt, mit Aufbewahrung von mindestens 10 Generationen; Wiederherstellung über den Betreiber getestet; Monitoring aller Server (Karl-Monitoring) mit Alarmierung; automatische Betriebssystem-Sicherheitsupdates und regelmäßige App-Updates über die zentrale Flottenverwaltung; Firewall und fail2ban auf allen Servern; Ressourcen-Autoskalierung.
4. Verfahren zur regelmäßigen Überprüfung
Datenschutz-Management: Verzeichnis der Verarbeitungstätigkeiten, Lösch-/Aufbewahrungskonzept, Notfall- und Meldekonzept (alle veröffentlicht unter somalu.eu/sicherheit.php); Incident-Response-Prozess mit 24-Stunden-Meldung an Kunden; automatischer Sicherheits-Scan des Webspace (Schadcode, Datei-Änderungen); jährliche Überprüfung der TOM und externer CyberRisikoCheck (DIN SPEC 27076).
Auftragskontrolle: Schriftliche AVV mit allen Kunden (Bestellprozess); Unterauftragsverarbeiter nur mit AVV/Standardvertragsklauseln; Weisungen dokumentiert über Ticketsystem.
Datenschutzfreundliche Voreinstellungen: Datensparsamkeit in jeder App; KI-Funktionen standardmäßig aus; Testlimits statt Vollzugriff; Löschfunktionen und Datenexport (Art. 15/17/20) in den Apps eingebaut.
Stand: 2026-09 – Änderungen werden unter somalu.eu/sicherheit.php veröffentlicht.
Unterauftragsverarbeiter
Unterauftragsverarbeiter (Anhang 2 zur AVV)
A. Stets eingesetzt
1. Hosting der Web- und Datenbankserver – KEIN Unterauftragsverarbeiter: Der Anbieter betreibt die Server (Virtualisierung, ein eigener virtueller Server und eine eigene Datenbank je App) im eigenen Rechenzentrum in Deutschland auf eigener Hardware. Es gibt keinen externen Hosting- oder Cloud-Dienstleister mit Zugriff auf Kundendaten.
2. E-Mail-Versand (Benachrichtigungen, Rechnungen) – KEIN Unterauftragsverarbeiter: eigenes Mail-Gateway des Anbieters im eigenen Rechenzentrum in Deutschland.
3. Domain/DNS-Registrar – verarbeitet keine Kundendaten (nur Domainverwaltung), daher kein Unterauftragsverarbeiter.
B. Optional – nur wenn der Kunde KI-Funktionen in einer App aktiviert
3. OpenAI, L.L.C. (USA) – Text- und Bilderzeugung, Vorschläge (Karl-KI, Karl-Ads, Karl-Familie, Karl-Share, Karl-Web, Karl-Reisen). Übermittelt werden nur die vom Nutzer eingegebenen Inhalte der jeweiligen Anfrage, keine Zugangsdaten; keine Nutzung zum Training durch OpenAI (API-Nutzungsbedingungen); Ort: USA; Grundlage: EU-U.S. Data Privacy Framework / EU-Standardvertragsklauseln. Der Kunde kann statt OpenAI einen anderen OpenAI-kompatiblen Endpunkt (z. B. europäischer Anbieter oder eigenes Modell) in den App-Einstellungen hinterlegen.
Änderungen werden mindestens 4 Wochen vorher hier veröffentlicht und per E-Mail an die Konto-Adresse mitgeteilt.
Stand: 2026-09
Verzeichnis der Verarbeitungstätigkeiten (Auftragsverarbeiter)
Verzeichnis der Verarbeitungstätigkeiten als Auftragsverarbeiter (Art. 30 Abs. 2 DSGVO)
Auftragsverarbeiter: SoMaLu Verwaltungs GmbH & Co. KG, vertreten durch Markus Thormann, Ausdorferstraße 7, 53489 Sinzig, E-Mail: info@somalu.eu, (im Folgenden „Auftragsverarbeiter“ oder „Anbieter“)
Datenschutz-Ansprechpartner: info@somalu.eu (ein Datenschutzbeauftragter ist nach § 38 BDSG derzeit nicht bestellt; weniger als 20 Personen mit ständiger Verarbeitung).
1. Betrieb der Kunden-Apps (SaaS) im Auftrag der Kunden
Verantwortliche: alle Kunden des Karl-Verbunds. Kategorien: siehe § 2 AVV. Ort: Deutschland. Empfänger: Unterauftragsverarbeiter gemäß Anhang 2. Löschung: gemäß Löschkonzept. TOM: siehe TOM-Dokument.
2. Zentrale Anmeldung (Karl-SSO)
Verarbeitung von Login-Namen, E-Mail, Passwort-Hash, 2FA-Geheimnis, Anmeldeprotokoll je Mandant; Zweck: Authentisierung und Lizenzprüfung; Löschung mit Mandantenlöschung, Anmeldeprotokoll nach 365 Tagen.
3. Backup und Wiederherstellung
Verschlüsselte Sicherungen je App; Aufbewahrung 10 Generationen (max. 90 Tage); Zweck: Verfügbarkeit.
4. Zentrales Audit- und Sicherheitsmonitoring
Sicherheitsrelevante Ereignisse der Apps (Anmeldungen, Rechteänderungen, Fehlversuche) mit Zeitstempel, Nutzerkennung, IP; Zweck: Erkennung von Angriffen (Art. 32); Aufbewahrung 365 Tage.
5. Support
Ticketdaten (Karl-Ticket): Name, E-Mail, Anfrageinhalt; Einsicht in Kundendaten nur nach Freigabe (protokollierte Support-Sitzung); Löschung 3 Jahre nach Abschluss.
6. Optionale KI-Funktionen
Übermittlung der Nutzereingabe an den konfigurierten KI-Dienst (Standard OpenAI, USA); keine Speicherung beim Anbieter über den App-Verlauf hinaus; Aktivierung durch den Kunden.
Eigene Verarbeitungen als Verantwortlicher (Kundenverwaltung, Rechnungsstellung, Website) sind in der Datenschutzerklärung beschrieben.
Stand: 2026-09
Lösch- und Aufbewahrungskonzept
Lösch- und Aufbewahrungskonzept
1. Grundsatz
Personenbezogene Daten werden gelöscht, sobald der Zweck entfällt und keine gesetzliche Aufbewahrungspflicht besteht. Jede App bietet Löschfunktionen (Einzeldatensatz, Mandant) und Datenexport; Löschungen werden im Audit-Log protokolliert (ohne Inhalt).
2. Fristen
Kundendaten in den Apps: Hoheit des Kunden; Löschung durch den Kunden jederzeit.
Mandant nach Vertragsende: Sperre zum Vertragsende, vollständige Löschung nach 30 Tagen (Rückholfrist), Backups nach max. 90 Tagen überschrieben.
Anmelde-/Audit-Protokolle: 365 Tage (je Mandant konfigurierbar, min. 30 Tage).
Server-Logfiles (IP-Adressen): 14 Tage.
Support-Tickets: 3 Jahre nach Abschluss.
Vertrags-, Rechnungs- und Buchungsdaten: 10 Jahre (§ 147 AO, § 257 HGB), danach Löschung.
Einwilligungsnachweise (AGB/Datenschutz/AVV/SEPA): Laufzeit + 3 Jahre (Nachweispflicht).
Bewerbungs- und Kontaktanfragen ohne Vertrag: 6 Monate.
Kita-spezifisch (Karl-Kita): Kinder-/Elterndaten nach Kündigungsdatum ins Archiv (nur Leitung), Löschung nach der landesrechtlichen Frist (Standard 12 Monate), Fotos sofort mit Widerruf der Einwilligung.
3. Verfahren
Automatische Aufräum-Jobs (Cron) je App für Protokolle, Backups und abgelaufene Mandanten; jährliche Überprüfung der Fristen; Lösch-Nachweis auf Anfrage.
Stand: 2026-09
Notfall- und Meldekonzept
Notfall- und Meldekonzept (Art. 33/34 DSGVO, §§ 32/33 DSG-EKD, §§ 33/34 KDG)
1. Erkennung
Zentrales Sicherheitsmonitoring (Audit-Ereignisse aller Apps, fail2ban, Schadcode-Scan, Server-Monitoring) mit E-Mail-Alarm an die Sicherheitsadresse des Betreibers; Meldeweg für Kunden und Nutzer: security@somalu.eu bzw. Ticket „Sicherheit“.
2. Sofortmaßnahmen (innerhalb 1 Stunde nach Kenntnis)
Betroffenen Dienst isolieren (IP-Sperre, Quarantäne, Passwort-/Schlüssel-Rotation), Beweise sichern (Logs, Snapshot), Umfang feststellen (welche Mandanten, welche Datenarten).
3. Meldung an Kunden (innerhalb 24 Stunden)
Information aller betroffenen Verantwortlichen per E-Mail an die Konto-Adresse mit: Art der Verletzung, betroffene Datenarten und Personen (soweit bekannt), wahrscheinliche Folgen, ergriffene Maßnahmen, Ansprechpartner – damit der Kunde seine Meldung an die Aufsichtsbehörde binnen 72 Stunden abgeben kann. Für eigene Verarbeitungen des Anbieters erfolgt die Meldung an die zuständige Aufsichtsbehörde (Landesbeauftragter für Datenschutz Rheinland-Pfalz) innerhalb von 72 Stunden.
4. Wiederherstellung
Rückspielen aus Backup (RPO 24 h, RTO 8 h je App), Health-Check, Freigabe; bei Bedarf Bereitstellung eines neuen App-Servers über die Flottenverwaltung.
5. Nachbereitung
Ursachenanalyse, Anpassung der TOM, Dokumentation im Vorfallsregister (auch Vorfälle ohne Meldepflicht), Information der Kunden über den Abschluss.
Stand: 2026-09