Ein Softwareunternehmen, das ISO 27001 hält und ISO 9001 zum ersten Mal liest, erkennt das meiste wieder. Kontext, Führung, Planung, Unterstützung, Bewertung der Leistung und Verbesserung, die Abschnitte 4 bis 7, 9 und 10, sind die Harmonized Structure: dasselbe Gerüst mit „Qualität", wo die andere Norm „Informationssicherheit" sagt. Dann erreicht es Abschnitt 8, Betrieb, und findet Produktion, Rückverfolgbarkeit, Erhaltung von Ergebnissen und das Eigentum der Kunden, geschrieben für Organisationen, die Dinge herstellen und liefern. Die Versuchung ist, das meiste davon für nicht anwendbar zu erklären. Das ist die falsche Lesart: Abschnitt 8 gilt für Software in vollem Umfang, er muss nur übersetzt werden, und die Übersetzung ist, was dieser Artikel tut, Unterabschnitt für Unterabschnitt, in unserer Lesart des Textes; der Wortlaut der ISO wird nicht wiedergegeben. In unserem eigenen Abschnittsregister ist Abschnitt 8, wo die ehrlichen Lücken liegen, und die Übersetzung unten ist, was diese Aufzeichnungen enthalten müssten.

8.1 Betriebliche Planung und Steuerung

Der Abschnitt verlangt von der Organisation, die Prozesse zu planen und zu steuern, die ihre Produkte und Dienstleistungen liefern: Kriterien für die Prozesse und für die Annahme, die Ressourcen und genügend dokumentierte Information, um darauf vertrauen zu können, dass die Prozesse wie geplant liefen. Für Software ist das die Definition, wie ein Feature von der Anfrage in die Produktion gelangt, und die Annahmekriterien an jedem Schritt. Es ist auch die eine Stelle, an der Abschnitt 8 ausgegliederte Prozesse nennt, was für ein Softwareunternehmen die Cloud-Plattform ist, auf der es läuft.

8.2 Anforderungen an Produkte und Dienstleistungen

8.2.1 ist die Kommunikation mit dem Kunden: wie ein Kunde erfährt, was das Produkt tut, wie er bestellt, wie er sich beschwert und wie sein Eigentum (im Fall eines Softwareunternehmens Daten) behandelt wird. 8.2.2 ist die Bestimmung der Anforderungen: was das Produkt tun muss, einschließlich der gesetzlichen und behördlichen Anforderungen, die für es gelten. 8.2.3 ist die Überprüfung dieser Anforderungen, bevor die Organisation sich zur Lieferung verpflichtet, mit aufbewahrten Ergebnissen, und es ist der Unterabschnitt, an dem Softwareunternehmen am häufigsten scheitern: Ein Vertrag mit einer kundenspezifischen Zusage, den niemand in der Entwicklung überprüft hat, ist eine Nichtkonformität gegen 8.2.3, was immer die Entwickler später erreichen. 8.2.4 ist Änderungen an Anforderungen, was in einem Abonnementprodukt jede Release-Notiz ist.

Für ein Softwareunternehmen haben „gesetzliche und behördliche Anforderungen" jetzt einen bestimmten Inhalt: Ab dem 11. Dezember 2027 sind die grundlegenden Anforderungen des Anhangs I des Cyber Resilience Act Anforderungen an das Produkt im Sinne von 8.2.2, und eine Anforderungsbewertung, die sie nicht berücksichtigt, ist unvollständig.

8.3 Entwicklung

