Unabhängiges IT-Infrastruktur-Audit: was es in sechs Domänen prüft und was es findet

Was ein IT-Infrastruktur-Audit umfasst

Ein unabhängiges IT-Infrastruktur-Audit, auch Infrastrukturanalyse oder Infrastructure Assessment genannt, erfasst, was ein Unternehmen betreibt, vergleicht es mit der tatsächlichen Nutzung der Systeme und ordnet die gefundenen Lücken nach Risiko. Unser Audit betrachtet sechs Domänen: Compute und Virtualisierung, Storage und Backup, Netzwerke, Security und Zugriffe, Lizenzen und Verträge sowie Compliance, die optional ist und separat beauftragt wird. Am Ende stehen vier Dokumente: eine Inventur, eine priorisierte Risikokarte, ein ROI-/TCO-Finanzmodell und eine Roadmap. Gearbeitet wird mit den Unterlagen und Exporten, die Sie bereitstellen, und mit Interviews mit Ihrem Team, ohne Zugriff auf Ihre Produktivsysteme und ohne Änderungen daran.

Das Wort unabhängig hat hier eine konkrete Bedeutung. Das Audit wird unabhängig von jedem Folgekauf kalkuliert und geliefert, als eigenständiges Produkt. Sein Finanzmodell vergleicht Szenarien verschiedener Hersteller in Geld und stellt die Option, nichts zu ändern, daneben. Die Roadmap gehört Ihnen: Umsetzen können Sie sie mit uns, allein oder mit einem anderen Dienstleister.

IT-Audit-Checkliste nach Domänen, mit je einem Beispielbefund

Die Spalte „Was geprüft wird“ folgt der Umfangstabelle unserer Seite Infrastruktur-Audit & Strategie (Stand der Website vom 12. November 2026); die Befunde sind allgemeine Beispiele, hinter denen keine Statistik steht.

Der Umfang wird im Vertrag festgelegt, mit allen sechs Domänen oder nur einem Teil davon. Die dritte Spalte nennt Beispiele für die Art von Befund, die ein Audit zeigen kann. Es sind allgemein gehaltene Illustrationen; Zahlen dazu, wie häufig ein Befund vorkommt, veröffentlichen wir nicht.

Unser Audit deckt diese Domänen ab, Umfang und Preis werden vor dem Start schriftlich festgelegt; nennen Sie uns die Domänen, die geprüft werden sollen, und die Zahl der Standorte und Hosts, unsere Antwort erhalten Sie innerhalb eines Werktages.

Compute, Storage und Backup, gemessen an dem, was gekauft wurde

Bei Compute und Virtualisierung vergleicht das Audit, was gekauft und zugeteilt wurde, mit dem, was genutzt wird: Server, Hypervisoren, Cluster und ihre tatsächliche Ressourcennutzung, um zu sehen, wo Überschuss ist und wo Mangel. Es kann Hosts zeigen, die für eine Last ausgelegt wurden, die inzwischen geschrumpft oder abgewandert ist, und virtuelle Maschinen mit weit mehr Prozessoren und Arbeitsspeicher, als sie nutzen. Es kann auch das Gegenteil zeigen: einen Cluster, der so voll ist, dass die übrigen Hosts die Last eines ausgefallenen Hosts nicht übernehmen könnten. Auch die Versionsliste gehört hierher, weil jedes Release ein Supportende hat. Broadcoms KB 459135, gelesen am 12. November 2026, nennt zum Beispiel den 11. Oktober 2027 als Ende des allgemeinen Supports für vSphere 8.

Für eine vSphere-Umgebung stehen die einzelnen Prüfungen in unseren Artikeln dazu, was ein VMware Health Check prüft, und zum Rightsizing zu großer VMs. Ein Health Check bleibt innerhalb einer Plattform und vergleicht sie mit den Regeln ihres Herstellers. Das Audit geht über die Domänen hinweg und endet in einem Finanzmodell und einer Roadmap.

