Sicherheits- und Datenschutzpraktiken

Wir setzen ein umfassendes Paket technischer und organisatorischer Maßnahmen (TOMs) gemäß Art. 32 DSGVO um, um die Vertraulichkeit, Integrität und Verfügbarkeit der Kundendaten sicherzustellen. Nachfolgend finden Sie einen Überblick über unsere betrieblichen Sicherheitspraktiken und Kontrollen:

Hosting & Architektur

Unsere Produktionssysteme werden in einem sicheren europäischen Rechenzentrum gehostet. Alle Server befinden sich in der EU (konkret in Deutschland), sodass die Daten unter EU-Rechtshoheit bleiben. Wir nutzen die Contabo GmbH als Infrastrukturprovider, die mehrere Tier-III+-Rechenzentren in Deutschland betreibt und damit für robuste physische Sicherheits- und Umweltschutzmaßnahmen sorgt.

Während wir die Herden-Daten jedes Züchters logisch voneinander trennen, streben wir mit ALPACUNA Herds eine globale Registrierungsfunktionalität an. Das bedeutet: Die Herden-Daten jedes Züchters sind logisch separiert, sodass kein Züchter Zugriff auf die Informationen eines anderen hat – Datenlecks zwischen Züchtern werden dadurch verhindert. Daten in Registern hingegen sind für alle ALPACUNA-Kunden einsehbar.

Der Zugriff auf die Server ist ausschließlich autorisiertem Personal vorbehalten, und administrativer Zugriff erfordert eine Multi-Faktor-Authentifizierung (siehe unten „Zugriffskontrollen“).

Verschlüsselung (Übertragung & Speicherung)

Datenübertragung: Sämtliche sensiblen Datenübertragungen sind mit TLS 1.3 verschlüsselt – dem neuesten Standard für Transportsicherheit. Wir erzwingen HTTPS für alle Client-Server-Kommunikationen und API-Aufrufe. Durch den Einsatz moderner TLS-Verschlüsselung sind die Daten während der Übertragung geschützt und können von unbefugten Dritten weder abgefangen noch gelesen werden.
Datenspeicherung: Eine vollständige Verschlüsselung ruhender Daten (at rest) ist derzeit auf den Anwendungs- und Datenbank-Volumes noch nicht implementiert. Das Risiko wird jedoch durch strikte rollenbasierte Zugriffskontrolle (RBAC/Least Privilege), verpflichtende Multi-Faktor-Authentifizierung (MFA) für Infrastrukturzugriffe, Mandantentrennung, gehärtete Hosts, kurze Aufbewahrungsfristen für nicht essentielle Daten sowie umfassendes Logging wirksam reduziert.

Backups & Notfallwiederherstellung

Wir erstellen regelmäßige Backups unserer Produktionsdatenbanken und kritischen Systeme, um Datenverlust vorzubeugen. Backups werden täglich durchgeführt und jeweils mindestens 7 Tage lang aufbewahrt, bevor sie sicher gelöscht werden. Dies ergibt ein Recovery Point Objective (RPO) von rund 24 Stunden (im schlimmsten Fall ginge maximal 1 Tag an Daten verloren) sowie ein konservatives Recovery Time Objective (RTO) von etwa 18 Stunden oder weniger bei größeren Vorfällen (Zeitspanne zur Wiederherstellung des Dienstes aus Backups). Diese Zielwerte stellen sicher, dass die Verfügbarkeit der Daten zeitnah wiederhergestellt werden kann – im Einklang mit dem DSGVO-Grundsatz der Verfügbarkeit und Belastbarkeit.

Backups werden verschlüsselt gespeichert und gegen unbefugten Zugriff geschützt. Wir verfügen über eine dokumentierte Backup-Strategie, die – wo möglich – Offsite- oder geo-redundante Speicherung vorsieht, um auch bei lokalen Ausfällen abgesichert zu sein.

Verfügbarkeit & Monitoring

Wir bemühen uns, unseren Dienst hochverfügbar zu halten und Ausfallzeiten zu minimieren. Zwar garantieren wir derzeit keine spezifische Verfügbarkeitsquote über eine SLA, doch ist unser Ziel die kontinuierliche Serviceverfügbarkeit. Es gibt keine festen Wartungsfenster, die längere Downtimes erfordern; stattdessen werden Updates und Verbesserungen nach gründlichen Tests ausgerollt – in der Regel ohne oder mit nur minimalen Unterbrechungen. Software-Updates werden bereitgestellt, sobald neue Funktionen fertiggestellt und getestet sind, anstatt in einem langsamen, periodischen Rhythmus. Das ermöglicht eine schnellere Reaktion auf Probleme und eine kontinuierliche Auslieferung von Verbesserungen.

