Welche TISAX-Nachweise sich automatisieren lassen und welche nicht

Für einen Entwicklungsdienstleister mit Kunden aus der Automobilindustrie betreuen wir die IT: Active Directory, Microsoft 365, Notebooks und eine Linux-Entwicklungsumgebung. Als die TISAX-Vorbereitung anstand, kam schnell die Frage, wie der Kunde seinen IT-Dienstleister steuert und kontrolliert. Wir haben dafür eine Nachweisliste mit 33 Positionen erstellt. Beim Durchgehen zeigte sich: Ein Teil davon lässt sich aus dem laufenden Betrieb erzeugen, ein anderer Teil bleibt Papier. Hier unsere Einordnung.

Vorweg: TISAX® ist ein Prüfverfahren der ENX Association. Das Assessment führt ein zugelassener Prüfdienstleister durch. Was folgt, betrifft die technische Vorbereitung, nicht die Prüfung selbst.

Automatisierbar: Nachweise, die aus den Systemen kommen

Nachweis	Woher er kommt
Liste der betreuten Systeme mit Eigentümer	NetBox und Ansible-Inventar
Netzwerkdiagramme	aus NetBox erzeugt, statt von Hand gezeichnet
Änderungen mit Freigabe	Merge Request, Pipeline-Protokoll und Ticket sind miteinander verknüpft
Schwachstellen je System	Wazuh gleicht das Softwareinventar mit bekannten CVEs ab
Härtungsstand	Wazuh prüft die Konfiguration gegen CIS-orientierte Richtlinien
Status der Sicherungen	Backup-Monitoring mit Alarm bei Fehlern

Bei diesen Nachweisen muss vor dem Audit niemand etwas zusammensuchen. Sie entstehen bei jeder Änderung oder jedem Prüflauf neu, mit Datum.

Teilweise automatisierbar: Daten automatisch, Bewertung von Hand

Nachweis	Was automatisch geht	Was Handarbeit bleibt
Liste privilegierter Konten	Export aus Active Directory, Entra ID, GitLab und Proxmox	Zuordnung zu Person und Zweck prüfen
Berechtigungsreview	Vergleich mit dem letzten Stand	Entscheidung, was wegfällt, und Abzeichnung
MFA-Nachweis	Export der Richtlinien und des Registrierungsberichts	Ausnahmen begründen
Offboarding	SSH-Schlüssel werden per Ansible zentral verwaltet und beim Austritt entfernt	Checkliste für Konten außerhalb des Codes
Restore-Test	Protokollvorlage, technische Werte aus dem Test	Test durchführen, Ergebnis bewerten
Patchstand	Update-Läufe aus den Pipelines mit Datum	Ausnahmen begründen, wenn ein System kein Update verträgt

Hier spart Automatisierung die Sammelarbeit, ersetzt aber nicht die Entscheidung. Ein Berechtigungsreview, bei dem niemand hinschaut, ist kein Review, auch wenn die Liste automatisch entsteht.

Handarbeit: Nachweise, die organisatorisch bleiben

• Dienstleistungsvertrag, SLA und Informationssicherheitsvereinbarung
• Vertraulichkeitsverpflichtungen der Mitarbeitenden
• Schulungsnachweise
• Bewertung der Subdienstleister
• Notfallplan und Break-Glass-Konten mit Testprotokoll
• Risikobewertung und deren Freigabe

Diese Punkte lassen sich strukturieren, versionieren und mit Erinnerungen versehen. Automatisch erzeugen lassen sie sich nicht. Wer verspricht, TISAX „auf Knopfdruck“ zu liefern, übergeht genau diesen Teil.

Was wir dabei gelernt haben

Jede Aussage braucht eine Quelle oder eine Markierung. Im Dienstleisterpaket steht bei jeder Maßnahme, ob sie umgesetzt und belegt, geplant oder noch zu prüfen ist, und bei umgesetzten Maßnahmen die Quelle: eine Datei im Repository, ein Protokoll, eine Konfiguration. So wird sichtbar, was wirklich fehlt.

Eine erkannte Lücke ist besser als eine beschönigte. Auditoren bewerten eine offen benannte Lücke mit Maßnahme und Termin besser als eine Antwort, die bei der ersten Nachfrage nicht hält. Deshalb gehört zu jeder offenen Position ein Eintrag im Maßnahmenplan.

Der Dienstleister muss mitliefern. Viele Fragen im Assessment zielen nicht auf die IT des Kunden selbst, sondern darauf, wie er seinen IT-Dienstleister bewertet, vertraglich bindet und kontrolliert. Ohne Unterlagen vom Dienstleister kann der Kunde diese Fragen nicht beantworten.

Code hilft, wenn er schon da ist. Weil die Konfiguration der Server bei diesem Kunden bereits in Ansible und Git lag, waren Änderungshistorie, Soll-Zustand und Zugänge belegbar, ohne dass wir sie nachträglich dokumentieren mussten. Wer erst vor dem Audit anfängt, alles als Code abzubilden, schafft das selten rechtzeitig.

---

Wenn bei Ihnen ein TISAX-Assessment ansteht: Unter TISAX-Vorbereitung beschreiben wir, wie wir den technischen Teil angehen. Für die Nachweise zu Schwachstellen und Härtung setzen wir Wazuh ein, für Änderungshistorie und Soll-Zustand Infrastructure as Code.