BSI TR-03185-2: Compliance-Hürde oder strategischer Hebel für Ihren Marktvorsprung?

Kein reines IT-Thema

Die neue BSI-Richtlinie TR-03185-2 für Open Source Software (OSS) ist eine Management-Aufgabe. Sie definiert die Spielregeln für den sicheren Einsatz von OSS und hat direkte Auswirkungen auf Geschäftsrisiko, Haftung und Wettbewerbsfähigkeit.

Vorbote des Cyber Resilience Act (CRA)

Diese Richtlinie antizipiert die verbindlichen Anforderungen des kommenden EU Cyber Resilience Act. Wer jetzt handelt, sichert sich einen entscheidenden Vorsprung im europäischen Markt.

Risiko wird zur Chance

Die systematische Absicherung Ihrer Software-Lieferkette ist kein Kostenfaktor, sondern ein Investment. Sie minimieren nicht nur Haftungsrisiken, sondern bauen Vertrauen bei Kunden auf und beschleunigen sichere Innovationen.

Die unsichtbare Gefahr in Ihrer Wertschöpfungskette

Nutzen Sie Open-Source-Software? Die rhetorische Frage erübrigt sich. OSS ist das Fundament der modernen digitalen Wirtschaft und steckt in nahezu jeder Anwendung, die Ihr Unternehmen entwickelt, kauft oder betreibt. Doch diese Abhängigkeit schafft eine massive, oft unkontrollierte Angriffsfläche. Jede nicht verwaltete OSS-Komponente ist eine potenzielle Zeitbombe, ein unkalkulierbares Risiko für Ihre Betriebsabläufe, Ihre Reputation und letztlich Ihre Bilanz.

Die entscheidende Frage ist also nicht ob, sondern wie Sie dieses Risiko managen.

Warum klassische Ansätze jetzt versagen: Einblicke aus der Praxis

Aus über 20 Jahren Erfahrung in der Cybersicherheit können wir mit Sicherheit sagen: Die meisten Unternehmen behandeln OSS-Sicherheit immer noch als technisches Problem, das man an die IT-Abteilung delegiert. Das ist ein fataler strategischer Fehler. Die BSI TR-03185-2 macht unmissverständlich klar:

Die Verantwortung für den sicheren Software-Lebenszyklus liegt bei der Unternehmensführung.

Kontraintuitive Wahrheit: Die BSI TR-03185-2 ist ein Geschenk. In einer Landschaft wachsender Bedrohungen und unklarer Haftungsfragen liefert sie einen klaren, praxiserprobten Fahrplan, um Chaos in Kontrolle und Risiko in einen Wettbewerbsvorteil zu verwandeln.

Von der regulatorischen Pflicht zur strategischen Kür

Die TR-03185-2 ist die Brücke zu den kommenden, strengen Vorgaben des EU Cyber Resilience Act (CRA) und der NIS2-Richtlinie. Während Ihre Wettbewerber noch damit kämpfen werden, die gesetzlichen Mindestanforderungen zu verstehen, können Sie bereits demonstrieren, dass Ihre Produkte und Dienstleistungen nachweislich sicher sind.

Ihr Nutzen: Sie reduzieren proaktiv Haftungsrisiken, bestehen Audits mühelos und positionieren sich als vertrauenswürdiger Partner im Markt.

Der Return on Security Investment (ROSI)

Sicherheit als reinen Kostenblock zu betrachten, ist eine veraltete Sichtweise. Die Implementierung eines Secure Software Development Lifecycle (SSDLC), wie ihn die BSI-Richtlinie fordert, generiert messbaren Mehrwert.

Effizienzsteigerung

Fehler, die früh im Entwicklungsprozess gefunden werden, sind exponentiell günstiger zu beheben.

Innovationsgeschwindigkeit

Ein etablierter, sicherer Rahmen erlaubt es Ihren Entwicklerteams, OSS schneller und ohne Sicherheitsbedenken zu nutzen.

Marktdifferenzierung

Nachweisbare Sicherheit wird zunehmend zum entscheidenden Kaufkriterium. Sie schaffen ein starkes Verkaufsargument, das Vertrauen schafft und Kunden bindet.

Das C-Level-Playbook: Ihr 3-Schritte-Aktionsplan

Die Umsetzung ist kein technisches Großprojekt, sondern eine Frage der strategischen Steuerung.

