Vor einem TISAX Assessment zählt nicht allein, ob eine Lieferantenrichtlinie existiert. Entscheidend ist der konkrete Steuerungsnachweis: wie das Unternehmen für einen bestimmten Lieferanten Anforderungen festgelegt, Evidenz bewertet, Änderungen erkannt und über eine Abweichung entschieden hat.
Hinweis: Allgemeine fachliche Einordnung; keine Rechtsberatung, Zertifizierungs- oder Auditgarantie.
Genau dort verschiebt ISA2027 den Schwerpunkt. ENX hat die neue Version am 1. Juli 2026 vorgestellt; die offizielle englische ISA2027-Datei ist verfügbar. ISA2027 gilt für TISAX Assessments, die ab dem 1. Januar 2027 bestellt werden. Das Bestelldatum ist damit der maßgebliche Steuerungshebel für die Katalogversion. Der zugleich eingeführte jährliche Veröffentlichungstakt ändert laut ENX weder die bestehende Labelgültigkeit noch automatisch die Reassessment-Frequenz. Bestehende Labels behalten ihre Gültigkeitsdauer; Labels können weiterhin bis zu drei Jahre gültig sein.
Das ist keine jährliche Zertifizierungsmaschine. Es ist ein häufigerer Katalogtakt bei unverändertem Label-Lebenszyklus. Für Management und ISMS entsteht der Handlungsdruck deshalb nicht aus einem künstlichen Jahresalarm, sondern aus anspruchsvollerer Supply-Chain-Evidenz.
Auch der Prototypenschutz wird strukturell gestrafft: Die bisher fünf Gruppen werden in zwei Domains gebündelt. Die offizielle englische ISA2027-Arbeitsmappe enthält insgesamt 78 nummerierte Kontrollfragen: 46 im Modul Information Security, 20 im Modul Prototype Protection und 12 im Modul Data Protection. Das ist keine pauschale Auditmenge; welche Module und Fragen relevant sind, richtet sich nach den Assessment Objectives. Diese Neuordnung, die Modulabdeckung und der stärkere Lieferantenfokus sollten im Versionsdelta getrennt betrachtet werden. Aussagen über Umstufungen von „should“ zu „must“ benötigen weiterhin einen belastbaren Versionsvergleich.
Das Lieferantenproblem ist nicht der Vertrag, sondern die geschlossene Nachweiskette
Viele Organisationen haben Sicherheitsklauseln, Lieferantenlisten und Selbstauskünfte. Trotzdem bleibt offen, welche Anforderungen für welchen Schutzbedarf gelten, wer die eingereichten Nachweise fachlich bewertet und was bei wesentlichen Änderungen passiert.
Ein typischer Bruch sieht so aus: Der Einkauf fordert „angemessene Informationssicherheit“. Der Lieferant verweist auf ein Zertifikat oder Label. Das Fachteam nimmt eine neue Cloud-Komponente in Betrieb. Das ISMS erfährt davon erst beim nächsten Review. Jede Einzelaktivität wirkt plausibel; gemeinsam bilden sie keine belastbare Steuerung.
Man kann den Unterschied an einer hypothetischen Betriebsszene sehen. Ein Entwicklungsdienstleister darf auf ein abgegrenztes Projektarchiv zugreifen. Bei der Erstfreigabe passt sein Nachweis zum vereinbarten Service und Standort. Sechs Monate später verlagert er einen Teil der Leistung an einen Unterauftragnehmer. Der Vertrag enthält zwar eine allgemeine Sicherheitsklausel, doch weder Einkauf noch Fachbereich haben festgelegt, welche Änderung meldepflichtig ist und wer ihre Auswirkung bewertet. Das Problem ist dann nicht das fehlende Dokument. Es fehlt der Übergang von einer neuen Tatsache zu einer neuen Entscheidung.
Eine geschlossene Nachweiskette muss deshalb mehr leisten als Ablage. Sie verbindet den konkreten Leistungsumfang mit Schutzbedarf und Anforderungen, ordnet die akzeptierte Evidenz ihrem tatsächlichen Scope zu und hält fest, wer das verbleibende Risiko verantwortet. Ändert sich ein Glied, wird nicht automatisch die gesamte Beziehung gestoppt. Aber die frühere Freigabe darf auch nicht stillschweigend weitergelten. Genau diese Entscheidungslogik macht aus Lieferantenverwaltung belastbare Governance.
Im Szenario meldet der Dienstleister die Unterbeauftragung an einem Dienstag. Der Einkauf leitet die Nachricht an den Fachbereich weiter, hält den Vorgang aber zunächst für eine operative Vertragsfrage. Der Fachbereich sieht keinen Anlass zur Eskalation, weil Zugriffsrechte formal unverändert bleiben. Informationssicherheit erfährt erst eine Woche später davon. Inzwischen ist unklar, ob der vorhandene Nachweis den neuen Leistungsteil, Standort und Zugriffsweg umfasst. Kein Beteiligter hat erkennbar falsch gehandelt; jede Rolle hat nur innerhalb ihres eigenen Ausschnitts entschieden. Genau diese lokale Plausibilität erzeugt die systemische Lücke.
Ein tragfähiger Ablauf macht aus der Meldung deshalb einen identifizierbaren Review-Fall. Der Leistungsowner beschreibt, was sich tatsächlich ändert. Der Einkauf ordnet Vertrag, Unterauftragnehmerregel und offene Zusagen zu. Informationssicherheit prüft Schutzbedarf, Nachweis-Scope und zusätzliche Risiken; Datenschutz und weitere Funktionen werden dort eingebunden, wo ihr Gegenstand berührt ist. Die freigabeberechtigte Rolle entscheidet anschließend über Fortführung, Begrenzung oder zusätzliche Evidenz. Das ursprüngliche Onboarding bleibt als damalige Entscheidung erhalten, wird aber für den geänderten Scope sichtbar ergänzt.
Für das Management entsteht daraus ein anderer Blick auf Lieferantenrisiko. Eine Liste abgelaufener Dokumente zeigt Verwaltungsarbeit, aber nicht zwingend die dringendsten Entscheidungen. Relevanter sind Beziehungen, bei denen Schutzbedarf, aktuelle Leistung und akzeptierte Evidenz auseinanderlaufen oder eine wesentliche Änderung ohne Owner offensteht. Dort kann Management Ressourcen priorisieren, Übergangskontrollen verlangen oder eine kommerzielle Abhängigkeit bewusst behandeln.
ISA2027 verstärkt nach der ENX-Einordnung insbesondere bei hohem Schutzbedarf die Erwartungen an Dokumentation, Review und Monitoring der Lieferanten-Compliance samt zugehöriger Evidenz. Wesentliche Änderungen beim Lieferanten oder in der Lieferkettenstruktur sollen in Reviews einfließen. Bei sehr hohem Schutzbedarf werden stärkere Assurance-Nachweise erwartet, etwa ein TISAX Label, eine gleichwertige unabhängige Bewertung oder ein angemessenes Lieferantenaudit.
Statische Dokumente belegen einen Zeitpunkt und einen Umfang; sie ersetzen weder Scope-Prüfung noch laufende Änderungssignale.
Aus Anforderungen muss ein Steuerungsmodell werden
Die praktische Antwort ist keine größere Fragebogenbibliothek. Sie ist ein risikobasiertes Lieferantensteuerungsmodell, das Anforderungen, Evidenz und Entscheidungen verbindet.
1. Schutzbedarf und Abhängigkeit zuerst
Segmentieren Sie Lieferanten nicht nur nach Umsatz oder Einkaufsvolumen. Entscheidend sind Informationswerte, Zugriffswege, Betriebsabhängigkeit, Unterauftragnehmer, Austauschbarkeit und die Folgen eines Ausfalls oder Datenabflusses. Ein kleiner Spezialanbieter kann sicherheitskritischer sein als ein großer Bürolieferant.
Die Segmentierung muss zu prüfbaren Konsequenzen führen. Für jedes Segment sind geltende Anforderungen, akzeptierte Nachweise, Prüfrhythmus und Autorität für Ausnahmegenehmigungen festgelegt.
Damit die Segmentierung nicht zu einer einmaligen Tabellenübung wird, braucht jedes Segment einen Mindestentscheidungsweg. Ein niedrigerer Schutzbedarf kann mit standardisierter Evidenz und periodischem Review auskommen. Bei höherem Schutzbedarf werden Scope-Prüfung, fachliche Freigabe und Änderungssignale enger geführt. Ausschlaggebend ist nicht die Zahl der Kategorien, sondern ihre Wirkung: Zwei Lieferantenklassen, die dieselben Anforderungen, Nachweise und Eskalationen auslösen, sind meist eine Klassifikation ohne Steuerungsnutzen.
2. Anforderungen eindeutig kaskadieren
Eine Klausel wie „der Lieferant hält angemessene Sicherheitsmaßnahmen ein“ lässt viel Interpretationsraum. Besser ist eine nachvollziehbare Zuordnung von Schutzbedarf zu Mindestanforderungen, Nachweisformen, Meldefristen, Unterauftragnehmerregeln und Änderungsmitteilungen.
Kaskadierung bedeutet nicht, jedem Kleinstlieferanten den gesamten Katalog zu schicken. Sie bedeutet, dass relevante Anforderungen entlang der tatsächlichen Leistungskette weitergegeben und ihre Umsetzung angemessen verifiziert werden.
3. Evidenz auf Aussagekraft prüfen
Ein Label, Zertifikat oder Auditbericht ist kein universeller Freifahrtschein. Prüfen Sie Scope, Standort, betrachtete Services, Schutzbedarf, Gültigkeit und erkennbare Einschränkungen. Dokumentieren Sie, warum der Nachweis für die konkrete Beziehung ausreicht – oder welche ergänzende Evidenz erforderlich ist.
Bei sehr hohem Schutzbedarf sollte die akzeptierte Assurance-Form ausdrücklich begründet und freigegeben sein. „Dokument vorhanden“ ist kein Bewertungsurteil.
Nehmen wir hypothetisch einen Anbieter, dessen Label einen deutschen Standort und einen bestimmten Managed Service umfasst. Das beauftragte Team nutzt inzwischen zusätzlich einen Service aus einem anderen Standort. Der Nachweis kann weiterhin echt, gültig und fachlich hochwertig sein – und trotzdem die relevante Leistung nicht vollständig abdecken. Die operative Entscheidung darf dann nicht auf „Zertifikat ja oder nein“ verkürzt werden. Sie muss den belegten Teil der Beziehung, die verbleibende Lücke und eine angemessene ergänzende Prüfung oder Begrenzung bestimmen.
Diese Differenzierung verhindert zwei gleichermaßen unbrauchbare Reaktionen. Die erste akzeptiert jedes Dokument ohne Scope-Prüfung. Die zweite verwirft pauschal jede Evidenz, die nicht exakt der eigenen Wunschform entspricht. Gute Steuerung nutzt vorhandene Assurance, benennt ihre Reichweite und ergänzt nur dort, wo Schutzbedarf und offene Fragen es verlangen. Das spart nicht nur Prüfaufwand. Es macht die Begründung später auch für Management und Assessment nachvollziehbar.
4. Änderungen zu Review-Auslösern machen
ISA2027 betont wesentliche Änderungen. Die Organisation braucht daher definierte Signale: neue Unterauftragnehmer, Standortwechsel, Eigentümerwechsel, erhebliche Vorfälle, Plattformmigration, veränderte Datenflüsse, neue Fernzugriffe oder ein veränderter Leistungsumfang.
Diese Signale müssen einen abgestuften Review auslösen. Ein jährliches Lieferantengespräch allein erfasst Veränderungen zwischen zwei Terminen nicht zuverlässig.
Die Signalwege müssen zu den tatsächlichen Informationsquellen passen. Ein Standortwechsel kann im Einkauf ankommen, ein neuer technischer Zugriff im Fachteam, ein Vorfall im SOC und ein Unterauftragnehmer im Vertragsmanagement. Von allen Funktionen dieselbe Sicherheitsbewertung zu verlangen wäre ineffizient. Sie müssen jedoch erkennen können, dass ein definiertes Signal vorliegt, und es mit Mindestdaten an den gemeinsamen Review-Prozess übergeben. Der zentrale Kontrollpunkt ist damit nicht ein allwissendes Lieferantenregister, sondern eine verlässliche Übergabe aus verteilten Beobachtungen.
Ein Review-Auslöser ist noch keine vollständige Neubewertung. Bei einer geänderten Firmenanschrift genügt möglicherweise eine administrative Prüfung. Ein neuer privilegierter Fernzugriff kann dagegen eine fachliche Scope-Prüfung, zusätzliche technische Begrenzungen und eine erneute Freigabe verlangen. Der Nutzen eines abgestuften Verfahrens liegt darin, dass nicht jede Änderung denselben Apparat startet, relevante Änderungen aber auch nicht im allgemeinen Postfach verdunsten.
In einem hypothetischen Donnerstagabend-Szenario meldet ein wichtiger Lieferant einen erheblichen Vorfall und zugleich eine vorübergehende Verlagerung seiner Leistung. Wer jetzt nur einen Jahresreview kennt, improvisiert unter Zeitdruck. Ein vorbereitetes Modell klärt zuerst betroffene Services und Datenflüsse, prüft dann vorhandene Evidenz und Übergangskontrollen und legt schließlich fest, wer über Fortführung, Begrenzung oder Aussetzung entscheidet. Aus einer Nachricht entsteht so eine kontrollierte Folge von Feststellung, Bewertung und Freigabe.
5. Abweichungen managementfähig entscheiden
Nicht jeder Lieferant liefert sofort den gewünschten Nachweis. Eine steuerbare Organisation kennt Alternativen: Zusatzkontrollen, begrenzter Scope, technische Abschottung, zeitlich befristete Ausnahme, Auditrecht, Exit-Plan oder Anbieterwechsel. Entscheidung, Restlaufzeit und Verantwortlicher werden dokumentiert.
„Vom Einkauf akzeptiert“ ist keine Risikobehandlungskategorie. Der Mechanismus dahinter ist die Trennung von kommerzieller Beauftragung und Risikofreigabe. Beide Entscheidungen können zusammenfallen, dürfen aber nicht versehentlich verwechselt werden.
Diese Trennung verändert auch die Managementinformation. Statt pauschal von „nicht complianten Lieferanten“ zu sprechen, sollte die Vorlage zeigen, welche Anforderung oder Evidenz fehlt, welche konkrete Leistung betroffen ist und welche Handlungsoptionen bestehen. So kann Management Nutzen, Abhängigkeit, Übergangskontrollen und Restlaufzeit gegeneinander abwägen, ohne die fachliche Bewertung neu zu erfinden. Die Konsequenz kann eine Zusatzprüfung sein, aber ebenso eine technische Begrenzung oder ein vorbereiteter Exit. Governance besteht hier nicht darin, jede Ausnahme zu verbieten, sondern jede Ausnahme entscheidbar und endlich zu machen.
Die Entscheidungsvorlage sollte knapp genug sein, um tatsächlich entschieden zu werden, und präzise genug, um später nicht als Stimmungsbild gelesen zu werden. Sie nennt die konkrete Evidenzlücke, den betroffenen Scope, die mögliche Auswirkung, vorhandene Übergangskontrollen, die vorgeschlagene Laufzeit und den nächsten überprüfbaren Schritt. Ablaufdatum, Owner und Eskalationsschwelle müssen gemeinsam festgelegt sein.
Hypothetisch könnte ein kaum ersetzbarer Spezialanbieter den geforderten unabhängigen Nachweis erst in vier Monaten liefern. Das Management kann die Leistung dennoch zeitlich begrenzt fortführen, wenn Zugriff und Scope reduziert, zusätzliche Protokollierung eingeführt und ein Exit-Szenario vorbereitet werden. Entscheidend ist nicht, dass jede Lücke sofort verschwindet. Entscheidend ist, dass die Organisation bewusst festlegt, welches Restrisiko sie wie lange trägt und welches Ereignis die Entscheidung vorzeitig öffnet.
Der Jahreszyklus verlangt Versionsfähigkeit, keine jährliche Panik
ISA2027 führt ein Jahresmodell ein: Kataloge sollen typischerweise im Sommer erscheinen und zum 1. Januar des Folgejahres für neu beauftragte Assessments wirksam werden. Organisationen werden bei regulären Reassessments daher weiterhin Versionen überspringen können.
Die richtige Reaktion ist ein Versionsdelta-Prozess. Sobald eine neue ISA erscheint, ermittelt das ISMS geänderte Anforderungen, betroffene Lieferantensegmente und fehlende Evidenz. Es bestimmt anzupassende Verträge und Review-Formulare und trennt Maßnahmen für das nächste beauftragte Assessment von solchen, die unabhängig davon wegen des realen Risikos sinnvoll sind.
Damit wird der Katalogwechsel planbar. Er landet nicht als Komplettprojekt kurz vor dem Assessment, sondern als priorisierte Änderung im bestehenden Kontrollsystem.
Ein umsetzbarer 60-Tage-Plan
In den ersten zwei Wochen werden Lieferantenpopulation, Schutzbedarf und vorhandene Assurance-Nachweise zusammengeführt. Lücken und widersprüchliche Klassifikationen bleiben sichtbar.
Bis Tag 30 werden für die wichtigsten Segmente akzeptierte Nachweisformen, Prüfkriterien und Änderungssignale definiert. Mindestens die kritischsten Lieferanten erhalten einen dokumentierten Scope- und Evidenzcheck.
Bis Tag 45 werden Verantwortlichkeiten zwischen Einkauf, Fachbereich, Informationssicherheit, Datenschutz und Management geklärt. Für Abweichungen gibt es Entscheidungsschwellen und Fristen.
Bis Tag 60 testet die Organisation den Mechanismus an drei realen Lieferanten: einem mit ausreichendem Nachweis, einem mit Scope-Lücke und einem mit wesentlicher Änderung. Die Testfrage lautet nicht, ob das Formular vollständig ist, sondern ob eine begründete Entscheidung entsteht.
Managementcheckliste
- Lieferanten sind nach Informationswert, Zugriff, Abhängigkeit und Schutzbedarf segmentiert; Segmente führen zu unterschiedlichen Anforderungen und Review-Zyklen.
- Labels, Zertifikate und Audits werden gegen den konkreten Scope geprüft.
- Unterauftragnehmer und Anforderungskaskaden sind berücksichtigt.
- Wesentliche Änderungen lösen auch außerhalb des Kalenderreviews eine Neubewertung aus.
- Evidenzlücken besitzen Eigentümer, Frist und Übergangskontrolle.
- Kommerzielle Freigabe und Risikofreigabe bleiben unterscheidbar.
- Ein dokumentierter ISA-Versionsdelta-Prozess berücksichtigt Bestelldatum, Jahreszyklus, Labelgültigkeit und Reassessment-Frequenz.
Fazit: der A-R-C-Impuls
ISA2027 macht Lieferantensteuerung nicht dadurch anspruchsvoller, dass mehr Dokumente gesammelt werden. Der Unterschied liegt in der nachvollziehbaren Verbindung von Schutzbedarf, Anforderungen, Evidenz, Änderung und Entscheidung.
Der A-R-C-Impuls: Wählen Sie drei sicherheitskritische Lieferanten und zeichnen Sie für jeden die Nachweiskette auf einer Seite nach. Wenn Scope, Bewertung, Änderungssignal oder Ausnahmeentscheidung fehlen, haben Sie Ihren nächsten priorisierten Arbeitspunkt. So wird Informationssicherheit in der Lieferkette steuerbar, prüfbar und managementfähig.
Abgrenzung
Dieser Beitrag bietet eine fachliche Governance-Einordnung. Er ist keine Rechtsberatung und keine verbindliche Auslegung des ISA-Katalogs. Er ersetzt weder die Prüfung der offiziellen ISA2027-Datei noch die Abstimmung mit ENX, Kunden oder einem zugelassenen Prüfdienstleister. Eine TISAX-Label- oder Assessment-Garantie wird nicht gegeben.
Quellen
- ENX Association, „10 Years of TISAX – VDA ISA2027 Released“, 01.07.2026, abgerufen am 02.08.2026: https://enx.com/en-US/news/isa2027/
- ENX Association, offizielle englische ISA2027-Arbeitsmappe (bei Abweichungen maßgeblich), abgerufen am 02.08.2026: https://www.enx.com/isa2027-en.xlsx
Über den Autor
Andreas Rühl unterstützt Unternehmen als Interim CISO und ISMS/GRC-Berater. Sein Schwerpunkt liegt darauf, Informationssicherheit steuerbar, prüfbar und managementfähig zu machen.