SOC 2 · ISO 27001

Deckt SOC 2 oder ISO 27001 auch Lizenzpflichten ab?

Nein. Sicherheitszertifizierungen und Drittanbieter-Lizenz-Offenlegung beantworten unterschiedliche Fragen, und beides kann gleichzeitig zutreffen: Sie können ein gültiges Zertifikat besitzen und trotzdem einen geprüften, produktbezogenen Lizenznachweis schulden.

Zuletzt aktualisiert: 2. Juli 2026

01Darum geht es

Die übersehenen Schwachstellen

Das zeigt sich in Due-Diligence-Prüfungen und Audits: Pflichten bestehen, Nachweise fehlen, und das Artefakt, das Käufer erwarten, ist nicht vorhanden.

Open-Source-Lizenzen sind rechtliche Pflichten, keine Vorlieben
MIT, Apache, GPL, LGPL und proprietäre SDK-Vereinbarungen legen Bedingungen fest: Hinweis, Namensnennung, Copyleft, Verbreitungsregeln. Sie zu verfehlen ist ein Lizenzverstoß, keine stilistische Lücke. SOC-2- und ISO-Programme lassen diese Pflichten nicht verschwinden; sie fragen, ob Ihre Kontrollen sie vor der Auslieferung erfassen.
ISO 27001: Geistiges Eigentum ist explizit geregelt
Anhang A 5.32 verlangt Verfahren zur Einhaltung von Rechten des geistigen Eigentums, einschließlich Softwarelizenzen. Auditoren erwarten Nachweise, nicht nur ein Richtlinien-PDF. Fehlt der vorgeschriebene Lizenztext dort, wo Lizenzen ihn verlangen, ist das zugleich eine IP-Verletzung und ein ISMS-Nachweisversagen, wenn Ihre Kontrollen behaupten, Drittanbieter-Software werde gemanagt.
SOC 2: Keine Kontrolle für Lizenzseiten, aber Auditoren verfolgen Spuren
Die Trust Services Criteria nennen nicht wörtlich „alle Lizenzen auf einer Website veröffentlichen“. Auditoren verfolgen dennoch Rechtskonformität und Änderungsmanagement. Systemische Lücken (fehlende Hinweise, ungeprüfter Bestand, kein produktbezogener Nachweis) treten als Kontrollmängel zutage, wenn Stichproben nicht zur Richtlinie passen.
Zertifizierungsumfang ist nicht Produktumfang
Ein SOC 2 Type II- oder ISO-Zertifikat deckt Ihr System und einen Zeitraum ab, nicht automatisch jede Abhängigkeit in jeder SKU. Käufer stellen trotzdem produktspezifische Fragen. Ihre Zertifizierung hilft; sie ersetzt nicht die Drittanbieter-Lizenz-Offenlegung für das vertraglich vereinbarte Produkt.
Nachweispakete veralten zwischen Audits
Teams legen bei der ISO-Überwachungsprüfung dieselbe OSS-Tabelle wie im Vorjahr vor, obwohl die Entwicklung inzwischen zwölf Versionen ausgeliefert hat. Überwachungsprüfer prüfen laufende Systeme stichprobenartig. Stimmen Nachweis und Produktion nicht überein, ist das ein klassischer schwerwiegender Befund. Dieselbe Abweichung kann auch Vertragsverlängerungen in der Beschaffung scheitern lassen.
Eine Sicherheitsprüfung ist keine Lizenzprüfung
Schwachstellen-Scanner und SBOM-Tools identifizieren Komponenten und manchmal Lizenzfelder. Sie fügen keinen vollständigen Lizenztext hinzu, geben kein Copyleft-Risiko frei und veröffentlichen keine käuferfertige Offenlegung. Die Ausgabe von AppSec-Tools mit Lizenzkonformität gleichzusetzen erzeugt trügerische Sicherheit sowohl bei SOC-Nachweisen als auch bei Ausschreibungsantworten.
Copyleft-Überraschungen treffen auch zertifizierte Organisationen
GPL oder AGPL in einem ausgelieferten Produkt ohne Quellcode-Angebot oder Compliance-Prüfung ist ein rechtliches und audit-relevantes Problem, unabhängig von einer ISO-27001-Zertifizierung. Die Entdeckung während der Käufer-Due-Diligence statt bei der internen Prüfung ist der teure Weg.
Käufer wollen Nachweise zusätzlich zu Ihrem Bericht
Großkunden verlangen Ihren SOC-Bericht und einen produktbezogenen Nachweis zu Drittanbieterlizenzen: Bestand, vollständige Texte und Pflegeprozess. Das Trust Center belegt die Sicherheitslage. Die Lizenzoffenlegung deckt die lizenzrechtlichen Pflichten in der Codebasis ab. Beides gehört zu einer gründlichen Anbieterprüfung.

Auf dieser Seite

SOC 2 und ISO 27001 belegen, dass Sie ein Sicherheits- und Managementsystem betreiben: Zugriffskontrolle, Änderungsmanagement, Risikobehandlung, Lieferantenüberwachung. Auditoren prüfen Kontrollgestaltung und operative Wirksamkeit. Keine der beiden Zertifizierungen erfasst standardmäßig jede Open-Source-Lizenzpflicht in jedem ausgelieferten Produkt.