Bei Storage und Backup fragt das Audit, ob sich die Kopien wiederherstellen lassen und ob sie so lange aufbewahrt werden, wie die Eigentümer der Daten es erwarten. Typischerweise prüft es, welche Systeme in einem Backup-Job enthalten sind, wann die Wiederherstellung jedes kritischen Systems zuletzt getestet wurde und wie lange sie gedauert hat. Ein Befund, den es zeigen kann: eine lange Reihe fehlerfreier Job-Berichte und daneben kein Nachweis, dass die größte Datenbank je wiederhergestellt wurde. Zwei öffentliche Dokumente fassen die Erwartung in Worte. CIS Control 11, „Data Recovery“, spricht von dem, was ausreicht, um die Unternehmens-Assets im Geltungsbereich in einen vertrauenswürdigen Zustand vor dem Vorfall zurückzuversetzen („sufficient to restore in-scope enterprise assets to a pre-incident and trusted state“). Das Cybersecurity Framework 2.0 des NIST enthält die Subkategorie PR.DS-11: „Backups of data are created, protected, maintained, and tested“. Warum ein abgeschlossener Job wenig über die Wiederanlaufzeit sagt, behandelt unser Artikel Backup ist kein Disaster Recovery; was sich beim Backup von vSphere-Umgebungen geändert hat, steht in VMware-Backup nach Broadcom.

Single Points of Failure in Netzwerk, Zugriffen und Protokollierung

Bei den Netzwerken liest das Audit Topologie, Segmentierung, Durchsatz, Engpässe und Ausfallsicherheit aus Plänen, Konfigurationsexporten und den Interviews. Ein Befund, den es zeigen kann, ist ein Single Point of Failure: ein Core-Switch, eine Firewall oder ein Uplink, von dem mehrere Systeme abhängen und für den es keinen zweiten Weg gibt. Ein anderer ist ein Netz ohne Segmentierung, in dem jeder Server jeden anderen erreicht. Unser Leitfaden zur Netzwerk­segmentierung beschreibt die Zonen, mit denen ein mittelständisches Unternehmen beginnt.

Security und Zugriffe umfasst privilegierte Zugriffe, MFA, Perimeterschutz und Ereignisprotokollierung. Hier kann ein Audit Administratorkonten zeigen, die sich mehrere Personen teilen, Dienstkonten mit mehr Rechten, als ihre Aufgabe braucht, Fernzugänge, die mit einem Passwort allein funktionieren, oder Protokolle, die nur auf dem System liegen, das sie geschrieben hat. Das Audit arbeitet ohne Zugriff auf Produktivsysteme; dieser Teil ist deshalb eine Prüfung von Konfiguration und Praxis anhand von Exporten und Interviews. Ein Penetrationstest ist eine eigene Arbeit. Die Maßnahmen hinter solchen Befunden beschreiben unsere Leitfäden zu Privileged Access Management und Phishing-resistenter MFA.

Lizenzen, Verträge und die optionale Compliance-Analyse

Lizenzen und Verträge werden als Editionen und Subscriptions, Renewal-Termine und Abgleich mit der tatsächlichen Nutzung geprüft. Ein Audit kann eine Edition zeigen, die für Funktionen bezahlt wird, die kein Cluster nutzt, eine lizenzierte Menge, die von der Hardware in den Racks abweicht, oder einen Verlängerungstermin, den nur eine Person kennt. Die Lizenzmetrik bestimmt, wie verglichen wird. Broadcoms KB 313548 setzt für VMware zum Beispiel ein Minimum von 16 lizenzierten Kernen je CPU, sodass ein Prozessor mit weniger Kernen trotzdem als 16 zählt. Eine solche Inventur ist etwas anderes als die Lizenzprüfung eines Herstellers, die sich aus dem Vertrag ergibt; was Broadcoms Vertrag dafür vorsieht, steht in unserem Artikel zum VMware-Lizenzaudit von Broadcom.

Die Compliance-Analyse gehört nicht zum Standardumfang. Wenn Sie sie bestellen, wird sie separat beauftragt und zeigt die Lücke zwischen dem Ist-Zustand und NIS2, Branchenstandards oder den Anforderungen von Versicherern und Kunden, als Liste der Lücken mit Prioritäten zum Schließen. Das Ergebnis ist eine technische Information. Die rechtliche Auslegung einer Richtlinie und ihrer nationalen Umsetzung bleibt bei Ihrer Rechtsberatung. Die Maßnahmen, die NIS2 aufzählt, fasst unsere Checkliste zu NIS2 Artikel 21 zusammen.

