Der stille Compliance-Brand: Eine User Story

Es ist ein Dienstagnachmittag im Februar 2026. Thomas Langer, IT-Leiter bei der Hoffmann Maschinenbau GmbH in Augsburg, sitzt einem externen Sicherheitsberater gegenüber. Auf dem Tisch liegt der Abschlussbericht eines internen Security-Audits. Langer hatte eigentlich erwartet, dass das Gespräch eine reine Formalität sein würde. Die vergangenen zwölf Monate waren technisch gesehen die produktivsten in der Geschichte seines Entwicklungsteams. GitHub Copilot und Cursor hatten die Entwicklungsgeschwindigkeit um fast 40 Prozent gesteigert. Neue Features wurden in Rekordzeit fertiggestellt. Kunden waren begeistert. Investoren auch.

Der Auditor öffnet die erste Folie. In roter Schrift steht: „Kritische Open-Source-Lizenzverletzungen: 3 Fälle. Ungepatchte CVEs mit CVSS ≥ 8.0: 7 Funde in aktiven Produktionskomponenten."

In den nächsten drei Stunden wird Thomas Langer verstehen, was es bedeutet, wenn KI-Systeme Code schreiben, ohne dass irgendjemand systematisch prüft, was dabei entsteht.

Wie es so weit kam

Die Hoffmann Maschinenbau GmbH ist kein Einzelfall – sie ist repräsentativ für hunderte von mittelständischen Softwareunternehmen und produktentwickelnden Betrieben in Deutschland. Das Unternehmen hatte die Einführung von KI-Coding-Tools als reine Produktivitätsfrage betrachtet. Die Entwickler liebten die neuen Werkzeuge. Code wurde schneller, Tests wurden häufiger, Bugs wurden früher entdeckt. Was niemand hatte, war ein systematischer Prozess dafür, welche Open-Source-Komponenten die KI in den Code einflocht und ob diese Komponenten lizenzrechtlich und sicherheitstechnisch einwandfrei waren.

GitHub Copilot und ähnliche KI-Coding-Assistenten generieren Code, der auf Milliarden von Zeilen Open-Source-Code trainiert wurde. Wenn ein Entwickler die KI bittet, eine Funktion zu implementieren, wählt diese die Bibliotheken und Abhängigkeiten, die sie für geeignet hält – oft ohne explizite Begründung, ohne Hinweis auf Lizenz, und ohne Prüfung auf bekannte Sicherheitslücken. Drei Bibliotheken, die Copilot in einem Hoffmann-Projekt eingebunden hatte, trugen GPL-Lizenzen: eine sogenannte Copyleft-Lizenz, die vorschreibt, dass abgeleiteter Code ebenfalls unter GPL veröffentlicht werden muss. Für proprietäre kommerzielle Software bedeutet das in der Praxis eine schwerwiegende Lizenzverletzung mit erheblichem Haftungsrisiko.

Dazu kamen sieben Abhängigkeiten mit bekannten CVEs – darunter eine Komponente mit einer Path-Traversal-Schwachstelle (CVSS 9.1), die Angreifern theoretisch ermöglicht hätte, beliebige Dateien auf dem Produktionsserver zu lesen.

Die Schadensbehebung kostete das Entwicklungsteam vier Wochen Mehrarbeit. Einen Kunden musste das Unternehmen aktiv informieren. Die Rechtsabteilung prüfte wochenlang die Lizenzexposition. Der geplante Auslieferungstermin für ein neues Kundenmodul wurde um drei Monate verschoben. Die indirekten Kosten – Vertrauensverlust, Mitarbeiterzeit, rechtliche Beratung – übertrafen die direkten Entwicklungskosten des ursprünglichen Features bei weitem.

Thomas Langer fasst es rückblickend so zusammen: „Die KI hat unsere Produktivität verdoppelt – und wir haben vergessen zu fragen, zu welchem Preis."

Das Grundproblem: Traditionelle SCA wurde für eine andere Welt gebaut

Software Composition Analysis – kurz SCA – ist kein neues Konzept. Seit mehr als einem Jahrzehnt helfen SCA-Tools Unternehmen dabei, Open-Source-Komponenten in ihrer Software zu inventarisieren, deren Lizenzen zu prüfen und bekannte Sicherheitslücken (CVEs) zu identifizieren. Tools wie Black Duck von Synopsys, FOSSA, Mend (ehemals WhiteSource) oder Snyk sind in professionellen Entwicklungsumgebungen weit verbreitet und haben ihren Wert bewiesen.

