Verzeichnis aller Datenarten

Unter systembezogenen Daten sind jene Informationen zu verstehen, welche primär technische Systeme und Abläufe betreffen – nicht direkt eine Person, sondern die Funktion und Ereignisse des Sicherheitssystems selbst. Diese Daten fallen automatisch bei Betrieb der Anlagen an und sind für die Steuerung, Überwachung und Wartung der Sicherheitsinfrastruktur unverzichtbar. Obwohl sie in der Regel keinen Personenbezug aufweisen, können sie indirekt mit personenbezogenen Vorgängen verknüpft sein (z. B. ein Alarm, der durch eine Person ausgelöst wurde). Ihre Erfassung begründet sich durch das Interesse, ein reibungslos funktionierendes und sicheres Gesamtsystem zu gewährleisten. Im Folgenden werden die wichtigsten systembezogenen Datenarten aufgelistet:

• Kurzbeschreibung: Laufend erfasste Statusinformationen der technischen Geräte im Zutritts- und Sicherheitssystem. Dazu zählen beispielsweise: Tür- und Schlossstatus (offen/geschlossen/verriegelt), Zustände von Sensoren (Bewegungsmelder aktiv/inaktiv, Magnetkontakte intakt, Batteriestand von Funkkomponenten), Verbindungsstatus von Kameras und Lesern (online/offline), Betriebszustand von Alarmzentralen oder Schalteinrichtungen, etc. Ebenfalls gehören Meldungen über technische Störungen oder Wartungsbedarfe hierher (z. B. „Batterie Türcontroller niedrig“, „Kamera 12 kein Signal“). Diese Daten haben meist Ereignisform („Gerät X hat Zustand Y um 12:30 angenommen“) oder werden zyklisch gepollt (regelmäßige Alive-Signale). Personenbezug besteht in der Regel nicht – es sind rein technische Rückmeldungen der Geräte.

• Zweck der Erfassung: Das Sicherheitssystem soll jederzeit funktionsfähig und manipulationsgeschützt sein. Daher ist es notwendig, Gerätestatusdaten in Echtzeit zu erfassen, um Fehlfunktionen, Ausfälle oder Sabotage umgehend zu erkennen. Beispielsweise muss die Leitstelle erfahren, wenn eine Zugangstür unerwartet offensteht oder ein Kartenleser defekt ist, um Gegenmaßnahmen einzuleiten (Tür sichern, Techniker senden). Diese Überwachung ist Teil der organisatorischen und technischen Maßnahmen zur Aufrechterhaltung der Sicherheit (Art. 32 DSGVO fordert u. a. die Fähigkeit, Systeme zuverlässig zu betreiben). Gleichzeitig dienen die Statusdaten der präventiven Wartung: Regelmäßig ausgelesene Werte (z. B. Akkuladestand) ermöglichen es, vorbeugend Batterien zu wechseln, bevor das Schloss versagt – dies verhindert Sicherheitslücken. Außerdem erlauben solche Daten eine Optimierung des Betriebs (z. B. zu erkennen, welche Türen häufig im „Not-Auf“ sind, ob ausreichend Geräte-Redundanz besteht etc.). Kurzum, diese Daten werden erfasst, um das Sicherheitsmanagementsystem als Ganzes stabil und reaktionsfähig zu halten – ein legitimes Interesse des Betreibers und teils auch eine Pflicht (denn eine Schutzmaßnahme, die wegen Gerätausfalls versagt, kann haftungsrechtliche Konsequenzen haben).

• Speicherort/System: Gerätestatusdaten werden in der Regel innerhalb des zentralen Sicherheitsmanagementsystems (z. B. einem Gefahrenmanagement- oder PSIM-System) gesammelt. Die Sensoren und Aktoren melden ihre Zustände an eine Leitstelle oder einen Server, wo sie in einer Statusdatenbank oder temporären Variablen gehalten werden. Akute Statusänderungen generieren oft zugleich Ereignisse/Alarme (siehe 2.2). Viele Systeme visualisieren den aktuellen Status aller Komponenten auf einer Bedienoberfläche (z. B. Grundriss mit Türsymbolen grün/rot). Historisch relevante Statusänderungen werden meist in Logdateien (siehe 2.3) protokolliert, während der momentane Status in einem flüchtigen Speicher verbleibt. Einige Statuswerte können auch in Geräte-internen Logs stecken (z. B. eine Zutrittskontrollzentrale speichert wann welche Nebenstelle zuletzt Kontakt hatte). Der primäre Speicherort ist jedoch zentral, typischerweise auf Servern der Sicherheitsleitwarte.

• Löschfrist: Da Statusdaten dynamischer Natur sind, stellt sich die Frage der Löschfrist etwas anders: Der aktuelle Status wird permanent aktualisiert und überschreibt den alten (z. B. eine Tür kann nur offen oder geschlossen sein – der Zustand ändert sich und der alte ist historisch im Log). Historische Statusänderungen, soweit aufgezeichnet, fallen unter Logdaten und können entsprechend aufbewahrt werden (oft 1–2 Jahre, siehe System-Logs unten). Viele unwichtige Statusänderungen werden jedoch gar nicht langfristig gespeichert, sondern nur soweit sie sicherheitsrelevant sind. Beispielsweise mag das System nicht jede „Tür auf/Tür zu“-Bewegung loggen, sondern nur, wenn sie außerhalb eines normierten Verhaltens stattfindet (z. B. Tür bleibt offen zu lange, Alarm). Insofern werden reine Status-pings oft nur kurz gehalten. Als generelle Richtlinie kann gelten: Technische Logs und Statusarchive löscht man, sobald sie für keinen Zweck (Fehleranalyse, Nachweis) mehr gebraucht werden. Das kann in der IT nach wenigen Tagen sein (bei voluminösen unwichtigen Logs) oder nach Monaten. Sollte ein Statusereignis Teil eines sicherheitsrelevanten Vorfalls sein (z. B. „Kamera ausgefallen kurz vor Einbruch“), wandert es in einen Vorfallsbericht und könnte dort länger aufbewahrt werden. Aber an sich sind Statusdaten unkritisch in Bezug auf Speicherfristen, solange kein Personenbezug besteht; primär wird aus Performancegründen eine Rollierung vorgenommen.

