TISAX®

Überblick

TISAX aus Management-Perspektive

Für die Geschäftsleitung ist TISAX zunächst eine geschäftliche Anforderung. Kunden verlangen einen nachvollziehbaren Nachweis, bevor sie besonders schützenswerte Informationen, Prototypen, Entwicklungsdaten oder Zugänge bereitstellen. Fehlt ein passendes Ergebnis, können Ausschreibungen, Nominierungen, Entwicklungsaufträge oder Vertragsverlängerungen gefährdet sein.

Die Leitung muss deshalb vier Entscheidungen treffen: Welcher Scope ist geschäftlich erforderlich? Welche Assessment Objectives werden verlangt? Welche Risiken werden akzeptiert? Welche Ressourcen stehen für Umsetzung, Prüfung und nachhaltigen Betrieb bereit? Diese Entscheidungen lassen sich nicht vollständig an die IT delegieren. Sie betreffen Organisation, Recht, Einkauf, Personal, Facility Management, Entwicklung, Produktion und Lieferantenmanagement.

Was der CEO vor dem Start wissen sollte

Ein TISAX-Projekt benötigt einen klaren Sponsor, ein belastbares Budget und einen realistischen Zeitrahmen. Die Prüfung selbst ist nur der sichtbare Endpunkt. Der größere Aufwand liegt in der Vorbereitung: Scope klären, Prozesse beschreiben, Verantwortlichkeiten festlegen, technische Lücken schließen, Nachweise sammeln, Selbsteinschätzung durchführen und interne Wirksamkeitsprüfungen organisieren.

Ein unrealistisch enger Scope kann später operative Schnittstellen ausblenden und zu Rückfragen führen. Ein zu weiter Scope erhöht Aufwand und Komplexität. Der wirtschaftlich sinnvolle Scope umfasst alle Prozesse, Standorte, Ressourcen und Dienstleister, die für die Schutzobjekte und Assessment Objectives tatsächlich relevant sind.

Grundlagen und Begriffe

TISAX steht für Trusted Information Security Assessment Exchange. Das Verfahren verbindet eine standardisierte Bewertung mit einem kontrollierten Austausch der Ergebnisse. Der VDA verantwortet den ISA-Katalog; die ENX Association betreibt das TISAX-System, registriert Teilnehmer und Scopes, regelt den Austausch und beaufsichtigt das Verfahren. Die Assessments werden von zugelassenen Prüfdienstleistern durchgeführt.

Das zentrale Problem, das TISAX adressiert, ist die wiederholte Sicherheitsprüfung derselben Lieferanten durch unterschiedliche Kunden. Ein standardisiertes Ergebnis reduziert Mehrfachprüfungen, sofern der anfragende Partner Scope, Objectives und Ergebnis akzeptiert. Der Austausch erfolgt nicht öffentlich. Das geprüfte Unternehmen entscheidet, mit welchen registrierten TISAX-Teilnehmern es sein Ergebnis teilt.

TISAX ist kein Zertifizierungsstandard

Die Bezeichnung „TISAX-Zertifizierung“ ist verbreitet, fachlich jedoch ungenau. TISAX führt zu einem Assessment-Ergebnis und zu Labels im ENX-Portal. Es gibt kein frei verwendbares ISO-ähnliches Zertifikat, das unabhängig von Scope, Objectives und Freigabestatus bewertet werden kann. Geschäftspartner prüfen, ob das Ergebnis für ihren konkreten Informationsaustausch ausreicht.

Rollen und Verantwortlichkeiten

Bei internationalen Unternehmen ist eine zusätzliche Governance sinnvoll: zentraler TISAX-Owner, lokale Scope-Verantwortliche, fachliche Control Owner und ein Management Steering Committee. Ohne klare Rollen entstehen widersprüchliche Antworten, doppelte Maßnahmen und Nachweislücken zwischen Standorten.

Assessment Objectives richtig bestimmen

Assessment Objectives bestimmen, welche Schutzanforderungen im registrierten Scope geprüft werden. Sie werden häufig vom Kunden vorgegeben. Unternehmen sollten die Anforderung schriftlich bestätigen lassen und nicht allein aus Projektbezeichnungen ableiten. Falsch gewählte Objectives können ein formal erfolgreiches Assessment wirtschaftlich unbrauchbar machen.

Die konkrete Bezeichnung und Zuordnung der Objectives richtet sich nach dem jeweils gültigen ENX- und VDA-Stand. Vor Registrierung sollten Unternehmen den aktuellen Objective-Wizard beziehungsweise die offiziellen Unterlagen verwenden. Veraltete Projektvorlagen können zu falschen Labels oder unnötigem Prüfaufwand führen.