1. Verantwortung neu definieren

Machen Sie OSS-Sicherheit zur Chefsache. Benennen Sie einen zentralen Verantwortlichen, der direkt an die Geschäftsführung berichtet und die Umsetzung organisationsweit steuert. Dies ist keine reine CISO-Aufgabe; es betrifft Produktentwicklung, Recht und Finanzen.

2. Transparenz schaffen und Prozesse etablieren

Sie können nicht schützen, was Sie nicht kennen. Führen Sie eine Software Bill of Materials (SBOM) ein, um einen vollständigen Überblick über alle eingesetzten OSS-Komponenten zu erhalten. Etablieren Sie darauf basierend Prozesse für die kontinuierliche Überwachung und schnelle Aktualisierung bei neuen Schwachstellen.

3. Eine Kultur der Sicherheit verankern

Die beste Richtlinie ist wirkungslos ohne die richtige Kultur. Fördern Sie das Sicherheitsbewusstsein im gesamten Unternehmen – vom Management bis zum Entwickler. Investieren Sie in Schulungen und machen Sie Sicherheit zu einem integralen Bestandteil Ihrer DNA.

Strategische Relevanz für die Führungsebene

Für CEOs & Geschäftsführer

Es geht um die Sicherung der Geschäftskontinuität, die Minimierung von Unternehmensrisiken und die Stärkung des Markenwerts. Die TR-03185-2 ist ein Werkzeug zur strategischen Unternehmenssicherung.

Für CFOs

Dies ist aktives Risikomanagement. Sie vermeiden unkalkulierbare Kosten durch Sicherheitsvorfälle, Strafzahlungen und den Verlust von Geschäftsabschlüssen. Gleichzeitig investieren Sie in die Zukunftsfähigkeit des Unternehmens.

Für CTOs & CIOs

Die Richtlinie liefert den notwendigen Rahmen, um Innovation und Agilität mit Stabilität und Sicherheit zu vereinen. Sie schaffen die Grundlage für eine resiliente und skalierbare IT-Landschaft.

Fazit: Handeln Sie jetzt, bevor Sie handeln müssen

Die BSI TR-03185-2 markiert einen Wendepunkt. Der sorglose Umgang mit Open-Source-Software ist vorbei. Entscheider haben jetzt die Wahl:

Sehen Sie diese Entwicklung als eine weitere regulatorische Last oder erkennen Sie die strategische Chance, die darin verborgen liegt?

Warten Sie nicht, bis der Gesetzgeber Sie zum Handeln zwingt. Beginnen Sie heute damit, die Kontrolle über Ihre Software-Lieferkette zurückzugewinnen. Diskutieren Sie diesen Artikel in Ihrem nächsten Management-Meeting. Der erste Schritt, um Risiken in einen Marktvorteil zu verwandeln, ist die Entscheidung, die Führung zu übernehmen.

Sprechen Sie uns an, für eine erste unverbindliche Beratung!

Nächster Schritt: Kostenlose Erstberatung

📖 Lesen Sie auch: SBOM – Die neue Pflicht für Software-Sicherheit? Erhöhen Sie die Sicherheit Ihrer Lieferkette.

📖 Lesen Sie auch: SBOM – Die neue Pflicht für Software-Sicherheit? Erhöhen Sie die Sicherheit Ihrer Lieferkette.

📖 Lesen Sie auch: Digitale Angriffsflächen im Auto: BSI warnt vor der neuen Realität im Straßenverkehr

Sie möchten IT-Sicherheit strategisch in Ihrem Unternehmen verankern? Unsere Experten beraten Sie gerne — unverbindlich und praxisnah. Jetzt Erstberatung vereinbaren →

BSI TR-03185-1 vs. BSI TR-03185-2: Die Unterschiede

Die BSI TR-03185 besteht aus zwei Teilen, die sich an unterschiedliche Zielgruppen richten. Teil 1 (BSI TR-03185-1) wurde 2024 veröffentlicht und richtet sich an Hersteller proprietärer Software. Er definiert Anforderungen für den gesamten Software-Lebenszyklus: von einem sicheren Software Development Lifecycle (SDLC) über Threat Modeling in der Designphase bis hin zu Secure Coding Guidelines, Vulnerability Management und einem strukturierten Patch-Prozess. Teil 2 (BSI TR-03185-2) erschien im November 2025 und adressiert Organisationen, die Open-Source-Software (OSS) einsetzen. Hier stehen SBOM-Management, Dependency Monitoring, Community-Contribution-Policies, License Compliance und Vulnerability Response im Fokus. Beide Teile zusammen bilden einen umfassenden Rahmen für die sichere Nutzung und Entwicklung von Software in Deutschland.