Das traditionelle SCA-Paradigma basiert auf einem klaren Modell: Entwickler deklarieren Abhängigkeiten explizit in Paketmanager-Dateien – package.json für Node.js, pom.xml für Java/Maven, requirements.txt für Python, go.mod für Go. Das SCA-Tool analysiert diese Manifest-Dateien, identifiziert die verwendeten Pakete inklusive aller Versionen und prüft sie gegen bekannte Schwachstellen- und Lizenzdatenbanken. Dieses Modell funktioniert hervorragend – solange Entwickler tatsächlich explizit Abhängigkeiten deklarieren und solange der gesamte Code menschlichen Ursprungs ist.

Die Ära des KI-generierten Codes bricht dieses Modell auf mehreren Ebenen auf:

Problem 1: Implizite Abhängigkeiten und Code-Snippets ohne Deklaration

KI-Coding-Assistenten fügen nicht nur Bibliotheken ein, die dann in der package.json auftauchen. Sie generieren häufig direkt Code-Snippets, die auf internen Logiken, Algorithmen oder Strukturen von Open-Source-Projekten basieren – ohne dass die Ursprungsbibliothek als Abhängigkeit deklariert wird. Ein von Copilot generierter Sortieralgorithmus, der konzeptuell einer GPL-lizenzierten Implementierung ähnelt, erscheint nicht in den Paketmanager-Dateien und wird von klassischen Dependency-Scannern schlicht nicht erfasst. Ob das urheberrechtlich relevant ist, ist juristisch umstritten – aber das Risiko liegt beim Unternehmen.

Problem 2: Entwicklungsgeschwindigkeit überholt Compliance-Prozesse

Wenn KI-Tools die Entwicklungsgeschwindigkeit verdoppeln oder verdreifachen, entsteht Code in entsprechendem Tempo. Traditionelle SCA-Prozesse, die einmal täglich als Teil von nächtlichen CI/CD-Pipelines laufen, können mit dieser Geschwindigkeit nicht Schritt halten. Was bis gestern Abend noch nicht im Repository war, kann heute Morgen bereits in der Staging-Umgebung liegen – und übermorgen in der Produktion. Die zeitliche Lücke zwischen Entstehung und Compliance-Prüfung wächst.

Problem 3: Provenienz-Unsicherheit bei KI-generiertem Code

Aus welchem Training-Datensatz stammt ein bestimmter Code-Vorschlag von Copilot oder Cursor? Wurde er durch ein MIT-lizenziertes Projekt inspiriert oder durch ein GPL-Projekt? Diese Frage lässt sich mit traditionellen Mitteln nicht zuverlässig beantworten – und KI-Coding-Tools geben diese Information standardmäßig nicht preis. Die Provenienz-Unsicherheit ist ein strukturelles Problem, das klassische SCA-Ansätze konstruktionsbedingt nicht lösen können.

Problem 4: SBOM-Integrität und regulatorische Nachweispflicht

Ein Software Bill of Materials (SBOM) – eine maschinenlesbare, strukturierte Liste aller Komponenten und Abhängigkeiten einer Software – ist zunehmend regulatorisch gefordert: durch den EU Cyber Resilience Act, durch NIS2, durch Ausschreibungsanforderungen öffentlicher Auftraggeber und durch die Anforderungen großer Unternehmenskunden. Wenn KI-generierter Code implizite Abhängigkeiten enthält, die nicht in Paketmanager-Dateien erscheinen, ist das resultierende SBOM strukturell unvollständig. Eine trügerische Sicherheit, die im Ernstfall – bei einer Lizenzverletzungsklage oder einem Sicherheitsvorfall – zum Problem wird.

Agentic SCA: Die neue Generation der Compliance-Prüfung

Am 14. April 2026 stellte FossID, ein auf Open-Source-Intelligence und Software-Compliance spezialisierter Anbieter, Agentic SCA vor – einen konzeptionell neuen Ansatz für Software Composition Analysis, der explizit für die Anforderungen des KI-Zeitalters entworfen wurde. Das Produkt befindet sich noch in der Pilotphase mit ausgewählten Unternehmenskunden aus den Bereichen Automotive, Semiconductor, Telekommunikation und Software, soll aber in der zweiten Hälfte 2026 allgemein verfügbar werden.