Unsere Infrastruktur wird rund um die Uhr (24/7) mittels automatisierter Tools überwacht, die Serverzustand, Leistung und Sicherheitsindikatoren verfolgen. Dieses Monitoring erlaubt es uns, schnell auf ungeplante Ausfälle oder Anomalien zu reagieren und so eine hohe Verfügbarkeit zu erreichen. In der Praxis werden Vorfälle mit hoher Priorität behandelt und so schnell wie möglich behoben. Obwohl unser Team klein ist, sind wir einer schnellen Incident Response verpflichtet, sobald ein Verfügbarkeitsproblem auftritt.

Zugriffskontrollen

Wir setzen strenge Zugriffskontrollen um, um sicherzustellen, dass nur autorisierte Nutzer Zugriff auf die Daten und Funktionen erhalten, die für ihre jeweilige Rolle notwendig sind. Unser Ansatz folgt dem Prinzip der rollenbasierten Zugriffskontrolle (RBAC) in Kombination mit dem Least-Privilege-Prinzip. Jedem Benutzerkonto werden spezifische Rollen/Berechtigungen zugewiesen, und Nutzer erhalten ausschließlich den minimal erforderlichen Zugriff zur Erfüllung ihrer Aufgaben – nicht mehr. Dies verhindert eine schleichende Ausweitung von Rechten und begrenzt potenzielle Schäden, falls ein Konto kompromittiert wird. Die Trennung von Aufgabenbereichen und die Umsetzung des Least-Privilege-Prinzips sind zentrale Bestandteile unseres Sicherheitsmodells.

Administrativer Zugriff: Administratorkonten und Zugriffe auf die Backend-Infrastruktur sind mit zusätzlichen Sicherheitsmechanismen geschützt. Für Administratoren oder Entwicklerzugriffe auf Produktivsysteme ist Multi-Faktor-Authentifizierung (MFA) zwingend erforderlich. So ist z. B. der Zugriff auf unsere Cloud-Infrastruktur bei Contabo durch einen zusätzlichen Zwei-Faktor-Authentifizierungsschritt abgesichert (die Plattform von Contabo erzwingt 2FA beim Login). Dadurch wird sichergestellt, dass ein gestohlenes Passwort allein keinen Zugriff auf unsere Server ermöglicht.

Nutzerzugriff und Sitzungen: Die Authentifizierung unserer Anwendung erfolgt über Keycloak (unser Identity Provider), der optionale Zwei-Faktor-Authentifizierung für Benutzer-Logins unterstützt. Wir empfehlen allen Nutzern – insbesondere Administratoren – dringend, 2FA (z. B. TOTP-Apps) zu aktivieren, um ihre Konten zusätzlich zu schützen. Darüber hinaus erzwingen wir automatische Sitzungs-Timeouts und Abmeldungen bei Inaktivität. Benutzersitzungen verfallen nach einem gewissen Zeitraum der Inaktivität, um zu verhindern, dass verlassene, aber noch authentifizierte Sitzungen missbraucht werden. Wiederholte fehlgeschlagene Login-Versuche sind rate-limitiert und können zu Kontosperren oder Alarmmeldungen führen, um Brute-Force-Angriffe abzuwehren.

Zusammengefasst: Der Zugang zu Daten ist streng kontrolliert durch klar abgegrenzte Rollen, starke Authentifizierung, Sitzungsmanagement und eine enge Überwachung administrativer Berechtigungen.

Passwörter & Authentifizierung

Die gesamte Benutzer-Authentifizierung wird sicher über Keycloak, ein Open-Source-Identity-Management-System, abgewickelt. Passwörter werden in unserem System niemals im Klartext gespeichert – sie werden mit einem modernen, sicheren Hashing-Algorithmus verschlüsselt. Standardmäßig nutzt Keycloak Argon2 für das Passwort-Hashing, den von OWASP empfohlenen und 2015 ausgezeichneten Algorithmus der Password Hashing Competition. Argon2 in Kombination mit Salt und Stretching stellt sicher, dass selbst im unwahrscheinlichen Fall eines Zugriffs auf die Passwortdatenbank die tatsächlichen Passwörter extrem schwer zu entschlüsseln wären. Damit bieten wir eine starke Schutzschicht für Benutzeranmeldedaten.

Wir erzwingen eine starke Passwort-Policy für Benutzerkonten:

Passwörter müssen mindestens 8 Zeichen lang sein (wir unterstützen und empfehlen deutlich längere Passphrasen für erhöhte Sicherheit).
Diese Vorgaben entsprechen den aktuellen NIST-Richtlinien, die mindestens 8 Zeichen fordern und für administrative oder hoch privilegierte Konten sogar 15+ Zeichen empfehlen.
Unser System erlaubt eine breite Palette an Zeichen (Buchstaben, Zahlen, Symbole), sodass komplexe oder passphrasenartige Passwörter ohne unnötige Einschränkungen erstellt werden können.
Wir verzichten bewusst auf starre Kompositionsregeln, die oft unsichere Muster begünstigen. Der Schwerpunkt liegt auf Länge und Einzigartigkeit. (Nutzer werden ausdrücklich darauf hingewiesen, keine Passwörter mehrfach zu verwenden.)
Ist ein Passwort zu schwach, kann unser System es gemäß empfohlener Prüfverfahren ablehnen.

