Technisch-organisatorische Maßnahmen (TOM)

gemäß Art. 32 DSGVO — Anlage 2 zum Auftragsverarbeitungsvertrag

roleALPHA GmbH, Aschergasse 34, 1130 Wien

Jeweils geltende Fassung. Dieses Dokument wird unter
https://rolealpha.com/legal/sicherheitsmassnahmen veröffentlicht und bei Weiterentwicklung des
Produkts fortgeschrieben; das Schutzniveau wird dabei nicht unterschritten (Abschnitt 4 des AVV).
Eine Fortschreibung ist keine Vertragsänderung.

0. Geltungsbereich und Abgrenzung

Dieses Dokument beschreibt die von der roleALPHA GmbH umgesetzten Maßnahmen zur Sicherheit der Verarbeitung nach Art. 32 DSGVO. Es ist Anlage 2 zum Auftragsverarbeitungsvertrag.

roleALPHA betreibt in allen Modellen den Core; wo die Data Nodes laufen, entscheidet der Kunde. Die Maßnahmen der Anwendungssoftware (Abschnitte 1 bis 7) verantwortet in jedem Modell roleALPHA, ebenso Betrieb und Absicherung des Core. Betrieb, physische Sicherheit, Netzwerk, Datenträgerverschlüsselung und Sicherungskopien der Data Nodes liegen in M1 bei roleALPHA, in M2 beim Kunden und in M3 bei dessen Dritt-Hoster. In M2 und M3 stellt roleALPHA die Software mit den hier beschriebenen Schutzfunktionen bereit; die Absicherung ihrer Betriebsumgebung obliegt dem Kunden. Abschnitt 8 fasst die Aufteilung tabellarisch zusammen.

1. Zugang und Berechtigungen

Zutritt. Der Betrieb erfolgt im Rechenzentrum eines professionellen Anbieters mit den branchenüblichen physischen Schutzmaßnahmen (Zutrittskontrolle, Videoüberwachung, unterbrechungsfreie Stromversorgung, Brandschutz, Klimatisierung): netcup GmbH, Emmy-Noether-Straße 10, 76131 Karlsruhe, Deutschland; Rechenzentrumsstandort Wien, Österreich. Zertifizierungen des Hosters: ⟨TODO: z.B. ISO/IEC 27001 — nachtragen und Nachweis beilegen⟩. Eigene Serverräume betreibt roleALPHA nicht. Der Zugang zu Betriebsräumen ist auf berechtigte Personen beschränkt; mobile Geräte sind verschlüsselt und mit Bildschirmsperre versehen.

Authentifizierung. Nutzer melden sich per Einmalcode an ihre Anmeldeadresse, mit einem Passkey oder über den Identitätsanbieter des Kunden an. Neue Zugänge erhalten kein Passwort; es werden weder Benutzernamen noch Startpasswörter erzeugt, angezeigt oder versandt. Eine Anmeldung mit Passwort nimmt der Server ausschließlich von Plattform-Administratoren der roleALPHA GmbH für die Plattformverwaltung an; für Konten der Kunden ist dieser Weg seit Oktober 2026 geschlossen — serverseitig durchgesetzt, unabhängig von der Oberfläche. Passwörter werden ausschließlich als bcrypt-Hash mit Salt gespeichert, nie im Klartext und ohne Wiederherstellbarkeit. Gehört ein Konto mehreren Mandanten, kann ein Mandanten-Administrator weder dessen Anmeldeadresse noch dessen Anmeldewege ändern; das Deaktivieren wirkt nur in seinem Mandanten, und eine gesperrte Mitgliedschaft lässt sich auch durch Erneuern einer laufenden Sitzung nicht weiterverwenden. Jede Sitzung vermerkt ihren Anmeldeweg; ein Wechsel in einen anderen Mandanten — auch über die zentrale Anmeldedomain — gelingt ohne erneute Anmeldung nur, wenn dieser Mandant den Weg zulässt, und eine Anmeldung über den Identitätsanbieter eines Mandanten gilt ausschließlich für diesen. Optional kommt ein zeitbasiertes Einmalkennwort (TOTP) hinzu, dessen Geheimnis verschlüsselt abgelegt wird. Phishing-resistent sind Passkeys nach FIDO2/WebAuthn: der private Schlüssel verlässt das Endgerät nicht, gespeichert wird nur der öffentliche; der Zugangsschlüssel ist kryptografisch an die Herkunftsadresse gebunden und wird auf nachgebauten Seiten vom Endgerät gar nicht erst angeboten. Verlangt wird eine Nutzerverifikation am Gerät (userVerification: required); ein Signaturzähler erkennt kopierte Schlüssel, biometrische Merkmale prüft ausschließlich das Endgerät. Alternativ wird der Identitätsanbieter des Kunden über OpenID Connect angebunden; die Authentifizierung erfolgt dann beim Kunden.

