Compliance as Code: Policy-as-Code für Cloud-Native KMU

Hauptartikel: Compliance Tool-Stack 2026 — welche Werkzeuge KMU für DSGVO, NIS2, AI Act, HinSchG und AGG einsetzen und welche Pflicht sie jeweils abdecken.

1. Was ist Compliance-as-Code?

Compliance as Code bedeutet, Vorgaben aus Datenschutz, Sicherheit und Compliance als Code zu dokumentieren und automatisch durchzusetzen — versioniert und getestet wie Software.

Rechtlich interessant ist daran nicht das Werkzeug, sondern der Nachweis. Nach § 30 Abs. 1 BSIG müssen besonders wichtige und wichtige Einrichtungen geeignete, verhältnismäßige und wirksame technische und organisatorische Maßnahmen ergreifen; die Einhaltung ist zu dokumentieren (§ 30 Abs. 1 Satz 3 BSIG). Im Datenschutz gilt die Rechenschaftspflicht nach Art. 5 Abs. 2 DSGVO. Eine versionierte Regelbasis erzeugt einen Teil dieser Spur automatisch: wer wann welche Vorgabe geändert hat und welche Prüfung dazu lief. Alle Fundstellen zum NISG 2026 in diesem Artikel greifen mit dessen Anwendungsbeginn am 01.10.2026.

Versioniert heißt dabei (Praxis): Jede Regel liegt als Textdatei im Repository — als YAML- oder Rego-Datei —, jede Änderung durchläuft dieselbe Freigabe wie Anwendungscode, und die Historie weist Autor, Zeitpunkt und Begründung aus. In der Datei selbst stehen die Angaben, die auch der Regel-Steckbrief der Abschnitte 3 bis 5 aufführt — geprüftes Objekt, Soll-Zustand, Wirkung bei Verstoß und Fundstelle —, ergänzt um einen Bezeichner der Regel und ein Feld für die Begründung. Das ist der Teil der Spur, der ohne zusätzliche Erfassung entsteht.

Schematisch — werkzeugneutral und ohne die Syntax einer bestimmten Regelsprache — trägt die Datei damit diese Felder, hier für die Beispielregel aus Abschnitt 3:

Regel:        objektspeicher-verschlüsselung
Prüfobjekt:   Objektspeicher-Bucket
Soll-Zustand: Verschlüsselung aktiv; Ablage in einer EU-Region
Wirkung:      blockierend
Begründung:   Kryptografie und Verschlüsselung stehen im Mindestkatalog
Fundstelle:   Verschlüsselung: § 30 Abs. 2 BSIG, § 32 Abs. 4 NISG 2026
              EU-Region: Praxisempfehlung, ohne Fundstelle

2. Tools 2026

Kurzantwort: Fünf Werkzeuge stehen zur Wahl — Open Policy Agent, Terraform Sentinel, AWS Config Rules, Azure Policy und Conftest. Welches Werkzeug passt, entscheidet der vorhandene Stack; wie stark eine Regel wirkt, entscheidet ihr Einsatzort.

Praxisempfehlung (keine Rechtspflicht): Wichtiger als die Produktwahl ist, an welcher Stelle eine Regel greift. Eine Prüfung im Pull Request verhindert, dass die Abweichung überhaupt entsteht, und hinterlässt ihr Ergebnis dauerhaft an der Änderung; eine Prüfung im laufenden Betrieb erkennt sie erst danach und erzeugt einen datierten Abweichungsbericht. Beide Ergebnisse eignen sich in der Praxis als Material für die Dokumentation; die Pflicht selbst knüpft an die Maßnahmen nach § 30 Abs. 1 und 2 BSIG an, nicht an ein Produkt (§ 30 Abs. 1 Satz 3 BSIG). Welcher Einsatzort für eine konkrete Regel passt, steht im Regel-Steckbrief der Abschnitte 3 bis 5.

Für die Wirkung einer Regel hat sich bewährt: Blockierend setzen, was im gesetzlichen Mindestkatalog eindeutig benannt und technisch eindeutig prüfbar ist — etwa Verschlüsselung, Zugriffskontrolle und Multi-Faktor-Authentifizierung (vollständiger Katalog in Abschnitt 3). Nur warnend setzen, was eine Abwägung voraussetzt. Jede blockierende Regel braucht einen dokumentierten Ausnahmeweg samt Zuständigkeit, sonst wird sie im Ernstfall umgangen statt angewendet. Bewährt hat sich, jede Ausnahme auf 30 Tage zu befristen: Die Verlängerung braucht eine erneute Freigabe derselben Rolle, andernfalls greift die Regel nach Ablauf automatisch wieder.

