Was ist OSCAL? Der Deep-Dive zu Compliance as Code und BSI Grundschutz++

Seit dem 1. Januar 2026 hat das Bundesamt für Sicherheit in der Informationstechnik den klassischen IT-Grundschutz durch Grundschutz++ abgelöst. Das war kein Versionsupdate, sondern der größte methodische Bruch in der Geschichte der Behörde. Im Kern steht ein international entwickelter Datenstandard, der den meisten Mittelständlern noch immer nichts sagt: OSCAL.

Vier Monate nach Inkrafttreten zeigt sich klar: Wer sein ISMS noch in Word und Excel pflegt, hat die Umstellung als Schock erlebt oder steht mitten drin. Wer jetzt versteht, wie OSCAL funktioniert und warum das BSI darauf setzt, kann die Migration noch geordnet nachholen und Compliance-Aufwand drastisch senken. Dieser Artikel ist der Deep-Dive für Geschäftsführer, CISOs und IT-Verantwortliche, die wissen wollen, wie sie die Lücke schließen.

Warum manuelle Compliance nicht mehr funktioniert

Die regulatorische Lage hat sich in den letzten zwei Jahren grundlegend verändert. NIS2, EU AI Act, DSGVO, TISAX und DORA überlagern sich, oft im selben Unternehmen. Wer Tier-1-Automotive beliefert und gleichzeitig SaaS-Produkte für Banken anbietet, jongliert mindestens vier Frameworks parallel.

Der traditionelle Ansatz, jede dieser Normen in eigenen Word-Dokumenten und Excel-Listen abzubilden, kollabiert unter dieser Last. Drei Belege:

Erstens, die versteckten Kosten manueller Compliance. Hochqualifiziertes Sicherheitspersonal verbringt 60 bis 80 Prozent seiner Zeit mit Dokumentenpflege statt mit echter Risikoanalyse. Pro Framework fallen 200 bis 400 Stunden Initialaufwand an, die sich beim Mehrfach-Audit nicht reduzieren, weil keine technische Verbindung zwischen den Dokumenten besteht.

Zweitens, die NIS2-Meldepflicht. Die 72-Stunden-Frist für signifikante Vorfälle ist mit E-Mail-Ketten und manuellen Tabellen nicht mehr einhaltbar. Wer im Ernstfall erst Excel-Sheets zusammenkopiert, verliert die Frist und riskiert Bußgelder.

Drittens, der Audit-Fluch. Externe Auditoren stellen jedes Jahr dieselben Fragen, auf die das Unternehmen jedes Jahr neu Beweise heraussucht. Es gibt keinen technischen Mechanismus, eine einmal hochgeladene Evidenz für mehrere Frameworks gleichzeitig zu nutzen.

Genau hier setzt OSCAL an.

Was ist OSCAL überhaupt?

OSCAL steht für Open Security Controls Assessment Language. Es ist ein offener, maschinenlesbarer Datenstandard, entwickelt federführend vom US-amerikanischen NIST in Zusammenarbeit mit dem Cloud-Programm FedRAMP.

Der Kerngedanke ist einfach: Anstatt Sicherheitskontrollen als Fließtext in PDFs und Tabellen zu pflegen, werden sie als strukturierte Daten beschrieben. Unterstützt werden die Formate JSON (für Web-APIs und SaaS-Plattformen), XML (für hierarchische Strukturen) und YAML (gut lesbar, ideal für Konfigurationsverwaltung).

Der entscheidende Unterschied zur klassischen Dokumentenwelt: Jede Kontrolle, jedes Profil, jedes Asset bekommt eine universell eindeutige Kennung (UUID). Damit lassen sich Kontrollen zwischen verschiedenen Frameworks präzise referenzieren, vergleichen und mappen, ohne dass es zu "Copy-and-Paste"-Fehlern oder Versionskonflikten kommt.

OSCAL legt das technische Fundament für Policy-as-Code: Die Anforderung "Passwörter müssen mindestens zwölf Zeichen haben" steht nicht mehr nur als Satz in einer Richtlinie. Sie wird als maschinenlesbarer Parameter definiert, den ein Konfigurationsscanner kontinuierlich gegen die Realität deiner IT-Infrastruktur prüft.

