IT-PLANUNG · DOKUMENTATION
Ein brauchbares IT-Inventar beantwortet nicht nur, welche Geräte vorhanden sind. Es zeigt, welcher Geschäftsablauf von welchem Dienst abhängt, wer darüber verfügen kann und was zuerst wiederhergestellt werden muss.
Gerätelisten aus der Buchhaltung, Passwortsammlungen und Netzpläne lösen jeweils nur einen Teil der Aufgabe. Für eine Störung, einen Anbieterwechsel oder die Vertretung eines Administrators müssen Hardware, Software, Cloudkonten, Verträge, Daten, Identitäten, Netzwerkwege und Zuständigkeiten miteinander verbunden sein.
Dieser Leitfaden beschreibt ein Inventar, das ein kleines Unternehmen mit vertretbarem Aufwand selbst besitzen und aktuell halten kann. Die enthaltenen Tabellen lassen sich direkt in eine geschützte Tabellenkalkulation, Datenbank oder Dokumentationsplattform übertragen. Für besonders vertrauliche Zugangsdaten bleibt ein getrennt geschützter Passwortmanager vorgesehen.
Kapitelübersicht
UmfangInventarfelderErhebungAbhängigkeitenPrioritätenZugängePflegeNotfallpaket
1. Das Inventar bildet den betriebsfähigen Zusammenhang ab
Ein Notebook ist ein Vermögensgegenstand. Arbeitsfähig wird es erst mit Benutzerkonto, Betriebssystem, Anwendungen, Lizenz, Netzwerk, Datenzugriff und Wiederherstellungsweg. Genau diese Beziehungen muss die Dokumentation sichtbar machen.
| Bestandsart | Beispiele | Entscheidender Nutzen |
|---|---|---|
| Hardware | Notebook, PC, Server, NAS, Router, Switch, Access Point, Mobiltelefon, USV | Standort, Eigentum, Zustand, Garantie und Ersatzweg kennen |
| Software | Betriebssystem, Office, Fachanwendung, Browsererweiterung, Treiber | Version, Lizenz, Support und Abhängigkeiten beherrschen |
| Cloud- und externe Dienste | Microsoft 365, Buchhaltung, CRM, Webhosting, Backup, DNS | Vertragsinhaber, Administratoren, Daten und Exitweg kennen |
| Identitäten | Benutzer, Gruppen, Admin-, Notfall- und Dienstkonten | Zugriff, Verantwortung und Vertretung nachvollziehen |
| Datenbestände | Mandant, Teamablage, Datenbank, Archiv, lokale Dateien | Eigentümer, Schutzbedarf, Aufbewahrung und Backup zuordnen |
| Netzwerk | Anschlüsse, VLANs, IP-Bereiche, WLANs, VPN, Firewallregeln | Erreichbarkeit, Trennung und Fehlerpfade verstehen |
| Verträge und Lizenzen | Provider, Domain, SaaS, Hardwarewartung, Leasing | Kündigung, Verlängerung, Kosten und Supportzugang sichern |
| Geschäftsprozesse | Angebot, Auftrag, Buchung, Zahlung, Kommunikation, Archivierung | Technik nach geschäftlicher Auswirkung priorisieren |
Inventarliste, Konfigurationsdokumentation und Zugangsspeicher trennen
| Ebene | Inhalt | Nicht dort ablegen |
|---|---|---|
| Inventar | Eindeutige ID, Bezeichnung, Zweck, Eigentümer, Standort, Status, Abhängigkeiten | Passwörter oder private Wiederherstellungscodes |
| Technische Dokumentation | Konfiguration, Netzwerkplan, Betriebs- und Wiederanlaufverfahren | Unverschlüsselte Geheimnisse oder beliebige Rohprotokolle |
| Passwortmanager | Kennwörter, Wiederherstellungscodes, API-Schlüssel, sichere Notizen | Alleinige Erklärung, wofür ein Konto oder Schlüssel verwendet wird |
Im Inventar steht beispielsweise „M365-ADM-02 – zweites Notfallkonto – Tresoreintrag 147“. Das Kennwort selbst liegt im Passwortmanager. Dadurch bleibt die Inventarliste lesbar, ohne zur offenen Schlüsselsammlung zu werden. Umgekehrt verhindert die Inventar-ID, dass ein isolierter Tresoreintrag ohne verständlichen Zweck zurückbleibt.
Woran man ein brauchbares Inventar erkennt
- Jedes Objekt besitzt eine eindeutige, dauerhaft verwendete Kennung.
- Geschäftlicher Zweck und verantwortliche Person sind benannt.
- Status und letzte Prüfung sind sichtbar.
- Verknüpfte Dienste, Daten und Zugänge sind auffindbar.
- Ein ausgemustertes Objekt bleibt mit Abschlussdatum nachvollziehbar.
- Eine Vertretung kann das Inventar unabhängig von einer einzelnen Person erreichen.
2. Einheitliche Felder machen unterschiedliche Bestände vergleichbar
Eine Inventarzeile soll eine Entscheidung ermöglichen. Seriennummer und Kaufpreis reichen dafür ebenso wenig wie ein freies Textfeld mit „Server im Büro“.
| Feld | Beispiel | Regel |
|---|---|---|
| Inventar-ID | NB-023 oder SaaS-014 | Eindeutig, kurz und nach Austausch nicht wiederverwenden |
| Bezeichnung | Notebook Buchhaltung 2 | Für Menschen verständlich, nicht nur Herstellername |
| Objektart | Notebook, Dienst, Konto, Datenbestand | Aus kontrollierter Auswahlliste |
| Geschäftlicher Zweck | Zahlungslauf und Belegprüfung | Konkreter Arbeitsvorgang statt „allgemeine Nutzung“ |
| Eigentümer | Leitung Finanzen | Fachlich entscheidende Rolle |
| Technische Verantwortung | Interne Person oder beauftragter Dienstleister | Mit Vertretung und Kontaktweg |
| Standort | Büro 2. OG, Homeoffice oder Rechenzentrum | Physisch oder logisch eindeutig |
| Status | geplant, produktiv, Reserve, gesperrt, ausgemustert | Aus kontrollierter Auswahlliste |
| Kritikalität | A, B oder C nach eigener Definition | Auswirkung und tolerierbare Unterbrechung dokumentieren |
| Abhängigkeiten | ID-004, NET-002, SaaS-014 | Über Inventar-IDs statt freien Text verknüpfen |
| Lebenszyklus | Kauf, Garantieende, Supportende, Zielersatz | Termine mit Quelle und Prüfrhythmus |
| Dokumente/Zugang | Link zur Anleitung und Tresoreintrag | Keine Geheimnisse im offenen Feld |
| Letzte Prüfung | 2026-09-11, TM | Datum plus verantwortliche Person |
Zusatzfelder je Objektart
| Objektart | Zusatzfelder |
|---|---|
| Hardware | Hersteller, Modell, Seriennummer, CPU, RAM, Speicher, MAC-Adresse, Kaufdatum, Garantie, Lieferant, Verschlüsselung |
| Software | Produkt, Edition, Version, Installationsart, Lizenzmodell, Lizenzinhaber, Supportende, betroffene Geräte, Updateweg |
| SaaS/Cloud | Mandantenname, Anmeldeadresse, Vertragsinhaber, Abrechnungskonto, Administratoren, MFA, Datenregion, Export- und Kündigungsweg |
| Identität | Kontotyp, Zweck, Rollen, MFA-Methode, Eigentümer, Vertretung, Lebenszyklus, verknüpfter Tresoreintrag |
| Datenbestand | Inhalt, Eigentümer, Schutzbedarf, führende Ablage, Volumen, Wachstum, Aufbewahrung, Backup, RPO, RTO |
| Netzkomponente | Management-IP, VLAN, Ports, Firmware, Konfigurationsbackup, Standort, Uplink, Stromversorgung |
| Vertrag | Anbieter, Kundennummer, Leistung, Laufzeit, Kündigungsfrist, Preislogik, Supportkanal, zugehörige Assets |
Kontrollierte Werte statt Schreibvarianten
Begriffe wie „aktiv“, „in Betrieb“, „produktiv“ und „läuft“ dürfen nicht dasselbe meinen. Für Status, Objektart, Standort, Kritikalität und Schutzbedarf werden feste Werte mit kurzer Definition verwendet. Freitext bleibt für Erläuterungen. Das ermöglicht Filter wie „alle produktiven SaaS-Dienste ohne benannte Vertretung“ oder „alle Geräte mit Supportende in den nächsten zwölf Monaten“.
- Produktiv: für einen laufenden Geschäftsprozess freigegeben
- Reserve: einsatzfähig vorbereitet, aber nicht regulär genutzt
- Gesperrt: absichtlich nicht nutzbar, Aufbewahrung noch nicht beendet
- Ausgemustert: Nutzung beendet, Daten und Zugänge nachweislich behandelt
- Ungeklärt: gefunden, aber Zweck oder Eigentümer noch offen; mit Frist zur Klärung
3. Die Erhebung verbindet technische Funde mit dem Wissen der Beschäftigten
Kein einzelnes Werkzeug findet alles. Netzwerkscans erkennen kein privates SaaS-Abonnement, Lizenzportale keinen ausgeschalteten Ersatz-PC und Interviews keine vergessene geplante Aufgabe.
| Quelle | Findet gut | Übersieht häufig |
|---|---|---|
| Begehung | Geräte, Standorte, Verkabelung, Beschriftung | Cloudkonten und logische Abhängigkeiten |
| Router, Switch und WLAN | Aktive Netzwerkgeräte, Adressen, Ports | Geräte außerhalb des Messzeitraums und externe Dienste |
| Endgeräteverwaltung | Hardware, Betriebssystem, installierte Software, Compliance | Nicht eingebundene oder private Geräte |
| Microsoft-365-Administration | Benutzer, Gruppen, Lizenzen, Apps, Geräte | Dienste anderer Anbieter und lokale Konten |
| Buchhaltung/Kontoauszüge | Wiederkehrende Anbieter und Abonnements | Kostenlose Dienste und privat bezahlte Schatten-IT |
| Passwortmanager | Bekannte Konten, Domains und Dienstzugänge | Konten außerhalb des gemeinsamen Tresors |
| Browser und E-Mail | Anmeldeportale, Rechnungen, Bestätigungen | Nicht verwendete oder gelöschte Nachrichten |
| Interviews | Arbeitsabläufe, informelle Wege, Probleme | Automatische Hintergrundprozesse |
| Server- und Anwendungsprotokolle | Tatsächliche Zugriffe, Jobs, Schnittstellen | Selten genutzte Vorgänge außerhalb des Zeitfensters |
Ersterfassung in zweiunddreißig Schritten
- Verantwortlichen für Inventarqualität und Freigaben benennen.
- Speicherort, Zugriffsschutz, Sicherung und Vertretungszugang festlegen.
- Objektarten, IDs, Statuswerte und Pflichtfelder definieren.
- Vorhandene Geräte-, Lizenz-, Vertrags- und Passwortlisten einsammeln.
- Jeden Raum und zugänglichen Technikstandort systematisch begehen.
- Hardwareetiketten fotografieren oder Seriennummern erfassen.
- Netzwerkkomponenten einschließlich unauffälliger Medienkonverter und PoE-Injektoren aufnehmen.
- Aktive Geräte aus Router, Switch, WLAN und Endgeräteverwaltung exportieren.
- Physische Liste und technische Exporte über Seriennummer, MAC-Adresse oder Hostname abgleichen.
- Unbekannte Geräte sperren oder mit klarer Frist identifizieren.
- Arbeitsplatzsoftware automatisiert erfassen, wo eine Verwaltung vorhanden ist.
- Fachanwendungen mit Version, Lizenz und Datenpfad ergänzen.
- Geplante Aufgaben, Dienste, Skripte und automatische Datenübertragungen erheben.
- Benutzer, Gruppen, privilegierte Rollen und Dienstkonten exportieren.
- Lokale Konten auf Servern, NAS, Netzwerk- und Spezialgeräten ergänzen.
- MFA- und Wiederherstellungswege je kritischem Konto dokumentieren.
- Cloudportale und Mandanten aus Passwortmanager, Rechnungen und E-Mails zusammenführen.
- Abrechnungen der letzten zwölf Monate nach IT-Anbietern und Abonnements prüfen.
- Domains, DNS, Webhosting, Zertifikate und E-Mail-Dienste erfassen.
- Internet-, Mobilfunk-, Telefonie- und Standortverträge aufnehmen.
- Datenablagen auf Server, NAS, Cloud und Endgeräten lokalisieren.
- Fachliche Eigentümer und Schutzbedarf je Datenbestand bestimmen.
- Backupweg, Aufbewahrung und letzten Restore-Nachweis verknüpfen.
- Geschäftsprozesse mit Verantwortlichen als konkrete Ablaufkette beschreiben.
- Für jeden Schritt benötigte Anwendung, Identität, Daten und Verbindung zuordnen.
- Externe Partner und Schnittstellen ergänzen.
- Ausfallauswirkung und maximal tolerierbare Unterbrechung festlegen.
- Wiederanlaufreihenfolge aus den Abhängigkeiten ableiten.
- Ungeklärte Funde in eine Liste mit Eigentümer und Termin überführen.
- Stichprobe mit Rechnungen, tatsächlichen Logins und Netzwerkbeobachtung prüfen.
- Fachbereiche bestätigen ihre Prozesse und Daten.
- Gesamtinventar freigeben und ersten regelmäßigen Prüftermin eintragen.
4. Die Abhängigkeitskarte beginnt beim Geschäftsprozess
Die Frage lautet nicht nur „Wovon hängt der Server ab?“, sondern „Was muss funktionieren, damit ein Auftrag angenommen, bearbeitet, abgerechnet und bezahlt werden kann?“
| Ebene | Benötigtes Element | Möglicher Ausfall |
|---|---|---|
| Geschäftsvorgang | Leistung abrechnen und Rechnung zustellen | Liquidität und Fristen beeinträchtigt |
| Anwendung | Buchhaltungs- oder ERP-Dienst | Beleg kann nicht erzeugt werden |
| Identität | Geschäftskonto mit Rolle und MFA | Anmeldung oder Freigabe scheitert |
| Daten | Kundendaten, Leistungspositionen, Nummernkreis | Rechnung unvollständig oder falsch |
| Kommunikation | E-Mail-Dienst oder E-Rechnungsschnittstelle | Zustellung scheitert |
| Netzwerk | Internet, DNS, Router, WLAN/LAN | Clouddienst nicht erreichbar |
| Endgerät | Verwalteter PC mit Browser oder Client | Bearbeitung vor Ort nicht möglich |
| Externer Anbieter | SaaS-, Mail-, Signatur- oder Peppol-Anbieter | Abhängigkeit außerhalb eigener Infrastruktur |
| Wiederherstellung | Notfallkonto, Export, Backup, Ersatzinternet | Störung kann nicht überbrückt werden |
Abhängigkeiten als Matrix pflegen
Für kleine Umgebungen ist eine Matrix oft nützlicher als ein überladener Architekturplan. Jede Zeile enthält einen Geschäftsprozess, jede Spalte eine Ressource. Ein Eintrag unterscheidet „zwingend“, „hilfreich“ und „Ersatzweg vorhanden“. Ergänzend verweist die Zelle auf die jeweilige Inventar-ID.
| Prozess | Identität | Anwendung | Daten | Verbindung | Ersatzweg |
|---|---|---|---|---|---|
| Rechnung erzeugen | ID-004 zwingend | SaaS-006 zwingend | DATA-003 zwingend | NET-001 zwingend | NET-004 Mobilfunk |
| Kundenanfrage bearbeiten | ID-002 zwingend | SaaS-001 Mail | DATA-001 Postfach | NET-001 zwingend | Mobiltelefon mit freigegebenem Zugriff |
| Objektakte bearbeiten | ID-007 zwingend | APP-003 zwingend | DATA-008 zwingend | NET-002 LAN/VPN | Nur lesbares Notfallexportarchiv |
| Zahlung freigeben | ID-009 plus zweite Person | SaaS-011 Bank | DATA-012 Zahlungsdaten | NET-001 | Separates verwaltetes Notebook |
Gemeinsame Fehlerursachen sichtbar machen
Zwei Dienste sind keine unabhängigen Alternativen, wenn beide denselben Anmeldeanbieter, Internetanschluss oder Administrator benötigen. Die Abhängigkeitskarte markiert solche gemeinsamen Fehlerursachen. Ein Backup in demselben Mandanten, ein Ersatzinternet am selben stromlosen Router oder zwei Notfallkonten mit demselben MFA-Telefon können im entscheidenden Moment gemeinsam ausfallen.
- Gleicher Stromkreis oder gleiche USV
- Gleicher Internet- oder DNS-Anbieter
- Gleiche Identitätsplattform und MFA-Methode
- Gleiches Administrationskonto
- Gleicher Cloudmandant oder Speicherort
- Gleicher physischer Standort
- Gleicher Dienstleister ohne dokumentierte Vertretung
- Gleicher Verschlüsselungsschlüssel oder Schlüsselzugang
5. Kritikalität wird aus der Geschäftsauswirkung abgeleitet
Ein teurer Server kann weniger dringlich sein als ein unscheinbares Administratorkonto. Priorität entsteht aus Ausfallfolge, Zeitabhängigkeit, Datenverlust, Ersatzweg und Wiederherstellbarkeit.
| Klasse | Auswirkung | Dokumentations- und Schutzfolge |
|---|---|---|
| A – betriebsentscheidend | Kernvorgang steht, Frist oder Zahlung gefährdet, hoher Schaden möglich | Verantwortung, Vertretung, Wiederanlauf, Backup und Ersatzweg vollständig prüfen |
| B – wichtig | Arbeit deutlich eingeschränkt, begrenzte Übergangslösung vorhanden | Wiederherstellung planen und innerhalb definierter Zeit testen |
| C – unterstützend | Ausfall zeitweise tragbar, keine unmittelbare wesentliche Folge | Inventarisieren, Standardwiederherstellung und Lebenszyklus pflegen |
| U – ungeklärt | Auswirkung oder Eigentümer unbekannt | Nicht automatisch als unwichtig behandeln; Klärung terminieren |
Priorität in zehn Fragen bestimmen
- Welcher konkrete Geschäftsprozess stoppt?
- Ab welchem Zeitpunkt entsteht ein finanzieller, vertraglicher oder reputativer Schaden?
- Wie viele Beschäftigte und externe Beteiligte sind betroffen?
- Welche Fristen oder Zahlungen können versäumt werden?
- Welche Daten können verloren gehen oder unbemerkt falsch werden?
- Existiert ein tatsächlich geübter manueller Ersatzweg?
- Wie lange trägt dieser Ersatzweg ohne Folgefehler?
- Welche anderen Systeme müssen vor diesem Objekt verfügbar sein?
- Wie lange dauert die getestete Wiederherstellung?
- Wer darf im Notfall die Entscheidung zur Wiederherstellung treffen?
RTO und RPO werden an den Geschäftsprozess gebunden. Die maximal tolerierbare Unterbrechung bestimmt, wie schnell ein Dienst zurückkehren muss. Der maximal tolerierbare Datenverlust bestimmt, aus welchem Sicherungszeitpunkt wiederhergestellt werden darf. Beide Werte werden mit den tatsächlich erreichbaren Wiederherstellungszeiten und Sicherungsintervallen verglichen.
Wiederanlauf aus technischen Voraussetzungen ableiten
| Reihenfolge | Komponente | Prüfergebnis vor dem nächsten Schritt |
|---|---|---|
| 1 | Strom, USV und Internetabschluss | Stabile Versorgung und physische Verbindung vorhanden |
| 2 | Router, Firewall und DNS | Interne und externe Namensauflösung funktioniert |
| 3 | Identitätsdienst und Notfallkonto | Testanmeldung mit korrekter MFA erfolgreich |
| 4 | Server, NAS oder Cloudzugang | Volumes, Dienste und Integritätsstatus unauffällig |
| 5 | Fachanwendung und Datenbank | Anwendungskonsistenz und Referenzdatensatz geprüft |
| 6 | Arbeitsplätze und Peripherie | Realer Geschäftsablauf vollständig ausgeführt |
| 7 | Backup und Monitoring | Neue Sicherung und Testwarnung erfolgreich |
6. Vertrags- und Administrationshoheit müssen beim Unternehmen auffindbar sein
Das Unternehmen sollte erkennen können, wem Domain, Mandant und Vertrag gehören, welche Personen administrieren und wie ein Zugang bei Ausfall oder Dienstleisterwechsel wiederhergestellt wird.
| Prüffeld | Zu dokumentieren | Praktischer Nachweis |
|---|---|---|
| Vertragsinhaber | Juristische oder natürliche Person mit Kundennummer | Aktuelle Rechnung und Kundenportal |
| Primäre Kontaktadresse | Geschäftlich kontrolliertes Funktionspostfach | Empfang einer Testnachricht |
| Administratoren | Mindestens zwei persönliche Konten, soweit Plattform unterstützt | Rollenexport und Testanmeldung |
| MFA | Je Administrator unabhängige Methode | Test ohne Gerät der jeweils anderen Person |
| Kontowiederherstellung | Alternative Adresse, Rufnummer, Support- und Identitätsnachweis | Verfahren anhand Anbieterangaben nachvollzogen |
| Abrechnung | Zahlungsmittel, Kostenstelle, Rechnungsabruf | Vertretung kann aktuelle Rechnung laden |
| Support | Portal, Vertragsnummer, Leistungsumfang, Eskalationsweg | Testticket oder dokumentierter Zugang |
| Datenexport | Formate, Umfang, Dauer, Rechte, Kosten | Repräsentativen Export öffnen und prüfen |
| Kündigung | Frist, Restlaufzeit, Datenlöschung und Exportfenster | Vertragliche Regel auffindbar |
Privilegierte Konten gesondert erfassen
Ein solches Konto kann globale Mandantenrechte, DNS-Zonen, Backupziele, Firewallregeln oder Bankfreigaben verändern. Seine Inventarzeile nennt Rolle, Zweck, Eigentümer, MFA, Notfallvertretung, letzte Prüfung und den Verweis zum Tresoreintrag. Sie enthält kein Kennwort. Gemeinsame Konten werden vermieden, soweit der Dienst persönliche Administratoren ermöglicht.
- Globaler oder Mandantenadministrator
- Domain- und DNS-Verwaltung
- Firewall-, Router- und VPN-Administration
- Backupadministration und Wiederherstellungsschlüssel
- Server-, NAS- und Virtualisierungsadministration
- Webhosting, Quellcode und API-Schlüssel
- Finanz-, Bank- oder Zahlungsfreigabe
- Notfallkonto mit abweichendem Zugriffspfad
7. Aktualität entsteht durch Ereignisse und feste Prüftermine
Eine jährliche Großinventur reicht nicht, wenn neue Dienste, Geräte und Konten zwischenzeitlich ohne Eintrag entstehen. Jede relevante Änderung aktualisiert das Inventar im selben Arbeitsvorgang.
| Ereignis | Zu aktualisierende Bestände | Abschlusskontrolle |
|---|---|---|
| Beschaffung | Hardware, Vertrag, Garantie, Zweck, Eigentümer | Inventar-ID vor produktiver Ausgabe |
| Inbetriebnahme | Konfiguration, Standort, Benutzer, Backup, Abhängigkeit | Abnahme und Status „produktiv“ |
| Mitarbeitereintritt | Konten, Geräte, Gruppen, Lizenzen, MFA | Rollenbezogene Checkliste |
| Mitarbeiteraustritt | Kontenstatus, Datenbesitz, Geräte, Weiterleitungen, Lizenzen | Positive Sperrprüfung und Übergabe |
| Update oder Umbau | Version, Konfiguration, Abhängigkeiten, Supportende | Änderungs- und Funktionstest |
| Neuer Cloud-Dienst | Vertrag, Administratoren, Daten, MFA, Export, Backup | Freigabe vor Nutzung |
| Störung | Zustand, Ursache, Ersatzteil, Wiederanlauf, offene Risiken | Dokumentation nach Fehlerbehebung |
| Ausmusterung | Status, Datenübergabe, Konten, Lizenzen, Löschung | Abschlussnachweis und Datum |
Monatliche, quartalsweise und jährliche Prüfung aufteilen
| Rhythmus | Prüfung |
|---|---|
| Monatlich | Neue Geräte, Konten, Cloud-Dienste, offene ungeklärte Objekte und bevorstehende Kündigungen |
| Quartalsweise | Privilegierte Rollen, inaktive Konten, Supportenden, Backupzuordnung und kritische Abhängigkeiten |
| Halbjährlich | Notfallkonten, Wiederanlaufreihenfolge, Dienstleisterkontakte und repräsentativer Datenexport |
| Jährlich | Vollständigkeitsabgleich, Fachbereichsbestätigung, Risikoeinstufung, Lebenszyklus- und Budgetplanung |
| Nach jeder wesentlichen Änderung | Betroffene Inventarobjekte, Dokumentation, Abhängigkeiten und Abnahmetest |
Qualitätskontrolle mit sechs Abfragen
- Zeige alle produktiven Objekte ohne fachlichen Eigentümer.
- Zeige alle kritischen Dienste ohne dokumentierte Vertretung.
- Zeige Support- und Vertragsenden der nächsten zwölf Monate.
- Zeige Datenbestände ohne getesteten Wiederherstellungsweg.
- Zeige privilegierte Konten ohne unabhängige MFA oder letzte Prüfung.
- Zeige ausgemusterte Geräte ohne Lösch- oder Rückgabenachweis.
Bleibt eine solche Abfrage technisch unmöglich, sind die Felder vermutlich zu frei oder nicht einheitlich. Liefert sie viele Treffer, entsteht daraus eine priorisierte Arbeitsliste. Damit wird Inventarpflege zu einem Steuerungsinstrument statt zu einer statischen Ablage.
Änderungen nachvollziehbar und ohne Dubletten einpflegen
Vor jedem neuen Eintrag wird nach Seriennummer, Vertragsnummer, Mandantenname, Domain und vorhandener Inventar-ID gesucht. Dadurch wird ein SaaS-Dienst nicht dreimal als Produkt, Rechnung und Login angelegt. Stattdessen verweist ein Dienstobjekt auf den zugehörigen Vertrag, die Administratoridentitäten und den Datenbestand. Hardwareaustausch erzeugt eine neue Geräte-ID; das alte Gerät wird mit Verweis auf den Nachfolger ausgemustert. So bleibt die Historie erhalten.
| Feld | Beispiel | Zweck |
|---|---|---|
| Änderungs-ID | CHG-2026-037 | Vorgang eindeutig referenzieren |
| Datum und Person | 11.09.2026, zuständige Bearbeitung | Zeitpunkt und Verantwortung belegen |
| Auslöser | Notebooktausch für NB-023 | Geschäftlichen Grund festhalten |
| Betroffene IDs | NB-023, NB-031, LIC-004, ID-017 | Zusammenhängende Objekte finden |
| Vorher/Nachher | NB-023 produktiv → ausgemustert; NB-031 geplant → produktiv | Statusänderung nachvollziehen |
| Prüfung | Verschlüsselung, Anmeldung, Datenzugriff, Backup | Technische Funktionsfähigkeit belegen |
| Restpunkt | Leasingrückgabe bis 30.09. | Offene Folgeaufgabe sichtbar halten |
- Vorhandenes Objekt über eindeutige Merkmale suchen.
- Änderungsgrund und betroffene Inventar-IDs erfassen.
- Neue Konfiguration und Abhängigkeiten eintragen.
- Vorgesehenen Funktions- oder Sicherheitstest ausführen.
- Alten Zustand nicht löschen, sondern nachvollziehbar beenden.
- Offene Rückgabe, Kündigung oder Datenlöschung mit Termin erfassen.
- Änderung erst schließen, wenn Test und Folgeaufgaben belegt sind.
Eine Versionshistorie der Datei oder Plattform schützt zusätzlich vor versehentlicher Überschreibung. Für besonders kritische Änderungen, etwa neue globale Administratoren, geänderte DNS-Server oder ein neues Backupziel, wird eine zweite prüfende Person vorgesehen. Die Inventardokumentation ersetzt dabei kein technisches Änderungsprotokoll; sie hält den für Betrieb, Verantwortung und Wiederherstellung relevanten Endzustand fest.
8. Ein begrenztes Notfallpaket bleibt auch ohne Hauptsystem erreichbar
Das vollständige Inventar darf geschützt und digital geführt werden. Für einen Identitäts-, Cloud- oder Netzausfall braucht die Vertretung zusätzlich einen bewusst begrenzten Offline-Auszug.
| Inhalt | Zweck | Schutz |
|---|---|---|
| Kontakt- und Eskalationsliste | Provider, Dienstleister, Leitung und fachliche Verantwortliche erreichen | Versioniert und nach Wechsel sofort aktualisieren |
| Wiederanlaufreihenfolge | Voraussetzungen in richtiger Reihenfolge herstellen | Kurze geprüfte Schritte statt vollständigem Handbuch |
| Kritische Inventar-IDs | Systeme, Verträge und Daten eindeutig benennen | Keine offenen Kennwörter |
| Vertrags- und Kundennummern | Support und Entstörung legitimieren | Nur erforderliche Angaben |
| Netzwerkübersicht | Internetweg, Router, Kernswitch, Server und Backup lokalisieren | Physisch geschützt aufbewahren |
| Tresorzugangsverfahren | Notfallkonto und Wiederherstellungsschlüssel erreichen | Zwei-Personen- oder versiegeltes Verfahren nach Schutzbedarf |
| Letzter Restore-Nachweis | Geeignete Sicherung und erwartete Dauer kennen | Ohne vertrauliche Nutzdaten |
| Entscheidungsbefugnisse | Abschaltung, Wiederherstellung und externe Hilfe freigeben | Rollen statt veralteter Einzelpersonen, soweit möglich |
Vertretungstest in zwölf Schritten
- Eine geeignete Vertretung bestimmen, die das Inventar nicht erstellt hat.
- Ausfall von Hauptadministrator, dessen Notebook und Mobiltelefon annehmen.
- Offline-Notfallpaket ohne Hinweis durch den Ersteller auffinden.
- Kritischen Geschäftsprozess und zugehörige Inventarobjekte identifizieren.
- Internetprovider samt Kundennummer und Supportweg finden.
- Notfallkonto nach vorgesehenem Verfahren erreichen.
- Abhängigkeiten und korrekte Wiederanlaufreihenfolge erklären.
- Letzte erfolgreiche Sicherung und Restore-Nachweis lokalisieren.
- Kontakt zu fachlichem Eigentümer und Dienstleister herstellen.
- Einen ungefährlichen Prüfvorgang anhand der Anleitung ausführen.
- Unklare, fehlende oder veraltete Angaben protokollieren.
- Unterlagen korrigieren und Test mit einer zweiten Person wiederholen.
9. Praxisbeispiel: Fünf Beschäftigte, 43 Inventarobjekte und sieben kritische Abhängigkeiten
Ein kleines Planungsbüro startet mit einer unvollständigen Geräteliste. Nach Begehung, Konto- und Vertragsprüfung umfasst das Inventar 14 Hardwaregeräte, 9 Softwareprodukte, 8 Cloud- und Kommunikationsdienste, 7 privilegierte oder technische Identitäten und 5 maßgebliche Datenbestände.
Als geschäftskritisch gelten Angebotsbearbeitung, Projektablage, Zeiterfassung, Rechnungsstellung und E-Mail. Die Abhängigkeitskarte zeigt, dass vier davon denselben Microsoft-365-Mandanten und dieselbe primäre Administratorin benötigen. Der vermeintlich unabhängige Backupdienst meldet sich ebenfalls über dieses Konto an. Außerdem besitzt nur eine private E-Mail-Adresse Zugriff auf Domain und DNS.
| Befund | Risiko | Maßnahme | Abnahme |
|---|---|---|---|
| Einzige M365-Administratorin | Abwesenheit sperrt Wiederherstellung und Änderungen | Zweites persönliches Notfallkonto mit unabhängiger MFA | Vertretung meldet sich erfolgreich an. |
| Backup nutzt gleiche Identität | Kontosperre betrifft Produktivdienst und Sicherung | Getrennte Backupadministration und dokumentierter Herstellerzugang | Restore ohne primäres Konto getestet |
| Domain auf Privatadresse | Unternehmen verliert bei Trennung möglicherweise Kontrolle | Inhaber- und Kontaktangaben auf kontrollierte Geschäftsadresse übertragen | Login, Rechnung und Wiederherstellung geprüft |
| Drei unbekannte SaaS-Abos | Kosten und Datenflüsse ungeklärt | Eigentümer, Zweck, Daten, Vertrag und Exit bewerten | Freigegeben oder gekündigt |
| Notebook ohne Inventar-ID | Verschlüsselungs- und Rückgabestatus unbekannt | Gerät aufnehmen, verschlüsseln und verantwortlicher Person zuordnen | Schlüssel und Verwaltungsstatus nachgewiesen |
| Projektablage ohne RTO | Backupziel nicht an Betriebsbedarf ausgerichtet | Tolerierbare Unterbrechung festlegen und Restore messen | Messwert erfüllt vereinbartes Ziel |
| Scanner schreibt mit Alt-Konto | Austritt oder Kennwortwechsel stoppt Belegfluss | Dokumentiertes Dienstkonto mit begrenztem Recht | Testscan und Protokoll erfolgreich |
Der größte Nutzen ist keine schönere Liste. Das Büro kann nun erklären, welche fünf Vorgänge geschützt werden, welche sieben gemeinsamen Abhängigkeiten bestehen und welche drei Maßnahmen die größte Ausfallwirkung reduzieren. Beschaffung, Eintritt, Austritt und Ausmusterung aktualisieren das Inventar künftig als festen Prozessschritt.
Häufige Fragen zum IT-Inventar
Reicht für ein kleines Unternehmen eine Excel-Tabelle?
Ja, wenn sie geschützt, gesichert, einheitlich strukturiert und regelmäßig gepflegt wird. Entscheidend sind Datenqualität, Verknüpfungen, Zuständigkeit und Vertretungszugang. Sobald mehrere Personen gleichzeitig pflegen, Änderungsverlauf oder automatischer Abgleich wichtig werden, kann eine Inventarplattform sinnvoller sein.
Müssen alle privaten Geräte erfasst werden?
Erfasst werden alle Geräte, die geschäftliche Daten oder Dienste erreichen, soweit das Unternehmen dies zulässt. Bei privaten Geräten kann der Datensatz auf Eigentumsart, Benutzer, zugelassene Nutzung, Verwaltungsstatus und Zugriff beschränkt werden. Besser ist eine klare Regel, welche privaten Geräte überhaupt Zugriff erhalten.
Gehören Passwörter in die Inventarliste?
Nein. Das Inventar verweist auf den geschützten Tresoreintrag und beschreibt Zweck, Rolle, Eigentümer und Wiederherstellungsweg. Kennwörter, Wiederherstellungscodes und Schlüssel verbleiben im dafür vorgesehenen Passwortmanager oder Notfallverfahren.
Wie findet man unbekannte Cloud-Abonnements?
Rechnungen, Firmenkreditkarten, Kontoauszüge, Passwortmanager, Browserprofile, Bestätigungsmails, Single-Sign-on-Protokolle und Gespräche mit Beschäftigten werden abgeglichen. Kostenlose Dienste fehlen in der Buchhaltung; privat bezahlte Dienste fehlen auf Unternehmenskarten. Deshalb sind mehrere Quellen erforderlich.
Wer sollte Eigentümer eines IT-Objekts sein?
Der fachliche Eigentümer entscheidet, wofür das Objekt benötigt wird, wer zugreifen darf und welche Ausfallfolge vertretbar ist. Die technische Verantwortung kann intern oder extern liegen. Beide Rollen dürfen benannt sein, weil eine technisch korrekte Konfiguration die geschäftliche Entscheidung nicht ersetzt.
Wie detailliert muss eine Abhängigkeitskarte sein?
So detailliert, dass Wiederanlauf, Änderung und Ausfallentscheidung möglich sind. Jede einzelne Kabelader oder Bibliotheksdatei aufzunehmen, hilft selten. Geschäftsprozess, Anwendung, Identität, Datenbestand, Netzwerk, externer Dienst, Verantwortlicher und Ersatzweg bilden für kleine Umgebungen meist die nützliche Ebene.
Weiterführende Primärquellen
- BSI: IT-Systeme erheben – strukturierte Erfassung von IT-Systemen sowie Matrixdarstellung ihrer Beziehungen zu Anwendungen.
- NIST: Cybersecurity Framework 2.0 – Small Business Quick-Start Guide – Inventar von Hardware, Software, Systemen, Diensten und geschäftlicher Auswirkung.
- NIST: CSF 2.0 Implementation Examples – Inventarisierung externer Dienste, Priorisierung, Datenbestände und Lebenszykluspflege.
- NIST: Cybersecurity Framework Quick Start Guide – Hardware- und Softwareinventar, Informationsflüsse sowie Rollen und Verantwortlichkeiten.
IT-Inventar und Abhängigkeiten verlässlich dokumentieren
fra.digital führt Geräte, Dienste, Identitäten, Verträge, Daten und Geschäftsprozesse in einer wartbaren Dokumentation zusammen und leitet daraus Lebenszyklus-, Sicherheits- und Wiederanlaufmaßnahmen ab.