• Besondere Schutzmaßnahmen: Obwohl Gerätestatusdaten keine persönlichen Informationen enthalten, sind sie sicherheitskritisch: Ein Angreifer, der diese Daten einsieht, könnte Schwachstellen entdecken (etwa gezielt ein Areal ansteuern, wo gerade eine Kamera offline ist). Daher unterliegen auch diese technischen Daten dem Need-to-know-Prinzip – nur Administratoren und Leitstellenmitarbeiter dürfen den vollständigen Status aller Komponenten sehen. Insbesondere extern sollten solche Daten niemals zugänglich sein (Absicherung gegen Cyberangriffe, z. B. indem das Sicherheitsnetzwerk vom offenen Firmennetz getrennt ist). Integrity ist wichtig: Manipuliert jemand die Statusanzeigen (z. B. indem er einen Ausfall verschleiert), könnte das System in falscher Sicherheit wiegen. Daher sollten Statusmeldungen authentifiziert/verschlüsselt übermittelt werden, und Unplausibilitäten (z. B. plötzlicher Ausfall einer ganzen Sektion) alarmieren wiederum. Für die Verfügbarkeit werden Redundanzen eingerichtet (Backup-Strom für Sensoren, Fallback-Kanäle), damit Statusdaten kontinuierlich fließen. Zusammengefasst: Die Schutzmaßnahmen zielen hier v.a. auf Systemsicherheit (vor Sabotage, Spionage) ab. Datenschutz spielt eine geringere Rolle, es sei denn, durch Korrelation könnten indirekt Personen identifiziert werden (was normalerweise nicht der Fall ist, da rein technische Zustände). Somit sorgen strikte Netzwerk- und Zugriffssicherungen dafür, dass Gerätestatusdaten zuverlässig und vertraulich im internen Gebrauch bleiben.

• Kurzbeschreibung: Alarmmeldungen sind besondere Ereignisdaten, die vom System generiert werden, sobald ein sicherheitsrelevanter Vorfall oder eine bestimmte vordefinierte Bedingung eintritt. Beispiele: Ein Einbruchalarm, wenn ein Türkontakt eine Öffnung außerhalb erlaubter Zeiten meldet; ein Überfallalarm von einem stillen Alarmknopf; ein Brandalarm aus der Brandmeldeanlage (wenn diese integriert ist); eine Sabotagemeldung (z. B. Gehäuse eines Lesers geöffnet); oder eine Zutrittsverletzung (mehrfache falsche PIN-Eingabe, unautorisierter Zugang versucht). Auch Systemalarme wie „Server ausgefallen“ gehören in diese Kategorie, aber primär sind hier sicherheitsrelevante Gefahren- und Störungsmeldungen gemeint. Jede Alarmmeldung enthält zumindest einen Zeitstempel, eine Alarmart/Kategorie, einen Ort/Zone (wo tritt der Alarm auf) und ggf. Zusatzinfos (betroffener Sensor, Schweregrad). Alarmmeldungen können durch Personen verursacht sein (etwa ein Mitarbeiter versucht unbefugt eine Tür zu öffnen) oder durch technische Umstände (Feuer, Defekt), haben aber zunächst rein systematischen Charakter. Neben Alarmen im engeren Sinne können auch Ereignismeldungen darunter fallen, die nicht immer „Alarm“ sind, aber eine besondere Notifikation – z. B. „Sicherheitsschleuse manuell übersteuert“ oder „Wetteralarm Sturm aktiviert“.

• Zweck der Erfassung: Alarm- und Ereignismeldungen werden erfasst und generiert, um unmittelbar auf sicherheitskritische Situationen reagieren zu können. Sie bilden den Kern der Gefahrenabwehr: Ohne ein Alarmsystem würde eine Zutrittskontrolle alleine nur dokumentieren, aber nicht aktiv warnen. Die Meldungen sorgen dafür, dass das Sicherheitspersonal oder automatische Prozesse (z. B. eine Benachrichtigungskette) ausgelöst werden und Gegenmaßnahmen eingeleitet werden können – etwa Ausschwärmen eines Sicherheitsdienstes, Benachrichtigung der Feuerwehr, Verriegelung von Türen, Einschaltung von Kameras auf einen Alarm-Monitor etc. Darüber hinaus dienen diese Ereignisdaten der Dokumentation von sicherheitsrelevanten Vorfällen. Im Nachgang kann analysiert werden, was passiert ist, wer ggf. beteiligt war und ob die Sicherheitsmaßnahmen ausreichten. Aus Management-Sicht liefern Alarmstatistiken auch wichtige Informationen zur Risikobewertung und Verbesserung des Sicherheitskonzepts (z. B. Häufung von Alarmen an einer bestimmten Tür deutet auf Schwachstelle hin). Kurzum: Die Erfassung von Alarmmeldungen ist organisatorisch notwendig und im Sicherheitsinteresse unabdingbar, um das Werksgelände proaktiv zu schützen und im Schadensfall Aufklärung und Beweissicherung zu betreiben. In einigen Bereichen gibt es auch gesetzliche Vorschriften für Alarmsysteme (z. B. Einbruchmeldeanlage in bestimmten genehmigungspflichtigen Lagerstätten); wo dies der Fall ist, ist die Alarmdatenerfassung auch gesetzliche Pflicht zur Einhaltung behördlicher Auflagen.

