ISO 27001: ISMS aufbauen und betreiben

ISO 27001 ist die internationale Norm für Informationssicherheits-Managementsysteme (ISMS). Sie sagt nicht, welche Sicherheitsmaßnahmen man treffen muss – sie verlangt einen funktionierenden Kreislauf, der sicherstellt, dass die richtigen Maßnahmen dauerhaft wirken.

Was die Norm verlangt

ISO 27001 besteht aus zwei Teilen:\n\n1) HAUPTTEIL (Kapitel 4-10) - verbindlich\n   4  Kontext der Organisation\n      Was machen wir? Wer sind wir? Was ist wichtig?\n   5  Fuehrung\n      Verpflichtung der Leitung, Rollen, Politik\n   6  Planung\n      Risiken bewerten, Ziele setzen, Massnahmen planen\n   7  Unterstuetzung\n      Ressourcen, Kompetenz, Bewusstsein, Dokumentation\n   8  Betrieb\n      Umsetzung der geplanten Massnahmen\n   9  Bewertung der Leistung\n      Ueberwachung, Messung, interne Audits\n   10 Verbesserung\n      Abweichungen, Korrekturmassnahmen, staendige\n      Verbesserung\n\n2) ANHANG A (93 Massnahmen, 4 Gruppen) - Pruefliste\n   A.5  Organisatorische Massnahmen       (37)\n   A.6  Personenbezogene Massnahmen       (8)\n   A.7  Physische Massnahmen              (14)\n   A.8  Technische Massnahmen             (34)\n   # WICHTIG: Der Anhang ist NICHT verbindlich im Sinne\n   # von "alle 93 umsetzen". Man muss begruenden, welche\n   # relevant sind und welche nicht (Erklaerung der\n   # Anwendbarkeit / Statement of Applicability).\n   # Nur die identifizierten Massnahmen werden umgesetzt.\n\nKernaussage: Die Norm verlangt keinen bestimmten\nSicherheitsstand, sondern einen Regelkreis, der\nRisiken erkennt und behandelt - und Nachweise.

Die wichtigsten technischen Maßnahmen (A.8)

A.8.2   Erhoehter Schutz fuer privilegierte Zugriffe\n        # Kleinstes Recht, kein taegliches Arbeiten als Root,\n        # getrennte Admin-Konten\n\nA.8.3   Informationszugriff einschraenken\n        # Zugriffskontrolle nach Rolle (RBAC),\n        # Regelmaessige Durchsicht der Berechtigungen\n        # (vierteljaehrlich - die meisten Verstoesse\n        #  sind zu breite Rechte)\n\nA.8.5   Sichere Authentifizierung\n        # Mehrfaktorautorisierung fuer alle Admin-Zugaenge\n        # und Fernzugriffe. Passwortrichtlinie, kein\n        # Kontenteilen.\n\nA.8.7   Schutz gegen Schadsoftware\n        # Endpoint-Schutz UND Erkennung UND Reaktion\n\nA.8.8   Verwaltung technischer Schwachstellen\n        # Regelzyklus, Bewertung, Fristen\n        # (siehe Schwachstellenmanagement)\n\nA.8.9   Konfigurationsverwaltung\n        # Haertung nach Standard, Dokumentation,\n        # Aenderungsnachvollziehbarkeit\n\nA.8.12   Verhinderung von Datenabfluss\n        # Keine nicht genehmigten Speichermedien,\n        # Ueberwachung ausgehender Daten DLP\n\nA.8.13   Sicherung (Backup)\n        # Wiederherstellung GETESTET - das ist der\n        # Punkt, an dem die meisten durchfallen\n\nA.8.15   Protokollierung\n        # Wer, wann, was, woher. UEBERWACHUNG der\n        # Protokolle ist Pflicht (nicht nur Schreiben!),\n        # und die Protokolle muessen geschuetzt sein.\n\nA.8.16   Ueberwachung\n        # Anomalieerkennung: ungewoehnliche Anmeldungen,\n        # Datenmengen, Zeiten\n\nA.8.20   Netzwerksicherheit\n        # Segmentierung, Filterregeln, Trennung von\n        # Verwaltungs- und Produktionsnetz\n\nA.8.23   Webfilterung / A.8.25-8.31 Sicherheit im\n         Entwicklungsprozess\n        # Sichere Entwicklung, Tests, Trennung von\n        # Umgebungen, geschuetzte Quelltexte\n\nA.8.24   Kryptografie\n        # Verschluesselung mit Schluesselverwaltung\n        # (wo liegen die Schluessel?)

