Auch kleine Unternehmen werden mitunter mit der Frage konfrontiert, ob sie ein Informationssicherheitsmanagementsystem (ISMS) nach ISO 27001 einführen sollten oder können. Bei diesem Vorhaben stehen im Grunde alle Organisationen vor verschiedenen Herausforderungen. Für kleine Unternehmen stell sich die Frage, ob die mit der Zertifizierung einhergehenden Herausforderungen, Kosten und Aufwände gemeistert werden können, jedoch in besonderem Maße.

Daher möchten wir die verschiedenen Herausforderungen aus Sicht kleiner Unternehmen in einer kleinen Beitrags-Serie beleuchten und Lösungsansätze aufzeigen.

Die erste Herausforderung: Haben wir die Ressourcen für eine ISO-27001-Zertifizierung?

Die in der Regel größte Herausforderung kleiner Organisationen bei der Einführung und dem Betrieb eines ISMS ist die Frage der Ressourcen , allem voran der finanziellen und personellen Ressourcen. Wenngleich der Ressourcenbedarf selbstverständlich durchaus von der Unternehmensgröße und Komplexität (Anzahl der Geschäftsbereiche, Standorte u. ä.) des Unternehmens abhängt, verhält sich der Ressourcenbedarf leider nicht proportional zur Unternehmensgröße. Der zur Unternehmensgröße relative zeitliche und finanzielle Aufwand ist für kleine Unternehmen in der Regel vergleichsweise hoch.

Dem kann in verschiedenen Weisen begegnet werden. Ein erster, sich aufdrängender Ansatz ist, die Implementierung des ISMS schrittweise über einen längeren Zeitraum anzugehen. Dabei besteht jedoch das Risiko, dass dem Projekt mit der Zeit „die Luft ausgeht“, ein Schicksal, das vielen Langzeitprojekten droht. Insofern ist Vorsicht geboten.

Vielmehr möchte ich an dieser Stelle auf ein wesentliches Grundprinzip eines ISMS und des Standards ISO 27001 hinweisen: Angemessenheit und risikobasierendes Vorgehen.

Lösung 1: Kapitel 4 (= Kontext der Organisation) ernst nehmen

Ein ISMS bzw. der Standard ISO 27001 werden oft als bürokratisches Werk betrachtet. In besonderem Maße werden die Anforderungen des Kapitels 4 (Kontext der Organisation) des Standards häufig eher als reiner Formalismus gesehen und behandelt. So wie es der Standard vorgibt, sollte der erste Schritt einer ISMS-Implementierung die Analyse des Kontexts der Organisation und nicht das Schreiben von Richtlinien sein. Das heißt, es sollte zunächst folgende Fragen gestellt werden:

  1. Was wollen wir durch die Implementierung eines ISMS erreichen? Was sind keine Ziele des Projekts?
  2. Welche internen und externen Herausforderungen sollen adressiert werden? Welche Themen stellen mit Bezug zur Informationssicherheit Schwerpunkte für die Organisation dar? Und: Welche Themen spielen gegenwärtig keine oder nur eine untergeordnete Rolle? (Vgl. Kapitel 4.1)
  3. Was sind die interessierten Parteien und deren Erwartungen an die Organisation hinsichtlich der Informationssicherheit? (Vgl. Kapitel 4.2)

Bereits in diesem Stadium ist eine Priorisierung enorm hilfreich und kann später helfen, den Ressourcenbedarf zu senken. Aufgrund der vorgenannten Erwägungen sollte ein sinnvoller und angemessener Scope für das ISMS definiert werden. Oftmals wird ohne großes Hinterfragen direkt im ersten Zug das gesamte Unternehmen in den Scope des ISMS und der Zertifizierung einbezogen. Dies ist jedoch keineswegs erforderlich oder per se sinnvoll. Der ISO-27001-Standard ist in dieser Hinsicht nicht nur offen für Einschränkungen, sondern sieht diese ausdrücklich vor (vgl. Kapitel 4.3).

Grenzen können dabei typischerweise hinsichtlich der einbezogenen Geschäftsprozesse bzw. Geschäftsbereiche und der Standorte gezogen werden. Abhängig vom Kontext der Organisation kann jedoch beispielsweise auch eine Beschränkung auf bestimmte Arten von Informationen, beispielsweise personenbezogene Daten oder Kundendaten, erfolgen. Selbstverständlich muss der Scope regelmäßig einer Reevaluierung unterzogen werden. Im Rahmen dessen kann auch die zuvor erwähnte schrittweise Umsetzung in Form einer späteren Scope-Erweiterung erfolgen.

Lösung 2: Risikobasierter Ansatz und Angemessenheit

Kern eines ISMS nach ISO 27001 sind nicht die einzelnen Informationssicherheitsmaßnahmen (z. B. Patch-Management) des Annex A, sondern das Risikomanagement (Kapitel 6 und 8) und die kontinuierliche Verbesserung. Dies hat der Standard ISO 27001 mit gesetzlichen Vorgaben wie NIS-2 (vgl. Art. 21 Abs. 1 NIS-2: „geeignete und verhältnismäßige technische, operative und organisatorische Maßnahmen“) und DORA – Kern der Anforderungen aus DORA ist der IKT-Risikomanagementrahmen gemäß Art. 6 DORA – gemein.