3. Regelbeispiel Cloud-Speicher: Verschlüsselung und Speicherort erzwingen

Eine typische OPA-Regel lautet: Alle S3-Buckets müssen verschlüsselt sein und in einer EU-Region liegen. Im Pull Request läuft der Test automatisch, beim Deployment blockiert die Regel die Abweichung.

Verschlüsselung ist dabei keine Hausregel, sondern Teil des gesetzlichen Mindestkatalogs der Risikomanagement-Maßnahmen. § 30 Abs. 2 Nr. 1 bis 10 BSIG (Deutschland), § 32 Abs. 4 lit. a bis j NISG 2026 (Österreich) und Art. 21 Abs. 2 der Richtlinie (EU) 2022/2555 verlangen mindestens die folgenden zehn Bereiche:

Für personenbezogene Daten verlangt Art. 32 DSGVO technische und organisatorische Maßnahmen, die Verfügbarkeit, Integrität und Vertraulichkeit sichern.

Die zweite Hälfte der Beispielregel — Speicherung in einer EU-Region — ist eine Praxisempfehlung und keine im Mindestkatalog benannte Pflicht. Bevor Sie eine Regel auf Regionen festlegen, klären Sie die Anforderungen an Übermittlungen in Drittländer gesondert — die Regel setzt die Entscheidung nur durch, sie ersetzt sie nicht.

Im Schadensfall wird der Unterschied greifbar: Nach Art. 34 Abs. 3 DSGVO ist die Benachrichtigung der betroffenen Personen unter anderem dann nicht erforderlich, wenn geeignete technische und organisatorische Schutzmaßnahmen — insbesondere Verschlüsselung — angewandt wurden. Eine Regel, die unverschlüsselte Speicher blockiert, wirkt damit auf eine Rechtsfolge. Die Meldung an die Aufsichtsbehörde nach Art. 33 Abs. 1 DSGVO (unverzüglich, möglichst binnen 72 Stunden) bleibt davon unberührt; sie entfällt nur, wenn die Verletzung voraussichtlich nicht zu einem Risiko für die Rechte und Freiheiten natürlicher Personen führt.

4. Regelbeispiel Zugriff: MFA, Bastion-Host und Freigabe-Workflow

Eine zweite Regel begrenzt den Produktionszugang: Er ist nur über Multi-Faktor-Authentifizierung, einen Bastion-Host und einen Freigabe-Workflow möglich, und die Regel setzt das automatisch durch.

Praxis: Bastion-Host heißt als Soll-Zustand dieser Regel ein einziger gehärteter Zugangspunkt — alle übrigen Zugangswege in die Produktionsumgebung bleiben netzseitig geschlossen. Daraus folgt ein einfach prüfbares Kriterium: Außerhalb dieses Punktes existiert kein direkter Zugang zur Produktionsumgebung. Den Nachweis trägt der Freigabe-Workflow, weil er eine datierte, personenbezogene Entscheidung erzeugt. Die drei im Steckbrief genannten Protokollarten getrennt zu führen, hat sich bewährt: Sie beantworten drei verschiedene Fragen — wer erhöhte Rechte genutzt hat, was an der Konfiguration geändert wurde und wer sich erfolglos anzumelden versucht hat. Der vollständige gesetzliche Mindestkatalog steht in Abschnitt 3.

5. Regelbeispiel Datenschutz: Was ein PII-Fund im Repository auslöst

Ein Pre-Commit-Hook prüft den Code vor der Übernahme auf personenbezogene Daten (PII, Personally Identifiable Information) und blockiert den Commit bei einem Fund.