Die fünf Schichten der OSCAL-Architektur

Die Stärke von OSCAL liegt in seiner Schichtarchitektur. Statt eines flachen Datenmodells trennt OSCAL sauber zwischen abstrakter Norm und konkreter Implementierung. Das macht das Modell wartbar und automatisierbar.

Schicht	Modell	Funktion
Control Layer	Catalog	Die unveränderliche Basis. Enthält die reinen Kontrollen einer Norm wie ISO 27001, NIST SP 800-53 oder BSI Grundschutz. Kontrollen werden parametrisiert (z. B. Passwortlängen oder Aufbewahrungsfristen) und mit Metadaten getaggt.
Profile Layer	Profile	Maßschneidert generische Kontrollen für einen konkreten Anwendungsfall. Ein Profil wählt Kontrollen aus, schließt nicht zutreffende aus, fügt eigene hinzu und setzt Parameter. Beispiele: "FedRAMP Moderate Baseline" oder ein BSI-Profil für KRITIS.
Implementation Layer	System Security Plan (SSP) & Component Definition	Beschreibt die konkrete Umsetzung in deiner IT-Landschaft. Component Definitions sind wiederverwendbare Bausteine (Firewall, Cloud-Service, Identity-Provider). Der SSP aggregiert sie zu einem Systeminventar mit Verantwortlichen und Evidenz-Referenzen.
Assessment Layer	Assessment Plan (AP) & Assessment Results (AR)	Plant und protokolliert Audits. Der AP definiert Aufgaben, Auditoren-Rollen und Methoden. Die AR speichern Findings als "compliant" oder "non-compliant", referenzieren Evidenzen und ermöglichen Continuous Monitoring.
Remediation Layer	Plan of Action and Milestones (POA&M)	Verfolgt die Behebung von Findings. Tasks mit Fristen, Verantwortlichen und Status. Direkt verknüpft mit SSP und AR, schließt den Risk-Management-Kreislauf.

Der eigentliche Hebel liegt in der Datenvererbung. Veröffentlicht das BSI eine neue Version eines Praktiken-Katalogs, importierst du in deiner GRC-Plattform nur das aktualisierte OSCAL-Profil. Die Software berechnet algorithmisch, welche Lücken sich gegenüber deiner aktuellen Implementierung ergeben, und legt sie als neue Tasks im POA&M an. Was früher eine mehrmonatige Gap-Analyse war, läuft in Minuten.

BSI Grundschutz++: der Bruch mit drei Jahrzehnten PDF-Tradition

Parallel zur internationalen Etablierung von OSCAL hat das BSI den radikalsten Methodikwechsel seiner Geschichte vollzogen. Der klassische IT-Grundschutz, jahrzehntelang De-facto-Standard für Behörden und KRITIS-Betreiber, wurde zum 1. Januar 2026 durch Grundschutz++ abgelöst. Die Roadmap dazu war bereits auf der it-sa 2024 finalisiert worden.

Vier strukturelle Innovationen unterscheiden Grundschutz++ vom Vorgänger:

Praktiken statt Bausteine. Die starren, vordefinierten Bausteine (z. B. APP.1.2 Webbrowser) verschwinden. An ihre Stelle treten thematische Praktiken (Identitäts- und Berechtigungsmanagement, Patch-Management, Krisenmanagement). Aus diesen Praktiken werden konkrete Anforderungen kontextbezogen abgeleitet, was Redundanzen drastisch reduziert.

Zielobjektkategorien mit Vererbung. Assets werden Kategorien zugeordnet (Server, Cloud-Service, mobiles Endgerät, Gebäude). Sicherheitsanforderungen werden auf Kategorie-Ebene formuliert. Ein einzelnes Asset erbt sie automatisch. Wer ein neues Server-Modell einführt, dokumentiert nur einmal die Kategorie, nicht jedes Asset einzeln.