• Speicherort/System: Alarm- und Ereignisdaten werden zentral im Alarmmanagement-Modul des Sicherheitssystems gehalten. Typischerweise verfügt die Leitstelle über Software, die alle eingehenden Alarme anzeigt, protokolliert und verwaltet (inkl. Quittierung durch Mitarbeiter etc.). Diese Meldungen werden in einer Ereignisdatenbank gespeichert, oft gemeinsam mit den Zutrittslogs, aber mit besonderer Kennzeichnung (Alarmflag, Priorität). Häufig sind Alarme auch konfiguriert, Aktionen auszulösen: z. B. schickt das System bei Alarm X automatisch eine E-Mail oder SMS an den Sicherheitschef – in diesem Fall werden die Daten kurzzeitig auch über Kommunikationssysteme übertragen (interne Mailserver, SMS-Gateways). Falls das System in Teilbereiche aufgegliedert ist (z. B. separate Einbruchmeldeanlage, separate Brandmeldeanlage), fließen deren Meldungen entweder über eine Schnittstelle ins zentrale System oder sie bleiben in ihrem Sub-System. In einem voll integrierten Sicherheitsmanagement laufen jedoch i.d.R. alle Ereignisse in einer vereinheitlichten Ereignisliste zusammen. Dort werden sie mit Zeit und allen Parametern gespeichert. Zusätzlich wird oft ein Alarmbuch geführt: das Sicherheitspersonal notiert zu jedem Alarm die verifizierte Ursache und ergriffene Maßnahme; dieses kann elektronisch im System hinterlegt oder separat geführt sein – gehört aber streng genommen auch zur Dokumentation solcher Ereignisse (ggf. als Teil von 3.2 technische Metadaten in Form von Notizen).

• Löschfrist: Alarmereignisse sind meist länger aufzubewahren als gewöhnliche Logeinträge, da sie sicherheitsrelevante Vorfälle markieren. Üblich ist, dass sie zumindest so lange gespeichert bleiben wie die zugehörigen Zutrittsprotokolle, oft auch darüber hinaus. In vielen Unternehmen werden Alarmhistorien ein bis mehrere Jahre archiviert, weil sie für Trendanalysen und rückblickende Untersuchungen wertvoll sind. Es gibt keine starre gesetzliche Frist; maßgeblich ist der Zweck: Solange Alarme ausgewertet werden (ggf. auch in jährlichen Sicherheitsberichten) oder als Nachweis dienen könnten, dürfen sie aufbewahrt bleiben. Beispielsweise kann es sinnvoll sein, einen Brandalarm einige Jahre nachzuhalten für Versicherungsdokumentation. Trotzdem sollte eine Routine zur Bereinigung existieren, die sicherstellt, dass uralte Daten entfernt werden, um Speicher und Datenschutzrisiken zu minimieren. Ein möglicher Ansatz: Alarmdaten, die keinem konkreten Zwischenfall zugeordnet waren (also Fehlalarme), nach 1 Jahr löschen; echte sicherheitsvorfälle im Alarmprotokoll 3-5 Jahre aufbewahren, es sei denn, ein längerer Zeitraum ist erforderlich (z. B. bis zum Abschluss eines Gerichtsverfahrens). Insgesamt lehnt man sich oft an allgemeine Verjährungs- oder Aufbewahrungsfristen für interne Berichte an. Sind Alarme mit Personenbezug verbunden (z. B. „Mitarbeiter X hat Alarm durch Zutrittsverstoß ausgelöst“), müsste man abwägen, ob nach gewisser Zeit eine Anonymisierung erfolgen sollte. Praktisch bleibt jedoch oft der Personenbezug in den Protokollen enthalten, bis diese insgesamt gelöscht werden.

• Besondere Schutzmaßnahmen: Alarmmeldungen sind sicherheitskritische Echtzeitdaten, daher liegen Schwerpunkte auf Verfügbarkeit und rascher Übermittlung sowie anschließend Vertraulichkeit der Archivdaten. Zunächst müssen Alarme zuverlässig die richtigen Empfänger erreichen – hierfür werden dedizierte, ausfallsichere Kommunikationswege eingerichtet (z. B. redundante Netzwerkverbindungen, Notfall-Stromversorgung, regelmäßige Tests der Alarmierungseinrichtungen). Die Echtheit der Alarme ist wichtig (kein Fake-Alarm via Hacker): Daher sind Alarmketten oft in geschlossenen Systemen gehalten und werden verschlüsselt/ signiert übertragen. In der Speicherung unterscheiden sich die Schutzmaßnahmen wenig von anderen Logs: Zugriffsbeschränkung ist zentral, damit nur berechtigtes Personal vergangene Alarmdaten einsehen kann, da diese Daten viel über die Sicherheitslage und eventuelle Schwachstellen verraten. Zudem könnten Alarmereignisse indirekt sensible Informationen über Mitarbeiter enthalten (z. B. wenn jemand wiederholt Zutrittsalarme auslöst, könnte dies zu ungerechtfertigten Schlüssen führen). Daher gilt auch hier das Need-to-know-Prinzip – etwa nur Sicherheitsleitung und Datenschutzstelle dürfen umfassende Auswertungen sehen, während einzelne Vorfälle nur den unmittelbar Zuständigen bekannt gemacht werden. Technisch werden Alarmlogs oft in sicheren Archiven aufbewahrt; ein Export bedarf Autorisierung. Um Manipulation vorzubeugen, sollten Alarm- und Ereignislogs unveränderbar protokolliert sein (z. B. mittels Hash-Ketten oder WORM-Speicher), damit im Nachhinein kein Vorfall gelöscht oder verändert werden kann – dies ist wichtig für Audits und rechtliche Beweiskraft. Zusammengefasst: Die Schutzmaßnahmen fokussieren darauf, dass Alarmdaten korrekt, vollständig und vertraulich gehandhabt werden, da ein Versagen dieser Datenkategorie entweder die Sicherheit akut gefährdet (wenn Alarme nicht ankommen) oder rückblickend Aufklärung erschwert bzw. rechtliche Probleme schafft.

