Das Problem
Vor dem Assessment beginnt oft die Sammelarbeit: Screenshots von Firewall-Regeln, Excel-Listen mit Admin-Konten, ein Backup-Konzept von vor drei Jahren. Bis zum Audit ist die Hälfte davon veraltet. Und wenn der Auditor fragt, wer eine Änderung freigegeben hat, sucht jemand in alten E-Mails.
Hinzu kommt: Wer einen externen IT-Dienstleister hat, muss auch dessen Arbeit steuern und belegen können. Auditoren fragen gezielt danach, wie der Dienstleister bewertet, vertraglich gebunden und kontrolliert wird.
Unser Ansatz: Compliance as Code
Was sich technisch prüfen lässt, prüfen wir technisch – regelmäßig und automatisch. Konfigurationen liegen in Git, jede Änderung hat einen Merge Request mit Freigabe und Pipeline-Protokoll. Inventar, Schwachstellen und Härtungsstand kommen aus den Systemen selbst. So entsteht ein Nachweis nicht einmal vor dem Audit, sondern bei jeder Änderung neu.
Was sich nicht automatisieren lässt, bleibt sichtbar offen: Richtlinien, Schulungen, Verträge. Diese Punkte strukturieren wir mit Ihnen, statt sie hinter einem Dashboard zu verstecken.
Aus der Praxis: TISAX aus Sicht des IT-Dienstleisters
Für einen Entwicklungsdienstleister mit Kunden aus der Automobilindustrie betreiben wir Active Directory, Microsoft 365, die Windows-Notebooks und eine Linux-Entwicklungsumgebung. Für dessen TISAX-Vorbereitung haben wir ein Dienstleisterpaket erarbeitet:
- Risikobewertung mit 20 Einzelrisiken – von kompromittierten Admin-Konten bis zu fehlender Protokollierung
- Service Level Agreement und eigenes SLA für Sicherheitsvorfälle
- Informationssicherheitsvereinbarung und RACI-Matrix
- Backup- und Restore-Konzept sowie Notfallplan mit Wiederanlauf-Reihenfolge
- Verfahren für Subdienstleister
- Nachweisliste mit 33 Positionen, Auditfragen mit Musterantworten und Maßnahmenplan
Jede Aussage darin ist entweder mit einer Quelle belegt – einer Datei im Repository, einem Protokoll, einer Konfiguration – oder als offen markiert. Auditoren bewerten eine erkannte und eingeplante Lücke besser als eine beschönigte.
Welche Nachweise sich automatisieren lassen
| Bereich | Nachweis aus dem Betrieb | Werkzeug |
|---|---|---|
| Inventar | Liste der Server, VMs und Netzkomponenten mit Eigentümer | NetBox, Ansible-Inventar |
| Änderungen | Merge Request mit Freigabe, Pipeline-Protokoll, Ticket | GitLab, Ticketsystem |
| Härtung | Prüfergebnisse gegen CIS-orientierte Richtlinien je System | Wazuh |
| Schwachstellen | bekannte CVEs je System mit Datum des Funds | Wazuh |
| Backup | Status der Sicherungen, Protokolle der Restore-Tests | Proxmox Backup Server, Protokollvorlage |
| Überwachung | überwachte Systeme, Alarmregeln, Beispiel-Alarm | Monitoring |
| Konfiguration | Soll-Zustand der Server als Code, reproduzierbar | Terraform, Ansible |
Was Handarbeit bleibt
- Richtlinien und Leitlinien des Informationssicherheitsmanagements
- Risikobewertung, Freigaben und Management-Reviews
- Schulungen und Vertraulichkeitsverpflichtungen der Mitarbeitenden
- Verträge mit Dienstleistern und deren Bewertung
- Physische Sicherheit von Gebäuden und Räumen
Ein TISAX-Assessment lässt sich nicht vollständig automatisieren. Ein Dashboard ersetzt kein Informationssicherheitsmanagement – es macht den technischen Teil davon belegbar.
Die Nachweiskette
Jeder Nachweis lässt sich so zurückverfolgen: Welche Anforderung, welches System, wer ist zuständig, wann wurde zuletzt geprüft, und wo liegt der Beleg.
So gehen wir vor
- Scope klären – Standorte, Systeme, Assessment-Level und Schutzbedarf. Wir arbeiten mit dem Katalog, der bei Projektbeginn gilt.
- Bestandsaufnahme – Welche Nachweise gibt es schon, welche fehlen, welche sind veraltet?
- Technische Lücken schließen – Härtung, Berechtigungen, Logging, Backup und Restore-Test.
- Nachweise automatisieren – Prüfungen laufen regelmäßig, Ergebnisse werden mit Datum abgelegt.
- Dienstleister einbinden – Risikobewertung, SLA, Sicherheitsvereinbarung und RACI, wenn wir Ihr IT-Dienstleister sind oder mit Ihrem Dienstleister zusammenarbeiten.
- Audit vorbereiten – Nachweisliste, Musterantworten und Maßnahmenplan für offene Punkte.
Leistungsumfang
- Bestandsaufnahme der technischen Anforderungen
- Härtung und Konfiguration als Code
- Schwachstellen- und Härtungsprüfung mit Wazuh
- Inventar in NetBox
- Backup- und Restore-Konzept mit Testprotokoll
- Dienstleisterpaket
- Nachweisliste und Auditvorbereitung
Technischer Einblick
Die Konfiguration der Server liegt als Ansible-Rollen und Terraform-Module in GitLab. Änderungen laufen über Merge Requests, die Pipeline protokolliert jeden Rollout. Zugangsdaten liegen verschlüsselt in Ansible Vault bzw. einem Passwort-Tresor, nie im Klartext im Repository. Wazuh prüft die Systeme alle zwölf Stunden gegen Härtungsrichtlinien und gleicht das Softwareinventar mit bekannten Schwachstellen ab. NetBox ist die Quelle für das Inventar und für die Zuordnung der Systeme zu Kunde und Standort.
Welche Nachweise sich aus unserer Erfahrung automatisieren lassen, beschreiben wir ausführlich im Beitrag über automatisierbare TISAX-Nachweise.
TISAX® ist eine eingetragene Marke der ENX Association. Wir sind kein TISAX-Prüfdienstleister und führen keine Assessments durch.
Warum cloudbase.run
- Wir haben ein TISAX-Dienstleisterpaket für einen Kunden selbst erarbeitet – aus Sicht des Dienstleisters, der dem Auditor Rede und Antwort stehen muss.
- Unsere eigene Infrastruktur betreiben wir so, wie wir es empfehlen: als Code, mit Wazuh, NetBox und protokollierten Restore-Tests.
- Wir trennen klar zwischen technischer Umsetzung und dem, was organisatorisch bei Ihnen bleibt.
Für wen geeignet
- Zulieferer und Entwicklungsdienstleister, deren Kunden ein TISAX-Label verlangen
- Unternehmen, die einen externen IT-Dienstleister haben und dessen Steuerung belegen müssen
- IT-Teams, die Nachweise nicht jedes Jahr neu von Hand zusammentragen wollen
Für wen nicht geeignet
- Wer einen Prüfdienstleister für das Assessment sucht – das sind wir nicht
- Wer ausschließlich organisatorische ISMS-Beratung ohne technischen Anteil braucht
- Wer ein Label ohne eigene Mitarbeit erwartet