Was ist ein ISMS? Sicherheitsarbeit mit Geschäftsentscheidungen verbinden

Sicherheitsarbeit kann geschäftig wirken, ohne koordiniert zu sein. Die Entwicklung patcht Systeme, die Personalabteilung bearbeitet Austritte, der Einkauf prüft Lieferanten und die Leitung genehmigt Ausnahmen. Ein Informationssicherheitsmanagementsystem verbindet diese Tätigkeiten mit gemeinsamen Zielen und einem ausdrücklichen Entscheidungsprozess.

Für einen CEO lautet die wichtige Frage nicht, ob das Unternehmen genügend Sicherheitsdokumente hat. Entscheidend ist, ob die Leitung erklären kann, was geschützt werden muss, welche Risiken relevant sind, wer verantwortlich ist und warum das aktuelle Schutzniveau akzeptabel ist. Ein ISMS macht diese Antworten wiederholbar, auch wenn sich das Unternehmen verändert.

Was ein ISMS tatsächlich steuert

Ein Informationssicherheitsmanagementsystem ist das organisatorische System zur Steuerung von Informationssicherheitsrisiken. Es umfasst Verantwortlichkeiten, Richtlinien, Prozesse, Ressourcen, Maßnahmen und Bewertung. Software kann es unterstützen, ist aber nicht das System. Eine Dokumentenbibliothek kann es beschreiben, doch Dokumente allein belegen nicht, dass es funktioniert.

Sein Zweck ist der Schutz von drei Eigenschaften von Informationen:

• Vertraulichkeit: Informationen sind nur befugten Personen und Systemen zugänglich.
• Integrität: Informationen bleiben richtig und vollständig und sind vor unzulässiger Veränderung geschützt.
• Verfügbarkeit: Befugte Nutzer können bei Bedarf auf Informationen zugreifen und unterstützende Dienste nutzen.

Diese Eigenschaften übersetzen sich in geschäftliche Anliegen. Offengelegte Kundendatensätze können Vertrauen untergraben und rechtliche Pflichten auslösen. Falsche Zahlungsanweisungen können finanzielle Verluste verursachen. Eine nicht verfügbare Supportplattform kann das Unternehmen daran hindern, Kundenzusagen einzuhalten.

ISO/IEC 27001 bietet anerkannte Anforderungen für ein ISMS mit festgelegtem Geltungsbereich. Die Kapitel 4 bis 10 behandeln Kontext der Organisation, Führung, Planung, Unterstützung, Betrieb, Bewertung der Leistung und Verbesserung. Eine Organisation kann ein ISMS aufbauen und betreiben, bevor sie eine Zertifizierung anstrebt.

Das Managementsystem stellt die Verbindung zwischen einzelnen Schutzvorkehrungen und Geschäftsentscheidungen her. Eine Datensicherung ist eine Maßnahme. Zu entscheiden, was wiederherstellbar sein muss, die Wiederherstellungsfähigkeit zu finanzieren, sie zu testen und auf fehlgeschlagene Tests zu reagieren, ist Arbeit des Managementsystems.

Warum die Leitung diese Verbindungen braucht

Sicherheitsentscheidungen fallen im ganzen Unternehmen bereits heute, ob es sie ISMS nennt oder nicht. Jemand wählt einen SaaS-Anbieter, genehmigt privilegierte Zugriffe, akzeptiert einen verzögerten Patch oder sagt einem Kunden eine bestimmte Wiederherstellungsanforderung zu. Ohne gemeinsamen Prozess beruhen diese Entscheidungen womöglich auf unterschiedlichen Annahmen, und niemand ist für ihre Gesamtwirkung verantwortlich.

Ein ISMS gibt der Leitung eine Grundlage, um begrenzte Ressourcen zu priorisieren. Es hilft Teams außerdem, Kundenfragen anhand gepflegter Aufzeichnungen zu beantworten, statt ihre Praxis bei jeder Vertriebsprüfung neu zu rekonstruieren. Das garantiert kein erfolgreiches Beschaffungsergebnis, macht die zugrunde liegenden Aussagen aber belastbarer.