• Kurzbeschreibung: Neben den bisher genannten inhaltlichen Protokollen existieren auf Systemebene auch Logdateien, welche die internen Prozesse des Sicherheitsmanagementsystems aufzeichnen. Diese Logs umfassen z. B. Administrations- und Zugrifflogs (wer hat sich wann am Security-System angemeldet, Änderungen der Konfiguration vorgenommen, Berechtigungen erstellt oder gelöscht), Systemereignis-Logs (Start/Stop von Diensten, Software-Updates, Fehlermeldungen, Backup-Durchläufe) und Kommunikationslogs (Nachrichten zwischen Komponenten, Netzwerkverbindungen, evtl. API-Zugriffe). Sie sind vergleichbar mit IT-Server-Logs, jedoch spezifisch für das Zutritts- und Überwachungssystem. Darin finden sich typischerweise Zeitstempel, technische Aktionen und ggf. Benutzerkenner (z. B. Admin-Benutzername). Ein Beispiel: „2025-04-27 08:00:00 – ADMIN login von Console 1 erfolgreich“ oder „2025-04-27 08:05:00 – Zutrittsprofil ’Gebäude A‘ geändert durch Benutzer X“. Diese Logs helfen, die Nachvollziehbarkeit von Systembedienhandlungen zu gewährleisten. Personenbezug ist hier allenfalls indirekt vorhanden (die Benutzer könnten Mitarbeiter sein, aber in ihrer Rolle als Systemnutzer; oder IP-Adressen, die theoretisch auf Personen schließen lassen, aber i.d.R. sind es Geräte). Hauptsächlich sind es technische Aufzeichnungen.

• Zweck der Erfassung: System-Logs und Audit-Trails werden erfasst, um die Sicherheit und Integrität des Systems selbst sicherzustellen. Sie ermöglichen es, Eingaben und Veränderungen im System zu rekonstruieren: Sollte es z. B. zu einer unberechtigten Änderung einer Zutrittsberechtigung kommen, lässt sich nachvollziehen, welcher Admin-Account diese Änderung durchgeführt hat. Das dient sowohl der Fehleranalyse (bei technischen Problemen kann man in Logs die Ursache suchen) als auch der Missbrauchskontrolle (Aufdeckung, wenn jemand unbefugt Einstellungen manipuliert hat). Insbesondere in sicherheitskritischen Umgebungen ist ein Audit-Trail vorgeschrieben, um Compliance zu gewährleisten – z. B. ISO 27001 verlangt, dass administrative Zugriffe protokolliert werden. Die Logs helfen außerdem beim Leistungsmonitoring (etwa festzustellen, ob das System an Kapazitätsgrenzen stößt, wenn konstant Fehlermeldungen auftreten). Ein weiterer Zweck ist die forensische Analyse nach Sicherheitsvorfällen: Sollte ein Angriff auf das Zugangssystem stattfinden (physisch oder digital), liefern die System-Logs Indizien, wie es geschah. Organisatorisch sind diese Logs das Gedächtnis des Systems – ohne sie könnte man bei Störungen oder Verdacht auf Sabotage kaum nachträglich Erkenntnisse gewinnen. Ihre Erfassung erfolgt also aus einem kombinierten IT-Sicherheits- und Organisationsinteresse und z.T. aufgrund rechtlicher Verpflichtung, interne Kontrollsysteme vorzuhalten (in Unternehmen oft Bestandteil der IT-Compliance).

• Speicherort/System: Diese Logdateien liegen auf den jeweiligen Servern oder Geräten, die die Zutritts- und Sicherheitssoftware betreiben. Häufig schreibt etwa die Zutrittskontroll-Serversoftware lokale Logfiles (im Dateisystem oder in einer internen Logdatenbank). Größere Organisationen leiten kritische Logs an ein zentrales Log-Management oder SIEM weiter, um konsolidierte Auswertung zu ermöglichen und die Logs manipulationssicher zu speichern (z. B. unveränderbar). So könnte z. B. jede Administrator-Aktion im Zutrittssystem zeitgleich ins SIEM der IT gespiegelt werden, um dort Korrelationen mit anderen Ereignissen (Netzwerk, andere Systeme) zu ermöglichen. Primär liegen sie aber in der Domäne der Sicherheitsinfrastruktur. Auch die Geräte (Kameras, Controller) haben oft interne Logs; falls relevant, können diese entweder manuell ausgelesen werden (im Servicefall) oder sie werden in regelmäßigen Abständen an den zentralen Server übermittelt. Der Speicherort kann somit verteilt sein, aber am Ende sind die kritischen Audit-Daten idealerweise zentral gesichert. Zugriff auf Roh-Logdateien hat meist nur das IT-Administrationspersonal, während bestimmte Auswertungen (z. B. wer hat wann was geändert) auch dem Sicherheitsmanager über ein Frontend bereitgestellt werden können.

• Löschfrist: Für technische Logs gelten in erster Linie IT-intern festgelegte Aufbewahrungsdauern. Da sie keinen direkten Personenbezug haben (bis auf Admin-IDs), sind sie weniger datenschutzsensibel, aber trotzdem volumenreich. Viele Unternehmen bewahren System-Logs für 6 bis 12 Monate online auf, ältere Logs werden ins Archiv ausgelagert oder gelöscht. Manche speziellen Audit-Trails, insbesondere für sicherheitskritische Bereiche, werden länger aufbewahrt, manchmal mehrere Jahre, falls sie für eventuelle Rückfragen (z. B. bei einer Revision) dienen könnten. Beispielsweise kann das interne Kontrollsystem vorschreiben, dass Protokolle über administrative Zugriffe 3 Jahre aufzubewahren sind, analog zu finanzrelevanten Daten. Wenn kein solcher Zwang besteht, orientiert man sich oft an pragmatischen Kriterien: Speicherkapazität und Nützlichkeit. Nach einer gewissen Zeit sind die meisten technischen Logs obsolet, weil Software-Versionen sich ändern oder etwaige Probleme längst behoben sind. Wichtig ist aber, dass während der aktiven Nutzungsphase genügend Loghistorie vorhanden ist, um schleichende Entwicklungen zu erkennen (z. B. sich häufende Fehlermeldungen). Eine mögliche Praxis: detailreiche Debug-Logs nur 1 Monat, normaler Audit-Trail 1 Jahr, komprimierte Zusammenfassungen evtl. länger. Werden Logs ins SIEM übertragen, kann dort ebenfalls eine Policy greifen (oft 1–2 Jahre Online, danach Offline-Archiv). Insgesamt sind Löschfristen hier eher von internen Richtlinien und Speicherplänen bestimmt, weniger von Gesetz – wobei Kritikalität der Daten (z. B. im Bankenumfeld wäre man strenger) berücksichtigt wird.