Sitzungen und Token. Zugriffstoken sind zustandslose, signierte JWT (RS256) mit begrenzter Gültigkeit und werden über ein gesondertes Verfahren erneuert. Sie werden mit dem privaten Schlüssel des jeweiligen Mandanten signiert und nur über den zugehörigen öffentlichen Schlüsselsatz (JWKS) geprüft — ein Token eines anderen Mandanten wird abgewiesen. Externe Anwendungen werden ausschließlich über OAuth 2.1 mit PKCE angebunden; der erteilte Zugang ist an eine Person, einen Mandanten und eine Zieladresse gebunden. Die dabei ausgegebenen Token tragen ein eigenes Verwendungsmerkmal und werden auf den Anmeldewegen der Anwendung abgewiesen; sie können eine Browser-Sitzung nicht ersetzen. Erneuerungsschlüssel werden rotiert, die Wiedervorlage eines verbrauchten Schlüssels gilt als Diebstahl und widerruft die gesamte Kette; gespeichert werden ausschließlich Hashwerte. Der Widerruf wirkt sofort, auch auf laufende Verbindungen.

Missbrauchsabwehr. Anmeldeversuche sind auf 10 je 15 Minuten und IP-Adresse begrenzt, Anfragen allgemein auf 100 je 60 Sekunden, KI-Endpunkte auf 60 je 60 Sekunden; ab 60 Anfragen je Minute greift zusätzlich eine progressive Verzögerung.

Berechtigungen. Die Zugriffskontrolle ist rollenbasiert im Schema Modul:Aktion und wird zentral an einer Prüfstelle im Code ausgewertet; Rollen sind je Mandant definierbar. Jedes Fachobjekt trägt zusätzlich eine Sichtbarkeitseinstufung, deren Filterung serverseitig und autoritativ über den Core erfolgt, nicht im Client. Plattformadministration, Mandantenadministration und fachliche Rollen sind getrennt; eine Sonderrolle für die Sichtbarkeitsprüfung erhält keinen Zugang zu Administrationsfunktionen. Dienste erhalten nur die für ihre Aufgabe nötigen Zugriffe, Dienst-zu-Dienst-Aufrufe werden über ein gesondertes internes Geheimnis autorisiert. Änderungen können je nach Konfiguration des Kunden erst nach Freigabe wirksam werden. Die Plattformverwaltung ist eine getrennte Anwendung mit eigenem Anmeldevorgang und eigenem Token; Zugänge zu Betriebssystemen laufen ausschließlich über Schlüsselverfahren, deren Geheimnisse verschlüsselt und nur schreibend verwaltet werden. Bei roleALPHA selbst wird die Berechtigungsvergabe dokumentiert, regelmäßig überprüft und beim Ausscheiden sofort entzogen; erhöhte Rechte werden nach dem Vier-Augen-Prinzip vergeben.

2. Mandantentrennung und Zugriffsschutz