Die Verbindungen sollten praktische Fragen beantworten:

Diese Verknüpfungen sind besonders in Wachstumsphasen wichtig. Informelle Praktiken, die funktionieren, solange sich alle kennen, werden unzuverlässig, wenn neue Teams, Standorte, Lieferanten und Kundenzusagen hinzukommen.

Legen Sie einen Geltungsbereich fest, der das Geschäft abbildet

Beginnen Sie mit dem geschäftlichen Kontext, nicht mit einer Liste von Maßnahmen. Ermitteln Sie die Dienste, die die Organisation erbringt, die Informationen, die sie nutzen, interessierte Parteien und deren Anforderungen sowie die internen und externen Bedingungen, die die Sicherheit beeinflussen.

Der Geltungsbereich legt die Grenze des ISMS fest. Er sollte die abgedeckten Tätigkeiten, Organisationseinheiten, gegebenenfalls Standorte, Technologie und Schnittstellen zu anderen Teilen des Unternehmens benennen. Ein sinnvoller erster Geltungsbereich könnte ein kundenseitiges Produkt und dessen Erbringung umfassen statt jeder Unternehmenstätigkeit.

Ein fokussierter Geltungsbereich darf Abhängigkeiten jedoch nicht ignorieren. Wenn die Personalabteilung den Austrittsprozess für Beschäftigte mit Produktzugriff anstößt, ist diese Schnittstelle relevant. Wenn ein Cloud-Anbieter den Dienst hostet, verschwindet die Abhängigkeit durch die Auslagerung nicht. Wenn der Support Kundeninformationen exportiert, gehört der Exportprozess in die Analyse.

Formulieren Sie eine Beschreibung des Geltungsbereichs und hinterfragen Sie sie mit drei Fragen:

• Könnte ein Kunde verstehen, was abgedeckt ist und was nicht?
• Haben wir die Abhängigkeiten einbezogen, die zum Schutz des abgedeckten Dienstes nötig sind?
• Können benannte Verantwortliche das System innerhalb dieser Grenze pflegen?

Klein anzufangen ist eine praktische Empfehlung, keine Erlaubnis für eine irreführende Grenze. Ein klarer Geltungsbereich mit verantwortlichen Personen ist stärker als ein großes Register, das niemand aktualisiert. Erweitern Sie ihn bewusst, wenn neue Dienste oder Abhängigkeiten es rechtfertigen.

Weisen Sie Entscheidungen zu, nicht nur Aufgaben

Die oberste Leitung muss einem ISMS nach ISO 27001 Richtung und Unterstützung geben. Wer die Koordination an eine Sicherheitsverantwortliche delegiert, überträgt damit nicht die Verantwortung der Leitung für Prioritäten, Ressourcen und akzeptables Risiko.

Trennen Sie Verantwortlichkeiten, die oft in der Stelle einer einzigen Person gebündelt werden:

Ein kleines Unternehmen kann einer Person mehrere Verantwortlichkeiten übertragen. Es sollte dennoch erkennbar sein, welche Rolle diese Person gerade ausübt und wo eine unabhängige Prüfung nötig ist, insbesondere beim internen Audit.

Legen Sie Eskalationsschwellen fest. Eine Teamleitung kann eine kurzfristige betriebliche Ausnahme innerhalb vereinbarter Grenzen genehmigen; ein Risiko, das wichtige Kundenzusagen gefährdet, kann eine Freigabe durch die Geschäftsleitung erfordern. Dokumentieren Sie Begründung, Bedingungen, Ablaufdatum und Überprüfungsauslöser. „Von der Leitung akzeptiert“ reicht nicht aus, wenn niemand die entscheidende Person oder das akzeptierte Risiko benennen kann.

Machen Sie die Risikobeurteilung zu einem Priorisierungsprozess

Die Risikobeurteilung sollte plausible Szenarien beschreiben, nicht nur Werte benennen oder Schwachstellen auflisten. „Kundendatenbank“ ist ein Wert. „Ein kompromittiertes Administratorkonto ermöglicht den massenhaften Abzug von Kundendatensätzen“ ist ein Risikoszenario mit Ursache und Folge.

