8 Min. Lesezeit

Eine interne Entwicklerplattform fällt in einem Audit selten am Code. Sie fällt am Nachweis. Wer bei einer NIS2-Prüfung zeigen muss, dass jedes Deployment Verschlüsselung, Region und Zugriff dokumentiert hat, sucht plötzlich nicht in Repositories, sondern auf der Plattform. Genau dort entscheidet sich, ob Compliance ein Dauerprojekt bleibt oder zu einer Konfiguration wird, die jedes Team mitnimmt, ohne es zu merken.

Das Wichtigste in Kürze

• Die Plattform wird zum Compliance-Hebel: Verschlüsselung, Tagging, erlaubte Regionen und Audit-Trail lassen sich an einer Stelle erzwingen statt in vierzig Repositories einzeln.
• Policy-as-Code ersetzt Excel-Checklisten: OPA Gatekeeper und Kyverno prüfen Konfigurationen automatisiert gegen NIS2-, DORA- und EU-AI-Act-Vorgaben, bevor Code in Produktion läuft.
• Das Plattform-Team wird prüfungsrelevant: Wer die Guardrails kontrolliert, kontrolliert die Compliance-Lage. Auditoren fragen ab 2026 zuerst dort, nicht mehr im einzelnen Service-Team.

Verwandt:Platform Engineering ist kein DevEx-Projekt mehr  /  Plattform oder Fassade?

Warum Compliance jetzt auf der Plattform landet

Was bedeutet Platform Engineering für Compliance? Es ist die Disziplin, regulatorische Anforderungen wie NIS2, DORA oder den EU AI Act nicht mehr pro Service zu prüfen, sondern als Voreinstellung in die interne Entwicklerplattform zu verlegen. Verschlüsselung, Logging, Zugriffsrechte und Region sind keine Empfehlungen mehr, sondern Bedingungen, die ein Deployment erst gar nicht überspringen kann.

Drei Regelwerke laufen gerade ineinander. NIS2 weitet den Kreis der pflichtigen Branchen drastisch aus und stellt Risikomanagement, Logging und Vorfallmeldung auf Vorstandsverantwortung. DORA ist seit Januar 2025 für den Finanzsektor scharf und verlangt nicht nur eigene Resilienz, sondern Aufsicht über kritische Drittanbieter. Der EU AI Act zieht ab August 2026 Dokumentations- und Nachweispflichten für Hochrisiko-Systeme an. Drei Pflichten, drei Fristen, drei Auditpfade. Wer das pro Repository löst, kommt nicht mehr nach.

Genau hier hat sich die interne Plattform in den letzten zwölf Monaten vom Komfort-Layer zum natürlichen Ort für Guardrails entwickelt. Wenn ohnehin jedes Deployment durch sie hindurchgeht, ist sie der einzige Punkt, an dem sich Regeln zentral durchsetzen lassen. Diese Zentralität ist Vorteil und Bürde zugleich.

Diese Gleichzeitigkeit ist der entscheidende Punkt. Eine Plattform, die als reines Entwickler-Komfort-Tool gebaut wurde, trifft 2026 auf eine Prüfungspraxis, die sie nicht eingeplant hat. Wer die Compliance-Funktion nachträglich an einer reifen Plattform vorbeibaut, riskiert genau die Insellösungen, die die Plattform eigentlich abschaffen sollte.

Was die Plattform automatisch erzwingen kann

Der praktische Hebel heisst Policy-as-Code. OPA Gatekeeper und Kyverno sind die zwei dominanten Engines im Kubernetes-Umfeld. Beide prüfen Ressourcen-Definitionen gegen deklarierte Regeln, bevor sie in den Cluster gelangen. Was als Policy formuliert ist, gilt automatisch für jeden, der über die Plattform deployt.

Eine pragmatische Einführung beginnt nicht mit dem Vollzug, sondern mit Sichtbarkeit. Erst Audit-Mode, dann Enforce. Die Erfahrung mehrerer Plattform-Teams im DACH-Raum: Wer Policies sofort blockierend ausrollt, erntet Workarounds. Wer sie zwei bis drei Wochen im Warn-Mode laufen lässt, bekommt eine reale Liste der Stellen, an denen die Realität von der Regel abweicht. Diese Liste ist mehr wert als jedes Audit-Protokoll.

Was sich an einer Plattform sinnvoll erzwingen lässt, hat sich in der Praxis auf eine überschaubare Liste eingependelt.

Keine dieser vier Guardrails ist technisch besonders anspruchsvoll. Der schwierige Teil ist organisatorisch. Eine Regel, die ein Team blockiert, braucht einen Eskalationspfad, eine dokumentierte Ausnahme und eine zuständige Person. Sonst entsteht aus jeder neuen Policy ein Schatten-Workflow, der die Plattform genau dort umgeht, wo sie eigentlich greifen soll.

