Frist statt Firewall: Was CADA und der NIS2-Auditstichtag für den Mittelstand bedeuten

Der Fragebogen, der vor der Firewall kommt

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, in welcher EU-Souveränitätsstufe sind diese Anbieter einordenbar, 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, weiß aber nicht, welche Stufe die Anbieter erreichen könnten. 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 Souveränitätsstufen 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 illustrativ, aber der Mechanismus ist realistisch für KMU mit 10 bis 100 Mitarbeitenden. Zwei Entwicklungen laufen im Juni 2026 zusammen: eine frische EU-Cloud-Souveränitätsrichtlinie, die Anbieter auf neue Stufen legt, und steigender NIS2-Auditdruck, der Kunden, Versicherer und Prüfer dazu bringt, genau diese Fragen zu stellen. Der Fragebogen ist nicht das eigentliche Problem. Er zeigt nur, dass die Frage nach der Souveränitätsstufe der eigenen Anbieter bislang niemand gestellt hat – und dass eine einmalige Antwort innerhalb eines Quartals veraltet, wenn sie nicht Teil des Betriebs wird.

Was sich im Juni 2026 wirklich ändert

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.

Die neue EU-Cloud-Souveränitätsrichtlinie (CADA) und ihre Stufen

Am 3. Juni 2026 hat die Europäische Kommission den Entwurf des Cloud and AI Development Act (CADA) veröffentlicht, das Herzstück des EU-Tech-Sovereignty-Pakets. CADA ist ein vorgeschlagener Rechtsakt, kein geltendes Recht. Er durchläuft jetzt das ordentliche Gesetzgebungsverfahren zwischen Europäischem Parlament und Rat. Rechtsanalyse (Jones Day, Juni 2026) geht von einer angestrebten Verabschiedung gegen Ende 2027 aus, mit Beschaffungspflichten, die etwa ein Jahr nach Verabschiedung wirksam werden.

Der Kern von CADA ist ein vierstufiges Souveränitätsrahmenwerk für Anbieter, die öffentliche EU-Aufträge bedienen:

• Stufe 1: Daten werden in Infrastruktur verarbeitet und gespeichert, die in der Union steht.
• Stufe 2: Anbieter weisen Unabhängigkeit von Drittländern nach und Transparenz über ihre Software-Lieferkette.
• Stufe 3: Anbieter stehen in EU-Eigentum und -Kontrolle und erfüllen weitere Kriterien wie Personalstaatsangehörigkeit; die Kommission kann Drittland-Anbieter anerkennen.
• Stufe 4: Volle Transparenz und Kontrolle über die Software-Lieferkette ohne Einmischung eines Drittlandes.

Diese vier Stufen sind eine eigenständige CADA-Struktur. Sie lassen sich nicht mit den ENISA-EUCS-Zertifikatsstufen (Basic, Substantial, High) gleichsetzen – die EC-Seite stellt diese Abbildung nicht her. Wichtig ist auch der Anwendungsbereich: Das Rahmenwerk richtet sich an die öffentliche Beschaffung. Eine Ausweitung auf NIS2-regulierte Privatanbieter wäre nur über delegierte Rechtsakte möglich, die noch erlassen werden müssten. CADA verpflichtet also kein KMU heute zu irgendetwas – aber die Trajektorie des Rahmenwerks verändert jetzt schon, wie Anbieter positioniert und wie Kunden fragen.

Der NIS2-Auditdruck und ein industriegetrackter Stichtag

Gleichzeitig steigt die Aufsichtsdichte unter NIS2. Deutschland hat die Richtlinie über das BSI-Gesetz im Dezember 2025 umgesetzt, Österreich mit dem NISG 2026 (BGBl. I Nr. 94/2025) vom 23. Dezember 2025. Die NIS2-Seite der Europäischen Kommission bestätigt das Inkrafttreten im Januar 2023 und die Umsetzungsfrist zum 17. Oktober 2024 und vermerkt vereinfachende Änderungsvorschläge vom 20. Januar 2026.

