Konzept: Daten und Informationen

evor Sie das Modul Daten und Informationen zum ersten Mal öffnen, lohnt ein Schritt zurück. Das Modul ist das Werkzeug, mit dem Sie die logischen Schutzgegenstände Ihrer Organisation beschreiben - also das, was Ihre Informationssicherheit und Ihr Datenschutz eigentlich schützen sollen. Dieser Artikel erklärt, warum es diese Schicht gibt, wie sie sich von Assets und Verarbeitungstätigkeiten unterscheidet und welche Logik hinter Schutzbedarf, Vererbung und Klassifikation steht.

Was ist ein Informationswert?

Ein Informationswert ist eine inhaltlich abgegrenzte Sammlung von Daten oder Informationen, die für Ihre Organisation einen erkennbaren Wert hat und deshalb geschützt werden muss. Beispiele aus der Praxis: Gehaltsdaten, Kundenstammdaten, Bewerbungsunterlagen, Rezepturen, Vertragsentwürfe, Konstruktionspläne, Patientenakten, Forschungsdaten.

Wichtig ist die Abstraktionsebene. Ein Informationswert ist nicht eine einzelne Datei und nicht ein Datensatz in einer Datenbank. Er ist eine Kategorie mit klarer fachlicher Bedeutung. "Gehaltsdaten" umfasst alle Lohn- und Gehaltsinformationen Ihrer Mitarbeitenden, unabhängig davon, ob sie aktuell im HR-System, in der Lohnbuchhaltung, in einem Excel-Export oder in einem ausgedruckten Bericht liegen.

Dieser Granularitätsgrad wird sich in der Praxis jedoch als zu grob herausstellen, sodass der audatis MANAGER diverse Werkzeuge zum Trennen und Zusammenführen von Daten- und Informationswerten enthält.

Die Frage wo Daten und Informationen gespeichert oder verarbeitet werden, gehört nicht in den Informationswert, sondern auf die Asset-Ebene bzw. in die Verknüpfung der Daten mit den Assets. Es kann sinnvoll sein, einen Informationswerte pro System oder Verarbeitungstätigkeit/Geschäftsprozess abzubilden. Es ist wichtig, das die Realität und die realen Schutzanforderungen abgebildet werden.

Warum diese Trennung sinnvoll ist

Wenn Sie Informationen und Assets zu grob in einem gemeinsamen Topf führen, entstehen drei Probleme.

1. Sie vervielfältigen den Aufwand: Aieselbe Gehaltsabrechnung liegt im HR-System, im Backup, im HR-Postfach und ggf. auf einem Papierausdruck. Müssten Sie für jeden dieser Speicherorte den Schutzbedarf neu denken, käme keine Organisation zu einem belastbaren Ergebnis.
2. Sie verlieren die fachliche und detaillierte Sicht: der Schutzbedarf hängt am Inhalt, nicht am Server. Datenkategorien können die gleichen sein, sich jedoch in verschiedenen Systemen in verschiedenen Geschäftsprozessen befinden.
3. Jede Vererbung bricht zusammen, sobald Sie ein System tauschen.

Mit der Zwei-Schichten-Logik bleibt der Aufwand behrrschbar und die Aussagekraft hoch. Sie bewerten den Schutzbedarf einmal auf der Informationsebene und vererben ihn automatisch an alle Träger, die diese Information enthalten. Tauschen Sie morgen den HR-Server, ändert sich die Verknüpfung, aber nicht der Schutzbedarf der Gehaltsdaten.

Daten und Informationen im ehemaligen audatis MANAGER

Wer aus der Vorgänger-Generation des audatis MANAGER kommt, kennt die Modellierung von Daten und Informationen als Vorlagentextbausteine.

Funktionsweise im ehemaligen MANAGER.

Im ehemaligen audatis MANAGER gab es keine eigenständigen Informationswerte als Datenobjekte. Daten und Informationen wurde dort über Textbausteine abgebildet. Dabei handelte es sich um frei formulierte Textblöcke, die Datenkategorien, Datenarten oder Verarbeitungs-Inhalte beschrieben. Diese Textbausteine wurden in Verarbeitungstätigkeiten oder andere Datensätze eingefügt, in Maßnahmen-Beschreibungen referenziert oder in TOM-Katalogen verwendet. Verknüpfungen zu anderen Objekten (weitere Textbausteine, Assets, TOM, Geschäftsprozesse) waren technisch nicht möglich und vom Datenmodell so nicht vorgesehen - in der Praxis blieb es bei einer textlichen Beschreibung neben den Strukturdaten, nicht bei einer strukturell verknüpften Daten-Entität.

Drei strukturelle Schwächen dieses Ansatzes traten in der täglichen Pflege regelmäßig auf:

1. Kein eigenständiger Schutzbedarf pro Daten-Einheit. Weil Daten und Informationen keine eigenen Objekte waren, ließ sich für sie auch kein eigener Schutzbedarf definieren, begründen oder fortschreiben. Schutzbedarf wurde - wenn überhaupt - auf Asset- oder VT-Ebene gepflegt. Das verkehrt die fachliche Logik: der Schutzbedarf hängt am Inhalt (Gehaltsdaten, Bewerbungsunterlagen, Konstruktionszeichnungen), nicht an der Verarbeitungstätigkeit/dem Geschäftsprozess. Wenn der Schutzbedarf an der Verarbeitungstätigkeit/dem Geschäftsprozess hängt, kann er nicht sauber vererbt werden. Eine C/I/A-Bewertung mit nachvollziehbarer Begründung pro Daten-Art war im alten Modell strukturell nicht abbildbar.
2. Verknüpfungen ohne Durchgriff. Textbausteine konnten zwar an VTen, an TOM-Katalogen oder an weitere Bausteine angehängt werden, aber diese Verknüpfungen waren lose Anhänge, keine ausgewerteten Beziehungen. Niemand konnte aus dem System heraus die Frage beantworten: "Welche TOM schützt diese Informationsart auf welchem Asset?" In der Folge wurden tiefere Verknüpfungen (zweite/dritte Ebene) in der Pflege oft vernachlässigt - sie brachten keinen sichtbaren Mehrwert, weil sie nirgendwo aggregiert ausgewertet wurden.
3. Dubletten, Inkonsistenzen und schwache Klassifikation. Dieselbe Informationsart wurde in unterschiedlichen Wordings in mehreren Textbausteinen geführt ("Gehaltsdaten", "Vergütungsdaten Personal", "Lohnabrechnung"), oder der selbe Textbaustein mehrfach verwendet (was fachlich falsch war). Es gab keinen technischen Mechanismus, um diese Synonyme zu erkennen oder zu konsolidieren. Klassifikationsschemata (öffentlich, intern, vertraulich, streng vertraulich) konnten beschrieben, aber nicht durchgesetzt werden.

Insgesamt waren die alten Textbausteine dokumentierende Sprachhilfen - geeignet, um in einem VVT oder einem AVV die Datenarten lesbar zu beschreiben, aber nicht geeignet als operatives Daten-Inventar mit Schutzbedarfsmechanik und Vererbung. Damit entfiel die Möglichkeit zur Nutzung der TOM über ein DOkumentationswerkzeug hinaus.

Grundidee des neuen MANAGERs.

Der neue audatis MANAGER macht den Informationswert zu einer eigenen Daten-Entität. Er ist nicht mehr ein Text, sondern ein eigenständiges Datenobjekt mit strukturiertem Feldsatz: Bezeichnung, fachliche Beschreibung, Personenbezug, Klassifikation, Schutzbedarf C/I/A mit eigener Begründung pro Dimension, Eigentümer, Status, Lebenszyklus. Damit lässt sich der Schutzbedarf einmal pro Informationsart bewerten und nach dem Maximum-Prinzip an alle Assets vererben, die diese Information tragen - die strukturelle Voraussetzung dafür, dass Informationswerte und Assets als zwei saubere Schichten zusammenarbeiten (siehe vorigen Abschnitt). Verknüpfungen werden im neuen Modell als auswertbare Beziehungen verwendet (statt als reine Textbausteine): vom Informationswert führen sofort referenzierbare Kanten zu Assets, zu Verarbeitungstätigkeiten, zu Geschäftsprozessen und zu TOM. Daraus entsteht der vollständige Beziehungs-Graph, mit dem ein Auditor und ein Compliance-Verantwortlicher in wenigen Klicks beantworten können, welche Information durch welche Maßnahme auf welchem Asset im Rahmen welcher Verarbeitung geschützt wird. Dubletten werden strukturell unwahrscheinlicher (eine Informationsart - ein Datensatz), und Klassifikation ist über das im Mandanten konfigurierte Klassifikationsschema umgesetz statt nur beschrieben.

Damit löst der neue MANAGER die drei zentralen Schwächen des Vorgängers: aus Textbausteinen ohne Datenmodell werden Informationswerte mit Schutzbedarf, aus losen Anhängen werden auswertbare Beziehungen, aus parallel verwendeten Textbausteinen wird ein zusammengeführtes Inventar. Der nächste Abschnitt beschreibt die Mechanik im Detail.

Schutzbedarf - das C/I/A-Modell

Jeder Informationswert wird im Tab Schutzbedarf entlang dreier Dimensionen bewertet:

• Vertraulichkeit (C - Confidentiality): Wie schlimm wäre es, wenn diese Information in falsche Hände gerät? Pflichtfeld inklusive Begründung.
• Integrität (I - Integrity): Wie schlimm wäre es, wenn diese Information verändert oder verfälscht wird, ohne dass es bemerkt wird? Pflichtfeld inklusive Begründung.
• Verfügbarkeit (A - Availability): Wie schlimm wäre es, wenn diese Information vorübergehend nicht zugänglich ist? Optional auf Informationswert-Ebene, weil Verfügbarkeit primär vom verarbeitenden Asset und vom Geschäftsprozess abhängt.

Die zulässigen Stufen werden in der Assetmanagement-Konfiguration zentral definiert und gelten modulübergreifend - typisch sind drei Stufen (normal, hoch, sehr hoch). Damit ist sichergestellt, dass Informationswerte, Assets und TOM dieselbe Skala verwenden und die spätere Zusammenführung im Risikomanagement nicht an Skalenbrüchen scheitert.

Der Begründungs-Pflichtteil ist kein Schikane-Feld. In einem Audit ist die Bewertung C = hoch ohne nachvollziehbare Begründung wertlos - der Auditor fragt nach dem Schaden, der entstünde, wenn diese Information öffentlich würde. Wer hier eine kurze, faktenbasierte Begründung hinterlegt, baut für jedes spätere Risiko-Assessment und jede Wirksamkeitsprüfung die nötige Argumentationsbasis auf.

Schutzbedarfs-Vererbung nach dem Maximum-Prinzip

Das mächtigste Konzept im Datenmodell ist die automatische Vererbung des Schutzbedarfs vom Informationswert auf das verknüpfte Asset. Sobald Sie einen Informationswert über den Tab Verknüpfungen mit einem Asset koppeln, übernimmt das Asset den Schutzbedarf nach dem Maximum-Prinzip: der höhere Wert aus allen verknüpften Informationswerten gewinnt.

Ein Beispiel: Auf dem Fileserver FS-01 liegen sowohl Marketing-Bilder (C = normal) als auch Personalakten (C = sehr hoch). Sobald beide Informationswerte mit FS-01 verknüpft sind, wird das Asset automatisch auf C = sehr hoch eingestuft. Senken Sie später den Schutzbedarf der Personalakten, weil Sie sie ausgelagert haben, bleibt das Asset auf dem höchsten Wert der noch verknüpften Informationswerte. Eine manuelle Absenkung des Asset-Schutzbedarfs unter den vererbten Wert ist gesperrt - dies ist eine Schutzschranke gegen versehentliches Heruntersetzen.

Die Verfügbarkeit verhält sich asymmetrisch. Sie kommt nicht primär von den Informationswerten, sondern aus den Geschäftsprozessen und Verarbeitungstätigkeiten, die mit dem Asset arbeiten. Das hat einen handfesten Grund: dieselben Personalakten sind im Monatslauf der Lohnbuchhaltung verfügbarkeitskritisch, im Archiv des HR-Berichts hingegen nicht. Die Verfügbarkeitsbewertung gehört dort hin, wo der Prozess die Anforderung erzeugt.

Klassifikation und Personenbezug

Neben dem Schutzbedarf trägt jeder Informationswert eine Klassifikation (öffentlich, intern, vertraulich, streng vertraulich oder ein vom Mandanten konfiguriertes Schema) und zwei DSGVO-Marker:

• Personenbezug - schaltet den Datensatz für VVT-Pflichten und Betroffenenrechte scharf.
• Art. 9 DSGVO - kennzeichnet besondere Kategorien personenbezogener Daten (Gesundheit, biometrische Daten, ethnische Herkunft, religiöse Überzeugungen, sexuelle Orientierung, Gewerkschaftszugehörigkeit, politische Meinung). Diese Markierung hat unmittelbare Folgen: Datenschutz-Folgenabschätzungen werden eher fällig, technisch-organisatorische Maßnahmen müssen den erhöhten Anforderungen aus Art. 9 Abs. 2 DSGVO entsprechen.

Die Klassifikation ist die Brücke zur Beschriftungs- und Behandlungsanforderung z.B. aus ISO 27001:2022 Annex Controls 5.12 und 5.13. Im audatis MANAGER ist sie ein eigenständiges Attribut neben dem Schutzbedarf - bewusst, weil Klassifikation und Schutzbedarf zwar oft korrelieren, aber unterschiedliche Fragen beantworten. Klassifikation regelt Umgang und Sichtbarkeit, Schutzbedarf regelt Schutzanforderung. Eine "öffentlich"-klassifizierte Information kann durchaus hohen Integritätsbedarf haben (Beispiel: amtliche Verkehrshinweise).

Verhältnis zu Assets, VVT und TOM

Der Informationswert ist die Drehscheibe Ihres Datenmodells. Vier Beziehungstypen sind dabei tragend:

Genau diese vier Beziehungen sind der Grund, warum der audatis MANAGER vom Informationswert aus mit wenigen Klicks ein vollständiges Lagebild liefert: welche Systeme tragen die Information, welche Prozesse verarbeiten sie und welche Maßnahmen schützen sie. Sauber gepflegte Daten und Informationen sind also die Basis jedes Datenschutz- und Informationssicherheitsmanagements.

Was ein Informationswert NICHT ist

Drei häufige Missverständnisse, die in Erst-Audits regelmäßig vorkommen:

1. Ein Informationswert ist keine Datei. Eine PDF mit Gehaltsdaten ist ein Vorkommen des Informationswerts "Gehaltsdaten", nicht der Informationswert selbst. Wer für jede Datei einen Eintrag anlegt, verliert die Abstraktion - und damit die Vererbungslogik.
2. Ein Informationswert ist keine Datenbank-Tabelle. Die Tabelle salaries im HR-System ist ein Vorkommen des Informationswerts. Der Informationswert beschreibt den Inhalt fachlich, die Tabelle ist nur eine Speicherform.
3. Ein Informationswert ist nicht der Geschäftsprozess. Der Prozess "Gehaltsabrechnung" verarbeitet den Informationswert "Gehaltsdaten" und verknüpft beide miteinander, ist aber selbst etwas anderes - eine Tätigkeit, kein Schutzgegenstand.

Eine pragmatische Daumenregel: Lassen sich zwei Datensammlungen mit unterschiedlichem Schutzbedarf oder unterschiedlicher Klassifikation belegen, sind es zwei Informationswerte. Lassen sie sich fachlich klar trennen (Marketing-Bilder vs. Bewerbungsunterlagen), sind es zwei. Sind sie inhaltlich identisch und unterscheiden sich nur im Speicherort, ist es ein Informationswert mit zwei Asset-Verknüpfungen.

Lebenszyklus eines Informationswerts

Ein Informationswert durchläuft im audatis MANAGER einen schlanken Lebenszyklus: anlegen, klassifizieren, Schutzbedarf bewerten, mit Assets und VVT verknüpfen, optional in den Prüfworkflow geben, regelmässig wiederbewerten. Archivierung ist reversibel; eine Löschung ist endgültig und sollte erst erfolgen, wenn keine VVT-Verknüpfung mehr besteht. Das Modul warnt nicht zwingend in jedem Fall - prüfen Sie deshalb vor jeder Löschung manuell die Verknüpfungs-Spalten, insbesondere GP/VT und Assets.

Tipp: Audit-Relevanz

Bei der Wirksamkeitsprüfung des ISMS prüft ein Auditor häufig die Inventar-Qualität. Erwartet wird ein vollständiges, aktuelles Verzeichnis der Informationswerte, eine nachvollziehbare Schutzbedarfsbegründung pro Eintrag und eine konsistente Verknüpfung mit den Assets, auf denen die Informationen verarbeitet werden. Fehlende Begründungen, leere Personenbezugs-Marker bei offensichtlich personenbezogenen Daten oder verwaiste Informationswerte ohne Asset-Verknüpfung sind die typischen Fundstellen.

Typische Stolperfallen

Schutzbedarfs-Begründungen als Floskel. "Personenbezogene Daten - daher hoch" ist keine Begründung. Die saubere Variante nennt das konkrete Schadensszenario: "Veröffentlichung würde Reputationsschaden und arbeitsrechtliche Folgen auslösen", "Manipulation würde zu falschen Lohnzahlungen führen". Eine Begründung sollte in einem Satz das konkrete Worst-Case-Szenario beschreiben. Wer die Begründung später für ein Risiko-Assessment verwendet, profitiert von dieser Disziplin doppelt.

Personenbezug ohne Art.-9-Prüfung. Wer den Haken bei Personenbezug setzt, sollte sich die Folgefrage stellen: Sind besondere Kategorien dabei? AU-Bescheinigungen, Gesundheitsdaten, Religionszugehörigkeit oder Gewerkschaftsmitgliedschaft sind im normalen HR-Umfeld häufig versteckt enthalten. Wer Art. 9 unbemerkt liegen lässt, riskiert, dass die DSFA-Pflicht und die erhöhten Anforderungen aus Art. 9 Abs. 2 DSGVO übersehen werden.

Schutzbedarfs-Updates ohne Verknüpfungs-Check. Wenn Sie einen Informationswert von C = hoch auf C = sehr hoch hochstufen, vererbt sich das automatisch an alle verknüpften Assets. Genau hier lohnt eine kurze Sichtprüfung: Sind alle dort verknüpften Assets diesem neuen Niveau gewachsen? Häufig zeigt sich Handlungsbedarf in den TOM, die jetzt einer höheren Schutzanforderung genügen müssen. Der MANAGER vererbt, er korrigiert nicht.

Was Sie als Nächstes lesen sollten

• Konzept: Assets
• Konzept: TOM
• Modul: Daten und Informationen
• Modul: Assetmananagement