ISO 9001 für SaaS. Ohne Produktionslogik.

ISO 9001 in der SaaS-Welt: warum die Übersetzung nötig ist

ISO 9001 ist 1987 für Industriebetriebe entstanden. Die Norm wurde 2015 grundlegend überarbeitet und auf die High Level Structure (HLS, früher Annex SL) umgestellt. Sie ist heute ausdrücklich branchenneutral. Die Praxis sieht anders aus: 90 Prozent der frei verfügbaren Templates, Beispiel-Handbücher und Schulungsbeispiele kommen aus der Fertigung, der Bauwirtschaft oder dem Handwerk. Für ein SaaS-Team, das Continuous Deployment praktiziert und in Quartals-OKRs plant, ist das ein Übersetzungsproblem.

Die gute Nachricht: ISO 9001 fordert keine Fertigungsprozesse. Sie fordert dokumentierte, gesteuerte und kontinuierlich verbesserte Prozesse. Welche Prozesse das sind, definierst du selbst nach deinem Geschäftszweck. Ein SaaS-Anbieter hat keine Wareneingangsprüfung, sondern eine Code-Review. Keine Maschinenwartung, sondern eine Infrastruktur-Pipeline. Keine Endkontrolle, sondern Monitoring und Observability.

Die Kunst besteht darin, die Klauselsprache der Norm in die Begriffswelt deiner Engineering-Organisation zu übersetzen, statt umgekehrt deine Organisation in die Norm zu zwingen.

SaaS-angepasste Prozesslandkarte

Statt 15 oder 20 Fertigungsblöcken kommt eine SaaS-Organisation mit vier Kernprozessen aus.

Product Management. Discovery (Kundeninterviews, Marktbeobachtung), Roadmap-Pflege, Spezifikation. Outputs: PRDs, RFCs, Roadmap-Items. Norm-Bezug: 4.2 (Erfordernisse interessierter Parteien), 8.2 (Anforderungen für Produkte und Dienstleistungen), 9.1.2 (Kundenzufriedenheit).

Engineering. Backlog-Refinement, Sprint-Planung, Implementierung, Code-Review, CI/CD, Deployment. Outputs: Pull Requests, Build-Logs, Deployment-Records. Norm-Bezug: 8.3 (Entwicklung), 8.5 (Produktion und Dienstleistungserbringung), 8.6 (Freigabe).

Customer Success. Onboarding, Adoption-Tracking, Quarterly Business Reviews, Renewal. Outputs: Onboarding-Tickets, Health Scores, QBR-Decks. Norm-Bezug: 8.2.1 (Kommunikation mit Kunden), 9.1.2 (Kundenzufriedenheit, NPS und CSAT).

Support und Incident Management. Ticket-Handling, Incident Response, Postmortems. Outputs: Support-Tickets, Incident-Reports, Root-Cause-Analysen. Norm-Bezug: 8.7 (Steuerung nicht-konformer Ergebnisse), 10.2 (Nichtkonformität und Korrekturmaßnahmen).

Mit dieser schlanken Karte deckst du den operativen Teil der Norm ab. Die Querschnittsklauseln (Führung, Planung, Ressourcen) sitzen darüber.

Engineering-Metriken als QM-Evidenz: die DORA Four Keys

Eine der schönsten Eigenschaften des SaaS-Kontexts: du hast bereits objektive Qualitätskennzahlen, ohne dass jemand neu messen muss. Die DORA Four Keys (DevOps Research and Assessment, Google Cloud) sind die anerkannten Industrie-Metriken für Engineering-Performance und gleichzeitig perfekte QMS-Indikatoren nach Klausel 9.1.

• Deployment Frequency. Wie oft deployt dein Team in Produktion? Hohe Frequenz korreliert mit niedrigem Risiko pro Change und hoher Reaktionsfähigkeit.
• Lead Time for Changes. Zeit vom Commit bis zum Produktiv-Deployment. Kurze Lead Time signalisiert einen gesunden Liefer-Prozess.
• Mean Time to Restore (MTTR). Wie schnell stellst du nach einem Incident den Betrieb wieder her? Direkter Indikator für Verfügbarkeitsqualität.
• Change Failure Rate. Anteil der Deployments, die einen Incident oder Rollback verursachen. Direkter Qualitätsindikator des Engineering-Outputs.

Diese vier Metriken passen exemplarisch in den Management-Review nach Klausel 9.3 und liefern objektive Datenpunkte, die kein Auditor in Frage stellt. Sie sind besser als jede klassische QM-Kennzahl, weil sie automatisch erhoben werden und nicht manipulierbar sind.