Wo Teams bei der Compliance-Plattform scheitern

Die häufigsten Fehler sind nicht in der Policy-Engine, sondern im Betriebsmodell.

Der Unterschied zwischen den beiden Spalten ist selten ein Werkzeug. Er ist eine Entscheidung über Verantwortung. Wer Policy-as-Code einführt, ohne die Frage zu klären, wer im Konfliktfall die Ausnahme zeichnet, baut eine technische Schicht ohne organisatorische Deckung.

Wer am Ende prüfungsrelevant wird

Sobald die Plattform Regeln durchsetzt, die ein Auditor sehen will, ist das Plattform-Team Teil der Compliance-Organisation. Es muss Auskunft geben können, welche Policies seit wann gelten, welche Ausnahmen erteilt wurden, welche Verstöße aufgefallen sind und wie sie behandelt wurden. Das ist eine andere Rolle als die des Dienstleisters, der eine Entwickler-Erfahrung pflegt.

Diese Verschiebung hat zwei Konsequenzen. Erstens braucht das Plattform-Team eine Linie ins Compliance- und Datenschutz-Team, die nicht ad hoc entsteht, sondern eingespielt ist. Zweitens wandert ein Teil der Vorstandsverantwortung für NIS2-Risikomanagement und DORA-Resilienz strukturell auf die Schultern, die die Guardrails kontrollieren. Das ist keine Karriere-Strafe, sondern die ehrliche Anerkennung dessen, was eine reife Plattform tatsächlich tut.

Wer die Plattform 2026 noch als Komfort-Layer behandelt, riskiert nicht nur den nächsten Audit. Er verschenkt den vielleicht grössten Hebel, den interne Plattformen jemals hatten: aus drei überlappenden EU-Regelwerken nicht drei Projekte zu machen, sondern eine Konfiguration.

Häufige Fragen

Was unterscheidet Platform Engineering für Compliance von klassischem GRC-Tooling?

GRC-Werkzeuge dokumentieren Regeln. Eine Compliance-Plattform setzt sie durch. Der Unterschied zeigt sich im Audit: GRC liefert Listen, was gelten sollte. Policy-as-Code auf der Plattform liefert Logs, was tatsächlich passiert ist und was im Konfliktfall blockiert wurde. Beide Schichten ergänzen sich, ersetzen einander aber nicht.

Welche Policy-Engine eignet sich für den Einstieg, OPA oder Kyverno?

Beide sind etabliert. Kyverno hat eine flachere Lernkurve, weil Policies in YAML formuliert werden und nahe an Kubernetes-Manifesten bleiben. OPA Gatekeeper ist mit Rego mächtiger und passt besser, wenn auch Cloud-Ressourcen und externe Systeme geprüft werden sollen. Viele Plattform-Teams kombinieren beide nach Anwendungsfall.

Wie verhindert man, dass Teams an einer strengen Plattform vorbei deployen?

Drei Maßnahmen helfen. Erstens: Eskalationsweg mit fester Person, die Ausnahmen mit Frist und Begründung gewährt. Zweitens: Audit-Mode vor Enforce, damit Teams die neue Regel verstehen, bevor sie sie blockiert. Drittens: Telemetrie auf Bypass-Versuche, damit Schatten-Pipelines früh sichtbar werden.

Reicht eine Compliance-Plattform für NIS2 allein aus?

Nein. NIS2 verlangt Risikomanagement, Vorfallmeldung und Geschäftsführungsverantwortung. Die Plattform deckt den technischen Teil ab und liefert die Evidenz. Prozesse, Verantwortlichkeiten und Meldewege bleiben in der Organisation. Die Plattform macht die Nachweispflicht aber von einem manuellen Sammeln zu einer Abfrage.

Ab welcher Unternehmensgrösse lohnt sich eine Compliance-Plattform?

Die Schwelle liegt weniger bei Mitarbeiterzahl als bei der Anzahl produktiver Workloads. Sobald mehrere Teams parallel deployen und dieselben Regeln auf jeden Service angewendet werden müssen, ist der manuelle Pfad teurer als eine zentrale Plattform. Bei zwei oder drei Services genügt eine Checkliste, bei zwanzig nicht mehr.

Lesetipps der Redaktion

• Platform Engineering ist kein DevEx-Projekt mehr
• Plattform oder Fassade? Platform Engineering ehrlich
• Die Inferenz-Rechnung, die niemand budgetiert hat

Quelle Titelbild: Pexels / Markus Spiske (px:6190327)