Governance-Shift zu Risk Ownern. Informationssicherheit ist im Grundschutz++ explizit Führungsaufgabe. Die Verantwortung für Geschäftsprozess-Risiken liegt nicht mehr in der IT, sondern bei den Risk Ownern in den Fachbereichen. Wer den Vertrieb leitet, trägt Verantwortung für die Sicherheit der CRM-Daten. Wer die Produktion verantwortet, für die OT-Schutzklassen.

Offene Entwicklung mit Stand-der-Technik-Bibliothek. Das BSI öffnet den Entwicklungsprozess erstmals systematisch für die Fachöffentlichkeit. Die digitale "Stand-der-Technik-Bibliothek" lässt neue Maßnahmen iterativ entstehen, bevor sie offizieller Standard werden. Die Bibliothek ist kein Textarchiv, sondern ein über APIs abfragbarer Datenraum.

Der PDCA-Zyklus im Grundschutz++

Methodisch folgt Grundschutz++ dem klassischen Plan-Do-Check-Act. Neu ist die saubere Trennung in fünf Prozessschritte, die deutlich enger an die OSCAL-Datenstruktur gekoppelt sind als der Vorgänger.

Phase	Schritt	Inhalt
Plan	1. Erhebung und Planung	Kontext der Organisation erfassen, Sicherheitsleitlinie erstellen, Geltungsbereich definieren, Risk Owner zuweisen. Verhindert Scope Creep, koppelt Sicherheit an Geschäftsziele.
Plan	2. Anforderungsanalyse	Informationsverbund abgrenzen, Assets in Zielobjektkategorien einordnen, Anforderungen aus Praktiken ableiten. Hier wird aus abstrakten Bedrohungen ein parametrisiertes Anforderungspaket.
Do	3. Realisierung	Ist-Zustand erfassen, Lücken identifizieren, Umsetzungsplan mit Fristen erstellen, Ausnahmen formal freigeben, Tracking sicherstellen.
Check	4. Überwachung	Wirksamkeit prüfen, interne und externe Audits durchführen, Managementbewertung vorbereiten, automatisiert validieren, ob das Anforderungspaket noch passt.
Act	5. Kontinuierliche Verbesserung	Non-Conformities behandeln, Korrekturen planen, Wirksamkeit prüfen, Verbesserungen als Parameter in den nächsten Zyklus überführen.

Der zentrale Gedanke heißt Continuous ISMS: Jede Änderung an Geschäftsprozessen, rechtlichen Rahmenbedingungen oder der IT-Landschaft wirkt sich unmittelbar auf das Anforderungspaket aus. Updates sind nicht mehr zyklische Ausnahme vor dem Audit, sondern permanenter Normalbetrieb.

Die Symbiose: OSCAL als Motor des Grundschutz++

Hier kommt die strategisch weitreichendste Entscheidung des BSI ins Spiel. Während alle früheren Iterationen des IT-Grundschutzes als hunderte Seiten lange PDFs publiziert wurden, nutzt das BSI für Grundschutz++ OSCAL als nativen Datenkern:

• Die Anforderungsebene wird über OSCAL Catalog und Profile abgebildet.
• Die Implementierungsebene über Component Definitions und den System Security Plan.
• Die Bewertungsebene über Assessment Plans und Assessment Results.

Die strategische Tragweite ist epochal. Die Stand-der-Technik-Bibliothek wird zum strukturierten, API-abfragbaren Datenraum, in den auch nutzergenerierte Kataloge und KI-gestützte Maßnahmenvorschläge einfließen. Statt PDF-Update herunterzuladen, abonnieren GRC-Plattformen das aktuelle BSI-Profil als Datenstrom.

Was sich für IT-Administratoren ändert

Konkrete Beispiele aus dem Alltag:

Konfigurationsprüfung läuft automatisch. Ob Verschlüsselungsalgorithmen dem aktuellen Stand der Technik entsprechen oder ob Patches zeitnah eingespielt wurden, wird nicht mehr per Excel-Checkliste abgefragt. Tools lesen den Status über APIs aus den Zielsystemen aus und übertragen ihn direkt in den OSCAL Assessment Results Layer.