Ein Scanner findet Muster, keine Rechtsgrundlage. Ob eine Verarbeitung zulässig ist, entscheidet Art. 6 Abs. 1 DSGVO: rechtmäßig ist sie nur, wenn mindestens einer der sechs Erlaubnistatbestände erfüllt ist — Einwilligung, Vertrag, rechtliche Verpflichtung, lebenswichtige Interessen, öffentliches Interesse oder berechtigtes Interesse. Für besondere Kategorien, etwa Gesundheitsdaten oder biometrische Daten zur eindeutigen Identifizierung, gilt nach Art. 9 Abs. 1 DSGVO ein grundsätzliches Verarbeitungsverbot mit engen Ausnahmen nach Abs. 2. Ein Fund im Repository ist deshalb ein Prüfanlass, kein Urteil.

Praxisempfehlung (keine Rechtspflicht) für die Triage nach einem Fund, in drei Schritten: Erstens Verarbeitungszweck und Rechtsgrundlage nach Art. 6 Abs. 1 DSGVO benennen. Zweitens prüfen, ob eine besondere Kategorie nach Art. 9 Abs. 1 DSGVO betroffen ist — dann greift das Verarbeitungsverbot, und es ist die Ausnahmeprüfung nach Art. 9 Abs. 2 DSGVO zu dokumentieren. Drittens bei voraussichtlich hohem Risiko — insbesondere bei Verwendung neuer Technologien — die Datenschutz-Folgenabschätzung nach Art. 35 Abs. 1 DSGVO anstoßen, bevor die Verarbeitung beginnt.

Technisch gut stützen lassen sich zwei Punkte: Beruht die Verarbeitung auf einer Einwilligung, muss der Verantwortliche nachweisen können, dass eingewilligt wurde (Art. 7 Abs. 1 DSGVO), und der Widerruf muss so einfach sein wie die Erteilung (Art. 7 Abs. 3 DSGVO). Die Integration der Datenschutz-Folgenabschätzung in Code-Reviews setzt an Art. 35 DSGVO an. Art. 35 Abs. 3 DSGVO nennt als weitere Auslöser für die in Schritt 3 genannte Abschätzung die systematische umfassende Bewertung persönlicher Aspekte mit Rechtswirkung (Profiling), die umfangreiche Verarbeitung besonderer Datenkategorien nach Art. 9 DSGVO und die systematische umfangreiche Überwachung öffentlich zugänglicher Bereiche. Trifft im Review einer dieser Punkte zu, ist das der Anlass, die Abschätzung zu starten.

Praxis, wie daraus ein Prozessschritt wird: Die Vorprüfung gehört als fester Punkt in die Vorlage des Pull Requests — die drei Auslöser des Art. 35 Abs. 3 DSGVO als Ankreuzfelder. Aufgesetzt wird sie von der Entwicklungsrolle, entschieden von der oder dem Datenschutzbeauftragten, sonst von der benannten Datenschutz-Rolle. Ergebnis ist ein datierter Vermerk am Pull Request, entweder „keine Datenschutz-Folgenabschätzung erforderlich“ mit Begründung oder „Abschätzung angestoßen“; dieser Vermerk ist zugleich Material für die Rechenschaft nach Art. 5 Abs. 2 DSGVO.

6. KMU-Reifegrad — und warum er die Pflichtenlage nicht ändert

Der Reifegrad des Werkzeugkastens entscheidet nicht darüber, ob Pflichten bestehen — er beeinflusst nur, wie aufwendig ihr Nachweis ist. Drei Stufen sind gebräuchlich; die Zuordnung ist eine Praxisempfehlung (keine Rechtspflicht):

• Stufe 1 — ein einzelner Cloud-Anbieter: die Regelmechanik dieses Anbieters (Abschnitt 2: AWS Config Rules bei AWS, Azure Policy bei Azure). Solange Infrastruktur über die Konsole geändert wird, entsteht der Beleg erst nachträglich, als datierter Abweichungsbericht. Zu Stufe 2 wechseln Sie, sobald Infrastruktur nicht mehr in der Konsole, sondern als Code geändert wird.
• Stufe 2 — Infrastruktur wird als Code verwaltet: OPA und Terraform Sentinel, ergänzt um Conftest als Testschritt in der Pipeline. Jetzt entsteht der Beleg als Prüfergebnis am Pull Request, also bevor die Abweichung wirksam wird. Zu Stufe 3 wechseln Sie, sobald mehr als ein Konto oder Anbieter dieselbe Vorgabe erfüllen muss.
• Stufe 3 — Regeln sollen über mehrere Konten oder Anbieter hinweg gelten: eigene Policies und eine Drift-Erkennung, die Abweichungen vom Soll-Zustand im laufenden Betrieb meldet. Erreicht ist diese Stufe, wenn eine Vorgabe einmal zentral definiert und in jedem Konto geprüft wird; der Beleg dafür erscheint datiert im Prüfprotokoll.