• Besondere Schutzmaßnahmen: Diese systeminternen Logs müssen vor allem vollständig und unverfälscht sein. Daher sollten sie gegen nachträgliche Manipulation geschützt werden – z. B. durch Write-Once-Speicherung oder regelmäßige Backups, sodass ein Angreifer nicht einfach Spuren verwischen kann, indem er Logs löscht. Zugriff auf die Rohlogs ist stark eingeschränkt (nur Systemadmin). Oft werden Logs fortlaufend überwacht: Ein SIEM kann Alarme schlagen, wenn z. B. jemand versucht, eine Logdatei zu löschen oder wenn auffällige Muster auftauchen (etwa wiederholte Admin-Login-Fehler, die auf einen Angriff hindeuten). Vertraulichkeit ist auch relevant, denn obwohl hier kaum personenbezogene Daten stehen, könnten Logs Passwörter oder Pfade enthalten, die Sicherheitsrelevant sind. Deswegen wird auch hier Verschlüsselung oder zumindest interne Abschottung umgesetzt. Bei der Entsorgung (Löschen) muss sichergestellt sein, dass keine unberechtigte Kopie existiert; deshalb werden alte Logfiles sicher überschrieben oder vernichtet. Einige Organisationen klassifizieren bestimmte Logs als vertrauliche Informationen – in so einem Fall würden sie wie andere vertrauliche Unterlagen behandelt (Zugang nur nach Vier-Augen-Prinzip etc.). Ein oft angewandtes Prinzip ist zudem die Minimalprotokollierung personenbezogener Elemente: Wenn z. B. Admin-Logs Mitarbeiter-Namen enthalten, könnte man stattdessen User-IDs loggen und die Zuordnung separat halten, um den direkten Personenbezug zu reduzieren (sofern datenschutzrechtlich relevant). Summa summarum sind die Schutzmaßnahmen hier Teil der allgemeinen IT-Security: Zugangskontrolle, Integritätssicherung, Backup und Monitoring, um sowohl die Vertraulichkeit als auch die Verfügbarkeit der Logs zu gewährleisten, denn sie sind für die Sicherheitsarchitektur unverzichtbar.

Neben den personenbezogenen und den primär technischen Systemdaten existieren weitere Daten, die im Rahmen des Sicherheitsmanagementsystems anfallen können und nicht unmittelbar in die obigen Kategorien passen. Diese sonstigen Daten sind häufig abgeleitete, verdichtete oder anonymisierte Informationen, die aus den operativen Daten generiert werden, oder sie sind Meta-Informationen, die für den Betrieb hilfreich sind. Sie unterliegen meist nicht strengen gesetzlichen Datenschutzvorgaben (weil entweder kein Personenbezug besteht oder dieser entfernt wurde), doch sind sie trotzdem mit Sorgfalt zu behandeln. Insbesondere können daraus Rückschlüsse auf Sicherheitsniveau und interne Abläufe gezogen werden, weshalb sie schutzbedürftig als Betriebsgeheimnis gelten können. Die wichtigsten sonstigen Datenkategorien sind:

• Kurzbeschreibung: Statistische Auswertungen und Berichte, die aus den Rohdaten des Zutritts- und Sicherheitssystems gewonnen werden, jedoch keine individuellen Personenbezüge mehr aufweisen. Beispiele: Gesamtzahl der Zutritte pro Tag/Woche, Verteilung der Zutritte auf Zeiträume (Stoßzeiten), Anzahl der Besucher pro Monat, Häufigkeit bestimmter Alarmtypen, durchschnittliche Verweildauer von Besuchern, etc. Diese Statistiken können in Tabellen, Grafiken oder Kennzahlen dargestellt sein. Wichtig ist, dass sie aggregiert oder anonymisiert sind – d.h. keine konkreten Namen oder Personenschlüssel mehr enthalten, sondern nur Summen, Durchschnitte, Trends. Mitunter werden auch Daten pseudonymisiert ausgewertet (z. B. pro Abteilung statt pro Person). Auch Berichte für Management (z. B. ein monatlicher Sicherheitsreport) fallen hierunter, wenn sie keine einzelnen Vorfälle mit personalisierten Details aufführen, sondern einen Überblick geben.

• Zweck der Erfassung: Solche Statistiken werden erzeugt, um Trends und Muster im Sicherheitsgeschehen zu erkennen und das Sicherheitsmanagement zu verbessern. Beispielsweise hilft die Auswertung der Zutrittsfrequenzen, Personal und Technik bedarfsgerecht zu planen (mehr Security Personal bei hohem Besucherandrang, zusätzliche Schleusen zu Stoßzeiten öffnen etc.). Die Analyse von Alarmhäufigkeiten kann Schwachstellen offenbaren, wie bereits erwähnt, oder den Erfolg von Maßnahmen (Rückgang von Alarmen nach Verbesserungen). Zudem dienen anonymisierte Berichte der Rechenschaft und Dokumentation gegenüber der Unternehmensleitung oder Aufsichtsorganen: Man kann belegen, dass Sicherheitsprozesse funktionieren (z. B. „In 2024 wurden X unautorisierte Zutrittsversuche erkannt und verhindert“). Da diese Daten keiner Person zugeordnet sind, können sie frei für wissenschaftliche oder statistische Zwecke im Unternehmen genutzt werden, was mit personenbezogenen Daten oft nur eingeschränkt möglich ist. Auch im Sinne des Datenschutzes selbst sind Anonymisierungen sinnvoll: Anstatt im Alltag immer personenbezogen zu schauen („Welcher Mitarbeiter kam zu spät?“), kann man auf aggregierter Ebene Monitoring betreiben („Wie viele Spätzugänge gibt es?“), was die Privatsphäre schont. Organisatorisch ermöglichen Statistiken auch ein Reporting an den Betriebsrat oder Datenschutzbeauftragten, um zu zeigen, dass Regeln eingehalten werden (z. B. wie schnell werden Besucherdaten gelöscht, wie viele Datenauskunftsanfragen gab es etc., je nachdem ob das System solche Meta-Infos bereitstellt). Insgesamt ist der Zweck hier die Gewinnung von Erkenntnissen aus den Sicherheitsdatenbeständen, zur kontinuierlichen Verbesserung und Kontrolle der Wirksamkeit der Sicherheitsmaßnahmen, ohne dabei individualisierte Daten zu verwenden.