Das Grundprinzip ist ein Paradigmenwechsel: Statt auf Paketmanager-Manifeste zu warten und einmal täglich zu scannen, setzen autonome KI-Agenten direkt auf den Quellcode an. Sie analysieren den Code auf mehreren Ebenen gleichzeitig und tun dies kontinuierlich – synchron mit dem Entwicklungsprozess, nicht als nächtlicher Batch-Job.

Die vier Analyseebenen im Zusammenspiel

Agentic SCA kombiniert vier komplementäre Methoden, die traditionelle Tools einzeln und oft unzureichend adressieren:

Signatur-Scanning: Die klassische Methode, neu gedacht. KI-gestützt beschleunigt und mit deutlich höherer Treffsicherheit als bisherige regelbasierte Ansätze. Bekannte Bibliotheken und deren spezifische Versionen werden gegen umfangreiche Datenbanken abgeglichen. Geringere False-Positive-Rate durch kontextsensitive Analyse.

Snippet Detection: Das technische Herzstück von Agentic SCA. KI-Agenten analysieren einzelne Code-Fragmente auf ihre Herkunft – vollständig unabhängig davon, ob sie als explizite Abhängigkeit deklariert wurden. Dieser Ansatz kann erkennen, wenn ein von Copilot generierter Algorithmus einer Funktion aus einer GPL-Bibliothek strukturell ähnelt, auch wenn die Bibliothek selbst nirgends als Abhängigkeit gelistet ist. Die technische Basis: Feature-Extraktion und semantische Ähnlichkeitssuche über einen Index von Millionen Open-Source-Code-Snippets.

Dependency Analysis: Erweiterte Analyse vollständiger Abhängigkeitsgraphen, die auch transitive Abhängigkeiten – also Abhängigkeiten von Abhängigkeiten – vollständig und rekursiv erfasst. Ein häufig unterschätztes Risiko: Viele der kritischsten CVEs der letzten Jahre (Log4Shell ist das bekannteste Beispiel) betrafen transitive Abhängigkeiten, die in der direkten Abhängigkeitsliste gar nicht auftauchten.

Deep License und Copyright Analysis: Automatische Klassifizierung von Lizenztypen mit differenzierten Kategorien (permissive Lizenzen wie MIT, Apache 2.0, BSD vs. Copyleft-Lizenzen wie GPL 2/3, AGPL, LGPL vs. proprietäre Lizenzen), Risikoklassifizierung basierend auf der konfigurierbaren Lizenzpolicy des Unternehmens. Urheberrechtsvermerke werden extrahiert, gespeichert und in Berichten dokumentiert.

Shift-Left: Compliance im Moment der Entstehung

Ein konzeptuell entscheidender Unterschied zu traditionellen SCA-Ansätzen: Agentic SCA gibt Entwicklern Feedback, bevor Code committet wird – direkt im Editor, während er getippt wird. Wenn ein Entwickler eine Bibliothek einbindet oder einen Code-Snippet einfügt, der eine Policy-Verletzung darstellt, erscheint unmittelbar eine Warnung – nicht erst nach dem nächtlichen Scan, nicht erst beim Code-Review, sondern in dem Moment, in dem der Fehler entsteht.

Dieses Prinzip – Shift-Left genannt, weil es Prüfungen an den frühestmöglichen Punkt im Entwicklungsprozess verschiebt – reduziert die Kosten von Compliance-Korrekturen dramatisch. Das IBM Systems Science Institute hat in einer vielzitierten Studie gezeigt, dass Fehler, die in der Entwicklungsphase entdeckt werden, bis zu 100-mal günstiger zu beheben sind als solche, die erst in der Produktion entdeckt werden. Für Compliance-Verletzungen gilt dasselbe – mit dem zusätzlichen Faktor rechtlicher Risiken.

Die Entwicklerproduktivität leidet dabei kaum: Die Agenten arbeiten im Hintergrund und melden sich nur dann, wenn eine echte Compliance-Verletzung oder ein tatsächliches Sicherheitsrisiko vorliegt. Kein Alarm-Flooding, keine False-Positive-Müdigkeit, kein Unterbrechen des Flow-Zustands für jede gefundene Bibliothek.

