Was TISAX ist und was nicht

TISAX ist ein Verfahren zum Austausch von Prüfergebnissen zur Informationssicherheit in der Automobilindustrie. Grundlage ist der VDA ISA, ein Katalog von Anforderungen, den der Verband der Automobilindustrie pflegt. Die ENX Association betreibt das Verfahren und die Plattform, über die Ergebnisse geteilt werden.

Zwe i Eigenschaften unterscheiden es von einer klassischen Zertifizierung: Erstens prüft ein zugelassener Prüfdienstleister gegen den VDA ISA, nicht gegen eine ISO-Norm. Zweitens erhalten Sie kein Zertifikat, das Sie auf die Website stellen, sondern ein Label, das Sie gezielt für einzelne Partner freigeben.

Für ein TISAX Startup heißt das: Der Nachweis entsteht nicht für die Öffentlichkeit, sondern für einen konkreten Kunden. Dieser Kunde gibt in der Regel auch vor, welche Anforderungen das Label erfüllen muss.

Assessment Level und Prüfziele

Der Aufwand hängt an zwei Festlegungen, die vor dem Projekt stehen und die der Kunde maßgeblich bestimmt:

Das Prüfziel beschreibt, worauf sich die Prüfung bezieht – etwa der allgemeine Umgang mit Informationssicherheit, der Schutz von Prototypen oder der Umgang mit besonders schützenswerten Daten. Jedes Prüfziel bringt eigene Anforderungen mit; Prototypenschutz etwa umfasst bauliche und organisatorische Anforderungen, die für ein reines Softwareunternehmen oft gar nicht einschlägig sind.
Das Assessment Level bestimmt die Prüftiefe. Es reicht von einer Selbstauskunft mit Plausibilitätsprüfung bis zu einer Prüfung mit Begehung vor Ort. Je höher das Level, desto mehr Nachweise werden nicht nur beschrieben, sondern gezeigt.

Klären Sie beides schriftlich mit dem Kunden, bevor Sie anfangen. Ein Projekt, das auf das falsche Prüfziel hinarbeitet, erzeugt Aufwand, den niemand braucht; das fällt erst am Ende auf.

Das Verhältnis zur ISO 27001

Der VDA ISA ist an der ISO/IEC 27001 orientiert und übernimmt viele ihrer Themen: Risikomanagement, Zugriffskontrolle, Umgang mit Lieferanten, Vorfallsbehandlung, Kontinuität. Wer ein funktionierendes ISMS betreibt, hat demnach einen erheblichen Teil der Arbeit bereits getan.
Deckungsgleich sind die beiden allerdings nicht. Der VDA ISA stellt in einigen Bereichen konkretere Anforderungen, insbesondere dort, wo es um den Schutz von Entwicklungsdaten und um den Umgang mit Informationen aus Kundenprojekten geht. Umgekehrt ersetzt ein TISAX-Label keine ISO-27001-Zertifizierung, falls ein anderer Kunde genau diese verlangt.

In der Praxis läuft es häufig auf eine Reihenfolge hinaus, die sich mit einer gemeinsamen Zertifizierungsvorbereitung abbilden lässt: Das ISMS wird einmal aufgebaut und trägt beide Nachweise. Ein zweites, paralleles System für den Automobilkunden ist grundsätzlich nicht nötig und wäre auf Dauer auch nicht pflegbar.

Der Ablauf in groben Zügen

Das Verfahren folgt einer festen Reihenfolge:

• Registrierung auf der ENX-Plattform und Festlegung von Prüfziel und Level
• Selbstauskunft entlang des VDA ISA, mit Reifegradbewertung je Anforderung
• Beauftragung eines zugelassenen Prüfdienstleisters
• Assessment, je nach Level mit Interviews und Vor-Ort-Anteil
• Maßnahmenplan für offene Punkte, Nachweis der Umsetzung
• Freigabe des Ergebnisses an den anfragenden Partner

Die Selbstauskunft ist dabei mehr als Vorbereitung: Sie ist das Arbeitsdokument des gesamten Projekts. Wer sie ehrlich ausfüllt, sieht die Lücken, bevor der Prüfer sie sieht, und kann die Reihenfolge der Maßnahmen selbst bestimmen.

Die ENX Association beschreibt Verfahren, Level und Prüfziele auf ihrer offiziellen Seite zu TISAX.

Was Startups erfahrungsgemäß unterschätzen

Drei Punkte kosten regelmäßig mehr Zeit als erwartet:

Der Reifegrad der Selbstauskunft ist keine Ja-Nein-Frage. Gefordert ist in der Regel nicht die höchste Stufe, aber eine, die über „gemacht, aber nicht festgelegt" hinausgeht. Ein Ablauf, der funktioniert, ohne beschrieben zu sein, fällt hier durch – nicht wegen der Praxis, sondern wegen der fehlenden Festlegung.
Der Umgang mit Lieferanten wird zur echten Aufgabe. Wenn Teile Ihrer Leistung bei Dienstleistern liegen, muss nachvollziehbar sein, welche Anforderungen Sie dort gestellt haben und wie Sie deren Einhaltung prüfen.
Und die Terminlage: Prüfdienstleister sind nicht beliebig verfügbar, freie Assessment-Termine liegen oft mehrere Wochen oder Monate in der Zukunft. Warten Sie mit der Anfrage deshalb nicht, bis Ihre Vorbereitung vollständig abgeschlossen ist. Sobald feststeht, bis wann der Kunde das Label erwartet, sollten Sie den Prüftermin anfragen und die Vorbereitung parallel darauf ausrichten. So vermeiden Sie, dass am Ende alles fertig ist, das Assessment aber erst Monate später stattfinden kann.

Häufige Fragen zu TISAX

Brauchen wir zuerst ISO 27001?

Nein, TISAX setzt keine ISO-27001-Zertifizierung voraus. Ein vorhandenes ISMS verkürzt die Vorbereitung aber deutlich, weil der VDA ISA auf denselben Themen aufsetzt.

Gilt das Label für das ganze Unternehmen?

Es gilt für den geprüften Standort und den festgelegten Umfang. Arbeiten mehrere Standorte am Kundenprojekt mit, gehört das in die Festlegung vor dem Assessment, nicht danach.

Wie lange ist ein TISAX-Label gültig?

Die Gültigkeit ist zeitlich begrenzt und wird über ein erneutes Assessment verlängert. Den genauen Rahmen legt die ENX Association fest; er gehört zu den Punkten, die Sie vor dem Projekt mit dem Prüfdienstleister klären.

Fazit

Wenn ein Automobilkunde ein TISAX-Label verlangt, wirkt das für Startups zunächst wie eine große, schwer greifbare Hürde. Bei genauerem Hinsehen ist TISAX aber ein klar strukturiertes Verfahren mit festen Schritten. Wie viel Aufwand es bedeutet, entscheidet sich vor allem an zwei Stellen: am Prüfziel und am Assessment Level. Beides legt in der Regel der Kunde fest, nicht Sie selbst.
Wer bereits ein ISMS nach ISO 27001 betreibt oder aufbaut, hat einen großen Teil der Arbeit schon erledigt und muss vor allem die Lücken zum VDA ISA schließen. Die Selbstauskunft zeigt dabei früh, wo diese Lücken liegen. Und wer den Prüftermin rechtzeitig anfragt, verhindert, dass das Projekt am Ende an der Terminlage hängt.
Der erste Schritt ist deshalb einfach: Lassen Sie sich vom Kunden schriftlich bestätigen, welches Prüfziel und welches Assessment Level er erwartet. Damit wird aus einer unklaren Anforderung ein planbares Projekt.

Die Betroffenheit hängt an drei Merkmalen

Die NIS2-Richtlinie knüpft nicht an ein vages Kriterium wie „Digitalisierung“ an. Ob ein Unternehmen unter sie fällt, ergibt sich aus dem Zusammenspiel von drei Merkmalen: dem Sektor, in dem es tätig ist, seiner Größe und dem Land, in dem es seinen Sitz hat.

Am Anfang steht der Sektor. Die Richtlinie unterscheidet zwischen Sektoren mit hoher Kritikalität und weiteren kritischen Sektoren; dazu zählen unter anderem Energie, Verkehr, Gesundheit, Trinkwasser, digitale Infrastruktur, IKT-Dienstleistungsmanagement, Post, Abfall, Chemie, Lebensmittel sowie Anbieter digitaler Dienste. Ein SaaS-Produkt fällt deshalb nicht automatisch darunter, denn entscheidend ist nicht, dass Ihr Geschäftsmodell digital ist, sondern welche Leistung Sie konkret erbringen. Liegt diese in einem der genannten Sektoren, kommt als zweites Merkmal die Größe ins Spiel. Die Schwellenwerte orientieren sich an mittleren und großen Unternehmen; kleinere Unternehmen sind in der Regel nicht erfasst, es sei denn, sie sind für die Versorgung besonders wichtig.