Käufer betrachten eine Zertifizierung als Grundvoraussetzung und fragen getrennt nach der Offenlegung von Drittanbieterlizenzen (vollständige Texte, Namensnennungen und ein produktbezogener Bestand). Eine bestandene SOC-2-Prüfung beantwortet nicht die Frage: „Welche GPL-Komponenten stecken in dem Build, den wir lizenziert haben?“

Was verlangt ISO 27001 tatsächlich bei Open-Source-Lizenzen?

ISO/IEC 27001:2022 verlangt unter Anhang-A-Kontrolle 5.32 den Betrieb von Verfahren, die die Einhaltung von Rechten des geistigen Eigentums sicherstellen, einschließlich Softwarelizenzbedingungen. Eine öffentliche Lizenzseite wird nicht vorgeschrieben, aber ein Auditor kann Nachweise dafür verlangen, dass die Drittanbieter-Lizenzbedingungen in dem, was Sie ausliefern, tatsächlich erfüllt werden.

Ein Kontrolldokument, das ohne Nachweise behauptet, „wir halten OSS-Lizenzen ein“, führt leicht zu einem Prüfungsbefund. Als Nachweise dienen ein geprüfter Bestand, vollständige Lizenztexte und der Abgleich mit den Produktversionen. Besonders kritisch ist es, wenn Stichproben in der Produktion Pakete finden, die auf keiner Liste stehen.

Richtlinie für zulässige Lizenzen und Freigabeprozesse.
Nachweis, dass ausgelieferte Produkte die Bedingungen von Drittanbieter-Lizenzen einhalten.
Prüfprotokolle, nicht nur Ausgaben von Discovery-Scans.
Übereinstimmung zwischen dem, was das ISMS behauptet, und dem, was das Entwicklungsteam ausliefert.
Umgang mit Lizenzänderungen bei Abhängigkeits-Updates.

Worauf SOC-2-Prüfer bei Lizenzen achten

SOC-2-Auditoren verlangen keine öffentliche Lizenzseite; sie verfolgen, ob Ihre Kontrollen zu den AICPA Trust Services Criteria für Rechtskonformität, Lieferantenmanagement und Änderungskontrolle tatsächlich Drittanbieter-Lizenzpflichten erfassen. Nachlässige OSS-Hygiene zeigt sich dort als schwacher Nachweis gemessen an Kriterien, die Sie bereits als erfüllt behaupten.

Auditoren prüfen Systeme stichprobenartig. Sie fragen, woher Sie wissen, dass Drittanbietersoftware korrekt lizenziert ist. „Wir führen npm audit aus“ ist keine Antwort. Ein Zertifizierungszeichen auf Ihrer Website ohne produktbezogenen Bestand ist es ebenfalls nicht.

Kontrolle	Was Auditoren erwarten	Nachweis, der das erfüllt
ISO 27001 A 5.32	Verfahren zur Sicherstellung der IP- und Softwarelizenzkonformität	Geprüfter Bestand mit vollständigem Lizenztext pro ausgeliefertem Produkt
SOC 2 CC2.2	Governance und Aufsicht über Compliance-Pflichten	Prüfprotokolle, die zeigen, wer welche Komponenten wann freigegeben hat
SOC 2 CC8.1	Abhängigkeitsänderungen durchlaufen das Änderungsmanagement	Drift-Protokolle, die Lockfile-Änderungen mit erneuter Prüfung verknüpfen
SOC 2 CC9.2	Risiken durch Drittanbieter- und Lieferantensoftware werden gesteuert	Produktbezogener Offenlegungsnachweis zum Stand der freigegebenen Version

Feststellungen entstehen, wenn eine Richtlinie existiert, der operative Nachweis aber fehlt.

Warum Zertifizierung und Käuferprüfung auseinandergehen

Die Zertifizierung umfasst die Kontrollumgebung, oft ein Trust Center, einen Zeitraum und eine Systemgrenze. Die Prüfung durch den Käufer umfasst dagegen das gekaufte Produkt: diese SKU, diese Version und die heute geltenden Pflichten.

Ihr SOC-2-Bericht deckt ab, wie Sie Änderungen managen. Das Rechtsteam des Käufers verlangt den MIT-Lizenztext für libfoo 2.4.1 im Installer, den es einsetzt. Unterschiedliche Fragen; beide brauchen ehrliche Antworten.

Warum veraltet der Bestand in zertifizierten Organisationen?

Der Bestand veraltet, weil Zertifizierungen regelmäßig stattfinden, während sich Abhängigkeiten laufend ändern. Laut dem Bericht „Open Source Security and Risk Analysis“ von Black Duck enthielten 96 Prozent der geprüften Codebasen Open-Source-Code. Die meisten enthielten zudem Komponenten mit Lizenzkonflikten oder ohne erkennbare Lizenz. Ein jährliches Nachweispaket kann daher nicht erfassen, was jede einzelne Version tatsächlich ausliefert.