Regulatorischer Kontext: Warum SBOM und SCA jetzt strategisch werden

Die Ankündigung von Agentic SCA fällt in eine Phase, in der gesetzliche Anforderungen an Software-Lieferkettensicherheit massiv zunehmen. Für Unternehmen, die Software entwickeln – ob als internes Tool, als Teil eines vernetzten Produkts oder als kommerzielles Softwareprodukt – sind drei regulatorische Entwicklungen besonders relevant:

EU Cyber Resilience Act (CRA)

Der im Oktober 2024 verabschiedete CRA stellt verbindliche Cybersicherheitsanforderungen an Produkte mit digitalen Elementen – also praktisch jede Software und jedes vernetzte Gerät, das auf dem EU-Markt in Verkehr gebracht wird. Die ersten Verpflichtungen greifen schrittweise ab 2026, mit vollständiger Wirksamkeit ab Ende 2027.

Zentrale SCA-relevante Anforderungen des CRA: Hersteller müssen eine maschinenlesbare SBOM erstellen und diese auf Anfrage verfügbar machen. Bekannte ausnutzbare Schwachstellen müssen identifiziert, gemeldet und innerhalb definierter Fristen gepatcht werden. Die Lieferkette – inklusive der eingesetzten Open-Source-Komponenten – muss systematisch auf Sicherheitsrisiken geprüft werden. Bei Verstößen drohen Bußgelder von bis zu 15 Millionen Euro oder 2,5 Prozent des weltweiten Jahresumsatzes.

Für Unternehmen, deren SBOM durch KI-generierten Code strukturell unvollständig ist, bedeutet der CRA ein wachsendes Compliance-Risiko, das sich mit Agentic SCA-Ansätzen direkt adressieren lässt.

NIS2 und Software-Lieferkettensicherheit

Die NIS2-Richtlinie, seit Dezember 2025 in deutsches Recht umgesetzt, schreibt betroffenen Unternehmen (über 50 Mitarbeiter in kritischen Sektoren oder Jahresumsatz über 10 Millionen Euro in regulierten Sektoren) explizit vor, die Sicherheit ihrer Software-Lieferketten zu managen – inklusive der von Drittanbietern bezogenen und der selbst genutzten Open-Source-Komponenten. Open-Source-Bibliotheken mit bekannten ausnutzbaren CVEs in selbst entwickelter oder eingesetzter Software fallen direkt unter diese Anforderung.

Die BSI-Registrierung, deren Frist im April 2026 endete, ist dabei nur der erste Schritt. Was folgt, sind konkrete Nachweispflichten für das tatsächliche Sicherheitsniveau – wozu auch die Qualität des Software-Lieferketten-Managements gehört.

EU AI Act und KI-gestütztes Development

Für Unternehmen, die KI-Systeme in ihrer eigenen Software einsetzen oder KI-gestützt entwickeln, kommt der EU AI Act als weitere Schicht hinzu. Hochrisiko-KI-Systeme unterliegen strengen Anforderungen an Transparenz, Dokumentation und Qualitätssicherung. Die Dokumentation der eingesetzten Software-Komponenten – inklusive ihrer Provenienz – ist ein expliziter Bestandteil dieser Anforderungen. KI-generierter Code ohne nachvollziehbare Komponentenherkunft stellt hier ein strukturelles Dokumentationsproblem dar.

Praktischer Fahrplan: Was Unternehmen heute tun können

Agentic SCA ist noch nicht allgemein verfügbar. Aber die zugrunde liegenden Praktiken lassen sich mit vorhandenen Werkzeugen bereits heute und schrittweise etablieren. Hier ist ein konkreter Fahrplan, der in der Praxis funktioniert:

Schritt 1: Ehrliche Bestandsaufnahme – Was haben wir eigentlich?

Viele Unternehmen unterschätzen erheblich, wie viele Open-Source-Komponenten tatsächlich in ihrer Software stecken. Der erste Schritt ist eine vollständige SCA-Analyse mit einem der verfügbaren Tools:

  • Snyk – Besonders gut für entwicklernahe Integration und starke IDE-Plugins. Freemium-Modell für kleinere Teams. Ideal für den Einstieg.
  • FOSSA – Stärken bei tiefer Lizenz-Compliance-Analyse und Policy-Management. Gut geeignet für Unternehmen mit komplexen Lizenzanforderungen.
  • Black Duck (Synopsys) – Umfassendste Snippet-Detection-Fähigkeiten im Markt. Für größere Teams und hohe Compliance-Anforderungen (Automotive, Aerospace).
  • Mend (ehemals WhiteSource) – Sehr gute CI/CD-Integration und automatisches Remediation-Vorschlagsystem.