Erst wenn Sektor und Größe zutreffen, lohnt sich der Blick auf die konkreten Pflichten, und hier wird das dritte Merkmal relevant, der Sitz. Weil NIS2 eine Richtlinie ist, setzt jeder Mitgliedstaat sie in eigenes Recht um, und die Details können von Land zu Land abweichen. Maßgeblich ist das Gesetz des Staates, in dem Sie niedergelassen sind.

Betroffen über die Lieferkette

Bei jungen Unternehmen ist der indirekte Fall deutlich häufiger: Sie sind nicht selbst verpflichtet, aber Ihr Kunde ist es. Die Richtlinie verlangt von ihm, auch die Sicherheit seiner Lieferkette zu berücksichtigen, und diese Pflicht reicht er über seine Verträge an Sie weiter. So landen plötzlich Zusagen zu technischen und organisatorischen Maßnahmen, Meldewege bei Sicherheitsvorfällen, Auskunftsrechte und manchmal sogar der Nachweis einer Zertifizierung auf Ihrem Tisch. Bindend sind diese Anforderungen, weil sie im Vertrag stehen, nicht weil das Gesetz Sie direkt adressiert.

Diese Unterscheidung ist für die eigene Planung wichtiger, als sie zunächst wirkt. Was ein Kunde vertraglich verlangt, lässt sich verhandeln und auf Ihre Situation zuschneiden; was das Gesetz verlangt, nicht.

Was die Richtlinie inhaltlich fordert

Wer sich schon einmal mit der ISO 27001 beschäftigt hat, wird in den Risikomanagementmaßnahmen der NIS2 vieles wiedererkennen. Die Richtlinie nennt unter anderem Konzepte für Risikoanalyse und Informationssicherheit, die Bewältigung von Sicherheitsvorfällen sowie die Aufrechterhaltung des Betriebs einschließlich Backup und Wiederherstellung. Dazu kommen die Sicherheit der Lieferkette, die Sicherheit bei Beschaffung, Entwicklung und Wartung von Systemen und die regelmäßige Bewertung, ob die getroffenen Maßnahmen tatsächlich wirken. Auch Grundlagen wie Cyberhygiene und Schulungen, Kryptografie, Personalsicherheit, Zugriffskontrolle und die Verwaltung von Anlagen gehören dazu, ebenso wie Authentifizierung und gesicherte Kommunikation.

Darüber hinaus sieht NIS2 Meldepflichten mit kurzen Fristen vor. Neu gegenüber früheren Regelungen ist außerdem, dass die Leitungsebene ausdrücklich in der Verantwortung steht und diese nicht delegieren kann. Den vollständigen Text veröffentlicht die Europäische Union als NIS2-Richtlinie im EU-Amtsblatt.

Wo ein ISMS bereits trägt

Die Überschneidung mit der ISO 27001 ist so groß, dass sich beides gut gemeinsam aufbauen lässt. Risikoanalyse, Zugriffskontrolle, Lieferantensteuerung, Vorfallsbehandlung, Betriebsfortführung und Kryptografie deckt ein Informationssicherheits-Managementsystem ohnehin ab. Eine Zertifizierung ersetzt die gesetzliche Pflicht allerdings nicht. Verlangt wird, dass die Maßnahmen dem Risiko angemessen sind, und dafür bleibt die Leitung verantwortlich. Ein Zertifikat ist ein starkes Indiz für diese Angemessenheit und gegenüber Kunden ein praktischer Nachweis, aber eben kein Freibrief.

Der eigentliche Nutzen liegt also in der Arbeitsersparnis. Wer bereits ein ISMS betreibt, muss für NIS2 vor allem zwei Dinge ergänzen: Meldewege, die die gesetzlichen Fristen einhalten, und eine nachweisbare Einbindung der Geschäftsleitung.

Was Sie jetzt tun können, ohne auf Details zu warten

Unabhängig davon, wie Ihre Betroffenheitsprüfung ausgeht, gibt es drei Dinge, die sich schon heute lohnen, weil Kunden ohnehin danach fragen werden. Legen Sie zuerst fest, wer bei einem Sicherheitsvorfall was tut: wer den Vorfall bewertet, wer entscheidet, wer meldet und wer die Kunden informiert. Kurze Meldefristen lassen sich nur einhalten, wenn diese Fragen vorher geklärt sind, und zwar auch für die Nacht und das Wochenende.

