CADA und NIS2: Cloud-Anbieter und Nachweise prüfen

Ein Kunde fragt nach den Cloud-Anbietern

Andrea öffnet die E-Mail um 8:47 Uhr. Der mittelständische Logistikdienstleister aus der DACH-Region hat rund 45 Mitarbeitende, steuert Transporte in der gesamten DACH-Region und liefert an mehrere Großkunden im Bereich Industrie und Handel. IT und Prozesse laufen auf einem Mix aus Cloud-Infrastruktur, einem CRM, einer Telematik-Plattform, einer Buchhaltungslösung, rund einem Dutzend SaaS-Werkzeugen und einigen n8n-Automationen für Versand- und Statusmeldungen. Bis zu dieser E-Mail wirkte das verteilt, aber beherrschbar. Jetzt will ein Großkunde vor der Vertragsverlängerung wissen: Welche Cloud- und Softwareanbieter verarbeiten Kundendaten, wer hat bei diesen Anbietern Zugriff auf die Daten, welche Nachweise gibt es für Datenresidenz, und was passiert beim Wechsel eines Anbieters?

Niemand im Team hat diese Antworten fertig. Markus, der IT-Leiter, kennt die technischen Systeme, hat aber keine vollständigen Angaben zu Supportzugriffen und Unterauftragnehmern. Petra aus Compliance und Qualitätsmanagement führt die Kundenfragebögen, baut sie aber jedes Mal neu aus E-Mails und alten Antworten zusammen. Danilo aus dem Einkauf kennt die Vertrags- und Erneuerungstermine, hat aber nie nach Supportzugriffen oder Wechselbedingungen gefragt. Andrea muss am Ende entscheiden, welche Antwort gegenüber dem Kunden belastbar ist und ob ein Anbieter vor dem nächsten Renewal ersetzt werden muss.

Das Szenario ist ein Beispiel, kein Kundenbericht. Für die Antwort braucht das Unternehmen eine Anbieterliste, Verträge und technische Nachweise. Dabei muss es unterscheiden, ob eine Anforderung aus geltendem Recht, einem Kundenvertrag oder einem vorgeschlagenen Bewertungsrahmen stammt.

Vorschlag und geltende Anforderungen unterscheiden

Zwei Signale verändern die Beschaffung von Cloud- und Softwareleistungen, auch wenn nur eines davon heute schon rechtlich verbindlich ist. Die Unterscheidung zwischen geltendem Recht und geplanten Rahmenwerken ist entscheidend, weil sie bestimmt, was jetzt gebaut werden muss und was nur beobachtet werden sollte.

CADA ist ein Gesetzgebungsvorschlag

Die Kommission veröffentlichte am 3. Juni 2026 ihren CADA-Vorschlag. Er sieht einen EU-weiten Bewertungsrahmen für Cloud- und KI-Souveränität vor. Daraus lässt sich heute keine allgemeine Einstufungs- oder Wechselpflicht für KMU ableiten. Eine interne Einschätzung darf nicht als amtliche Anerkennung verkauft werden.

Für Ihre Beschaffung können Sie bereits konkrete Angaben sammeln: Wo werden Daten verarbeitet? Wer hat Zugriff? Welche Unterauftragnehmer sind beteiligt? Welche Exportmöglichkeiten bietet der Vertrag? Damit lassen sich Kundenanforderungen prüfen, auch wenn ein vorgeschlagener Bewertungsrahmen noch geändert wird.

NIS2-Fristen richten sich nach dem anwendbaren Recht

Die deutsche Umsetzung gilt seit 6. Dezember 2025, das österreichische NISG 2026 seit 1. Oktober 2026. Ein allgemeiner NIS2-Auditstichtag am 30. Juni 2026 ist daraus nicht abzuleiten. Betroffenheit, Registrierungs- und Nachweisfristen müssen anhand der zuständigen nationalen Regeln geprüft werden.

Ein Lieferantenfragebogen kann außerdem auf einer vertraglichen Anforderung beruhen. Dokumentieren Sie deshalb, wer welchen Nachweis verlangt und bis wann. Eine Kundenfrist sagt für sich genommen nichts über die direkte gesetzliche Betroffenheit Ihres Unternehmens aus.

Was der Einkauf vor einer Verlängerung klären sollte

Der Einkauf kennt Vertragslaufzeiten und Ansprechpartner. Die IT kennt Datenflüsse und technische Abhängigkeiten. Für eine Vertragsverlängerung müssen beide zusammenarbeiten: Welche Anforderungen wurden tatsächlich vereinbart, und welche davon kann der Anbieter belegen?

Anforderungen mit dem Vertrag abgleichen

Ein Serverstandort oder ein „Sovereign Region“-Label reicht für diese Prüfung nicht aus. Fordern Sie die Nachweise an, die zur konkreten Anforderung passen: Verarbeitungsorte, Supportzugriffe, Vertragsparteien oder technische Exportmöglichkeiten. Halten Sie fest, welche Angaben bestätigt sind und wo eine Rückfrage offen bleibt.