Das Ziel ist eine erste SBOM als Baseline. Diese ist zunächst noch unvollständig – sie erfasst nur deklarierte Abhängigkeiten. Aber aus ihr lassen sich sofort kritische Risiken ableiten: Welche Bibliotheken haben aktuelle CVEs? Welche Lizenzen könnten problematisch sein?

Schritt 2: KI-Coding-Policy definieren und kommunizieren

Klären Sie schriftlich und verbindlich, welche KI-Coding-Tools eingesetzt werden dürfen, und etablieren Sie klare Regeln für deren Nutzung:

  • Jede von einer KI vorgeschlagene neue Bibliothek muss explizit und bewusst in die Paketmanager-Datei aufgenommen werden – kein blindes Akzeptieren von Import-Vorschlägen
  • KI-generierter Code durchläuft denselben Code-Review-Prozess wie menschlich geschriebener Code – kein Fast-Track für AI-Output
  • Neue Abhängigkeiten werden vor dem Commit durch den Entwickler auf Lizenzkompatibilität geprüft (Lizenztyp-Lookup dauert 30 Sekunden)
  • Entwickler sind aktiv geschult, Copyleft-Lizenzen (GPL, AGPL) zu erkennen und zu melden

Diese Policy ist kein Misstrauensvotum gegen KI-Tools – sie ist professionelle Hygiene für eine Zeit, in der Code schneller entsteht als je zuvor.

Schritt 3: SCA als Gate in die CI/CD-Pipeline integrieren

Automatisieren Sie SCA-Scans als verbindliches Gate in Ihrer Continuous-Integration-Pipeline: Bei jedem Pull Request oder Merge Request wird automatisch ein SCA-Scan ausgeführt. Kritische CVEs (CVSS ≥ 9,0) oder konfigurierten Lizenz-Policy-Verletzungen blockieren den Merge automatisch – genauso wie ein fehlgeschlagener Unit Test. Das stellt sicher, dass keine bekannte kritische Schwachstelle und keine schwerwiegende Lizenzverletzung unbemerkt in die Produktion gelangt.

Gängige CI/CD-Integrationen sind für alle führenden SCA-Tools gut dokumentiert verfügbar: GitHub Actions, GitLab CI/CD, Jenkins, Azure DevOps, CircleCI. Die Implementierungszeit beträgt für einen erfahrenen DevOps-Engineer in der Regel wenige Stunden.

Schritt 4: Unternehmensweite Lizenz-Policy definieren

Nicht alle Open-Source-Lizenzen sind gleich – und die Unterschiede sind für proprietäre Softwareprodukte geschäftskritisch. Definieren Sie eine verbindliche, schriftliche Lizenz-Policy:

  • Grüne Liste (erlaubt ohne Einschränkung in proprietärer Software): MIT, Apache 2.0, BSD 2-Clause, BSD 3-Clause, ISC, Boost Software License
  • Gelbe Liste (bedingt erlaubt, Einzelfallprüfung erforderlich): LGPL 2.1/3.0 (bei korrekter dynamischer Verlinkung möglich), Eclipse Public License, Mozilla Public License 2.0
  • Rote Liste (nicht erlaubt in proprietärer kommerzieller Software ohne explizite kommerzielle Lizenz): GPL 2.0, GPL 3.0, AGPL 3.0, EUPL 1.2 (in bestimmten Anwendungsszenarien)

Diese Policy muss den Entwicklern bekannt sein und sollte in SCA-Tools konfiguriert werden, die dann automatisch bei Policy-Verletzungen warnen.

Schritt 5: SBOM als lebendiges Dokument etablieren

Ein SBOM ist kein einmaliger Audit-Output – es ist ein Dokument, das mit jeder Softwareversion aktualisiert werden muss. Automatisieren Sie die SBOM-Generierung als Teil Ihres Build-Prozesses. Standardisierte Formate wie SPDX (Linux Foundation, ISO-Standard 5962:2021) oder CycloneDX werden von der Regulatorik zunehmend anerkannt und von den meisten SCA-Tools nativ exportiert.