Klären Sie anschließend, welche Dienstleister Zugriff auf Ihre Systeme oder Kundendaten haben und was mit ihnen vertraglich vereinbart ist. Genau diese Lieferkettenfrage werden Ihnen Ihre eigenen Kunden stellen. Und halten Sie schließlich fest, dass die Geschäftsführung über die Risiken entschieden hat; ein datiertes Protokoll erfüllt diesen Zweck bereits.

Häufige Fragen zu NIS2

Gilt NIS2 für jedes Software-Startup?

Nein. Maßgeblich sind Sektor und Größe nach dem jeweiligen nationalen Umsetzungsgesetz. Viele junge Unternehmen sind nicht direkt verpflichtet, geraten aber über die Verträge ihrer Kunden in denselben Anforderungsrahmen.

Reicht eine ISO-27001-Zertifizierung für NIS2?

Sie deckt einen großen Teil der geforderten Maßnahmen ab und ist ein belastbarer Nachweis, ersetzt die gesetzliche Pflicht aber nicht. Die Meldewege und die Verantwortung der Leitung müssen gesondert geregelt werden.

Was passiert bei einem meldepflichtigen Vorfall?

Die Richtlinie sieht ein mehrstufiges Verfahren vor, das mit einer frühen Erstmeldung beginnt und durch spätere Berichte ergänzt wird. Welche Fristen genau gelten und welche Behörde zuständig ist, ergibt sich aus dem nationalen Recht.

Fazit

NIS2 ist für Startups zuerst eine Prüfungs- und erst danach eine Umsetzungsfrage. Ob eine direkte Pflicht besteht, entscheiden Sektor und Größe; weit häufiger kommen die Anforderungen jedoch über den Vertrag mit einem betroffenen Kunden. Der konkrete nächste Schritt ist deshalb überschaubar: Halten Sie in zwei Sätzen fest, in welchem Sektor Sie Ihre Leistung erbringen und wie viele Beschäftigte Sie haben. Mit diesen beiden Angaben lässt sich die Betroffenheit anhand des nationalen Umsetzungsgesetzes klären, und alles Weitere richtet sich danach.

Dieser Artikel geht die Kapitel 4 bis 10 einmal durch und beschreibt für jedes, welche Entscheidung dahintersteht und wie eine schlanke Umsetzung aussehen kann. Kein nacherzählter Normtext, sondern die Frage: was müsst ihr tatsächlich tun.

Wie die ISO 9001 Struktur aufgebaut ist

Die ISO 9001 folgt der gemeinsamen Grundstruktur, die alle neueren ISO-Managementsystemnormen teilen. Deshalb sehen ISO 27001, ISO 14001 und ISO 9001 auf Kapitelebene ähnlich aus. Wer später eine zweite Zertifizierung anstrebt, kann Kontext, Führung, Kompetenz und Auditlogik weitgehend wiederverwenden.

Die Kapitel 1 bis 3 enthalten Anwendungsbereich, normative Verweisungen und Begriffe. Sie stellen keine Anforderungen an euch. Auditiert wird ab Kapitel 4.

Die restlichen Kapitel bilden einen Zyklus ab: Kontext und Führung schaffen die Grundlage, Planung und Unterstützung bereiten vor, Betrieb ist die Wertschöpfung, Bewertung und Verbesserung schließen den Kreis. Diese Logik ist wichtiger als die Reihenfolge der Absätze. Ein Auditor prüft nicht, ob ihr Kapitel für Kapitel abgearbeitet habt, sondern ob der Kreislauf tatsächlich läuft.

Den offiziellen Überblick zur Norm veröffentlicht die Internationale Organisation für Normung zu ISO 9001. Der verbindliche Wortlaut steht nur im gekauften Normtext – ohne den solltet ihr nicht arbeiten.

Kapitel 4 und 5: Kontext, Anwendungsbereich und Führung

Kapitel 4 verlangt, dass ihr euer Umfeld versteht. Welche internen und externen Themen beeinflussen eure Fähigkeit, die vereinbarte Qualität zu liefern. Bei einem SaaS-Startup sind das etwa Abhängigkeit von einem Cloud-Anbieter, hohe Fluktuation im Engineering oder ein Kundenstamm, in dem drei Accounts den Großteil des Umsatzes ausmachen.

Dazu kommen die interessierten Parteien und deren relevante Anforderungen: Kunden, Investoren, Aufsichtsbehörden, Mitarbeitende, Lieferanten. Ihr müsst nicht jede Erwartung erfüllen, aber ihr müsst wissen, welche für euer Qualitätsmanagement relevant sind. Eine Tabelle mit zwei Spalten reicht dafür in der Regel aus.