Findings erzeugen automatisch Tasks. Wird ein Server als "non-compliant" erkannt, generiert das System im selben Moment einen zuweisbaren Task im POA&M. Der zuständige Risk Owner erhält die Eskalation per Workflow, nicht per Mail-Forward.

Open-Source-Profile beschleunigen die Umsetzung. Initiativen wie das ComplianceAsCode-Projekt auf GitHub stellen bereits Profile bereit, mit denen sich Linux-Distributionen, Cloud-Konfigurationen und Datenbanken automatisiert auf BSI-Konformität prüfen lassen. Anbieter wie NTT Data zeigen mit dem "BSI Grundschutz Edition 2023 Converter", wie sich historische PDF-Module per KI-Pipeline in OSCAL-konforme JSON-Kataloge transformieren lassen.

Cross-Framework-Mapping: eine Eingabe, vier Frameworks

Die Stärke der maschinenlesbaren OSCAL-Architektur entfaltet sich vollständig, wenn dein Unternehmen mehr als ein Framework bedient. Praktisch jeder Mittelständler, der TISAX braucht, hat parallel einen ISO-27001-Bedarf für Großkunden, eine NIS2-Pflicht aus dem KRITIS-Umfeld und perspektivisch eine Grundschutz++-Anforderung von Behördenkunden.

Werden diese Normen in Silos bearbeitet, vervielfacht sich der Aufwand. OSCAL macht sogenanntes Cross-Walking zur Routine: Eine technische Maßnahme, einmal in der Component Definition als implementiert markiert, deckt simultan Anforderungen mehrerer Frameworks ab.

Beispiel Multi-Faktor-Authentifizierung für Cloud-Dienste:

Framework	Anforderung
ISO 27001:2022	A.5.16, A.5.17, A.8.5
NIS2	Art. 21(2)(d) Identitätsmanagement
BSI Grundschutz++	Praktik "Identitäts- und Berechtigungsmanagement"
TISAX 6.0	Kontrolle 4.x
DORA	Art. 9 ICT Risk Management

In der traditionellen Welt: fünf separate Kontrollnachweise, fünf Auditberichte, fünf Evidenz-Sammlungen. Mit OSCAL: eine Component Definition, fünf automatische Mappings, ein Findings-Report. Die Synergien zwischen ISO 27001 und TISAX reduzieren den Aufwand für eine TISAX-Level-3-Implementierung um 20 bis 30 Prozent, wenn ein konformes ISMS existiert. Mit Grundschutz++ wird dieser Hebel zur Standardfunktion.

NIS2 in der Praxis: warum OSCAL zur Überlebensfrage wird

Das schärfste Beispiel für die ökonomische Notwendigkeit dieser Transformation ist die NIS2-Meldepflicht. Betroffene Unternehmen müssen signifikante Vorfälle innerhalb von 24 Stunden initial und innerhalb von 72 Stunden in einem detaillierten Bericht an die zuständige Behörde melden.

Wer Vorfälle in Excel führt, ist unter Stress eines aktiven Cyberangriffs strukturell außerstande, diese Frist einzuhalten. In integrierten Plattformen läuft der Workflow nativ:

1. Ein Monitoring-System erkennt einen Incident und triggert automatisch einen Workflow.
2. Das System benachrichtigt die im OSCAL-SSP hinterlegten Risk Owner zielgerichtet.
3. Sofortmaßnahmen werden über das POA&M-Modell delegiert und nachverfolgt.
4. Evidenzen für die Behördenmeldung werden automatisch aggregiert und bereitgestellt.

Die NIS2-Pflicht für Mittelstand und Zulieferer ist damit nicht nur eine rechtliche Hürde, sondern der wahrscheinlich stärkste Treiber für die Adaption maschinenlesbarer Compliance-Architekturen im deutschen Mittelstand.

Was das für KMUs heißt: ROI und Toolwahl

Die Investition in ein OSCAL-natives ISMS amortisiert sich auf zwei Pfaden: durch Effizienzgewinne im Tagesgeschäft und durch radikal verkürzte Audit-Zyklen.

