ISO 27001 für Softwareunternehmen: was die Norm wirklich verlangt

Avatar
Autor

ISO 27001 für Softwareunternehmen sieht anders aus als das Bild, das die meisten im Kopf haben. Üblich ist die Vorstellung von Richtlinien, Ordnern und einem abgeschlossenen Serverraum. In einem Unternehmen, dessen Produkt Code ist, greift der größte Teil der Norm stattdessen im Lieferprozess, bei Entscheidungen, die Entwicklerinnen und Entwickler jede Woche treffen.

Das ist in zwei Richtungen relevant. Wenn Sie Software einkaufen, zeigt es Ihnen, welche Fragen tatsächlich prüfen, ob das Zertifikat eines Anbieters etwas bedeutet. Wenn Sie ein Softwareunternehmen sind, das über eine Zertifizierung nachdenkt, zeigt es, wie viel der Arbeit Technik und nicht Dokumentation ist.

Es folgen die sechs Bereiche, in denen die Norm in einer Entwicklungsorganisation am stärksten greift, und zu jedem der Nachweis, den ein Kunde vernünftigerweise verlangen kann.

Ein Zertifikat belegt, dass ein Auditor das System geprüft hat. Der Geltungsbereich sagt Ihnen, ob er den Teil geprüft hat, der Ihre Software baut.

Was ISO 27001 für Softwareunternehmen tatsächlich verlangt

Die Norm zertifiziert ein Informationssicherheits-Managementsystem, was administrativ klingt, bis man betrachtet, wo die Kontrollen wirken müssen. In einer Beratung sind das Büros und Notebooks. In einem Softwareunternehmen sind es Repositories, Build-Pipelines, Umgebungen und die Personen, die zu allen dreien Zugangsdaten haben.

Dasselbe Zertifikat bedeutet also etwas deutlich anderes, je nachdem, was die Organisation tut. ISO 27001 für Softwareunternehmen konzentriert sich daher an Stellen, die eine allgemeine Auditzusammenfassung nie erwähnt. Die beiden Spalten unten zeigen, wo das Gewicht in einem Entwicklungsteam liegt.

Was man erwartet
Richtlinien und Papierkram
Ein dokumentiertes Richtlinienwerk, ein Asset-Register, Schulungsnachweise und eine Managementbewertung. Echte Anforderungen, und der Teil, den die meisten Beratungen verkaufen.
Was es in der Praxis bedeutet
Der Lieferprozess
Code Review, Dependency Management, Trennung der Umgebungen, Repository-Zugriffe, Bewertung von Unterauftragnehmern und Incident Response, nachgewiesen statt beschrieben.
Beides wird auditiert. Nur das Zweite sagt Ihnen etwas über die Software, die Sie gleich beauftragen.

Diese Unterscheidung erklärt ein Muster, das Einkäufern auffällt, sobald sie darauf achten. Eine Beratung und ein Entwicklungshaus können Zertifikate halten, die auf der ersten Seite fast gleich klingen, während die zugrunde liegenden Audits völlig Unterschiedliches geprüft haben. Das eine sah Notebooks, Schulungsnachweise und ein Risikoregister. Das andere sah all das plus die Pipeline, die Code in die Produktion bringt.

Sechs Bereiche, in denen ISO 27001 für Softwareunternehmen die Lieferung berührt

Keiner davon ist exotisch. Viele Teams arbeiten bereits so, denn die Praktiken sind älter als die Norm und existieren aus technischen und nicht aus Compliance-Gründen. Was ISO 27001 für Softwareunternehmen hinzufügt, ist nicht die Praxis selbst, sondern ein externer Auditor, der sie prüft und jedes Jahr wiederkommt.

Code Review vor dem Merge. Änderungen erreichen den Hauptbranch über ein Review und nicht daran vorbei. Nachweis: Branch-Protection-Regeln und Review-Historie, rückwirkend schwer zu fälschen.
Dependency Management. Ein Verzeichnis dessen, was im Build steckt, und ein Prozess für den Fall, dass eine Komponente sich als verwundbar erweist. Nachweis: ein Komponenteninventar auf Anfrage, und wie schnell es kommt.
Trennung der Umgebungen. Entwicklung, Staging und Produktion getrennt, mit kontrollierter Promotion dazwischen und ohne Produktionsdaten in der lokalen Datenbank eines Entwicklers. Nachweis: Dokumentation des Deployment-Prozesses und Zugriffsgrenzen.
Zugriffe auf Repositories und Infrastruktur. Nach Least Privilege mit dokumentierter Freigabe erteilt, danach regelmäßig überprüft statt einmal vergeben und vergessen. Nachweis: Protokolle der Zugriffsüberprüfung und das Offboarding-Verfahren.
Bewertung von Unterauftragnehmern. Jeder Dritte wird bewertet, bevor er ein Projekt berührt, einschließlich Freelancern und Partneragenturen. Nachweis: der Lieferantenbewertungsprozess und eine aktuelle Liste der Unterauftragnehmer.
Incident Response mit Fristen. Erkennung, Klassifizierung, Meldung und Nachbereitung, schriftlich festgehalten und getestet statt improvisiert. Nachweis: das Verfahren und ein Protokoll einer Übung.