Das ist der Softwareentwicklungslebenszyklus, und der Unterabschnitt, der sich am direktesten abbilden lässt. 8.3.2, Planung, ist die Definition des Prozesses: Phasen, Überprüfungen, Verifizierung und Validierung, Verantwortlichkeiten, woran der Kunde beteiligt ist, und die aufzubewahrende dokumentierte Information. 8.3.3, Eingaben, sind die Anforderungen, von denen ein Stück Arbeit ausgeht, einschließlich gesetzlicher und behördlicher, und was aus früheren Produkten gelernt wurde. 8.3.4, Steuerungsmaßnahmen, ist die Unterscheidung, die die Norm zieht und die Entwicklungsteams meist verwischen: Überprüfungen (entspricht das Design dem Plan), Verifizierung (entspricht das Ergebnis den Eingabeanforderungen, also Code-Review und Testsuite) und Validierung (entspricht das Produkt seinem Verwendungszweck, also Abnahme durch oder im Namen des Nutzers). 8.3.5, Ergebnisse, ist, was die Entwicklung verlässt: das Artefakt, seine Dokumentation, die Annahmekriterien, gegen die es geprüft wurde. 8.3.6, Änderungen, ist die Änderungssteuerung am Design, mit aufbewahrter Überprüfung, Autorisierung und jeder Maßnahme gegen nachteilige Auswirkungen.

Ein Unternehmen, das seine Arbeit in einem Ticketsystem führt, Code überprüft, Tests ausführt und eine Definition of Done hat, hat die meisten Aufzeichnungen, die 8.3 verlangt. Was ihm meist fehlt, ist die Aufzeichnung, die sie je Änderung zusammenbindet: welche Eingabe, welche Überprüfung, welche Verifizierung, welche Validierung, wer autorisiert hat.

8.4 Extern bereitgestellte Prozesse, Produkte und Dienstleistungen

8.4.1 verlangt, externe Anbieter zu bewerten, auszuwählen, zu überwachen und neu zu bewerten, mit Aufzeichnungen; 8.4.2, dass Art und Umfang der Steuerung dem entsprechen, wie stark das Ergebnis des Anbieters das Produkt beeinflusst; 8.4.3, dass dem Anbieter mitgeteilt wird, was von ihm verlangt wird. Für Software sind die externen Anbieter drei Arten: die Cloud-Plattform und die SaaS-Werkzeuge, auf denen das Produkt läuft, ausgegliederte Prozesse nach 8.4.1; die Open-Source- und kommerziellen Komponenten im Produkt, extern bereitgestellte Produkte; und Auftragnehmer, die Code schreiben. Bei der zweiten Art treffen sich 8.4 und der Cyber Resilience Act: Die Sorgfaltspflicht, die Artikel 13(5) für Komponenten verlangt, ist die Steuerung nach 8.4.2 für eine Softwareabhängigkeit, und dieselbe Aufzeichnung dient beiden.

8.5 Produktion und Dienstleistungserbringung

Der Unterabschnitt mit dem meisten Übersetzungsbedarf. 8.5.1, beherrschte Bedingungen, ist die Bereitstellung: der dokumentierte Prozess, die Überwachung an den entscheidenden Stellen, Infrastruktur und Umgebung, kompetente Personen und die Validierung von Prozessen, deren Ergebnis sich nachträglich nicht verifizieren lässt, was in einem Softwareunternehmen die Bereitstellungspipeline selbst ist. 8.5.2, Kennzeichnung und Rückverfolgbarkeit, sind Versionen und Build-Kennungen: welcher Build in Produktion ist, welcher Kunde welche Version nutzt, und die Fähigkeit, ein Ergebnis durch seine Geschichte zurückzuverfolgen, wo Rückverfolgbarkeit gefordert ist. 8.5.3, Eigentum der Kunden oder externer Anbieter, ist der Unterabschnitt, den ein SaaS-Unternehmen am sorgfältigsten lesen muss: Kundendaten, Zugangsdaten und Inhalte sind Kundeneigentum im Sinne der Norm, zu kennzeichnen, zu verifizieren, zu schützen und zu sichern, und ein Verlust oder Schaden ist dem Kunden mit aufbewahrter Aufzeichnung zu melden. 8.5.4, Erhaltung, sind Backups und die Integrität des gelieferten Artefakts. 8.5.5, Tätigkeiten nach der Lieferung, sind Support, Wartung und Updates, solange die Organisation sie zugesagt hat, was unter dem Cyber Resilience Act der Unterstützungszeitraum mit Sicherheitsupdates über seine Dauer wird. 8.5.6, Steuerung von Änderungen, ist die Änderungssteuerung in der Produktion, mit aufbewahrter Überprüfung, autorisierender Person und jeder Maßnahme.