Die Mandantentrennung ist ein tragendes Konstruktionsprinzip. Jeder Datensatz ist einem Mandanten zugeordnet, und alle Abfragen sind auf den Mandanten des angemeldeten Nutzers eingeschränkt. Hinzu kommt die Datenhoheit je Datenknoten: jeder Data Node verwaltet ausschließlich seine eigenen Tabellen, der Core fragt Fachdaten nur über dessen Schnittstelle ab, und umgekehrt greifen Data Nodes nicht auf Core-Tabellen zu. Beides ist durch automatisierte Architekturprüfungen im Entwicklungsprozess abgesichert. Die Trennung wirkt auch kryptografisch, weil Zugriffstoken mandantengebunden signiert sind (Abschnitt 1). Getrennte Datenbanken sind je Bereitstellung möglich und werden bei Kundendomänen sowie in M2 und M3 eingesetzt. Test- und Produktivumgebungen sind getrennt; in Testumgebungen werden keine Produktivdaten von Kunden verwendet. Auf dem gemeinsamen Standort rA Cloud (AVV Anlage 1.2) laufen Data Nodes mehrerer Kunden nebeneinander. Dort ist ein Data Node nicht an einen einzelnen Realm gebunden: er bestimmt den Realm je Anfrage aus der Schlüsselkennung des Zugriffstokens und prüft die Signatur gegen den öffentlichen Schlüssel dieses Realms — wie die zusätzlichen Core-Knoten (Cells). Die Trennung der Mandanten bleibt dieselbe wie auf jedem anderen Standort: jede Abfrage ist auf den Mandanten des Tokens eingeschränkt, und ein Token ohne gültige Signatur wird abgelehnt.

Pseudonymisierung. Bei den Interaktionssignalen werden Akteure ausschließlich als SHA-256(Mandantenkennung + ":" + externe Benutzerkennung) gespeichert — kein Klarname, keine Einzelereignisse, nur aggregierte Gewichte je Akteurpaar und Zeitfenster, Höchstaufbewahrung 90 Tage. Eine Zuordnung zu einer Person erfolgt nur bei ausdrücklicher Einrichtung durch den Kunden. In der Nutzungsstatistik verlassen Mandanten-, Realm- und Personenkennungen den Browser ausschließlich als gesalzener SHA-256-Hashwert; die Statistik ist cookielos und respektiert „Do Not Track".

Datenschutzfreundliche Voreinstellungen (Art. 25 DSGVO). KI-Funktionen sind ohne Konfiguration nicht nutzbar, die Datenfreigabe ist fehlerabweisend voreingestellt. Interaktionssignale sind standardmäßig aus und technisch auf pseudonyme, aggregierte Metadaten mit erzwungener Höchstaufbewahrung begrenzt. Der Core hält keine Fachinhalte, sondern nur Metadaten. Die Anwendung setzt keine Cookies und bindet kein Drittanbieter-Tracking ein. Der Kunde kann die Aufbewahrungsfristen für Protokolle, Entwürfe, Chatverläufe und Anhänge selbst verkürzen. Die Eignungsprüfung eines Vorgangsprotokolls wertet die übermittelte Stichprobe ausschließlich im Arbeitsspeicher aus; vier personenbezogene Vorgangsarten (Bewerbung, Gesundheit, Disziplinar, Hinweisgeber und Beschwerde) sind als Quelle technisch gesperrt und nicht abwählbar. Export und Löschung sind Produktfunktionen, keine Sonderleistungen.

3. Verschlüsselung

Externe Verbindungen laufen ausschließlich über TLS 1.2 und 1.3 mit starken Cipher-Suites; unverschlüsselte Aufrufe werden umgeleitet, Zertifikate automatisiert ausgestellt und erneuert. Dienst-zu-Dienst-Kommunikation findet innerhalb geschützter Netzsegmente statt; extern erreichbare Endpunkte sind nur über TLS erreichbar.