Hier ist eine wichtige Grenze zu ziehen: Ein universal gültiger Auditstichtag 30. Juni 2026 steht weder im NIS2-Richtlinientext noch auf der NIS2-Seite der Kommission. Aufsichts- und Auditzyklen sind national und werden von den zuständigen Behörden und CSIRTs festgelegt. Das Datum 30. Juni 2026 stammt aus Branchen- und GRC-Kommentaren (Optro, März 2026; Cloud Security Alliance, Juni 2026). Der Artikel darf diesen Termin als industriegetrackten Bereitschaftsdruck nutzen – er muss ihn aber zuschreiben und Leser an ihre nationale Stelle verweisen, im deutschsprachigen Raum an das BSI bzw. die zuständige österreichische Behörde. Die Strafobergrenzen sind hingegen im Richtlinientext verankert: Gegen wesentliche Einrichtungen können nach Artikel 34 der Richtlinie (EU) 2022/2555 Geldbußen bis zu 10 Millionen Euro oder 2 Prozent des weltweiten Jahresumsatzes verhängt werden, je nachdem, welcher Wert höher ist; für wichtige Einrichtungen bis zu 7 Millionen Euro oder 1,4 Prozent. Welche Einstufung und welcher Zyklus für ein einzelnes Unternehmen gilt, bleibt eine eigene rechtliche Prüfung.

Warum dieser Stichtag den Einkauf trifft, nicht nur die IT

CADA ist öffentlich-rechtlich angelegt, aber die Frage nach der attainable Souveränitätsstufe eines Anbieters erreicht KMU über Kunden, Versicherer und Lieferketten – also über den Einkauf, nicht über das Serverzimmer. Genau deshalb ist der Stichtag eine Beschaffungs- und Vertragsfrage, bevor er eine IT-Frage ist.

Stufen entscheiden über Verträge

Die Stufen 3 und 4 setzen EU-Eigentum und -Kontrolle bzw. vollständige Lieferkettentransparenz ohne Drittland-Einmischung voraus. Für Anbieter mit Sitz außerhalb der EU, auf die das US-amerikanische CLOUD Act durchschlagen kann, sind diese Stufen strukturell schwer erreichbar – nach Jones Day hat EU-Tech-Chefin Henna Virkkunen die CLOUD-Act-Spannung ausdrücklich angesprochen. Daraus folgt eine einfache, aber oft übersehene Tatsache: Ein „Sovereign Region"-Label oder ein Zertifikat ist nicht dasselbe wie eine erreichbare Stufe 3 oder 4. Wenn ein Großkunde nach der Stufe fragt, reicht die Region nicht als Antwort.

Das verschärft sich durch die Data Act. Die Wechsel- und Portabilitätsvorschriften der Data Act sind seit dem 12. September 2025 in Kraft; Gebühren für Datenexport und Formatumwandlung sollen bis zum 12. September 2027 auf null sinken. Lock-in wird damit zu einer umkehrbaren Entscheidung statt zu einem feststehenden Zustand. Wer das heute ignoriert, baut eine Anbieterstufe in jede Verlängerung ein, die er später nicht mehr wählen kann.

Lock-in wird zur Compliance-Schuld

Die Kombination aus neuen Stufen, Data Act und NIS2-Druck macht Vendor-Lock-in zu einer latenten Compliance-Verbindlichkeit. Ein Anbieter, der die vom Kunden geforderte Stufe nicht erreichen kann, lässt sich unter Druck kurzfristig kaum austauschen – aber bei ihm zu bleiben, schreibt eine nicht konforme Beschaffung in jedes Renewal fort. Die Strafobergrenzen von bis zu 10 Millionen Euro oder 2 Prozent Umsatz für wesentliche Einrichtungen setzen den Rahmen; relevant für ein KMU ist aber häufiger der indirekte Druck: Ein größerer Kunde muss seine eigene Lieferkette erklären und reicht die Frage weiter an den kleineren Zulieferer. Selbst wer unter der NIS2-Schwelle von in der Regel 50 Mitarbeitenden oder 10 Millionen Euro Umsatz liegt, spürt die Frage über seine Auftraggeber.

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 einschätzen, welche CADA-Stufe die eigenen Cloud-Anbieter plausibel erreichen könnten. Die Stufen sind zwar an öffentliche Beschaffung gebunden und noch nicht in Kraft – die Frage der Kunden kommt trotzdem, weil deren Risikomanagement sie stellt. Wer die attainable Stufe nicht einmal schätzen kann, hat keine Grundlage für eine Renewal-Entscheidung. Das zweite Signal: Fragebögen werden jedes Mal neu erfunden. Wenn Petra für jeden Kunden eine neue Tabelle aus E-Mails und Screenshots zusammenbaut, ist das kein Effizienzproblem, sondern ein Betriebsmodell-Problem. Die Antworten sind nicht wiederholbar und veralten innerhalb eines Quartals.