Assessment Scope: Grenzen, Standorte und Abhängigkeiten

Der Assessment Scope ist die wichtigste Architekturentscheidung des gesamten Vorhabens. Er umfasst alle Prozesse, Verfahren und Ressourcen unter Verantwortung der bewerteten Organisation, die für die Schutzobjekte und Schutzziele der gewählten Assessment Objectives an den angegebenen Standorten relevant sind.

Bestandteile eines belastbaren Scopes

Typische Scope-Fehler

Häufig werden zentrale IT-Dienste ausgeschlossen, obwohl sie mehrere bewertete Standorte versorgen. Ebenso problematisch sind nicht berücksichtigte Homeoffice-Arbeitsplätze, Cloud-Dienste, Entwicklungsumgebungen, externe Lager oder gemeinsam genutzte Werkstätten. Der Scope muss die reale Leistungserbringung abbilden. Organigramme, Netzpläne, Datenflüsse, Dienstleisterlisten und Standortbegehungen helfen, blinde Flecken zu vermeiden.

Multi-Site-Organisationen sollten prüfen, ob zentrale Prozesse tatsächlich einheitlich betrieben werden. Ein gemeinsames ISMS reduziert Aufwand nur, wenn Richtlinien, Risikomethodik, Kontrollbetrieb, Nachweise und Eskalationen konsistent sind. Lokale Abweichungen müssen sichtbar bleiben und dürfen nicht durch zentrale Dokumente verdeckt werden.

VDA ISA: Bewertungsgrundlage und Versionsmanagement

Der VDA ISA ist die fachliche Bewertungsgrundlage. Er unterstützt sowohl die Selbsteinschätzung als auch das TISAX-Assessment. Der Katalog verbindet Anforderungen an Informationssicherheit mit branchenspezifischen Modulen. Maßgeblich ist stets die für das Assessment gültige Version. Unternehmen sollten Versionswechsel als eigenes Change-Projekt behandeln, weil neue oder geänderte Anforderungen Auswirkungen auf Richtlinien, Kontrollen und Nachweise haben können.

Wie der Katalog gelesen werden sollte

Ein Control besteht nicht nur aus einer Frage. Relevant sind Ziel, Anforderungen, Zusatzanforderungen, Reifegradkriterien und erwartete Nachweise. Eine positive Selbsteinschätzung ist nur vertretbar, wenn Prozess, Verantwortlichkeit, Umsetzung und Wirksamkeit zusammenpassen. Einzelne Dokumente ersetzen keine gelebte Praxis.

VDA ISA 6 und zukünftige Versionen

VDA ISA 6 wurde 2023 veröffentlicht und bildet die Grundlage vieler aktueller Assessments. Der VDA informiert zugleich über die Weiterentwicklung des Katalogs. Unternehmen sollten nicht warten, bis ein neuer Katalog verbindlich wird. Eine strukturierte Gap-Analyse vor dem Versionswechsel reduziert spätere Hektik und verhindert, dass Dokumente erst unmittelbar vor dem Assessment angepasst werden.

Reifegradmodell verstehen und belastbar anwenden

Der VDA ISA verwendet ein Reifegradmodell. Bewertet wird nicht nur, ob eine Aktivität existiert, sondern wie verlässlich, gesteuert und wirksam sie betrieben wird. Eine formale Richtlinie ohne nachweisbare Anwendung erreicht deshalb keinen belastbaren Reifegrad.

Für die Prüfung ist die Gesamtlogik entscheidend. Ein einzelnes Control mit niedrigem Reifegrad kann je nach Bedeutung das Ergebnis beeinflussen. Unternehmen sollten deshalb nicht nur Durchschnittswerte betrachten, sondern kritische Controls, Abhängigkeiten und die Qualität der Nachweise priorisieren.

Warum Reifegrad 3 in der Praxis eine hohe Hürde ist

„Etabliert“ verlangt mehr als eine schriftliche Verfahrensanweisung. Der Prozess muss innerhalb des Scopes bekannt, umgesetzt, wiederholbar und überprüfbar sein. Unterschiedliche Standorte, Schichtmodelle, externe Mitarbeiter und Dienstleister erhöhen die Beweislast. Ein Prozess, der nur am Hauptstandort funktioniert, ist in einem internationalen Scope nicht flächendeckend etabliert.

Assessment Levels AL1, AL2 und AL3