Geheimnisse in der Datenbank werden mit AES-256-GCM in Umschlagverschlüsselung abgelegt: API-Zugangsschlüssel für KI-Anbieter, Zugangsdaten von Konnektoren und Signalquellen, TOTP-Geheimnisse, SSH-Zugangsdaten von Bereitstellungszielen sowie die Zugangsdaten des E-Mail-Versands — der Plattform und der eigenen Versandwege einzelner Mandanten. Der Hauptschlüssel wird über eine gesonderte Umgebungsvariable bereitgestellt und ist nicht Teil der Datenbank; für die Rotation der Verschlüsselungsschlüssel besteht ein dokumentiertes Verfahren. Je Mandant existiert ein RSA-Schlüsselpaar; private Schlüssel liegen verschlüsselt, öffentliche werden über einen JWKS-Endpunkt bereitgestellt. Arbeitsgeräte sind vollständig festplattenverschlüsselt. Verschlüsselung der Datenträger auf Ebene des Hosters: ⟨TODO: durch den Hoster bestätigen⟩.

4. Verfügbarkeit und Wiederherstellung

Die Datenbanken werden regelmäßig gesichert; Turnus: ⟨TODO: Sicherungsturnus im Produktivbetrieb⟩. Sicherungskopien werden spätestens 90 Tage nach Löschung der betreffenden Daten aus den aktiven Systemen gelöscht oder überschrieben (Abschnitt 7 des AVV). Zusätzlich besteht ein anwendungsseitiges Sicherungs- und Wiederherstellungsverfahren je Mandant über alle Data Nodes hinweg, mit Prüfsummenkontrolle der wiederhergestellten Datenmengen. Die dabei erzeugte Datei wird verschlüsselt abgelegt (AES-256-GCM mit Integritätssiegel); der Schlüssel wird je Vorgang neu erzeugt und ausschließlich im Arbeitsspeicher gehalten — er wird nicht abgeleitet, nicht gespeichert und nicht ausgegeben. Eine nach einem Absturz verbliebene Datei ist dadurch nicht mehr lesbar und wird beim nächsten Start entfernt; nach dem Herunterladen wird die Datei sofort gelöscht. Wiederherstellungen werden im Rahmen der automatisierten Prüfläufe regelmäßig tatsächlich durchgeführt, nicht nur geplant.

Die Dienste werden mit Zustandsprüfungen überwacht und alarmiert; Betriebskennzahlen werden gesammelt. Ein zusätzlicher Überwachungsdienst auf Betriebssystemebene außerhalb der Container-Fehlerdomäne erkennt hängende oder ausgefallene Dienste und startet sie neu; diese Maßnahme setzt voraus, dass die Betriebssystemebene des Data Node mit ausgeliefert wird. Wird der Data Node in eine vom Kunden betriebene Container-Orchestrierung ausgeliefert, entfällt sie und wird durch deren Neustart- und Zustandsmechanismen ersetzt, die der Kunde verantwortet. Gegen Überlast wirken Ratenbegrenzung, progressive Verzögerung, Begrenzung der Anfragegrößen (50 MB am Reverse-Proxy, 25 MB in der Anwendung) und Zeitüberschreitungen bei ausgehenden Aufrufen. Alle Dienste setzen Schutz-Header (unter anderem gegen Clickjacking, MIME-Sniffing und Referrer-Weitergabe). Infrastrukturdienste wie Datenbank und Nachrichtenbus sind nicht von außen erreichbar; öffentlich exponiert ist nur der Reverse-Proxy. Für Störungen besteht ein definierter Ablauf aus Meldung, Priorisierung, Behebung und Rückkanal an betroffene Kunden, dazu dokumentierte Wiederanlaufabläufe, die durch die automatisierten Wiederherstellungsprüfungen regelmäßig erprobt werden.

5. Integrität und Protokollierung