Eine Ergänzung der Norm aus dem Jahr 2024 verlangt zusätzlich, zu betrachten, ob der Klimawandel für euren Kontext ein relevantes Thema ist. Für viele Softwareunternehmen lautet die begründete Antwort: eingeschränkt relevant. Wichtig ist, dass die Frage bewusst beantwortet wurde. Wir empfehlen die Aufnahme in den Kontext oder ein, zwei Risiken in der Risikoanalyse dazu.

Der Anwendungsbereich ist eine Entscheidung mit Folgen. Ihr legt fest, welche Produkte, Dienstleistungen, Standorte und Prozesse das QM-System abdeckt – und was nicht. Er muss als dokumentierte Information vorliegen und Ausschlüsse nachvollziehbar begründen.

Kapitel 4 verlangt außerdem, dass ihr eure Prozesse bestimmt, ihre Reihenfolge und Wechselwirkung kennt und Verantwortlichkeiten zuordnet. Für ein kleines Unternehmen bedeutet das: eine Prozesslandkarte auf einer Seite, nicht ein Handbuch mit 80 Seiten.

Kapitel 5 richtet sich an die Geschäftsführung, und zwar wörtlich. Die oberste Leitung muss Verantwortung für die Wirksamkeit des Systems übernehmen, Qualitätsanforderungen in die Geschäftsprozesse integrieren und Ressourcen bereitstellen. Delegieren an eine Person mit QM-Rolle ist möglich, die Verantwortung bleibt oben.

Die Qualitätspolitik ist ein kurzes, freigegebenes Dokument, das Rahmen und Selbstverpflichtung festlegt. Sie muss zur Organisation passen, intern bekannt sein und interessierten Parteien bei Bedarf zur Verfügung stehen. Drei ehrliche Sätze wirken im Audit besser als eine Seite Allgemeinplätze.

Schließlich müssen Rollen, Verantwortlichkeiten und Befugnisse zugewiesen und kommuniziert sein. Wer entscheidet über Freigaben, wer meldet Abweichungen, wer berichtet an die Leitung.

Kapitel 6 und 7: Planung und die Grundlagen dahinter

Kapitel 6 verlangt den Umgang mit Risiken und Chancen. Die Norm schreibt weder eine Methode noch ein Risikoregister vor. Sie erwartet, dass ihr Risiken für die Zielerreichung erkennt, Maßnahmen plant, sie in die Prozesse integriert und ihre Wirksamkeit bewertet.

Praktisch heißt das für ein Startup meist eine überschaubare Liste: Wissenskonzentration bei einzelnen Personen, Lieferantenabhängigkeit, unklare Anforderungsaufnahme im Vertrieb. Wer hier ein Register mit 200 Einträgen anlegt, pflegt es nach dem Erstaudit nicht mehr.

Qualitätsziele müssen messbar sein, zur Qualitätspolitik passen, überwacht und kommuniziert werden. Zusätzlich verlangt die Norm eine Planung: was wird getan, welche Ressourcen sind nötig, wer ist verantwortlich, wann ist es fertig, wie wird das Ergebnis bewertet. Drei bis fünf Ziele mit echter Aussagekraft sind besser als zehn dekorative.

Kapitel 6 behandelt außerdem geplante Änderungen am Managementsystem. Wenn ihr Prozesse umbaut, ein Tool wechselt oder Verantwortlichkeiten neu schneidet, soll das nicht ungeplant und ohne Blick auf Folgen und Ressourcen passieren.

Kapitel 7 fasst die Grundlagen zusammen, die ihr für den Betrieb braucht. Dazu gehören Personen, Infrastruktur, Prozessumgebung und, wo relevant, Ressourcen zur Überwachung und Messung. Reine Softwareunternehmen haben oft keine Messmittel im klassischen Sinn – das ist zulässig, sollte aber begründet sein.

Zum Thema Wissen der Organisation verlangt die Norm, dass ihr das für eure Prozesse notwendige Wissen bestimmt, verfügbar haltet und bei veränderten Anforderungen ergänzt. Bei kleinen Teams ist das der Punkt, der real weh tut: das Deployment-Wissen steckt in einem Kopf.

Kompetenz und Bewusstsein sind zwei getrennte Anforderungen. Kompetenz heißt: die richtigen Fähigkeiten sind vorhanden und nachgewiesen. Bewusstsein heißt: die Leute wissen, was die Qualitätspolitik für ihre Arbeit bedeutet und welche Folgen Abweichungen haben.