• Speicherort/System: Die statistischen Auswertungen können entweder ad-hoc erzeugt werden (z. B. über Abfragen im System oder BI-Tools, die auf die Datenbank zugreifen) oder als Berichtsdokumente gespeichert werden. Viele Sicherheitsmanagementsysteme bieten integrierte Reporting-Module, die periodisch Berichte erstellen und beispielsweise als PDF, Excel oder in einem internen Portal ablegen. Falls die Daten ins Data Warehouse der Firma einfließen, können sie dort mit anderen Kennzahlen verknüpft und in Dashboards dargestellt werden. Wichtig ist, dass die Rohdaten für die Statistik aus den operativen Systemen stammen (Zutrittslogs, Alarmdaten, etc.), aber für die anonymisierte Form werden Personenmerkmale entfernt. Der Speicherort solcher Berichte ist oft das Dateisystem (Netzlaufwerk der Sicherheitsabteilung) oder ein Reporting-System. Da diese Berichte oft auch Management zugänglich gemacht werden, liegen sie möglicherweise in weniger geschützten Umgebungen (z. B. im Intranet veröffentlicht). Jedoch sind sie streng genommen vertrauliche betriebliche Informationen, weshalb eine Ablage in gesicherten internen Bereichen ratsam ist.

• Löschfrist: Anonymisierte Statistiken sind datenschutzrechtlich nicht problematisch, weil kein Personenbezug besteht – daher gibt es keine gesetzlichen Vorgaben, sie zu löschen. Viele dieser Auswertungen haben jedoch nur begrenzte Aktualitätsrelevanz (z. B. monatliche Reports, Jahresberichte). Man bewahrt sie oft so lange auf, wie sie für Vergleichszwecke dienen. Beispielsweise kann es nützlich sein, mehrere Jahre an Sicherheitsberichten zu archivieren, um Entwicklungen über Zeit zu sehen. Aus Praktikabilitätsgründen wird man aber irgendwann ältere Auswertungen aussortieren, wenn z. B. das Sicherheitskonzept völlig verändert wurde (dann sind alte Statistiken nicht mehr vergleichbar). Insofern gibt es hier eher Aufbewahrungs- statt Löschfristen: Meist werden solche Berichte analog zu geschäftlichen Unterlagen einige Jahre behalten (z. B. 3-5 Jahre), oder dauerhaft, wenn sie in großen Jahresreports einfließen. Da sie keine personenbezogenen Daten enthalten, ist ihre Aufbewahrung allein eine Frage des Platzes und der Übersicht. Dennoch sollte ein Archivierungskonzept vorhanden sein, um Informationen, die sicherheitsrelevant sein könnten, nicht unkontrolliert ewig liegen zu lassen. Sollte aus Versehen doch personenbeziehbares in einer Statistik stehen (z. B. ein Diagramm mit einzelnen Ausreißern, die auf Personen rückschließen lassen), müsste das natürlich bereinigt werden. Grundsätzlich kann man aber sagen: Keine spezifische Löschfrist, Aufbewahrung nach betrieblichem Nutzen.

• Besondere Schutzmaßnahmen: Obwohl anonymisierte Sicherheitsstatistiken keine personenbezogenen Daten enthalten, sind sie für das Unternehmen sicherheitssensitiv. Aus ihnen lässt sich z. B. ablesen, wie häufig sicherheitsrelevante Zwischenfälle passieren, wann das Gelände stark frequentiert ist, oder welche Bereiche relative Schwachstellen haben (wenn z. B. viele Zutrittsalarme an einem Tor gemeldet wurden). Solche Informationen könnten von Angreifern oder unerwünschten Dritten ausgenutzt werden, wenn sie bekannt würden. Daher werden diese Auswertungen als vertraulich eingestuft. Die Verteilung erfolgt nur intern an berechtigte Kreise (Geschäftsführung, Sicherheitsverantwortliche, ggf. Betriebsrat im Rahmen der vereinbarten Berichte). Technisch sollten gespeicherte Berichte durch Zugriffsrechte geschützt sein (z. B. nur die Sicherheitsabteilung hat Zugriff auf das entsprechende Verzeichnis). Werden sie per E-Mail versandt, dann möglichst verschlüsselt oder im Intranet hinter Passwort. Ein weiteres Augenmerk: Richtigkeit und Anonymität – es muss geprüft werden, dass wirklich keine Einzelpersonen erkennbar sind, und dass die Daten korrekt aggregiert wurden (Fehler könnten zu falschen Sicherheitsentscheidungen führen). Wenn Berichte extern gegeben werden (z. B. an einen Berater oder Auditor), ist sicherzustellen, dass keine personenbezogenen Daten herausgegeben werden – hier zeigt die Anonymisierung ihre Stärke, diese Gefahr zu minimieren. Letztlich sind die Schutzmaßnahmen hier vergleichbar mit denen für interne Berichte: Zugangsbeschränkung, Integritätsschutz (damit Zahlen nicht unbemerkt verändert werden) und Sicherstellung der fortlaufenden Verfügbarkeit (z. B. durch Ablage in einem dokumentierten Archivsystem).