Zertifizierte Unternehmen arbeiten auch zwischen den Prüfzyklen Aktualisierungen von Abhängigkeiten ein. Entwickler fügen Pakete hinzu, ohne die Tabelle aus dem ISO-Nachweispaket des Vorjahres zu aktualisieren. Das Zertifikat ist gültig, der Bestand ist veraltet.

Operative Lizenzkonformität bedeutet: bei jeder Version erneut importieren, prüfen und veröffentlichen. Es ist derselbe Pflegezyklus, den CRA und Beschaffung verlangen. Er läuft innerhalb eines ISMS, das bereits belegen soll, dass Sie Risiken durch Drittanbieter steuern.

Nachweise, die Auditoren und Käufer gleichermaßen akzeptieren

Geprüfter Drittanbieterbestand mit Verknüpfung zu Versionskennungen. Vollständige Lizenztexte für jede freigegebene Komponente. Veröffentlichungs- oder Exportstand mit Datum und freigebender Person. Drift-Erkennung bei Änderungen an Lockfiles. Öffentliche oder für Kunden bestimmte Offenlegung, wenn Verträge sie verlangen.

Das Format variiert (URL, PDF-Export, JSON-Paket). Der Nachweis ist der geprüfte Datensatz und der Prozess, nicht der Dateityp.

Lockfiles oder SBOMs für jede Version importieren.
Menschliche Prüfung vor Freigabe, besonders bei Copyleft.
Audit-Trail: Wer hat wann was freigegeben?
Exporte, angehängt an ISO-Nachweise oder SOC-Auditor-Anfragen.
Erneuter Durchlauf bei Abhängigkeitsänderungen, nicht nur jährlich.

Häufige Fehler bei Prüfungen und Vertragsabschlüssen

Richtlinie ohne Bestand. Bestand ohne vollständige Lizenztexte. Vollständige Texte einmal erfasst und nie aktualisiert. Automatische Sicherheitsprüfung mit Lizenzprüfung verwechselt. Ein Trust Center, das Datenschutz und Sicherheit erwähnt, zu OSS aber schweigt. GPL in Produktion, entdeckt durch die Prüfung des Käufers statt durch die eigene.

Jedes dieser Muster führt zu ISO-Feststellungen, SOC-Ausnahmen oder verzögerten Vertragsabschlüssen. Die Lösung sind belastbare Abläufe für Lizenzpflichten, parallel zu den Zertifizierungsprogrammen und nicht als deren Ersatz.

Wie Teams Kontrollen mit Lizenzprozessen verknüpfen

Ordnen Sie Kontrolle 5.32 und die SOC-Kriterien zur Änderungssteuerung konkreten Schritten zu: Import, Prüfung, Veröffentlichung und Drift-Prüfung. Benennen Sie Verantwortliche in Entwicklung und Compliance. Legen Sie Offenlegungsexporte in den ISMS-Nachweisordnern ab. Prüfen Sie Produkte bei der internen Prüfung so, wie es externe Prüfer tun werden.

Zertifizierung belegt Prozessreife. Produktbezogene Lizenznachweise belegen, dass Sie die Pflichten in der Software erfüllen, die Sie verkaufen. Käufer und ISO-Stichprobentests erwarten beides zunehmend gemeinsam.

Wie SourceTrust Nachweise für Zertifizierungen unterstützt

Zertifizierungen belegen, dass Sie ein Managementsystem betreiben. Produktbezogene Lizenznachweise belegen, was ausgeliefert wurde: geprüft, mit vollständigem Text, aktualisiert bei Abhängigkeitsänderungen.

SourceTrust importiert Paketdateien und SBOMs, verlangt eine Prüfung vor der Veröffentlichung und erzeugt einen gepflegten Offenlegungs-Nachweis pro Produkt plus Exporte für ISO-Nachweisordner und Käuferfragebögen. Drift-Prüfungen gleichen Lizenznachweise mit denselben Abhängigkeitsänderungen ab, die Ihre Änderungsmanagement-Kontrollen für SOC 2 bereits erfassen.

Sehen Sie, wie die Plattform funktioniert

Import aus Repositories, Manifesten und SBOMs. Jede Zeile ist eine zu erfüllende Lizenz
Prüf- und Freigabekontrollen. Nachweise, die Auditoren stichprobenartig mit der Produktion abgleichen können
Offenlegungs-Nachweis pro Produkt. Das, wonach Käufer über den SOC-Bericht hinaus fragen
Drift-Warnungen, wenn sich Abhängigkeiten oder Lizenzen zwischen Prüfzyklen ändern

SourceTrust bietet Infrastruktur für Lizenzkonformität, keine Rechtsberatung und keinen Ersatz für Ihre ISO- oder SOC-Prüfgesellschaft. Es hilft Ihnen, Lizenzpflichten in die Praxis umzusetzen. Ihr Rechtsbeistand und Ihre Auditoren bleiben für die Gestaltung Ihrer Kontrollen maßgeblich.