Konkrete Anforderungen der BSI TR-03185

Anforderungen an Software-Hersteller (TR-03185-1)

Secure SDLC: Hersteller müssen einen dokumentierten, sicheren Software Development Lifecycle implementieren, der Sicherheitsanforderungen in jeder Phase — von der Planung über die Implementierung bis zum End-of-Life — systematisch berücksichtigt.

Threat Modeling in der Designphase: Bereits in der Entwurfsphase müssen potenzielle Bedrohungen systematisch identifiziert und bewertet werden. Methoden wie STRIDE oder PASTA sollen sicherstellen, dass Sicherheitsrisiken frühzeitig erkannt und adressiert werden.

Secure Coding Guidelines: Verbindliche Coding-Richtlinien müssen definiert und durchgesetzt werden, die typische Schwachstellen wie Injection-Angriffe, unsichere Deserialisierung oder fehlerhafte Authentifizierung von vornherein verhindern.

Automatisierte Sicherheitstests (SAST/DAST): Statische und dynamische Sicherheitsanalysen müssen in die CI/CD-Pipeline integriert werden. SAST prüft den Quellcode auf Schwachstellen, während DAST die laufende Anwendung auf Sicherheitslücken testet.

Vulnerability Disclosure Process: Hersteller müssen einen transparenten Prozess für die Meldung, Bewertung und Behebung von Sicherheitslücken etablieren — inklusive koordinierter Offenlegung (Coordinated Vulnerability Disclosure) und zeitnaher Bereitstellung von Patches.

Anforderungen an OSS-Nutzer (TR-03185-2)

SBOM für alle OSS-Komponenten: Organisationen müssen eine vollständige Software Bill of Materials (SBOM) für alle eingesetzten Open-Source-Komponenten pflegen. Diese muss Versionen, Lizenzen, Herkunft und bekannte Schwachstellen dokumentieren.

Kontinuierliches Vulnerability Monitoring: Alle eingesetzten OSS-Komponenten müssen kontinuierlich auf neu bekannt gewordene Schwachstellen überwacht werden — etwa über CVE-Datenbanken, Security Advisories der Projekte oder automatisierte Scanning-Tools.

Definierter Patch-Prozess mit SLAs: Es muss ein klar definierter Prozess für das Einspielen von Sicherheitsupdates existieren, mit verbindlichen Service Level Agreements (SLAs) — beispielsweise kritische Patches innerhalb von 72 Stunden, hohe Schwachstellen innerhalb von 30 Tagen.

License Compliance Management: Die Einhaltung aller OSS-Lizenzbedingungen muss systematisch sichergestellt werden. Dies umfasst die Identifikation aller Lizenzen, die Prüfung auf Kompatibilität und die Erfüllung von Pflichten wie Quellcode-Weitergabe oder Urhebernennung.

Contribution-Back-Policies: Organisationen sollten Richtlinien für die aktive Beteiligung an OSS-Projekten definieren. Dazu gehören klare Regeln für Bug-Reports, Patch-Beiträge und die Zusammenarbeit mit der Open-Source-Community — auch um die langfristige Sicherheit der genutzten Komponenten zu stärken.

BSI TR-03185 und der Cyber Resilience Act (CRA)

Die BSI TR-03185 steht in engem Zusammenhang mit dem EU Cyber Resilience Act (CRA), der erstmals verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen auf dem europäischen Markt einführt. Die technische Richtlinie des BSI kann als deutsche Umsetzungshilfe für zentrale CRA-Anforderungen verstanden werden: Wer die Vorgaben der TR-03185 erfüllt, deckt bereits wesentliche Kernbereiche des CRA ab.