• Kurzbeschreibung: Unter technischen Metadaten fassen wir verschiedene unterstützende Datenpunkte zusammen, die bei Betrieb des Systems anfallen oder für dessen Konfiguration benötigt werden, ohne selbst Kerninhalt der Zutritts- oder Überwachungsfunktion zu sein. Beispiele: Konfigurationsdaten wie Lagepläne, Raum- und Türbezeichnungen, Hierarchien von Sicherheitszonen, Berechtigungsprofil-Namen; Netzwerk- und Geräte-Metadaten wie IP-Adressen der Kameras, Firmware-Versionen, Seriennummern der Kartenleser, installierte Software-Version des Zutrittsmanagement-Servers; Zeitstempel und Synchronisationsdaten (z. B. Zeiten von Zeitsynchronisationsservern); Kalenderdaten (Feiertagskalender, Schichtpläne, sofern ins System eingepflegt für zeitabhängige Berechtigungen) und Systemparameter (Passwortrichtlinien für die Software, Timeout-Einstellungen, etc.). Diese Informationen sind meist nicht direkt Ergebnis einer Erfassung, sondern entweder manuell eingepflegt bei der Einrichtung des Systems oder automatisch generiert (z. B. Logs der Softwareversion bei Update). Der Personenbezug fehlt in der Regel – es sind Daten über das System und die Struktur, nicht über einzelne Zutritte. (Allenfalls könnte man argumentieren, ein Berechtigungsprofil „Vorstand“ indirekt bezieht sich auf Personen der Vorstandsebene, aber das Profil selbst enthält keine personenbezogenen Details).

• Zweck der Erfassung: Diese Metadaten sind notwendig, um das System ordnungsgemäß konfigurieren und betreiben zu können. Ohne Konfigurationsdaten wüsste das System nicht, welche Türen es gibt, welche Zonen definiert sind oder welche Öffnungszeitprofile gelten. Das Pflegen dieser Daten ist eine organisatorische Notwendigkeit, um die technischen Sicherheitsmaßnahmen passgenau auf die Gegebenheiten abzustimmen. Beispielsweise müssen Lagepläne und Gerätedaten hinterlegt sein, damit ein Alarm in „Sektor B1“ vom Personal schnell einem realen Ort zugeordnet werden kann. Netzwerk- und Softwaredaten sind wichtig für Wartung und IT-Sicherheit – man muss wissen, welche Versionen im Einsatz sind, um Updates zu planen, oder IP-Adressen kennen, um die Kommunikation zu schützen. Zeitliche Metadaten (Kalender) ermöglichen es, Zugänge zeitabhängig zu steuern (z. B. Besucher nur werktags 8-17 Uhr), was die Sicherheit erhöht und zugleich Flexibilität bietet. Kurz gesagt, diese Metadaten bilden das Rückgrat der Systemfunktionalität: Sie werden nicht um ihrer selbst willen erfasst, sondern um die Basisdaten für alle Sicherheitsprozesse bereitzustellen. Außerdem ermöglichen sie die Dokumentation der Sicherheitsinfrastruktur, was für Audits (z. B. Prüfung durch Versicherungen oder Zertifizierer) essenziell sein kann – z. B. verlangt ein Audit eventuell eine Liste aller sicherheitsrelevanten Geräte und deren Standorte. Die Erfassung und Pflege dieser Daten folgt also aus dem inneren Bedarf des Systems und den organisatorischen Vorgaben (wer darf wo rein, wann sind Zugänge offen, etc.), und letztlich auch aus Sorgfaltspflichten, ein aktuelles Inventar der Sicherheitskomponenten zu halten.

• Speicherort/System: Konfigurations- und Metadaten werden innerhalb des Sicherheitsmanagementsystems in Konfigurationsdateien, Datenbanktabellen oder speziellen Verwaltungsmodulen gehalten. Bei der Inbetriebnahme einer Zutrittskontrollanlage legt ein Techniker z. B. alle Türen mit IDs und Namen an, die in der Datenbank gespeichert werden. Berechtigungsprofile und -regeln werden via Management-Software eingegeben und dort gesichert. Technische Parameter könnten in Ini-Dateien oder im Anwendungscode hinterlegt sein. Größere Systeme bieten oft einen Export/Import dieser Konfiguration (z. B. um Einstellungen zu sichern oder zu übertragen), was dann in XML/JSON-Format oder Ähnlichem geschieht. Die Lagepläne und Übersichtszeichnungen werden entweder im System (als Grafik hinterlegt und mit Sensoren verknüpft) oder getrennt in Dokumentationen verwaltet. Netzwerkinformationen können Teil der IT-Dokumentation sein, überschneiden sich aber mit dem Sicherheitsinventar. Meist existiert ein Systemhandbuch oder eine digitale Konfigurationsübersicht, die von den Administratoren gepflegt wird. Ein Teil der Metadaten (wie Firmware-Version) kann auch direkt im Gerät stecken und nur bei Bedarf ausgelesen werden. In summe liegen diese Daten verteilt: was zur Laufzeit nötig ist, steckt im System; was nur dokumentarisch ist, evtl. in separaten Dateien. Zugriff darauf haben in erster Linie die Systemadministratoren und gegebenenfalls Servicetechniker.

• Löschfrist: Solange das Sicherheitssystem betrieben wird, müssen die Konfigurationsdaten aktuell gehalten werden – eine Löschung kommt hier eher im Rahmen von Änderungen oder Außerbetriebnahme vor. Bei Änderungen werden Daten aktualisiert (z. B. ein altes Türenprofil gelöscht, wenn eine Tür ausgebaut wird), wobei man historisch oft ein Backup behält. Eine generelle „Löschfrist“ existiert für solche Daten nicht, da sie ja gerade die Grundlage für den Betrieb sind. Wenn das gesamte System außer Dienst gestellt wird (z. B. bei Austausch), sollten die Konfigurationsdaten als Teil der Dokumentation archiviert oder datenschutzkonform entsorgt werden. Da sie kaum personenbezogen sind, gibt es keine datenschutzrechtliche Vorgabe zur Löschung, aber aus Sicherheitsgründen sollte man veraltete Konfigurationen nicht ewig herumliegen lassen (könnten Angreifern Hinweise geben, falls in falsche Hände). Ein möglicher Ansatz: Nach Migration auf ein neues System werden die alten Datenbestände noch eine gewisse Zeit aufbewahrt (für eventuelle Fragen oder rechtliche Belange), dann gelöscht. Ein Beispiel: Ein Werk behält die alten Pläne und Listen 1-2 Jahre für audit trail, danach werden sie ins Archiv oder vernichtet. Grundsätzlich gilt: aktuelle Konfiguration aktuell halten; veraltete Konfiguration entfernen, sobald sie nicht mehr benötigt wird.