Was die Interviews den Exporten hinzufügen

Exporte zeigen, was konfiguriert ist; die Gründe stehen nicht darin. Wo Systeme über Jahre von verschiedenen Leuten gebaut wurden, fehlt mitunter die Dokumentation, und Abhängigkeiten sind unbekannt. Die Interviews bringen zutage, was in keiner Datei steht: einen geplanten Job auf einem Server, der abgeschaltet werden soll, eine Anwendung, die stehen bleibt, wenn ein vergessener Lizenzserver offline ist, eine Firewall-Regel, deren Verfasser das Unternehmen verlassen hat. Jede solche Abhängigkeit wird ein Eintrag der Inventur, zusammen mit den Systemen, die sie verbindet. Die Interviews richten sich nach dem Kalender Ihres Teams.

Öffentliche Rahmenwerke für dasselbe Feld

Unsere Serviceseite nennt kein Rahmenwerk, und für die Beauftragung eines Audits ist keines nötig. Öffentliche Rahmenwerke helfen aus einem anderen Grund: Ein Befund, der sich an einer veröffentlichten Anforderung messen lässt, ist gegenüber Geschäftsleitung, Versicherer oder Kunden leichter zu erklären. Die Tabelle gibt wieder, was die Dokumente selbst sagen, gelesen am 12. November 2026.

Liste der CIS Controls (v8.1); NIST CSWP 29, „The NIST Cybersecurity Framework (CSF) 2.0“; ISO-Seite zu ISO/IEC 27001 und Katalogeintrag der Norm; COBIT-Seite der ISACA; ITIL-Zertifizierungsseite von PeopleCert; BSI-Standard 200-2 „IT-Grundschutz-Methodik“ (15. November 2017) und Online-Kurs IT-Grundschutz des BSI; alle gelesen am 12. November 2026.

Drei dieser Dokumente beginnen dort, wo ein Audit beginnt: bei der Kenntnis des Bestands. Die CIS Controls beginnen mit zwei Controls zur Inventarisierung. Die NIST-Kategorie zum Asset Management verlangt, dass Inventare von Hardware sowie von Software, Diensten und Systemen gepflegt werden („are maintained“). Die Lektion zur Strukturanalyse im Kurs des BSI nennt unter anderem die Teilschritte „Anwendungen erheben“, „Netzplan erheben“, „IT-Systeme erheben“ und „Räume erheben“. Deshalb ist das erste Dokument eines Audits die Inventur.

ISO/IEC 27001 ist eine Norm für ein Managementsystem. ISO hält fest, dass eine Zertifizierung nach ISO/IEC 27001 möglich, aber nicht verpflichtend ist („certification to ISO/IEC 27001 is possible but not obligatory“) und dass ISO selbst nicht zertifiziert („ISO does not perform certification“). Ein Infrastruktur-Audit, wie es hier beschrieben ist, endet mit den vier Dokumenten weiter unten und stellt kein Zertifikat aus.

Wie Befunde nach Risiko und Aufwand geordnet werden

Die Risikokarte trennt, was kritisch ist, von dem, was warten kann, und jede Komponente der Inventur trägt eine Zustands- und Risikobewertung. Zwei Fragen ordnen die Befunde. Die erste betrifft das Risiko: was steht, wenn aus dem Befund ein Ereignis wird, wie lange die Wiederherstellung dauern würde und wie plausibel der Auslöser ist. Die zweite betrifft den Aufwand: ob die Korrektur eine Einstellung ist, eine Beschaffung oder ein Projekt mit Abhängigkeiten. Die Tabelle zeigt die Logik an fiktiven Beispielen.

unsere Darstellung der Ordnungslogik; die Beispiele sind fiktiv und stammen nicht von einem Kunden.

Befunde mit hohem Risiko und kleiner Korrektur kommen zuerst, weil sie mit dem geringsten Aufwand das meiste Risiko beseitigen. Große Korrekturen gehen als Schritte mit Etappen, Abhängigkeiten und Budgetschätzung in die Roadmap. Zur Bewertung gehört auch die Frage, wo die Infrastruktur das Geschäft bereits bremst und was zuerst brechen würde.

Die vier Dokumente am Ende eines Audits