Maßgeblich für die Pflichtenlage ist in Deutschland § 28 BSIG: Als besonders wichtige Einrichtung gilt eine sonstige Einrichtung einer in Anlage 1 bestimmten Art, wenn sie mindestens 250 Mitarbeiter beschäftigt oder einen Jahresumsatz von über 50 Mio. EUR und zudem eine Jahresbilanzsumme von über 43 Mio. EUR aufweist. Als wichtige Einrichtung gilt eine Einrichtung einer in Anlage 1 oder 2 bestimmten Art mit mindestens 50 Mitarbeitern oder einem Jahresumsatz und einer Jahresbilanzsumme von jeweils über 10 Mio. EUR, soweit sie nicht bereits besonders wichtige Einrichtung ist. Ohne Zuordnung zu einer Anlagen-Art greift diese Größeneinstufung nicht; unabhängig von diesen Größenkennzahlen erfasst § 28 BSIG unter anderem qualifizierte Vertrauensdiensteanbieter, Top-Level-Domain-Name-Registries und DNS-Diensteanbieter. Betreiber kritischer Anlagen gelten nach § 28 Abs. 1 BSIG gesondert als besonders wichtige Einrichtung.

In Österreich läuft die Einstufung über §§ 24 und 25 NISG 2026 mit denselben Größenkennzahlen: großes Unternehmen ab 250 Mitarbeitern oder über 50 Mio. EUR Umsatz und über 43 Mio. EUR Bilanzsumme, mittleres Unternehmen ab 50 Mitarbeitern oder über 10 Mio. EUR Umsatz und über 10 Mio. EUR Bilanzsumme.

7. Welche Pflichten sich als Regel abbilden lassen — und welche nicht

Kurzantwort: Automatisieren lässt sich der Zustand, nicht die Beurteilung. Regeln prüfen, ob eine Maßnahme technisch wirkt, und erzeugen den Beleg dafür; ob eine Pflicht erfüllt, ein Vorfall „erheblich“ und eine Meldung fällig ist, entscheiden Menschen.

Jede Fundstelle in der Tabelle ist mit dem Rechtsraum gekennzeichnet (DE, AT oder EU). Die beiden rechten Spalten sind Praxiseinschätzung; die dort genannten Fundstellen benennen lediglich die jeweils einschlägige Norm.

Die Meldestufen der Zeile „Meldung erheblicher Sicherheitsvorfälle“ im Einzelnen (DE: § 32 Abs. 1 Nr. 1 bis 4 BSIG, AT: § 34 Abs. 2 Z 1 bis 5 NISG 2026):

• Stufe 1 — unverzüglich, spätestens binnen 24 Stunden nach Kenntnis vom Vorfall: frühe Erstmeldung, in Österreich Frühwarnung.
• Stufe 2 — unverzüglich, spätestens binnen 72 Stunden: Meldung mit Erstbewertung; Art. 23 Abs. 4 Buchst. b der Richtlinie (EU) 2022/2555 nennt dafür Schweregrad, Auswirkungen und gegebenenfalls Kompromittierungsindikatoren.
• Auf Ersuchen: Zwischenmeldung beziehungsweise Zwischenbericht.
• Stufe 3 — spätestens einen Monat nach der 72-Stunden-Meldung: Abschlussmeldung. Dauert der Vorfall noch an, ist zunächst eine Fortschrittsmeldung zu übermitteln; die Abschlussmeldung folgt nach abschließender Bearbeitung.

Empfänger ist in Deutschland die gemeinsame Meldestelle von BSI und BBK, in Österreich das zuständige — sektorspezifische beziehungsweise nationale — CSIRT.