Das SBOM sollte für jede Produktionsversion archiviert werden – nicht nur das aktuelle. Im Falle einer später entdeckten Schwachstelle (wie bei Log4Shell, die Monate nach Einführung öffentlich wurde) müssen Sie wissen, welche Ihrer vergangenen Versionen betroffen waren.

Schritt 6: Kontinuierliches Vulnerability Monitoring für Abhängigkeiten

CVEs für Bibliotheken, die Sie heute einsetzen, werden morgen oder nächste Woche veröffentlicht. Richten Sie automatisches Monitoring ein, das Sie benachrichtigt, sobald eine neue Schwachstelle in einer Ihrer Abhängigkeiten bekannt wird. GitHub Dependabot (kostenfrei für GitHub-Nutzer), Snyk Monitor oder FOSSA bieten diese Funktion. Definieren Sie klare SLAs für das Patchen bekannter Schwachstellen analog zu Ihren System-Patches: Kritische CVEs innerhalb von 24-48 Stunden, High CVEs innerhalb von 7 Tagen.

Die Rückkehr zu Hoffmann Maschinenbau

Thomas Langer und sein Team haben ihre Lehren gezogen. Drei Monate nach dem Audit sieht die Entwicklungslandschaft bei Hoffmann Maschinenbau GmbH anders aus. Snyk ist als GitHub-Actions-Step in die CI/CD-Pipeline integriert – jeder Pull Request durchläuft automatisch einen Scan. Eine Lizenz-Policy wurde formal verabschiedet und ins Entwickler-Onboarding integriert. GPL-Bibliotheken sind explizit als rote Liste konfiguriert. Entwickler werden bei neuen Abhängigkeiten durch einen internen Slack-Bot daran erinnert, den Lizenztyp zu prüfen.

Die KI-Coding-Tools laufen weiter – Copilot und Cursor sind fester Bestandteil des Workflows. Aber sie laufen jetzt mit einem Sicherheitsnetz. Die Entwicklungsgeschwindigkeit ist immer noch deutlich höher als vor der KI-Einführung. Die Compliance-Risiken sind kontrollierbar geworden.

Als FossID im April 2026 Agentic SCA ankündigt, steht Hoffmann Maschinenbau bereits auf der Warteliste für den Beta-Zugang. „Wir hatten gedacht, das Problem ist zu komplex, um es richtig anzugehen", sagt Langer rückblickend. „Dabei ist der Einstieg gar nicht so schwer. Man muss nur anfangen."

Ausblick: Code-Hygiene als strategische Kompetenz

Agentic SCA ist ein Vorgeschmack auf das, was kommen wird: Systeme, die nicht reaktiv prüfen, was bereits gebaut wurde, sondern proaktiv und kontinuierlich sicherstellen, dass das Entstehende von Anfang an sauber ist. In einer Welt, in der KI-Systeme täglich Millionen Zeilen Code erzeugen, wird Code-Hygiene zur kritischen Infrastruktur – nicht zum lästigen Verwaltungsakt.

Für Unternehmen, die heute in Software-Entwicklung investieren – ob für eigene Produkte oder interne Tools –, ist der Aufbau einer SCA-Praxis keine optionale Zusatzmaßnahme. Sie ist Grundvoraussetzung für regulatorische Compliance (CRA, NIS2), für wirtschaftliche Absicherung gegen Lizenzklagen, und zunehmend auch für das Vertrauen von Kunden, Partnern und Investoren.

Die gute Nachricht: Der Einstieg ist heute leichter als je zuvor. Die Tools sind ausgereift, die CI/CD-Integrationen gut dokumentiert, die Community groß. Was fehlt, ist oft nur der erste Schritt: eine ehrliche Bestandsaufnahme dessen, was tatsächlich in der eigenen Software steckt.

Das pleXtec-Team unterstützt Sie bei der Einführung von SCA-Prozessen, der Integration in bestehende Entwicklungsumgebungen und der Definition einer unternehmensweiten Lizenz-Policy. Erfahren Sie mehr in unserem Bereich Softwareentwicklung oder sprechen Sie uns direkt über das Kontaktformular an. Für strategische Fragen zur Compliance empfehlen wir zudem unsere Seiten zu Compliance-Software und Informationssicherheit.