Assessment Levels beschreiben die Art und Intensität der Prüfung. Sie sind nicht mit dem Reifegrad zu verwechseln. Das erforderliche Level ergibt sich aus den Assessment Objectives und dem Schutzbedarf. Unternehmen sollten Level und Objectives vor Beauftragung verbindlich prüfen.

Die pauschale Annahme „AL3 ist immer besser“ führt zu unnötigen Kosten. Maßgeblich ist die Kundenanforderung. Umgekehrt kann ein zu niedriges Level trotz bestandener Prüfung unbrauchbar sein. Scope, Objectives und Level bilden gemeinsam den wirtschaftlichen Wert des Ergebnisses.

Der TISAX-Assessment-Prozess

Ein TISAX-Vorhaben lässt sich in Registrierung, Vorbereitung, Assessment, Korrektur und Ergebnisaustausch gliedern. Die ENX-Unterlagen definieren den formalen Prozess. Intern sollte das Unternehmen einen erweiterten Projektzyklus verwenden, der Managemententscheidungen, technische Umsetzung und Nachweisqualität einschließt.

Prüfdienstleister auswählen

Der günstigste Anbieter ist nicht automatisch die wirtschaftlich beste Wahl. Relevant sind Branchenerfahrung, internationale Abdeckung, verfügbare Auditoren, Sprache, Terminrisiko, Verständnis komplexer Scopes und Klarheit des Angebots. Unternehmen sollten prüfen, welche Leistungen im Preis enthalten sind und wie Nachbewertungen, Reiseaufwand oder Scope-Änderungen behandelt werden.

Umgang mit Feststellungen

Feststellungen sollten nicht nur mit kurzfristigen Dokumentenänderungen beantwortet werden. Eine belastbare Korrektur umfasst Ursache, Sofortmaßnahme, dauerhafte Maßnahme, Verantwortlichkeit, Termin und Wirksamkeitsnachweis. Wiederkehrende Abweichungen deuten häufig auf unklare Governance oder fehlende Kontrollüberwachung hin.

Dokumente und Nachweise: vom Papier zur Wirksamkeit

Prüfer bewerten Nachweise im Zusammenhang mit dem jeweiligen Control. Eine große Dokumentensammlung ist kein Qualitätsmerkmal. Entscheidend sind Aktualität, Scope-Bezug, Freigabe, Anwendung und Konsistenz. Richtlinien müssen zu technischen Konfigurationen, Tickets, Protokollen und Interviews passen.

Die Nachweiskette

Eine überzeugende Nachweiskette beginnt mit einer Anforderung, führt über Risiko und Regelwerk zur operativen Kontrolle und endet bei Wirksamkeitsprüfung und Verbesserung. Beispiel: Schutzbedarf vertraulicher Entwicklungsdaten → Risiko unberechtigter Zugriff → Rollenmodell und MFA → genehmigter Berechtigungsantrag → technische Konfiguration → Rezertifizierungsprotokoll → Kennzahl und Review.

Technische Umsetzung im Automotive-Umfeld

TISAX schreibt keine bestimmte Produktlandschaft vor. Technische Maßnahmen müssen zum Risiko, Scope und Objective passen. Prüfer betrachten Konfiguration, Betrieb und Nachweis. Ein gekauftes Tool erfüllt keine Anforderung, wenn Rollen, Überwachung und Reaktion fehlen.

Automotive-spezifische Schnittstellen

In der automobilen Lieferkette verdienen EDI, OFTP2, Remote-Support, Entwicklungsportale, CAD-Austausch, Software-Repositories und Produktionszugänge besondere Aufmerksamkeit. Verantwortlichkeiten zwischen OEM, Zulieferer und Dienstleister müssen dokumentiert sein. Für jede Schnittstelle sollten Datenarten, Authentisierung, Verschlüsselung, Logging, Störungsprozess und Änderungsverantwortung bekannt sein.

Prototypenschutz

Prototypenschutz umfasst mehr als verschlossene Räume. Geschützt werden Fahrzeuge, Komponenten, Muster, Zeichnungen, Fotos, Testdaten, Softwarestände und öffentliche Wahrnehmung. Das Schutzkonzept muss Entwicklung, Transport, Werkstatt, Testgelände, Veranstaltung und Entsorgung berücksichtigen.

Die Wirksamkeit zeigt sich häufig in Details: Sind Besucher tatsächlich begleitet? Werden Fotos technisch und organisatorisch verhindert? Sind Nachtschichten und externe Reinigung berücksichtigt? Gibt es klare Regeln für beschädigte oder ausgesonderte Prototypenteile?

Datenschutz im TISAX-Kontext