Das heißt, eine ernsthafte und nicht nur formalistische Risikoanalyse ist essenziell, um die begrenzten Ressourcen gezielt für die tatsächlich erforderlichen und sinnvollen Risikobehandlungsoptionen einzusetzen. Die Risikoanalyse sollte auf einer geeigneten Informationssicherheits- bzw. Risikostrategie basieren. Kernfrage ist dabei vor allem der Risikoappetit der Geschäftsführung. Es kann abhängig von den Geschäftsstrategie (z. B. schnellstmöglicher Markteintritt bei einem jungen Startup) absolut legitim und sinnvoll sein, bewusst und willentlich auch hohe Informationssicherheitsrisiken zu akzeptieren.

Nachdem die identifizierten Risiken analysiert und bewertet wurden, müssen die Risikobehandlungsmaßnahmen festgelegt werden. Dabei liegt es in der Natur eines Risikomanagements, dass auch das Akzeptieren von Risiken eine valide Risikobehandlungsoption ist. Selbstverständlich dürfen dabei nicht einfach alle Risiken wahllos akzeptiert werden.

Die wichtigste Konsequenz dessen ist: Es müssen nicht grundsätzlich alle Kontrollen (Maßnahmen) aus dem Annex A der ISO 27001 in das Statement of Applicability (SoA) aufgenommen und umgesetzt werden. Man begegnet der Auffassung, dass alle Kontrollen aus dem Annex A, die in irgendeiner Weise für das Unternehmen thematisch anwendbar sind, anzuwenden seien, immer wieder. Dem steht jedoch der eindeutige Wortlaut der Norm entgegen („select appropriate information security risk treatment options“ (Kap. 6.1.3 a)); „determine all controls that are necessary to implement the information security risk treatment option(s) chosen“ (Kap. 6.1.3 b)) ). Es muss allerdings für alle Kontrollen des Annex A begründet werden, warum diese angewandt oder nicht angewandt werden.

Dies bedeutet beispielsweise, nur weil in einem Unternehmen Softwareentwicklungsaktivitäten (z. B. kleine Hilfswerkzeuge für interne Prozesse, Features für die Unternehmenswebseite) stattfinden, folgt daraus noch nicht zwingend, dass ein umfassender sicherer Softwareentwicklungsprozess auf Grundlage der Kontrollen A.8.4, A.8.25 – A.8.31 umzusetzen ist und die genannten Kontrollen in das SoA aufgenommen werden müssen. Das Unternehmen sollte seine begrenzten Ressourcen für wichtigere Maßnahmen einsetzen. Ist der Softwareentwicklungsprozess hingegen ein Kernprozess des Unternehmens, sollte der Schwerpunkt auf diese Maßnahmen gelegt werden.

Priorisierung der Risiken und Maßnahmen

Es ist nicht sinnvoll und in der Regel auch nicht möglich, alle technischen und organisatorischen Maßnahmen gleichzeitig in kurzer Zeit umzusetzen. Die Anforderungen der Norm ISO 27001 sehen ausdrücklich vor, dass die Risiken und Maßnahmen priorisiert werden sollen.

Das ISMS ist ferner nicht erst „fertig“, wenn alle identifizierten Risiken behandelt und alle geplanten Maßnahmen umgesetzt wurden. „Das ISMS“ bilden im Wesentlichen der vorgenannte, gesteuerte und wiederholte Risikomanagementprozess, die gesteuerte Dokumentation (vgl. Kap. 7.5) und Kommunikation (vgl. Kap. 7.4) sowie die Prozesse zur kontinuierlichen Verbesserung (Leistungs- bzw. Wirksamkeitsevaluierung (vgl. Kap. 9) und Behebung von Nichtkonformitäten (vgl. Kap. 10)). Zertifiziert nach ISO 27001 wird das Managementsystem, nicht die Informationssicherheit. Das heißt, eine Zertifizierung ist prinzipiell bereits möglich, wenn die vorgenannten Steuerungsprozesse nachweislich wirksam implementiert wurden. Es ist nicht erforderlich, dass bereits alle ausgewählten Maßnahmen des Annex A vollständig umgesetzt wurden. Entscheidend ist, dass es eine ordnungsgemäße Maßnahmenplanung gibt und dieser Plan auch laufend umgesetzt wird. Dies schließt wiederum an den initialen Gedanken der schrittweisen Umsetzung mit Blick auf die verfügbaren Ressourcen an.

Fazit

Selbstredend stellt die Einführung und Zertifizierung eines ISMS nach ISO 27001 vor allem für kleine Unternehmen hinsichtlich des Ressourcenbedarfs oftmals einen besonderen Kraftakt dar. Dieser lässt sich jedoch gut meistern, indem der Fokus auf das Wesentliche gesetzt wird und die wenigen verfügbaren Ressourcen zielgerichtet und effizient eingesetzt werden. Ein ISMS nach ISO 27001 muss kein überbordendes „Bürokratiemonster“ sein, sondern kann entsprechend der Art des Unternehmens schlank gehalten werden. Die ISO 27001 ermöglicht dies aufgrund ihrer sehr offen formulierten Anforderungen ganz bewusst.

Im nächsten Beitrag werden wir die Frage der „Prozessfähigkeit“ kleiner Unternehmen, d.h. die Herausforderung definierte Prozesse einzuführen und tatsächlich zu befolgen, betrachten.