Umgang mit Kommunikationssträngen wird ebenfalls thematisiert. Kommunikation muss geplant sein – intern und extern, mit Angabe von Thema, Zeitpunkt, Zielgruppe und Verantwortung. Eine kurze Tabelle genügt.

Dokumentierte Information ist der Teil, der die meiste unnötige Arbeit erzeugt. Zu allererst: Dokumentierte Information bedeutet lediglich, dass man etwas schriftlich haben muss. Gefordert ist, was die Norm ausdrücklich verlangt, plus das, was ihr selbst für die Wirksamkeit eurer Prozesse als notwendig bestimmt. Der Umfang darf sich an Größe, Komplexität und Kompetenz der Belegschaft orientieren. Lenkung bedeutet: aktuell, auffindbar, freigegeben, vor unbeabsichtigter Änderung geschützt.

Kapitel 8: Betrieb, also eure eigentliche Arbeit

Kapitel 8 ist das umfangreichste und beschreibt die Wertschöpfung. Es beginnt mit der betrieblichen Planung und Steuerung: Anforderungen bestimmen, Kriterien für Prozesse und Annahme festlegen, Ressourcen zuordnen, Ergebnisse nachweisen.

Der Abschnitt zu Kundenanforderungen verlangt geregelte Kommunikation mit dem Kunden, das vollständige Erfassen der Anforderungen und eine Prüfung vor der Zusage. Praktisch: bevor ihr ein Angebot unterschreibt, prüft jemand, ob ihr liefern könnt. Bei Änderungen am Auftrag müssen die betroffenen Stellen informiert und die Unterlagen angepasst werden.

Die Entwicklung von Produkten und Dienstleistungen ist ein eigener Block mit Planung, Eingaben, Steuerung, Ergebnissen und Änderungen. Für Softwareteams lässt sich das gut auf einen bestehenden Entwicklungsprozess abbilden – Anforderungen, Review, Test, Freigabe, Versionierung. Wenn ihr nichts entwickelt, sondern rein nach Kundenspezifikation fertigt, kann dieser Abschnitt begründet als nicht anwendbar eingestuft werden.

Externe Anbieter müssen gesteuert werden. Ihr legt Kriterien für Auswahl und Bewertung fest, definiert, was ihr vom Anbieter erwartet, und prüft, dass die Leistung ankommt. Für Startups sind das typischerweise Cloud-Provider, Freelancer und Agenturen.

Bei Produktion und Dienstleistungserbringung geht es um beherrschte Bedingungen: dokumentierte Vorgaben, geeignete Ressourcen, qualifiziertes Personal, Freigaben. Dazu kommen Kennzeichnung und Rückverfolgbarkeit, der Umgang mit Eigentum von Kunden – bei SaaS häufig Kundendaten -, Erhaltung der Ergebnisse und Tätigkeiten nach der Lieferung wie Support und Gewährleistung.

Zwei Abschnitte werden gern übersehen. Erstens: Ergebnisse dürfen erst freigegeben werden, wenn die geplanten Prüfungen bestanden sind, und es muss nachvollziehbar sein, wer freigegeben hat. Zweitens: nichtkonforme Ergebnisse müssen erkannt, gekennzeichnet und gesteuert werden, damit sie nicht unbeabsichtigt beim Kunden landen.

Kapitel 9 und 10: Bewertung und Verbesserung

Kapitel 9 verlangt, dass ihr bestimmt, was ihr überwacht und messt, mit welchen Methoden, zu welchem Zeitpunkt und wann ihr die Ergebnisse bewertet. Ohne diese Festlegung sammelt ihr Zahlen, die niemand interpretiert.

Die Kundenzufriedenheit muss überwacht werden. Die Norm schreibt keine Umfrage vor. Reklamationen, Support-Tickets, Churn, Feedback aus Quarterly Business Reviews sind legitime Quellen, solange ihr sie systematisch auswertet.

Interne Audits finden in geplanten Abständen statt und prüfen, ob das System die Normanforderungen und eure eigenen Vorgaben erfüllt und wirksam ist. Auditoren dürfen ihre eigene Arbeit nicht bewerten. In kleinen Teams löst man das über gegenseitige Audits oder externe Unterstützung.

Die Managementbewertung ist die Sitzung der obersten Leitung, in der Auditergebnisse, Kennzahlen, Kundenfeedback, Status von Maßnahmen, Änderungen im Kontext und Ressourcenbedarf zusammenlaufen. Ergebnis sind Entscheidungen, keine Präsentation. Das Protokoll ist eines der Dokumente, die im Audit sicher angesehen werden.