Single Sign-On (SSO): Unsere Plattform ist derzeit nicht in externe SSO/SAML/OIDC-Provider integriert – die Anmeldung erfolgt direkt mit den über Keycloak verwalteten Zugangsdaten. (Keycloak selbst unterstützt SAML/OIDC-Föderation, sodass wir künftig SSO-Optionen für Unternehmenskunden anbieten könnten, derzeit ist dies jedoch nicht aktiviert.) Jede Nutzerin bzw. jeder Nutzer verfügt über ein dediziertes Konto innerhalb unseres Systems.

Zusätzlich zum passwortbasierten Login unterstützen wir Zwei-Faktor-Authentifizierung (2FA), z. B. über TOTP-Apps. Dies kann von den Nutzern über die Kontoeinstellungen in Keycloak aktiviert werden und bietet eine zusätzliche Sicherheitsebene über das Passwort hinaus.

Zusammenfassend folgen unsere Authentifizierungsmechanismen den gängigen Best Practices der Branche: robustes Hashing für gespeicherte Geheimnisse, starke Passwortanforderungen, optionale MFA und keine veralteten oder unsicheren Authentifizierungsprotokolle.

Logging & Auditing

Wir führen detaillierte Audit-Logs über sicherheitsrelevante Ereignisse innerhalb des Systems. Zu den protokollierten Schlüsselereignissen gehören: Login-Versuche von Nutzern (erfolgreich und fehlgeschlagen), Passwortänderungen, administrative Aktionen (z. B. Änderungen an Konfigurationen oder Benutzerberechtigungen), Datenexporte oder Löschanfragen sowie andere sensible Vorgänge. Durch die Aufzeichnung dieser Ereignisse entsteht eine Prüfspur, die im Falle verdächtiger Aktivitäten oder eines Sicherheitsvorfalls analysiert werden kann. Beispielsweise werden administrative Aktionen und Änderungen an Sicherheitseinstellungen mit Zeitstempel und auslösendem Konto protokolliert, was Transparenz und Verantwortlichkeit schafft.

Log-Aufbewahrung: Wir bewahren Audit- und Sicherheitsprotokolle über einen längeren Zeitraum auf, um Untersuchungen und Compliance-Anforderungen zu unterstützen. Logs werden mindestens 90 Tage lang aktiv gespeichert. Eine ausreichende Protokollhistorie ist im Falle eines Cybersecurity-Vorfalls entscheidend, um die Abläufe nachvollziehen zu können. Branchenüblich ist eine Aufbewahrung von mindestens 3–6 Monaten (oder länger), um Incident Response und Forensik zu ermöglichen. Sämtliche Protokolldaten werden sicher gespeichert (mit Zugriffskontrollen), um ihre Vertraulichkeit zu gewährleisten.

Darüber hinaus protokollieren wir Zugriffe auf Produktionsinfrastruktur und Datenbanken – beispielsweise jede administrative Shell-Sitzung auf Produktivsystemen. Diese Maßnahmen ermöglichen es uns, Audits durchzuführen, die Einhaltung von Sicherheitsanforderungen nachzuweisen und im Falle eines Vorfalls die Ereignisse schnell und präzise nachzuvollziehen.

Schwachstellen- & Patch-Management

Aktuell zu bleiben und Sicherheits-Patches zeitnah einzuspielen, ist ein zentraler Bestandteil unseres Betriebs. Wir verfügen über einen Prozess zum Schwachstellenmanagement, der eine kontinuierliche Überwachung relevanter Sicherheitshinweise umfasst und es uns ermöglicht, Updates für unsere Software und Abhängigkeiten schnell anzuwenden. Zwar folgen wir keinem starren, periodischen Update-Zeitplan, doch wir verfolgen die eingesetzten Softwareversionen und Sicherheits-Patches aller Komponenten in unserem Stack manuell. Unser Team beobachtet hierzu Release Notes, Schwachstellendatenbanken (CVE-Meldungen) sowie Herstellerankündigungen, um sicherheitsrelevante Probleme frühzeitig zu erkennen. Wird eine kritische Schwachstelle in einer genutzten Komponente entdeckt, behandeln wir deren Behebung mit höchster Priorität.

In der Praxis:

Kritische Sicherheits-Patches spielen wir innerhalb weniger Tage nach Veröffentlichung ein, oft innerhalb von 24–72 Stunden bei schwerwiegenden Problemen.
Hochgefährliche Schwachstellen werden so schnell wie möglich adressiert (typischerweise innerhalb weniger Arbeitstage).
Mittlere und geringere Risiken werden in reguläre Entwicklungszyklen integriert, spätestens jedoch alle paar Wochen.

Dieser Ansatz entspricht Branchenempfehlungen, die eine schnelle Behebung kritischer Probleme und feste Intervalle für hoch- und mittelgradige Schwachstellen nahelegen.

Vor dem Einspielen testen wir Updates in unserer Staging-Umgebung, um sicherzustellen, dass keine Regressionen auftreten. Unsere CI/CD-Pipeline unterstützt uns dabei (siehe „Secure SDLC“), indem sie automatisierte Tests auf neuen Code anwendet. Wir nutzen derzeit keine automatisierten Dependency-Scanner in der CI (wie z. B. Dependabot); stattdessen prüfen unsere Entwickler Updates manuell und wenden sie bewusst an, was eine sorgfältige Kompatibilitätsprüfung ermöglicht. Gleichwohl erkennen wir den Mehrwert automatisierter Scanner und evaluieren deren Integration, um bei Drittanbieter-Bibliotheken schneller auf veraltete Komponenten hingewiesen zu werden (vgl. OWASP Top 10: Risiko durch unsichere Komponenten).

Zusätzlich pflegen wir ein internes Inventar sämtlicher Softwarekomponenten und deren Versionen (ein leichtgewichtiges SBOM – Software Bill of Materials). Dadurch können wir bei neuen CVE-Meldungen schnell erkennen, ob wir eine betroffene Version nutzen, und entsprechend handeln. Unsere Change-Management-Verfahren stellen sicher, dass alle Updates (ob Sicherheits-Patches oder andere Änderungen) einer Code-Review und Tests unterzogen werden, bevor sie in die Produktion gelangen.

Zusammengefasst: Auch ohne festen Patch-Zeitplan bleiben wir wachsam und reaktionsschnell: Sicherheitsupdates werden ohne unangemessene Verzögerung eingespielt, sobald sie verfügbar sind, wodurch das Risiko bekannter Schwachstellen effektiv reduziert wird.

Sicherheitsorientierte Softwareentwicklung (SDLC) & Tests

Sicherheit ist in unseren gesamten Softwareentwicklungsprozess (SDLC) integriert – von der Code-Planung bis hin zum Deployment. Unser Entwicklungsteam ist klein (zwei Entwickler), dennoch folgen wir strikten Prozessen, um Codequalität und Sicherheit sicherzustellen:

Code-Review (Vier-Augen-Prinzip): Alle Änderungen am Code müssen vor dem Merge mindestens eine Peer-Review durchlaufen. Wir befolgen die „Two-Person-Rule“: Eine Entwicklerin bzw. ein Entwickler schreibt den Code, eine weitere Person überprüft und genehmigt ihn. Dieses Vorgehen hilft, Fehler und potenzielle Sicherheitsprobleme frühzeitig zu erkennen. Es stellt sicher, dass mindestens zwei Personen jede wesentliche Änderung geprüft haben, wodurch die Wahrscheinlichkeit sinkt, dass Sicherheitslücken unentdeckt bleiben.

CI/CD-Pipeline und automatisierte Tests: Wir nutzen eine Continuous-Integration-Pipeline, die bei jedem Commit automatisierte Tests (Unit-Tests, Integrationstests) ausführt – insbesondere bevor Code in den Main-Branch gemergt wird. Nur Code, der alle Tests besteht, darf gemergt und anschließend bereitgestellt werden. Unsere Continuous-Delivery-Pipeline baut und deployed die Anwendung automatisch nach bestandenen Tests. Deployments sind in der Regel automatisiert, wodurch menschliche Fehler reduziert werden. Zudem existieren CI/CD-Gates, die einen Deployment-Prozess sofort stoppen, falls sicherheitsrelevante Tests oder Prüfungen fehlschlagen. So wird verhindert, dass unsicherer Code in die Produktion gelangt.

Secret Management: Sensible Konfigurationsdaten (z. B. API-Keys, Datenbankzugänge, Zugangsdaten zu Drittanbietern) werden mit besonderer Sorgfalt behandelt. Secrets werden niemals in Quellcode-Repositories gespeichert, sondern über sichere Konfigurationsmechanismen wie Umgebungsvariablen zur Laufzeit eingebunden. Der Zugriff auf diese Secrets ist streng auf die Dienste oder Administratoren beschränkt, die sie tatsächlich benötigen. Darüber hinaus rotieren wir Secrets regelmäßig (Passwörter, API-Tokens) und überwachen, dass keine Secrets versehentlich in Logs oder Fehlermeldungen auftauchen.

