Art. 32 DSGVO · Anlage zum AVV
Technische und organisatorische Maßnahmen (KIES-App)
KIES – Stand: 08.11.2026 · Dokumentierter Entwicklungs- und Betriebsstand
Übersicht der technischen und organisatorischen Maßnahmen für die Verarbeitung personenbezogener Daten in der KIES-Anwendung. Die Angaben unterscheiden nachgewiesene Funktionen von noch nicht verifizierten Maßnahmen des geplanten Produktivbetriebs.
1. Geltungsbereich
Diese Übersicht betrifft die KIES-Anwendung unter app.kies-online.cloud und die dafür vorgesehene Auftragsverarbeitung durch BKData GmbH. Sie beschreibt Maßnahmen im Sinne des Art. 32 DSGVO und kann als Grundlage einer AVV-Anlage verwendet werden. Die Marketing-Website auf STRATO ist hiervon getrennt und wird in der Website-Datenschutzerklärung beschrieben. Der aktuelle Entwicklungsbetrieb auf Microsoft Azure ist nicht mit der gesondert vorgesehenen Produktivumgebung gleichzusetzen. Aussagen zu Microsofts Infrastruktur gelten nur im Umfang der tatsächlich gebuchten Dienste und der einschlägigen Anbieterunterlagen.
2. Vertraulichkeit
| Bereich | Maßnahme | Stand |
|---|---|---|
| Zutrittskontrolle (Rechenzentrum) | Die physische Absicherung der für KIES genutzten Microsoft-Azure-Rechenzentren liegt im Verantwortungsbereich von Microsoft. Nachweise ergeben sich aus den für den gebuchten Dienst einschlägigen Microsoft-Unterlagen. | Anbietermaßnahme; dienstbezogene Nachweise erforderlich |
| Zutrittskontrolle (Büro BKData) | Physischer Zutritt zu BKData-Arbeitsplätzen und gegebenenfalls lokalen Administrationssystemen ist organisatorisch zu regeln. Konkrete Schließ- und Besucherregelungen sind nicht Bestandteil dieses öffentlich belegten Stands. | Betriebliche Ausgestaltung nicht verifiziert |
| Zugangskontrolle | Die Anwendung verwendet nach dokumentiertem Entwicklungsstand E-Mail-Adresse und Passwort mit ASP.NET Core Identity; TOTP-MFA und Wiederherstellungscodes sind vorgesehen beziehungsweise implementiert. Die MFA-Frischeprüfung für sensible Aktionen ist auf 60 Minuten mit erneuter Codebestätigung festgelegt. Die Wirksamkeit für alle produktiven Zugriffspfade muss bei Betriebsaufnahme geprüft werden. | Entwicklungsstand dokumentiert; PROD-Prüfung ausstehend |
| Zugangskontrolle (Betriebspersonal) | Privilegierte Zugriffe auf die Managementkonsole sind rollenbasiert (PlatformAdmin) und an Mehrfaktor-Authentifizierung gebunden. Die vollständige technische Absicherung sämtlicher Administrations- und Azure-Zugänge bedarf einer gesonderten produktiven Rechteprüfung. | Anwendungsfunktion dokumentiert; Gesamtprüfung ausstehend |
| Zugriffskontrolle | Die Anwendung verfügt über rollenbasierte Berechtigungen für Mandantenbenutzer und Betriebsadministration. Sperren, Einladungen, Rechtewechsel und Sitzungsbeendigung sind Teil des Zugriffskonzepts; konkrete Zeitgarantien für die Beendigung bestehender Sitzungen werden ohne Abnahmetest nicht zugesichert. | Implementierungsstand dokumentiert; Wirksamkeit produktiv zu prüfen |
| Trennung (Mandantentrennung) | Mandantendaten werden in der Anwendung logisch über Mandantenbezüge und anwendungsseitige Zugriffsprüfungen getrennt. Automatisierte Tests und Freigabeprüfungen prüfen diese Isolation. Eine eigene physische Datenbank je Mandant wird nicht zugesichert. | Anwendungsmodell dokumentiert; regelmäßige Tests erforderlich |
| Trennung von Test und Produktion | Eine getrennte Azure-PROD-Umgebung ist für den Regelbetrieb vorgesehen. Zum Dokumentstand ist die bestehende DEV-Umgebung nicht als abschließend abgenommene Produktivumgebung anzusehen. Produktive Daten dürfen erst nach Umsetzung der Trennung und Freigabe verarbeitet werden. | Produktivtrennung nicht abgenommen |
| Verschlüsselung | Die Webanwendung nutzt HTTPS für die Übertragung. Azure-Dienste bieten Verschlüsselungsfunktionen für gespeicherte Daten; ihre konkrete Aktivierung, Schlüsselverwaltung und Konfiguration sind je tatsächlich eingesetztem Produktivdienst nachzuweisen. | Transport im DEV zu prüfen; Speicherung PROD nicht verifiziert |
| Geheimnisverwaltung | Zugangsdaten, API-Schlüssel und Data-Protection-Schlüssel sind gegen unbefugten Zugriff zu schützen. Die produktive Strategie für Key Vault, Schlüsselrotation, Berechtigungen und Wiederherstellung ist noch gesondert zu verifizieren; ein vollständig umgesetztes Rotationsverfahren wird nicht behauptet. | Produktive Umsetzung und Rotation offen |
3. Integrität
| Bereich | Maßnahme | Stand |
|---|---|---|
| Weitergabekontrolle | Datenübertragungen zwischen Browser und KIES-Anwendung erfolgen über HTTPS. Datenexporte und Bereitstellung von Dokumenten müssen auf Berechtigungen sowie erforderliche sichere Übertragungswege geprüft werden. Ein vollständig automatisiertes Exit-Paket wird nicht als bereits verfügbar zugesichert. | HTTPS im Entwicklungsbetrieb; Exportverfahren vor PROD verifizieren |
| Eingabekontrolle | Die Anwendung enthält Protokollierungsfunktionen für ausgewählte administrative und fachliche Änderungen. Umfang, Unveränderbarkeit, Einsichtsbefugnisse und Aufbewahrung der Protokolle sind im Regelbetrieb anhand der tatsächlichen Implementierung festzulegen. | Teilfunktionen dokumentiert; Umfang zu verifizieren |
| Änderungsprotokoll Fachdaten | Änderungen an Evidenzen, Dokumenten und Freigaben sollen nachvollziehbar sein. Konkrete Protokollinhalte, Versionierung und Löschfristen richten sich nach dem implementierten Datenmodell und müssen durch Tests und Dokumentation belegt werden. | Umfang noch nicht vollständig verifiziert |
4. Verfügbarkeit und Belastbarkeit
| Bereich | Maßnahme | Stand |
|---|---|---|
| Datensicherung | Für die geplante Azure-SQL-Produktivdatenbank sind die tatsächlich verfügbaren Sicherungs- und Point-in-Time-Restore-Funktionen entsprechend der gebuchten Dienststufe zu konfigurieren. Verbindliche RPO- und RTO-Werte werden erst nach Festlegung und Wiederherstellungstests benannt. | PROD-Konfiguration und Leistungswerte nicht bestätigt |
| Aufbewahrung der Sicherungen | Die Aufbewahrungsfristen für PITR und gegebenenfalls LTR sind für die produktive Datenbank gemäß Betriebs- und Löschkonzept festzulegen und in Azure nachzuweisen. | PROD-Aufbewahrung nicht festgelegt |
| Wiederherstellungstest | Nach Einrichtung der Produktivumgebung sind Wiederherstellungen in eine geeignete Testumgebung mit Datum, Ergebnis, Prüfer und ermittelter Dauer nachvollziehbar zu dokumentieren. | Produktiver Restore-Test noch nicht nachgewiesen |
| Überwachung | Application Insights ist nach dokumentiertem Entwicklungsstand für die Anwendung im Einsatz. Umfang, Datenminimierung, Zugriffsrechte, Alarmierung und Aufbewahrung sind für den Produktivbetrieb gesondert zu prüfen und festzulegen. | DEV-Monitoring dokumentiert; PROD-Einstellungen offen |
| Redundanz | Die verfügbare Redundanz richtet sich nach den in der Produktivumgebung tatsächlich gebuchten Azure-Dienststufen und ihrer Konfiguration. Eine bestimmte Hochverfügbarkeit oder Wiederanlaufzeit ist ohne Abnahme nicht zugesichert. | PROD-Ausgestaltung offen |
5. Verfahren zur regelmäßigen Überprüfung
| Bereich | Maßnahme | Stand |
|---|---|---|
| Qualitätssicherung | Für KIES werden automatisierte Build- und Anwendungstests sowie manuelle Freigabeprüfungen eingesetzt. Ein erfolgreicher Testlauf ersetzt keine Sicherheits-, Mandantentrennungs- oder Wiederherstellungsprüfung der Produktivumgebung. | Entwicklungsprozess dokumentiert |
| Änderungsfreigabe | Änderungen an geschützten Git-Zweigen, produktiven Diensten, Azure-Ressourcen und Datenbanken erfolgen nach dem vorgesehenen Freigabe- und Releaseprozess. | Freigabeprozess dokumentiert |
| Datenschutzvorfälle | Sicherheits- und Datenschutzvorfälle müssen bewertet, dokumentiert und entsprechend den vertraglichen Meldewegen unverzüglich an den Verantwortlichen weitergegeben werden, damit dieser seine gesetzlichen Fristen einhalten kann. Konkrete Alarmierungs-, Eskalations- und Vertretungsabläufe sind betriebsseitig nachzuweisen. | Betrieblicher Prozess noch zu verifizieren |
| Verpflichtung der Beschäftigten | Personen mit Zugriff auf personenbezogene Daten müssen auf Vertraulichkeit verpflichtet und angemessen unterwiesen werden. Die betreffenden Nachweise sind in der BKData-Organisation zu führen. | Organisationsnachweise separat erforderlich |
| Auftragskontrolle | Unterauftragsverarbeiter sind entsprechend der tatsächlich abgeschlossenen AVV und der jeweils aktuellen, vertraglich genehmigten Unterauftragsverarbeiterliste einzusetzen. Microsoft Azure ist für den Anwendungsbetrieb vorgesehen; STRATO betrifft das separate Website-Hosting. | Verträge und Liste für PROD abgleichen |
| E-Mail-Versand der Anwendung | Für Einladungs-, Vertrags- und Systemnachrichten sind nur die tatsächlich eingerichteten und vertraglich geprüften Maildienste anzugeben. Die Nutzung von Azure Communication Services ist für den Produktivbetrieb nicht belegt und wird hier nicht als eingerichtet behauptet. | Provider und Versandweg vor PROD bestätigen |
6. Nachweisführung und Fortschreibung
Diese öffentliche Übersicht unterscheidet bereits dokumentierte Anwendungsfunktionen von Maßnahmen, deren Ausgestaltung in der geplanten Produktivumgebung noch nicht nachgewiesen ist. Für die Verwendung als verbindliche AVV-Anlage sind insbesondere produktive Tenant-Isolation und Rechteprüfung, tatsächliche Azure-Konfiguration, Zugriffsschutz und Schlüsselverwaltung, Sicherungen und Wiederherstellung, Monitoring und Aufbewahrung, Vorfallmanagement sowie Unterauftragsverarbeiter vertraglich und technisch nachzuweisen. Die Übersicht ist nach Betriebsfreigabe und bei wesentlichen Änderungen zu aktualisieren.