Kapitel 10 regelt den Umgang mit Abweichungen. Ihr reagiert auf die Nichtkonformität, prüft die Ursache, bewertet, ob Ähnliches anderswo auftreten kann, setzt Maßnahmen um und bewertet deren Wirksamkeit. Art und Ergebnis müssen nachweisbar sein.

Fortlaufende Verbesserung heißt nicht, jedes Quartal etwas Neues zu erfinden. Es heißt, dass Erkenntnisse aus Messung, Audit und Managementbewertung nachweislich zu Veränderungen führen.

Was die Kapitel für ein kleines Unternehmen konkret bedeuten

Die Reihenfolge im Aufbau muss nicht der Kapitelnummerierung folgen. Sinnvoll ist meist: Anwendungsbereich und Prozesslandkarte zuerst, dann Kapitel 8 an der real gelebten Arbeitsweise entlang, danach Planung, Ressourcen und Dokumentenlenkung.

Kapitel 9 und 10 brauchen Zeit, weil sie Nachweise über einen Zeitraum verlangen. Ein internes Audit und eine Managementbewertung müssen vor dem Zertifizierungsaudit stattgefunden haben. Wer erst zwei Wochen vorher anfängt, hat kein System, sondern Dokumente.

Der häufigste Fehler ist ein QM-System neben dem Tagesgeschäft. Wenn ihr Prozesse beschreibt, die niemand so ausführt, fällt das im Audit auf und erzeugt dauerhaft Pflegeaufwand. Beschreibt, wie ihr arbeitet, und ändert dort, wo die Arbeitsweise tatsächlich schwach ist.

Häufige Fragen zu ISO 9001 Kapitel

Müssen alle Kapitel umgesetzt werden?

Anforderungen enthalten die Kapitel 4 bis 10, und sie gelten grundsätzlich alle. Einzelne Anforderungen können als nicht anwendbar eingestuft werden, wenn das begründet ist und die Fähigkeit zur Erfüllung von Kundenanforderungen nicht beeinträchtigt wird. Diese Begründung gehört in die Beschreibung des Anwendungsbereichs.

Brauchen wir einen Qualitätsmanagementbeauftragten?

Die Norm fordert diese Rolle seit der Ausgabe 2015 nicht mehr ausdrücklich. Die zugehörigen Verantwortlichkeiten müssen aber zugewiesen und kommuniziert sein. Viele Unternehmen benennen trotzdem eine verantwortliche Person, weil es die Koordination vereinfacht.

Wie viel Dokumentation ist genug?

Die Norm verlangt bestimmte dokumentierte Informationen ausdrücklich, darunter Anwendungsbereich, Qualitätspolitik und Qualitätsziele. Alles Weitere richtet sich danach, was ihr selbst als notwendig für wirksame Prozesse bestimmt, abhängig von Größe, Komplexität und Kompetenz eures Teams.

Fazit

Die Kapitel 4 bis 10 beschreiben einen geschlossenen Kreis aus Verstehen, Planen, Ausführen, Bewerten und Verbessern. Der Aufwand liegt nicht im Schreiben von Dokumenten, sondern in der Entscheidung, welche eurer bestehenden Abläufe ihr formalisiert und welche ihr vorher ändert.

Ein guter erster Schritt ist eine Gap-Analyse entlang der Kapitelstruktur: für jede Anforderung notieren, was es bereits gibt, was fehlt und wer zuständig wäre. Damit habt ihr eine belastbare Grundlage für Zeitplan und Aufwandsschätzung – und wisst, ob eine Zertifizierung im gewünschten Zeitfenster realistisch ist.

Warum ist C5 für Cloud-Anbieter relevant?

Cloud-Umgebungen werden komplexer, Sicherheitsanforderungen strenger. Kund:innen wollen nachvollziehbar sehen, wie Daten geschützt, Risiken gemanagt und technische Maßnahmen umgesetzt werden.
C5 bietet genau dafür einen strukturierten, transparenten Rahmen – inklusive:

• klar definierter Sicherheitskontrollen,
• Anforderungen an Cloud-Architektur & technische Maßnahmen,
• Dokumentations- und Nachweispflichten,
• einem auditierbaren Prüfbericht, der Vertrauen schafft.

Damit ist C5 ein „Qualitätssiegel“ für moderne Cloud-Anbieter – und ein entscheidender Wettbewerbsvorteil.

Welche Bereiche deckt C5 ab?

Der C5-Katalog umfasst u. a.:

• Identity & Access Management (IAM, Rollen, Berechtigungen)
• Logging & Monitoring (Cloud Logs, SIEM, Alerting)
• Technische Security-Maßnahmen (Netzwerksegmentierung, Verschlüsselung, Patch-Management)
• Incident Response & Notfallprozesse
• Business Continuity & Disaster Recovery
• Risikomanagement & Governance
• Vendor-Management & Third-Party-Risiken

Damit geht C5 deutlich tiefer in technische Details als klassische Managementsysteme wie ISO 27001.

Wer braucht C5 – und ab wann?

Besonders relevant ist C5 für:

• SaaS-Anbieter, die an Enterprise oder Behörden verkaufen
• Cloud-Infrastrukturanbieter
• FinTech & InsurTech-Unternehmen
• HealthTech & GovTech-Plattformen
• Unternehmen mit sensiblen oder kritischen Datenverarbeitungen

Viele öffentliche Ausschreibungen fordern bereits C5-Nachweise – Tendenz steigend.

Wie läuft ein C5-Audit ab?

Ein C5-Audit wird üblicherweise durch externe Wirtschaftsprüfungsgesellschaften durchgeführt und umfasst:

1. Prüfung der Dokumentation
2. Bewertung der technischen Sicherheitsmaßnahmen
3. Interviews mit technischen & organisatorischen Rollen
4. Nachweisführung anhand konkreter Beispiele
5. Bericht & Ergebnisdarstellung

Besonders kritisch: technische Nachweise, z. B. Logs, IAM-Regeln, Backup-Prozesse oder Alerting-Konfigurationen.

Was sollten Cloud-Anbieter jetzt tun?

Wer C5-Anforderungen erfüllen möchte, sollte rechtzeitig:

• die aktuelle Cloud-Architektur überprüfen,
• Sicherheitskonzepte & Dokumentationen aktualisieren,
• technische Maßnahmen überprüfen (IAM, Logging, Monitoring),
• Rollen und Verantwortlichkeiten klären,
• Prozesse für Incident Response & Notfallmanagement definieren.

Der Aufwand lohnt sich, denn C5 stärkt Vertrauen, reduziert Sicherheitsrisiken und verbessert die Marktposition.

Unser letztes Offsite hat uns nach Athen geführt: in ein gemeinsames Airbnb, mit Laptops, Einkaufsliste und jeder Menge Lust auf Austausch. Tagsüber haben wir gearbeitet, mittags gekocht, abends die Stadt entdeckt. Ohne festen Ablauf – aber mit echtem Mehrwert.

Für uns war das mehr als ein Ortswechsel: Es war ein Perspektivwechsel. Und das merkt man – in Projekten, in Gesprächen, und im Umgang miteinander.

💻 Tagsüber: Remote-Mindset

Trotz Ferienhaus-Flair wurde bei uns auch gearbeitet – wirklich. Ob Strategie-Workshop, Bugfix oder Produkt-Diskussionen: Wir haben gemacht, was wir sonst remote tun – nur eben nebeneinander. Auf der sonnigen Terasse konnten wir alle unseren eigenen Arbeitsplatz aufbauen und klassisch Co-Worken. Aber dazwischen war auch Raum für:

• spontane Code-Reviews über die Schulter
• 1-on-1 Besprechungen zu verschiedensten Themen
• Gespräche, die remote nie passiert wären

🍝 Mittags: Kochen statt

Unser Mittagessen war nicht bestellt – sondern handgemacht. Jeden Tag hat jemand anderes gekocht. Es gab Curry, Bowls. Warum das cool war? Weil dabei Dinge entstanden sind, die man nicht planen kann: Gespräche, Lacher, und manchmal sogar neue Ideen.

🏙️ Abends: Stadt, Essen, Gespräche ohne Agenda

Nach getaner Arbeit ging’s raus. Athen bei Nacht ist ein Erlebnis – und wir haben’s genutzt: Essen in kleinen Tavernen, Rooftop-Bars mit Blick auf die Akropolis, durch enge Gassen treiben lassen. Kein Programmpunkt, keine Gruppenpflicht. Nur das Team, die Zeit zusammen – und ziemlich gutes Essen.

🧠 Was wir mitgenommen haben

• Mehr Verständnis für die Menschen hinter den Profilbildern
• Einen Haufen schöner Erinnerungen – und mehr Flow im Alltag
• Die Erkenntnis: Gute Remote-Arbeit braucht ab und zu reale Begegnung

Ob neue Teammitglieder, neue Ideen oder neue Perspektiven – nach Athen sind wir nicht nur erholt zurückgekommen, sondern auch ein Stück näher zusammengerückt.