Ergänzend lohnen sich SLO-Adherence (wie oft hältst du dein Service Level Objective ein), Error-Budget-Burn (wie viel deines Fehlerbudgets verbrauchst du pro Quartal) und CSAT/NPS für die Kundensicht.

Kundenorientierung über NPS, CSAT und Quarterly Business Reviews

ISO 9001 fordert in Klausel 9.1.2 die Erfassung der Kundenzufriedenheit. SaaS-Teams haben dafür drei etablierte Mechanismen, die du einfach in dein QMS einbauen kannst.

NPS (Net Promoter Score) wird typischerweise quartalsweise erhoben. Der Wert wandert in den Management-Review, Kommentar-Cluster werden als Verbesserungsinput behandelt. CSAT (Customer Satisfaction Score) wird transaktional pro Support-Ticket oder pro Onboarding gemessen, dient als operatives Frühwarnsignal. Quarterly Business Reviews mit deinen Top-Kunden liefern qualitatives Feedback, das in deine Roadmap zurückfließt.

Wichtig: dokumentiere die Methodik einmal in einem schlanken Dokument („So messen wir Kundenzufriedenheit“) und referenziere die laufenden Daten aus deinem analytics-Tool. Du musst das Rad nicht zweimal erfinden.

Kontinuierliche Verbesserung über Retros, nicht über Beschwerdebücher

Klausel 10.3 verlangt kontinuierliche Verbesserung. SaaS-Teams haben dafür längst eine etablierte Praxis: Sprint-Retros, Quartals-Retros, Postmortems nach Incidents.

Wenn du diese Termine als deine Verbesserungs-Mechanik dokumentierst, brauchst du keine zusätzliche Struktur. Wichtig ist:

• Jede Retro produziert mindestens eine Action mit Owner und Termin.
• Actions werden in einem Tool getrackt, nicht in einem Confluence-Dokument vergessen.
• Postmortems sind blameless und folgen einem festen Template (Was ist passiert, warum, was tun wir, um es zu verhindern).
• Quartals-Retros prüfen, welche Actions umgesetzt wurden und welche systematische Verbesserung daraus entstanden ist.

Damit hast du Klausel 10.3 erfüllt, ohne ein Beschwerdebuch zu erfinden.

Schlanke Prozessdokumentation, kein Wasserfall-Rückfall

Die größte Falle bei ISO 9001 in SaaS-Teams ist der Wasserfall-Rückfall. Externe Berater oder unsichere QM-Manager fordern dann Spezifikationen vor jedem Sprint, Abnahmeprotokolle vor jedem Deployment und schriftliche Genehmigungen für jede Konfigurationsänderung. Das zerstört die Engineering-Kultur und das QMS gleich mit.

Stattdessen: dokumentiere die Spielregeln, nicht jede Spielzug-Entscheidung. Beispiele für gute, schlanke Dokumentation:

• Definition of Ready und Definition of Done als zwei einseitige Dokumente.
• Code-Review-Policy: wer reviewt was, wann ist Vier-Augen-Prinzip Pflicht.
• Deployment-Policy: wann wird in Produktion deployt, welche automatischen Checks laufen, was ist Rollback-Kriterium.
• Incident-Response-Playbook: Schweregrade, Eskalationswege, Kommunikationsregeln.
• Architektur-Decision-Records (ADRs): wichtige technische Entscheidungen mit Begründung. Norm-konformer Ersatz für klassische Spezifikationen.

Mit diesen fünf bis zehn Dokumenten plus dem QMS-Handbuch hast du eine Norm-konforme Dokumentenlandschaft, die deine Engineering-Realität abbildet, statt sie zu blockieren.

Cross-Referenzen für deine Detailrecherche

Wenn du parallel ISO 27001 betreibst oder einführen willst, lohnt der Sprung in den ISO 27001 Hub, der Annex-A-Controls, Roadmap und Statement of Applicability strukturiert. Die methodische Brücke zwischen QMS und ISMS schlägt unser Leitfaden zum integrierten Managementsystem. Er zeigt, wie du beide Standards mit einem Handbuch und einem Risikoregister fährst. Den strukturierten Vergleich von Geltungsbereich, Klauseln und Anforderungen findest du im Vergleich ISO 9001 vs ISO 27001.

Kopexa unterstützt sowohl Self-Service-Teams, die ISO 9001 in Eigenregie aufbauen wollen, als auch Setups mit externem QM-Partner. Die Plattform liefert die Struktur, du oder dein Partner liefern den Inhalt. Beides ist legitim und wird vom Auditor gleichermaßen akzeptiert.