SOC 2 · ISO 27001

Deckt ein bestandenes SOC 2 oder ISO 27001 die Lizenz-Offenlegung 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

01Worauf diese Seite hinweist

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 reichen bei der ISO-Überwachung dieselbe OSS-Tabelle ein, die sie letztes Jahr eingereicht haben, während Engineering zwölf Releases ausgeliefert hat. Überwachungsauditoren nehmen Live-Systeme unter die Lupe. Die Abweichung zwischen Nachweis und Produktion ist eine klassische schwerwiegende Feststellung, und dieselbe Abweichung lässt Vertragsverlängerungen in der Beschaffung scheitern.
Security-Scanning 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 Lizenz-Compliance 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
Enterprise-Kunden verlangen Ihren SOC-Bericht und einen Drittanbieter-Lizenznachweis für das Produkt: Bestand, vollständiger Text, Pflegeprozess. Das Trust Center deckt die Sicherheitslage ab; Lizenz-Offenlegung deckt IP-Pflichten in der Codebasis ab. Beides erscheint in ausgereiften Anbieter-Reviews.

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 Zertifizierung als Grundvoraussetzung und fragen separat nach Drittanbieter-Lizenz-Offenlegung (vollständiger Text, Namensnennung, produktbezogener Bestand). Ein bestandener SOC-2-Audit beantwortet nicht die Frage „welche GPL-Komponenten stecken im 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 „wir respektieren OSS-Lizenzen“ behauptet, ohne Nachweise (geprüfter Bestand, vollständiger Text, Abgleich mit Releases), ist eine Feststellung, die nur auf ihre Entdeckung wartet. Besonders dann, wenn Stichproben Pakete in Produktion 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 Engineering ausliefert.
Umgang mit Lizenzänderungen bei Abhängigkeits-Updates.

Wonach suchen SOC-2-Auditoren in der Praxis bei Lizenz-Compliance?

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 gegen Kriterien, die Sie bereits als erfüllt behaupten.

Auditoren nehmen Systeme stichprobenartig unter die Lupe. Sie fragen, woher Sie wissen, dass Drittanbieter-Software korrekt lizenziert ist. „Wir führen npm audit aus“ ist keine Antwort. Ein Zertifizierungs-Badge auf Ihrer Website ohne produktbezogenen Bestand ist es ebenso wenig.

Kontrolle	Was Auditoren erwarten	Nachweis, der das erfüllt
ISO 27001 A 5.32	Verfahren, die IP- und Softwarelizenz-Compliance sicherstellen	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 Offenlegungs-Nachweis, aktuell zum Release

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

Warum Zertifizierungen und Käufer-Due-Diligence auseinanderlaufen

Der Zertifizierungsumfang ist die Kontrollumgebung: oft ein Trust Center, ein Zeitraum, eine Systemgrenze. Der Umfang der Käufer-Due-Diligence ist das Produkt, das gekauft wird (diese SKU, dieses Release, diese Pflichten heute).

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 Zertifizierung periodisch erfolgt, während sich Abhängigkeiten fortlaufend ändern. Der Black-Duck-Bericht Open Source Security and Risk Analysis fand Open-Source-Code in 96 Prozent der geprüften Codebasen, und die meisten enthielten Komponenten mit Lizenzkonflikten oder ohne erkennbare Lizenz. Ein einzelnes jährliches Nachweispaket kann daher nicht verfolgen, was jedes Release tatsächlich ausliefert.

Zertifizierte Unternehmen mergen zwischen den Audit-Zyklen weiterhin Abhängigkeits-Updates. 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 Lizenz-Compliance bedeutet: erneuter Import bei jedem Release, erneute Prüfung, erneute Veröffentlichung. Derselbe Pflegekreislauf, den CRA und Beschaffung verlangen, innerhalb eines ISMS, das bereits behauptet, Sie würden Drittanbieter-Risiken managen.

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

Geprüfter Drittanbieter-Bestand, verknüpft mit Release-Tags. Vollständiger Lizenztext, hinterlegt bei jeder freigegebenen Komponente. Veröffentlichungs- oder Export-Snapshot mit Datum und Freigebendem. Drift-Erkennung bei Lockfile-Änderungen. Öffentliche oder kundenseitige Offenlegung, wenn Verträge es verlangen.

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

Import aus Lockfiles oder SBOMs pro Release.
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 Fehlermuster in Audits und Deals

Richtlinie ohne Bestand. Bestand ohne vollständigen Lizenztext. Vollständiger Text einmal erfasst und nie aktualisiert. Security-Scan mit Lizenzprüfung verwechselt. Trust Center, das Datenschutz und Sicherheit erwähnt, zu OSS aber schweigt. GPL in Produktion, entdeckt durch den Scan des Käufers, nicht Ihren eigenen.

Jedes dieser Muster erzeugt ISO-Feststellungen, SOC-Ausnahmen oder verzögerte Deals. Die Lösung ist operative Infrastruktur für Lizenzpflichten, parallel zu Zertifizierungsprogrammen, nicht als deren Ersatz.

Wie Teams Kontrollen auf Lizenzarbeit abbilden

Bilden Sie Kontrolle 5.32 und die SOC-Änderungsmanagement-Kriterien auf konkrete Schritte ab: Import, Prüfung, Veröffentlichung, Drift-Prüfung. Benennen Sie Verantwortliche in Engineering und Compliance. Fügen Sie Offenlegungs-Exporte den ISMS-Nachweisordnern bei. Nehmen Sie Produkte beim internen Audit so unter die Lupe, wie es externe Auditoren 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.

Quellen

Wie SourceTrust zertifizierungsgestützte Nachweise 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 Publish-Gates. Nachweise, die Auditoren stichprobenartig gegen die Produktion prüfen 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 Audit-Zyklen ändern

SourceTrust ist Compliance-Infrastruktur, keine Rechtsberatung und kein Ersatz für Ihre ISO- oder SOC-Prüfgesellschaft. Es hilft Ihnen, Lizenzpflichten zu operationalisieren; Ihr Rechtsbeistand und Ihre Auditoren bleiben die Autorität für Ihr Kontrolldesign.