Der Kern: Risikoanalyse

Ohne Risikoanalyse funktioniert kein ISMS. Sie ist\nder Punkt, an dem die Norm am haeufigsten scheitert -\nnicht an der Technik.\n\nVorgehen (einfach und ausreichend):\n\n1) INVENTAR\n   Informationen und Systeme auflisten:\n     Informationsart, System, Eigentuemer,\n     Verfuegbarkeit/Vertraulichkeit/Integritaet\n     # Ohne Inventar gibt es keine Risikoanalyse,\n     # und ohne Analyse kein ISMS.\n\n2) BEDROHUNGEN\n   Was kann passieren? Fuer jedes Objekt:\n     Ausfall, Datenverlust, unbefugter Zugriff,\n     Manipulation, Diebstahl, Fehler von Beschaeftigten,\n     Schadsoftware, Angriff von aussen\n     # Threat Modeling (STRIDE) ist hier sehr\n     # hilfreich und macht es systematisch.\n\n3) SCHWACHSTELLEN\n   Was macht uns anfaellig?\n     Fehlende Sicherung, offene Dienste, zu breite\n     Rechte, ungetestete Wiederherstellung\n\n4) BEWERTUNG\n   Eintrittswahrscheinlichkeit (1-3) x Auswirkung (1-3)\n     # Nicht wissenschaftlich werden wollen. Fuenf\n     # Risiken je Informationsart reichen.\n\n5) MASSNAHMEN\n   Je Risiko: Massnahme, Verantwortlicher, Frist,\n   Restrisiko\n     # Entscheidend: Wenn Risiken AKZEPTIERT werden,\n     # muss das dokumentiert und genehmigt sein. Eine\n     # stillschweigende Akzeptanz ist der haeufigste\n     # Auditbefund.\n\n6) NACHWEIS\n   Alles dokumentiert und mit Datum versehen.\n   # "Wir machen das schon" ist kein Nachweis.\n   # Ein Screenshot, ein Ticket, ein Protokoll sind\n   # Nachweise.

Erklärung der Anwendbarkeit (SoA)

Das SoA ist das zentrale Dokument. Es listet alle\n93 Massnahmen des Anhangs A und sagt zu jeder:\n  - Anwendbar:    ja / nein\n  - Begruendung\n  - Umsetzungsstand\n  - Nachweis (Dokument, Ticket, System)\n\nBeispielzeilen:\n  A.8.13 Backup             anwendbar\n    Umsetzung: taegliche Sicherung, Off-Site-Kopie\n    Nachweis:  Ticket 4711, Wiederherstellungstest\n               vom 2026-08-14 (protokolliert)\n  A.7.4 Physische Ueberwachung   anwendbar\n    Umsetzung: Zutrittskontrolle, Videoueberwachung\n  A.5.30 IKT-Bereitschaft   anwendbar\n    Umsetzung: Notfallplan, Uebung halbjaehrlich\n\n  A.8.9 Konfigurationsverwaltung  anwendbar\n    Umsetzung: Haertungskatalog, Aenderungstickets\n\n  A.5.29  anwendbar   ...\n  # Massnahmen als "nicht anwendbar" zu erklaeren\n  # ist ausdruecklich zulaessig - aber die Begruendung\n  # muss nachvollziehbar sein. "Haben wir nicht" ist\n  # keine Begruendung.\n\nWICHTIG: Das SoA ist ein lebendes Dokument. Wer es\neinmal schreibt und weglegt, hat kein ISMS - er hat\nein Dokument.

Praktischer Einstieg (12 Monate)