Statische Codeanalyse & Dependency-Scanning (geplant): Als zukünftige Verbesserung planen wir, statische Codeanalyse-Tools und Schwachstellen-Scanner für Abhängigkeiten in unsere CI-Pipeline zu integrieren. Damit ließe sich eine zusätzliche Sicherheitsebene schaffen, um gängige Coding-Fehler (wie OWASP-Top-10-Probleme) automatisiert zu erkennen und bei bekannten Sicherheitslücken in Bibliotheken zu warnen. Aktuell setzen wir auf manuelle Reviews, sind uns aber bewusst, dass automatisierte Tools die Sicherheit weiter erhöhen können.

Penetrationstests & Audits: Als Teil unseres Sicherheitsversprechens planen wir regelmäßige externe Penetrationstests unserer Anwendung und Infrastruktur. Auch wenn dies nicht ausdrücklich durch die DSGVO vorgeschrieben ist, gelten regelmäßige externe Tests als Best Practice, um proaktive Sicherheits-Compliance zu demonstrieren. Mindestens einmal jährlich soll ein unabhängiges Security-Audit oder Pentest stattfinden, um mögliche Schwachstellen aufzudecken. Externe Sicherheitsexperten können dabei etwaige Lücken in Authentifizierung, Zugriffskontrollen oder mögliche Injection-Schwachstellen identifizieren. Die Ergebnisse dienen uns zur Behebung von Schwachstellen und kontinuierlichen Verbesserung. Zusätzlich führen wir interne Sicherheitsreviews durch und nehmen gelegentlich an Secure-Coding-Schulungen teil, um mit neuen Bedrohungen Schritt zu halten.

Fazit: Unser SDLC berücksichtigt Sicherheit in jedem Schritt – von sorgfältigem Design, über Code-Review und Tests, bis hin zu Deployment und Wartung. Änderungen an Produktionssystemen werden kontrolliert, nachverfolgt und sicherheitsrelevante Anpassungen nur nach entsprechender Genehmigung umgesetzt. Durch diese Praktiken senken wir das Risiko, Schwachstellen einzuführen, und stellen sicher, dass gefundene Sicherheitslücken schnell behoben werden können.

Incident Response & Meldung von Datenschutzverletzungen

Auch mit starken Präventionsmaßnahmen erkennen wir an, dass Sicherheitsvorfälle auftreten können. Daher verfügen wir über einen Incident-Response-Plan, der festlegt, wie wir auf Sicherheitsvorfälle oder Datenschutzverletzungen reagieren und diese bewältigen. Zentrale Aspekte unseres Programms sind:

Meldung und Erkennung: Wir ermutigen unsere Mitarbeitenden, Nutzer und Partner, verdächtige Aktivitäten oder potenzielle Sicherheitsprobleme umgehend an unser Sicherheitsteam zu melden (hierfür stellen wir eine Kontaktadresse per E-Mail bereit). Unsere Monitoring- und Alarmierungssysteme (siehe oben) dienen ebenfalls als automatisierte Vorfall-Detektoren, etwa bei Dienstausfällen, wiederholten fehlgeschlagenen Logins oder anomalen Systemverhalten. Sobald ein Alarm oder eine Meldung eingeht, starten wir unverzüglich das Incident-Response-Verfahren.

Rollen und Verantwortlichkeiten: Unser Plan definiert klare Rollen für die Bearbeitung eines Vorfalls. Beispielsweise übernimmt unser leitender Entwickler die Rolle des Incident-Managers und koordiniert die technische Reaktion, während unser Datenschutzbeauftragter (oder eine gleichwertige Funktion) für Kommunikation und behördliche Meldungen zuständig ist. Eine interne Kommunikationsstrategie stellt sicher, dass alle relevanten Teammitglieder informiert sind und ihre Aufgaben (z. B. Eindämmung, Beseitigung, Wiederherstellung) erfüllen.

Untersuchung und Eindämmung: Nach der Erkennung eines Vorfalls arbeiten wir zunächst an der Eindämmung (z. B. Isolierung betroffener Systeme, Widerruf kompromittierter Anmeldedaten), um weiteren Schaden zu verhindern. Anschließend untersuchen wir Art und Umfang des Vorfalls – welche Systeme oder Daten betroffen sind und wie es dazu kam. Während des gesamten Prozesses führen wir detaillierte Aufzeichnungen über das Ereignis, inklusive Ablauf, Zeitpunkt und getroffener Maßnahmen. Diese Dokumentation ist sowohl für Lerneffekte als auch für die DSGVO-Compliance erforderlich.

Beseitigung und Wiederherstellung: Sobald der Vorfall verstanden ist, beseitigen wir die Bedrohung (z. B. Entfernen von Malware, Schließen von Sicherheitslücken). Danach stellen wir Systeme wieder her – gegebenenfalls durch Rückkehr zu einem „Last Known Good State“ oder mithilfe von Backups. Anschließend überwachen wir die Systeme engmaschig, um Anzeichen einer Persistenz auszuschließen.