Datenschutzanforderungen im TISAX-Kontext ergänzen die Informationssicherheitsbewertung, ersetzen jedoch keine vollständige rechtliche Datenschutzprüfung. Organisationen müssen Rollen, Zwecke, Rechtsgrundlagen, Verträge, technische Maßnahmen und Löschprozesse konsistent beherrschen. Besonders relevant sind Auftragsverarbeitung, internationale Transfers, Testdaten, Beschäftigtendaten und vernetzte Fahrzeugdaten.

Prüfbare Kernelemente

Ein Verzeichnis von Verarbeitungstätigkeiten, aktuelle Verträge, dokumentierte technische und organisatorische Maßnahmen, Berechtigungskonzepte, Löschregeln, Incident-Prozesse und Schulungsnachweise bilden die Grundlage. Entscheidend ist die Verbindung zur tatsächlichen Systemlandschaft. Generische TOM-Dokumente ohne Scope- und Dienstleisterbezug überzeugen selten.

Lieferanten und Drittparteien steuern

Viele TISAX-Lücken liegen außerhalb der eigenen Organisation. Cloud-Provider, Entwicklungsdienstleister, Logistikpartner, Rechenzentren, Zeitarbeit und Wartungsfirmen können direkten Einfluss auf die Schutzobjekte haben. Lieferantensteuerung muss deshalb risikobasiert, vertraglich und operativ erfolgen.

Ein TISAX-Label des Lieferanten kann ein wichtiger Nachweis sein, ersetzt jedoch nicht die eigene Risikobewertung. Scope, Objectives, Level, Gültigkeit und Freigabe müssen zur bezogenen Leistung passen.

Typische Findings und Fehlerbilder

20 häufige Feststellungen

1. Unklarer oder zu eng beschriebener Assessment Scope.
2. Risikoregister ohne Verbindung zu Assets, Prozessen und Maßnahmen.
3. Richtlinien sind freigegeben, aber nicht in allen Standorten umgesetzt.
4. Privilegierte Konten werden nicht regelmäßig rezertifiziert.
5. Cloud-Dienste und SaaS-Anwendungen fehlen im Asset-Inventar.
6. Backups werden erstellt, Restore-Tests sind jedoch nicht belastbar dokumentiert.
7. Notfallpläne nennen Rollen, enthalten aber keine realistischen Wiederanlaufverfahren.
8. Kritische Lieferanten wurden nicht nach einheitlichen Kriterien bewertet.
9. Zutrittslisten stimmen nicht mit aktiven Beschäftigten und Dienstleistern überein.
10. Sicherheitsvorfälle werden technisch bearbeitet, aber nicht systematisch ausgewertet.
11. Awareness-Schulungen messen Teilnahme, nicht Wirksamkeit.
12. Patch-Ausnahmen besitzen keine Risikoakzeptanz oder Befristung.
13. Netzwerksegmentierung ist geplant, Regeln und Datenflüsse sind nicht dokumentiert.
14. Joiner-Mover-Leaver-Prozesse funktionieren bei internen Beschäftigten, nicht bei Externen.
15. Klassifizierungsregeln existieren, werden in Kollaborationsplattformen nicht angewendet.
16. Prototypenbereiche berücksichtigen Besucher, Reinigung oder Schichtbetrieb unzureichend.
17. Kennzahlen werden erhoben, führen aber zu keiner Managemententscheidung.
18. Interne Audits prüfen Dokumente, nicht die operative Wirksamkeit.
19. Korrekturmaßnahmen behandeln Symptome statt Ursachen.
20. Nachweise wurden kurz vor dem Assessment erzeugt und zeigen keinen stabilen Betrieb.

Ursachenmuster

Die meisten Abweichungen lassen sich auf fünf Ursachen zurückführen: fehlende Ownership, unklarer Scope, getrennte Dokument- und Betriebswelt, unvollständige Lieferantenintegration sowie unzureichende Wirksamkeitsprüfung. Wer diese Muster adressiert, verbessert nicht nur das Assessment-Ergebnis, sondern die tatsächliche Resilienz.

Roadmap für 30, 60, 90, 180 und 365 Tage

Priorisierung

Priorität erhalten Maßnahmen mit hohem Schutzbedarf, breiter Scope-Wirkung und langer Umsetzungsdauer. Dazu zählen häufig Identitätsmanagement, Netzwerksegmentierung, Lieferantenverträge, Notfalltests und Prototypenschutz. Dokumentation sollte parallel entstehen; sie darf weder die Umsetzung ersetzen noch erst am Projektende beginnen.