Reine Implementierungskosten. Eine ISO-27001-Implementierung bewegt sich klassisch im Rahmen 25.000 bis 250.000 Euro Initialinvestition mit 6 bis 18 Monaten Vorlauf. Die belegbare ROI-Rate liegt bei bis zu 440 Prozent durch Risikoreduktion und Audit-Beschleunigung. Mit OSCAL-nativen Plattformen verschiebt sich der Anteil zwischen Tool-Kosten und Beratungskosten deutlich Richtung Tool, was die Gesamtkosten senkt.

Plattformkosten im Vergleich. Globale Anbieter wie Vanta veranschlagen für mittelständische Unternehmen 14.000 bis 23.000 Euro pro Jahr für ein einzelnes Framework. Jedes weitere Framework kostet zusätzlich, Audits sind nicht eingerechnet. Modulare europäische Anbieter wie Kopexa starten ab 249 Euro pro Monat im Lite-Tier mit drei Nutzern. Im Pro-Plan ab 599 Euro pro Monat bekommst du unbegrenzte Frameworks, OSCAL-Support, Vendor- und Asset-Management. Eine vollständige Übersicht findest du auf der Pricing-Seite und im Vergleich der Compliance-Software-Kosten für KMU.

Auswahlkriterien für 2026. Drei nicht verhandelbare Kriterien für die Toolauswahl:

• Native OSCAL-Unterstützung in JSON, XML und YAML. Tools, die Kataloge nur als PDF importieren, sind ab 2026 nicht mehr zukunftsfähig.
• Cross-Framework-Mapping-Engine mit dokumentierten Mappings zwischen ISO 27001, NIS2, TISAX, DORA und Grundschutz++.
• Automatisierter Vorfall-Workflow mit definierter NIS2-Eskalationskette und Behördenmeldung.

Strategische Empfehlungen für 2026

Drei zeitkritische Handlungsempfehlungen für Geschäftsführung und CISO:

1. Migration zur Grundschutz++-Methodik abschließen. Grundschutz++ ist seit dem 1. Januar 2026 der verbindliche Standard. Wer noch nicht migriert ist, sollte als Erstes das Asset Management aufräumen. Ein sauberes Asset-Inventar ist die einzige solide Grundlage für die neue Logik der Zielobjektkategorien und Praktiken.

2. Investition in OSCAL-native, modulare GRC-Plattformen. Manuelles Mapping über mehrere Frameworks ist nicht mehr vertretbar. Modulare Architekturen erlauben dir, mit einem Framework zu starten und organisch zu wachsen, ohne in starre Lizenzmodelle gefangen zu sein.

3. Governance-Transformation Richtung Risk Ownership. Sicherheit allein in der IT zu lassen, ist unter NIS2 und Grundschutz++ keine Option mehr. Definiere Risk Owner in jedem Fachbereich und gib ihnen Echtzeit-Dashboards, die ihren Verantwortungsbereich abbilden. Das ist nicht nur Compliance, sondern echtes Risikomanagement.

Fazit: Compliance as Code ist kein Buzzword mehr

Der Paradigmenwechsel von dokumentengetriebener zu datengetriebener Compliance ist keine theoretische Vision mehr. Mit OSCAL existiert ein global etablierter Datenstandard. Mit Grundschutz++ macht das BSI ihn zum nationalen Default. Mit NIS2 wird die Geschwindigkeit, die OSCAL ermöglicht, zur juristischen Notwendigkeit.

Wer Mitte 2026 noch sein ISMS in Excel führt, riskiert nicht nur Audit-Befunde. Er verliert die Fähigkeit, neue regulatorische Anforderungen überhaupt noch in vertretbarer Zeit umzusetzen. Wer jetzt auf OSCAL-native Plattformen umstellt, transformiert den steigenden Regulierungsdruck in einen strategischen Wettbewerbsvorteil.

Wenn du wissen willst, wie sich OSCAL-Frameworks und Grundschutz++-Migration in Kopexa konkret abbilden, vereinbare einen Demo-Termin oder probiere es im Framework-Katalog selbst aus.