Das Offboarding verdient besondere Aufmerksamkeit, denn dort unterscheiden sich zertifizierte und nicht zertifizierte Organisationen am sichtbarsten. Zugriffe zu erteilen gelingt leicht, weil jemand darauf wartet. Zugriffe in der Woche zu entziehen, in der eine Entwicklerin das Projekt verlässt, drängt niemand, und genau deshalb fragt ein Auditor danach.

Das Dependency Management ist der andere verlässliche Unterscheider geworden, vor allem wegen der Art, wie Software heute gebaut wird. Eine moderne Anwendung enthält Hunderte von Drittkomponenten, und jede ist ein Weg in Ihre Systeme, wenn niemand sie verfolgt. Ein Team, das auf Anfrage ein belastbares Inventar liefert, weiß bereits, was es ausliefert.

Fordern Sie von einem Anbieter ein aktuelles Komponenteninventar an. Die Antwortzeit sagt mehr als das Dokument selbst.
Sie bewerten einen Softwarelieferanten und möchten diese sechs Bereiche an einem echten Anbieter testen?
Sprechen Sie mit unserem Team

Welche Nachweise Sie von einem zertifizierten Softwarelieferanten verlangen

Die Zertifizierung sagt Ihnen, dass ein Auditor zufrieden war. Sie sagt Ihnen nicht, was er geprüft hat, und deshalb sind drei konkrete Anfragen mehr wert als ein zwanzigseitiger Fragebogen.

Drei Anfragen, die das Zertifikat prüfen
Der Geltungsbereich
Nennt er Softwareentwicklung, Bereitstellung und Support, oder nur eine Zentrale?
Die Zugriffsüberprüfung
Wer Zugriff auf Repositories und Produktion hat, wann zuletzt überprüft wurde und was das Offboarding entfernt.
Der letzte Vorfall
Was passiert ist, wer informiert wurde und was sich danach geändert hat. Eine echte Antwort ist konkret.
Ein Anbieter mit vorhandenen Prozessen beantwortet alle drei in Tagen. Vagheit beim dritten ist das stärkste Signal, denn ein getestetes Verfahren erzeugt eine Geschichte, ein ungetestetes eine Beschreibung.

Warum der Geltungsbereich alles entscheidet

Zwei Zertifikate können dieselbe Norm, dieselbe akkreditierte Stelle und dasselbe Logo tragen und dabei völlig unterschiedliche Tätigkeiten abdecken. Das eine lautet "Informationssicherheits-Management für die Unternehmenszentrale". Das andere lautet "Konzeption, Entwicklung, Bereitstellung, Wartung und Support von Software und IT-Lösungen".

Nur das zweite sagt Ihnen, dass die Entwickler, die Ihren Code schreiben, innerhalb des zertifizierten Systems arbeiten. Diesen Absatz zu lesen dauert dreißig Sekunden und klärt mehr über ISO 27001 für Softwareunternehmen als jeder Fragebogen, und trotzdem öffnet ihn fast niemand.

Der Geltungsbereich sagt Ihnen auch, ob externe Personen abgedeckt sind. Wenn ein Anbieter Entwickler in Ihre Organisation setzt oder über Partneragenturen arbeitet, ist das Zertifikat nur dann nützlich, wenn diese Konstellationen im zertifizierten System liegen. Ein Geltungsbereich, der bei Festangestellten endet, lässt genau das Modell aus, das Sie einkaufen.

Caixa Mágica Software hält das Zertifikat 26ISMS-1252 nach ISO/IEC 27001:2022, mit einem Geltungsbereich, der Konzeption, Entwicklung, Bereitstellung, Wartung und Support von Software und IT-Lösungen umfasst, einschließlich Nearshore- und Team-Augmentation-Dienstleistungen. Sie können nachlesen, was unsere Zertifizierung abdeckt oder sie direkt in der IAF-CertSearch-Datenbank prüfen.

Wann sich ISO 27001 für Softwareunternehmen lohnt