TISAX im Vergleich zu ISO 27001 und NIS2

TISAX und ISO 27001 gemeinsam nutzen

Ein gut betriebenes ISO-27001-ISMS liefert Governance, Risikomethodik, Audit, Managementreview und viele Kontrollen. TISAX ergänzt Automotive-spezifische Objectives, Reifegradlogik, Scope- und Austauschmechanismus. Unternehmen sollten kein paralleles „TISAX-System“ aufbauen, sondern Anforderungen in ein gemeinsames Managementsystem integrieren.

TISAX und NIS2

TISAX kann wesentliche organisatorische und technische Grundlagen für NIS2 unterstützen, ersetzt aber keine gesetzliche Betroffenheitsprüfung, Registrierung, Meldepflicht oder Leitungsorganverantwortung. Umgekehrt reicht eine NIS2-Umsetzung nicht automatisch für ein gefordertes TISAX-Ergebnis.

Aufwand, Dauer und Kosten

Kosten entstehen aus Teilnehmergebühren, Prüfdienstleister, internen Ressourcen, externer Unterstützung, technischen Maßnahmen, Reisen und Nachbewertungen. Der größte Kostenblock ist häufig nicht das Assessment, sondern die Schließung struktureller Lücken. Eine seriöse Budgetplanung trennt Pflichtaufwand, nachhaltige Verbesserungen und reine Projekthilfen.

Die Dauer reicht je nach Reife, Scope und Objective von wenigen Monaten bis deutlich über ein Jahr. Ein Unternehmen mit etabliertem ISMS und belastbaren Nachweisen kann schneller sein. Internationale Multi-Site-Scopes mit großen technischen Lücken benötigen einen längeren Vorlauf.

Governance-Modell für CEO, CIO und CISO

Eine wirksame TISAX-Governance trennt strategische Verantwortung, operative Steuerung und Kontrollausführung. Die Geschäftsleitung setzt Schutz- und Geschäftsprioritäten, genehmigt Risiken und Ressourcen. CIO und CISO übersetzen diese Vorgaben in Architektur, Standards, Kontrollen und Messgrößen. Fachbereiche und Standorte betreiben die Prozesse innerhalb ihres Verantwortungsbereichs. Interne Revision oder eine unabhängige zweite Linie prüft, ob Umsetzung und Nachweise belastbar sind.

In kleinen Organisationen können mehrere Rollen bei einer Person liegen. Die Verantwortungen bleiben dennoch unterscheidbar. Wer eine Kontrolle betreibt, sollte ihre Wirksamkeit nicht ausschließlich selbst bewerten. Mindestens bei kritischen Themen wie privilegierten Zugängen, Restore-Fähigkeit, Prototypenschutz und Lieferantenrisiken ist eine unabhängige Prüfung sinnvoll.

Management-Kalender

Ein jährlicher Kontrollkalender verhindert, dass Nachweise erst vor dem Assessment entstehen. Monatlich sollten kritische Ausnahmen, Vorfälle, Schwachstellen und überfällige Maßnahmen betrachtet werden. Quartalsweise eignen sich Risiko-, Lieferanten- und Standortreviews. Mindestens jährlich folgen Managementreview, interne Audits, Wiederherstellungstests, Notfallübungen und eine vollständige Aktualisierung von Scope und Schutzobjekten.

Executive- und Funktionschecklisten

CEO-Checkliste

• Ist schriftlich geklärt, welche Kunden welches Objective und welches Assessment Level erwarten?
• Deckt der Scope alle geschäftlich relevanten Standorte, Prozesse und zentralen Dienste ab?
• Gibt es einen benannten Sponsor mit Entscheidungskompetenz?
• Sind Budget, interne Kapazitäten und Terminrisiken realistisch bewertet?
• Welche fünf Risiken könnten Kundeninformationen oder Marktzugang am stärksten gefährden?
• Wer darf Risiken akzeptieren, und wann muss die Geschäftsleitung entscheiden?
• Werden kritische Lücken, Vorfälle und überfällige Maßnahmen regelmäßig berichtet?
• Ist der dauerhafte Betrieb nach dem Assessment finanziert?

CIO-Checkliste

• Sind alle zentralen und lokalen Systeme, Cloud-Dienste, Schnittstellen und OT-Abhängigkeiten inventarisiert?
• Existieren belastbare Verantwortungsmodelle für SaaS, Hosting, Netzwerke und Anwendungen?
• Werden privilegierte Konten, Service Accounts und externe Zugriffe systematisch gesteuert?
• Sind EOL-Risiken, Patch-Ausnahmen und technische Schulden transparent?
• Wurden Wiederherstellungen aus Backups praktisch getestet?
• Sind Netzwerkzonen, Datenflüsse und Fernzugriffe dokumentiert?
• Liefern Logging und Monitoring verwertbare Alarme und nachvollziehbare Reaktionen?
• Sind zentrale Änderungen, Ausnahmen und Notfallmaßnahmen kontrolliert?

