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 — Protokoll und Aufzeichnungen
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" |
| 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. |
Was es nicht tut
Ein Sicherheitsversprechen, dessen Grenzen man nicht kennt, ist selbst ein Risiko.
| Grenze | Was das bedeutet |
|---|---|
| Keine qualifizierten Zeitstempel | Die Zeit im Protokoll ist die Serverzeit. Gegenüber Dritten beweist sie nichts; dafür bräuchte es einen Zeitstempeldienst nach RFC 3161. |
| Ein Datenbank-Administrator kann weiterhin alles | Er kann die Sperre abschalten und Zeilen ändern. Er hinterlässt dabei eine gebrochene Kette — mehr nicht. Der Eigentümerzugang gehört deshalb getrennt verwahrt, nicht in die Konfiguration der Anwendung. |
| Keine Ablage, die Überschreiben verbietet | Unterschriebene PDF liegen im Dateisystem. Ein Austausch fällt spätestens am nächsten Tag auf — verhindert wird er nicht. |
| Sicherungen sind nicht unveränderlich | Wer eine Sicherung manipuliert und einspielt, umgeht alles. Dagegen hilft nur ein Sicherungsziel, das Überschreiben verbietet — das liegt im Betrieb, nicht im Werkzeug. |
| Das Protokoll wächst unbegrenzt | Archivieren wäre eine Änderung, Löschen entfernt Zeilen; beides zerrisse die Kette. Die Aufbewahrungsregel für Protokolleinträge kann deshalb nur „behalten" heißen. Abschnitte zu siegeln und zu überrollen ist der saubere Ausweg — noch nicht gebaut. |
| Die Kette belegt nur die Zeit seit ihrer Einrichtung | Wird sie über einen bestehenden Bestand gelegt, bleibt unentdeckt, was davor geändert wurde. Ab der Einrichtung ist jede Änderung sichtbar. |
Was der Begriff „revisionssicher" eigentlich verlangt — und fünf 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 Protokoll revisionssicher?
Es ist gegen nachträgliche Änderung gesichert, und zwar nachprüfbar: Jeder Eintrag trägt den SHA-256-Hash seines Vorgängers, die Verkettung entsteht in der Datenbank, und der Datenbankbenutzer der Anwendung darf Einträge weder ändern noch löschen. Einmal täglich rechnet das System die Kette und die Prüfsummen der unterschriebenen Dokumente nach und protokolliert das Ergebnis — auch wenn alles stimmt. Was es nicht leistet: qualifizierte Zeitstempel, eine Ablage mit Überschreibschutz und Schutz vor einem Datenbank-Administrator mit vollen Rechten. Der hinterlässt eine gebrochene Kette, aufgehalten wird er nicht.
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.