QMS-Prozesse als Security-Schnittstellen: Entwicklung, Änderungen, Lieferanten und Reklamationen

Problem in der Praxis

In Organisationen mit etabliertem QMS kommt die Security oft später dazu und baut eigene Strukturen: ein eigenes Security-Gate für Vorhaben, ein eigenes Lieferantenregister, ein eigenes Lessons-Learned-Verfahren. Ein mögliches, in der eigenen Organisation zu überprüfendes Fehlermuster: Entschieden wird dort, wo die Organisation es gewohnt ist, in den eingeübten QM-Routinen; der separate Security-Schritt gerät unter Termindruck als Erstes ins Hintertreffen.

Ein zweites Prüffeld sind die Fehlerdaten. Ereignisse wie Fehlversand an falsche Empfänger, verlorene Unterlagen oder fehlkonfigurierte Systeme können im QM als Qualitätsfehler abgearbeitet werden, obwohl sie aus Sicherheitssicht Vorfälle mit Bewertungs- und gegebenenfalls Meldebedarf sind. Ob solche Fälle den CISO erreichen, hängt davon ab, ob jemand diese Daten mit der Sicherheitsbrille liest, eine Stichprobe in den eigenen Fehlerdaten schafft hier schnell Klarheit.

Das dritte Prüffeld sind doppelt geführte Lieferantenbestände: eine Bewertung nach QM-Logik, daneben eine eigene Security-Liste. Divergieren beide Stände, bleibt ungeklärt, welcher gilt.

CISO-Einordnung

Das folgende Schnittstellenmodell ist eigene Managementpraxis. Es beschreibt, wo Sicherheitsbelange an vorhandene QM-Routinen andocken können, nicht, was ISO 9001 fordert oder enthält. Voraussetzung ist stets, dass der jeweilige Trägerprozess in der eigenen Organisation existiert und wirksam gelebt wird.

Bei Entwicklung und Änderungen: Führt das QMS Vorhaben über Prüf- und Freigabepunkte, gehören Sicherheitsanforderungen und -freigaben in genau diese Punkte statt in einen zweiten Gate-Prozess daneben. Ein tatsächlich gelebter und technisch beziehungsweise organisatorisch erzwungener Prüfpunkt reduziert das Risiko, dass die Sicherheitsprüfung übergangen wird; ein nur formal existierender Prüfpunkt leistet das nicht.

Bei externen Anbietern liegt der eigenständige Wert nicht in den Sicherheitskriterien selbst, die fachliche Tiefe der Lieferkettensicherheit behandelt Artikel nis2-005 —, sondern in der Schnittstellenentscheidung: ein gemeinsamer Datenbestand statt zweier Register, definierte Übergabepunkte (wann die Security an Bewertung, Vertrag und Überwachung beteiligt wird), klare Entscheidungsrechte (wer eine Freigabe aus Sicherheitsgründen stoppen kann) und ein Eskalationsweg bei Zielkonflikten. Die Grenze bleibt: Der QM-Prozess ersetzt keine gesetzliche Lieferketten-Cybersicherheitspflicht wie unter NIS-2; er ist der Trägerprozess für deren Umsetzung.

Bei Reklamationen, Fehlern und Korrekturmaßnahmen liegt die Chance im Sensorkanal: QM-Fehlerdaten können Sicherheitsvorfälle enthalten, die nie als solche erkannt wurden, etwa Fehlversand, falsche Empfänger, Datenverlust oder Fehlkonfiguration. Eine Sicherheitsrelevanz-Markierung mit Weiterleitungsregel macht diesen Kanal dort nutzbar, wo Fehler bereits erfasst werden. Umgekehrt kann ein gelebter Korrekturmaßnahmenprozess als Vehikel der Vorfallsnachbereitung dienen; die methodische Tiefe von Ursachenanalyse und Wirksamkeitsprüfung behandelt der Korpusartikel ciso-audit-013. Hier zählt der Übergabepunkt: Welcher Fall wechselt wann in die Sicherheitsnachbereitung, und wer entscheidet das.