Eingabekontrolle. Erstellung, Änderung und Löschung von Objekten werden mit handelnder Person, Zeitstempel, Objekt, Aktion und — bei Änderungen — den geänderten Feldwerten protokolliert; berechtigte Nutzer des Kunden können die Protokolle einsehen. Die Aufbewahrung beträgt voreingestellt 365 Tage und ist je Mandant konfigurierbar; durchgesetzt wird sie über automatisierte Löschläufe, deren Ausführung selbst protokolliert wird. Betriebsprotokolle werden strukturiert mit Schweregraden zentral gesammelt und 30 Tage aufbewahrt. Programmfehler sammelt eine selbst betriebene Fehler-Erfassung (GlitchTip) — quelloffen, in einem eigenen Netz mit eigener Datenbank und eigener Datenbankrolle, ohne Beteiligung eines Dienstleisters; Aufbewahrung 30 Tage, plattformweit fest.

Änderungen durch roleALPHA im Auftrag. Ändern befugte Beschäftigte von roleALPHA auf Weisung des Kunden Konfigurationen in dessen Mandanten (Data Nodes, KI-Einstellungen, Firmen- und Rechnungsdaten), verlangt die Plattform an einer zentralen Prüfstelle einen Grund (5 bis 500 Zeichen) und lehnt die Änderung ohne ihn ab. Grund, handelnde Person und Vorgang stehen im Prüfpfad des Mandanten und sind für den Kunden sichtbar. Ein Mandanten-Administrator des Kunden kann sich nicht als roleALPHA ausgeben: der Vermerk wird nur für Konten mit Plattform-Administratorrolle gesetzt. Ein automatisierter Test stellt sicher, dass jeder betroffene Schreibweg an dieser Prüfstelle hängt und den Grund protokolliert.

Weitergabekontrolle. Die Freigabe für KI-Dienste ist fehlerabweisend voreingestellt: ohne ausdrückliche, bereichsweise Freigabe des Kunden erhält die KI keinen Zugriff auf Entitäts- und Vektordaten, und eine leere Freigabeliste bedeutet kein Zugriff. Die Prüfung erfolgt zentral an einer Stelle im Code und ist durch automatisierte Tests abgesichert. Anbieter und Modell werden je Mandant konfiguriert; der Kunde kann einen eigenen Anbieterzugang hinterlegen, sodass keine Vertragsbeziehung von roleALPHA zum Anbieter besteht. Dienst-zu-Dienst-Aufrufe werden über ein internes, nur serverseitig bekanntes Geheimnis autorisiert; die Herkunftsprüfung (CORS) wird dynamisch aus der Konfiguration abgeleitet und nicht pauschal geöffnet. Zugangsdaten externer Datenquellen werden verschlüsselt gespeichert, Verbindungen nur mit den vom Kunden bereitgestellten Zugängen aufgebaut. Exporte sind nur für berechtigte Nutzer möglich und werden protokolliert.

Verlinkte Dokumente ruft roleALPHA nicht selbst ab — kein serverseitiger Zwischenabruf, keine Zwischenspeicherung, kein externer Anzeigedienst; verlinkt werden ausschließlich die Protokolle http und https, andere Adressarten werden als Text dargestellt. Die Vorschau läuft in einem abgeschotteten Rahmen (sandbox) und nur mit den Rechten, die das Quellsystem dem Nutzer gewährt. Bildschirmaufnahmen und Seitenexporte der Feedbackfunktion werden dem Nutzer vor dem Absenden zur Prüfung und Bearbeitung angezeigt; das Zielverzeichnis ist nicht öffentlich zugänglich. Fehlermeldungen des Browsers laufen nicht unmittelbar zur Fehler-Erfassung, sondern über den eigenen Server; dort schwärzt eine Prüfstelle vor dem Weiterleiten Formularinhalte, den Text angeklickter Elemente, Abfrageteile von Adressen, Anfrageinhalte, Cookies und Kopfzeilen und maskiert Werte mit Geheimnismuster. Eine nicht zerlegbare Meldung wird abgewiesen, nicht durchgereicht; Sitzungsaufzeichnung und Laufzeitmessung einzelner Nutzer sind nicht aktiviert. Eigene Datenträger betreibt roleALPHA im Produktivbetrieb nicht; ihre Entsorgung obliegt dem Hoster nach dessen zertifizierten Verfahren.