• Besondere Schutzmaßnahmen: Diese technischen Metadaten mögen unscheinbar wirken, doch enthalten sie den „Bauplan“ der Sicherheitsinfrastruktur – damit sind sie aus Sicherheitssicht hochgradig schützenswert. Würden Unbefugte die vollständige Konfiguration erlangen, kennen sie sämtliche Türen, Alarmanlagen, vielleicht sogar wo Schwachstellen sein könnten (z. B. keine Kameraabdeckung). Daher werden Konfigurationsdaten streng vertraulich behandelt. Zugriff darf nur der engste technische Kreis haben; oft sind sie passwortgeschützt oder verschlüsselt gespeichert (zumindest sensible Teile, wie Administrator-Passwörter oder Kryptoschlüssel, werden nicht in Klartext abgelegt). Backups dieser Daten werden sicher verwahrt (z. B. im Tresor oder auf einem offline-Medium), da die Verfügbarkeit ebenfalls kritisch ist – ein Verlust der Konfiguration könnte den Betrieb lahmlegen. Integrität ist entscheidend: Ein manipulierter Parameter (z. B. geändertes Zeitprofil) könnte Türen unerwartet offen lassen oder Alarme unterdrücken. Deshalb gibt es Change-Management-Prozesse: Änderungen nur durch authentifizierte Admins, idealerweise nach Vier-Augen-Prinzip, und Dokumentation jeder Änderung (wiederum in den System-Logs festgehalten). Teil der Schutzmaßnahmen ist auch die Limitierung von Schnittstellen: Falls das System Konfigurationsdaten import/export erlaubt, wird diese Funktion abgesichert, um nicht als Einfallstor zu dienen. In Bezug auf Datenschutz: Die meisten dieser Metadaten enthalten keine personenbezogenen Informationen, so dass hier vor allem Informationssicherheit (Vertraulichkeit, Integrität, Verfügbarkeit) im Vordergrund steht, nicht Personenbezogener Datenschutz. Allerdings können indirekt sensible Informationen drin sein (z. B. Profilname „Vorstandszimmer“ verrät, wo der Vorstand sitzt) – aber das fällt eher unter Geheimhaltung aus Unternehmenssicht. Insgesamt gilt: Konfigurations- und Metadaten werden wie streng vertrauliche technische Dokumentation gehandhabt, mit entsprechenden Zutritts- und Zugriffskontrollen (sowohl physisch als auch digital), Berechtigungsmanagement, Verschlüsselung und Backup.

Abschließend ist festzuhalten, dass alle genannten Datenarten in einem integrativen Sicherheitssystem eng miteinander verzahnt sind. Personenbezogene Daten bilden die Grundlage dafür, „wer“ Zugang hat; Systemdaten gewährleisten das „wie“ (die zuverlässige technische Umsetzung); und sonstige Daten erlauben es, aus dem „was passiert ist“ zu lernen und die Sicherheit kontinuierlich zu verbessern. Die Erfassung jeder Datenart ist durch berechtigte Zwecke motiviert – sei es die Sicherheit von Mensch und Anlage, die Erfüllung von Vorschriften oder effiziente Organisation. Gleichzeitig müssen alle Erhebungen im Lichte des Datenschutzes und der Verhältnismäßigkeit stehen: so viel wie nötig, so wenig wie möglich. Durch definierte Löschfristen, Zugriffsbeschränkungen und weitere Schutzmaßnahmen wird sichergestellt, dass die Daten ihrer Funktion dienen, ohne unkontrolliert zum Risiko zu werden. Dieses Verzeichnis kann als Bestandteil des Datenschutz- und Sicherheitskonzeptes des Industriebetriebs dienen und würde typischerweise auch im Rahmen eines Verzeichnisses von Verarbeitungstätigkeiten (Art. 30 DSGVO) herangezogen werden, um gegenüber Aufsichtsbehörden transparent zu machen, welche Daten im Zutritts- und Sicherheitsmanagement verarbeitet werden und warum.

• Datenschutz-Grundverordnung (DSGVO) : EU-Verordnung 2016/679, insbesondere Art. 6 Abs. 1 lit. f (berechtigtes Interesse als Rechtsgrundlage für Sicherheitsdatenerfassung), Art. 5 (Datenminimierung, Zweckbindung), Art. 17 (Löschpflicht), Art. 32 (Sicherheit der Verarbeitung – technische und organisatorische Maßnahmen).

• Bundesdatenschutzgesetz (BDSG) : Nationale Ergänzungen zur DSGVO, z. B. §26 BDSG (Datenverarbeitung im Beschäftigungskontext, relevant für Mitarbeiter-Zutrittsdaten) und ggf. §4 BDSG (Videoüberwachung öffentlich zugänglicher Räume, soweit anwendbar auf Werksgeländebereiche).

• Betriebsverfassungsgesetz (BetrVG) : Insbesondere § 87 Abs. 1 Nr. 6 BetrVG (Mitbestimmungsrecht des Betriebsrats bei Einführung und Anwendung technischer Überwachungseinrichtungen). Integrierte Zutritts- und Überwachungssysteme müssen daher in enger Abstimmung mit dem Betriebsrat betrieben werden, was in Betriebsvereinbarungen festzuhalten ist.

• ISO/IEC 27001 : Internationaler Standard für Informationssicherheits-Management. Forderungen nach Zugangskontrollmechanismen und Logging decken sich mit genannten Zwecken. Die aufgeführten Maßnahmen (Audit-Trails, Zugriffsbeschränkungen) orientieren sich an diesen Best Practices.

• Beispielhafte unternehmensinterne Richtlinien wie Löschkonzepte und Sicherheitsrichtlinien (z. B. Löschkonzept nach DSGVO, hier angewandt auf Besucherlisten mit 4-Wochen-Frist, oder Vorgaben zur Protokollierung und Aufbewahrung aus internen Compliance-Vorschriften).