Konkret überschneiden sich die Anforderungen in drei zentralen Bereichen: Erstens fordert der CRA ebenso wie die TR-03185 die Erstellung und Pflege einer Software Bill of Materials (SBOM) für alle Produkte. Zweitens verlangt der CRA ein strukturiertes Vulnerability Handling — von der Erkennung über die Meldung bis zur Behebung — was direkt den Anforderungen der TR-03185 an Vulnerability Management und Disclosure entspricht. Drittens schreibt der CRA Update-Pflichten vor, die sicherstellen, dass Sicherheitsupdates zeitnah und kostenlos bereitgestellt werden — analog zum Patch-Prozess der TR-03185.

Beim Zeitplan ist die Abstimmung ebenfalls relevant: Ab September 2026 gelten die Meldepflichten des CRA für aktiv ausgenutzte Schwachstellen, ab Dezember 2027 müssen alle Produkte die vollständigen CRA-Anforderungen erfüllen. Unternehmen, die jetzt mit der Umsetzung der BSI TR-03185 beginnen, schaffen damit eine solide Grundlage für die CRA-Compliance und vermeiden Last-Minute-Hektik.

Umsetzungs-Roadmap: BSI TR-03185 in 5 Schritten

Schritt 1 — Bestandsaufnahme: Erstellen Sie ein vollständiges Inventar aller eingesetzten Software — proprietär und Open Source. Erfassen Sie Versionen, Einsatzzwecke, Verantwortlichkeiten und Abhängigkeiten. Ohne diese Grundlage ist keine zielgerichtete Umsetzung möglich.

Schritt 2 — Gap-Analyse: Vergleichen Sie Ihren aktuellen Stand systematisch mit den Anforderungen der BSI TR-03185. Identifizieren Sie Lücken in Bereichen wie SDLC-Dokumentation, Vulnerability Management, SBOM-Vollständigkeit und Patch-Prozessen. Priorisieren Sie die Gaps nach Risiko und Aufwand.

Schritt 3 — SBOM-Aufbau: Implementieren Sie ein Software Bill of Materials Management. Nutzen Sie standardisierte Formate wie CycloneDX oder SPDX. Integrieren Sie SBOM-Generierung in Ihre Build-Pipelines und stellen Sie sicher, dass SBOMs bei jedem Release aktualisiert werden.

Schritt 4 — Prozesse definieren: Etablieren Sie dokumentierte Prozesse für Vulnerability Management, Patch-Management und Incident Response. Definieren Sie klare Verantwortlichkeiten, Eskalationspfade und SLAs. Schulen Sie Ihre Teams und verankern Sie die Prozesse in der täglichen Arbeit.

Schritt 5 — Kontinuierliche Überwachung: Richten Sie ein kontinuierliches Monitoring ein: automatisierte Vulnerability-Scans, regelmäßige SBOM-Audits, KPI-Tracking für Patch-Zeiten und Compliance-Status. Führen Sie periodische Reviews durch und passen Sie Ihre Prozesse an neue Bedrohungen und regulatorische Änderungen an.

BSI TR-03185-1 vs. BSI TR-03185-2: Die Unterschiede

Die BSI TR-03185 besteht aus zwei Teilen, die sich an unterschiedliche Zielgruppen richten. Teil 1 (BSI TR-03185-1) wurde 2024 veröffentlicht und richtet sich an Hersteller proprietärer Software. Er definiert Anforderungen für den gesamten Software-Lebenszyklus: von einem sicheren Software Development Lifecycle (SDLC) über Threat Modeling in der Designphase bis hin zu Secure Coding Guidelines, Vulnerability Management und einem strukturierten Patch-Prozess. Teil 2 (BSI TR-03185-2) erschien im November 2025 und adressiert Organisationen, die Open-Source-Software (OSS) einsetzen. Hier stehen SBOM-Management, Dependency Monitoring, Community-Contribution-Policies, License Compliance und Vulnerability Response im Fokus. Beide Teile zusammen bilden einen umfassenden Rahmen für die sichere Nutzung und Entwicklung von Software in Deutschland.

Konkrete Anforderungen der BSI TR-03185

Anforderungen an Software-Hersteller (TR-03185-1)

Secure SDLC: Hersteller müssen einen dokumentierten, sicheren Software Development Lifecycle implementieren, der Sicherheitsanforderungen in jeder Phase — von der Planung über die Implementierung bis zum End-of-Life — systematisch berücksichtigt.

