Viele Unternehmen lesen die Anforderug ISO 27001 A.5.32 "Geistige Eigentumsrechte" und denken zuerst an Patente, Markenanmeldungen und große Rechtsabteilungen. In der Praxis ist das Thema meistens viel bodenständiger. Es geht darum, dass Ihr Unternehmen sauber regelt, was Sie nutzen dürfen, wem was gehört und wie Sie das im Zweifel nachweisen. Gerade in der Softwareentwicklung ist das kein Randthema, weil moderne Produkte fast immer auf Fremdkomponenten, Bibliotheken, Frameworks, Tools und sonstigen Inhalten aufbauen. OpenChain beschreibt Open Source bspw. als essenziellen Teil moderner Softwareentwicklung und betont, dass Nutzung, Änderung und Weitergabe an die jeweiligen Lizenzbedingungen gebunden sind.
Genau deshalb ist A.5.32 nicht bloß ein Thema für die Rechtsabteilung. Es ist ein Thema für Entwicklung, Einkauf, IT, Marketing und die Fachbereiche. Denn Probleme entstehen oft nicht dort, wo jemand absichtlich Rechte verletzt, sondern dort, wo schnell etwas eingebaut, heruntergeladen, kopiert oder weiterverwendet wird, ohne dass jemand die Bedingungen sauber geprüft hat. Der European IP Helpdesk beschreibt ein IP-Audit genau deshalb als strukturierte Bestandsaufnahme, bei der rechtlicher Status, Eigentum und strategische Bedeutung geprüft werden.
Die kurze Antwort
ISO 27001 A.5.32 verlangt in der Praxis kein juristisches Kunststück, sondern ein brauchbares Verfahren. Ihr Unternehmen sollte festlegen, wie mit Softwarelizenzen, Open-Source-Komponenten, Code-Snippets, Bildern, Icons, Fonts, Vorlagen, Logos, Dokumenten und eigenen Arbeitsergebnissen umzugehen ist. Das Ziel ist einfach: Rechte Dritter nicht verletzen und eigene Rechte nicht versehentlich aus der Hand geben.
Für die meisten Unternehmen heißt das: zugelassene Bezugsquellen, klare Freigaben, nachvollziehbare Lizenzprüfung bei relevanten Komponenten, saubere Vertragsregelungen mit Dienstleistern und eine einfache Dokumentation, aus der hervorgeht, was genutzt wird und unter welchen Bedingungen. OpenChain nennt dafür unter anderem eine interne OSS-Policy, eine SBOM und fortlaufende Prüfungen auf Schwachstellen und Lizenzthemen als verhältnismäßige Best Practices.
Worum es bei A.5.32 in der Praxis wirklich geht
Der Kern von A.5.32 ist nicht nur "Schützen", sondern auch "Respektieren". Sie sollen also nicht nur Ihr eigenes geistiges Eigentum sichern, sondern auch vermeiden, dass Ihr Unternehmen Rechte Dritter verletzt: Es geht um die Einhaltung geistiger Eigentumsrechte, einschließlich der legalen Nutzung gekaufter, abonnierter oder geleaster Software.
Für die Softwareentwicklung (ob intern oder auch ausgelagert) bedeutet das vor allem:
- Nur weil eine Bibliothek öffentlich verfügbar ist, heißt das noch lange nicht, dass sie automatisch unproblematisch ist.
- Und nur weil ein Mitarbeiter ein hilfreiches Tool, ein Icon-Pack oder eine Vorlage schnell herunterladen kann, heißt das noch lange nicht, dass Ihr Unternehmen es im geschäftlichen Kontext auch nutzen darf.
Genau an dieser Stelle wird A.5.32 praktisch.
Der häufigste Denkfehler
Der häufigste Denkfehler lautet: "Wenn etwas kostenlos verfügbar ist, wird es schon in Ordnung sein."
"Kostenlos" ist kein Lizenzmodell. Open Source ist ebenfalls nicht gleichbedeutend mit "ohne Bedingungen. Open Source ist nur unter Einhaltung der zugehörigen Lizenzbedingungen in Ordnung - es gibt hier verschiedene gängige Lizenztypen, die festlegen, was in welchem Umfang verändert und verteilt werden darf, unter welche Lizenzbedingung das Ergebnis zu stellen ist und inwieweit kommerzielle Verwendung gestattet ist.
Uns sind persönlich Fälle bekannt, in denen Lieferanten wegen nicht eingehaltener Pflichten rechtlich belangt wurden!
Der zweite Denkfehler lautet: "Wir schauen uns das erst an, wenn das Produkt fertig ist." Auch das ist zu spät. Wer Komponenten, Snippets oder Assets erst am Ende prüft, baut Lizenzrisiken systematisch ins Produkt ein. Genau deshalb empfiehlt die britische Regierungsstudie zu Open-Source-Best-Practices eine interne Policy, eine SBOM und den kontinuierlichen Einsatz von Werkzeugen, die auch Lizenzprobleme sichtbar machen.
Wo Unternehmen typischerweise in Probleme laufen
1. Open-Source-Komponenten, Pakete und Snippets
In fast jedem Softwareprojekt landen heute externe Pakete im Code. Das Problem ist meistens nicht die Nutzung an sich, sondern der fehlende Überblick. Die SPDX License List existiert genau deshalb: Sie stellt standardisierte Kurzkennungen, Lizenztexte und dauerhafte Referenzen bereit, damit Lizenzen eindeutig identifiziert werden können. Wenn in Ihrem Projekt niemand sauber sagen kann, welche wesentlichen Fremdkomponenten enthalten sind und unter welchen Bedingungen sie stehen, ist das ein sehr praktisches Problem.
REUSE geht noch einen Schritt weiter und macht einen sehr pragmatischen Vorschlag: Lizenz- und Copyright-Informationen sollen direkt an den Dateien hängen, damit Menschen und Maschinen erkennen können, was unter welcher Lizenz steht und wem die Rechte zuzuordnen sind. Das ist kein Selbstzweck. Es hilft genau dort, wo Unternehmen sonst in Diskussionen geraten: beim Nachweis.
2. Schnell heruntergeladene Tools, Fonts, Icons und Vorlagen
Nicht nur Entwickler geraten hier in die Falle. Auch Marketing, Vertrieb oder Fachbereiche laden sich schnell einmal Fonts, Bilder, Icons, Präsentationsvorlagen oder kleine Tools herunter. Das Problem: Manche Inhalte dürfen nur unter bestimmten Bedingungen genutzt werden. Bei Creative Commons ist zum Beispiel die NonCommercial-Klausel so definiert, dass die Nutzung nicht primär auf geschäftlichen Vorteil oder geldwerte Gegenleistung gerichtet sein darf. Für ein normales Unternehmen ist das ein Warnsignal, nicht ein Freifahrtschein.
Hinzu kommt: Creative Commons selbst empfiehlt, CC-Lizenzen nicht für Software zu verwenden. Für Software sollen stattdessen passende Softwarelizenzen genutzt werden. Für Logos und Marken empfiehlt Creative Commons CC-Lizenzen ebenfalls nicht, weil das mit dem Zweck von Marken kollidiert und sogar zu Problemen beim Erhalt von Markenrechten führen kann. Das ist ein guter Hinweis für die Praxis: Nicht alles, was "irgendwie lizenziert" ist, passt auch zu jedem Einsatzzweck.
3. Public Domain, CC0 und "das ist doch frei"
Auch bei vermeintlich freien Inhalten lohnt sich sauberes Arbeiten. Creative Commons unterscheidet klar zwischen CC0 und der Public Domain Mark. CC0 ist ein rechtliches Instrument, mit dem Rechteinhaber ihre Rechte so weit wie rechtlich möglich aufgeben. Die Public Domain Mark ist dagegen nur ein Hinweis für Werke, die bereits weltweit als gemeinfrei gelten. Wer das durcheinanderwirft, dokumentiert am Ende zu wenig oder falsch.
Für Unternehmen ist die praktische Folgerung einfach: Selbst wenn Sie Inhalte mit CC0 oder Public-Domain-Hinweis verwenden, sollten Sie Quelle, Fundstelle und Einordnung dokumentieren. Nicht, weil Sie Bürokratie lieben müssen, sondern weil Sie bei Rückfragen sonst nur mit den Schultern zucken können.
4. Eigene Entwicklungen, Agenturen und Freelancer
ISO 27001 A.5.32 betrifft nicht nur fremde Rechte, sondern auch die eigenen. Wenn Agenturen, externe Entwickler oder Freelancer an Code, Texten, Designs, Schulungsunterlagen oder Vorlagen mitarbeiten, sollte vertraglich sauber geregelt sein, wer was in welchem Umfang nutzen darf und welche Rechte übertragen oder eingeräumt werden. Der European IP Helpdesk beschreibt ein IP-Audit als Prüfung von Eigentum, Rechtsstatus und strategischem Wert. Genau daraus folgt in der Praxis: Eigentum und Nutzungsrechte dürfen nicht bloß vermutet werden.
Viele Unternehmen merken erst spät, dass sie zwar etwas "bezahlt" haben, aber die Frage der Rechte nicht sauber geregelt ist. Für ISO 27001 ist das unerquicklich, weil dann weder Schutz noch Nachweis ordentlich funktionieren. A.5.32 wird also sehr schnell zu einem Thema von Vertragsmanagement und Lieferantensteuerung.
Ein pragmatischer Start
Sie brauchen für A.5.32 keine 40-seitige Richtlinie. Vier saubere Entscheidungen reichen für den Anfang oft aus.
Erstens: Legen Sie fest, aus welchen Quellen Software, Pakete, Bilder, Fonts, Vorlagen und Tools bezogen werden dürfen und wer im Zweifel freigibt. Das reduziert Wildwuchs sofort.
Zweitens: Halten Sie für wesentliche Softwareprodukte und Eigenentwicklungen nachvollziehbar fest, welche Fremdkomponenten und Lizenztypen relevant sind. Eine vollständige juristische Abhandlung braucht es dafür nicht. Aber eine vernünftige Übersicht braucht es schon. SBOM und SPDX liefern dafür eine brauchbare Denkweise.
Drittens: Regeln Sie in Verträgen mit Dienstleistern und Agenturen sauber, wem Ergebnisse gehören und welche Nutzungsrechte Ihr Unternehmen erhält. Sonst kaufen Sie Leistung, aber keine Klarheit.
Viertens: Schulen Sie die betroffenen Mitarbeiter kurz und konkret. Nicht mit einer Vorlesung über Urheberrecht, sondern mit drei bis fünf typischen Fallbeispielen aus Ihrem Alltag. A.5.32 lebt im Unternehmen nicht von Paragrafen, sondern von vernünftigen Gewohnheiten. Diese praktische Schlussfolgerung ergibt sich direkt aus den genannten Compliance- und Audit-Ansätzen.
Was will der Auditor sehen?
Ein Auditor will hier in aller Regel nicht hören: "Wir nutzen da halt einiges aus dem Internet, das passt schon." Er will erkennen, dass Ihr Unternehmen ein nachvollziehbares Verfahren hat. Also: Regeln für Beschaffung und Nutzung, Verantwortlichkeiten, gegebenenfalls Freigaben, eine sinnvolle Dokumentation für relevante Assets und den Nachweis, dass Mitarbeiter das Thema verstanden haben. Das passt genau zu der Logik von Control ISO 27001 5.32 und zu dem, was externe Leitfäden als IP-Audit oder Compliance-Programm beschreiben.
Im Audit helfen typischerweise Nachweise wie eine kurze Richtlinie oder Arbeitsanweisung, Vertragsklauseln mit Dienstleistern, eine Liste freigegebener Bezugsquellen, eine Übersicht wesentlicher Fremdkomponenten in Eigenentwicklungen, Hinweise auf Lizenzprüfungen und ein paar konkrete Beispiele aus dem Alltag. Der Auditor sucht kein perfektes Rechtsgutachten. Er sucht Steuerung.
FAQ
Praktisch bedeutet A.5.32, dass Ihr Unternehmen Verfahren braucht, um Rechte Dritter einzuhalten und eigene Rechte sauber zu schützen. Dazu gehören vor allem Regeln für Software, Open Source, Downloads, Vorlagen, Verträge und Nachweise.
Nein. Das ist nur ein Teil. Relevante Risiken entstehen genauso bei Open-Source-Komponenten, Snippets, Bildern, Fonts, Vorlagen, Logos, Datenbanken oder Arbeitsergebnissen externer Dienstleister. A.5.32 wird in seriösen Erläuterungen deshalb ausdrücklich breiter verstanden als nur "keine Raubkopien verwenden".
Nein. Open Source darf genutzt werden, aber nur unter Einhaltung der jeweiligen Bedingungen. OpenChain verweist ausdrücklich auf diese Pflichten und auf reale Streitfälle bei fehlender Compliance.
Nicht pauschal. Bei Creative Commons hängt viel von der konkreten Lizenz ab. Die NonCommercial-Klausel ist ausdrücklich an nicht primär kommerzielle Nutzung gebunden. Außerdem empfiehlt Creative Commons seine Lizenzen nicht für Software und auch nicht für Logos oder Marken als Standardlösung.
Nein. A.5.32 verlangt kein Museumskatalogsystem. Aber für relevante Software, zentrale Fremdkomponenten, wichtige Inhalte und kritische Lieferanten sollten Sie nachvollziehbar dokumentieren können, was genutzt wird und auf welcher Grundlage. Genau diesen Gedanken tragen IP-Audit- und Compliance-Ansätze nach außen.
Starten Sie mit einer kurzen Regel zu Bezugsquellen, Freigaben und Lizenzprüfung für typische Fälle. Wenn Sie Software entwickeln, ergänzen Sie das um eine einfache Übersicht wesentlicher Fremdkomponenten. Das ist deutlich besser als sofort ein riesiges Regelwerk zu bauen.
Unser Tipp
Machen Sie A.5.32 nicht größer als nötig, aber nehmen Sie es ernst. Der beste Einstieg ist fast nie ein umfangreiches Rechtsdokument, sondern eine kleine, klare betriebliche Regel: Was dürfen Mitarbeiter verwenden, wer prüft Zweifelsfälle und wie wird bei wichtigen Komponenten oder Inhalten die Grundlage dokumentiert? Genau damit bekommen Sie das Thema in den Griff, bevor es in Entwicklung, Marketing oder Einkauf still und leise ausfranst.
Interesse geweckt?
Wenn Sie den Umgang mit geistigen Eigentumsrechten im Rahmen einer ISO 27001-Einführung sauber regeln wollen, dann lassen Sie uns sprechen oder schreiben uns etwas gleich hier rechts unten auf der Seite in den Chat!