Legen Sie eine dokumentierte Beurteilungsmethode und Kriterien für die Risikoakzeptanz fest. ISO 27001 schreibt keine bestimmte Bewertungsformel vor. Als praktischer Ansatz bietet es sich an, Kategorien für Eintrittswahrscheinlichkeit und Auswirkung in einer Sprache zu definieren, die Ihre Entscheidungsträger verstehen, einschließlich betrieblicher Störungen, finanzieller Verluste, vertraglicher Folgen und, wo relevant, Schäden für Einzelpersonen.

Dokumentieren Sie für jedes wesentliche Szenario:

• Den betroffenen Dienst, die betroffenen Informationen und Abhängigkeiten.
• Die Bedrohung oder das Ereignis und relevante Schwachstellen.
• Bestehende Maßnahmen und ihre bekannten Grenzen.
• Eintrittswahrscheinlichkeit, Auswirkung und daraus folgende Priorität.
• Die risikoverantwortliche Person und die vorgeschlagene Behandlung.

Die Behandlung kann darin bestehen, die Gefährdung durch Maßnahmen zu verringern, eine Tätigkeit zu vermeiden, Aspekte des Risikos über Verträge oder Versicherungen zu teilen oder das Risiko im Rahmen genehmigter Kriterien zu akzeptieren. Eine Versicherung stellt verlorene Informationen nicht wieder her, und ein Lieferantenvertrag nimmt der Organisation ihre Verantwortung nicht ab.

Unterscheiden Sie das aktuelle Risiko vom Restrisiko nach der Behandlung. Senken Sie eine Bewertung nicht schon deshalb, weil eine Aufgabe eingeplant ist. Beurteilen Sie neu, sobald die Umsetzung erfolgt ist und geeignete Nachweise über den Betrieb vorliegen. Lassen Sie den Behandlungsplan und die Akzeptanz des Restrisikos von der festgelegten Stelle freigeben.

Das betriebliche Risikoregister sollte eine Entscheidungsdokumentation bleiben: Was hat sich geändert, warum wurde eine Behandlung gewählt und wann muss die Beurteilung überprüft werden?

Wählen Sie Maßnahmen aus und begründen Sie ihre Anwendbarkeit

Maßnahmen sind die Mittel, mit denen Risiken verändert werden. Dazu gehören technische Schutzvorkehrungen wie Multi-Faktor-Authentisierung, organisatorische Prozesse wie Lieferantenbewertungen, personenbezogene Maßnahmen wie Schulungen und physischer Schutz für Geräte und Räumlichkeiten.

Anhang A der ISO/IEC 27001:2022 enthält 93 Referenzmaßnahmen: 37 organisatorische, 8 personenbezogene, 14 physische und 34 technologische. Die Auswahl ist risikobasiert; eine Organisation setzt nicht automatisch jede Maßnahme um. ISO/IEC 27002 bietet Umsetzungshinweise und ist keine eigenständige Zertifizierungsanforderung für ein ISMS.

Bestimmen Sie für ISO 27001 die zur Risikobehandlung erforderlichen Maßnahmen und gleichen Sie sie mit Anhang A ab, um sicherzustellen, dass keine erforderlichen Maßnahmen fehlen. Maßnahmen können auch aufgrund gesetzlicher oder vertraglicher Anforderungen notwendig sein und müssen sich nicht auf Anhang A beschränken.

Die Erklärung zur Anwendbarkeit dokumentiert die erforderlichen Maßnahmen, die Begründung für ihre Aufnahme, ihren Umsetzungsstand und die Begründung für den Ausschluss von Maßnahmen aus Anhang A. Sie unterscheidet sich vom Risikobehandlungsplan: Die eine erläutert die anwendbaren Maßnahmen, der andere die Schritte, die zur Behandlung von Risiken nötig sind. Diese Referenzstruktur erklärt der Leitfaden zu den Maßnahmen aus Anhang A.