• Inventur. Das vollständige Bild von Infrastruktur, Lizenzen und Zugriffen: Server, Virtualisierung, Storage, Netzwerke, Lizenzen, Backup und Zugriffe, jede Komponente mit Zustands- und Risikobewertung.
• Risikokarte. Die Befunde nach Priorität: was kritisch ist und was warten kann.
• ROI-/TCO-Finanzmodell. Die Szenarien Modernisierung, Cloud und Hybrid, in Geld verglichen über 3 bis 5 Jahre, daneben die Option, nichts zu ändern. Es ist für die Entscheidung auf Vorstandsebene geschrieben.
• Roadmap. Eine Abfolge von Schritten mit Etappen, Abhängigkeiten und Budgetschätzung.

Eine Compliance-Analyse kommt hinzu, wenn sie beauftragt wurde. Wir präsentieren die Ergebnisse und vertreten die Schlussfolgerungen vor Ihrem Management. Wie aus Modell und Roadmap ein Budgetantrag wird, behandelt unser Schwesterartikel IT-Infrastruktur prüfen vor der Budgetplanung. Wo ein Szenario Server in ein externes Rechenzentrum stellt, wird das Gebäude Teil des Vergleichs: Was eine Einstufung aussagt, erklärt unser Artikel zum Tier-3-Rechenzentrum, und die Fragen an den Betreiber stehen in der Colocation-Checkliste für GPU-Server.

Diese vier Dokumente liefern wir für die Domänen, die Sie wählen; schicken Sie uns eine kurze Beschreibung Ihrer Umgebung und der Entscheidung, die Sie vorbereiten müssen, und wir schlagen vor, welche Domänen in den Umfang gehören.

Wie das Audit ohne Zugriff auf Produktivsysteme abläuft

Das Audit hat drei Schritte. Der erste ist ein kostenloses Gespräch, in dem Aufgabe, Umfang und Erwartungen geklärt werden; danach werden Umfang und Preis vor dem Start schriftlich festgelegt. Der zweite ist das Audit selbst. Es arbeitet mit den Informationen, die Sie bereitstellen, und mit Interviews. Zugriff auf Ihre Produktivsysteme ist nicht nötig, an den Systemen wird nichts verändert, und Kopien von Produktivdaten werden nicht mitgenommen. Vor technischen Details wird ein NDA unterzeichnet, einen Auftrags­verarbeitungs­vertrag gibt es auf Anfrage, und Subauftragsverarbeiter stehen namentlich im Vertrag. Der dritte Schritt ist die Präsentation des Berichts mit Risikokarte, Finanzmodell und Roadmap.

Typische Unterlagen, als Beispiele:

• ein Export der Hosts, Cluster und virtuellen Maschinen mit ihren Versionen, dazu die Leistungshistorie, soweit sie aufbewahrt wird
• Berichte der Backup-Jobs und vorhandene Nachweise über Restore-Tests
• Netzpläne und Exporte der Switch- und Firewall-Konfiguration
• eine Liste der privilegierten Konten und der Stellen, an denen MFA erzwungen wird
• Verträge, Subscription-Laufzeiten und Verlängerungstermine
• vorhandene Dokumentation, gleich welchen Alters

Welche Unterlagen gebraucht werden, ergibt sich aus dem Umfang. Der erste Schritt ist eine Nachricht über das Formular unten oder an request@eurokommerz.at.

Wann eine engere Prüfung das bessere Mittel ist

Ein Audit über sechs Domänen ist mehr, als manche Frage braucht. Geht es nur um die Konfiguration einer vSphere-Umgebung, beantwortet ein Health Check dieser Plattform die Frage. Steht ein einzelnes Wiederanlaufszenario in Zweifel, kann das Team es an einem Tisch durchspielen, mit unserem Ablaufplan für eine Tabletop-Übung für IT-Ausfälle.

Außerdem gibt es zwei Fälle, in denen ein Audit von uns der falsche Auftrag ist. Einen Bericht, der nur pro forma gebraucht wird, ohne echte Bewertung, erstellen wir nicht. Und wo die Entscheidung bereits gefallen ist und das Audit sie nur bestätigen soll, kann eine unabhängige Bewertung anders ausfallen.

FAQ