Vor zehn Jahren klang der Satz „Infrastruktur ist Code" für viele IT-Leiter noch nach Marketing. Heute ist er Standard. Niemand baut mehr produktive Umgebungen per Hand zusammen, dokumentiert sie in einem Word-Dokument und hofft, dass die Dokumentation zur Realität passt. Infrastructure-as-Code (IaC) hat das Verhältnis zwischen Beschreibung und System umgedreht: Die Beschreibung ist das System. Ein Terraform-Manifest ist nicht Dokumentation über die Infrastruktur, es ist die Infrastruktur.
Compliance steht heute genau dort, wo Infrastruktur 2012 stand. Executable Compliance bezeichnet genau diesen Wandel: Kontrollen werden nicht mehr beschrieben, sondern als ausführbare, versionierbare und prüfbare Artefakte verwaltet – Compliance as Code statt Compliance als Aktenordner. Genau auf dieser Idee basiert BAM: Compliance-Artefakte werden nicht dokumentiert, sondern als ausführbare, versionierbare Objekte verwaltet, gegen den realen Systemzustand geprüft statt nur behauptet.
Außerhalb von BAM zeigt bereits ein Werkzeug, wie dieser Übergang technisch konkret aussieht: Open Policy Agent (OPA), seit 2021 ein Graduated Project der Cloud Native Computing Foundation. Laut CNCF-Umfragen wird OPA heute in der überwiegenden Mehrheit der befragten Organisationen von Entwicklung bis Produktion eingesetzt. Produktiv im Einsatz unter anderem bei Goldman Sachs, Netflix, Pinterest und T-Mobile. Das ist kein Nischenwerkzeug für Enthusiasten mehr, das ist gelebte Praxis in regulierten Branchen.
Das alte Modell: Compliance als Behauptung
In den meisten Unternehmen existiert Compliance als eine Sammlung von Behauptungen. Ein Richtlinien-PDF behauptet, Zugriffe würden nach dem Least-Privilege-Prinzip vergeben. Ein Audit-Bericht behauptet, diese Richtlinie sei im vergangenen Quartal eingehalten worden. Eine Exceltabelle behauptet, welche Maßnahmen aus ISO 27001 Annex A bereits umgesetzt sind.
Zwischen Behauptung und Realität liegt keine erzwingende Verbindung. Die Richtlinie kann aktuell sein, während die Systeme längst abgewichen sind – Konfigurationsdrift, nur im Compliance-Kontext statt im Infrastruktur-Kontext. Was das in Euro bedeutet, zeigt ein Blick auf reale ISO-27001-Projekte: Nach Erfahrungswerten von Beratungen und ISMS-Dienstleistern liegen die Gesamtkosten im ersten Jahr für ein KMU mit 50 bis 250 Mitarbeitenden typischerweise zwischen 37.000 und 80.000 Euro, mit Audit-Kosten allein in der Größenordnung von 6.000 bis 60.000 Euro – die Spannen variieren je nach Anbieter und Branche erheblich. Der größte Kostentreiber ist dabei nach übereinstimmender Beobachtung mehrerer Marktstudien meist nicht das externe Audit, sondern der interne Personalaufwand für die Rekonstruktion des Ist-Zustands: Ein ISMS-Projektleiter bindet über sechs bis zwölf Monate häufig 40 bis 60 Prozent seiner Arbeitszeit. Ein Audit wird damit faktisch zu einem Archäologie-Projekt: Wochen vor dem Termin wird zusammengetragen, was eigentlich längst hätte vorliegen müssen.
Die Übersetzung: vier Eigenschaften, ein Prinzip
IaC hat sich nicht durch ein einzelnes Feature durchgesetzt, sondern durch vier Eigenschaften, die zusammen ein neues Paradigma bilden. Sie lassen sich auf Compliance übertragen – nicht als Metapher, sondern als technisch konkrete Übersetzung.
Versionierbar. Eine Terraform-Datei liegt in Git, mit vollständiger Commit-Historie. Bei Executable Compliance gilt dasselbe für Kontrollen: Eine Maßnahme aus ISO 27001 oder NIS-2 liegt nicht als Status in einer Tabelle vor, sondern als versioniertes Artefakt. In BAM heißt dieses Artefakt schlicht „Objekt" – eine einzelne Kontrolle mit Zustand, Nachweis und Historie. Wenn sich eine Anforderung ändert, zum Beispiel weil eine neue BSI-Auslegung zur NIS-2-Meldepflicht erscheint, ist im Commit-Log nachvollziehbar, wer die Kontrolle wann angepasst hat – ohne Rückfrage beim Kollegen, der die Änderung vielleicht selbst nicht mehr erinnert.
Testbar. Ein terraform plan zeigt vor jeder Anwendung, was sich ändern würde. Bei Policy-as-Code-Werkzeugen wie OPA ist das Pendant eine in Rego geschriebene Regel, die sich gegen den tatsächlichen Systemzustand prüfen lässt. Ein verkürztes Beispiel, das prüft, ob ein S3-Bucket öffentlichen Zugriff verbietet – eine Anforderung, die in praktisch jedem ISO-27001- und NIS-2-Kontrollkatalog auftaucht:
deny[msg] {
input.resource.acl == "public-read"
msg := "Verstößt gegen A.8.12 (Datenleckage-Prävention)"
}Diese wenigen Zeilen Code verhindern automatisch, dass Cloud-Ressourcen mit öffentlichem Zugriff bereitgestellt werden. Die Kontrolle wird damit nicht dokumentiert, sondern technisch durchgesetzt. Diese Regel läuft nicht einmal jährlich bei einem externen Auditor, sie läuft bei jedem Deployment. Genau das ist der Unterschied zwischen einer Behauptung und einem Test, und genau das macht aus Compliance-Automatisierung im engeren technischen Sinn Audit-Automatisierung im weiteren betrieblichen Sinn.
Deploybar. Eine Kontrolle, die nur auf Papier existiert, hat keinen Effekt. Eine Kontrolle, die als Code vorliegt, kann direkt durchgesetzt werden – als Policy-Check in der CI/CD-Pipeline, als Gate, das einen Merge blockiert, wenn eine sicherheitsrelevante Anforderung verletzt wird. Genau diesen Mechanismus nutzt Goldman Sachs im eigenen Cloud Entitlements Service, um Berechtigungen über tausende Anwendungen hinweg zentral durchzusetzen statt sie in einzelnen Teams zu dokumentieren.
Auditierbar per Diff. Der für GRC-Verantwortliche wichtigste Punkt: Wenn Compliance als Code vorliegt, wird ein Audit zu einem Diff. Statt monatelang Nachweise zusammenzutragen, zeigt ein Vergleich zwischen zwei Zuständen exakt, was sich am Kontrollstatus geändert hat – maschinell nachvollziehbar, ohne Interpretationsspielraum bei der Frage, ob eine Maßnahme „im Wesentlichen" umgesetzt war. In der Summe ergeben die vier Eigenschaften das, was im englischsprachigen Raum als Continuous Compliance bezeichnet wird: nicht die jährliche Momentaufnahme, sondern ein durchgehend geprüfter Zustand.
Stresstest · 20 Minuten
Wo steht Ihr Unternehmen bei NIS-2, DORA und ISO 27001?
Kostenloser Compliance-Stresstest – unabhängig davon, ob Sie BAM Core selbst betreiben oder eine dedizierte Instanz wünschen.
Stresstest starten →Wo die Analogie an ihre Grenze stößt
Eine ehrliche Betrachtung muss an dieser Stelle innehalten. Infrastruktur und Compliance sind nicht deckungsgleich, und wer das verschweigt, verkauft statt zu informieren.
Ein terraform apply hat ein binäres Ergebnis: Die Ressource existiert in der gewünschten Konfiguration, oder der Lauf schlägt fehl. Viele Compliance-Anforderungen sind dagegen genuin interpretationsbedürftig. „Angemessene technische und organisatorische Maßnahmen" aus Art. 32 DSGVO oder „Stand der Technik" aus dem BSI-Grundschutz lassen sich nicht vollständig in eine Rego-Regel gießen. Ein Penetrationstest-Bericht, eine Risikobewertung mit qualitativem Urteil, eine Mitarbeiterschulung – das sind Kontrollen, die sich dokumentieren, terminieren und nachweisen, aber nicht im technischen Sinn „testen" lassen wie ein offener S3-Bucket.
Wo die Grenze liegt
Executable Compliance funktioniert vollständig für technisch prüfbare Kontrollen – Zugriffsrechte, Verschlüsselungsstandards, Patch-Stände, Netzwerksegmentierung, Logging-Konfigurationen. Das deckt den größten Teil eines ISO-27001- oder NIS-2-Kontrollkatalogs ab, aber nicht alles. BAM bildet deshalb beide Kategorien im selben Objektmodell ab, statt nur die technisch einfachen Fälle zu lösen und den Rest stillschweigend auszublenden.
Warum das jetzt kommt, nicht später
Der regulatorische Kalender macht den Zeitpunkt unausweichlich. Erstens verlangen NIS-2, DORA und der EU AI Act zunehmend kontinuierlichen Nachweis statt punktueller Zertifizierung – DORA etwa mit der Vier-Stunden-Meldepflicht bei IKT-Vorfällen, die ohne automatisierte Erkennung kaum einzuhalten ist. Zweitens hat sich in DevSecOps-Teams die Erwartung etabliert, dass sicherheitsrelevante Anforderungen in der Pipeline geprüft werden, nicht in einem separaten Audit-Silo, das einmal im Jahr aktiv wird. Drittens ist die technische Basis erwachsen: Was 2018 als CNCF-Sandbox-Projekt startete, ist heute, mit Beiträgen von Google, Microsoft und VMware, Standardinfrastruktur in produktiven Multi-Tenant-Umgebungen.
Was bislang fehlt, ist die Verbindung dieser drei Stränge zu einem durchgängigen Modell für GRC, das nicht bei einzelnen technischen Checks stehen bleibt, sondern den gesamten Kontrollrahmen abbildet – von ISO 27001 über NIS-2 bis zu branchenspezifischen Frameworks wie DORA. Compliance Automation in diesem umfassenden Sinn bedeutet, die in Rego oder vergleichbaren Sprachen geprüften technischen Kontrollen mit den organisatorischen Nachweisen im selben System zu verwalten, statt zwei getrennte Welten – Engineering-Pipeline hier, GRC-Tabelle dort – nebeneinander zu pflegen.
Was das für IT-Leitung und DevSecOps konkret bedeutet
Für Teams, die Infrastructure-as-Code bereits leben, ist der gedankliche Sprung klein, die Werkzeuglandschaft – Git, Pipelines, automatisierte Tests – ist bereits vorhanden. Was fehlt, ist die Übertragung auf Compliance-Artefakte selbst, mit einem Datenmodell, das Auditoren, Geschäftsführung und Engineering-Team gleichermaßen lesen können.
Der praktische Effekt: Audits verlieren ihren Ausnahmecharakter. Ein Kontrollstatus ist nicht mehr eine Momentaufnahme, die mühsam rekonstruiert wird, sondern ein laufend aktueller Zustand. Bei einem typischen ISO-27001-Erstprojekt in der genannten Kostenspanne liegt der größte Hebel nicht im Verhandeln der Zertifizierungsstelle, sondern in der Reduktion des internen Rekonstruktionsaufwands, der nach übereinstimmenden Markteinschätzungen regelmäßig der größte Einzelposten ist.
Die entscheidende Frage lautet daher nicht mehr, ob Compliance automatisiert werden kann. Die entscheidende Frage lautet, welcher Teil des eigenen Kontrollrahmens bereits heute ausführbar gemacht werden sollte – und welcher, wie im Abschnitt zuvor beschrieben, vorerst ein strukturierter Nachweisprozess bleibt.
Denn dieselbe Entwicklung, die Infrastruktur vor zehn Jahren verändert hat, beginnt gerade die Compliance-Welt zu verändern.