Threat Modeling in der Designphase: Bereits in der Entwurfsphase müssen potenzielle Bedrohungen systematisch identifiziert und bewertet werden. Methoden wie STRIDE oder PASTA sollen sicherstellen, dass Sicherheitsrisiken frühzeitig erkannt und adressiert werden.

Secure Coding Guidelines: Verbindliche Coding-Richtlinien müssen definiert und durchgesetzt werden, die typische Schwachstellen wie Injection-Angriffe, unsichere Deserialisierung oder fehlerhafte Authentifizierung von vornherein verhindern.

Automatisierte Sicherheitstests (SAST/DAST): Statische und dynamische Sicherheitsanalysen müssen in die CI/CD-Pipeline integriert werden. SAST prüft den Quellcode auf Schwachstellen, während DAST die laufende Anwendung auf Sicherheitslücken testet.

Vulnerability Disclosure Process: Hersteller müssen einen transparenten Prozess für die Meldung, Bewertung und Behebung von Sicherheitslücken etablieren — inklusive koordinierter Offenlegung (Coordinated Vulnerability Disclosure) und zeitnaher Bereitstellung von Patches.

Anforderungen an OSS-Nutzer (TR-03185-2)

SBOM für alle OSS-Komponenten: Organisationen müssen eine vollständige Software Bill of Materials (SBOM) für alle eingesetzten Open-Source-Komponenten pflegen. Diese muss Versionen, Lizenzen, Herkunft und bekannte Schwachstellen dokumentieren.

Kontinuierliches Vulnerability Monitoring: Alle eingesetzten OSS-Komponenten müssen kontinuierlich auf neu bekannt gewordene Schwachstellen überwacht werden — etwa über CVE-Datenbanken, Security Advisories der Projekte oder automatisierte Scanning-Tools.

Definierter Patch-Prozess mit SLAs: Es muss ein klar definierter Prozess für das Einspielen von Sicherheitsupdates existieren, mit verbindlichen Service Level Agreements (SLAs) — beispielsweise kritische Patches innerhalb von 72 Stunden, hohe Schwachstellen innerhalb von 30 Tagen.

License Compliance Management: Die Einhaltung aller OSS-Lizenzbedingungen muss systematisch sichergestellt werden. Dies umfasst die Identifikation aller Lizenzen, die Prüfung auf Kompatibilität und die Erfüllung von Pflichten wie Quellcode-Weitergabe oder Urhebernennung.

Contribution-Back-Policies: Organisationen sollten Richtlinien für die aktive Beteiligung an OSS-Projekten definieren. Dazu gehören klare Regeln für Bug-Reports, Patch-Beiträge und die Zusammenarbeit mit der Open-Source-Community — auch um die langfristige Sicherheit der genutzten Komponenten zu stärken.

BSI TR-03185 und der Cyber Resilience Act (CRA)

Die BSI TR-03185 steht in engem Zusammenhang mit dem EU Cyber Resilience Act (CRA), der erstmals verbindliche Cybersicherheitsanforderungen für alle Produkte mit digitalen Elementen auf dem europäischen Markt einführt. Die technische Richtlinie des BSI kann als deutsche Umsetzungshilfe für zentrale CRA-Anforderungen verstanden werden: Wer die Vorgaben der TR-03185 erfüllt, deckt bereits wesentliche Kernbereiche des CRA ab.

Konkret überschneiden sich die Anforderungen in drei zentralen Bereichen: Erstens fordert der CRA ebenso wie die TR-03185 die Erstellung und Pflege einer Software Bill of Materials (SBOM) für alle Produkte. Zweitens verlangt der CRA ein strukturiertes Vulnerability Handling — von der Erkennung über die Meldung bis zur Behebung — was direkt den Anforderungen der TR-03185 an Vulnerability Management und Disclosure entspricht. Drittens schreibt der CRA Update-Pflichten vor, die sicherstellen, dass Sicherheitsupdates zeitnah und kostenlos bereitgestellt werden — analog zum Patch-Prozess der TR-03185.

Beim Zeitplan ist die Abstimmung ebenfalls relevant: Ab September 2026 gelten die Meldepflichten des CRA für aktiv ausgenutzte Schwachstellen, ab Dezember 2027 müssen alle Produkte die vollständigen CRA-Anforderungen erfüllen. Unternehmen, die jetzt mit der Umsetzung der BSI TR-03185 beginnen, schaffen damit eine solide Grundlage für die CRA-Compliance und vermeiden Last-Minute-Hektik.

