ISO/IEC 27001:2022
ISO-27001-Software, die zeigt,
wo sie nicht hilft
Ein Anbieter, der bei 93 von 93 Controls einen Haken setzt, hat entweder die Norm nicht gelesen oder hofft, dass Sie es nicht getan haben. Hier steht, was aus dem Betrieb heraus belegbar ist, was teilweise trägt und was Ihre Organisation selbst leisten muss.
- 93Controls in der Erklärung zur Anwendbarkeit
- 27davon mit Nachweis aus dem laufenden Betrieb
- 5Klauseln des Managementsystems abgebildet
Annex A im Überblick
Die ganze Karte, nicht nur die grünen Felder
A.5 Organisatorisch 19/37
- 5.1 A.5.1 Informationssicherheitsrichtlinien Nachweis im System
- 5.2 A.5.2 Rollen und Verantwortlichkeiten nur in der SoA geführt
- 5.3 A.5.3 Aufgabentrennung nur in der SoA geführt
- 5.4 A.5.4 Verantwortlichkeiten der Leitung nur in der SoA geführt
- 5.5 A.5.5 Kontakt mit Behörden nur in der SoA geführt
- 5.6 A.5.6 Kontakt mit Interessengruppen nur in der SoA geführt
- 5.7 A.5.7 Bedrohungsintelligenz nur in der SoA geführt
- 5.8 A.5.8 Informationssicherheit im Projektmanagement nur in der SoA geführt
- 5.9 A.5.9 Inventar der Werte Nachweis im System
- 5.10 A.5.10 Zulässiger Gebrauch von Werten nur in der SoA geführt
- 5.11 A.5.11 Rückgabe von Werten Nachweis im System
- 5.12 A.5.12 Klassifizierung von Informationen nur in der SoA geführt
- 5.13 A.5.13 Kennzeichnung von Informationen nur in der SoA geführt
- 5.14 A.5.14 Informationsübertragung nur in der SoA geführt
- 5.15 A.5.15 Zugangssteuerung Nachweis im System
- 5.16 A.5.16 Identitätsmanagement Nachweis im System
- 5.17 A.5.17 Authentisierungsinformation Nachweis im System
- 5.18 A.5.18 Zugangsrechte Nachweis im System
- 5.19 A.5.19 Informationssicherheit in Lieferantenbeziehungen Nachweis im System
- 5.20 A.5.20 Sicherheit in Lieferantenvereinbarungen Nachweis im System
- 5.21 A.5.21 Sicherheit in der IKT-Lieferkette Nachweis im System
- 5.22 A.5.22 Überwachung von Lieferantendienstleistungen Nachweis im System
- 5.23 A.5.23 Sicherheit bei Cloud-Diensten nur in der SoA geführt
- 5.24 A.5.24 Vorbereitung der Vorfallbehandlung Nachweis im System
- 5.25 A.5.25 Beurteilung von Sicherheitsereignissen Nachweis im System
- 5.26 A.5.26 Reaktion auf Sicherheitsvorfälle Nachweis im System
- 5.27 A.5.27 Erkenntnisse aus Vorfällen Nachweis im System
- 5.28 A.5.28 Sammeln von Beweismaterial nur in der SoA geführt
- 5.29 A.5.29 Informationssicherheit während einer Störung Nachweis im System
- 5.30 A.5.30 IKT-Bereitschaft für Betriebskontinuität Nachweis im System
- 5.31 A.5.31 Rechtliche und vertragliche Anforderungen nur in der SoA geführt
- 5.32 A.5.32 Geistige Eigentumsrechte nur in der SoA geführt
- 5.33 A.5.33 Schutz von Aufzeichnungen Nachweis im System
- 5.34 A.5.34 Schutz personenbezogener Daten nur in der SoA geführt
- 5.35 A.5.35 Unabhängige Überprüfung nur in der SoA geführt
- 5.36 A.5.36 Einhaltung von Richtlinien und Normen nur in der SoA geführt
- 5.37 A.5.37 Dokumentierte Betriebsabläufe Nachweis im System
A.6 Personenbezogen 2/8
- 6.1 A.6.1 Sicherheitsüberprüfung nur in der SoA geführt
- 6.2 A.6.2 Beschäftigungs- und Vertragsbedingungen nur in der SoA geführt
- 6.3 A.6.3 Bewusstsein, Ausbildung und Schulung Nachweis im System
- 6.4 A.6.4 Maßregelungsprozess nur in der SoA geführt
- 6.5 A.6.5 Verantwortlichkeiten bei Beendigung Nachweis im System
- 6.6 A.6.6 Geheimhaltungsvereinbarungen nur in der SoA geführt
- 6.7 A.6.7 Arbeiten aus der Ferne nur in der SoA geführt
- 6.8 A.6.8 Meldung von Sicherheitsereignissen nur in der SoA geführt
A.7 Physisch 0/14
- 7.1 A.7.1 Physische Sicherheitsperimeter nur in der SoA geführt
- 7.2 A.7.2 Physischer Zutritt nur in der SoA geführt
- 7.3 A.7.3 Sichern von Räumen und Einrichtungen nur in der SoA geführt
- 7.4 A.7.4 Physische Sicherheitsüberwachung nur in der SoA geführt
- 7.5 A.7.5 Schutz vor physischen Bedrohungen nur in der SoA geführt
- 7.6 A.7.6 Arbeiten in Sicherheitsbereichen nur in der SoA geführt
- 7.7 A.7.7 Aufgeräumter Arbeitsplatz nur in der SoA geführt
- 7.8 A.7.8 Platzierung und Schutz von Geräten nur in der SoA geführt
- 7.9 A.7.9 Sicherheit von Werten außerhalb nur in der SoA geführt
- 7.10 A.7.10 Speichermedien nur in der SoA geführt
- 7.11 A.7.11 Versorgungseinrichtungen nur in der SoA geführt
- 7.12 A.7.12 Sicherheit der Verkabelung nur in der SoA geführt
- 7.13 A.7.13 Instandhaltung von Geräten nur in der SoA geführt
- 7.14 A.7.14 Sichere Entsorgung oder Wiederverwendung nur in der SoA geführt
A.8 Technologisch 8/34
- 8.1 A.8.1 Endpunktgeräte des Benutzers teilweise
- 8.2 A.8.2 Privilegierte Zugangsrechte nur in der SoA geführt
- 8.3 A.8.3 Informationszugangsbeschränkung nur in der SoA geführt
- 8.4 A.8.4 Zugang zum Quellcode nur in der SoA geführt
- 8.5 A.8.5 Sichere Authentisierung Nachweis im System
- 8.6 A.8.6 Kapazitätssteuerung nur in der SoA geführt
- 8.7 A.8.7 Schutz gegen Schadsoftware nur in der SoA geführt
- 8.8 A.8.8 Handhabung technischer Schwachstellen Nachweis im System
- 8.9 A.8.9 Konfigurationsmanagement Nachweis im System
- 8.10 A.8.10 Löschung von Informationen nur in der SoA geführt
- 8.11 A.8.11 Datenmaskierung nur in der SoA geführt
- 8.12 A.8.12 Verhinderung von Datenlecks nur in der SoA geführt
- 8.13 A.8.13 Sicherung von Informationen Nachweis im System
- 8.14 A.8.14 Redundanz von Einrichtungen nur in der SoA geführt
- 8.15 A.8.15 Protokollierung Nachweis im System
- 8.16 A.8.16 Überwachungstätigkeiten teilweise
- 8.17 A.8.17 Uhrensynchronisation nur in der SoA geführt
- 8.18 A.8.18 Privilegierte Hilfsprogramme nur in der SoA geführt
- 8.19 A.8.19 Installation von Software im Betrieb nur in der SoA geführt
- 8.20 A.8.20 Netzwerksicherheit nur in der SoA geführt
- 8.21 A.8.21 Sicherheit von Netzwerkdiensten nur in der SoA geführt
- 8.22 A.8.22 Trennung von Netzwerken nur in der SoA geführt
- 8.23 A.8.23 Webfilterung nur in der SoA geführt
- 8.24 A.8.24 Gebrauch von Kryptographie nur in der SoA geführt
- 8.25 A.8.25 Sicherer Entwicklungslebenszyklus nur in der SoA geführt
- 8.26 A.8.26 Anforderungen an die Anwendungssicherheit nur in der SoA geführt
- 8.27 A.8.27 Sichere Systemarchitektur nur in der SoA geführt
- 8.28 A.8.28 Sicheres Codieren nur in der SoA geführt
- 8.29 A.8.29 Sicherheitsprüfung in Entwicklung und Abnahme nur in der SoA geführt
- 8.30 A.8.30 Ausgegliederte Entwicklung nur in der SoA geführt
- 8.31 A.8.31 Trennung von Entwicklung, Test und Betrieb nur in der SoA geführt
- 8.32 A.8.32 Änderungsmanagement Nachweis im System
- 8.33 A.8.33 Testinformationen nur in der SoA geführt
- 8.34 A.8.34 Schutz während Auditprüfungen nur in der SoA geführt
Die Erklärung zur Anwendbarkeit führt alle 93 Controls — auch die, die für Sie nicht anwendbar sind, denn auch das will begründet sein. Bei 27 davon entsteht der Nachweis aus dem laufenden Betrieb, ohne dass jemand ihn für das Audit noch einmal zusammenträgt. Physische Sicherheit (A.7) gehört bewusst nicht dazu: Ein Zaun lässt sich nicht in Software belegen.
Der Hauptteil der Norm
Ein Managementsystem ist mehr als 93 Maßnahmen
Die Klauseln 4 bis 10 sind der Teil, an dem Zertifizierungen tatsächlich scheitern — und der Teil, den Werkzeuge dieser Kategorie meist gar nicht anfassen.
| Anforderung | Wie sie abgebildet ist | Modul |
|---|---|---|
| Klausel 4 — Kontext | Geltungsbereich mit begründungspflichtigen Ausschlüssen, interne und externe Themen, interessierte Parteien mit Kennzeichnung bindender Verpflichtungen, Freigabe durch die Leitung mit jährlicher Überprüfung. | Managementsystem |
| Klausel 5.2 — Leitlinie | Die Informationssicherheitsleitlinie als Führungsdokument bleibt Ihre Aufgabe. Das Modul Richtlinien lenkt sie: unveränderliche Fassungen, Freigabe, Kenntnisnahme je Fassung. | Richtlinien |
| Klausel 6.1 — Risiken | Risikoregister mit Brutto- und Nettobewertung von 1 bis 25, Maßnahmenplan und dokumentierter Akzeptanz. Ab Restrisiko 12 ist die Akzeptanz durch die Leitung erzwungen. | Risiken |
| Klausel 6.1.3 — SoA | Erklärung zur Anwendbarkeit über alle 93 Annex-A-Controls: anwendbar oder begründet nicht anwendbar, mit Verweis auf die Umsetzung. | Risiken |
| Klausel 6.2 — Ziele | Messgröße und Zielwert sind Pflicht, die Richtung („mindestens" / „höchstens") wird bei der Bewertung berücksichtigt, Istwerte kommen aus den Kennzahlen. | Managementsystem |
| Klausel 7.5 — Dokumentierte Information | Gelenkte Dokumente mit Fassungsverlauf, Freigabe und Kenntnisnahme. Eine inhaltliche Änderung hebt die Freigabe automatisch auf. | Richtlinien |
| Klausel 9.1 — Bewertung | Kennzahlen über Servicedesk, Änderungsmanagement, Sicherheit, Risiken und organisatorische Nachweise — jede mit genannter Grundgesamtheit und Zielwert. | Kennzahlen |
| Klausel 9.2 — Internes Audit | Auditprogramm mit Kriterien, geprüften Controls und dokumentierter Unabhängigkeit des Auditors. Die Abdeckungsanzeige belegt, dass über den Zyklus alle anwendbaren Controls geprüft werden. | Managementsystem |
| Klausel 9.3 — Managementbewertung | Alle sieben von 9.3.2 vorgeschriebenen Eingaben sind Pflicht, die Ergebnisse nach 9.3.3 ebenfalls. Der Datenstand wird eingefroren, die Freigabe ist der Leitung vorbehalten, danach ist die Bewertung unveränderlich. | Managementsystem |
| Klausel 10.1 — Korrekturmaßnahmen | Ein gemeinsames Register für Feststellungen aus Audits, Vorfällen, Lieferantenbewertungen, Rezertifizierungen und Notfallübungen. Ohne ermittelte Ursache keine Maßnahme, ohne bestätigte Wirksamkeit kein Abschluss. | Managementsystem |
Ausgewählte Controls im Detail
Wo genau der Nachweis liegt
Nicht „unterstützt A.8.8", sondern: welches Feld, welche Regel, welcher Protokolleintrag.
| Control | Titel | Abdeckung und Nachweisquelle |
|---|---|---|
| A.5.9 | Inventar der Werte | Typspezifische Attribute je Asset-Typ, Schutzbedarf, Verantwortlicher mit vollständiger Historie, automatischer Abgleich aus Microsoft Intune. Lückenlos ab der Beschaffung: Eine auf „geliefert" gesetzte Bestellung erzeugt die Inventarposten selbst. |
| A.5.11 | Rückgabe von Werten | Wird jemand über den Verzeichnissync deaktiviert, erscheinen die Geräte als offene Rückgabe. Deshalb entstehen Assets aus einer Lieferung bewusst ohne Zuordnung — eine automatische Zuordnung ohne Übergabe würde den Nachweis entwerten. |
| A.5.19–5.22 | Lieferantenbeziehungen | Kritikalität steuert den Prüfturnus (12 bis 36 Monate), AVV mit Ablaufdatum, vorgelegte Zertifikate, Unterauftragnehmer. Ein „nicht akzeptabel" in der Sicherheitsbewertung setzt den Lieferanten automatisch auf In Prüfung. |
| A.5.24–5.26 | Vorfallbehandlung | Incident, Problem und Service Request mit Priorität und Zuweisung, dazu echte SLA-Verwaltung: getrennte Reaktions- und Lösungszeiten, Geschäftszeitenkalender mit Feiertagen, Pausieren bei „Warten auf", dauerhaft markierte Verletzungen. |
| A.5.29 / A.5.30 | Betriebskontinuität | Notfallpläne mit Auslösekriterien, Wiederanlaufschritten und Zielwerten. Der Kern ist die Übung, nicht der Plan: Ablauf, Ergebnis, Beteiligte und erreichte Wiederanlaufzeit werden dokumentiert, Feststellungen sind bei nicht bestandener Übung Pflicht. |
| A.5.33 | Schutz von Aufzeichnungen | Aufbewahrungsregeln mit begründungspflichtiger Rechtsgrundlage und protokollierten Archivläufen. Dazu elektronische Unterschriften auf PDF mit Prüfsumme vor und nach dem Unterschreiben — und die Prüfsummen werden täglich von selbst nachgerechnet: stimmt, abweichend oder fehlt, je Dokument. Einfache elektronische Signatur nach eIDAS Art. 3 Nr. 10 — bewusst kein PAdES. Im Einzelnen ↓ |
| A.6.3 | Schulung und Bewusstsein | Kategorie, Format, Zielgruppe und Auffrischungsturnus. Die Erfüllungsquote zählt ausschließlich Nachweise, die zum Stichtag gültig sind — ein abgelaufener Nachweis belegt nichts. Nicht bestandene Teilnahmen zählen nicht und verlangen eine Notiz zur Nachholung. |
| A.8.5 | Sichere Authentisierung | Zwei Faktoren per TOTP nach RFC 6238 für lokale Konten, Wiederherstellungscodes einmalig ausgegeben, Abschalten nur mit gültigem Code. Bei SSO erzwingt der Identity Provider den zweiten Faktor. Auch fehlgeschlagene Versuche stehen im Protokoll. |
| A.8.8 | Technische Schwachstellen | CVE und CVSS, daraus abgeleiteter Schweregrad, Behandlungsfrist ab Entdeckung. Verknüpfung zu betroffenen Assets, Risiko und Change. Behebung nur mit Nachweis, Akzeptanz nur mit Begründung. Die Veralterungsprüfung schließt aktualisierte Geräte selbst wieder. |
| A.8.1 | Endpunktgeräte teilweise | Verschlüsselungs- und Compliance-Status, Betriebssystemstand, Beitrittsart und letzter Kontakt — automatisch aus Intune und Entra ID. Die Durchsetzung selbst liegt bei Intune, nicht bei uns. Wie die Anbindung arbeitet → |
| A.8.9 | Konfigurationsmanagement | Gerichtete Beziehungen (hängt ab von, läuft auf, gehört zu, verbunden mit, sichert) und daraus die transitive Auswirkungsanalyse mit Schutzbedarf. Kreise in den Abhängigkeiten werden abgelehnt. Der Asset-Typ Dienst verknüpft Geschäftsdienste mit der Technik darunter. |
| A.8.15 | Protokollierung | Systemweites Protokoll über alle Module: wer, wann, welche Aktion, welches Objekt, welches Detail. Jeder Eintrag trägt den SHA-256-Hash seines Vorgängers; die Anwendung darf Einträge schreiben und lesen, aber weder ändern noch löschen. Die Kette wird täglich nachgerechnet. Im Einzelnen ↓ |
| A.8.32 | Änderungsmanagement | Siehe unten — dieses Control ist der Prüfstein. |
A.8.32 Änderungsmanagement
Das Control, an dem sich zeigt, ob ein Werkzeug ernst gemeint ist
Die Norm verlangt, dass Änderungen kontrolliert erfolgen. Der Unterschied liegt darin, ob ein System den Ablauf empfiehlt oder ihn erzwingt.
| Anforderung | Umsetzung |
|---|---|
| Planen und bewerten | Change mit Typ (Standard, Normal, Emergency), Risiko- und Auswirkungsbewertung, Wartungsfenster, Umsetzungsplan. |
| Rückfallmöglichkeit | Ohne Rückfallplan lässt sich ein Change weder einreichen noch umsetzen. |
| Genehmigung | Genehmiger mit Rolle (CAB, fachverantwortlich, Sicherheit, Datenschutz). Eine Ablehnung kippt den Change, vollständige Zustimmung gibt ihn frei. |
| Auswirkung prüfen | Automatische Analyse über die CMDB: alle mittelbar betroffenen Werte mit Schutzbedarf und Abstand in der Kette. Warnung, wenn gar keine Assets verknüpft sind. |
| Kollisionen | Andere Changes im selben Fenster auf denselben oder abhängigen Werten. Sonst ist bei einer Störung nicht zurechenbar, welche Änderung sie verursacht hat. |
| Kritische Zeiträume | Sperrzeiten mit Pflichtbegründung, wahlweise auf bestimmte Werte begrenzt. Ausnahmen sind begründungspflichtig und an das Genehmigungs-, nicht das Pflegerecht gebunden. |
| Beständiger Nachweis | Die Auswirkungsanalyse wird bei der Genehmigung eingefroren. Ohne das würde eine spätere CMDB-Änderung rückwirkend anzeigen, es sei etwas anderes bewertet worden. |
| Nachbetrachtung | Ohne dokumentiertes Review kein Abschluss. |
Sonderfälle gelöst statt verboten
Standard-Changes gelten als vorgenehmigt und brauchen keine Einzelgenehmigung. Emergency-Changes dürfen sofort umgesetzt werden, werden aber bis zur Nachgenehmigung sichtbar markiert; auch eine laufende Sperrzeit hält sie nicht auf — ihr Lauf trotz Sperre steht dafür im Protokoll. Ein Werkzeug, das den Notfall blockiert, wird im Notfall umgangen, und dann fehlt der Nachweis ganz.
A.8.15 und A.5.33 — Revisionssicherheit
Dass sich Nachweise nicht ändern lassen, behaupten alle. Hier stehen die Fehlermeldungen.
„Wir schreiben nur, wir ändern nie" ist eine Absprache, kein Beweis. Wer prüft, muss eine Lücke von einem Ereignis unterscheiden können, das es nie gab. Deshalb ist das Protokoll verkettet — und zwar in der Datenbank, nicht im Anwendungscode: Eine Kette, die die Anwendung berechnet, schützt nur gegen Fehler der Anwendung, nicht gegen jemanden mit Datenbankzugang.
| Nr. | Eintrag | Vorgänger | Hash |
|---|---|---|---|
| 298 | CHG-0142 genehmigtCAB | c6a1a953 | e0e23f94 |
| 299 | Risiko R-017 akzeptiert · begründetA. Rieck | e0e23f94 | c39141ab |
| 300 | Vorfall als nicht meldepflichtig bewertetM. Berger | c39141ab | 693b0f8a |
| 301 | Richtlinie in Fassung 3 freigegebenA. Rieck | 693b0f8a | 5e399046 |
| 302 | Unversehrtheit geprüft · alles stimmtSystem | 5e399046 | 7435106f |
Kette unversehrt · 5 Einträge nachgerechnet
Probieren Sie es aus. Die Hashes sind echt gerechnet und hier auf acht Stellen gekürzt; jeder „Vorgänger" ist der Hash der Zeile darüber. Vereinfacht ist nur der Inhalt — in der Anwendung geht der ganze Eintrag in den Hash ein: wer, wann, welche Aktion, welches Objekt, welches Detail.
Zwei Datenbankbenutzer statt einem
Eine Sperre kann abschalten, wem die Tabelle gehört. Deshalb läuft die Anwendung mit einem Benutzer, dem nichts gehört: Er darf Protokolleinträge schreiben und lesen, sonst nichts. Der Eigentümer wird nur für Aktualisierungen gebraucht und gehört dem Betrieb, nicht der Anwendung.
Geprüft wird von selbst
Einmal täglich rechnet das System Kette und Dokumentprüfsummen nach. Prüfsummen gab es vorher schon — nur hat nie jemand nachgesehen. Ein Schutz, der eine Handlung voraussetzt, die im Alltag niemand vornimmt, ist keiner.
Das Ergebnis steht auch dann im Protokoll, wenn alles stimmt. Sonst ließe sich später nur sagen „es ist nichts aufgefallen" — nicht „am 3. März war alles in Ordnung". Und weil der Eintrag Teil der Kette ist, belegt die Prüfung ihre eigene Durchführung.
Versucht, als Datenbankbenutzer der Anwendung
| Versuch | Ergebnis |
|---|---|
| Protokolleintrag schreiben | Geht. Die Kette wird fortgeführt. |
| Eintrag ändern | Abgewiesen: permission denied for table AuditEvent |
| Eintrag löschen | Abgewiesen: permission denied for table AuditEvent |
| Die Sperre abschalten | Abgewiesen: must be owner of table AuditEvent |
Erkannt, mit absichtlich abgeschalteter Sperre
| Manipulation | Befund der Prüfung |
|---|---|
| Inhalt eines Eintrags geändert | „Inhalt stimmt nicht mehr mit dem Hash überein" — bei genau diesem Eintrag. |
| Eintrag gelöscht | „Lücke in der Folge: erwartet 300, gefunden 301" |
| Die letzten Einträge entfernt — Kette in sich gültig | „Die Kette reichte bei der letzten Prüfung bis Eintrag 1285, heute nur noch bis 72 — es wurden Einträge am Ende entfernt." Das sieht nur der Anker außerhalb der Datenbank. |
| Sperre abgeschaltet, Zeile geändert, ab dort neu gerechnet | „Eintrag 1285 trägt einen anderen Hash als bei der letzten Prüfung — die Kette wurde nachträglich neu gerechnet." |
| Einträge ohne laufende Nummer eingeschleust | Befund statt übersprungen: „… stehen außerhalb der Kette und sind damit ungeprüft." |
| Ein Byte an ein unterschriebenes PDF angehängt | Befund abweichend, mit Namen des Dokuments. Gegenmaßnahme: Vorfall, Original aus der Sicherung. |
| Unterschriebenes PDF umbenannt | Befund fehlt. Ein Nachweis, den es nicht gibt, belegt nichts. |
Nicht nur das Protokoll: das ganze System
Ein geschütztes Protokoll neben Fachtabellen, in denen sich alles umschreiben lässt, belegt nur, dass umgeschrieben wurde. Deshalb reicht der Schutz bis in die Entscheidungen hinein.
| Baustein | Wie es umgesetzt ist |
|---|---|
| Der Anker außerhalb der Datenbank | Die Kette beweist, dass zwischen zwei Einträgen nichts verändert wurde — nicht, dass sie vollständig ist. Deshalb hält jede Prüfung außerhalb der Datenbank fest, bis zu welchem Eintrag die Kette reichte und welchen Hash er trug; dieselbe Zeile geht ins Anwendungsprotokoll. Die nächste Prüfung sieht nach, ob genau dieser Eintrag noch genau so dasteht. Nur eine unversehrte Kette setzt einen neuen Anker. |
| Unterschriften | Die Prüfsummen unterschriebener Dokumente liegen in einer Tabelle, die die Anwendung nur lesen und anlegen darf. Dürfte sie sie ändern, ließe sich eine Datei austauschen und die Prüfsumme gleich mit. Die tägliche Prüfung deckt alle Unterschriften ab, nicht nur die jüngsten. |
| Nachweise hängen fest | 20 Beziehungen, an denen Nachweise hängen — Kommentare, Zeiten, Schritthistorie mit Genehmigungen, Change-Stimmen, NIS2-Berichte, Kenntnisnahmen, Schulungsnachweise, Rezertifizierungen, Maßnahmen, Übungen, Lieferantenbewertungen, Bestellpositionen, Preishistorie — stehen auf ON DELETE RESTRICT. Wer den Elterndatensatz entfernen will, scheitert an der Datenbank, statt die Nachweise mitzunehmen. |
| Beides oder nichts | Unterschrift, Stilllegung, Bestellfreigabe und Change-Entscheidung schreiben ihren Protokolleintrag in derselben Transaktion wie die Änderung selbst. Es gibt keinen Zustand, in dem die Entscheidung da ist und die Spur fehlt. Ein Eintrag, der nicht geschrieben werden konnte, ist ein Zähler im Systemstatus — nicht eine Zeile in einer Konsole. |
| Eine Genehmigung bindet an den Inhalt | Ab „In Genehmigung" sind Typ, Risiko, Auswirkung und die drei Pläne eines Changes gesperrt. Wer den Inhalt ändern will, nimmt den Change zurück in den Entwurf — beim erneuten Einreichen verfallen die Stimmen, und das steht im Protokoll. Eine abgegebene Stimme lässt sich nicht überschreiben. |
| Abgeschlossenes bleibt zu | Ein abgeschlossener Sicherheitsvorfall, eine geschlossene Abweichung, ein abgeschlossenes Audit, eine abgeschlossene Change-Nachbetrachtung: unveränderlich. Eine abgesetzte NIS2-Meldung lässt sich nicht auf „nicht erheblich" wegbewerten. Ein gültiger Notfallplan ändert sich nur im Entwurf; eine Risikoakzeptanz verfällt, wenn das Risiko danach höher bewertet wird; die Freigabe des Anwendungsbereichs fällt, wenn er sich ändert. |
| Alt- und Neuwert im Protokoll | Wer den Mailserver umstellt, eine Verzeichnisgruppe auf „admin" abbildet, Abteilungsmitglieder ändert, einen Termin verschiebt oder die Kenntnisnahme eines Vorfalls korrigiert, hinterlässt beide Werte. Geheimnisse stehen nur als „geändert". |
Was der Begriff „revisionssicher" eigentlich verlangt — und sieben Fragen, die Sie jedem Anbieter stellen können: zur Erklärseite →
Häufige Fragen
ISO 27001 und Entrutrace
Deckt das die Norm vollständig ab?
Nein. 27 der 93 Annex-A-Controls belegen sich aus dem Betrieb, 2 teilweise. Die physischen Controls (A.7) gehören bewusst nicht dazu — ein Zaun lässt sich nicht in Software nachweisen. Was Entrutrace zusätzlich abbildet, ist das Managementsystem selbst: Klausel 4, 6.2, 9.2, 9.3 und 10.1.
Ersetzt das einen Berater?
Nein. Es ersetzt die Excel-Tabellen, die ein Berater sonst anlegt, und es hält den Stand danach von selbst aktuell. Die Entscheidung, welcher Geltungsbereich richtig ist und welche Risiken Ihr Haus wirklich trägt, nimmt Ihnen kein Werkzeug ab.
Ist das System revisionssicher?
Nachprüfbar gegen nachträgliche Änderung gesichert, und zwar nicht nur das Protokoll: Jeder Eintrag trägt den SHA-256-Hash seines Vorgängers, die Verkettung entsteht in der Datenbank, der Datenbankbenutzer der Anwendung darf Einträge und Unterschrifts-Prüfsummen weder ändern noch löschen, und ein Anker außerhalb der Datenbank erkennt, wenn die Kette gekürzt oder neu gerechnet wurde. Nachweispflichtige Entscheidungen schreiben ihren Eintrag in derselben Transaktion, Abgeschlossenes bleibt zu, Genehmigungen binden an den Inhalt. Einmal täglich prüft das System Kette und Dokumente und protokolliert das Ergebnis — auch wenn alles stimmt.
Wie kommt der Auditor an die Nachweise?
Über den Auditnachweis-Export: Er ordnet jedem Annex-A-Control die konkrete Quelle im System zu — welches Modul, welcher Datensatz, welcher Protokolleintrag. Das ist die Tabelle, nach der im Audit gefragt wird.
Abgrenzung: Entrutrace liefert die operativen Nachweise aus dem IT-Betrieb und bildet das Managementsystem ab. Es ist keine Rechtsberatung und keine Zertifizierungsgarantie — die hängt am Betrieb, nicht am Werkzeug.
Am schnellsten überzeugt der eigene Fall.
Vierzig Minuten, Ihre Landschaft als Beispiel, kein Foliensatz. Wir zeigen den Weg von der Meldung bis zum Auditnachweis an einem Vorgang, den Sie selbst aussuchen.