Zur Zeile „Registrierung bei der Behörde“ im Einzelnen: In Österreich läuft die Drei-Monats-Frist zusätzlich ab Inkrafttreten des NISG 2026. Änderungen der Stammdaten sind in Deutschland grundsätzlich unverzüglich, spätestens binnen zwei Wochen zu melden (§ 33 Abs. 5 BSIG), in Österreich binnen zwei Wochen für die Kerndaten nach § 29 Abs. 2 Z 1 bis 5 NISG 2026. Für Einrichtungen, die in Deutschland bereits seit dem Inkrafttreten des BSIG am 06.12.2025 als besonders wichtige oder wichtige Einrichtung gelten, ist die Drei-Monats-Frist des § 33 Abs. 1 BSIG abgelaufen; das BSI weist darauf hin, dass die gesetzliche Registrierungsfrist bereits abgelaufen ist (Abschnitt 10).

8. Audit-Trail: was der Nachweis tragen muss

Kurzantwort: Ohne Audit-Trail bleibt eine bestandene CI-Prüfung eine flüchtige Konsolenausgabe — erst die Protokollierung macht sie zum Beleg.

Mindestfelder je Eintrag: Zeitstempel (UTC), User-ID, Aktion (Read/Write/Delete), betroffener Datensatz als Hash, Ergebnis (success/fail), IP-Adresse. Reproduzierbarkeit heißt hier: Dieselbe Regelversion erzeugt gegen denselben Zustand dasselbe Prüfergebnis — deshalb bleibt ein Prüfprotokoll auch Monate später nachvollziehbar. Diese Angaben sind Praxis, keine gesetzlichen Pflichtfelder. Umgekehrt gilt: Mit User-ID und IP-Adresse verarbeitet das Protokoll selbst personenbezogene Daten — behandeln Sie es deshalb wie jede andere Verarbeitung personenbezogener Daten, einschließlich Aufnahme in das Verzeichnis der Verarbeitungstätigkeiten, soweit Sie ein solches zu führen haben.

Für die Manipulationssicherheit haben sich hashbasierte Logs (HMAC), Append-only-Speicherung und WORM-Storage bewährt; unveränderliche Logs haben den höheren Beweiswert, Hash-Chains und Time-Stamping erhöhen ihn weiter. Gestaffelt heißt das: Das Minimum ist die Append-only-Speicherung, damit Einträge nicht nachträglich geändert werden können. Die nächste Stufe ist die Hash-Verkettung, wenn die Protokolle gegenüber Dritten Bestand haben sollen. WORM-Speicherung und Time-Stamping lohnen den Aufwand, sobald ein Nachweis ansteht — in Deutschland nach § 39 Abs. 1 BSIG nur für Betreiber kritischer Anlagen, in Österreich nach § 33 NISG 2026 für alle wesentlichen und wichtigen Einrichtungen; die Zyklen dazu stehen im nächsten Absatz.

Aufbewahrung: Weder die Richtlinie (EU) 2022/2555 noch das BSIG noch das NISG 2026 schreiben Log-Aufbewahrungsfristen vor — 90 Tage operativ plus 12 Monate Archiv sind ein Praxiswert. Weil das Protokoll personenbezogene Daten enthält, dokumentieren Sie diese Werte als Löschfrist, nicht nur als Vorhaltezeit. Gesetzlich verlangt ist die Dokumentation der Einhaltung (§ 30 Abs. 1 Satz 3 BSIG). Einen festen Zyklus gibt es in Deutschland nur für Betreiber kritischer Anlagen: Nachweis durch Sicherheitsaudits, Prüfungen oder Zertifizierungen frühestens drei Jahre nach der erstmaligen Einstufung und anschließend alle drei Jahre (§ 39 Abs. 1 BSIG). In Österreich gilt stattdessen § 33 NISG 2026: strukturierte Selbstdeklaration binnen zwölf Monaten nach Eintritt der Registrierungspflicht und — auf Aufforderung — Nachweis durch eine unabhängige Stelle binnen zwei Jahren; wesentliche Einrichtungen müssen die operative und organisatorische Umsetzung bereits binnen zwei Monaten nach Aufforderung nachweisen. In Deutschland bleiben handels- und steuerrechtliche Fristen unberührt: je nach Dokumententyp sechs Jahre nach § 257 HGB oder zehn Jahre nach § 147 AO.

9. In welcher Reihenfolge KMU einsteigen

Kurzantwort: Der erste Schritt ist keine Regel, sondern die Klärung der Betroffenheit — ohne sie ist unklar, welche Pflichten überhaupt abzubilden sind. Die folgende Reihenfolge ist eine Praxisempfehlung (keine Rechtspflicht); die genannten Fundstellen benennen die jeweilige Pflicht, nicht den Weg dorthin.