Umsetzungs-Roadmap: BSI TR-03185 in 5 Schritten

Schritt 1 — Bestandsaufnahme: Erstellen Sie ein vollständiges Inventar aller eingesetzten Software — proprietär und Open Source. Erfassen Sie Versionen, Einsatzzwecke, Verantwortlichkeiten und Abhängigkeiten. Ohne diese Grundlage ist keine zielgerichtete Umsetzung möglich.

Schritt 2 — Gap-Analyse: Vergleichen Sie Ihren aktuellen Stand systematisch mit den Anforderungen der BSI TR-03185. Identifizieren Sie Lücken in Bereichen wie SDLC-Dokumentation, Vulnerability Management, SBOM-Vollständigkeit und Patch-Prozessen. Priorisieren Sie die Gaps nach Risiko und Aufwand.

Schritt 3 — SBOM-Aufbau: Implementieren Sie ein Software Bill of Materials Management. Nutzen Sie standardisierte Formate wie CycloneDX oder SPDX. Integrieren Sie SBOM-Generierung in Ihre Build-Pipelines und stellen Sie sicher, dass SBOMs bei jedem Release aktualisiert werden.

Schritt 4 — Prozesse definieren: Etablieren Sie dokumentierte Prozesse für Vulnerability Management, Patch-Management und Incident Response. Definieren Sie klare Verantwortlichkeiten, Eskalationspfade und SLAs. Schulen Sie Ihre Teams und verankern Sie die Prozesse in der täglichen Arbeit.

Schritt 5 — Kontinuierliche Überwachung: Richten Sie ein kontinuierliches Monitoring ein: automatisierte Vulnerability-Scans, regelmäßige SBOM-Audits, KPI-Tracking für Patch-Zeiten und Compliance-Status. Führen Sie periodische Reviews durch und passen Sie Ihre Prozesse an neue Bedrohungen und regulatorische Änderungen an.

Häufige Fragen zur BSI TR-03185

Was ist die BSI TR-03185 und für wen gilt sie?

Die BSI TR-03185 ist eine technische Richtlinie des Bundesamts für Sicherheit in der Informationstechnik für den sicheren Software-Lebenszyklus. Teil 1 richtet sich an Hersteller proprietärer Software, Teil 2 (veröffentlicht November 2025) an Unternehmen, die Open Source Software einsetzen. Beide Teile sind besonders relevant im Kontext des Cyber Resilience Act (CRA).

Was ist der Unterschied zwischen BSI TR-03185-1 und BSI TR-03185-2?

Teil 1 definiert Anforderungen an den sicheren Lebenszyklus von proprietärer Software – von der Konzeption über die Entwicklung bis zur Wartung. Teil 2 fokussiert auf Open Source Software: SBOM-Management, Schwachstellenmonitoring, Patch-Prozesse und die sichere Integration von OSS-Komponenten in eigene Produkte.

Welche konkreten Anforderungen stellt die BSI TR-03185?

Die Richtlinie fordert unter anderem: eine Software Bill of Materials (SBOM) für alle Komponenten, ein systematisches Schwachstellenmanagement, sichere Entwicklungsprozesse (Secure SDLC), regelmäßige Sicherheitstests, einen definierten Patch- und Update-Prozess sowie klare Verantwortlichkeiten für die Software-Sicherheit.

Wie hängt die BSI TR-03185 mit dem Cyber Resilience Act zusammen?

Die BSI TR-03185 kann als deutsche Implementierungshilfe für den EU Cyber Resilience Act (CRA) verstanden werden. Wer die Anforderungen der TR-03185 erfüllt, hat bereits wesentliche CRA-Anforderungen abgedeckt – insbesondere bei SBOM, Schwachstellenmanagement und sicherem Software-Lebenszyklus.

Gibt es eine BSI TR-03185 Zertifizierung?

Eine dedizierte Zertifizierung nach TR-03185 existiert derzeit nicht. Allerdings kann die Einhaltung der Richtlinie im Rahmen von BSI-Grundschutz-Audits, ISO 27001-Zertifizierungen oder zukünftigen CRA-Konformitätsbewertungen nachgewiesen werden. ADVISORI unterstützt bei Gap-Analysen und Readiness-Assessments.