Legen Sie für jede ausgewählte Maßnahme eine verantwortliche Person, das beabsichtigte Ergebnis, die Funktionsweise und die Nachweise fest, die ihre Wirksamkeit belegen. „Zugriffskontrolle umgesetzt“ ist weniger nützlich als ein ausdrücklicher Prozess, der Genehmigung, Einrichtung, Überprüfung und Entzug abdeckt.

Richtlinien sollten Regeln aufstellen, denen Menschen folgen können. Verfahren sollten die Durchführung erklären. Keines von beiden sollte Überprüfungen oder technische Beschränkungen versprechen, die die Organisation tatsächlich nicht aufrechterhalten kann.

Verankern Sie Nachweise im normalen Betrieb

Nachweise sollten aus der Arbeit selbst entstehen, nicht daraus, dass vor einem Audit eine Geschichte rekonstruiert wird. Eine Zugriffsüberprüfung kann eine datierte Benutzerliste, Entscheidungen der Prüfenden, Tickets für Entzüge und eine Bestätigung der durchgeführten Änderungen liefern. Eine Wiederherstellungsübung kann Testbedingungen, Ergebnisse, beobachtete Grenzen und Folgemaßnahmen liefern.

Ein Screenshot kann eine Einstellung zu einem bestimmten Zeitpunkt zeigen. Er belegt nicht unbedingt, dass die Einstellung alle relevanten Systeme abdeckt oder über einen Zeitraum hinweg wirksam war. Prüfende sollten Umfang, Datum, Quelle, Vollständigkeit und die Schlussfolgerung untersuchen, die der Nachweis tatsächlich stützt.

Ein praxistauglicher Nachweisbestand für ein ISMS umfasst:

Nicht jede Zeile braucht ein eigenes Dokument. Eine kleine Organisation kann Aufzeichnungen zusammenfassen, solange Klarheit und Nachvollziehbarkeit erhalten bleiben. Schützen Sie die Nachweise selbst: Benutzerexporte, Vorfallaufzeichnungen und Screenshots können sensible Informationen enthalten und brauchen angemessene Zugriffs- und Aufbewahrungsregelungen.

Beispiel: eine Kundensupportplattform

Betrachten Sie als Beispiel ein Softwareunternehmen mit 30 Beschäftigten, das eine SaaS-Supportplattform nutzt. Angenommen, die Plattform enthält Kundennamen, Kontaktdaten, Ticketverläufe und gelegentlich Diagnoseanhänge. Die Mitarbeitenden nutzen persönliche Konten, ein externer Dienstleister hostet die Anwendung, und manche Tickets werden zur Fehlersuche exportiert. Dies sind Beispielannahmen, kein vorgeschriebenes Unternehmensmodell.

Der Geltungsbereich des ISMS umfasst den Kundensupport und seine Abhängigkeiten: Identitäten der Mitarbeitenden, den SaaS-Lieferanten, Zugriff über Endgeräte, Exporte, Aufbewahrung und Wiederherstellungsregelungen. Die Supportleitung verantwortet den Dienst; die IT betreibt die Zugriffskontrollen; der Einkauf koordiniert die Lieferantenbewertung; die Leitung gibt Risiken frei, die über die delegierte Befugnis hinausgehen.

Die erste Beurteilung ermittelt drei Szenarien:

Angenommen, ein Kontenabgleich ergibt, dass eine ehemalige Mitarbeiterin noch Zugriff hat. Die Sofortmaßnahme besteht darin, den Zugriff zu entziehen und zu prüfen, ob das Konto unzulässig genutzt wurde. Die Maßnahme des Managementsystems besteht darin, zu ermitteln, warum der Entzug fehlgeschlagen ist. Vielleicht hat die Personalabteilung die IT informiert, aber die Supportanwendung fehlte in der Austrittscheckliste.

Die Korrekturmaßnahme aktualisiert dann das Anwendungsinventar, nimmt die Supportplattform in den Austrittsprozess auf, weist die Verantwortung für die Bestätigung zu und prüft spätere Austritte. Allein das Schließen des Tickets für den Entzug würde den unmittelbaren Zustand beheben, ohne seine Ursache zu beseitigen.

