Ab dem 11. September 2026 gelten die Meldepflichten aus Artikel 14 des Cyber Resilience Acts (CRA), ab dem 11. Dezember 2027 die übrigen Anforderungen. Viele Hersteller werden bis dahin Prozesse nach IEC 62443-4-1 im QM-System liegen haben. Ob die Entwicklungsabteilungen danach arbeiten, ist die schwierigere Frage.
Die IEC 62443-4-1 beschreibt den sicheren Produktentwicklungsprozess in acht Praktiken, vom Sicherheitsmanagement über Anforderungen, Design, Implementierung und Verifikation bis zur Behandlung gemeldeter Schwachstellen und zur Bereitstellung von Updates. Die Norm verlangt, dass Sie diese Tätigkeiten festlegen, dokumentieren und anwenden. Wie Ihre Abläufe im Einzelnen aussehen, schreibt sie nicht vor.
Der CRA fordert dokumentierte Prozesse und überlässt Ihnen die Abläufe
Der CRA, die Verordnung (EU) 2024/2847, verlangt an mehreren Stellen einen Prozessnachweis. Anhang I Teil II fordert Verfahren zur Behandlung von Schwachstellen, Artikel 13 Absatz 8 verlangt, dass Sie Schwachstellen über den gesamten Unterstützungszeitraum wirksam bearbeiten, und Anhang VII führt die Beschreibung dieser Prozesse als Bestandteil der technischen Dokumentation auf. Dahinter steht die Wiederholbarkeit. Ein Produkt soll dieselben Sicherheitseigenschaften bekommen, unabhängig davon, welche Abteilung es entwickelt und wer gerade im Urlaub ist.
Konkrete Abläufe schreibt der CRA nicht vor. Er verlangt Ergebnisse und Nachweise, und dasselbe gilt für IEC 62443-4-1 und für die horizontalen Normen der EN 40000-Reihe. Wenn Ihre Entwicklung heute funktioniert, und das tut sie, sonst kämen keine Produkte auf den Markt, dann ist Ihr bestehender Ablauf die richtige Ausgangslage.
Ein konformes Prozessset steht in zwei Monaten, gelebt wird es nach eineinhalb Jahren
Die Dokumente selbst sind schnell fertig: Ein zu IEC 62443-4-1 konformes Prozessset anzupassen und freizugeben, dauert in unseren Projekten erfahrungsgemäß etwa ein bis zwei Monate. Bis alle Abteilungen danach arbeiten, vergehen schnell sechs bis achtzehn Monate. Der Abstand zwischen beiden Zahlen ist das eigentliche Projekt.
Am längsten dauert es dort, wo heute noch nicht nach Prozessen gearbeitet wird. Dann müssen Sie neben den Inhalten auch die Gewohnheit einführen, überhaupt in ein Prozesssystem zu schauen. Wer das nicht berücksichtigt, plant die Freigabe der Dokumente als Projektende und steht dann im Audit, bei dem Anweisung und tägliche Arbeit nicht zusammenpassen.
Woran die Einführung in den Abteilungen scheitert
Bei einem Hersteller vernetzter Geräte, der Firmware und einige Apps entwickelt, haben wir Prozesse nach IEC 62443-4-1 eingeführt. Ein QM-System war vorhanden, mit allgemeinen Entwicklungsprozessen, sogar konform zu ISO/IEC 15288. Für den Alltag in der Entwicklung hatte es jedoch keine Bedeutung. Die Fachabteilungen hatten sich eigene Prozesse ins Wiki nachgebaut, die ihren tatsächlichen Ablauf beschrieben.
Das zentrale System war für ein überschaubares Softwareteam zu komplex. Für verteilte Hardwareentwicklung oder für Automotive wäre es angemessen gewesen, für Firmware und Apps war es das nicht.
Beim Überarbeiten stellte sich zudem heraus, dass sich niemand an die zentralen Prozesse hielt und eine Abteilung die konzernweiten Vorgaben nicht einmal kannte. Aufgefallen ist das erst, als wir die Security-spezifischen Anforderungen ergänzen wollten. Der CTO war bis dahin davon ausgegangen, dass alle Abteilungen sich daran halten. Wenn Sie Prozessbeschreibungen im Wiki einer Fachabteilung finden, brauchen Sie keine weitere Analyse: Die Mitarbeiter haben das zentrale System längst aufgegeben.
Zu allgemeine Prozesse enden bei planen, machen, prüfen
Die Überarbeitung war der schwierigere Teil. Viele Beteiligte hatten das Bild aufgeblähter Dokumente mit komplizierten Freigaben vor Augen und blieben deshalb bei den Abläufen abstrakt. Je allgemeiner ein Prozess formuliert wird, desto weniger bleibt von ihm übrig. Am Ende steht planen, machen, prüfen – und damit kann niemand arbeiten.
Ein Hersteller mit drei oder vier verschiedenen Produkten braucht keinen Prozess, der alles gleichzeitig abdeckt. Er braucht je Produkttyp die Anweisung, was zu tun ist, mit welchem Werkzeug und was das Ergebnis sein muss. Kommt dann noch ein unübersichtliches System dazu, in dem unzählige Word-Dateien untereinander aufeinander verweisen, hat die Dokumentation für die Entwicklung keinen Nutzen mehr.
Die Wunschvorstellung zu dokumentieren macht dauerhaft Arbeit
Ein verbreiteter Fehler ist, den Ablauf zu beschreiben, den man gern hätte. Der Prozess sieht sauber aus, hat aber mit der Entwicklung nichts zu tun. Ab dem Moment pflegen Sie dann zwei Welten, die reale und die dokumentierte, und müssen die Parallelwelt für jedes Audit aufrecht erhalten.
Ein Prozess muss nicht akademisch sauber sein um konform zu sein. Er muss beschreiben, was passiert, und die Ergebnisse liefern, die die Normen und die Verordnung verlangen.
Vorlagen sind der Maßstab für den Abgleich, nicht der Startpunkt
Gute Vorlagen zeigen Ihnen, was am Ende vorhanden sein muss. Dieses Soll-Bild gleichen Sie gegen Ihre eigene Welt ab, und behandeln die drei Fälle: Gibt es die Vorlage oder den Prozessschritt bei Ihnen noch nicht, übernehmen Sie ihn. Ist er teilweise vorhanden, ergänzen Sie ihn. Reicht das Vorhandene aus, lassen Sie es so wie es ist und führen nichts Neues ein.
Wer stattdessen ein komplettes Vorlagenpaket über die Organisation legt, baut eine zweite Struktur zu dem, was die Mitarbeiter im Alltag machen. Am Ende steht dann auch wieder ein Prozess, der niemanden erreicht, nur diesmal mit fremder Handschrift.
Damit eine Vorlage im Alltag benutzt wird, muss man sie ohne langes Nachdenken ausfüllen können. Unsere Vorlagen sind verständlich geschrieben und beschreiben, was zu tun ist, statt abstrakt zu erklären, wie man was in der Normenwelt machen würde. In den Vorlagen stehen daher u.a. auch Beispiele und Ausfüllhilfen, damit ein Entwickler direkt anfangen kann.
Guter und schlechter Prozess unterscheiden sich an sechs Stellen
Ob ein Prozess im Alltag genutzt wird, entscheidet sich an wenigen Merkmalen. Die folgende Gegenüberstellung fasst zusammen, was wir in Projekten auf beiden Seiten sehen:
| Merkmal | Guter Prozess | Schlechter Prozess |
|---|---|---|
| Ausgangspunkt | der Ablauf, der heute gelebt wird | das Wunschbild oder das Vorlagenpaket |
| Detailtiefe | konkrete Anweisung je Entwicklungstyp | planen, machen, prüfen für alles |
| Mitgeliefert | Vorlagen mit Beispielen und Ausfüllhilfen | leere Formulare ohne Anleitung |
| Sprache | einfach, die Handlung steht vorn | Abhandlung in Normvokabular |
| Auffindbarkeit | nach Rolle filterbar, Zielsystem verlinkt | Word-Dateien mit Verweisen auf IDs andere Dokumente |
| Zweck der Struktur | der Anwender findet seine Tätigkeiten | der Auditor findet den Nachweis |
Welches Werkzeug Sie einsetzen, ist zweitrangig. Entscheidend ist, dass die Mitarbeiter darauf zugreifen, nach ihrer Rolle filtern können und sofort sehen, was in ihrer Situation zu tun ist und welchem Tools oder Vorlagen sie dafür zu nutzen haben.
Prozessschulden aus der CE-Praxis werden mit dem CRA fällig
Wer Nachweise bisher am Ende der Entwicklung für die CE-Kennzeichnung zusammengesucht hat, hat Schulden aufgebaut. Im CRA entstehen diese Nachweise während der Entwicklung. Der Frust und die Panik, die wir aktuell rund um den CRA sehen, kommen in vielen Fällen aus dem Abbezahlen dieser alten Prozessschulden.
Hersteller, die ihre Entwicklung ohnehin strukturiert abwickeln, haben beim CRA fachliche Themen zu klären, und die Prozessseite ist in wenigen Wochen erledigt. Verbesserungspotenzial hat trotzdem jedes Unternehmen. Wir halten es deshalb für falsch, das Thema auf 2027 zu schieben. Dann sind die technischen Aufgaben noch offen, die Beraterkapazität ist knapp, und die sechs bis achtzehn Monate bis zur täglichen Anwendung stehen immer noch bevor. Ein neuer Prozess läuft nicht ab dem ersten Tag rund, und genau dafür brauchen Sie die Zeit vor dem 11. Dezember 2027.
Kommentar hinzufügen