CISO-Checkliste

• Ist die Risikomethodik verständlich, konsistent und im Scope angewendet?
• Sind Controls eindeutig Eigentümern und Nachweisen zugeordnet?
• Gibt es aktuelle Kennzahlen zur Wirksamkeit statt nur Aktivitätszahlen?
• Werden interne Audits risikobasiert und unabhängig durchgeführt?
• Sind Findings mit Ursachenanalyse und Wirksamkeitsprüfung geschlossen?
• Ist die Lieferantensteuerung mit Einkauf und Vertragsmanagement verbunden?
• Werden Scope- oder Geschäftsänderungen in das ISMS übernommen?
• Sind Kundenmeldungen, Sicherheitsvorfälle und Lessons Learned integriert?

Standortleiter-Checkliste

• Sind lokale Verantwortliche, Stellvertretungen und Eskalationswege bekannt?
• Stimmen Zutrittsrechte, Besucherprozesse und physische Zonen mit der Praxis überein?
• Werden externe Mitarbeiter, Reinigung, Wartung und Logistik berücksichtigt?
• Sind lokale IT- und Produktionssysteme vollständig erfasst?
• Werden zentrale Richtlinien in lokaler Sprache verstanden und umgesetzt?
• Existieren Nachweise für Schichtbetrieb, Notfälle und lokale Übungen?

Interviews und Stichproben im Assessment

Prüfer kombinieren Dokumente, Interviews, Beobachtungen und technische Stichproben. Gute Vorbereitung bedeutet nicht, Antworten auswendig zu lernen. Mitarbeitende sollten ihre tatsächlichen Aufgaben, Eskalationen und Kontrollhandlungen erklären können. Widersprüche zwischen Richtlinie und Praxis sind problematischer als eine offen benannte, gesteuerte Abweichung.

Stichproben sollten intern vorab mit realen Fällen getestet werden: ein ausgeschiedener Mitarbeiter, ein kritischer Patch, ein Restore, ein Lieferanten-Onboarding, ein Vorfall, ein privilegierter Zugriff und ein Prototypentransport. Diese Fälle zeigen, ob Prozesse Ende-zu-Ende funktionieren.

Kennzahlen und Wirksamkeitsmessung

Kennzahlen sollen Entscheidungen auslösen. Eine hohe Zahl geschulter Mitarbeiter belegt Aktivität, aber nicht zwingend Wirksamkeit. Aussagekräftiger sind Zielerreichung, Fehlerquote, Reaktionszeit, Abdeckungsgrad und Entwicklung kritischer Ausnahmen.

Ein Dashboard mit zu vielen Kennzahlen verschleiert Prioritäten. Für das Management genügen häufig zehn bis fünfzehn Indikatoren, sofern Schwellenwerte, Trends, Verantwortliche und Eskalationen definiert sind.

Multi-Site- und internationale Organisationen

Internationale Scopes erhöhen die Komplexität deutlich. Zentrale Richtlinien reichen nur dann, wenn lokale Standorte sie verstehen, anwenden und belegen. Unterschiede in Arbeitsrecht, Datenschutz, Gebäuden, Netzwerken, Dienstleistern und Schichtmodellen müssen in die Umsetzung einfließen.

Zentrales Modell

Ein zentrales ISMS kann Methodik, Regelwerk, Risikomodell, Kontrollkalender, Reporting und gemeinsame Dienste bereitstellen. Lokale Standorte verantworten physische Sicherheit, lokale Assets, Benutzer, Lieferanten, Notfallmaßnahmen und gesetzliche Besonderheiten. Diese Trennung muss in einer RACI-Matrix nachvollziehbar sein.

Lokale Readiness

Vor dem externen Assessment sollten Standortreviews stattfinden. Dabei werden Serverräume, Zutritte, Besucher, Prototypenzonen, lokale IT, Schichtbetrieb, Dienstleister und Nachweise geprüft. Interviews in der jeweiligen Arbeitssprache erhöhen die Aussagekraft. Übersetzte Richtlinien sollten fachlich geprüft und nicht nur maschinell übertragen werden.

Zentrale Dienste