6. Löschung

Löschvorgänge sind protokolliert; ein Löschen ohne Spur im Prüfpfad ist nicht vorgesehen. Die Aufbewahrungsfristen für Protokolle, Entwürfe, Chatverläufe und Anhänge sind je Mandant einstellbar und können vom Kunden verkürzt werden; durchgesetzt werden sie durch automatisierte Löschläufe. Nach Vertragsende gelten die Fristen aus Abschnitt 7 des AVV: Löschung aus den aktiven Systemen binnen 30 Tagen, Sicherungskopien spätestens nach 90 Tagen, dazwischen kein laufender Zugriff auf die Sicherungen. Bereits ausgeführte Löschungen werden nach einer Wiederherstellung erneut angewendet, bevor die Daten produktiv genutzt werden. Ein automatisierter Test stellt sicher, dass jede neue mandantenbezogene Tabelle in Sicherung, Wiederherstellung und Löschung aufgenommen ist; bewusst aufbewahrte Tabellen müssen begründet ausgewiesen werden. In M2 und M3 verantwortet der Kunde die Löschung auf seiner Infrastruktur; roleALPHA unterstützt ihn dabei.

7. Organisation und Wirksamkeitsprüfung

Verpflichtung und Zuständigkeit. Alle Beschäftigten und Auftragnehmer sind schriftlich zur Vertraulichkeit und zur Einhaltung des Datenschutzes verpflichtet; die Verpflichtung gilt über das Ende der Tätigkeit hinaus. Ein Datenschutzbeauftragter ist bestellt (Kontakt siehe Datenschutzerklärung, Abschnitt 1). Beschäftigte werden regelmäßig zu Datenschutz und Informationssicherheit unterwiesen. Das Verzeichnis der Verarbeitungstätigkeiten wird nach Art. 30 Abs. 1 und Abs. 2 DSGVO geführt. Entwicklung, Betrieb und Plattformadministration sind rollenmäßig getrennt. Fernwartung erfolgt zweckgebunden, protokolliert und mit verschlüsselt verwalteten Zugängen, in M2 und M3 nur mit einem vom Kunden bereitgestellten Zugang.

Verfahren bei Datenschutzverletzungen. Dokumentierter Ablauf mit Bewertung, Meldung an den Kunden binnen 48 Stunden, Meldung an die Aufsichtsbehörde binnen 72 Stunden (soweit roleALPHA Verantwortlicher ist), Dokumentation und Nachbereitung.

Auftragskontrolle. Unterauftragsverarbeiter werden nur nach Prüfung ihrer Eignung und Schutzmaßnahmen ausgewählt; mit jedem wird ein Vertrag nach Art. 28 DSGVO mit im Wesentlichen gleichen Pflichten geschlossen. Bei Drittlandbezug wird ein zulässiger Übermittlungsmechanismus sichergestellt (Angemessenheitsbeschluss oder Standardvertragsklauseln) samt Beurteilung der Umstände der Übermittlung. Die Liste der Unterauftragsverarbeiter wird geführt und versioniert; Änderungen werden den Kunden mit einer Vorlaufzeit von 14 Tagen mitgeteilt, innerhalb derer sie widersprechen können. Es bestehen anlassbezogene Nachprüfung und ein Kündigungsrecht bei Verstößen.