1. Betroffenheit klären — Geschäftsleitung. Prüfen, ob die Einrichtung einer Art nach Anlage 1 oder 2 zuzuordnen ist und die Größenkennzahlen erfüllt: § 28 BSIG in Deutschland, §§ 24 und 25 NISG 2026 in Österreich.
2. Registrierung prüfen und gegebenenfalls nachholen — Geschäftsleitung. Prüfen, ob registriert wurde, und Versäumtes unverzüglich nachholen: § 33 Abs. 1 BSIG über die gemeinsam von BSI und BBK eingerichtete Registrierungsmöglichkeit, § 29 NISG 2026 bei der Cybersicherheitsbehörde. Änderungsfristen der Stammdaten in Abschnitt 7.
3. Erste Regel dort setzen, wo der Mindestkatalog technisch greift — IT-Betrieb. Kryptografie, Zugriffskontrolle und Multi-Faktor-Authentifizierung nach § 30 Abs. 2 BSIG beziehungsweise § 32 Abs. 4 NISG 2026 lassen sich als Soll-Zustand formulieren und automatisch prüfen.
4. Prüfergebnisse protokollieren — IT-Betrieb, bei personenbezogenen Daten gemeinsam mit der oder dem Datenschutzbeauftragten. Die Protokolle sind Material für die Dokumentation der Einhaltung nach § 30 Abs. 1 Satz 3 BSIG und für die Rechenschaft nach Art. 5 Abs. 2 DSGVO.
5. Meldeweg und Einstufungsentscheidung als menschlichen Prozess festlegen — Geschäftsleitung. Festhalten, wer entscheidet, ob ein Vorfall erheblich ist (§ 2 Nr. 11 BSIG, § 35 Abs. 1 NISG 2026), und wer die Meldung nach § 32 BSIG beziehungsweise § 34 NISG 2026 absetzt — festgelegt, bevor der erste Vorfall eintritt.

10. Grenzen: was Policy-as-Code nicht abnimmt

Kurzantwort: die Verantwortung. In Deutschland müssen Geschäftsleitungen besonders wichtiger und wichtiger Einrichtungen die Risikomanagement-Maßnahmen nach § 30 BSIG umsetzen und ihre Umsetzung überwachen (§ 38 Abs. 1 BSIG); verletzen sie diese Pflichten, haften sie ihrer Einrichtung für schuldhaft verursachten Schaden nach den Regeln des für die Rechtsform geltenden Gesellschaftsrechts (§ 38 Abs. 2 BSIG), und sie müssen regelmäßig an Schulungen teilnehmen (§ 38 Abs. 3 BSIG). In Österreich haben die Leitungsorgane die Einhaltung der Maßnahmen nach § 32 NISG 2026 sicherzustellen und zu beaufsichtigen sowie an Cybersicherheitsschulungen teilzunehmen (§ 31 NISG 2026); eine ausdrückliche Innenhaftungsnorm wie § 38 Abs. 2 BSIG enthält das NISG 2026 nicht — die Haftung folgt dort aus dem allgemeinen Gesellschaftsrecht.

Zweitens erledigt keine Pipeline eine Anmeldung bei einer Behörde. Die Registrierung beim BSI ist nach § 33 Abs. 1 BSIG spätestens drei Monate nach Eintritt der Einrichtungseigenschaft vorzunehmen; das BSI weist darauf hin, dass die gesetzliche Registrierungsfrist bereits abgelaufen ist. Ein amtliches Datum für den Beginn der Aufsichts- und Bußgeldpraxis liegt nicht vor. Wer die Registrierung versäumt hat, holt sie unverzüglich nach — sie ist Voraussetzung für die weiteren Schritte. Für Einrichtungen, die erst später erstmals als besonders wichtige oder wichtige Einrichtung gelten, läuft die Drei-Monats-Frist des § 33 Abs. 1 BSIG. Und drittens bleibt die Abwägung: § 30 Abs. 1 BSIG verlangt geeignete, verhältnismäßige und wirksame Maßnahmen. Was im konkreten Betrieb verhältnismäßig ist, lässt sich nicht als Regel hinterlegen — es muss begründet und dokumentiert werden.