So läuft es heute in den meisten Unternehmen
Die erste Liste entsteht in der IT, und sie entsteht aus einem guten Grund: Es muss beschafft, verlängert und lizenziert werden. Also gibt es eine Arbeitsmappe namens „Hardware_Software.xlsx" – ein Tabellenblatt für Notebooks und Server, eines für Softwarelizenzen, eines für Cloud-Dienste. Die Spalten heißen Bezeichnung, Hersteller, Anzahl, Kostenstelle, Vertragsende und Wartung bis. Für Beschaffung und Budgetplanung ist das genau das richtige Werkzeug, und meistens wird diese Liste auch sorgfältig gepflegt.
Parallel entsteht eine zweite Aufstellung, an anderer Stelle und aus einem anderen Anlass. Das Verzeichnis der Verarbeitungstätigkeiten nach Art. 30 DSGVO verlangt die Angabe, in welchen Systemen personenbezogene Daten verarbeitet werden. Also führt die Datenschutzbeauftragte oder der Datenschutzbeauftragte eine eigene Systemliste – als zusätzliches Tabellenblatt im Verzeichnis oder als Abschnitt in der Word-Vorlage. Darin stehen Anbieter, Datenkategorien und, wenn es gut läuft, ein Verweis auf den Auftragsverarbeitungsvertrag.
Zwei Listen, zwei Zwecke, zwei Sprachen. In der IT-Liste steht „M365 E3, 240 Lizenzen". In der Datenschutz-Liste steht „Microsoft 365 (Exchange, SharePoint, Teams)". Das Ticketsystem heißt an der einen Stelle nach dem Hersteller, an der anderen nach der Abteilung, die es nutzt. Ob dasselbe System gemeint ist, weiß nur, wer beide Dateien nebeneinander gelesen hat. Und wird ein Anbieter gewechselt, ändert sich in der Regel nur eine der beiden Listen.
Das eigentliche Problem ist aber das, was in keiner von beiden steht. Es gibt keine Angabe, wie schutzbedürftig ein System ist – weder für Vertraulichkeit noch für Integrität noch für Verfügbarkeit. Es gibt keine Person, die ein einzelnes Asset verantwortet; verantwortlich ist „die IT". Es gibt keine Beziehung zwischen den Zeilen: Dass das CRM ohne den Verzeichnisdienst nicht anmeldet und beide auf demselben Hypervisor laufen, steht nirgends. Und ausgemusterte Systeme bleiben einfach stehen, weil das Streichen einer Zeile niemandem auffällt.
Der Moment, in dem es auffällt
Im Alltag stört das nicht. Auffällig wird es in vier Situationen: beim ersten Zertifizierungsaudit, wenn nach dem Geltungsbereich des Managementsystems und nach der Schutzbedarfsfeststellung gefragt wird. Bei einer Lieferantenprüfung, wenn ein Kunde wissen will, in welchen Systemen seine Daten liegen. Nach einem Ausfall, wenn rekonstruiert werden soll, welche Prozesse betroffen waren und in welcher Reihenfolge wieder angefahren wird. Und beim Weggang des Administrators, der als Einziger wusste, was hinter welcher Zeile steckt.
In allen vier Fällen lautet die Frage nicht „Haben Sie eine Inventarliste?", sondern „Welche Systeme sind für welchen Prozess kritisch – und wer verantwortet sie?" Darauf hat eine Beschaffungsliste keine Antwort. Nicht, weil sie schlecht geführt wäre, sondern weil sie über Schutzbedarf, Verantwortung und Abhängigkeit strukturell nichts weiß.
Die Analyse
Fünf Probleme, die zwei getrennte Listen erzeugen
Sie entstehen unabhängig davon, wie sorgfältig die beiden Listen gepflegt werden – sie sind eine Folge der Trennung, nicht der Arbeitsweise.
Asset-Management in preeco ansehenDasselbe System, zwei Namen
Jedes System wird zweimal erfasst und dabei unterschiedlich benannt. Beide Stände lassen sich nicht verlässlich abgleichen, und bei einem Anbieterwechsel wird meist nur einer von beiden nachgezogen. Die Frage, wie viele Systeme im Einsatz sind, hat damit zwei Antworten.
Der Schutzbedarf steht nirgends
Keine der beiden Listen sagt, welchen Schutzbedarf ein System für Vertraulichkeit, Integrität und Verfügbarkeit hat. Ohne diese Einstufung gibt es keine begründete Priorisierung: Der Dateiserver mit Personalakten wird behandelt wie der Besprechungsraum-Kalender.
Kein Verantwortlicher je Asset
Zuständig ist „die IT" oder „der Datenschutz", nicht eine benannte Person je System. Rückfragen aus einem Audit landen deshalb immer bei derselben Stelle, und Pflege findet nur statt, wenn diese Stelle Zeit hat.
Abhängigkeiten sind unsichtbar
Eine Tabelle kennt nur Zeilen, keine Beziehungen. Welche Anwendung von welchem Dienst abhängt und welche Systeme sich eine Plattform teilen, steht nirgends. Damit lässt sich kein Ausfallszenario bewerten und keine Wiederanlaufreihenfolge begründen.
Kein Bezug zu Maßnahmen und Risiken
Schutzmaßnahmen stehen in einem eigenen Dokument, Risiken in einem dritten. Ob ein kritisches System tatsächlich durch Maßnahmen abgedeckt ist, lässt sich nur durch manuellen Abgleich beantworten – und niemand macht diesen Abgleich zwischen zwei Audits.
Der Soll-Prozess in sechs Schritten
Ein tragfähiges Asset-Management unterscheidet sich von einer Inventarliste nicht durch mehr Zeilen, sondern durch das, was an jeder Zeile hängt. Diese sechs Schritte beschreiben den Ablauf – unabhängig vom Werkzeug.
1. Einen Bestand führen statt zwei Listen. Jedes System wird genau einmal angelegt, mit einer Bezeichnung, die beide Seiten verwenden. Datenschutz und Informationssicherheit sehen denselben Datensatz aus ihrer jeweiligen Perspektive: der Datenschutz als Datenverarbeitungssystem mit Anbieter und Datenkategorien, die Informationssicherheit als Asset mit Konfiguration, Hosting und Betriebssystem. Genau das ist der Grund, warum preeco | datenschutz und preeco | informationssicherheit auf einer gemeinsamen Plattform liegen.
2. Assets kategorisieren und Prozessen zuordnen. Server, Clients, Anwendungen und Cloud-Dienste werden Kategorien zugeordnet und mit den Geschäftsprozessen verbunden, die sie tragen. Erst diese Zuordnung macht das Wort „kritisch" überprüfbar: Kritisch ist ein System nicht, weil es teuer war, sondern weil ein wichtiger Prozess ohne es stillsteht.
3. Je Asset eine verantwortliche Person benennen. Zu jedem System gehören eine fachlich verantwortliche Person sowie die Hersteller- und Lieferantenkontakte. Damit ist bei jeder Rückfrage klar, wer antwortet – im Audit, im Vorfall und bei der jährlichen Überprüfung.
4. Schutzbedarf feststellen statt schätzen. Für Vertraulichkeit, Integrität und Verfügbarkeit wird der Schutzbedarf über eine Schadensszenarien-Matrix nach dem Maximumprinzip bestimmt, wahlweise manuell oder KI-gestützt. Verknüpfte Systeme werden inklusive Kumulationseffekt berücksichtigt. Das Ergebnis lässt sich als PDF oder DOCX exportieren – mit Gesamtschutzbedarf, Matrix und vererbten Quellen.
5. Abhängigkeiten abbilden. Systeme werden hierarchisch über- und untergeordnet, Datenflüsse zwischen ihnen werden dokumentiert. Dazu kommen die Angaben, die im Ernstfall zählen: Hosting und Standort, Verschlüsselung, Erreichbarkeit, bekannte Schwachstellen und die Frage, ob ein System in den Anwendungsbereich der NIS2-Vorgaben fällt.
6. Lebenszyklus statt Liste. Ein Asset wird nicht gelöscht, wenn es außer Betrieb geht – es bekommt einen Status. Alle Änderungen werden mit Zeitstempel und Benutzer protokolliert, sodass auch Jahre später nachvollziehbar bleibt, wann ein System eingeführt und wann es abgelöst wurde.
Warum ein gemeinsamer Bestand mehr ist als eine zusammengeführte Datei
Zwei Excel-Listen ließen sich auch zusammenkopieren. Der Unterschied liegt nicht im Zusammenführen, sondern in dem, was danach möglich ist. Ein Asset ist dort ein Objekt, an dem andere Objekte hängen: die Verarbeitungstätigkeiten, die darauf laufen, die Maßnahmen, die es schützen, die Audits, in denen es geprüft wurde, und die Risikoanalysen, die es bewerten.
Das verändert die Richtung der Arbeit. Statt für ein Audit fünf Dokumente zusammenzusuchen, öffnen Sie das System und sehen, was daran hängt. Fällt ein Dienstleister aus, ist die Liste der betroffenen Verarbeitungen eine Ansicht statt einer Recherche. Und steigt der Schutzbedarf eines Systems, wird sichtbar, welche Maßnahmen und Risikoanalysen davon berührt sind.
Vorher und nachher im direkten Vergleich
| Kriterium | Vorher: zwei Excel-Listen | Nachher: gemeinsamer Asset-Bestand |
|---|---|---|
| Pflegeaufwand | Jedes System wird zweimal erfasst und zweimal geändert | Ein Datensatz, zwei Sichten für Datenschutz und Informationssicherheit |
| Aktualität | Änderung erreicht nur eine der beiden Listen | Änderung wirkt für beide Bereiche sofort |
| Vollständigkeit | Ausgemusterte Systeme bleiben stehen, neue fehlen | Status je Asset, Zugänge und Abgänge dokumentiert |
| Schutzbedarf | Nirgends hinterlegt, im Zweifel geschätzt | Vertraulichkeit, Integrität und Verfügbarkeit nach dem Maximumprinzip bestimmt |
| Verantwortlichkeit | „Die IT" | Benannte Person je Asset, dazu Hersteller- und Lieferantenkontakt |
| Abhängigkeiten | Nicht abgebildet, Ausfallszenarien nicht bewertbar | Über- und Unterordnung sowie Datenflüsse dokumentiert |
| Nachweisfähigkeit | Dateistand ohne Historie | Änderungen mit Zeitstempel und Benutzer protokolliert, Export als PDF und DOCX |
| Ausfallrisiko | Wissen liegt bei einer einzelnen Person | Bestand, Bewertung und Historie liegen im System |
In der Praxis
So sieht das in preeco | informationssicherheit aus
Die drei Bausteine, die den beschriebenen Prozess tragen.
Asset-Management
Server, Clients, Anwendungen und Cloud-Dienste zentral erfassen – mit Verantwortlichen, Anbietern, Hosting und Standort. Hierarchien und Datenflüsse werden abgebildet, der Schutzbedarf für Vertraulichkeit, Integrität und Verfügbarkeit über eine Schadensszenarien-Matrix bestimmt.
Risikoanalysen
Schutzbedarfs-, Ressourcen-, Schwellwert- und Gefährdungsanalysen bauen auf dem Asset-Bestand auf. Risiken werden direkt mit Maßnahmen verknüpft, freigegebene Analysen automatisch revisioniert und als PDF oder DOCX ausgegeben.
Verarbeitungstätigkeiten und Systeme
Dieselben Systeme erscheinen im Datenschutz als Datenverarbeitungssysteme – mit Datenkategorien, zugeordneten Verarbeitungstätigkeiten und den Verträgen zur Auftragsverarbeitung. Gepflegt wird der Bestand nur einmal.
Was der Umstieg praktisch bedeutet
Der häufigste Einwand lautet, man müsse dann alles neu aufnehmen. Das ist nicht der Fall. Die vorhandene Inventarliste ist die Grundlage: Sie wird übernommen und den strukturierten Feldern zugeordnet. Ergänzt wird nur, was in der Tabelle ohnehin gefehlt hat – Verantwortliche, Schutzbedarf und Abhängigkeiten. Genau diese Lücken sind der eigentliche Ertrag, denn sie werden sichtbar, bevor ein Auditor oder ein Ausfall sie sichtbar macht.
Der Aufwand liegt selten in der Technik. Bei einem mittelständischen Unternehmen mit 60 bis 120 Assets entfällt der größere Teil auf die inhaltliche Klärung: Wer verantwortet welches System, welcher Prozess hängt daran, und wie hoch ist der Schutzbedarf wirklich. Diese Klärung wäre in jedem Fall fällig – im Zweifel unter Zeitdruck, kurz vor dem Audit.
Drei Fehler, die den Umstieg unnötig schwer machen
Zu tief einsteigen. Ein Asset-Bestand ist keine Konfigurationsdatenbank. Erfassen Sie die Systeme, die Geschäftsprozesse tragen oder personenbezogene Daten verarbeiten – nicht jedes einzelne Peripheriegerät.
Den Schutzbedarf auf später verschieben. Ein Inventar ohne Einstufung ist wieder nur eine Liste. Der Schutzbedarf ist der Punkt, an dem aus dem Bestand eine Priorisierung wird und an dem Risikoanalysen andocken können.
Datenschutz und Informationssicherheit getrennt einführen. Wer beide Bereiche nacheinander und jeweils für sich aufsetzt, baut die zwei Listen im neuen Werkzeug wieder auf. Der gemeinsame Bestand ist die Voraussetzung dafür, dass der Pflegeaufwand tatsächlich sinkt.
Woran Sie erkennen, dass es Zeit ist
Eine Inventarliste in Excel ist kein Fehler. Sie wird zum Risiko, sobald einer dieser Punkte zutrifft:
- Sie können nicht sicher sagen, wie viele Systeme im Einsatz sind.
- Zu einem System lässt sich keine verantwortliche Person benennen.
- Der Schutzbedarf ist für kein System dokumentiert.
- Bei einem Ausfall wäre unklar, welche Prozesse betroffen sind.
- Eine Zertifizierung oder eine Kundenprüfung steht an.
Trifft davon nichts zu, reicht die Liste vorerst. Trifft davon zwei oder mehr zu, beschreibt sie längst nicht mehr das, was tatsächlich betrieben wird.
FAQ
Häufige Fragen zum Asset-Management
Alles, was einen Geschäftsprozess trägt oder Daten verarbeitet: Server, Clients, Anwendungen, Cloud-Dienste, Netzkomponenten und die zugehörigen Dienstleister. Der übliche Fehler ist nicht, zu wenig zu erfassen, sondern zu tief zu gehen. Beginnen Sie mit den Systemen, die Prozesse tragen oder personenbezogene Daten verarbeiten, und verfeinern Sie später.
Über Schadensszenarien: Sie bewerten je Schutzziel – Vertraulichkeit, Integrität und Verfügbarkeit – welcher Schaden bei einer Verletzung entstehen würde. Der höchste Wert bestimmt die Einstufung (Maximumprinzip). In preeco | informationssicherheit erfolgt das über eine Schadensszenarien-Matrix, wahlweise manuell oder KI-gestützt; verknüpfte Systeme werden inklusive Kumulationseffekt berücksichtigt. Das Ergebnis lässt sich als PDF oder DOCX exportieren.
Nein. Beide Bereiche beschreiben dieselben Systeme, nur mit unterschiedlichem Blick. preeco | datenschutz und preeco | informationssicherheit teilen sich eine Plattform: Ein System wird einmal gepflegt und erscheint im Datenschutz als Datenverarbeitungssystem, in der Informationssicherheit als Asset. Doppelte Pflege und abweichende Bezeichnungen entfallen damit.
Anlassbezogen und im Turnus. Anlassbezogen bei jeder Einführung, Ablösung oder wesentlichen Änderung eines Systems sowie bei einem Anbieterwechsel. Ergänzend hat sich eine vollständige Überprüfung pro Jahr bewährt, bei der Verantwortliche und Schutzbedarf bestätigt werden. Ein fester Turnus ist deshalb wichtig, weil Zugänge in der Regel auffallen, Abgänge dagegen nicht.
Die Norm erwartet ein Inventar der Werte im Geltungsbereich des Managementsystems, eine zugeordnete Verantwortung je Wert und Regeln für den zulässigen Umgang damit. In der Prüfung wird deshalb weniger die Vollständigkeit einer Liste betrachtet als die Nachvollziehbarkeit: ob Einstufung, Verantwortung und Maßnahmen zusammenpassen und ob der Bestand gepflegt wird.
Ihre Inventarliste gemeinsam durchgehen
Bringen Sie Ihre bestehende Tabelle mit. In 30 Minuten zeigen wir, wie daraus ein gemeinsamer Bestand für Datenschutz und Informationssicherheit wird.