Die vierte Ebene ist eine Abgrenzung: Qualität und Informationssicherheit bleiben getrennte fachliche Domänen. Die Qualitätsverantwortung beurteilt die Freigabefähigkeit, die Sicherheitsverantwortung die sicherheitsseitige Tragbarkeit; im Konfliktfall entscheidet eine definierte Eskalation. Die Akkreditierungssicht stützt das: Auch ein integriertes Managementsystem wird gegen die getrennten Kriteriensätze der Normen auditiert, Konformität je Norm bewertet.

Umsetzungsperspektive

Der erste Schritt ist eine gemeinsame Prozessaufnahme von CISO und Qualitätsverantwortlichen: Welche QM-Prozesse existieren, und welche werden tatsächlich gelebt, nicht, welche dokumentiert sind. Ein Papierprozess trägt keine Sicherheitsanforderungen. Zur Aufnahme gehört auch, wo die Verantwortung für diese Prozesse in der eigenen Organisation tatsächlich liegt; das lässt sich nicht organisationsübergreifend vorhersagen und darf nicht aus Rollenklischees abgeleitet werden.

Dann folgt je Schnittstelle die minimalinvasive Erweiterung: Sicherheitskriterien in den bestehenden Prüf- und Freigabepunkten, mit klarer Regel, welche Vorhaben ohne Security-Beteiligung laufen dürfen. Im Lieferantenprozess die Verankerung von Übergabepunkten, Entscheidungsrechten und Eskalation in einem gemeinsamen Register. Im Fehler- und Reklamationsprozess eine Markierung für Sicherheitsrelevanz, wenige Beispielmuster für die Erfassenden und eine Weiterleitungsregel mit Zeitvorgabe.

Das Owner-Modell gehört schriftlich fixiert: Prozessowner, fachliche Owner je Domäne, Freigabe- und Eskalationswege, jeweils so, wie sie in der eigenen Organisation tatsächlich verortet sind. Die Qualitätsverantwortlichen werden nicht nebenbei zu Sicherheitsentscheidern, der CISO nicht zum Co-Qualitätsmanager.

Schließlich die Pflege: Ändert das QM Formulare oder Prozessschritte, müssen die Sicherheitsanteile mitwandern. Eine jährliche Durchsicht samt Stichprobe in den Fehlerdaten hält die Schnittstellen aktuell; die angekündigte Revision der ISO 9001 (geplant September 2026, Stand 2026-07-24 nicht veröffentlicht) ist dafür ein natürlicher Anlass.

Typische Fehler

1. Die Andockpunkte werden übernommen, ohne zu prüfen, ob die QM-Prozesse in der eigenen Organisation existieren und gelebt werden; ein Papierprozess trägt keine Sicherheitsfreigaben.
2. Ein separates Security-Gate wird neben die QM-Änderungslenkung gestellt und unter Termindruck übergangen, weil nur der QM-Weg als verbindlich wahrgenommen wird.
3. Die Security führt ohne dokumentierten Grund ein zweites Lieferantenregister; die Stände divergieren, keine Liste bleibt vollständig.
4. QM-Fehlerdaten werden nie auf Sicherheitsrelevanz gesichtet; sicherheitsrelevante Fälle bleiben reine Qualitätsfehler.
5. Mit dem gemeinsamen Prozess wandert stillschweigend die Verantwortung: Qualitätsverantwortliche entscheiden faktisch Sicherheitsfragen ohne Mandat.
6. Die Schnittstellen werden einmalig eingerichtet, aber nicht gepflegt; Prozessänderungen des QM lassen die Sicherheitsanteile veralten.

Risiken und Trade-offs

Wer sich in QM-Prozesse einklinkt, erbt deren Reifegrad. Ist die Änderungslenkung nur formal vorhanden, trägt sie auch keine Sicherheitsfreigaben; dann hilft nur die gemeinsame Ertüchtigung des Trägerprozesses, oder die dokumentierte Entscheidung, vorerst separat zu arbeiten.