Wirksamkeitsprüfung. Jede Änderung an der Software durchläuft ein mehrstufiges, verpflichtendes Prüfverfahren: vor jeder Übernahme in die Versionsverwaltung statische Typprüfung sowie Modul- und Komponententests, vor jeder Auslieferung in die Produktion ein vollständiger Prüflauf einschließlich Integrations- und durchgängiger Oberflächentests gegen eine echte Datenbank und einen echten Nachrichtenbus, fortlaufend in der Bauumgebung Linting, Tests und Bauprüfung aller Pakete. Architekturprüfungen erzwingen automatisiert die Datenhoheit der Datenknoten, die Vollständigkeit der Lösch- und Wiederherstellungspfade und die Verdrahtung von Sicherheitsschaltern — ein Verstoß bricht den Prüflauf ab. Abhängigkeiten werden auf bekannte Schwachstellen geprüft, mit definiertem Behebungsprozess; Änderungen an sicherheitsrelevanten Pfaden durchlaufen eine sicherheitsbezogene Codeprüfung. Jede Änderung durchläuft eine Codeprüfung, und ausgeliefert wird ausschließlich aus der Bauumgebung, nicht manuell. Dieser Maßnahmenkatalog wird mindestens jährlich sowie anlassbezogen bei wesentlichen Änderungen überprüft.

8. Verantwortlichkeitsmatrix je Betriebsmodell

Die Matrix gilt je Data Node: welches Modell zutrifft, folgt aus dem Standort, den der Kunde für den jeweiligen Data Node in der Plattform gewählt hat. Ein Kunde kann Modelle mischen.

Maßnahmenbereich	M1	M2	M3
Authentifizierung, Berechtigungen, Mandantentrennung (Software)	roleALPHA	roleALPHA	roleALPHA
Verschlüsselung von Geheimnissen in der Anwendung	roleALPHA	roleALPHA	roleALPHA
Protokollierung und Audit-Trail (Funktion)	roleALPHA	roleALPHA	roleALPHA
TLS-Terminierung des Core	roleALPHA	roleALPHA	roleALPHA
TLS-Terminierung der Data Nodes	roleALPHA	Kunde	Dritt-Hoster des Kunden
Physische Sicherheit und Netzwerksicherheit der Data Nodes	roleALPHA	Kunde	Dritt-Hoster des Kunden
Datenträgerverschlüsselung der Data Nodes	roleALPHA (über Hoster)	Kunde	Dritt-Hoster des Kunden
Sicherungskopien und Wiederherstellung der Fachinhalte	roleALPHA	Kunde	Kunde
Einspielen von Aktualisierungen der Data Nodes	roleALPHA	Kunde (mit Unterstützung von roleALPHA)	Kunde
Überwachung der Verfügbarkeit der Data Nodes	roleALPHA	Kunde	Kunde

Einfluss der Auslieferungsform (M2, M3). Wie die beiden letzten Zeilen praktisch erfüllt werden, hängt zusätzlich davon ab, in welcher Form der Data Node ausgeliefert wird. Liefert der Anbieter die Betriebssystemebene mit aus (Server- oder Container-Paket), bringt er Werkzeuge mit, die Aktualisierungen selbsttätig einspielen und den Betrieb zusätzlich überwachen; der Kunde stellt dann die Infrastruktur. Wird der Data Node dagegen in eine vom Kunden betriebene Container-Orchestrierung ausgeliefert, gibt es diese Werkzeuge nicht: Einspielen von Aktualisierungen und Überwachung der Verfügbarkeit obliegen dort vollständig dem Kunden. Der Anbieter zeigt den jeweils erwarteten Stand an und stellt ihn zum Abruf bereit; er spielt ihn nicht ein.

9. Noch zu ergänzende Angaben

Folgende Punkte sind vor Herausgabe an Kunden zu vervollständigen; sie hängen von der Produktivumgebung ab und sind nicht aus der Software ableitbar:

⟨TODO: Zertifizierungen des Hosters (z.B. ISO/IEC 27001) und Nachweise⟩
⟨TODO: Bestätigung der Datenträgerverschlüsselung durch den Hoster⟩
⟨TODO: Sicherungsturnus im Produktivbetrieb⟩
⟨TODO: Wiederherstellungszeit- und Wiederherstellungspunktziele (RTO/RPO), sofern zugesagt⟩
⟨TODO: Name und Kontakt des Datenschutzbeauftragten⟩

Weitere Dokumente

English version: Technical and Organisational Measures