<aside> <img src="/icons/thought-dialogue_green.svg" alt="/icons/thought-dialogue_green.svg" width="40px" /> Im folgenden Dokument erklären wir die Hintergründe und warum diese Maßnahme den Datenschutz sogar deutlich erhöht.

Wie in unserer AVV geregelt, spiegeln wir jeden Sonntag alle Produktiv-Datenbanken auf einen Test-Datenbank-Server, wo sie in der nächsten Woche wieder überschrieben werden.

</aside>

Maßname

• Jeden Sonntag werden Produktiv-Daten vom Produktiv-Datenbank-Server auf einen Test-Datenbank-Server gespiegelt.
• Diese Test-Datenbanken werden dann jedes Mal überschrieben, so dass die Daten maximal eine Woche aufgehoben werden.

Begründung

Pre-Release-Testing von Updates

• Jeder Kunde hat bei uns eine enorm individuelle Konfiguration. Dokumente, Nutzermasken, Workflows, Auswertungen und Schnittstellen basieren darauf.
• Updates der Software können diese Konfigurationen leicht beschädigen, was zu Einschränkungen beim Kunden bis hin zum Datenverlust führen kann.
• Darum ist es enorm wichtig Updates nicht nur allgemein ausgiebig zu testen, sondern auch zuvor gegen die jeweiligen Konfigurationen der Kunden zu testen.
• Diese Tests erfolgen automatisiert. Nur wenn alle Tests erfolgreich verlaufen, wird das Update veröffentlicht.
• Damit diese Test nicht in der Produktiv-Umgebung ausgeführt werden müssen, verwenden wir die gespiegelten Test-Datenbanken dafür. Damit können wir eine sehr hohe Zuverlässigkeit des Systems garantieren, obwohl es so individuell konfiguriert ist.

Positiv für den Datenschutz:

• Verringerung des Fehlerpotentials.
• Verhinderung von Nicht-Verfügbarkeits-Zeiträumen.
• Verhinderung, dass Updates die Arbeitsfähigkeit der Nutzer*innen beeinträchtigen.
• Verhinderung von Datenverlust.
• Unsere MA würden ohnehin mit den personenbezogenen Daten arbeiten müssen. Diese Maßnahme führt also einen weiteren Sicherheits-Layer ein.

Alternativen:

• Wir würden das Testing im Produktiv-System vornehmen müssen
• Wir würden Testing auf pseudonymisierten Daten durchführen müssen, wodurch nicht alle Fehlerquellen zuverlässig getestet werden können.

Bearbeiten von Support-Aufträgen

• Wir nutzen diese Testdatenbanken auch um Support-Aufträge vorzubereiten, bevor sie in die Live-Datenbank überführt werden.
• Beispielsweise das Anlegen und Bearbeiten von Auswertungen, Dokumenten, Schnittstellen, Workflows und Nutzer-Masken bereiten wir zunächst in der Testumgebung vor.
• Würden wir dies im Produktiv-System vornehmen, könnte es zu Beeinträchtigungen der Nutzer*innen kommen.
• Zum Bearbeiten dieser Aufträge sind oft Klardaten erforderlich, um bspw. das Layout von Dokumenten anzupassen oder Schnittstellen testen (Import & Export) testen zu können