Zweitens die Kopplung an fremde Taktung: QM-Prozesse sind auf geplante Änderungen ausgelegt. Sicherheitskritische Sofortmaßnahmen brauchen einen definierten Schnellweg mit nachgelagerter Dokumentation, sonst wird der gemeinsame Prozess zur Trägheitsfalle.

Drittens bleibt die Bewertung getrennt: Auditiert wird je Rahmenwerk, und gesetzliche Pflichten wie die Lieferketten-Cybersicherheit unter NIS-2 gelten unabhängig vom Trägerprozess. Der Prozess ist das Vehikel, nicht der Rechtsgrund. Zudem können unterschiedliche Scopes, Geheimhaltungsanforderungen, Konzernstrukturen oder regulatorisch getrennte Systeme im Einzelfall getrennte Strukturen rechtfertigen, dann als bewusste, dokumentierte Ausnahme, nicht als gewachsene Doppelstruktur.

Entscheidungspunkte

• Welche QM-Prozesse (Entwicklung, Änderungen, Lieferanten, Reklamationen) existieren in der eigenen Organisation, werden gelebt und können Sicherheitsanteile tragen?
• Wo liegt die Verantwortung für diese Prozesse tatsächlich, und wie wird das Owner-Modell mit Eskalationsweg dokumentiert?
• An welchen Prüf- und Freigabepunkten wird die Security beteiligt, und nach welcher Regel gilt ein Vorhaben als sicherheitsrelevant?
• Gibt es begründete Ausnahmen für getrennte Strukturen, etwa unterschiedliche Scopes, Geheimhaltungsanforderungen, Konzernstrukturen oder regulatorisch getrennte Systeme, und sind sie dokumentiert?
• Wer sichtet Fehler- und Reklamationsdaten auf Sicherheitsrelevanz, und wie schnell erreicht ein markierter Fall die Security?

Praktische Empfehlungen

1. Nehmen Sie mit den Qualitätsverantwortlichen auf, welche QM-Prozesse existieren und gelebt werden und wo die Verantwortung dafür tatsächlich liegt; docken Sie nur an wirksame Prozesse an.
2. Verankern Sie Sicherheitsanforderungen und -freigaben in den bestehenden Prüf- und Freigabepunkten der Entwicklungs- und Änderungsprozesse; ein eigenes Gate nur als dokumentierte Ausnahme mit klarem Grund.
3. Entscheiden Sie die Registerfrage bewusst: im Regelfall ein gemeinsamer Lieferantenbestand mit Sicherheitsattributen; Abweichungen (Scope, Geheimhaltung, Konzern- oder Regulierungsgrenzen) begründen und dokumentieren Sie.
4. Ergänzen Sie den Fehler- und Reklamationsprozess um eine Sicherheitsrelevanz-Markierung mit Weiterleitungsregel und prüfen Sie per Stichprobe, ob Ihre Fehlerdaten unerkannte Sicherheitsvorfälle enthalten.
5. Definieren Sie den Übergabepunkt in die Vorfallsnachbereitung: welcher Fall wann in die Sicherheitsdomäne wechselt und wer das entscheidet; die fachliche Tiefe der Korrekturmaßnahmen behandelt Artikel ciso-audit-013.
6. Fixieren Sie das Owner-Modell schriftlich: getrennte fachliche Verantwortung, definierte Eskalation, Schnellweg für sicherheitskritische Sofortmaßnahmen.

Relevante Normreferenzen

• ISO 9001:2015 einschließlich Amd 1:2024: Referenzrahmen Qualitätsmanagement, geltende Ausgabe; Revision (sechste Ausgabe) für September 2026 angekündigt, Stand 2026-07-24 nicht veröffentlicht (Referenz).
• ISO/IEC 27001:2022: Referenzrahmen Informationssicherheits-Managementsystem, wie ISO 9001 nach harmonisierter Struktur (Referenz).
• IAF MD 11:2023: Akkreditierungssicht auf Audits integrierter Managementsysteme (Referenz; IAF-Nachfolge seit 01.01.2026: Global ACI).
• Richtlinie (EU) 2022/2555 (NIS-2): gesetzliche Lieferketten-Cybersicherheitspflichten, vertieft in Artikel nis2-005 (Referenz).