ERP, EDI, Active Directory, Cloud-Tenants, Backup, SOC oder zentrale Firewalls wirken oft auf mehrere Standorte. Der Scope muss zeigen, wo diese Dienste betrieben werden, wer sie verantwortet und wie lokale Abhängigkeiten behandelt werden. Eine zentrale Kontrolle kann mehrere Standorte abdecken, wenn ihre Anwendung und Wirksamkeit standortbezogen belegbar sind.

30 typische Projektfehler

1. Der Kundentermin wird übernommen, ohne Scope und Objective zu bestätigen.
2. Das Projekt wird als reine IT-Aufgabe gestartet.
3. Es fehlt ein Sponsor mit Entscheidungskompetenz.
4. Der Scope wird aus Kostengründen künstlich verengt.
5. Zentrale Dienste werden trotz Relevanz ausgeschlossen.
6. Cloud- und SaaS-Dienste fehlen in Inventaren.
7. Die Selbsteinschätzung wird ohne Nachweise bewertet.
8. Reifegrade werden mit Dokumentenexistenz verwechselt.
9. Maßnahmen werden nach einfacher Umsetzbarkeit statt Risiko priorisiert.
10. Richtlinien werden kurz vor dem Assessment erstellt.
11. Lokale Standorte erhalten zentrale Vorgaben ohne Umsetzungshilfe.
12. Verantwortliche kennen ihre Controls nicht.
13. Ausnahmen haben weder Ablaufdatum noch Risikoakzeptanz.
14. Technische Tools werden gekauft, ohne Betriebsprozesse zu definieren.
15. Restore-Tests beschränken sich auf Statusanzeigen der Backupsoftware.
16. Notfallpläne werden nicht praktisch geübt.
17. Privilegierte Konten werden unvollständig inventarisiert.
18. Externe Mitarbeiter fallen aus Joiner-Mover-Leaver-Prozessen heraus.
19. Lieferantenverträge enthalten generische, nicht prüfbare Klauseln.
20. Kritische Unterauftragnehmer bleiben unbekannt.
21. Prototypenschutz endet an der Werkstatttür und ignoriert Transporte.
22. Datenschutzdokumente stimmen nicht mit Systemen und Datenflüssen überein.
23. Interne Audits prüfen nur Dokumente.
24. Findings werden mit Einzelmaßnahmen ohne Ursachenanalyse geschlossen.
25. Das Managementreview ist eine Präsentation ohne Entscheidungen.
26. Kennzahlen messen Aktivität statt Wirksamkeit.
27. Der Prüfdienstleister wird zu spät ausgewählt.
28. Nachbewertungsfristen werden nicht in den Projektplan aufgenommen.
29. Das Ergebnis wird nicht gezielt für Kunden freigegeben.
30. Nach dem Assessment endet das Projektteam, ohne den Regelbetrieb zu übergeben.

Häufige Fragen

Ist TISAX gesetzlich vorgeschrieben?

Nein. TISAX ist kein Gesetz. Kunden, Ausschreibungen oder Verträge können ein geeignetes Ergebnis verlangen.

Ist TISAX eine Zertifizierung?

Fachlich handelt es sich um ein Assessment mit Ergebnis und Labels im ENX-System, nicht um ein ISO-Zertifikat.

Wer betreibt TISAX?

Die ENX Association betreibt das System; der VDA verantwortet den ISA-Katalog.

Wie lange ist ein TISAX-Ergebnis nutzbar?

Die Gültigkeit richtet sich nach den ENX-Regeln und dem konkreten Ergebnis. Geschäftspartner prüfen zusätzlich Scope und Objectives.

Kann ein Ergebnis öffentlich veröffentlicht werden?

Der Austausch erfolgt kontrolliert zwischen TISAX-Teilnehmern. Freigaben werden im ENX-Portal gesteuert.

Braucht jedes Automotive-Unternehmen TISAX?

Nur wenn ein Kunde, Vertrag oder Schutzbedarf dies verlangt oder das Unternehmen den Nachweis strategisch benötigt.

Reicht ISO 27001 statt TISAX?

Nur wenn der anfragende Geschäftspartner dies akzeptiert. Ein ISO-Zertifikat ersetzt ein ausdrücklich gefordertes TISAX-Ergebnis regelmäßig nicht.

Hilft ISO 27001 bei TISAX?

Ja. Ein reifes ISMS liefert viele gemeinsame Grundlagen, ersetzt aber Automotive-spezifische Anforderungen und das TISAX-Verfahren nicht.

Was ist wichtiger: Dokumentation oder Technik?