Meldung & Rechtspflichten: Tritt eine Verletzung personenbezogener Daten auf, befolgen wir die DSGVO-Vorgaben zur Meldung von Datenschutzverletzungen. Wenn ein Vorfall voraussichtlich ein Risiko für die Rechte von Personen birgt (z. B. unbefugter Zugriff auf personenbezogene Daten), informieren wir die zuständige Aufsichtsbehörde unverzüglich und spätestens innerhalb von 72 Stunden nach Bekanntwerden des Vorfalls (Art. 33 DSGVO). Wir verfügen über Prozesse, um die hierfür notwendigen Informationen schnell zu sammeln (Art des Verstoßes, betroffene Daten, Zahl der Betroffenen, ergriffene Maßnahmen usw.). Falls ein hohes Risiko für die Privatsphäre der Betroffenen besteht, informieren wir auch die betroffenen Kunden/Personen direkt und ohne Verzögerung (gemäß Art. 34 DSGVO). Die Benachrichtigung umfasst, was geschehen ist, welche Daten betroffen sind und welche Maßnahmen wir ergreifen. Unser Ziel ist Transparenz und zeitnahe Kommunikation.

Nachbearbeitung: Nach der Behebung eines Vorfalls führen wir eine Post-Mortem-Analyse durch, um zu ermitteln, was schiefgelaufen ist und wie ähnliche Vorfälle künftig vermieden werden können. Unsere Sicherheitsmaßnahmen und unser Reaktionsplan werden anhand der gewonnenen Erkenntnisse aktualisiert. Beispielsweise implementieren wir zusätzliche Sicherheitskontrollen oder verbessern die Schulung unseres Teams, wenn Lücken sichtbar werden.

Unser Incident-Response-Plan wird regelmäßig überprüft und aktualisiert, sobald sich unser System verändert oder neue Bedrohungen auftauchen. Alle Teammitglieder sind mit dem Plan vertraut und in ihren Rollen geschult – auch in einem kleinen Team ist Vorbereitung entscheidend. Mit einem klar definierten Plan und der Einhaltung der gesetzlichen Meldepflichten können wir schnell und wirksam auf Sicherheitsvorfälle reagieren, Schäden minimieren und unseren Verpflichtungen gegenüber Nutzern und Behörden nachkommen.

Datenlebenszyklus & Aufbewahrung

Wir verwalten den Lebenszyklus personenbezogener Daten sorgfältig – von der Eingabe in unser System bis zur endgültigen Löschung. Unsere Richtlinien decken Import, Export, Aufbewahrung und Löschung ab und entsprechen den Grundsätzen des Datenschutzes:

Datenimport: Wenn Kunden Daten in unser System importieren (z. B. durch Hochladen von Datensätzen oder über eine API), werden diese sicher verarbeitet und unterliegen sämtlichen in diesem Dokument beschriebenen Sicherheitskontrollen (Verschlüsselung, Zugriffskontrolle usw.). Wir stellen sicher, dass alle Daten-Importkanäle (Datei-Uploads, Importskripte) abgesichert sind und dass Daten validiert und sicher verarbeitet werden, um die Einspeisung schädlicher Inhalte zu verhindern.

Datenexport & Portabilität: Wir unterstützen die Datenportabilität unserer Kunden. Auf Anfrage (oder über eingebaute Funktionen) können Nutzer ihre Daten in einem gängigen Format exportieren. Exporte werden auf sichere Weise erstellt – nur autorisierte Nutzer können die zu ihrem Konto gehörenden Daten exportieren, und die Bereitstellung erfolgt über sichere Kanäle (z. B. Download per HTTPS oder Versand über verschlüsselte E-Mail). So können Kunden ihre Daten jederzeit abrufen, im Einklang mit den Rechten auf Datenübertragbarkeit nach DSGVO. Bei Bedarf stellen wir Kunden auch relevante Metadaten oder Audit-Logs zur Verfügung, um Transparenz zu gewährleisten.

Datenaufbewahrung: Wir speichern personenbezogene Daten nur so lange, wie es für die Zwecke erforderlich ist, für die sie erhoben wurden, oder soweit es unsere vertraglichen bzw. gesetzlichen Pflichten verlangen. Aktive Kundendaten verbleiben während der Nutzung des Dienstes in unseren Produktionsdatenbanken. Wenn ein Kundenkonto inaktiv wird oder beendet wird, gilt ein Aufbewahrungsplan: In der Regel behalten wir die Daten für eine kurze Nachfrist (z. B. 30 Tage), falls der Kunde reaktiviert oder zur Wiederherstellung aus Backups, und löschen oder anonymisieren die Daten anschließend endgültig. Bestimmte Daten, die für die gesetzliche Aufbewahrung erforderlich sind (z. B. Abrechnungsunterlagen), werden entsprechend den rechtlichen Vorgaben länger archiviert, jedoch sicher gespeichert.

