ASST – Informationen und Assets
Katalogstand: 24. September 2026 — Quelle: BSI Stand-der-Technik-Bibliothek.
Eine Anforderung von dieser Seite zitieren
Maßgeblich ist immer das Original, nicht diese Aufbereitung. Zitierfähig ist: BSI, Anwenderkatalog Grundschutz++, Version 2026-09-24, Dokument-ID ebe77c16-3ddc-42ce-8d53-eff5b6e23334 (RFC 9562), Anforderung <ID> — wobei die ID die Kennung neben der jeweiligen Überschrift ist, etwa GC.5.1.1. Sie bleibt stabil, auch wenn das BSI eine Formulierung ändert.
Im Rahmen der IT-Komponenten stellt das Asset Management sicher, dass die IT-Komponenten erfasst und inventarisiert werden. Hierbei geht es darum eine Übersicht, über relevante “Assets”, wie Server, Clients, Netzwerkkomponenten sowie auch Datenträger sowie deren Verantwortlichkeiten, Besitzer oder auch Produktlebenszyklus zu haben. Des Weiteren soll im Rahmen des Asset Management auch die Ist-Dokumentation der Komponenten (z.B. Konfiguration, Patch-Level, Kritikalitätsstufen) erfasst werden. Während die Praktik “Konfiguration” die Parameter einer IT-Komponenten betrachtet und IT-Betrieb die Vorgehensweisen zu Wartung und Pflege von IT-Komponenten, betrachtet Asset Management die Übersicht und Dokumentation aller IT-Komponenten.
ASST.1 Grundlagen
Abschnitt betitelt „ASST.1 Grundlagen“ASST.1.1 – Verfahren und Regelungen
Abschnitt betitelt „ASST.1.1 – Verfahren und Regelungen“Informationen und Assets MUSS Verfahren und Regelungen zum Management von Informationen und damit verbundener Assets verankern.
Informationsmanagement ist der systematische Umgang mit Informationen während ihres gesamten Lebenszyklus, einschließlich von Regelungen, Prozessen und technischen Verfahren zur Erhebung, Verarbeitung, Speicherung, sowie Löschung und Vernichtung. Dazu gehören z.B. Schutzbedarf, Verarbeitung in den Geschäftsprozessen, Aufbewahrungs- und Löschfristen. Die bei der Festlegung des Verfahrens im Einzelnen zu berücksichtigenden Inhalte ergeben sich aus den Anforderungen dieser Praktik.
ASST.1.1.1 – Dokumentation
Abschnitt betitelt „ASST.1.1.1 – Dokumentation“Informationen und Assets MUSS die Verfahren und Regelungen dokumentieren.
Ohne eine Dokumentation könnte die Einhaltung der Verfahren und Regelungen von der Tagesform oder dem individuellen Wissen einzelner Mitarbeiter abhängen, was zu inkonsistenten Entscheidungen und Fehlern führen könnte; insbesondere beim Ausscheiden eines langjährigen Administrators könnte wertvolles prozessuales Wissen verloren gehen. Eine klare Dokumentation sichert die Verbindlichkeit und Wiederholbarkeit und dient als unverzichtbare Grundlage für die Einarbeitung neuer Kollegen, für die Durchführung von Audits und zur einheitlichen Anwendung der Regeln in der gesamten Institution. Die Dokumentation kann in einem eigenständigen Dokument als Richtlinie erfolgen, aber auch als Abschnitt in einem bereits bestehenden Dokument oder über die digital strukturiere Erfassung von Maßnahmen zur Umsetzung der Anforderungen, etwa über eine Software zum Management der Informationssicherheit. Sinnvoll ist es Ort und Struktur der Dokumentation an der jeweiligen Zielgruppe, d.h. den für das Management und die Umsetzung verantwortlichen Personen oder Rollen, auszurichten.
ASST.1.1.2 – Zuweisung der Aufgaben
Abschnitt betitelt „ASST.1.1.2 – Zuweisung der Aufgaben“Informationen und Assets MUSS die mit den Verfahren und Regelungen verbundenen Aufgaben [zuständigen Personen oder Rollen] zuweisen.
Die Zuweisung von Aufgaben bezeichnet die eindeutige und verbindliche Übertragung von konkreten Tätigkeiten und Verantwortlichkeiten des Änderungsprozesses, wie etwa die Risikobewertung, die technische Umsetzung oder die finale Freigabe, an definierte Stellen in der Institution. Der Sinn dieser Vorschrift ist es, die Verantwortlichkeit (“Accountability”) für jeden einzelnen Schritt im Prozess klarzustellen. Ohne eine solche Zuweisung könnten kritische Prüfungen unterbleiben, weil sich niemand explizit zuständig fühlt, was wiederum die Wahrscheinlichkeit fehlgeschlagener Änderungen erhöht. Eine klare Regelung kann sicherstellen, dass keine Aufgaben übersehen werden und jede Tätigkeit von einer dafür qualifizierten und befugten Stelle ausgeführt wird, was die Prozesssicherheit signifikant erhöht. Eine bewährte Methode zur Umsetzung ist die Erstellung einer RACI-Matrix (Responsible, Accountable, Consulted, Informed), die tabellarisch für jeden Prozessschritt darstellt, wer für die Durchführung verantwortlich ist, wer die Gesamtverantwortung trägt, wer zu konsultieren und wer zu informieren ist. Diese Zuständigkeiten können auch direkt in einem Workflow- oder Ticketsystem abgebildet werden, sodass Aufgaben, wie beispielsweise Genehmigungsschritte, automatisch an die richtige Gruppe oder Person weitergeleitet werden. Sinnvoll ist es die Zuweisung anhand von Rollen (z.B. “Anwendungsverantwortlicher”, “Netzwerkadministrator”, “Change Manager”) vorzunehmen, statt an konkrete Personen. Dieser Ansatz stellt sicher, dass die Prozesse auch bei Personalwechseln stabil weiterlaufen, da die Zuständigkeit an die Funktion und nicht an das Individuum gebunden ist.
ASST.1.1.3 – Bekanntgabe
Abschnitt betitelt „ASST.1.1.3 – Bekanntgabe“Informationen und Assets MUSS die zuständigen Personen oder Rollen über die Verfahren und Regelungen informieren.
Wenn die Zuständigen die etablierten Verfahren nicht kennen, besteht die Gefahr, dass diese – sei es aus Unwissenheit oder Bequemlichkeit – umgangen werden, was die Schutzwirkung des gesamten Managementsystems untergräbt. So könnte ein neuer Systemadministrator eine weitreichende Konfigurationsänderung vornehmen, ohne den vorgeschriebenen Genehmigungsprozess zu durchlaufen, was zu einem unbemerkten Sicherheitsrisiko führen könnte. Eine gezielte Information kann hingegen die Akzeptanz der Regelungen fördern und sicherstellen, dass alle Beteiligten ihre Rolle im Prozess verstehen und die Abläufe korrekt anwenden. Zur Umsetzung ist es sinnvoll die Dokumentation im Rahmen eines Onboarding-Prozesses bekanntzugeben und bei allen Änderungen eine automtatische Benachrichtigung aller zuständigen Personen oder Rollen anzustoßen.
ASST.1.2 – Regelmäßige Überprüfung
Abschnitt betitelt „ASST.1.2 – Regelmäßige Überprüfung“Informationen und Assets MUSS die Verfahren und Regelungen [regelmäßig] und anlassbezogen auf Aktualität überprüfen.
Eine geplante Überprüfung der etablierten Verfahren und Regelungen dient dazu festzustellen, ob diese noch wirksam, effizient und an die aktuellen Gegebenheiten angepasst sind. Eine anlassbezogene Überprüfung wird durch spezifische Ereignisse ausgelöst, wie etwa einen schwerwiegenden Sicherheitsvorfall, eine strategische Neuausrichtung der IT oder neue gesetzliche Anforderungen. Der Zweck dieser Anforderung ist es, die kontinuierliche Verbesserung und Anpassungsfähigkeit des Prozesses sicherzustellen, da veraltete Regelungen neuen technologischen Entwicklungen oder Bedrohungen nicht mehr gerecht werden könnten; ein vor Jahren für monolithische Anwendungen konzipierter Prozess ist beispielsweise für agile Entwicklungsmethoden oder Microservice-Architekturen ungeeignet. Die regelmäßige Überprüfung kann die Effektivität des Sicherheitsmanagements langfristig aufrechterhalten und die Resilienz der Institution stärken.
ASST.2 Inventarisierung
Abschnitt betitelt „ASST.2 Inventarisierung“ASST.2.1 – Inventar der Informationen
Abschnitt betitelt „ASST.2.1 – Inventar der Informationen“Informationen und Assets SOLLTE ein Inventar der Informationen und damit verbundener Assets dokumentieren.
Um die Informationssicherheit zu schützen ist es erforderlich, die zu schützenden Werte systematisch zu erfassen und ihre Verwendung über den gesamten Lebenszyklus nachzuhalten. Sinnvoll ist es hierbei, den Detaillierungsgrad des Inventars angepasst an Schutzbedarf und Risikoprofil des Informationsverbundes zu wählen. Das Inventar kann eine Übersicht der für Geschäftsprozesse relevanten Kategorien von schützenswerten Informationen, z.B. für Kunden Vor- und Nachname, Adresse, IBAN, Telefonnummer, Kundenkennwort als Grundlage haben. Es muss sich allerdings nicht um eine einzige Liste von Informationen und Assets handeln. Um eine leichtere, automatische Pflege des Inventars zu ermöglichen ist es vielmehr sinnvoll, eine Reihe dynamischer Inventare oder Datenbestände möglichst nahe an der Quelle der Informationen zu verwenden, z.B. eine Verzeichnisdatenbank für Zugangskonten und Systeme, eine Anwendung zum Assetmanagement für physische Assets, sowie Dateisysteme oder Datenbanken für einzelne Dateien und Daten. Falls ein datenschutzrechtliches Verarbeitungsverzeichnis für die Erfassung von personenbezogenen Daten besteht, kann es ebenfalls in das Inventar einbezogen werden. Für physische Dokumente kann ein Aktenbestandsverzeichnis eingesetzt werden. Zur Erfassung von Netzen siehe Praktik Architektur. Zur Erfassung von Identitäten, Zugangskonten und Berechtigungen siehe Praktik Berechtigung. Für kurzlebige Informationen, z.B. virtuelle Maschinen, nur on-demand automatisch eingerichtet und wieder gelöscht werden oder händische Notizen, die nicht systematisch verarbeitet werden, ist keine Inventur erforderlich. Für Details zum IT-Assetmanagement siehe ISO/IEC 19770-1.
ASST.2.1.1 – Informationsverantwortung
Abschnitt betitelt „ASST.2.1.1 – Informationsverantwortung“Informationen und Assets für Daten SOLLTE die Zuständigkeit für deren Verarbeitung [einer zuständigen Person oder Rolle] zuweisen.
Hiermit ist das Eigentum oder die institutionsinterne Zuständigkeit für die Nutzung und den damit einhergehenden Schutz der jeweiligen Informationen und Assets (Asset Ownership) gemeint. Klare Zuweisungen stellen sicher, dass den Beteiligten nicht nur ihre prozessualen Aufgaben, sondern auch ihre Zuständigkeit für die konkreten Informationen bewusst und die damit verbundenen Pflichten bewusst sind. Dies kann durch dezentrales Nachhalten der Verantwortung nachgehalten werden. Alternativ kann auch eine Gruppierung der Informationen nach Assets wie Anwendungen oder Diensten umgesetzt werden, so dass die Zuständigen für das Asset dadurch auch die Zuständigkeit für die Informationen enthalten, die dort verarbeitet werden.
ASST.2.2 – Inventar der Systeme
Abschnitt betitelt „ASST.2.2 – Inventar der Systeme“| IND.1.A4-UA.2 | überschneidet sich mit |
Informationen und Assets SOLLTE ein Inventar der IT-Systeme einschließlich Identifikationsbezeichnung und letztem bekannten Verbleib dokumentieren.
Hierbei sind neben physischen Endgeräten auch Hostsysteme, virtuelle Systeme, IoT-Geräte, Funkgeräte und Fahrzeuge relevant, wenn diese für die Verarbeitung von Daten aus dem Informationsverbund bestimmt sind. Als Identifikationsbezeichnung ist z.B. die Identifikationsnummer gemeint. Hierzu können z.B. eine Gerätenummer, Hardware-MAC-Adresse oder ein DNS-Name zählen, anhand derer das System eindeutig und nachvollziehbar identifiziert wird. Mit Verbleib ist hier z.B. der physische Standort, die Person, das Virtualisierungssystem oder die Netzadresse gemeint, wo das IT-System zu finden ist. Kann durch Integration in das Inventar der Informationen umgesetzt werden. Ein Asset-Inventar kann im einfachsten Fall händisch gepflegt werden. Empfehlenswert ist jedoch, auch automatisierte Systeme zum Erfassen von Asset-Inventar (z.B. Verzeichnisdienste, CMDB, DHCP-Logging, Passive Asset Discovery Tools, EDR oder MDM) einzusetzen.
ASST.2.2.1 – Aufdecken unautorisierter IT-Systeme
Abschnitt betitelt „ASST.2.2.1 – Aufdecken unautorisierter IT-Systeme“Informationen und Assets für Netze SOLLTE das Aufdecken unautorisierter IT-Systeme verankern.
Ziel ist sicherzustellen, dass keine unautorisierten Assets im Informationsverbund betrieben werden. Hierzu können z.B. aktive Netzscans (z.B. mit Nmap), passive Analysen des Netzwerkverkehrs oder spezielle Werkzeuge zur Erkennung von unbekannten WLAN-Access-Points (z.B. Kismet) genutzt werden. Zur Behandlung können die gefundenen IT-Systeme beispielsweise aus dem Netz entfernt, in eine Quarantäne verschoben oder nach Überprüfung autorisiert werden.
ASST.2.3 – Inventar der Anwendungen
Abschnitt betitelt „ASST.2.3 – Inventar der Anwendungen“| IND.1.A4-UA.2 | überschneidet sich mit |
| IND.1.A4-UA.3 | überschneidet sich mit |
Informationen und Assets SOLLTE ein Inventar der Anwendungen einschließlich Produktname, Versionsstand, Herkunft und Lizenzierung dokumentieren.
Ein zentrales Inventar der Anwendungen, oft auch als Application Inventory oder Teil des Software Asset Management (SAM) bezeichnet, dient als grundlegende, strukturierte Übersicht aller in der Institution eingesetzten Applikationen. Relevant sind dabei sowohl lokal installierte Anwendungen, als auch solche, die auf Cloud-Servern oder in verteilten Diensten betrieben werden. Hierbei beschreibt die Herkunft nicht nur den Hersteller, sondern auch den Lieferanten oder die Bezugsquelle, um die Vertrauenswürdigkeit bewerten zu können. Die Lizensierung erfasst die rechtliche Grundlage für die Nutzung, einschließlich des Lizenzmodells (z.B. pro Benutzer, pro Gerät, Abonnement), der Anzahl erworbener Lizenzen und deren Gültigkeitsdauer. Häufig sind weitere Angaben sinnvoll, z.B. Beschaffungs- und Installationszeitpunkt, URL, App-Store, Schnittstellen wie z.B. Cloud-APIs oder Datenexporte in andere Anwendungen, auch auf Dateiserver. Ohne eine solche Übersicht könnte die Institution unwissentlich Software mit bekannten, kritischen Schwachstellen einsetzen oder durch den Einsatz nicht lizenzierter Produkte hohe finanzielle und rechtliche Risiken eingehen. Ein gepflegtes Inventar kann hingegen bei neuen Sicherheitswarnungen eine schnelle Auswirkungsanalyse ermöglichen. Zur praktischen Umsetzung kann die Institution eine zentrale Liste, beispielsweise in einer Datenbank oder einem spezialisierten SAM-Tool, aufbauen, die durch verschiedene Quellen gespeist wird. Eine automatisierte Erfassung kann durch technische Werkzeuge erfolgen, wie zum Beispiel durch (1) Netzwerks-Scanner, die installierte Applikationen auf Endgeräten identifizieren, (2) Agenten-basierte Systeme, die kontinuierlich Software-Änderungen melden, oder (3) die Auswertung von Daten aus zentralen Software-Verteilungssystemen. Die Dokumentation kann auch durch eine Liste mit Verweisen umgesetzt werden (z.B. auf die Lizendateien und Schnittstellenkonfiguration).
ASST.2.3.1 – Autorisierung von Anwendungen
Abschnitt betitelt „ASST.2.3.1 – Autorisierung von Anwendungen“Informationen und Assets für IT-Systeme SOLLTE die Nutzung von Anwendungen auf diesen durch [eine zuständige Person oder Rolle] autorisieren.
Der Sinn dieser Regelung liegt in der Minimierung von Risiken, die durch unkontrollierte Nutzung entstehen. Durch nicht autorisierte Anwendungen könnte beispielsweise Schadsoftware in die Systeme der Institution eingeschleust, könnten durch Sicherheitslücken in veralteter Software Angriffsvektoren geöffnet oder könnten durch den Einsatz nicht konformer Tools sensible Informationen unkontrolliert abfließen. Ein strukturierter Autorisierungsprozess kann somit die Integrität der IT-Systeme wahren und sicherstellen, dass nur geprüfte, für den Geschäftszweck erforderliche und aus rechtlicher Sicht unbedenkliche Anwendungen zum Einsatz kommen, was die gesamte Angriffsfläche der Institution signifikant reduziert. Relevant sind dabei sowohl lokal installierte Anwendungen, als auch solche, die auf Cloud-Servern oder in verteilten Diensten betrieben werden. Je nach Geschäftsprozessen oder Risikoprofil kann die Autorisierung einzeln für jedes System und jede Anwendung, oder für bestimmte Kategorien von Systemen oder Anwendungen vorgenommen werden (z.B. “Alle Office-Produkte eines bestimmten Herstellers auf Notebooks mit einem bestimmten Betriebssystem). Hierbei ist es sinnvoll, Standard-Anwendungen zu bestimmen, die für alle Nutzenden freigegeben sind und die Verwendung darüber hinausgehender Anwendungen pro Nutzer oder Organisationseinheit zu autorisieren.
ASST.2.3.2 – Software Bill of Materials (SBOM)
Abschnitt betitelt „ASST.2.3.2 – Software Bill of Materials (SBOM)“Informationen und Assets für Anwendungen SOLLTE die Software Bill of Materials (SBOM) dokumentieren.
Eine Software Bill of Materials (SBOM) ist in diesem Zusammenhang eine strukturierte Liste aller Komponenten, Bibliotheken und Abhängigkeiten, die in einer Anwendung enthalten sind, einschließlich ihrer Versionen und Herkunft. Sie kann dabei sowohl Open-Source- als auch proprietäre Bestandteile erfassen und in maschinenlesbaren Formaten (z. B. SPDX, CycloneDX) vorliegen. Der Zweck dieser Dokumentation liegt darin, Transparenz über die eingesetzten Softwarebestandteile zu schaffen, sodass Abhängigkeiten, potenzielle Schwachstellen oder veraltete Komponenten nachvollziehbar bleiben. Ohne diese Transparenz könnte es bei Sicherheitsvorfällen, Lizenzkonflikten oder fehlender Wartbarkeit zu erheblichen Problemen kommen, während eine gepflegte SBOM die schnelle Identifikation von Risiken, die Minimierung von Vendor Lock-in und die Nachvollziehbarkeit der Software-Lieferkette unterstützen kann. Hierzu kann die BSI TR-03183-2 verwendet werden.
ASST.2.3.2.1 – Software Discovery
Abschnitt betitelt „ASST.2.3.2.1 – Software Discovery“Informationen und Assets KANN die Aktualität des Inventars der Anwendungen durch ein automatisiertes Verfahren [regelmäßig oder bei Änderungen] überprüfen.
Die automatische Aktualisierung des Anwendungsinventars (etwa bei Installationen, Konfigurationsänderungen und Deinstallationen) dient in erster Linie der vollständigen Transparenz über die IT-Landschaft. Ein aktuelles Anwendungsinventar kann als Grundlage für Compliance-Nachweise, Lizenzmanagement und Schwachstellenanalysen dienen. Die Automatisierung dieses Prozesses verringert dabei den manuellen Verwaltungsaufwand und erhöht die Datenqualität, da menschliche Fehler oder Versäumnisse bei der Dokumentation vermieden werden können. Konkrete Anwendungsfälle können die automatische Erfassung einer neu installierten ERP-Software im Inventar, die Dokumentation einer Konfigurationsänderung an einer Firewall-Anwendung oder die Entfernung einer nicht mehr genutzten Datenbanksoftware aus dem Inventar sein. Auch Updates von Anwendungen, Änderungen an Zugriffsberechtigungen oder Konfigurationsanpassungen aufgrund neuer Sicherheitsanforderungen können als relevante Ereignisse für eine Inventaraktualisierung betrachtet werden. Für die Umsetzung können Software Asset Management (SAM) Tools eingesetzt werden, die über Agenten oder regelmäßige Netzwerk-Scans Änderungen erkennen. Eine Alternative kann die Integration von Deployment- und Konfigurationsmanagement-Systemen mit der CMDB (Configuration Management Database) sein, wodurch jede Änderung automatisch im zentralen Inventar gespiegelt wird. Die Implementierung von Event-Triggern in der IT-Infrastruktur kann ebenfalls dazu beitragen, dass bei definierten Ereignissen eine sofortige Inventaraktualisierung ausgelöst wird. Einen hohen Mehrwert für alle Sicherheitsbereiche kann es haben, Inventardaten aus verschiedenen Quellen automatisiert miteinander abzugleichen, z.B. aus Verzeichnisdiensten, AMDB, EDR und CMDB. Eine regelmäßige Validierung der Prozesse durch Stichprobenkontrollen kann dabei helfen, die Vollständigkeit und Genauigkeit der automatisierten Inventarisierung zu gewährleisten.
ASST.2.4 – Klassifizierung
Abschnitt betitelt „ASST.2.4 – Klassifizierung“Informationen und Assets für Daten SOLLTE diese einer Schutzbedarfsklasse zuweisen.
Klassifizierung dient dazu, Daten entsprechend ihrer Schutzbedürftigkeit systematisch zu ordnen, um angemessene Schutzmaßnahmen zielgerichtet umzusetzen und Risiken effektiv zu reduzieren. Unter Klassifizierung versteht man dabei die Einteilung von Daten in Kategorien, etwa “öffentlich”, “intern”, “vertraulich” oder “Verschlussache - Nur für den Dienstgebrauch”. Beispielsweise ist eine öffentlich zugängliche Marketingbroschüre weniger sensibel als personenbezogene Kundendaten, Betriebs- und Geschäftsgeheimnisse oder staatliche Verschlusssachen. Anzahl der Klassen und Umfang der Beschreibungen können sich an den ermittelten Risiken und der Menge der verarbeiteten Informationen orientieren. Die Kriterien zur Klassifizierung können sich daran orientieren, mit welchen Schäden eine Kompromittierung der Vertraulichkeit, Integrität oder Verfügbarkeit verbunden wäre, z.B. geschätzte Umsatzverluste, Gefahr für die Allgemeinheit, Schädigung der Rechte und Freiheiten betroffener Personen. Für Assets ist es sinnvoll, diese im Einklang mit der Klassifikation der Informationen ebenfalls in Klassen zu unterteilen, für deren Verarbeitung sie gebraucht werden. Je nach Aufgaben der Institution und Arten von verarbeiteten Informationen bietet es sich an, ein bestehendes Klassifikationsschema 1:1 zu verwenden - etwa das Schema der Verschlusssachenanweisung (VSA) - oder ein eigenes Schema zu erstellen, in dem mehrere bestehende Schemata auf die eigenentwickelten Klassen abgebildet werden.
ASST.3 Regelungen zum Gebrauch
Abschnitt betitelt „ASST.3 Regelungen zum Gebrauch“ASST.3.1 – Nutzungsvereinbarungen
Abschnitt betitelt „ASST.3.1 – Nutzungsvereinbarungen“Informationen und Assets für Nutzende SOLLTE diese zu den Regelungen der Nutzung von Informationen und anderen Assets anweisen.
Wenn Nutzende nicht angewiesen werden bestimmte Nutzungsregelungen einzuhalten, dann könnte es zu ungewollten Verstößen gegen die Sicherheitsverfahren kommen. Auch Maßregelungen bei Verstößen werden erschwert, wenn unklar ist, ob Verstöße für die Nutzenden vorher als solche erkennbar waren. Dies gilt insbesondere für externe Personen, die nur durch die Nutzung von Assets mit den Regelungen in Berührung kommen könnten, z.B. Kunden oder Drittunternehmen. Die konkreten Regelungen ergeben sich aus den Maßnahmen zur Umsetzung der anderen Anforderungen dieser Praktik und den Anforderungen zur Sensibilisierung.
ASST.3.1.1 – Weitergabe nur bei Erforderlichkeit
Abschnitt betitelt „ASST.3.1.1 – Weitergabe nur bei Erforderlichkeit“Informationen und Assets für Nutzende SOLLTE zur Weitergabe von Informationen nur bei Erforderlichkeit anweisen.
Das Need-to-Know-Prinzip ist ein Sicherheitskonzept, das den Zugriff auf Informationen auf das absolut notwendige Maß beschränkt. Es besagt, dass Personen nur dann Zugang zu bestimmten Daten enthalten, wenn diese Informationen für die Erfüllung ihrer konkreten Aufgaben erforderlich sind. Ziel ist es, das Risiko von Datenmissbrauch, -verlust oder unbefugtem Zugriff zu minimieren.
ASST.3.2 – Entfernung nicht erforderlicher Rest- oder Zusatzdaten
Abschnitt betitelt „ASST.3.2 – Entfernung nicht erforderlicher Rest- oder Zusatzdaten“Informationen und Assets für Daten SOLLTE die Entfernung nicht erforderlicher Rest- oder Zusatzdaten verankern.
Hierunter können z.B. Metainformationen wie Bearbeitername oder Geostandort fallen. Handelt es sich um strukturierte Daten, so ist eine automatisierte Entfernung leicht möglich. Für unstrukturierte Daten hat sich eine Kombination aus automatischer Filterung / Regex und manueller Überprüfung bewährt.
ASST.3.3 – Kennzeichnung
Abschnitt betitelt „ASST.3.3 – Kennzeichnung“Informationen und Assets SOLLTE die Kennzeichnung von Informationen verankern.
Kennzeichnungen helfen dabei sicherzustellen, dass vertrauliche, personenbezogene oder besonders kritische Daten im gesamten Lebenszyklus angemessen behandelt werden – von der Erstellung über die Verarbeitung bis hin zur Archivierung oder Löschung. Hierzu gehört sowohl die Kennzeichnung physikalischer Systeme oder Speichermedien als auch die virtuelle Kennzeichnung, z.B. durch Metadaten oder die Kopfzeile eines Dokumentes. Eine klare Kennzeichnung kann dazu beitragen, unbeabsichtigte Offenlegung, unsachgemäße Weitergabe oder unsichere Verarbeitung zu vermeiden, die Sensibilisierung für den Umgang mit verschiedenen Informationsarten fördern und rechtlichen oder regulatorischen Anforderungen (z. B. DSGVO, Geheimschutz) Rechnung tragen. Beispiele sind Informationen, die einer bestimmten Schutzbedarfsklasse (z. B. „vertraulich“, „intern“) zugeordnet sind. Auch personenbezogene Daten, Forschungsergebnisse, Finanzinformationen, Sicherheitskonzepte oder technische Spezifikationen können einer Kennzeichnungspflicht unterliegen. Die Art der Kennzeichnung kann visuell erfolgen, etwa durch Wasserzeichen, farbige Markierungen, Aufkleber, sowie Kopf-/Fußzeilen oder Metadaten in Dateien. Wichtig ist, dass die Kennzeichnung verständlich, konsistent und leicht erkennbar ist, um ihre Schutzwirkung zu entfalten. Zur Umsetzung ist es nicht erforderlich, dass alle Daten, Systeme oder Speichermedien gekennzeichnet sind sondern nur solche, deren Risikoprofil eine solche Kennzeichnung erforderlich macht - hier ist insbesondere die Vertraulichkeit oder Verfügbarkeit relevant. Dokumentvorlagen, automatisierte Klassifizierungsfunktionen in gängigen Office-Programmen oder Richtlinien in einem DMS können helfen die Einhaltung zu gewährleisten.
ASST.3.4 – Kennzeichnung ohne vertrauliche Daten
Abschnitt betitelt „ASST.3.4 – Kennzeichnung ohne vertrauliche Daten“Informationen und Assets für IT-Systeme SOLLTE Kennzeichnung ohne vertrauliche Daten verankern.
Enthalten Kennzeichnungen vertrauliche Daten wie den Namen des zugeordneten Mitarbeiters, des Standortes, der Netzstruktur oder der Abteilung, so könnten diese Angaben von Angreifern ausgelesen werden, z.B. über das Netz, per Bluetooth oder durch physisches Ablesen. Die so abgeflossenen Daten könnten Angreifer zur weiteren Ausforschung der Institution oder des Zugangs zu Daten missbrauchen.
ASST.3.5 – Tainting
Abschnitt betitelt „ASST.3.5 – Tainting“Informationen und Assets für Daten KANN eine Markierung durch eingebettete Daten oder Funktionen zur Wiedererkennung zuweisen.
Zielt darauf ab, die Nachverfolgbarkeit und Kontextbindung von Daten zu ermöglichen, insbesondere in komplexen IT-Systemen, in denen Daten über viele Verarbeitungsschritte hinweg genutzt, kombiniert oder verteilt werden. Durch die Einbettung spezifischer, erkenntlicher Merkmale (z.B. Metadaten, Marker oder Funktionsventhalten) kann ein Datensatz identifizierbar gemacht werden, ohne dass seine Funktion oder Nutzbarkeit wesentlich eingeschränkt wird. Dies kann bei der Erkennung unerlaubter Datenweitergaben, der Nachverfolgung von Datenflüssen oder bei Sicherheitsanalysen hilfreich sein, insbesondere wenn potenziell sensible oder schützenswerte Daten im Spiel sind. Für welche Daten Tainting gezielt eingesetzt wird kann sich nach deren Klassifizierung oder einer spezifischen Risikoanalyse richten. Beispiele für Tainting-Mechanismen können sein: das Einfügen eines unsichtbaren Wasserzeichens in ein Dokument, das Anhängen kryptografisch prüfbarer Metadaten an Datensätze, Dummy-Datensätze oder das Verwenden von Datencontainern, die sich beim Zugriff oder bei der Weitergabe protokollierend venthalten. Auch das Markieren von Datenbankeinträgen mit zusätzlichen Attributen, die Rückschlüsse auf Herkunft, Vertrauensstufe oder Kontext erlauben, kann eine Form des Taintings darstellen. Ebenso kann bei Programmcode eine Markierung durch sogenannte Taint-Tracking-Systeme erfolgen, die überwachen, welche Eingaben in sicherheitskritische Operationen einfließen. Für die Umsetzung kann der Einsatz strukturierter Datenformate (wie XML oder JSON mit Markierungsfeldern), der Aufbau kontrollierter Datenflüsse mit Protokollierung oder das Nutzen von Middleware-Komponenten mit Tainting-Funktionalität in Betracht gezogen werden. Wichtig ist dabei, dass die Tainting-Informationen robust, interpretierbar und möglichst schwer entfernbar gestaltet werden, um ihre Wirksamkeit zu sichern. Die Wahl geeigneter Methoden hängt stark vom Anwendungskontext, den Schutzbedarfen und den bestehenden Systemarchitekturen ab.
ASST.3.6 – Verifikation
Abschnitt betitelt „ASST.3.6 – Verifikation“Informationen und Assets für Informationen KANN die Korrektheit anhand anderer Informationsquellen testen.
Wenn die Korrektheit bestimmter Informationen von hohen Bedeutung ist, hilft eine Verifikation aus zweiter Quelle dabei, fundierte und belastbare Entscheidungen in sicherheitsrelevanten Situationen treffen zu können. Durch Verifikation wird das Risiko verringert, dass Fehlinformationen in Geschäftsprozessen oder dem Sicherheitsmanagement weiterverarbeitet werden und sich Fehler so fortsetzen oder Vorfälle übersehen werden. Sie kann insbesondere dazu beitragen, Fehlalarme zu erkennen, Täuschungsversuche (z.B. durch gefälschte Logdaten) zu identifizieren oder die Wirksamkeit von Gegenmaßnahmen zu bewerten. Die Anforderung stärkt somit die Integrität und Qualität der sicherheitsbezogenen Lagebewertung. Beispiele für Ereignisse können sicherheitsrelevante Systemmeldungen, Alarme aus Intrusion Detection Systemen (IDS), Hinweise auf Datenabflüsse oder ungewöhnliches Nutzerventhalten sein. Informationsquellen können externe Dienstleister, Zeugen, Sicherungskopien oder Sensoren in der physischen Sicherheit sein. Die Verifikation kann sich in solchen Fällen z.B. auf die Gegenprüfung eines IDS-Alarms durch Logdaten anderer Systeme oder durch Replizierbarkeit des Ereignisses in einer Testumgebung beziehen. In der Praxis kann eine Verifikation unter anderem durch Korrelation mehrerer unabhängiger Datenquellen erfolgen. Auch das Einführen von Plausibilitätsprüfungen, standardisierten Analyseverfahren oder temporären Reproduktionsversuchen kann hilfreich sein. Eine strukturierte Dokumentation der Informationsquellen und ihrer typischen Aussagekraft kann ebenfalls zur Umsetzung beitragen.
ASST.3.7 – Pseudonymisierung
Abschnitt betitelt „ASST.3.7 – Pseudonymisierung“Informationen und Assets für Informationen KANN die Pseudonymisierung vor der Weitergabe verankern.
Bei der Pseudonymisierung werden Informationen so verändert, dass sie für den Empfänger nicht mehr dem ursprünglichen Informationswert oder Datensatz zugeordnet werden können, ohne zusätzliche Informationen hinzuzuziehen. Die Weitergabe meint hier jegliche Form des Teilens von Informationen über die Grenzen des Informationsverbundes hinaus – etwa an externe Dienstleister, Behörden oder Partnerinstitutionen – unabhängig davon, ob dies elektronisch, schriftlich oder mündlich geschieht. Anwendungsbeispiele sind personenbezogene Daten oder institutionsinterne IP-Adressbereiche, die zu Diagnosezwecken herausgegeben oder zum Zugriff auf Cloud-Dienste von der Institution verwendet werden. Problematisch ist hierbei oft die funktionsenthaltende Pseudonymisierung, d.h. die Pseudonymisierung derart, dass es bei der beabsichtigten Verwendung zu keinen Problemen durch die Pseudonymisierung kommt. Typische Umsetzungsmaßnahmen können beinhalten: (1) den Einsatz technischer Pseudonymisierungsverfahren wie Hashing oder Tokenisierung, (2) die getrennte, zugriffsbeschränkte Speicherung von Zuordnungstabellen („mapping tables“) in gesicherten Datenräumen oder Datenbanken, und (3) den Einsatz kontrollierter Schlüsselverwaltung, die nur autorisierten Personen eine Re-Identifizierung erlaubt. Auch kann eine Pseudonymisierung in Prozessen oder Schnittstellen fest verankert werden, etwa durch automatisierte Filtermechanismen bei Exporten oder vor externen Übertragungen.
ASST.3.8 – Anonymisierung
Abschnitt betitelt „ASST.3.8 – Anonymisierung“Informationen und Assets für Informationen KANN die Anonymisierung vor der Weitergabe verankern.
Bei der Anonymisierung werden Informationen so verändert, dass sie für den Empfänger nicht mehr dem ursprünglichen Informationswert oder Datensatz zugeordnet werden können. Dabei werden gezielt rückverfolgbare Merkmale entfernt oder verfremdet, sodass eine Zuordnung zu einem bestimmten Informationswert der Institution (z.B. einer Person, Systemkonfiguration oder Zugangskonto) nicht mehr möglich ist. Davon abzugrenzen ist die Pseudonymisierung („pseudonymization“), bei der eine Identifizierbarkeit theoretisch weiterhin besteht, etwa durch separate Zuordnungstabellen oder Schlüssel. Die Weitergabe meint hier jegliche Form des Teilens von Informationen über die Grenzen des Informationsverbundes hinaus – etwa an externe Dienstleister, Behörden oder Partnerinstitutionen – unabhängig davon, ob dies elektronisch, schriftlich oder mündlich geschieht. Beispiele sind die Bildung summarischer Statistiken aus personenbezogenen Daten oder die Ersetzung eines Gerätenamens durch eine zufällige Zeichenkette vor der Herausgabe zu Diagnosezwecken.
ASST.3.9 – Aktualisierung
Abschnitt betitelt „ASST.3.9 – Aktualisierung“Informationen und Assets für Daten KANN deren Aktualisierung verankern.
Wenn gespeicherte Daten nicht regelmäßig mit Veränderungen abgeglichen werden, nimmt das Risiko von Fehlern in den Daten zu. Ein Abgleich mit Quellen kann durch automatische Vergleichsprozesse (z.B. anhand von Checksummen) vorgenommen werden oder durch eine Versionsverwaltung erleichtert werden.
ASST.3.10 – Autorisierung von Datenlokationen
Abschnitt betitelt „ASST.3.10 – Autorisierung von Datenlokationen“Informationen und Assets für Daten SOLLTE Datenlokationen durch [eine zuständige Person oder Rolle] autorisieren.
Autorisierte Datenlokationen sind virtuelle oder physische Orte, an denen die Speicherung oder anderweitige Verarbeitung der jeweiligen Datenkategorie durch die Institution erlaubt wird. Physische Orten sind z.B. Serverstandorte in der EU, aber auch die organisatorische Regelung zu Standorten wie dem Mobile Arbeitsplatz oder Auslandsreisen außerhalb der EU gemeint. Regelungen könnten hier z.B. sein: “Verarbeitung als vertraulich markierter Daten nur innerhalb von Institutsgebäuden”, “Personenbezogene Daten nur innerhalb der EU”. Je nach Datenart bestehen auch häufig Compliance-Verpflichtungen (z.B. DSGVO, Staatenliste im Sinne von § 13 Abs. 1 Nr. 17 SÜG), durch die erlaubte Datenlokationen beschränkt sind. Virtuelle Datenlokationen (z.B. VoIP-Netz, dom0, Hauptgebäude) sind Verarbeitungssphären.
ASST.3.11 – Autorisierung von Systemen
Abschnitt betitelt „ASST.3.11 – Autorisierung von Systemen“Informationen und Assets für Daten SOLLTE für die Informationsverarbeitung verwendete Systeme durch [eine zuständige Person oder Rolle] autorisieren.
Autorisierte Systeme können einzeln oder als Kategorien von IT-Systemen und Peripherie benannt werden, auf denen bestimmte Daten verarbeitet werden dürfen. Hierzu gehört auch, welche Peripheriegeräte angeschlossen werden dürfen, z.B. z.B. keine Speicherung sensibler Erreichbarkeiten auf einem einfachen Mobiltelefon oder Verarbeitung hochvertraulicher Daten nur auf stationären Endgeräten. Relevant ist dabei auch, ob Bring Your Own Device (BYOD) untersagt oder unter bestimmten Voraussetzungen gestattet ist. Kann entweder einmalig für alle Daten, oder getrennt nach Datenkategorien (z.B. keine personenbezogenen Daten auf Ausleihgeräten) umgesetzt werden.
ASST.3.11.1 – Autorisierung von Peripheriegeräten
Abschnitt betitelt „ASST.3.11.1 – Autorisierung von Peripheriegeräten“Informationen und Assets für Daten SOLLTE auch Peripheriegeräte autorisieren.
Peripheriegeräte sind externe Hardware-Komponenten sowie virtuelle Geräte, die an IT-Systeme angeschlossen oder eingebunden werden, darunter USB-Sticks, externe Festplatten, Drucker, Kameras, Smartphones, Tablets, virtuelle Laufwerke, softwaredefinierte Netzwerkadapter und emulierte Hardware. Die Autorisierung solcher Geräte schützt vor Sicherheitsrisiken, da unkontrollierte Peripherie Malware einschleusen, Daten exfiltrieren oder als Einfallstor für Angriffe dienen kann; so kann ein privater USB-Datenträger Schadsoftware enthalten, die sich beim Anschluss ausbreitet, oder ein nicht autorisierter Drucker vertrauliche Dokumente in ungeschützten Bereichen ausgeben. Die Umsetzung erfolgt zweckmäßig über eine zentrale Geräteregistrierung, in der alle zulässigen Geräte mit eindeutigen Kennungen erfasst werden; abhängig vom Risikoprofil kann die Autorisierung gerätespezifisch oder für ganze Gerätegruppen erfolgen (etwa für alle beschafften Tastaturen und Mäuse). Administrative Prozesse umfassen ein Antragsverfahren für neue Peripheriegeräte mit Sicherheitsbewertung, die regelmäßige Überprüfung und Aktualisierung der Gerätelisten sowie die Definition von Gerätekategorien mit abgestuften Autorisierungsebenen, beispielsweise vollständig gesperrte USB-Ports für externe Nutzer, eingeschränkte Freigaben für Standardarbeitsplätze und erweiterte Berechtigungen für Administratoren. Technisch wird dies durch Device-Control-Lösungen unterstützt, die nur autorisierte Geräte anhand von Hardware-IDs, Herstellerzertifikaten oder digitalen Signaturen erkennen und freischalten; ergänzend erhöhen Logging-Mechanismen zur Nachverfolgung sämtlicher Peripheriegeräte-Aktivitäten die Transparenz und Auditierbarkeit der Prozesse. Die Autorisierung selbst erfolgt durch die Personen oder Rollen, die in der Organisation für die Freigabe der betreffenden Systeme verantwortlich sind.
ASST.3.12 – Autorisierung von Personen oder Institutionen
Abschnitt betitelt „ASST.3.12 – Autorisierung von Personen oder Institutionen“Informationen und Assets für Daten SOLLTE den Zugriff von Personen oder Institutionen im Einklang mit den zugehörigen Anforderungen zum Identitäts- und Berechtigungsmanagement autorisieren.
Ziel dieser Regelung ist es, sicherzustellen, dass nur berechtigte Stellen auf sensible Werte zugreifen, wodurch unautorisierte Einsichtnahme, Manipulation oder Missbrauch verhindert werden kann. Ohne eine klare Kopplung an Identitäts- und Berechtigungsmanagement könnte es zu unkontrollierten Datenabflüssen, Einsicht durch Dritte oder langfristigen Abhängigkeiten von bestimmten Dienstleistern kommen, die den Zugriff einseitig steuern könnten. Eine korrekte Umsetzung kann hingegen Transparenz schaffen und den Zugriff auf Informationen nachvollziehbar, reversibel und sicher gestalten. Umfasst sowohl die Autorisierung eigenen Personals, als auch die Autorisierung externer Dienstleister oder Partner. Die Formulierung “im Einklang mit den zugehörigen Anforderungen zum Identitäts- und Berechtigungsmanagement” bedeutet, dass die Autorisierung so erfolgt, wie in der Praktik Berechtigung (BER) festgelegt.
ASST.3.13 – Lagerung physischer Assets
Abschnitt betitelt „ASST.3.13 – Lagerung physischer Assets“Informationen und Assets für Administrierende SOLLTE zur Lagerung physischer Assets in einem dazu vorgesehenen Lager anweisen.
Lagerung meint hier die Aufbewahrung nicht an Nutzende ausgegebener physischer Assets. Die Lagerung kann in verschlossenen Lagerräumen, Schränken oder bei Dienstleistern erfolgen.
ASST.3.14 – Reserve physischer Assets
Abschnitt betitelt „ASST.3.14 – Reserve physischer Assets“Informationen und Assets SOLLTE eine Reserve physischer Assets verankern.
Die Beschaffung und Installation von Systemen und deren Peripherie nimmt gewöhnlich eine längere Zeit in Anspruch, weshalb es sinnvoll ist, Ersatzgeräte für Ausfälle bereitzuhalten. Die Menge der Ersatzgeräte reicht aus, wenn sie den voraussichtlichen Bedarf deckt, der bis zur Lieferung und Installation der nächsten Beschaffung vergeht. Der voraussichtliche Bedarf kann aus dem bisherigen Bedarf unter Anpassung an Veränderungen (z.B. Wachstum der Nutzerzahlen) berechnet werden. Typische Assets wären hier z.B. IT-Clients (Desktop PCs/Laptops), Smartphones oder andere häufig genutzte Endgeräte.
ASST.3.15 – Ausleihe physischer Assets
Abschnitt betitelt „ASST.3.15 – Ausleihe physischer Assets“Informationen und Assets KANN einen ausreichenden Ausleihbestand verankern.
Wenn bei bestimmten Ereignissen wie Auslandsreisen, Veranstaltungen oder Sicherheitsvorfällen die regulären Endgeräte nicht verwendet werden können (z.B. aufgrund der Regelungen zu Datenlokationen oder der Vorfallsbehandlung), dann ist es sinnvoll Endgeräte bereitzuhalten, die nur mit den für die Ereignisse notwendigen Anwendungen und Daten ausgestattet sind. Die Menge der Ausleihgeräte ist ausreichend, wenn sie den Bedarf deckt. Der Bedarf kann anhand einer Prognose ermittelt werden, die sich wiederum auf bekannte Statistiken (z.B. Anzahl der Nutzenden, Anzahl der Teilnehmer von Schulungsveranstaltungen, Anzahl Auslandsreisen pro Jahr) stützen kann.
ASST.4 Regelungen zum Transfer
Abschnitt betitelt „ASST.4 Regelungen zum Transfer“ASST.4.1 – Autorisierung von Schnittstellen
Abschnitt betitelt „ASST.4.1 – Autorisierung von Schnittstellen“Informationen und Assets für Daten KANN Schnittstellen, über die Informationen ausgetauscht werden, durch [eine zuständige Person oder Rolle] autorisieren.
Schnittstellen können hier sowohl physikalisch (z.B. Briefversand, regelmäßige Meetings an einem geschützten Ort) als auch virtuell (API, verschlüsselter Cloudspeicher) sein.
ASST.4.2 – Vertraulichkeit und Integrität beim Transport
Abschnitt betitelt „ASST.4.2 – Vertraulichkeit und Integrität beim Transport“| CON.10.A7-UA.1 | überschneidet sich mit |
| IND.2.1.A2-UA.2 | entspricht |
Informationen und Assets für Daten SOLLTE Vertraulichkeit und Integrität beim Transport verankern.
Transport meint hier sowohl die Datenübertragung per Netz als auch auf physischen Datenträgern (Sneakernet) oder den physischen Transport ganzer Systeme. Zur Umsetzung kann z.B. in Netzen die Transportverschlüsselung und -signierung von E-Mails, Ende-zu-Ende-Verschlüsselung mit PGP genutzt werden. Beim physischen Transport können die vorherige Verschlüsselung von Speichermedien, die Verwahrung von Assets an der Person, Verwahrungsprotokolle, manipulationssichere Verpackungen, Geolocation Tracking oder vertrauenswürdige Kuriere genutzt werden. Die Auswahl der Maßnahmen richtet sich nach dem Schutzbedarf der ausgetauschten Informationen und der Transportart.
ASST.4.3 – Autorisierung von Veröffentlichungen
Abschnitt betitelt „ASST.4.3 – Autorisierung von Veröffentlichungen“Informationen und Assets SOLLTE Veröffentlichungen durch [eine zuständige Person oder Rolle] autorisieren.
„Veröffentlichungen“ bezieht sich hier auf jede Form der öffentlichen oder externen Verbreitung von Informationen, sei es durch Pressemitteilungen, Social-Media-Beiträge, wissenschaftliche Publikationen, öffentliche Datensätze oder zur Erfüllung gesetzlicher Informationspflichten. Hierbei besteht das Risiko, dass vertrauliche Informationen unbeabsichtigt veröffentlicht werden. Kriterien zur Veröffentlichung können z.B. das Entfernen von Geschäftsgeheimnissen oder die Freigabe durch bestimmte Stellen innerhalb oder außerhalb der Institution sein. Der Hauptzweck dieser Anforderung ist die Schaffung einer Gatekeeping-Funktion, um den Informationsfluss zu steuern, der die Institution verlässt, und so das Risiko unbefugter oder schädlicher Offenlegungen zu mindern. Ohne diese Kontrolle könnte eine Institution versehentlich sensible Geschäftsdaten, geistiges Eigentum oder vertrauliche Kundeninformationen offenlegen, was zu schwerwiegendem Reputationsschaden, finanziellem Verlust oder rechtlichen Strafen führen könnte. So könnte ein nicht genehmigter Social-Media-Beitrag Details über ein noch nicht veröffentlichtes Produkt preisgeben, ein Forscher könnte versehentlich einen Datensatz mit vertraulichen Informationen veröffentlichen, oder ein Finanzbericht könnte vorzeitig veröffentlicht werden und Marktvolatilität verursachen. Ein sinnvoller Ansatz könnte die Einrichtung eines gestuften Genehmigungsprozesses sein, der auf der Sensibilität der Informationen basiert und sich am Konzept der Vertraulichkeitsanforderungen orientiert. Eine öffentliche Ankündigung von geringer Sensibilität erfordert möglicherweise nur die Genehmigung durch einen Abteilungsleiter, während ein Finanzbericht mit hohem Risiko die Unterschrift mehrerer Führungskräfte, einschließlich des Leiters der Rechtsabteilung und des CISO, erfordert. Um dies zu erleichtern, können Institutionen technische Maßnahmen ergreifen, wie z. B. ein digitales Workflow-System, in dem der Veröffentlichungsstatus eines Dokuments nachverfolgt und verwaltet wird. Dieses System könnte Funktionen umfassen wie: (1) automatisches Routing von Dokumenten an die entsprechenden Genehmiger, (2) eine sichere Überwachung aller Genehmigungen und Ablehnungen, und (3) ein zentrales Repository für alle genehmigten und veröffentlichten Materialien. Aus prozessualer Sicht ist es von Vorteil, eine Veröffentlichungs-Checkliste zu erstellen, die sicherstellt, dass alle relevanten rechtlichen und Compliance-Prüfungen vor der Veröffentlichung durchgeführt werden.
ASST.4.4 – Nachweis des Zugangs
Abschnitt betitelt „ASST.4.4 – Nachweis des Zugangs“Informationen und Assets für Daten KANN einen Nachweis des Zugangs protokollieren.
Ein Zugangsnachweis stellt sicher, dass bestimmte Nachrichten ihren Empfänger tatsächlich erreicht haben und dieser Zugang im Streitfall nachvollziehbar belegt werden kann. Dies ist insbesondere in rechtlich relevanten Kontexten oder bei Revisionen von Bedeutung – etwa wenn Fristen, Genehmigungen oder vertrauliche Informationen übermittelt werden. Kriterien können sich an der Nachvollziehbarkeit der Integrität der Informationen oder ihrer Rechtswirkung orientieren, z.B. wenn sie einen Vertragsabschluss oder die Bekanntgabe eines Verwaltungsaktes, auslösen. Beispiele hierfür sind arbeitsrechtlich relevante Dokumente wie Abmahnungen oder Kündigungen, Sicherheitsanweisungen, Änderungen an internen Richtlinien, Zugangsdaten zu sicherheitsrelevanten Systemen oder auch technische Anordnungen mit verbindlichem Charakter. Die Kriterien können zusammen mit anderen Kriterien dokumentiert sein, beispielsweise im Rahmen eines Informationssicherheitskonzepts oder Kommunikationsleitfadens. Die Umsetzung dieser Anforderung kann durch verschiedene technische und organisatorische Maßnahmen erfolgen. Dazu gehören u. a. die Nutzung von E-Mail-Systemen mit Empfangsbestätigung, das Verwenden von Systemprotokollen oder speziellen Portalen mit Zugriffsnachweis. Wichtig ist dabei, dass der Nachweis manipulationssicher gespeichert und nachvollziehbar archiviert wird – bis zum Ablauf einer definierten Aufbewahrungsfrist, z. B. drei oder fünf Jahre, je nach rechtlicher oder organisatorischer Vorgabe. Sinnvoll ist es hierbei nicht nur die Tatsache des Zugangs zu einem bestimmten Zeitpunkt sondern auch für den Nachweis relevante Inhalte zu dokumentieren, z.B. Titel, sowie Versand- und Zieladressen der Nachricht. Sie kann je nach Medium auch den Inhalt der Nachricht enthalten.
ASST.4.5 – Vereinbarungen zum Austausch
Abschnitt betitelt „ASST.4.5 – Vereinbarungen zum Austausch“Informationen und Assets für Daten SOLLTE Regelungen zum Transfer verankern.
Beispielsweise kann es für Geschäfts- und Betriebsgeheimnisse wie Patente sinnvoll sein, eine explizite Vertraulichkeitsvereinbarung abzuschließen, bevor genaue Informationen weitergegeben werden. Hierzu kann z.B. gehören nach welchen Kriterien ausgetausche Informationen zu klassifizieren sind oder wie in eine bestimme Klasse eingestufte Daten zu schützen oder verarbeiten sind. Die Vereinbarung über anzuwendende Sicherheitsanforderungen kann anhand von vorformulierten Vertragstexten erfolgen oder über den Austausch von Sicherheitsanforderungen in strukturierten Datenformaten wie OSCAL. Letzteres hat den Vorteil, dass weiterführende Daten etwa zum Umsetzungsstand ebenfalls leichter gepflegt und ausgetauscht werden können.
ASST.5 Wartung
Abschnitt betitelt „ASST.5 Wartung“ASST.5.1 – Wartungsbedarf dokumentieren
Abschnitt betitelt „ASST.5.1 – Wartungsbedarf dokumentieren“Informationen und Assets für IT-Systeme SOLLTE den Wartungsbedarf für Systemkomponenten und die zum Betrieb erforderliche Infrastruktur dokumentieren.
Wartungsbedarf meint die regelmäßig oder anlassbezogen erforderlichen Maßnahmen zur Instandhaltung, Aktualisierung und Funktionssicherung von Systemkomponenten und der Betriebsinfrastruktur eines IT-Systems. Unter Systemkomponenten sind hier sowohl Hardware-Elemente (Server, Netzwerkkomponenten, Speichergeräte) als auch Software-Elemente (Betriebssysteme, Middleware, Anwendungen) zu verstehen; die Infrastruktur umfasst unterstützende Einrichtungen wie Stromversorgung, Klimatisierung, Kommunikationsschnittstellen oder Brandabschottungen für Kabel- und Rohrdurchführungen. Ziel der Dokumentation ist es, einen strukturierten Überblick über alle Abhängigkeiten, Wartungszyklen und Zuständigkeiten zu schaffen, um sicherzustellen, dass Betrieb und Sicherheit des Systems über den gesamten Lebenszyklus hinweg gewährleistet bleiben. Die Dokumentation des Wartungsbedarfs kann verhindern, dass kritische Komponenten ungeplant ausfallen oder Sicherheitslücken durch versäumte Updates bestehen bleiben. Ohne klare Wartungsinformationen könnte beispielsweise ein Firmware-Update bei einer Netzkomponente übersehen werden, was Angreifern das Eindringen über bekannte Schwachstellen erleichtern könnte. Umgekehrt kann eine dokumentierte Wartungsplanung dazu beitragen, Systemverfügbarkeit und Integrität zu sichern, indem sie planbare Wartungsfenster und Zuständigkeiten ermöglicht. Durch das Zusammenführen der Herstellerangaben mit den vor Ort bekannten Rahmenbedingungen kann frühzeitig erkennbar werden, wann Eingriffe nötig sind, welche Abhängigkeiten bestehen und welche Fachkenntnisse oder Werkzeuge erforderlich sein können. Zum Ressourcenbedarf kann ebenso gehören, dass ein Testsystem bereitgestellt wird, dass administrative Zugänge vorbereitet werden oder dass ein Wartungsdienstleister während der Arbeiten abgesichert fernzugreifen kann. Für die praktische Umsetzung kann es hilfreich sein, einen zentralen Wartungskalender mit Ampel‑Logik zu führen, der sich aus dem Konfigurations‑ oder Asset‑Management speist. Eine Ticket‑ oder Change‑Management‑Lösung kann automatisch Termine auslösen, Erinnerungen versenden und Reports erzeugen.
ASST.5.2 – Geregelte Wartungen
Abschnitt betitelt „ASST.5.2 – Geregelte Wartungen“| OPS.1.1.1.A19-UA.1 | überschneidet sich mit |
Informationen und Assets für IT-Systeme SOLLTE die Wartung [regelmäßig oder prädiktiv] ausführen.
„Wartung“ bezeichnet hier sämtliche planmäßigen oder zustandsabhängigen Maßnahmen zur Erhaltung der Funktionsfähigkeit, Sicherheit und Integrität von IT-Systemen, Anwendungen und den zugehörigen physischen wie logischen Assets („maintenance“). Verschleißende Systeme und Infrastrukturen könnten zu Fehlerzuständen und hierdurch zu Ausfallzeiten und Sicherheitsrisiken führen. Das betrifft auch die für das IT-System verwendete Stromversorgung, USV, Klimatechnik, sowie Brandabschottungen für Kabel- und Rohrdurchführungen. Beispiele hierfür können vielfältig sein: Ein Server kann turnusmäßig mit Firmware‑Updates versorgt oder nach einer bestimmten Betriebsdauer auf Staubablagerungen überprüft werden; Netzwerkkomponenten können per Lifecycle‑Plan aktualisiert oder lüfterseitig gereinigt werden; USV‑Batterien können nach Herstellerempfehlung getauscht werden; Software‑Module können per Patch‑Management in ein Wartungsfenster eingeplant werden. Eine „regelmäßige Wartung“ bedeutet hierbei ein turnusmäßiges Vorgehen nach festen Zeitintervallen (Vorausbestimmte Instandhaltungsstrategie), während prädiktive Wartung den tatsächlichen Abnutzungs- oder Belastungszustand auswertet, um Eingriffe bedarfsgerecht zu planen (Prädiktive Instandhaltungsstrategie). Beide Ansätze verfolgen das Ziel, Sicherheits- und Betriebsrisiken zu minimieren, die aus dem Ausfall oder der Fehlfunktion technischer Komponenten resultieren könnten.
ASST.5.3 – Autorisierung von Wartungen
Abschnitt betitelt „ASST.5.3 – Autorisierung von Wartungen“Informationen und Assets für IT-Systeme KANN Wartungen durch [eine zuständige Person oder Rolle] autorisieren.
Wartung ist die planbare oder anlassbezogene Änderung an Komponenten (z. B. Patches, Konfigurationsänderungen, Hardwaretausch, Firmware-Updates). Dies betrifft auch den Transfers des Systems oder von Komponenten für Reparatur oder Austausch an einem anderen Ort. Unklare oder fehlende Freigaben für Wartungen könnten zu unkoordinierten Änderungen, ungeplanten Ausfällen, Datenverlust oder der Einschleusung von Schadcode durch interne wie externe Dienstleister führen; außerdem könnten unpassende Zeitfenster oder inkompatible Firmwarestände Vertraulichkeit, Integrität und Verfügbarkeit beeinträchtigen. Zur Umsetzung kann die Institution ein schlankes Freigabeverfahren gestalten, z.B. (1) ein standardisiertes Wartungs-Ticket mit Pflichtangaben (Asset-ID, Maßnahme, Risiko-Einschätzung, Zeitfenster, Back-out-Plan, Ansprechpartner), das über CMDB-Bezüge (Konfigurationsdatenbank) automatisch an Asset-/Service-Owner geroutet und dort freigegeben werden kann; (2) technische Gates, sodass produktive Änderungen erst im Status „autorisiert“ durch CI/CD-Pipelines (Build-/Deployment-Kette), Change-Flags oder Just-in-Time-Privilegien mit zeitlich begrenzten Admin-Konten ausgeführt werden können; (3) ein Katalog vordefinierter, niedrig-riskanter Standardwartungen (z. B. Signatur-Updates, agentenlose Log-Rotation), die vorab genehmigt und ohne Einzelfallprüfung ausgelöst werden können.
ASST.5.4 – Behandlung als Änderungen und Tests
Abschnitt betitelt „ASST.5.4 – Behandlung als Änderungen und Tests“Informationen und Assets für IT-Systeme SOLLTE zur Wartung erforderliche Änderungen im Einklang mit den Verfahren und Regelungen zum Management von Änderungen verankern.
Werden bei Wartungsarbeiten Änderungen vorgenommen, so sind die Verfahren und Regelungen zum Management von Änderungen auch hier anzuwenden. Ein nicht abgestimmter oder ungetesteter Eingriff könnte etwa zu Systemausfällen, Datenverlust oder dem Einbringen von Schwachstellen führen, während ein geordnetes Änderungsmanagement solche Risiken deutlich reduzieren kann. Sinnvoll ist oft ein kurzer Wartungsleitfaden, in dem typische Abläufe (z. B. Vorab‑Backup, Rollback‑Option, Dokumentation des Ergebnisses) hinterlegt werden. Auf diese Weise kann jede Wartung reproduzierbar, überprüfbar und ressourcenschonend gestaltet werden, ohne sich auf konkrete Herstellerprodukte festzulegen.
ASST.5.5 – Wartungsfenster
Abschnitt betitelt „ASST.5.5 – Wartungsfenster“Informationen und Assets für IT-Systeme SOLLTE bei voraussichtlichen Verfügbarkeiteinschränkungen durch bevorstehende Wartungen die Nutzenden über Dauer und Umfang der Einschränkungen informieren.
Wenn durch Wartungsarbeiten die Verfügbarkeit von Systemen, Anwendungen oder Daten in Geschäftsprozessen beeinträchtigt werden könnte, ist eine Information über die bevorstehende Wartung sinnvoll. Dazu gehört, dass über die Dauer (Beginn und Ende), sowie über den Umfang der Einschränkungen (z.B. betroffene Anwendungen, Netze oder Funktionen) informiert wird. Beispiele sind Firmware- oder Betriebssystemupdates von zentralen Speichersystemen oder Netzkomponenten, der Austausch von Komponenten an zentralen Stromverteilern oder eine Wartung an den Klimasystemen eines nicht redundant ausgelegten Serverraumes.
ASST.5.6 – Wartung durch Externe
Abschnitt betitelt „ASST.5.6 – Wartung durch Externe“Informationen und Assets für Mitarbeitende KANN bei Wartungen, die von Externen ohne Sicherheitsüberprüfung vorgenommen werden, zur Beaufsichtigung durch internes Personal anweisen.
Eine Sicherheitsüberprüfung bezeichnet hier die systematische Bewertung der Vertrauenswürdigkeit und Zuverlässigkeit von externen Dienstleistern oder deren Personal durch background checks, Referenzprüfungen oder formelle Sicherheitsclearance-Verfahren. Externe ohne Sicherheitsüberprüfung umfasst alle Dienstleister, Wartungstechniker oder Support-Personal von Drittanbietern, die nicht durch entsprechende Verfahren zur Vertrauenswürdigkeit validiert wurden. Beaufsichtigung durch internes Personal ist die kontinuierliche Anwesenheit und Überwachung von qualifizierten eigenen Mitarbeitenden während der gesamten Dauer der Wartungsarbeiten, um sowohl fachliche Aufsicht als auch Sicherheitskontrolle zu gewährleisten. Dazu gehört, dass die begleitenden Mitarbeitenden sicherstellen, dass Externe ausschließlich auf die für ihre Wartungsaufgabe notwendigen Systembereiche zugreifen und keine unauthorisierten Aktionen wie das Kopieren von Dateien oder die Installation nicht genehmigter Software durchführen. Externe Wartungskräfte ohne Sicherheitsüberprüfung könnten sonst vertrauliche Informationen einsehen, kopieren oder manipulieren, Malware einschleusen oder unbeabsichtigt Systemkonfigurationen beschädigen. Durch begleitendes internes Personal kann eine Institution kontinuierliche Aufsicht über alle durchgeführten Aktivitäten sicherstellen und gleichzeitig den Wissenstransfer für zukünftige Wartungsarbeiten fördern. Bei einer Fernwartung kann dies z.B. durch das Logging von Diagnose- und Wartungsaktivitäten, sowie die anschließende Überprüfung, dass alle Wartungsverbindungen getrennt sind, geschehen.
ASST.5.7 – Dokumentation von Wartungen
Abschnitt betitelt „ASST.5.7 – Dokumentation von Wartungen“| OPS.1.1.1.A19-UA.4 | überschneidet sich mit |
Informationen und Assets für IT-Systeme SOLLTE Wartungen mit Asset, Anlass, Zeitpunkt, Beteiligten, durchgefürten Maßnahmen und Ergebnissen dokumentieren.
Die Dokumentation von Wartungen an IT-Systemen kann Nachvollziehbarkeit, Verantwortlichkeit und Beweisfähigkeit herstellen; ohne sie könnten unerkannte Konfigurationsänderungen, verdeckte Schwachstellen oder verlängerte Ausfälle entstehen. Zur Umsetzung kann die Institution ein schlankes, einheitliches Wartungsprotokoll verwenden, das je Vorgang erfasst: (1) eindeutig referenziertes Asset/CI, Umgebung und betroffener Service, (2) Anlass, Art der Wartung (präventiv/korrektiv/notfall) und geplanter Zeitraum, (3) Verantwortliche, Beteiligte/Dienstleister und Kontakt, (4) geplante Maßnahmen, Backout-Plan sowie definierte Vor-/Nach-Checks, (5) tatsächlich durchgeführte Schritte („as-built“), verwendete Versionen/Images und geänderte Parameter, (6) Messergebnisse/Logs/Screenshots/Hashes als Nachweis, (7) Auswirkungen (Downtime, Kapazität), Abnahme/Testresultat und Freigabe, (8) Verweise auf Tickets/Changes/Störungsmeldungen, (9) Datum/Zeit mit Zeitzone und Protokollversion. Die Erfassung kann in einem vorhandenen Ticket- oder CMDB-Werkzeug stattfinden.
ASST.6 Rücknahme von Assets
Abschnitt betitelt „ASST.6 Rücknahme von Assets“ASST.6.1 – Abhandenkommen
Abschnitt betitelt „ASST.6.1 – Abhandenkommen“Informationen und Assets SOLLTE eine Vorgehensweise beim Abhandenkommen von Assets verankern.
Eine Vorgehensweise beim Abhandenkommen von Assets ist ein strukturierter, dokumentierten Reaktionsprozess, der alle notwendigen Schritte und Verantwortlichkeiten für den Umgang mit verloren gegangenen, gestohlenen oder anderweitig außer Kontrolle geratenen Informationswerten nach Eintritt des Verlustereignisses festlegt. Ohne strukturierte Prozesse könnte ein verlorenes Laptop mit Kundendaten zu anhaltenden Datenschutzverletzungen führen, ein gestohlenes Smartphone könnte dauerhaft unbefugten Zugang zu Unternehmensressourcen ermöglichen, oder vergessene Dokumente könnten unkontrolliert Geschäftsgeheimnisse preisgeben. Eine etablierte Vorgehensweise kann durch schnelle Reaktionszeiten und koordinierte Sofortmaßnahmen das bereits eingetretene Schadenspotential begrenzen und die Wiederherstellung der Informationssicherheit beschleunigen. Die Vorgehensweise zur Behandlung kann z.B. die Ortung, Sperrung oder Löschung per Fernzugriff, das Melden bei Ermittlungsbehörden oder lokalen Fundbüros, die Änderung aller betroffenen Zugangsdaten, sowie die Sperre von Authentisierungsmitteln und der enthaltenen SIM-Karte beim Provider beinhalten.
ASST.6.2 – Rückkehr abhandengekommener Assets
Abschnitt betitelt „ASST.6.2 – Rückkehr abhandengekommener Assets“Informationen und Assets SOLLTE eine Vorgehensweise bei Rückkehr von abhandengekommenen Assets verankern.
“Abhandengekommene Assets” bezeichnen Informationswerte, die ungewollt oder ungeplant außerhalb der direkten Kontrolle der Institution geraten sind - beispielsweise durch Verlust, Diebstahl, vergessene Mitnahme oder andere unbeabsichtigte Ereignisse. Eine “Vorgehensweise bei Rückkehr” meint einen strukturierten Prozess zur systematischen Wiederaufnahme und sicherheitstechnischen Bewertung solcher Assets nach ihrer Wiederbeschaffung oder ihrem Wiederauffinden. Diese Anforderung zielt auf die Risikominimierung bei der Wiederintegration potenziell kompromittierter Assets ab, da während der unkontrollierten Abwesenheit Manipulationen, unautorisierten Zugriffe oder Datenabflüsse aufgetreten sein könnten. Ohne strukturierte Rückkehrprozesse kann die unkontrollierte Wiederverwendung zurückgekehrter Assets zu Sicherheitslücken, Malware-Infektionen oder Datenschutzverletzungen führen. Umsetzungen können bei der Asset-Rückkehr (1) eine vollständige Identitätsprüfung anhand eindeutiger Kennzeichnungen wie Seriennummern oder Asset-Tags, (2) eine technische Integritätsprüfung durch Malware-Scans, Firmware-Vergleiche und Hardwareanalysen sowie (3) eine Datenintegrität-Bewertung mittels kryptografischer Prüfsummen oder forensischer Analysen umfassen. Als Alternative zur tiefergehenden Analyse von Systemen und Daten bietet sich auch die Löschung oder Entsorgung an. Prozessual kann die Einrichtung einer zentralen Asset-Return-Stelle mit definierten Eskalationswegen bei Auffälligkeiten, die Dokumentation aller Rückkehrfälle in einem Asset-Management-System und die Implementierung von Quarantäne-Verfahren für verdächtige Assets erfolgen.
ASST.6.3 – Konformitätsprüfung
Abschnitt betitelt „ASST.6.3 – Konformitätsprüfung“Informationen und Assets für IT-Systeme KANN bei Rücknahme die Konformität mit den einschlägigen Anforderungen testen.
Assets sind nicht konform, wenn Sie die für sie geltenden Anforderungen nicht oder nicht mehr erfüllen, z.B. weil die Hardware manipuliert wurde oder keine Sicherheitsupdates mehr bereitgestellt werden. Die Prüfung kann durch automatische Prüfsysteme oder mit manuellen Verfahren, z.B. Sichtkontrolle von Siegeln, gewährleistet werden. Auch die Nutzung von Stichprobenkontrollen ist möglich. Zur Behandlung kann entweder die Ursache der Nichtkonformität beseitigt werden, oder alternative Lösungen können angewendet werden, z.B. kann das Gerät auf Werkszustand zurückgesetzt und neu installiert werden. Ist dies nicht möglich so bleibt keine andere Behandlungsmöglichkeit als das Assets nicht weiter zu verwenden.
ASST.6.4 – Zurücksetzen auf Ausgangszustand
Abschnitt betitelt „ASST.6.4 – Zurücksetzen auf Ausgangszustand“| INF.10.A9-UA.1 | überschneidet sich mit |
Informationen und Assets für IT-Systeme SOLLTE bei Rücknahme das Zurücksetzen in einen definierten Ausgangszustand ausführen.
Mit definierter Ausgangszustand ist hier ein Zustand gemeint, in dem alle während der Nutzung möglicherweise angefallenen vertraulichen Daten wieder gelöscht oder vernichtet sind. Dies kann in vielen Fällen am einfachsten durch Überschreiben der Speichermedien, kryptografisches Löschen oder das vollständige Zurücksetzen auf Werkseinstellungen erfolgen. Zur Umsetzung einer Vernichtung siehe DIN 66399. Alternativ kann auch ein vordefiniertes Systemimage installiert werden, wodurch das System für die erneute Ausgabe vorbereitet wird, wenn das Systemimage alle vorher auf dem System vorhandenen Daten überschreibt oder diese vollständig verschlüsselt waren.
ASST.7 Löschen und Vernichten
Abschnitt betitelt „ASST.7 Löschen und Vernichten“ASST.7.1 – Nicht mehr benötigte Anwendungen
Abschnitt betitelt „ASST.7.1 – Nicht mehr benötigte Anwendungen“Informationen und Assets für Anwendungen SOLLTE eine Deinstallation nicht mehr benötigter Anwendungsinstanzen verankern.
„Nicht mehr benötigte Anwendungsinstanzen“ sind installierte, aber aktuell nicht mehr genutzte Softwarekomponenten, Applikationen oder Dienste (engl. application instances), die auf Servern, Endgeräten oder virtuellen Umgebungen verbleiben, obwohl ihre betriebliche Funktion entfallen ist. Diese können produktiv, testweise oder temporär eingerichtet gewesen sein. Eine Deinstallation ist hier als geregelter Prozess der vollständigen und nachvollziehbaren Entfernung solcher Komponenten zu verstehen, einschließlich ihrer Konfigurationen, temporären Daten und zugehörigen Zugriffsrechte. Der Zweck liegt in der Vermeidung von Sicherheits- und Integritätsrisiken, die durch ungenutzte oder veraltete Software entstehen könnten – etwa weil diese weiterhin Angriffsflächen bietet, unbemerkte Schwachstellen enthält oder unbeabsichtigte Datenabflüsse begünstigen könnte. Die Entfernung kann somit die Systemhärtung und Transparenz über tatsächlich aktive Anwendungen fördern. Dies kann durch Systeme automatisiert geschehen, die bei der Zuordnung von Anwendungen zu Personen eine automatische Installation oder Deinstallation erledigt. Wenn Anwendungen nicht länger benötigt werden, dann sind auch die für die Anwendung erforderlichen Berechtigungen nicht länger erforderlich. Hierzu gehören sowohl lokale als auch Cloud-Zugänge. Steht die Anwendungsinstanz in der Cloud nicht unter der Kontrolle der Institution, so sind stattdessen soweit möglich alle Daten in der Cloud zu löschen.
ASST.7.2 – Aufbewahrungs- und Löschfristen
Abschnitt betitelt „ASST.7.2 – Aufbewahrungs- und Löschfristen“Informationen und Assets für Daten SOLLTE die Aufbewahrung für [eine bestimmte Frist] verankern.
Klar festgelegte und in Prozessen verankerte Löschfristen helfen Sicherheits- und Compliancerisiken zu minimieren, indem Informationen entsorgt werden, wenn sie nicht mehr benötigt werden. Dies gilt sowohl für Originaldaten als auch für Kopien und archivierte Aufzeichnungen, einschließlich Protokolldateien. Hier besteht ein enger Bezug zu Compliance-Verpflichtungen, sowohl zur Aufbewahrung (z.B. für Nachweispflichten aus dem Steuerrecht) als auch zur Löschung (z.B. aus dem Datenschutzrecht). Die Auswahl der Methode zum Löschen hängt von der Vertraulichkeit der Daten, verwendeten Anwendungen oder Speichermedien und ggf. bestehenden Compliance-Verpflichtungen ab. Eine Herausforderung stellt dabei der Umgang mit Datenkopien in Datensicherungen dar. Da das nachträgliche Herausfiltern bestimmter Daten aus Datensicherungen häufig sehr aufwändig ist, ist es empfehlenswert die Versionierung der Datensicherungen so zu gestalten, dass die Daten zum Ablauf der Löschfrist ohnehin mit neueren Datensicherungen überschrieben wurden oder ältere Kopien der Datensicherung insgesamt gelöscht sind. Für kurzlebige Daten bietet es sich an diese nicht in eine einzige zentrale Datensicherung aufzunehmen, sondern je nach Schutzbedarf an Integrität und Verfügbarkeit dieser Daten gar keine oder eine Datensicherung für kurzlebige Daten, z.B. Diagnosedaten mit Personenbezug, vorzuhalten.
ASST.7.2.1 – Langfristige Archivierung
Abschnitt betitelt „ASST.7.2.1 – Langfristige Archivierung“Informationen und Assets für Daten KANN die langfristige Archivierung mindestens für [eine bestimmte Frist] verankern.
Archivierung meint hier die langfristige Aufbewahrung derjenigen Daten, die über längere Zeit benötigt werden, z.B. über mehr als 10 Jahre. Hierbei kann es sich beispielsweise um Nachweise der Einhaltung rechtlicher Verpflichtungen, Daten zur Nachvollziehbarkeit von Angriffen (Audit Log), oder zur Geltendmachung von Ansprüchen handeln. Dabei kann es sich sowohl um analoge Dokumente als auch um digitale Daten handeln. Die meisten Institutionen verarbeiten Daten, die aufgrund von Compliance-Verpflichtungen langfristig gespeichert werden, z.B. handels- und steuerrechtlich relevante Dokumente oder Eigentumsurkunden.
ASST.7.3 – Geregeltes Löschen oder Vernichten
Abschnitt betitelt „ASST.7.3 – Geregeltes Löschen oder Vernichten“Informationen und Assets für Daten SOLLTE diese bei Erreichen der Aufbewahrungs- und Löschfrist durch [kryptografisches löschen, überschreiben oder vernichten des Speichermediums] löschen.
Ereignisse können z.B. der Ablauf der festgelegten Löschfrist, die Veräußerung von Assets oder deren Weitergabe an einen Dienstleister sein. Relevant sind hierbei neben physischen und virtuellen Medien auch die Datenträger in IT-Systemen wie Notebooks und Fahrzeugen. Sicheres Löschen bedeutet, Daten so zu entfernen, dass sie mit vertretbarem Aufwand (auch forensisch) nicht mehr rekonstruierbar sind. Je nach Medium geschieht das z. B. durch verifizierbares Überschreiben, kryptografisches Löschen (Schlüsselvernichtung) oder physische Zerstörung (inklusive zugehöriger Metadaten, Caches und Datensicherungen). Die Anforderung ist auch erfüllt, wenn sie durch einen Dienstleister durchgeführt wird, der hierzu verpflichtet ist.
ASST.7.3.1 – Standardisierte Vernichtung
Abschnitt betitelt „ASST.7.3.1 – Standardisierte Vernichtung“Informationen und Assets für Daten SOLLTE ein standardisiertes Verfahren zur Vernichtung bei Veräußerung nach [einem anerkannten Standard] gemäß [einer Sicherheitsstufe] verankern.
Anerkannte Standards für die Vernichtung sind DIN 66399 sowie ISO/IEC 21964; die Sicherheitsstufe beschreibt die Intensität der Vernichtung, wobei eine möglichst kleinteilige Zerkleinerung die Wahrscheinlichkeit einer Rekonstruktion aus Fragmenten minimiert. Die konkrete Vorgehensweise richtet sich nach der Art des Speichermediums: Papier wird nach Sicherheitsstufe P-3 gemäß ISO/IEC 21964-2 vernichtet, optische Speichermedien nach Sicherheitsstufe O-3 gemäß ISO/IEC 21964-2 und sonstige Speichermedien nach Sicherheitsstufe E-3 oder H-3 gemäß ISO/IEC 21964-2. Für Speichermedien, die vor der Nutzung vollständig verschlüsselt waren und deren kryptografische Schlüssel unwiederbringlich gelöscht wurden, ist eine physische Vernichtung nicht erforderlich.
ASST.7.3.2 – Löschverfahren
Abschnitt betitelt „ASST.7.3.2 – Löschverfahren“| APP.1.4.A12-UA.1 | überschneidet sich mit |
Informationen und Assets für Daten SOLLTE ein Verfahren zur endgültigen Löschung verankern.
Hierunter ist ein nachvollziehbarer, dokumentierter technischer und prozessualer Ablauf zur endgültigen Entfernung oder Unkenntlichmachung von Informationen zu verstehen; „Endgültig“ bedeutet, dass Daten mit vertretbarem Aufwand nicht wiederhergestellt werden können. Ohne klare Verfahren könnte Alt- oder Schattendatenbestand bei Geräteweitergabe, in Backups oder Cloud-Objektspeichern verbleiben, was zu Datenschutzverletzungen, Erpressungsversuchen oder regulatorischen Sanktionen führen könnte. Hierzu gehören sowohl Nutzdaten von IT-Systemen und Anwendungen, als auch Konfigurationsdateien oder Daten, die in begleitenden Dokumenten wie Betriebshandbüchern oder Informationswikis abgelegt sind.
ASST.7.3.3 – Zugelassene Löschanwendungen
Abschnitt betitelt „ASST.7.3.3 – Zugelassene Löschanwendungen“Informationen und Assets für Daten KANN die Daten durch [eine vom BSI zugelassene Löschanwendung] löschen.
Für eine aktuelle Liste der zugelassenen Löschanwendungen siehe BSI-Schrift 7164: Liste der zugelassenen IT-Sicherheitsprodukte und -systeme. Sicheres Löschen bedeutet, Daten so zu entfernen, dass sie mit vertretbarem Aufwand (auch forensisch) nicht mehr rekonstruierbar sind. Je nach Medium geschieht das z. B. durch verifizierbares Überschreiben, kryptografisches Löschen (Schlüsselvernichtung) oder physische Zerstörung (inklusive zugehöriger Metadaten, Caches und Datensicherungen).
ASST.7.4 – Wiederherstelltest
Abschnitt betitelt „ASST.7.4 – Wiederherstelltest“Informationen und Assets für Daten KANN den Erfolg des Löschvorgangs testen.
Der Test kann mit Software oder Hardware, die vermeintlich gelöschte Daten von Speichermedien wiederherstellen kann, durchgeführt werden. Bei vernichteten Speichermedien ist der Test entbehrlich.
ASST.7.5 – Vernichtungseinrichtungen
Abschnitt betitelt „ASST.7.5 – Vernichtungseinrichtungen“Informationen und Assets für Standorte KANN an allen Standorten, an denen körperliche Dokumente verarbeitet werden, Vernichtungseinrichtungen vor dem Zugriff unbefugter geschützt installieren.
Die Installation von Vernichtungseinrichtungen dient dem Schutz sensibler Daten vor unbefugtem Zugriff, Missbrauch oder unkontrollierter Weitergabe. Ziel ist es, die Vertraulichkeit, Integrität und Verfügbarkeit von Informationen auch über ihren gesamten Lebenszyklus hinweg sicherzustellen – einschließlich der ordnungsgemäßen Entsorgung. Unter Vernichtungseinrichtungen versteht man mechanische oder elektronische Geräte, die Dokumente so zerkleinern oder unlesbar machen, dass eine Rekonstruktion unmöglich ist; typische Beispiele sind Aktenvernichter mit Schutzklasse P-4 oder höher oder Entsorgungsbehälter mit gesichertem Zugriff (z.B. abschließbare Sicherheitsbehälter). Dies kann auch so realisiert werden, dass Datenträger gesammelt und zentral gelöscht oder vernichtet werden. Kann durch die Institution selbst oder Dienstleister für die Aktenvernichtung umgesetzt werden. Bei der Verwendung von Dienstleistern ist es sinnvoll, deren Professionalität zu verifzieren, z.B. durch ein Zertifikat. Bei der Umsetzung ist es sinnvoll darauf zu achten, dass solche Einrichtungen nicht nur ausreichend dimensioniert und technisch geeignet sind, sondern auch physisch gegen unbefugten Zugriff geschützt werden – etwa durch Aufstellung in abgeschlossenen Räumen oder durch Zugangskontrolle.
ASST.7.6 – Autorisierung von Veräußerungen
Abschnitt betitelt „ASST.7.6 – Autorisierung von Veräußerungen“Informationen und Assets SOLLTE Veräußerungen von Assets durch [eine zuständige Person oder Rolle] autorisieren.
Veräußerung bezeichnet in diesem Kontext jede endgültige Abgabe oder Eigentumsübertragung (Verkauf, Spende, Rückgabe an Leasing, Recycling) eines Assets. Die Autorisierung kann verhindern, dass schutzbedürftige Informationen unkontrolliert den Besitz wechseln, Compliance-Vorgaben übersehen werden und Verantwortlichkeiten verwischen. Ohne geregelte Freigabe könnte ein ausgemusterter Laptop mit Restdaten verkauft, ein Speicherarray mit verbleibenden Schlüsseln weitergegeben oder eine nicht übertragbare Softwarelizenz abgegeben werden, was zu Datenabfluss, Vertragsverletzungen und Reputationsschäden führen könnte. Zur Umsetzung kann die Institution einen schlanken, nachvollziehbaren Freigabe-Workflow etablieren: Ein Veräußerungsantrag kann Asset-ID/Inventarnummer, Asset-Owner, Schutzbedarf/Klassifizierung, Datenträgerart, vorgesehenes Verwertungsverfahren, gewählte Datenlösch-/Vernichtungsmethode, Lizenz-/Vertragsrestriktionen, Übergabedatum und Empfänger erfassen; die Freigabe kann vor Übergabe erfolgen und revisionssicher protokolliert werden. Eine Entscheidungsmatrix kann die Genehmigungstiefe nach Schutzbedarf steuern, z. B. (1) „öffentlich“: fachliche Freigabe, (2) „intern“: Asset Owner + IT-Freigabe, (3) „vertraulich/streng“: Vier-Augen-Prinzip aus zuständige Person oder Rolle und Informationssicherheitsbeauftragte/r.
ASST.7.7 – Beschriftungen entfernen
Abschnitt betitelt „ASST.7.7 – Beschriftungen entfernen“Informationen und Assets SOLLTE alle der Institution zuzuordnenden Beschriftungen vor der Veräußerung von Assets löschen.
Die „Beschriftung“ eines Assets ist jede physische oder digitale Kennzeichnung, die eine eindeutige Zuordnung des Gegenstands oder Datenträgers zu Werten der Institution ermöglicht. Darunter fallen unter anderem Eigentumskennzeichnungen (engl. asset tags), Seriennummern, Barcodes, Gravuren, Aufkleber mit Logo, aber auch digitale Metadaten wie Gerätebezeichnungen, E-Mail-Konten, Hostnamen oder eingebettete Wasserzeichen. Das Löschen dieser Beschriftungen vor der Veräußerung stellt sicher, dass Dritte nicht unmittelbar auf den ursprünglichen Eigentümer schließen oder unautorisierte Rückschlüsse auf interne Strukturen, Sicherheitsarchitekturen oder Verantwortlichkeiten ziehen. Ohne diese Bereinigung könnte ein weiterveräußertes Gerät durch verbleibende Markierungen auf die Institution hinweisen und so gezielt für Social-Engineering-Angriffe oder Reputationsschäden genutzt werden. Eine solche Zuordnung könnte zudem dazu führen, dass vertrauliche Informationen über Inventar, Sicherheitsstandards oder IT-Bestände unbeabsichtigt offengelegt werden. Zudem könnte eine verbleibende Beschriftung zu Missverständnissen über Eigentumsverhältnisse oder Haftung führen, falls das Asset in einen Vorfall verwickelt wird. Konkret können unter den zu entfernenden Beschriftungen beispielsweise Eigentumsaufkleber mit der Inventarnummer, Etiketten mit Standort- oder Abteilungsbezeichnungen, Markierungen für interne Verwendungszwecke (z.B. “Testgerät”, “intern”), aber auch digital eingebettete Informationen wie institutionelle Metadaten in Office-Dokumenten oder gespeicherte WLAN-Profile auf mobilen Geräten verstanden werden. Auch optische Hinweise wie eingravierte Logos auf Gehäusen oder institutionelle Startbildschirme bei Laptops können darunterfallen. Zur Umsetzung kann es hilfreich sein, vor der Veräußerung eine Sichtprüfung durchzuführen und standardisierte Checklisten zu nutzen, um typische Beschriftungen systematisch zu identifizieren. Je nach Beschaffenheit des Assets kann der Einsatz von Reinigungsmitteln, Etikettenentfernern oder speziellen Werkzeugen in Betracht gezogen werden. Auch softwaregestützte Verfahren, etwa das Zurücksetzen auf Werkseinstellungen und das Prüfen auf verbleibende Metadaten, sind relevant. Nicht zuletzt kann die Einbindung von ISB oder des Datenschutzbeauftragten in Zweifelsfällen Klarheit darüber schaffen, ob eine bestimmte Kennzeichnung potenziell sicherheitsrelevant ist.