8.6 Freigabe von Produkten und Dienstleistungen

Die Freigabe erfolgt erst, wenn die geplanten Vorkehrungen abgeschlossen sind, sofern nicht eine zuständige Stelle und gegebenenfalls der Kunde etwas anderes genehmigen; die Aufzeichnung zeigt den Nachweis der Konformität mit den Annahmekriterien und wer die Freigabe autorisiert hat. Für Software ist das das Freigabetor: die Kriterien, gegen die der Build geprüft wurde, der Nachweis und die benannte Person, die ihn freigegeben hat. Ein Unternehmen, das kontinuierlich bereitstellt, hat trotzdem bei jeder Bereitstellung eine Freigabe im Sinne der Norm, und das Tor sind die Prüfungen der Pipeline plus die Genehmigung, die eine Änderung durchlässt; die Aufzeichnung ist das Protokoll der Pipeline, sofern es die Kriterien und den Genehmigenden nennt.

8.7 Steuerung nichtkonformer Ergebnisse

Ein Ergebnis, das nicht konform ist, wird gekennzeichnet und gesteuert, damit es nicht unbeabsichtigt geliefert oder verwendet wird: korrigiert, ausgesondert, der Kunde informiert oder eine Sonderfreigabe eingeholt; und die Aufzeichnung sagt, was die Nichtkonformität war, was getan wurde, jede Sonderfreigabe und wer entschieden hat. Für Software sind nichtkonforme Ergebnisse die Fehler, die einen Kunden erreicht haben, die Vorfälle, das Release, das zurückgezogen werden musste. Der Bugtracker hält den Großteil der Aufzeichnung bereits; was 8.7.2 hinzufügt, ist die Entscheidung, insbesondere die Sonderfreigabe, also die Entscheidung, einen bekannten Fehler auszuliefern oder zu belassen, durch jemanden mit der Befugnis dazu. Ein bekannter Fehler, der ohne diese Entscheidung ausgeliefert wird, ist die Nichtkonformität, die ein Auditor aufschreibt, nicht der Fehler selbst.

Was das zusammen ergibt

So gelesen, ist Abschnitt 8 für ein Softwareunternehmen sechs Aufzeichnungen, die das Unternehmen in seinen Ticket-, Code-Review-, CI- und Vorfallwerkzeugen größtenteils bereits erzeugt, plus die Entscheidungen, die diese Werkzeuge nicht aufzeichnen: die Anforderungsbewertung vor einer Zusage, die Autorisierung einer Designänderung, die Freigabegenehmigung und die Sonderfreigabe für einen bekannten Fehler. Die Aufgabe des Managementsystems ist, diese Entscheidungen neben den Artefakten zu halten, sodass ein Auditor, oder der Auditor eines Kunden, einer Änderung von der Anfrage bis zur Freigabe folgen kann, mit jeder Prüfung und jedem Namen an seinem Platz. Für welche Unterabschnitte des Abschnitts 8 StandardOS Aufzeichnungen hält und für welche nicht, ist Abschnitt für Abschnitt veröffentlicht; die übrigen Abschnitte, die dokumentierte Information und die Managementbewertung darunter, sind die, die ein ISO-27001-Unternehmen bereits betreibt.

Quellen

  • ISO 9001:2015, Abschnitte 8.1 bis 8.7, nach Nummer zitiert; der Text gehört der ISO und wird nicht wiedergegeben.
  • Verordnung (EU) 2024/2847 (CRA), Artikel 13(5) und (8), Anhang I, dafür, wo dieselben Aufzeichnungen von einem Softwareprodukt verlangt werden.

Dies ist keine Zertifizierungsberatung. Wie weit ein Unterabschnitt auf ein bestimmtes Produkt anwendbar ist, wird im Anwendungsbereich der Organisation entschieden und dort begründet; die Übersetzung oben ist unsere.