Das dritte Signal: Es gibt keinen Portabilitätsplan. Wer Workloads nicht containerisiert betreibt und keine Datenexport- und Migrationspfade kennt, behandelt Lock-in als Schicksal statt als Entscheidung. Das vierte Signal: Niemand besitzt die Evidence-Pipeline. Wenn unklar ist, wer Nachweise sammelt, wer Reviews freigibt und wer bei einem Anbieterwechsel entscheidet, ist der nächste Audit ein Kaltstart. Das fünfte Signal schließlich: Rechtliches und Operatives werden vermischt. Die juristische Einordnung – wesentlich, wichtig, meldepflichtig – bleibt qualifizierter Rechtsberatung und der nationalen Stelle überlassen. Die Betriebsarbeit, die Nachweise für diese Einordnung liefert, muss aber jemand besitzen.

Vom Stichtag zum Betriebsmodell

Ein Stichtag, der einmal beantwortet wird, veraltet. Erst aus Inventar, Zuständigkeit, Review-Gates und Audit-Spur wird ein Betriebsmodell, das den nächsten Zyklus übersteht. Die konkrete Form für ein KMU ist schlank, aber sie braucht klare Eigentumsgrenzen.

Vendor-Klassifikation gegen die neuen Stufen

Der erste Schritt ist eine klassifizierte Anbieterliste – nicht nach Umsatzvolumen, sondern nach Datenklasse, Zugriffstyp, kritischem Workflow und attainable CADA-Stufe. Die Stufeneinschätzung ist ausdrücklich eine Plausibilitätsabschätzung, keine Anerkennung: Die formelle Stufenzuerkennung erfolgt nach CADA durch Mitgliedsstaaten nach Audit und steht aktuell noch aus. Für jeden Anbieter mit Kundendaten oder privilegiertem Zugriff genügt ein kaufmännischer Eigentümer nicht; Markus prüft die technische Evidenz, Petra führt das Fragebogen-Archiv, Danilo verhandelt Renewals gegen das neue Stufenbild, und Andrea entscheidet über kritische Ausnahmen.

Die Keep-Replace-Repatriate-Entscheidung

Aus der Klassifikation entsteht die strategische Entscheidung: behalten, ersetzen oder relozieren. Ein Anbieter, der die geforderte Stufe plausibel erreicht, bleibt; sein Vertrag bekommt Review- und Nachweisauflagen. Ein Anbieter, der sie nicht erreichen kann, wird ersetzt, idealerweise mit Wechselkonditionen nach der Data Act. Workloads mit hohen Daten- oder Compliance-Anforderungen können auf DACH-gehostete Infrastruktur reloziert werden. Diese Entscheidung ist nur ausführbar, wenn Workloads portabel sind – was direkt zur Architekturfrage führt.

Die Evidence-Pipeline, die den nächsten Audit übersteht

Die Pipeline macht den Unterschied zwischen einem einmaligen Snapshot und einer wiederkehrenden Fähigkeit. Ihre Elemente sind einfach: ein zentrales Anbieteregister als Quelle der Wahrheit, ein Evidence-Ordner oder Git-Repository für Nachweise, ein n8n-Workflow für Fristen, Erinnerungen und Eskalationen, ein Runbook für Anbieter-Incidents und ein Review-Gate für Managemententscheidungen. Jede kritische Ausnahme hat eine dokumentierte Entscheidung, jede fehlende Evidenz ein Datum, jeder Anbieter-Incident einen Kontaktpfad. n8n orchestriert die wiederkehrende Arbeit – Review-Erinnerungen, überfällige Nachweise, Statuslisten für den Quartalsreview –, die Entscheidung selbst bleibt menschlich. Genau das macht die Antwort auf den nächsten Fragebogen reproduzierbar statt erfunden.

Technischer Deep-Dive: Souveräne Infrastruktur als Compliance-Substrat

Die Betriebsebene, auf der eine Stufenentscheidung überhaupt ausführbar wird, ist souveräne Infrastruktur: DACH-Hosting, portable Workloads und nachvollziehbare Audit-Spuren. Ohne dieses Substrat bleibt jede Keep-Replace-Repatriate-Entscheidung theoretisch, weil ein Wechsel nicht technisch durchführbar ist.

DACH-Hosting und Kubernetes-Portabilität

Portabilität ist der technische Kern der Antwort auf Lock-in. Wer Workloads containerisiert nach Kubernetes-Standard betreibt, kann sie zwischen DACH-gehosteten Umgebungen, Sovereign-Regionen und privaten Infrastrukturen bewegen, ohne sie neu zu schreiben. Das macht eine Stufen-Downgrade überlebbar statt katastrophal: Wenn ein Anbieter die attainable Stufe verliert, kann das Workload umgezogen werden, statt dass das gesamte Renewal davon abhängt. Das funktioniert nur mit Disziplin – klare Helm-Charts oder Manifeste, kein Anbieter-spezifisches Lock-in in Storage- oder Identitätsdiensten, geplante Datenexporte und definierte Migrationspfade. CKA- und CKAD-zertifizierter Kubernetes-Betrieb ist dabei ein Fähigkeitsnachweis für diese kritische Betriebsarbeit, kein Compliance-Badge.

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
├── tier: attainable CADA-Stufe (Schätzung), Begründung, Lücken
├── 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