Für ein Softwareunternehmen, das über eine Zertifizierung nachdenkt, ist die ehrliche Rechnung kaufmännisch und nicht technisch. Sind Ihre Kunden wesentliche oder wichtige Einrichtungen nach NIS2, Finanzunternehmen nach DORA oder öffentliche Verwaltung, kommt die Anforderung ohnehin über deren Verträge und Fragebögen. Einmal zu zertifizieren kostet weniger, als dieselben Fragen zwanzigmal im Jahr zu beantworten.

Ist keiner Ihrer Kunden reguliert, ist das Argument für ISO 27001 für Softwareunternehmen schwächer und die Arbeit real. Rechnen Sie mit weniger Dokumentationsaufwand als befürchtet und mit mehr Prozessdisziplin, vor allem bei Zugriffsüberprüfungen und der Aufbewahrung von Nachweisen.

Eines sollten Sie vorab entscheiden: wie breit der Geltungsbereich sein soll. Ein enger Geltungsbereich ist günstiger zu erreichen und deutlich weniger nützlich, denn Einkäufer, die ein Zertifikat lesen können, merken es. Die gesamte Lieferkette abzudecken kostet in der Vorbereitung mehr und beantwortet später weit mehr Fragen.

Häufige Fragen

Fünf Fragen tauchen immer auf, wenn Zertifizierung und Softwarelieferung aufeinandertreffen, deshalb stehen die Antworten hier gesammelt.

Was verlangt ISO 27001 von einem Softwareunternehmen?
Über das dokumentierte Managementsystem hinaus greifen die Kontrollen im Lieferprozess: Code Review vor dem Merge, Dependency Management mit Verzeichnis des Build-Inhalts, Trennung von Entwicklung, Staging und Produktion, Zugriffe auf Repositories und Infrastruktur nach Least Privilege mit regelmäßiger Überprüfung, Bewertung von Unterauftragnehmern und ein getestetes Incident-Response-Verfahren mit definierten Fristen.
Zertifiziert ISO 27001 die Software, die ein Unternehmen baut?
Nein. Die Norm zertifiziert das Managementsystem der Organisation, nicht einzelne Produkte, Plattformen oder Anwendungen. Wer behauptet, ein bestimmtes Produkt sei ISO 27001 zertifiziert, hat die Norm falsch gelesen. Das Zertifikat deckt jedes Projekt innerhalb des angegebenen Geltungsbereichs ab.
Wie lange dauert die ISO 27001 Zertifizierung in einem Softwareunternehmen?
Das hängt weit mehr von der bestehenden Praxis ab als von der Unternehmensgröße. Teams, die Code Review, Zugriffskontrolle und Dependency Management bereits betreiben, dokumentieren und belegen im Wesentlichen das, was sie ohnehin tun. Teams, die bei null anfangen, ändern ihre Arbeitsweise, was erheblich länger dauert. Das Zertifikat gilt danach drei Jahre, mit jährlichen Überwachungsaudits.
Welche Nachweise kann ein Kunde von einem zertifizierten Anbieter verlangen?
Den Geltungsbereich, ein aktuelles Komponenteninventar, Protokolle der Zugriffsüberprüfung, das Offboarding-Verfahren, das Incident-Response-Verfahren samt Übungsprotokoll und die Liste der Unterauftragnehmer. Die Antwortzeit ist oft aufschlussreicher als die Dokumente, denn ein Anbieter mit funktionierenden Prozessen liefert sie in Tagen.
Reicht ISO 27001 für NIS2 oder DORA aus?
Sie beantwortet einen großen Teil der Lieferkettenfrage, aber nicht alles. Meldefristen, ein benannter Sicherheitskontakt und der Datenstandort hängen an Ihren eigenen Meldepflichten und müssen weiterhin vertraglich vereinbart werden. Die Zertifizierung deckt das zugrunde liegende Managementsystem ab, nicht die Bedingungen Ihrer konkreten Vereinbarung.
Caixa Mágica Software
Team Caixa Mágica
Caixa Mágica Software ist ein portugiesisches Softwareunternehmen seit 2000. Kundenspezifische Software, KI-Plattformen und Nearshore-Entwicklung für europäische Unternehmen in PT, DE und UK.
Softwareentwicklung · Caixa Mágica Software
Fordern Sie alle drei an
Den Geltungsbereich, die Zugriffsüberprüfung, den letzten Vorfall. Unser Zertifikat deckt die gesamte Lieferkette einschließlich Nearshore-Teams ab und ist in der IAF-Datenbank prüfbar, ohne uns überhaupt zu fragen.