Recht auf Löschung („Right to be Forgotten“): Wir verfügen über einen klar definierten Löschprozess, um das Recht auf Vergessenwerden umzusetzen. Wenn ein Kunde (oder Endnutzer) die Löschung seiner personenbezogenen Daten beantragt oder ein Konto gelöscht wird, löschen wir die personenbezogenen Daten unverzüglich aus unseren Produktionssystemen (sofern keine gesetzlichen Aufbewahrungspflichten bestehen). Die Daten werden aus unseren Datenbanken und Dateispeichern entfernt. Zusätzlich stellen wir sicher, dass die Daten auch im Rahmen des nächsten Backup-Zyklus aus unseren Sicherungen gelöscht werden. Da wir Backups 7 Tage lang aufbewahren, können gelöschte Daten bis zu 7 Tage in Backups verbleiben, bevor diese ebenfalls gelöscht werden. Nutzer werden über diese Backup-Aufbewahrung im Falle eines Löschantrags informiert. Eine Wiederherstellung gelöschter personenbezogener Daten aus Backups erfolgt nicht, außer es ist absolut notwendig (z. B. für Disaster Recovery). Sämtliche Löschvorgänge werden zu Audit-Zwecken protokolliert.

Test- & Entwicklungsdaten: In unseren Entwicklungs- und Testumgebungen verwenden wir keine echten personenbezogenen Daten. Es ist unser Standard und Branchenpraxis, dass Testdaten anonymisiert oder synthetisch sein müssen. Wir generieren entweder Dummy-Daten oder anonymisieren Datensätze, wenn wir ein strukturell ähnliches Set zu Produktionsdaten benötigen. Dadurch stellen wir sicher, dass persönliche Informationen nicht versehentlich in Nicht-Produktivumgebungen offengelegt oder missbraucht werden. Sollte in seltenen Fällen Produktionsdaten zur Fehleranalyse erforderlich sein, würden wir die entsprechenden Genehmigungen einholen und Transformationsmethoden anwenden (z. B. Pseudonymisierung oder Minimierung der Daten). Grundsätzlich arbeiten Entwickler jedoch mit nicht-realen Daten in lokalen und Staging-Umgebungen.

Zusammenfassung: Wir verwalten Daten über ihren gesamten Lebenszyklus hinweg datenschutzgerecht – wir bewahren sie nur so lange auf, wie notwendig, ermöglichen Nutzern jederzeit Abruf oder Löschung und schützen sie in jeder Phase (einschließlich bei Tests oder Systemmigrationen). Verfahren zur Datenportabilität und -löschung sind etabliert, um die Rechte der Nutzer nach DSGVO zu gewährleisten.

Unterauftragsverarbeiter

Zur Bereitstellung unseres Dienstes greifen wir auf eine begrenzte Anzahl von Unterauftragsverarbeitern (externe Dienstleister) zurück, die personenbezogene Daten in unserem Auftrag verarbeiten können. Jeder Unterauftragsverarbeiter wird sorgfältig hinsichtlich seiner Sicherheits- und Datenschutzpraktiken geprüft, durch eine Vereinbarung zur Auftragsverarbeitung (AVV) vertraglich gebunden und muss unsere Standards für den Datenschutz erfüllen (gemäß Art. 28 DSGVO).

Aktuell setzen wir folgende Unterauftragsverarbeiter ein:

Contabo GmbH – Hosting & Infrastruktur
Contabo stellt die physische Server-Infrastruktur (Cloud-VMs und Speicher) in Deutschland bereit, auf denen unsere Anwendung und Datenbank betrieben werden.
Standort: Frankfurt & Nürnberg, Deutschland (Europäische Union)
Verarbeitete Daten: Sämtliche Kundendaten und Anwendungsdaten (Datenbanken, hochgeladene Dateien, Backups) werden auf den Servern von Contabo gespeichert. Contabo handelt ausschließlich auf unsere Weisung im Rahmen der Hosting-Plattform und hat keinen Zugriff auf die Daten, außer für zwingend notwendige Infrastrukturwartungen. Eine AVV mit Contabo regelt die nach DSGVO erforderlichen Schutzmaßnahmen.
Mollie B.V. – Zahlungsabwicklung
Mollie verarbeitet zahlungsrelevante Daten zur Abwicklung von Abonnements und Transaktionen.
Standort: Amsterdam, Niederlande (EU/EWR)
Verarbeitete Daten: Identifikations- und Kontaktdaten des Zahlenden/Kunden (z. B. Name, E-Mail, Rechnungsadresse), Transaktions-Metadaten (Bestellnummer, Betrag, Währung, Zeitstempel), Zahlungsdetails und Token/Identifikatoren (z. B. letzte vier Ziffern einer Karte oder maskierte IBAN; vollständige Kartendaten speichern wir nicht), Signale zur Betrugsprävention sowie Compliance-Informationen gemäß Finanzvorschriften. Mollie verarbeitet diese Daten, um Zahlungen in unserem Auftrag auszuführen und agiert, wo erforderlich (z. B. Geldwäscheprävention/Fraud Prevention), als eigenständiger Verantwortlicher nach eigenen gesetzlichen Pflichten. Eine AVV (basierend auf den Standardbedingungen von Mollie) regelt die Verarbeitung als unser Auftragsverarbeiter.