Der Kompromiss liegt auf der Hand: Vollständige Portabilität kostet anfangs Disziplin und Standardisierung, reduziert aber später die Migrations- und Lock-in-Kosten drastisch. Wer den Aufwand scheut, zahlt ihn bei jedem Renewal in Form einer Anbieterstufe, die er nicht mehr wählen kann.

Observability und Audit-Trails als Beweisquelle

Die zweite technische Säule sind Observability und versionierte Audit-Trails. NIS2-Artikel 21 verlangt risikobasierte Maßnahmen, Artikel 20 Führungsverantwortung, Artikel 23 Incident-Meldungen. Operativ übersetzt heißt das: Änderungen an Systemen müssen nachvollziehbar sein, Incidents müssen einen dokumentierten Pfad haben, und Reviews müssen eine Spur hinterlassen. Infrastruktur, die über Git-gesteuerte, wiederholbare Wege geändert wird – GitLab, Konfigurationsmanagement, standardisierte Deployments –, produziert genau diese Beweise als Nebenprodukt des Betriebs statt als einmaliger Audit-Aufwand. Ein supervisorischer Zyklus, der national gesteuert wird, fragt nicht nach einer Präsentation, sondern nach Nachweisen, die zu einem bestimmten Datum gültig waren. Die Audit-Spur liefert sie.

Wie Planfold den Stichtag in ein Betriebsmodell übersetzt

Planfold betrachtet den Stichtag nicht als einmalige Audit-Aufgabe, sondern als Anlass, ein Betriebsmodell aufzubauen. Die Methodik ist technisch definiert, nicht dekorativ gemeint. Plan heißt: technische Schulden, Vendor-Stufen (als Plausibilität, nicht als Anerkennung), Datenresidenz, Zugriffswege und bestehende Fragebogen-Antworten auditieren. Das Ergebnis ist eine priorisierte Anbieterkarte – was ist kritisch, was ist unklar, wer entscheidet, wo fehlt Evidenz?

Unfold heißt: Systeme bauen und integrieren. Das umfasst das souveräne Infrastruktur-Substrat – DACH-Hosting und portable Kubernetes-Workloads – sowie die Evidence-Workflows: n8n-gestützte Register- und Review-Routinen, Zugriffsprüfungen, Restore-Nachweise und Incident-Runbooks. Resonate heißt: stabiler Betrieb mit wiederkehrender Audit-Readiness. Quartalsweise Reviews, überfällige Evidenz, Anbieterwechsel, neue Automationen und Incident-Learnings fließen in das Register zurück, sodass die nächste Frage nicht aus dem Gedächtnis rekonstruiert werden muss.

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 – die Stufenzuerkennung ist nach CADA eine Mitgliedsstaaten-Entscheidung nach Audit. 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 Ihre Cloud- und Softwareanbieter: Cloud, Hosting, SaaS, MSP, Automatisierung, Backup, Payment, Telematik, Support. Markieren Sie nicht alle gleich, sondern die mit Kundendaten, privilegiertem Zugriff, kritischem Workflow oder Incident-Bedeutung. In Woche 2 schätzen Sie für die Top-Anbieter die attainable CADA-Stufe ein – klar gekennzeichnet als Schätzung, nicht als Anerkennung – und ergänzen Datenklasse, Zugriffstyp und betroffene Workflows. Fehlt etwas, gibt es keinen grünen Haken, sondern eine offene Aktion.

In Woche 3 sammeln Sie Nachweise und Kontakte: SLA, Sicherheitskontakt, Datenresidenz-Nachweis, Restore-Proof, Wechsel- und Exportkonditionen nach der 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.

Was vor dem nächsten Stichtag getan werden muss, ist nicht die Beantwortung eines einzelnen Fragebogens. Es ist die Fähigkeit, die Frage reproduzierbar zu beantworten: Welche Anbieter sind kritisch, welche Stufe könnten sie erreichen, wer besitzt die Evidenz, und welcher Workflow sorgt dafür, dass diese Antworten in drei Monaten nicht wieder verschwunden sind.

Ein Stichtag wird nicht leichter, wenn er liegen bleibt. Er wird leichter, wenn er Teil des Betriebs wird: sichtbar, zuständig, portabel und ehrlich über offene Lücken.