¶ Externe Dienste und Cloud
Leeres Musterregister: Diese öffentliche Beispielseite enthält keine realen Anbieter, Cloud-Mandanten, Vertragsinhalte, Unterauftragnehmer, Regionen, Sicherheitslücken, Konten, Schlüssel, Konfigurationen oder Prüfberichte. Farben und Musterzeilen erläutern ausschließlich das vorgesehene Steuerungsverfahren.
Auslagerung verlagert Aufgaben, nicht die eigene Steuerungsverantwortung: Ein Vertrag, Zertifikat oder Prüfbericht ersetzt weder die organisationsbezogene Risikobewertung noch die Prüfung eigener Kundenkontrollen, Kontinuität und Exit-Fähigkeit.
¶ Dokumenteninformationen
| Feld | Wert |
|---|---|
| Dokumenten-ID | NIS2-REG-03-07 |
| Dokumentenart | Verfahrensbeschreibung und Registermodell für externe Dienste und Cloud-Abhängigkeiten |
| Wiki.js-Pfad | /NIS2/03-Assets-Prozesse-und-Dienste/Externe-Dienste-und-Cloud |
| Verantwortlich | Dienst-Owner, Einkauf/Lieferantenmanagement und Informationssicherheitsfunktion |
| Status | Entwurf – keine realen Anbieter oder Cloud-Dienste bewertet |
| Version / Stand | 0.3 / 09.08.2026 |
| Schutzklasse | Wiki enthält Methodik und anonymisierte Muster; Verträge, Architektur-, Risiko- und Nachweisdaten geschützt |
| Rechtsbezug | insbesondere § 30 Absatz 2 Nummer 4 BSIG; abhängig von der Einrichtungsart Durchführungsverordnung (EU) 2024/2690 |
| Freigabe | Ausstehend; Register, Kritikalitätsklassen, Prüftiefe, Vertrags- und Exit-Anforderungen festzulegen |
Externe Leistungen, Verantwortungsgrenzen, Lieferketten und Exit-Fähigkeit vollständig steuern. Eigene redaktionelle SVG-Grafik. Zum Vergrößern öffnen.
¶ 1. Steuerungscockpit – Muster ohne Echtdaten
Ein Gedankenstrich bedeutet: Auf dieser Musterseite liegt kein realer Messwert vor. Er darf nicht als Null, vollständige Prüfung oder wirksame Kontrolle interpretiert werden.
■ Kritische Dienste ohne Owner
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
▲ Offene Anbieterabweichungen
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
● Überfällige Nachweise
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
? Ungetestete Exit-Szenarien
—
keine Echtdaten im Muster-Wiki
—
keine Echtdaten im Muster-Wiki
Ein produktives Cockpit nennt Stichtag, Scope, bekannte Grundgesamtheit, Kritikalitätsklassen, Datenquellen und Aussagegrenzen. Die Anzahl geprüfter Anbieter ist ohne Dienstebezug und Prüftiefe wenig aussagekräftig.
¶ 2. Die Steuerung auf einen Blick
| Phase | Leitfrage | Hauptdokument |
|---|---|---|
| Bedarf | Welche Leistung wird für welchen relevanten Dienst benötigt? | Bedarf und Dienstebezug |
| Auswahl | Kann der konkrete Anbieter-Dienst die Anforderungen erfüllen? | Due-Diligence-Bewertung |
| Vertrag | Sind Sicherheit, Nachweise, Vorfälle, Unterauftragnehmer und Exit geregelt? | Vertrags- und Abweichungsmatrix |
| Einführung | Sind Mandant, Identitäten, Datenflüsse und Monitoring sicher eingerichtet? | Konfigurationsabnahme |
| Betrieb | Werden Leistung, Risiken, Änderungen und Nachweise wirksam überwacht? | Review- und Maßnahmenprotokoll |
| Kontinuität | Kann der eigene Dienst bei Anbieterproblemen fortgeführt oder wiederhergestellt werden? | BCM-/Restore-Test |
| Exit | Sind Portabilität, Übergang und sichere Löschung praktisch möglich? | Exit-Plan und Exittest |
¶ 3. Zweck und Arbeitsergebnisse
Das Verfahren soll nachvollziehbar beantworten:
| Steuerungsfrage | Erwartetes Ergebnis |
|---|---|
| Welche externen Leistungen unterstützen relevante Dienste? | vollständige Dienst-Anbieter-Zuordnung |
| Wer entscheidet und wer betreibt? | bestätigte interne und externe Verantwortungen |
| Welche Risiken und Abhängigkeiten bestehen? | aktuelle Risiko- und Konzentrationssicht |
| Welche Kontrollen liegen beim Anbieter, welche beim Kunden? | kontrollbezogene Shared-Responsibility-Matrix |
| Welche Nachweise sind belastbar? | bewertete Berichte mit Scope, Zeitraum und Einschränkungen |
| Wie wird auf Änderungen und Vorfälle reagiert? | Fristen, Kontakte, Eskalation und Entscheidungsweg |
| Wie funktionieren Wiederherstellung und Exit? | getestete, realistische Kontinuitäts- und Übergangsszenarien |
¶ 4. Rechtlicher Rahmen
§ 30 Absatz 2 Nummer 4 BSIG verlangt Sicherheit der Lieferkette einschließlich sicherheitsbezogener Aspekte der Beziehungen zu unmittelbaren Anbietern oder Diensteanbietern. Weitere Nummern betreffen unter anderem Risikoanalyse, Betriebskontinuität, sicheren Erwerb und Wartung, Wirksamkeitsbewertung, Kryptografie und Zugriffskontrolle.
Für die in § 30 Absatz 3 BSIG genannten digitalen Einrichtungsarten gilt die Durchführungsverordnung (EU) 2024/2690 vorrangig. Nummer 5.1 konkretisiert unter anderem Auswahlkriterien, Diversifizierungsfähigkeit, vertragliche Cybersicherheitsanforderungen, Vorfallmeldungen, Prüfberichte, Schwachstellenbehandlung, Unterauftragnehmer und Pflichten bei Vertragsbeendigung. Für andere Einrichtungsarten wird die Anwendbarkeit dieser Detailvorgaben geprüft.
Die Seite ist keine Rechtsberatung und kein Nachweis einer erfüllten Lieferkettenpflicht.
¶ 5. Welche externen Leistungen gehören in das Register?
| Kategorie | Typische Beispiele | Mögliche kritische Wirkung |
|---|---|---|
| Cloud-Infrastruktur | Rechenleistung, Storage, Netzwerk, Containerplattform | Ausfall mehrerer Anwendungen und Datenzugriff |
| SaaS / Fachanwendung | ERP, CRM, Kollaboration, HR, Ticketsystem | Unterbrechung von Kern- oder Supportprozessen |
| Identität und Vertrauen | IdP, MFA, PKI, Signatur, DNS | organisationsweiter Zugriffs- oder Vertrauensausfall |
| Rechenzentrum | Colocation, Housing, Strom, Klima, Zutritt | physischer Ausfall zentraler Systeme |
| Managed Service | IT-Betrieb, SOC, MSSP, Administration, Support | privilegierter Zugriff und Betriebsabhängigkeit |
| Kommunikation | Internet, Telefonie, E-Mail, VPN, Notfallkommunikation | fehlende Erreichbarkeit und Meldemöglichkeit |
| Entwicklung / Lieferkette | Software, Updates, CI/CD, Bibliotheken, Hersteller | kompromittierte Komponenten oder fehlender Support |
| Backup / Kontinuität | Sicherung, Archiv, Restoreplattform, Ausweichdienst | Verlust der Wiederherstellungsfähigkeit |
| Spezialdienst | Fernwartung, Übersetzung, Datenverarbeitung, Logistik | Datenzugriff oder Ausfall eines Teilprozesses |
Auch intern erbrachte Konzernleistungen werden erfasst, wenn eine eigenständige Anbieter-, Vertrags- oder Abhängigkeitsbeziehung besteht.
¶ 6. Service- und Bereitstellungsmodelle
| Modell | Typische Anbieteraufgabe | Typische Kundenaufgabe |
|---|---|---|
| IaaS | physische Infrastruktur, Virtualisierung und Basisverfügbarkeit | Betriebssystem, Workload, Identitäten, Daten und Konfiguration |
| PaaS | Plattformlaufzeit und definierte Plattformkontrollen | Anwendung, Daten, Berechtigungen und sichere Nutzung |
| SaaS | Anwendung und vereinbarter Dienstbetrieb | Mandantenkonfiguration, Nutzer, Freigaben, Daten und Integration |
| Managed Service | vertraglich definierter Betriebs- oder Sicherheitsprozess | Zielvorgaben, Freigaben, Kontrolle und nicht ausgelagerte Aufgaben |
| Colocation | Raum, Strom, Klima und physischer Grundschutz im Scope | eigene Systeme, Zugriffe, Betrieb und Wiederherstellung |
Die tatsächliche Verantwortung ergibt sich aus Leistungsbeschreibung, Architektur, Konfiguration und Vertrag – nicht allein aus der Modellbezeichnung.
¶ 7. Rollen und Entscheidungsrechte
| Rolle | Entscheidung / Aufgabe | Mindestnachweis |
|---|---|---|
| Dienst-/Prozess-Owner | Bedarf, Kritikalität, Ausfalltoleranz und Ersatzweg | Dienstfreigabe |
| Einkauf/Lieferantenmanagement | Auswahl, Vertrag, Laufzeit und kommerzielle Eskalation | Beschaffungsakte |
| Informationssicherheit | Sicherheitsrisiko, Anforderungen, Abweichungen und Nachweise | Sicherheitsbewertung |
| IT-/Cloud-/Application-Owner | Architektur, Konfiguration, Integration, Betrieb und Exit | technische Abnahme |
| Datenschutz/Recht | Datenschutz-, Geheimhaltungs-, Regulierungs- und Vertragsfragen | Fachprüfung im Mandat |
| BCM/Notfallmanagement | Wiederherstellung, Ersatzbetrieb und Krisenkommunikation | Test- und Übungsreferenz |
| Geschäftsleitung | wesentliche Restrisiken und Konzentrationsentscheidungen | dokumentierte Entscheidung |
Auch bei vollständigem Outsourcing bleibt mindestens ein befugter interner Owner erforderlich.
¶ 8. Mindestfelder im Anbieter- und Cloud-Register
| Feldgruppe | Pflichtangaben |
|---|---|
| Identität | Anbieter-ID, Dienst-ID, konkrete Leistung, Vertragsreferenz und Status |
| Dienstbezug | relevante Dienste, Prozesse, Systeme, Informationen und Kritikalität |
| Verantwortung | interner Owner, Betreiber, Anbieterrollen und Vertretung |
| Leistungsmodell | IaaS/PaaS/SaaS/Managed Service, Mandant und bestellte Ausprägung |
| Lieferkette | unmittelbarer Anbieter, wesentliche Unterauftragnehmer und Konzentrationsbezug |
| Orte | Leistungs-, Speicher-, Backup-, Support- und Administrationsregionen |
| Sicherheit | Identitäten, Zugriffe, Kryptografie, Logs, Schwachstellen und Vorfälle |
| Nachweise | Berichtstyp, Scope, Zeitraum, Ausnahmen, Kundenkontrollen und Review |
| Kontinuität | SLA, RTO/RPO, Backup, Wiederherstellung, Kommunikation und Alternative |
| Exit | Formate, Export, Übergang, Fristen, Kosten, Löschung und Teststatus |
¶ 9. Kritikalitätsklassen
| Klasse | Typische Auswirkung | Mindeststeuerung |
|---|---|---|
| K1 – kritisch | erhebliche Beeinträchtigung eines relevanten Dienstes; geringe Austauschbarkeit | vertiefte Due Diligence, verbindliche Nachweise, enges Monitoring, getestete Wiederherstellung und Exit |
| K2 – wesentlich | merkliche Auswirkung; begrenzter Ersatz innerhalb tolerierbarer Zeit | risikobasierte Prüfung, regelmäßiger Review und vorbereitete Alternative |
| K3 – unterstützend | begrenzte direkte Auswirkung; kurzfristig ersetzbar | dokumentierte Basisprüfung und angemessene Vertragskontrollen |
| Ungeklärt | Dienstebezug, Ausfallfolge oder Abhängigkeit nicht belastbar bestimmt | keine positive Freigabe; Klärung und Risikobewertung erforderlich |
Die Klasse richtet sich nicht nach Vertragswert oder Anbietergröße. Ein günstiger DNS-, Identitäts- oder Zertifikatsdienst kann hochkritisch sein.
¶ 10. Entscheidungsfaktoren für die Kritikalität
| Faktor | Leitfrage |
|---|---|
| Dienstwirkung | Welche relevanten Dienste fallen aus oder werden unsicher? |
| Zeit | Wie lange ist die Unterbrechung tolerierbar? |
| Daten | Welche Informationen und Schutzziele sind betroffen? |
| Privilegien | Besitzt der Anbieter administrativen oder weitreichenden Zugriff? |
| Austauschbarkeit | Wie schnell kann realistisch gewechselt oder intern überbrückt werden? |
| Konzentration | Welche weiteren Dienste hängen vom selben Anbieter oder Unterbau ab? |
| Lieferkette | Welche Unterauftragnehmer, Regionen oder Softwarekomponenten sind wesentlich? |
| Wiederherstellung | Sind Daten, Konfiguration und Fachbetrieb unabhängig wiederherstellbar? |
¶ 11. Due-Diligence-Matrix
| Prüffeld | Kernfrage | Geeigneter Nachweis |
|---|---|---|
| Organisation | Sind Sicherheitsrollen, Prozesse und Kontakte belastbar? | Richtlinienauszug, Ansprechpartner, Bericht |
| Dienst-Scope | Deckt die Prüfung genau den bestellten Dienst und die Region ab? | Systembeschreibung, Leistungsumfang |
| Architektur | Sind Mandantentrennung, Netz, Administration und Abhängigkeiten verstanden? | Architekturgespräch und Diagramm |
| Identitäten | Wie werden privilegierte Zugriffe, MFA und Austritte gesteuert? | Kontrollbeschreibung und Stichprobe |
| Schwachstellen | Wie erfolgen Tests, Meldung, Priorisierung und Behebung? | Prozess, Kennzahlen, Prüfbericht |
| Vorfälle | Werden relevante Vorfälle schnell genug gemeldet und gemeinsam behandelt? | Meldeverfahren und Kontaktmatrix |
| Lieferkette | Welche Unterauftragnehmer und kritischen Komponenten sind beteiligt? | Subdienstleisterliste und Änderungsweg |
| Kontinuität | Sind Backup, Wiederherstellung, Kapazität und Krisenkommunikation geeignet? | Testbericht, SLA, BCP-Auszug |
| Exit | Sind Export, Übergang und Löschung praktisch realisierbar? | Exitbeschreibung und Probeexport |
Fehlende Informationen werden als bewertbare Lücke mit Owner, Risiko und Termin behandelt – nicht stillschweigend als erfüllt.
¶ 12. Auswahl- und Freigabeentscheidung
| Ergebnis | Bedeutung | Entscheidung |
|---|---|---|
| geeignet | Kriterien im geprüften Scope erfüllt; Restrisiken vertretbar | Freigabe mit Reviewtermin |
| bedingt geeignet | begrenzte Lücken mit wirksamer Kompensation und Termin | befristete Freigabe |
| nicht geeignet | wesentliche Anforderung oder Steuerbarkeit fehlt | keine Produktivfreigabe |
| nicht bewertbar | Scope, Nachweise oder Verantwortungen unzureichend | Informationsnachforderung und Eskalation |
Die Entscheidung nennt Dienst, Version, Region, Vertragsstand, Annahmen und Gültigkeitsdauer.
¶ 13. Shared-Responsibility-Matrix
| Kontrollbereich | Anbieter | Eigenes Unternehmen | Gemeinsamer Nachweis |
|---|---|---|---|
| Plattformschutz | technische Basis im vereinbarten Scope | sichere Auswahl und Nutzung | Systembeschreibung und Konfiguration |
| Mandant / Organisation | Mandantenfunktion und Trennmechanismus | Struktur, Richtlinien und Verantwortungen | Tenant- und Architekturabnahme |
| Identitäten | Anbieteradministration und IAM-Funktionen | Konten, Rollen, MFA, Review und Austritt | Rollenmodell und Reviewprotokoll |
| Daten | vereinbarte Speicher- und Verarbeitungsfunktionen | Klassifizierung, Zweck, Freigabe und Löschung | Datenfluss- und VVT-Referenz |
| Kryptografie | angebotene Verfahren und Plattformschlüssel | Auswahl, Konfiguration und eigene Schlüsselanteile | Konfigurations- und Schlüsselreferenz |
| Protokollierung | verfügbare Logs und Zeitbasis | Aktivierung, Export, Korrelation und Alarmierung | Logkonfiguration und Alarmtest |
| Schwachstellen | Anbieter-Scope und Plattformbehebung | eigene Workloads, Konfiguration und Bewertung | Bericht, Ticket und Nachprüfung |
| Backup/Restore | vertragliche Plattformleistung | Anforderungen, Zusatzsicherung und End-to-End-Test | SLA und Wiederherstellungstest |
| Vorfall | Erkennung und Meldung im Anbieter-Scope | eigene Bewertung, Reaktion und Meldepflichten | Kontaktmatrix und Übung |
| Exit | Export- und Löschfunktionen | Planung, Migration, Kontrolle und Abnahme | Probeexport und Löschreferenz |
„Anbieter verantwortlich“ ist ohne konkrete Kontrollaufgabe, Scope und Nachweis nicht ausreichend.
¶ 14. Vertragsanforderungsmatrix
| Regelungsbereich | Mindestinhalt | Warnsignal |
|---|---|---|
| Sicherheitsanforderungen | konkreter Dienst, Scope, Standards und Kundenpflichten | nur allgemeine Marketingaussage |
| Vorfallmeldung | Ereignisse, Inhalt, Kontakt, Frist und Aktualisierungen | Meldung erst nach vollständiger Ursachenklärung |
| Prüf- und Auskunftsrecht | Bericht, Nachfragen, Sonderprüfung und Maßnahmenstatus | ausschließlich unverbindliche Selbstauskunft |
| Schwachstellen | Meldung, Priorisierung, Behebung und Kundeninformation | keine Frist oder Statusinformation |
| Unterauftragnehmer | Liste, Sicherheitsanforderungen, Änderung und Reaktion | unbegrenzte Änderung ohne Information |
| Leistungs-/Datenorte | Speicherung, Verarbeitung, Backup, Support und Administration | nur pauschale Regionsangabe |
| Kontinuität | SLA, Backup, Wiederherstellung, Kapazität und Kommunikation | unklare Ausschlüsse und Messpunkte |
| Vertragsende | Export, Übergang, Datenlöschung, Nachweis und Unterstützung | proprietäres Format ohne realistische Migration |
Abweichungen erhalten Risiko, Ersatzmaßnahme, Entscheidung, Owner, Frist und Nachprüfung.
¶ 15. Unterauftragnehmer und Lieferkettentiefe
| Betrachtung | Erforderliche Information |
|---|---|
| unmittelbarer Anbieter | Vertragspartner, Leistung und verantwortete Kontakte |
| wesentlicher Unterauftragnehmer | Teilservice, Region, Zugriff und Austauschbarkeit |
| technische Schlüsselkomponente | Software, Plattform, Identitäts- oder Netzwerkabhängigkeit |
| Änderungsweg | Information, Bewertungsfrist, Widerspruch und Exit-Option |
| Sicherheitsdurchgriff | vertragliche oder nachweisbare Weitergabe relevanter Anforderungen |
Nicht jede Unterlieferstufe muss gleich detailliert geführt werden. Kritische Knoten, privilegierte Zugriffe und schwer austauschbare Leistungen werden jedoch sichtbar gemacht.
¶ 16. Leistungs-, Daten- und Zugriffsorte
| Ortsart | Beispielhafte Frage |
|---|---|
| primäre Speicherung | In welcher Region liegen produktive Daten? |
| Verarbeitung | Wo werden Daten entschlüsselt, analysiert oder transformiert? |
| Backup / Replikation | Welche Regionen und Wiederherstellungswege werden genutzt? |
| Support | Von wo ist administrativer oder lesender Zugriff möglich? |
| Telemetrie | Wohin fließen Protokolle, Diagnose- und Nutzungsdaten? |
| Unterauftragnehmer | Welche weitere Organisation verarbeitet oder verwaltet den Dienst? |
Datenschutz- und Rechtsbewertungen erfolgen in den zuständigen Verfahren. Das Cloud-Register dokumentiert die tatsächliche technische und organisatorische Beziehung und die kontrollierte Referenz.
¶ 17. Konzentrationsrisiko sichtbar machen
| Konzentrationsart | Beispiel | Steuerungsoption |
|---|---|---|
| Anbieter | mehrere kritische Dienste beim selben Konzern | Gesamtportfolio und Eskalation betrachten |
| Region | mehrere Dienste in derselben Cloudregion | alternative Region oder Notbetrieb prüfen |
| Identität | alle Dienste von einem IdP abhängig | Notfallzugriff und Wiederherstellung testen |
| Netzwerk / DNS | gemeinsamer Carrier oder DNS-Anbieter | alternative Kommunikation bewerten |
| Softwarekomponente | identische Bibliothek oder Plattform | Schwachstellen- und Updateabhängigkeit überwachen |
| Supportkette | derselbe MSP administriert mehrere Systeme | privilegierte Zugriffe und Vertretung begrenzen |
Getrennte Verträge bedeuten nicht automatisch unabhängige Risiken.
¶ 18. Sichere Cloud-Einführung – Quality Gate
| Prüfschritt | Status im Muster | Nachweisreferenz |
|---|---|---|
| Dienst, Mandant, Region und Owner eindeutig | Offen | geschützt vorzusehen |
| Architektur und Datenflüsse freigegeben | Offen | geschützt vorzusehen |
| Identitäten, Rollen, MFA und Notfallkonten geprüft | Offen | geschützt vorzusehen |
| sichere Baseline und Abweichungen dokumentiert | Offen | geschützt vorzusehen |
| Protokollierung, Export und Alarmierung getestet | Offen | geschützt vorzusehen |
| Backup- und Restore-Verantwortung bestätigt | Offen | geschützt vorzusehen |
| Provider-, VVT- und Vertragsreferenzen verknüpft | Offen | geschützt vorzusehen |
| Betriebs-, Vorfall- und Exitkontakte bestätigt | Offen | geschützt vorzusehen |
Herstellerstandardwerte gelten nicht automatisch als bedarfsgerecht oder sicher.
¶ 19. Identitäten und privilegierte Zugriffe
| Thema | Mindeststeuerung |
|---|---|
| Benutzeridentitäten | zentrale Identität, MFA, Rollen und regelmäßiger Review |
| Anbieteradministration | benannte Funktion, Zweckbindung, Protokollierung und Kontrolle |
| Supportzugriff | Genehmigung, Befristung, technischer Kanal und Nachkontrolle |
| Service-Identitäten | eindeutiger Owner, geringste Rechte, Rotation und sicherer Speicher |
| Notfallkonten | geschützter Zugriff, Alarmierung, Test und Rücksetzung |
| Austritt / Rollenwechsel | zeitnaher Entzug bei Kunde, Anbieter und Partnern |
¶ 20. Nachweise richtig bewerten
| Nachweis | Was er leisten kann | Was zusätzlich zu prüfen ist |
|---|---|---|
| Zertifikat | bestätigt einen definierten zertifizierten Scope zu einem Zeitpunkt | konkreter Dienst, Standorte, Gültigkeit und Ausschlüsse |
| Prüfbericht Typ 1 | Design und Einrichtung zu einem Stichtag | keine nachhaltige Betriebswirksamkeit über einen Zeitraum |
| Prüfbericht Typ 2 | Ausgestaltung und Betrieb über einen Prüfzeitraum | Abweichungen, Zeitraum, Subdienstleister und Kundenkontrollen |
| C5-Bericht | strukturierte Beurteilung von Cloud-Kontrollen im beschriebenen Scope | Systembeschreibung, Testatstyp, Abweichungen und ergänzende Kundenkontrollen |
| Penetrationstest | technische Befunde im getesteten Umfang | Abdeckung, Zeitpunkt, Behebung und Nachprüfung |
| Selbstauskunft | liefert Informationen und Erklärungen | unabhängige Bestätigung und Widerspruchsprüfung |
Ein C5-Testat ist keine BSI-Zertifizierung. Ein Bericht wird fachlich ausgewertet und nicht nur abgelegt.
¶ 21. Nachweisstatus
| Status | Bedeutung | Folge |
|---|---|---|
| aktuell und passend | Scope, Zeitraum und Dienst passen; Abweichungen bewertet | regulär weiterführen |
| eingeschränkt | teilweise passend oder mit offenen Kundenkontrollen | Zusatznachweis und Maßnahme |
| abgelaufen | Gültigkeits- oder Prüfzeitraum überschritten | aktuelle Information anfordern |
| ungeeignet | anderer Dienst, Standort oder nicht aussagefähiger Bericht | nicht als Nachweis verwenden |
| nicht bewertbar | Bericht oder Systembeschreibung fehlt | Eskalation und Risikobewertung |
¶ 22. Laufende Überwachung
| Signal | Quelle | Reaktion |
|---|---|---|
| Verfügbarkeit / Leistung | Monitoring, SLA-Bericht | Trend, Ursache und Dienstwirkung prüfen |
| Sicherheitsmeldung | Anbieter, Hersteller, CERT | Betroffenheit und Maßnahmen bewerten |
| neuer Unterauftragnehmer | Anbieterinformation | Region, Zugriff und Risiko prüfen |
| ablaufender Nachweis | Nachweisregister | aktuellen Bericht anfordern |
| offene Abweichung | Maßnahmenregister | Termin, Risiko und Eskalation prüfen |
| Support- oder Produktende | Roadmap / Vertrag | Migration oder Akzeptanz entscheiden |
| erheblicher Vorfall | Anbieter und eigene Erkennung | Incident- und Meldeprozess aktivieren |
¶ 23. Änderungsmatrix
| Änderung | Mindestprüfung vor Übernahme |
|---|---|
| neue Region | Datenschutz, Resilienz, Latenz, Vertrag und Datenfluss |
| neuer Unterauftragnehmer | Leistung, Zugriff, Sicherheit und Widerspruchsrecht |
| neue Funktion | Datenarten, Berechtigungen, Exponierung und Logging |
| geänderte Sicherheitskontrolle | Risiko, Kompensation und Nachweis |
| Anbieterfusion / Verkauf | Vertrag, Rechtsraum, Konzentration und Exit |
| Preismodell / Ausstiegsgebühr | wirtschaftliche Exit-Fähigkeit und Lock-in |
| eingestellter Dienst / Support | Migration, Datenexport und Fristen |
Wesentliche Änderungen erhalten eine dokumentierte Freigabe; fehlende oder verspätete Anbieterinformationen werden als Risiko behandelt.
¶ 24. Vorfall- und Kommunikationsmatrix
| Thema | Anbieterbeitrag | Eigenes Unternehmen |
|---|---|---|
| Erkennung | Ereignisse im Anbieter-Scope erkennen | eigene Logs und Dienstwirkung überwachen |
| Erstinformation | betroffene Leistung, Zeitpunkt und vorläufige Wirkung melden | Triage, Ansprechpartner und mögliche Meldepflicht prüfen |
| Eindämmung | Plattformmaßnahmen und Zugangsbeschränkung | Integrationen, Konten und Datenflüsse begrenzen |
| Beweissicherung | vereinbarte Logs und Informationen sichern | eigene Beweiskette und Entscheidungen dokumentieren |
| Kommunikation | regelmäßige Updates und technische Kontakte | Behörden-, Kunden- und interne Kommunikation steuern |
| Wiederherstellung | Anbieterplattform stabilisieren | eigenen Ende-zu-Ende-Dienst prüfen und freigeben |
| Nachbereitung | Ursache und Korrekturen berichten | Risiko, Vertrag, Register und Maßnahmen aktualisieren |
Vertragliche Anbieterfristen werden mit eigenen gesetzlichen und vertraglichen Fristen abgestimmt.
¶ 25. SLA und tatsächliche Dienstwirkung
| SLA-Frage | Warum sie wichtig ist |
|---|---|
| Was ist der Messpunkt? | Plattformverfügbarkeit kann trotz gestörtem End-to-End-Dienst grün sein |
| Wann beginnt die Ausfallzeit? | Erkennung, Meldung und Messung können auseinanderfallen |
| Welche Ereignisse sind ausgeschlossen? | Wartung oder abhängige Dienste können unberücksichtigt bleiben |
| Welche Region und Funktion sind umfasst? | Vertrag kann nur Teilbereiche abdecken |
| Welche Gutschrift gibt es? | finanzielle Kompensation stellt den Dienst nicht wieder her |
| Welche Informationen stehen bereit? | eigene Vorfall- und Meldebewertung benötigt zeitnahe Daten |
¶ 26. Backup und Wiederherstellung
| Prüffeld | Anbieterleistung | Eigene Prüfung |
|---|---|---|
| Sicherungsumfang | Daten, Konfiguration, Metadaten laut Vertrag | passt der Umfang zum Dienst und RPO? |
| Isolation | technische und organisatorische Trennung | schützt sie vor Fehlbedienung und Ransomware? |
| Aufbewahrung | angebotene Fristen und Versionen | passen Recht, Fachbedarf und Löschkonzept? |
| Wiederherstellung | Plattformverfahren und zugesagte Zeit | funktioniert der eigene Ende-zu-Ende-Dienst? |
| Kundenexport | Exportfunktion und Format | kann unabhängig gespeichert und zurückgespielt werden? |
| Test | Anbieter- oder Plattformtest | eigener Test mit Daten, Identitäten und Integrationen |
Ein erfolgreicher Anbietertest ersetzt nicht automatisch einen organisationsbezogenen Wiederherstellungstest.
¶ 27. Exit- und Portabilitätsmatrix
| Exit-Baustein | Mindestinhalt | Prüfmethode |
|---|---|---|
| Auslöser | Vertragsende, Risiko, Ausfall, Strategie oder Rechtsänderung | Tischübung |
| Datenexport | Format, Volumen, Dauer, Kosten und Integrität | Probeexport |
| Konfiguration | Rollen, Regeln, Workflows, Schlüssel und Metadaten | dokumentierter Export |
| Zielumgebung | Alternative, Kapazität, Sicherheit und Abnahme | Teilmigration |
| Parallelbetrieb | Synchronisation, Rückfall und Entscheidungszeitpunkt | technischer Test |
| Übergangsunterstützung | Ansprechpartner, Fristen und Know-how | Vertragsprüfung |
| Löschung | Primärdaten, Sicherungen, Unterauftragnehmer und Bestätigung | Löschreferenz |
| Rückbau | Konten, Schnittstellen, Freigaben, Schlüssel und Monitoring | Abschlusscheckliste |
¶ 28. Exit-Reifegrad
| Stufe | Bedeutung |
|---|---|
| 0 – unbekannt | kein belastbares Exit-Szenario |
| 1 – beschrieben | Plan und Verantwortungen vorhanden, aber nicht erprobt |
| 2 – teilweise getestet | Export oder Teilmigration praktisch geprüft |
| 3 – Ende-zu-Ende getestet | Übergang, Wiederanlauf und Rückbau im definierten Scope erprobt |
| 4 – laufend steuerbar | Tests, Änderungen, Kosten und Alternativen regelmäßig aktualisiert |
Die Stufe beschreibt den geprüften Scope und darf nicht pauschal auf alle Dienste eines Anbieters übertragen werden.
¶ 29. Fiktiver Musterregistereintrag
| Feld | Fiktiver Musterwert |
|---|---|
| Anbieter-/Dienst-ID | DEMO-SUP-001 / DEMO-CLOUD-001 |
| Leistung | Muster-SaaS A |
| Unterstützter Dienst | DEMO-SVC-001 |
| Kritikalität | K1 – Muster, nicht freigegeben |
| Owner | Rolle Dienst-Owner |
| Region / Unterauftragnehmer | noch nicht bewertet |
| Shared Responsibility | Entwurf |
| Nachweisstatus | Violett – nicht bewertbar |
| Wiederherstellung | keine reale Prüfung |
| Exit-Reifegrad | 0 – unbekannt |
| Nächster Review | kein Echtdatum |
Der Eintrag ist vollständig fiktiv und bestätigt weder einen realen Anbieter noch eine sichere oder NIS2-konforme Cloud-Nutzung.
¶ 30. Statusampel
| Ampel | Bedeutung | Folge |
|---|---|---|
| Grün | Prüfung, Vertrag, Kundenkontrollen und Review im definierten Scope aktuell | regulär überwachen |
| Gelb | begrenzte Lücke mit Owner und Termin | nachverfolgen |
| Orange | wesentliche Nachweis-, Vertrags- oder Kontinuitätslücke | priorisiert behandeln |
| Rot | kritischer Dienst ohne steuerbare Sicherheits- oder Exit-Basis | unverzüglich eskalieren |
| Violett | wegen fehlender Daten oder ungeklärtem Scope nicht bewertbar | Informationsnachforderung und Risikoentscheidung |
¶ 31. Arbeitsansichten und Filter
| Ansicht | Nutzen |
|---|---|
| kritische Dienste je Anbieter | Gesamtwirkung eines Anbieterausfalls erkennen |
| offene K1-Abweichungen | priorisierte Maßnahmen steuern |
| Nachweise mit Ablauf in 90 Tagen | frühzeitige Anforderung ermöglichen |
| neue Regionen und Unterauftragnehmer | Änderungsprüfung bündeln |
| ungetestete Restore- und Exit-Szenarien | Resilienzlücken sichtbar machen |
| Anbieter mit privilegiertem Zugriff | Zugriffs- und Überwachungsbedarf prüfen |
| gemeinsame Regionen / IdP / Carrier | Konzentrationsrisiken erkennen |
| nicht bewertbare Dienste | fehlende Grundinformationen eskalieren |
¶ 32. Kennzahlen und Managementbericht
| Kennzahl | Aussagegrenze |
|---|---|
| K1-Dienste mit bestätigtem Owner | sagt nichts über Nachweisqualität aus |
| Anteil aktuell bewerteter K1-Dienste | hängt von vollständiger Grundgesamtheit ab |
| überfällige Nachweise | Bericht kann trotz formaler Aktualität unpassend sein |
| offene kritische Anbieterabweichungen | Anzahl und Dienstwirkung getrennt berichten |
| ungeprüfte wesentliche Änderungen | Erkennung hängt von Anbieterinformation ab |
| getestete Restore-Szenarien | Testumfang und Ergebnis separat bewerten |
| getestete Exit-Szenarien | Teiltest nicht als vollständiger Exit ausgeben |
Der Managementbericht zeigt betroffene Dienste, Trends, Konzentrationen, Ursachen, Maßnahmen, Termine, Entscheidungen und Aussagegrenzen.
¶ 33. Nachweisregister
| Nachweisart | Mindestmetadaten |
|---|---|
| Due-Diligence-Bewertung | Dienst, Scope, Datum, Prüfer und Ergebnis |
| Vertrag / Anlage | Vertragsstand, Regelungsbereich und geschützter Ablageort |
| Prüfbericht | Typ, Zeitraum, Scope, Standorte, Ausnahmen und Kundenkontrollen |
| Shared-Responsibility-Matrix | Dienstversion, Kontrollbereiche und Owner |
| Konfigurationsabnahme | Mandant, Baseline, Abweichungen und Freigabe |
| Restore-/Exittest | Szenario, Scope, Ergebnis, Lücken und Nachprüfung |
| Reviewprotokoll | Änderungen, Vorfälle, Kennzahlen und Entscheidung |
Vertrauliche Originale verbleiben im geschützten Vertrags- oder Nachweissystem. Das öffentliche Wiki führt nur Methodik, Musterstatus und kontrollierte Referenzen.
¶ 34. Häufige Fehler
| Fehler | Folge | Gegenmaßnahme |
|---|---|---|
| Anbieter statt konkretem Dienst bewertet | Scope passt nicht zur Nutzung | Dienst, Region und Ausprägung festlegen |
| Zertifikat nur abgelegt | Ausnahmen und Kundenkontrollen bleiben ungeprüft | Bericht fachlich auswerten |
| Shared Responsibility zu allgemein | Kontrollen fallen zwischen Zuständigkeiten | Verantwortung je Kontrollbereich zuordnen |
| Unterauftragnehmer unbekannt | Lieferketten- und Ortsrisiken bleiben verborgen | Liste, Änderungsweg und Durchgriff regeln |
| SLA mit Kontinuität verwechselt | Gutschrift ersetzt Wiederherstellung nicht | Ende-zu-Ende-Szenario testen |
| Backup vollständig beim Anbieter vermutet | Löschung oder Kontokompromittierung nicht abgedeckt | Umfang, Isolation und Export prüfen |
| Exit erst bei Kündigung geplant | Zeit, Format und Kosten verhindern Wechsel | früh planen und risikobasiert testen |
| Marketing-Region statt realer Zugriffsorte | Support- und Telemetriepfade fehlen | Speicherung, Verarbeitung und Zugriff trennen |
¶ 35. Qualitätsgate vor Freigabe
| Prüffrage | Musterstatus |
|---|---|
| Sind Dienst, Anbieter, Region, Vertrag und Owner eindeutig? | Offen |
| Sind Kritikalität, Ausfallwirkung und Konzentration bewertet? | Offen |
| Ist Shared Responsibility bis zur Kontrollebene geklärt? | Offen |
| Sind Nachweise hinsichtlich Scope, Zeitraum und Abweichungen bewertet? | Offen |
| Sind Unterauftragnehmer, Orte und Änderungswege nachvollziehbar? | Offen |
| Sind Vorfallfristen und Kontakte mit eigenen Pflichten abgestimmt? | Offen |
| Sind Backup, Restore, Notbetrieb und Exit praktisch realisierbar? | Offen |
| Sind Kundenkontrollen eingerichtet und angemessen getestet? | Offen |
| Sind Abweichungen, Restrisiken, Owner und Termine dokumentiert? | Offen |
| Sind vertrauliche Originale geschützt? | Offen |
¶ 36. Offene Entscheidungen vor produktiver Nutzung
| Entscheidung | Verantwortliche Funktion | Musterstatus |
|---|---|---|
| führendes Anbieter- und Cloud-Register | Einkauf / Informationssicherheit | Offen |
| Kritikalitätsklassen und Prüftiefe | Dienststeuerung / Management | Offen |
| Sicherheits- und Vertragskatalog | Sicherheit / Recht / Einkauf | Offen |
| Shared-Responsibility-Vorlage | Cloud-/System-Owner | Offen |
| Nachweisbewertung und Reviewtakt | Informationssicherheit | Offen |
| Vorfall- und Änderungsfristen | Incident / Einkauf / Recht | Offen |
| Backup-, Restore- und Exit-Mindesttests | BCM / IT / Dienst-Owner | Offen |
| geschützte Vertrags- und Nachweisablage | Dokumentenverantwortung | Offen |
Bis zur Entscheidung bleiben sämtliche Musterwerte ausdrücklich Entwurf.
¶ 37. Verknüpfte Seiten
| Thema | Wiki-Seite |
|---|---|
| Dienstebezug | Relevante Dienste und Prozesse |
| Asset- und Systembezug | Asset- und Systeminventar |
| Abhängigkeiten | Kritikalität und Abhängigkeiten |
| Datenwege | Daten- und Informationsflüsse |
| Risiken | NIS2-Risikoregister |
| Nachweise | NIS2-Nachweisregister |
| Lieferantensteuerung | Lieferanten und Dienstleister |
| Cloud-Nutzung | Mobile Arbeit und Cloud |
| Zugriffe | Zugriff und Berechtigungen |
| Nachweisprüfung | Lieferantenbewertungen |
| Kontinuität | Notfallvorsorge und BCM |
¶ 38. Offizielle Grundlagen und Orientierung
| Quelle | Verwendung |
|---|---|
| § 30 BSIG | Lieferkettensicherheit und Beziehungen zu unmittelbaren Anbietern |
| Durchführungsverordnung (EU) 2024/2690 | für die erfassten digitalen Einrichtungsarten insbesondere Nummer 5.1 |
| BSI – Kriterienkatalog C5 | mögliche Grundlage zur Bewertung von Cloud-Kontrollen und Prüfberichten |
| BSI – Mindeststandard zur Nutzung externer Cloud-Dienste | für die Bundesverwaltung verbindlicher Kontext; außerhalb davon mögliche fachliche Orientierung |
Anwendbarkeit, Rechtsstand, Scope und sektorale Anforderungen werden vor produktiver Nutzung aktuell geprüft. Die externen Links öffnen in einem neuen Tab.
¶ 39. Weiterführende Unterstützung durch SMCT MANAGEMENT
SMCT MANAGEMENT
Unterstützung bei Cloud-, Lieferketten-, Vertrags-, Nachweis-, Kontinuitäts- und Exit-Risikomanagement.
Informationen zur NIS2-Beratung öffnen
Unterstützung bei Cloud-, Lieferketten-, Vertrags-, Nachweis-, Kontinuitäts- und Exit-Risikomanagement.
Informationen zur NIS2-Beratung öffnen
¶ 40. Änderungshistorie
| Version | Datum | Änderung | Freigabe |
|---|---|---|---|
| 0.3 | 09.08.2026 | Seite tabellenorientiert und visuell neu aufgebaut; Rechtsrahmen, Serviceklassen, Due Diligence, Shared Responsibility, Vertragsmatrix, Unterauftragnehmer, Konzentration, Nachweisbewertung, Monitoring, Vorfälle, Restore, Exit, Musterregister, Ampeln und Qualitätsgate ergänzt | Ausstehend |
| 0.2 | 08.08.2026 | Kritikalität, Due Diligence, Vertragsanforderungen, Verantwortungsmatrix, Überwachung, Kontinuität, Exit und Freigabekriterien fachlich vertieft | Ausstehend |
| 0.1 | 08.08.2026 | Leere Musterstruktur für externe Dienste und Cloud erstellt | Ausstehend |