(Wir nutzen derzeit keine weiteren externen Unterauftragsverarbeiter für personenbezogene Daten. Dienste wie Nutzer-Analytics oder E-Mail-Versand werden entweder nicht eingesetzt oder intern abgewickelt. Sollten wir künftig neue Unterauftragsverarbeiter integrieren – z. B. einen E-Mail-Versanddienst oder ein Support-Ticketsystem, das personenbezogene Daten speichert –, aktualisieren wir unsere Dokumentation und stellen sicher, dass dieselben Sicherheitsstandards eingehalten werden.)

Wir führen eine stets aktuelle Liste aller Unterauftragsverarbeiter, einschließlich deren Zweck und Standort, auf unserer Website. Änderungen an dieser Liste (Hinzufügen oder Austausch von Unterauftragsverarbeitern) werden unseren Kunden transparent mitgeteilt, ggf. unter Einholung einer Zustimmung.

Alle Unterauftragsverarbeiter befinden sich im EU-/EWR-Raum oder in Rechtsordnungen mit einem anerkannten angemessenen Datenschutzniveau. Wir beauftragen keine Verarbeiter in Hochrisiko-Drittländern ohne geeignete Schutzmaßnahmen.

Datenübermittlungen (International)

Keine Drittland-Übermittlungen: Sämtliche personenbezogenen Daten werden innerhalb der Europäischen Union verarbeitet und gespeichert. Wir übertragen Kundendaten im Rahmen der Leistungserbringung nicht in Länder außerhalb der EU/des EWR. Unser primäres Hosting erfolgt in Deutschland, und auch die Datenverarbeitung durch unsere Unterauftragsverarbeiter findet innerhalb der EU statt. Somit erfolgen keine Datenexporte in Drittstaaten wie die USA oder andere Nicht-EU-Länder, und es sind keine Standardvertragsklauseln (SCCs) für unsere Datenflüsse erforderlich.

Sollte künftig im Einzelfall eine Datenübermittlung außerhalb der EU/des EWR erforderlich sein (z. B. auf ausdrücklichen Kundenwunsch zur Weitergabe von Daten an einen Drittanbieter im Ausland oder bei der späteren Einbindung eines Unterauftragsverarbeiters in einem Drittland), stellen wir die vollständige Einhaltung von Kapitel V der DSGVO sicher. Das bedeutet, dass wir Daten ausschließlich dann übermitteln würden, wenn ein angemessener Schutzmechanismus besteht – etwa ein Angemessenheitsbeschluss der EU-Kommission für das Zielland oder geeignete Garantien wie Standardvertragsklauseln (SCCs) in Kombination mit zusätzlichen Maßnahmen. Derzeit vermeiden wir derartige Übermittlungen vollständig, was die Compliance vereinfacht und Risiken reduziert.

Durch die ausschließliche Datenverarbeitung innerhalb der EU-Rechtsordnung bieten wir unseren Kunden die Sicherheit, dass ihre Daten den Schutzbestimmungen des EU-Datenschutzrechts unterliegen und die Komplexität internationaler Datenübermittlungen entfällt. Personenbezogene Daten unserer Nutzer verbleiben vom Zeitpunkt der Erhebung bis zur Löschung auf EU-Boden – geschützt nach EU-Standards.

Hinweis zur Compliance: Alle oben beschriebenen Maßnahmen gewährleisten insgesamt ein dem Risiko angemessenes Schutzniveau im Sinne von Art. 32 DSGVO. Wir überprüfen und aktualisieren diese technischen und organisatorischen Maßnahmen regelmäßig, um sich verändernden Bedrohungen und geschäftlichen Anforderungen gerecht zu werden. Unser Anspruch ist es, Kundendaten durch robuste Sicherheitspraktiken zu schützen und transparent darzulegen, wie wir dies umsetzen. Bei Fragen zu unseren Sicherheits- oder Datenschutzmaßnahmen wenden Sie sich bitte an unser Datenschutz- oder Sicherheitsteam.