Angenommen nun, der SaaS-Lieferant ändert seine Liste der Unterauftragsverarbeiter. Die für den Lieferanten verantwortliche Person prüft die Änderung anhand vertraglicher, sicherheitsbezogener und relevanter datenschutzrechtlicher Anforderungen. Sie dokumentiert, ob die Änderung den Umgang mit Daten, Abhängigkeiten oder akzeptierte Risiken betrifft und ob eine fachliche Prüfung nötig ist. Die Änderung hat eine verantwortliche Person und einen Prüfweg, statt ungelesen in einem gemeinsamen Postfach zu liegen.

Die Leitung erhält die offenen Entscheidungen: ob ein stärkerer Ausweichprozess finanziert, die in Anhängen erhobenen Informationen verringert oder ein festgelegtes Restrisiko akzeptiert werden soll. So verbindet das ISMS betriebliche Feststellungen mit geschäftlichen Entscheidungen.

Arbeiten Sie in einem Rhythmus, der Veränderungen erkennt

Planen Sie Überprüfungen nach Risiko, Änderungshäufigkeit und Pflichten. Eine wöchentliche Lückenbesprechung während der Ersteinführung und eine regelmäßige Managementbewertung können nützliche praktische Entscheidungen sein, sind aber keine allgemeingültigen, von ISO 27001 vorgeschriebenen Intervalle. Die Norm verlangt interne Audits und Managementbewertungen in geplanten Abständen.

Ergänzen Sie ereignisgesteuerte Auslöser: Vorfälle, größere Releases, Übernahmen, Lieferantenwechsel, neue rechtliche Pflichten, wesentliche Kundenzusagen und Auditfeststellungen. Ein Kalender allein übersieht wichtige Änderungen zwischen geplanten Besprechungen.

Die Überwachung fragt, ob Maßnahmen und Ziele wie beabsichtigt funktionieren. Das interne Audit bewertet, ob das ISMS die Anforderungen erfüllt und wirksam umgesetzt und aufrechterhalten wird. Die Managementbewertung betrachtet Eignung, Angemessenheit und Wirksamkeit des Systems und trifft Entscheidungen über Änderungen und Ressourcen. Diese Tätigkeiten ergänzen einander, sind aber nicht austauschbar.

Die Leitung sollte entscheidungsreife Informationen erhalten: wesentliche Risiken, überfällige Behandlungen, wiederholte Fehler, Auditfeststellungen, sich ändernde Anforderungen und Ressourcenengpässe. Wer abgeschlossene Aufgaben zählt, ohne die Ergebnisse zu betrachten, kann schwache Leistung verdecken. Der Leitfaden zu ISMS-Kennzahlen behandelt nützliche Messgrößen.

Auch das Vorfallmanagement gehört in diesen Zyklus. Legen Sie Meldewege, Bewertungskriterien, Reaktionsverantwortlichkeiten, Kommunikationsbefugnisse und Wiederherstellungsregelungen fest. Testen Sie Kontaktwege und Entscheidungsfindung in Übungen. Prüfen Sie anwendbare Meldepflichten, statt anzunehmen, eine einzige Frist gelte für jeden Vorfall.

Beheben Sie nach einem Vorfall oder einer Nichtkonformität das unmittelbare Problem, untersuchen Sie die Ursachen, setzen Sie Korrekturmaßnahmen um und bewerten Sie deren Wirksamkeit. Wiederholte Feststellungen sind ein Anlass, Prozessgestaltung oder Ressourcen zu überdenken, nicht einfach dieselbe Erinnerung zu wiederholen.

Trennen Sie ISMS, Zertifizierung und gesetzliche Pflichten

Das ISMS ist das System, das die Organisation betreibt. ISO 27001 ist eine Norm, anhand derer dieses System bewertet werden kann. Die Zertifizierung wird von einer unabhängigen Zertifizierungsstelle erteilt, nicht von ISO oder Secani, und gilt für den angegebenen Geltungsbereich.