Für Wechselgebühren im Anwendungsbereich des Data Act gilt der 12. Januar 2027 als Abschaffungstermin. Eigene Migrationsarbeit und Parallelbetrieb können trotzdem Kosten verursachen. Lassen Sie sich vom Anbieter erklären, welche Leistungen und Gebühren im konkreten Wechsel enthalten sind.

Fehlende Nachweise bewerten

Ein fehlender Nachweis kann eine Verlängerung erschweren. Er belegt aber nicht automatisch einen Rechtsverstoß. Prüfen Sie, welche Verpflichtung betroffen ist, ob eine Ersatzinformation genügt und welche Übergangslösung möglich ist. Die Entscheidung sollte mit Verantwortlichem, Begründung und Prüftermin festgehalten werden.

Warnsignale: Woran Mittelständler erkennen, dass sie nicht bereit sind

Die meisten KMU merken nicht an einem Audit, dass sie unvorbereitet sind, sondern an einem Kundenmail. Es gibt klare Signale, die früh sichtbar werden, wenn man sie ernst nimmt.

Das erste Signal: Niemand kann zeigen, wo die vertraglichen Anforderungen und zugehörigen Nachweise liegen. Das zweite Signal: Fragebögen werden für jeden Kunden neu aus E-Mails und Screenshots zusammengesetzt. Eine gepflegte Anbieterliste sollte auf die jeweilige Quelle und ihr Datum verweisen, damit veraltete Angaben erkennbar bleiben.

Das dritte Signal ist ein ungeprüfter Export- oder Wiederherstellungsweg. Dafür sind Container keine Voraussetzung; entscheidend ist, ob Daten und Anwendung am Ziel nutzbar sind. Das vierte Signal sind ungeklärte Zuständigkeiten für Nachweise und Ausnahmen. Die rechtliche Einordnung bleibt eine eigene Aufgabe; die technischen Informationen dafür müssen im Betrieb verfügbar sein.

Anbieterprüfung im laufenden Betrieb

Eine Anbieterliste braucht Pflege: Wer aktualisiert sie nach einem Vertragswechsel, einer neuen Integration oder einem geänderten Supportzugang? Legen Sie diese Aufgaben so fest, dass sie auch bei Abwesenheit der üblichen Ansprechperson erledigt werden können.

Anbieter und Anforderungen zuordnen

Der erste Schritt ist eine Anbieterliste nach Datenklasse, Zugriff und betroffenen Abläufen. Markus prüft im Beispiel die technische Evidenz, Petra hält die Kundenanforderungen fest, Danilo klärt Verträge und Andrea entscheidet über Ausnahmen. Falls ein Kunde eine bestimmte Bewertung verlangt, wird sie mit Quelle und Geltungsbereich dokumentiert; eine eigene Schätzung ist keine Zertifizierung.

Behalten, anpassen oder wechseln

Danach entscheidet das Unternehmen, ob es einen Dienst behält, Anpassungen verlangt oder einen Wechsel vorbereitet. Maßgeblich sind die tatsächlichen Anforderungen, der Nutzen des Dienstes und die vertretbaren Risiken. Ein Standort in DACH kann eine vereinbarte Datenresidenz unterstützen, ersetzt aber keine Prüfung von Zugriffen und Vertragsbedingungen.

Nachweise auffindbar halten

Verknüpfen Sie jeden Eintrag im Anbieterregister mit seinem Nachweis und Prüfdatum. Ein zentraler Ordner genügt für den Anfang, solange die zuständigen Personen Zugriff haben und Änderungen nachvollziehbar bleiben. Halten Sie fest, wer fehlende Informationen anfordert und wann erneut geprüft wird. Erinnerungen können aus einem Kalender oder einem n8n-Workflow kommen. Automatisieren Sie erst, wenn Zuständigkeiten und Abläufe geklärt sind. Ein abgelaufener Nachweis sollte dabei nicht stillschweigend als aktuell erscheinen: Kennzeichnen Sie ihn, fragen Sie eine neue Fassung an und dokumentieren Sie, wie bis dahin mit der offenen Frage umgegangen wird.

Technische Voraussetzungen für einen Anbieterwechsel

Dokumentierte Konfigurationen, verfügbare Zugänge und erprobte Exportwege machen einen beschlossenen Wechsel ausführbar. Prüfen Sie diese Voraussetzungen für das vorgesehene Ziel.

DACH-Hosting und Kubernetes-Portabilität

Container und Kubernetes können Teile einer Anwendung leichter übertragbar machen. Datenbanken, Speicher, Identität und Netzwerk müssen trotzdem gesondert geprüft werden. Ein Probelauf am vorgesehenen Ziel zeigt, welche Anpassungen erforderlich sind. CKA- und CKAD-Zertifikate belegen dabei persönliche Fachqualifikation, keine Rechtskonformität der gesamten Umgebung.

Eine schlanke Registerstruktur, die diese Arbeit nachvollziehbar macht, könnte so aussehen:

cada-vendor-register
├── vendor: Name, Service, Contract Owner, Technical Owner
├── exposure: Datenklasse, privilegierter Zugriff, kritischer Workflow
├── requirements: Quelle, Geltungsbereich, Nachweis, offene Fragen
├── portability: Workload-Form, Migrationspfad, Export-Format, Data-Act-Status
├── evidence: SLA, Sicherheitskontakt, Datenresidenz-Nachweis, Restore-Proof
├── review: Faelligkeit, Reviewer, Entscheidung, Ausnahme, naechste Aktion
└── audit trail: Zeitstempel, Änderung, Reviewer, akzeptiertes Risiko

Portable Komponenten können einen Wechsel erleichtern. Der Aufwand hängt aber auch von Datenmengen, Schnittstellen, Lizenzen und dem Zielbetrieb ab. Vergleichen Sie einen Probelauf mit den Kosten des Weiterbetriebs, bevor Sie eine Ablösung beschließen. Eine vollständige Übertragbarkeit lässt sich aus dem Einsatz von Containern allein nicht ableiten.

Observability und Audit-Trails als Beweisquelle

Änderungsprotokolle können zeigen, wann eine Konfiguration geändert und wer dafür verantwortlich war. Für Vorfälle sollten außerdem Meldewege, Ansprechpartner und die getroffenen Maßnahmen dokumentiert sein. Git und Deployment-Protokolle liefern technische Teile davon; sie ersetzen weder die rechtliche Einordnung noch alle geforderten Nachweise. Ordnen Sie deshalb jedem benötigten Nachweis eine konkrete Quelle zu. Prüfen Sie, ob sie den fraglichen Zeitraum abdeckt und ob die zuständigen Personen sie tatsächlich abrufen können. Für personenbezogene Inhalte sind Zugriff und Aufbewahrung gesondert festzulegen.

Technische Unterstützung vereinbaren

Bei einer technischen Bestandsaufnahme lassen sich Anbieter, Zugänge, Datenflüsse und vorhandene Nachweise zusammenführen. Welche Prüfungen Planfold übernimmt und welche bei Ihrem Team oder einer rechtlichen Beratung liegen, wird im Projekt vereinbart.

Je nach vereinbartem Auftrag kann daraus eine technische Umsetzung entstehen: dokumentierte Konfigurationen, ein erprobter Wiederherstellungsweg oder eine Erinnerung an fällige Anbieterprüfungen. Für den anschließenden Betrieb muss feststehen, wer die Informationen pflegt und Änderungen bewertet. Ein neuer Anbieter, ein anderer Verarbeitungsort oder ein geänderter Supportzugang sollte Anlass sein, die betroffenen Einträge erneut durchzugehen. Umfang und Häufigkeit dieser Arbeiten gehören in die Leistungsvereinbarung.

Die Grenze bleibt klar: Planfold gibt keine Rechtsberatung, zertifiziert keine NIS2-Konformität, führt keine formalen Penetrationstests als Compliance-Ersatz durch, entscheidet nicht über die wesentliche oder wichtige Eigenschaft eines Unternehmens und garantiert keine konkrete CADA-Stufe eines Anbieters – CADA ist weiterhin ein Vorschlag. Planfold baut die Architektur-, Prozess- und Nachweisschicht, die qualifizierte Rechts-, Datenschutz- und Managemententscheidungen mit belastbaren Fakten versorgt.

Ein 30-Tage-Startplan für den Mittelstand

Ein brauchbarer Start muss klein genug sein, um wirklich zu passieren. In 30 Tagen entsteht keine vollständige Compliance, aber eine priorisierte Entscheidungsgrundlage.

In Woche 1 inventarisieren Sie die Anbieter mit Kundendaten, privilegiertem Zugriff oder kritischen Aufgaben. In Woche 2 ordnen Sie die tatsächlich geltenden gesetzlichen und vertraglichen Anforderungen zu. Notieren Sie fehlende Angaben als konkrete Rückfragen und benennen Sie die zuständige Person.

In Woche 3 sammeln Sie Nachweise und Kontakte: SLA, Sicherheitskontakt, Datenresidenz-Nachweis, Restore-Proof, Wechsel- und Exportkonditionen nach dem Data Act. Akzeptieren Sie, dass nicht alles sofort da ist – entscheidend ist, dass die Lücke sichtbar wird. In Woche 4 legen Sie den Review-Rhythmus fest: Wer prüft wann, wer entscheidet kritische Ausnahmen, wie läuft der Incident-Pfad, und ab wann übernimmt Rechtsberatung oder die nationale Stelle. Petra führt das Register, Markus die technische Evidenz, Danilo die Renewal-Verhandlungen, Andrea die Ausnahmeentscheidungen. n8n erinnert an fällige Reviews und eskaliert überfällige Nachweise.

Für die nächste Kundenfrage sollten Anforderung, Quelle, Nachweis und verantwortliche Person zusammen auffindbar sein. Vereinbaren Sie außerdem, welche Änderungen einen erneuten Review auslösen, etwa ein neuer Unterauftragnehmer oder ein anderer Verarbeitungsort.