Beides. Prüfer erwarten definierte Prozesse, wirksame technische und organisatorische Umsetzung sowie belastbare Nachweise.

Welcher Assessment Level ist erforderlich?

Das ergibt sich aus Assessment Objective und Kundenanforderung. Die Auswahl sollte vor Registrierung bestätigt werden.

Kann ein Scope mehrere Standorte enthalten?

Ja. Die zentrale und lokale Umsetzung muss jedoch konsistent, nachvollziehbar und prüfbar sein.

Müssen Homeoffice-Arbeitsplätze berücksichtigt werden?

Wenn dort relevante Informationen verarbeitet werden, gehören Prozesse, Geräte und Zugriffe in die Scope-Betrachtung.

Sind Cloud-Dienste Teil des Scopes?

Wenn sie Schutzobjekte verarbeiten oder kritische Leistungen erbringen, müssen sie berücksichtigt und gesteuert werden.

Brauchen Lieferanten selbst TISAX?

Das hängt von Risiko und Kundenanforderung ab. Ein Label kann verlangt werden, ist aber nicht für jeden Lieferanten zwingend.

Was ist eine Selbsteinschätzung?

Die Organisation bewertet die Umsetzung der VDA-ISA-Anforderungen und belegt ihre Einschätzung mit Nachweisen.

Darf die Selbsteinschätzung optimistisch sein?

Sie sollte evidenzbasiert und realistisch sein. Überbewertungen erhöhen Rückfragen und gefährden Glaubwürdigkeit.

Was passiert bei Abweichungen?

Je nach Schwere sind Korrekturmaßnahmen, Nachweise und gegebenenfalls Nachbewertungen erforderlich.

Kann man den Prüfdienstleister frei wählen?

Ja, aus den zugelassenen TISAX-Prüfdienstleistern. Verfügbarkeit, Erfahrung und Scope-Kompetenz sind wichtige Kriterien.

Wie früh sollte man beginnen?

Bei mittlerer Ausgangsreife mindestens mehrere Monate vor dem Kundentermin; komplexe internationale Scopes benötigen oft deutlich länger.

Wer sollte Projektleiter sein?

Eine Person mit organisatorischer Autorität, Kenntnis des Scopes und Zugang zu Management, IT, Fachbereichen und Standorten.

Ist TISAX nur ein IT-Thema?

Nein. Personal, Einkauf, Recht, Facility, Entwicklung, Produktion, Datenschutz und Management sind regelmäßig beteiligt.

Welche Rolle spielt die Geschäftsleitung?

Sie priorisiert, stellt Ressourcen bereit, akzeptiert Risiken und überprüft die Wirksamkeit des Managementsystems.

Sind Penetrationstests zwingend?

Die Notwendigkeit folgt aus Risiken und Anforderungen. Ein Penetrationstest ersetzt keine grundlegende Governance oder Schwachstellensteuerung.

Müssen Backups nur vorhanden sein?

Nein. Umfang, Schutz, Aufbewahrung, Wiederherstellbarkeit und Tests müssen zum Risiko passen und nachweisbar sein.

Wie wichtig sind interne Audits?

Sie prüfen vor dem externen Assessment, ob Prozesse umgesetzt und wirksam sind. Reine Dokumentenreviews reichen nicht.

Was ist ein gutes Managementreview?

Eine dokumentierte Bewertung von Risiken, Zielen, Vorfällen, Audits, Kennzahlen, Ressourcen und Verbesserungsentscheidungen.

Kann TISAX zentral für eine Gruppe organisiert werden?

Ja, sofern zentrale Prozesse tatsächlich einheitlich betrieben werden und lokale Unterschiede beherrscht werden.

Was ist bei Übernahmen oder Umzügen zu beachten?

Scope, Standorte, Systeme, Verantwortlichkeiten und Ergebnisse müssen auf ihre weitere Gültigkeit geprüft werden.

Kann ein Label automatisch an alle Kunden freigegeben werden?

Freigaben werden kontrolliert gesteuert. Das Unternehmen entscheidet, welchen TISAX-Teilnehmern es Ergebnisse zugänglich macht.

Warum scheitern Projekte trotz vollständigem Katalog?

Weil Dokumente, technische Praxis und Verantwortlichkeiten nicht konsistent sind oder Nachweise keinen stabilen Betrieb zeigen.

Wie bleibt das Ergebnis nachhaltig?

Durch Kontrollkalender, regelmäßige Reviews, interne Audits, Risikoupdates, Schulungen, Nachweismanagement und Managementsteuerung.

Glossar

Verwandte Themen

Primärquellen und redaktioneller Stand