Eine Zertifizierung kann ein nützliches Instrument der Vertrauensbildung sein, wenn Kunden oder andere Anspruchsgruppen sie verlangen. Sie beweist nicht, dass jede Unternehmenstätigkeit abgedeckt ist, jede Maßnahme immer funktioniert oder keine Vorfälle eintreten können. Prüfen Sie Geltungsbereich und Status, statt ein Zertifikat als unternehmensweite Sicherheitsgarantie zu behandeln.

Die rechtliche Anwendbarkeit erfordert eine gesonderte Analyse. Artikel 32 DSGVO verlangt geeignete technische und organisatorische Sicherheitsmaßnahmen auf Grundlage der relevanten Risiken. NIS2 regelt über die nationale Umsetzung die Aufsicht durch die Leitung, Risikomanagementmaßnahmen und die Meldung von Sicherheitsvorfällen für erfasste Einrichtungen.

Ein ISMS kann Nachweise und Verantwortlichkeiten ordnen, die solche Pflichten unterstützen, doch eine Zertifizierung begründet keine Konformität mit der DSGVO oder NIS2. Ebenso wenig trifft es zu, dass ein ISMS niemals gesetzlich vorgeschrieben sein kann: Anwendbare nationale oder branchenspezifische Vorschriften müssen geprüft werden.

Vermeiden Sie drei vorhersehbare Fehler bei der Umsetzung

Vorlagen unverändert übernehmen. Vorlagen können eine Gliederung liefern, doch die Verantwortlichen müssen jede Zusage mit der tatsächlichen Praxis abgleichen. Eine Richtlinie, die Überprüfungen verlangt, die niemand durchführt, erzeugt eine ungesteuerte Lücke.

Eine Grenze ziehen, die niemand pflegen kann. Ein ambitioniertes Inventar nützt wenig, wenn Verantwortung und Abhängigkeiten unklar sind. Beginnen Sie mit einer begründbaren Grenze um einen Dienst und erweitern Sie sie dann nach einem ausdrücklichen Plan.

Die Zertifizierung als Ziellinie betrachten. Das System muss Personalwechsel, Lieferantenwechsel, Vorfälle und neue Produkte überdauern. Budgetieren Sie Betrieb, Überprüfung und Verbesserung, nicht nur die anfängliche Dokumentation.

Eine verwandte Warnung betrifft ungeprüfte Automatisierung. Automatisch erhobene Aufzeichnungen und KI-generierte Zusammenfassungen können die Arbeit unterstützen, doch Menschen müssen weiterhin die Relevanz bestimmen, Lücken bewerten und Schlussfolgerungen freigeben.

Machen Sie die erste Entscheidung der Leitung konkret

Wählen Sie einen repräsentativen Dienst und bitten Sie die verantwortliche Person, eine Beschreibung des Geltungsbereichs, eine Abhängigkeitskarte, erste Risikoszenarien, die aktuellen Maßnahmen und offene Entscheidungen mitzubringen. Vereinbaren Sie, wer Risiken akzeptieren darf, welche Ressourcen verfügbar sind und wann der Fortschritt überprüft wird. So entsteht ein beherrschbarer Ausgangspunkt, ohne so zu tun, als sei bereits die gesamte Organisation abgedeckt.

Das Arbeitsbereichsmodell von Secani unterstützt diesen Ablauf, indem es Dienste und unterstützende Zielobjekte modelliert, Nachweise mit Anforderungen, Maßnahmen und Entscheidungen verbindet und Verantwortliche sowie Prüfzuständigkeiten zuweist. Teams können fehlende Nachweise oder unklare Verantwortung in Aufgaben überführen. KI-gestützte Vorschläge bleiben Entwürfe für die menschliche Prüfung, wobei Quellen und Freigaben nachvollziehbar bleiben.

Das nächste Gespräch der Leitung sollte daher konkret sein: Welchen Dienst schützen wir zuerst, welche Gefährdung erfordert jetzt eine Entscheidung und welche Nachweise werden zeigen, dass die Entscheidung gewirkt hat?