MONAT 1-2: Vorbereitung\n  - Umfang festlegen (welche Standorte, Systeme, Dienste?)\n  - Leitung einbinden und Verpflichtung schriftlich\n  - Zuständige Person benennen (mit Zeitbudget!)\n  - Inventar aufbauen\n\nMONAT 3-4: Risikoanalyse\n  - Risiken je Informationsart und System\n  - Bewertung, Priorisierung\n  - Massnahmenplan mit Verantwortlichen und Fristen\n\nMONAT 5-8: Umsetzung\n  - Technische Massnahmen umsetzen (Haertung,\n    Mehrfaktorauthentifizierung, Sicherungen,\n    Protokollierung, Berechtigungen)\n  - Dokumentation schreiben (Politik, Verfahren)\n  - Schulung durchfuehren (auch Leitung)\n  # JETZT laeuft der eigentliche Aufwand - vorher\n  # war es Planung.\n\nMONAT 9-10: Betrieb und Pruefung\n  - Interne Audits\n  - Wirksamkeit messen (Kennzahlen)\n  - Korrekturmassnahmen\n\nMONAT 11-12: Managementbewertung und Zertifizierung\n  - Managementpruefung mit Nachweisen\n  - Zertifizierungsaudit (Stufe 1: Dokumente,\n    Stufe 2: Umsetzung)\n  - Ueberwachungsaudits folgen jaehrlich\n\nKENNZAHLEN, die sich lohnen:\n  - Anteil Systeme mit Mehrfaktorauthentifizierung\n  - Anteil Systeme mit getesteter Wiederherstellung\n  - Zeit bis zum Schliessen kritischer Schwachstellen\n  - Anteil geschulter Beschaeftigter\n  - Zahl der Sicherheitsvorfaelle und Zeit bis Erkennung\n  # Diese Zahlen zeigen Wirksamkeit besser als\n  # die Zahl der vorhandenen Dokumente.

Prüfliste

Ist der Anwendungsbereich definiert (Standorte, Systeme, Dienste)?
Existiert ein Inventar der Informationswerte und Systeme?
Gibt es eine dokumentierte Risikoanalyse – nicht nur einen Plan dazu?
Sind akzeptierte Risiken mit Genehmigung dokumentiert?
Existiert eine Erklärung der Anwendbarkeit mit Begründungen?
Werden die Maßnahmen nachgewiesen (Tickets, Protokolle, Tests)?
Ist die Wiederherstellung aus Sicherungen nachweislich getestet?
Gibt es interne Audits und eine Managementbewertung?
Bekommen alle Beschäftigten eine Sicherheitsschulung – auch die Leitung?
Gibt es Kennzahlen, die die Wirksamkeit zeigen?
Werden Berechtigungen regelmäßig durchgesehen?
Wird das ISMS weiterentwickelt oder ist es eingefroren?

Häufige Fehler

Dokumente statt Wirklichkeit. Ein wunderschönes Handbuch ohne funktionierende Sicherungen. Der Audit findet das – spätestens bei der Frage nach dem Wiederherstellungstest.
Keine Risikoanalyse. Ohne sie hängt alles Weitere in der Luft. Und ohne Inventar gibt es keine Analyse.
Alle 93 Maßnahmen abarbeiten. Das SoA existiert genau deswegen: Man wählt begründet aus.
Akzeptierte Risiken ohne Unterschrift. „Wurde besprochen“ ist kein Nachweis. Der häufigste Auditbefund.
Leitung nur auf dem Papier. Ohne Beteiligung fehlt Ressourcenentscheidung und Richtung.
Ungetestete Sicherung. A.8.13 verlangt Wiederherstellung, nicht nur eine Kopie.
Protokollierung ohne Überwachung. A.8.15 verlangt, dass jemand hinsieht. Ein Protokoll, das niemand auswertet, erfüllt die Anforderung nicht.
Zertifikat als Ziel. Zertifizierung ist der Nachweis, nicht der Zweck. Wer nur für das Audit arbeitet, baut ein System, das nach dem Audit verfällt.
Keine Kennzahlen. Ohne Messung keine Verbesserung – und Kapitel 9/10 werden nicht erfüllt.

Verwandte Grundlagen: NIS2, Threat Modeling, Schwachstellenmanagement, Vorfallbehandlung.

IT-Sicherheit