ISO 27001: Womit anfangen? Mit dem Zoom-in auf Ihr Unternehmen

„Wir wollen mit ISO 27001 anfangen. Welche Richtlinie sollen wir zuerst schreiben?“

Die Frage ist verständlich. Sie setzt nur ungefähr drei Stockwerke zu tief an. Wer gleich mit Richtlinien, Risikolisten, Maßnahmenkatalogen oder einem ISMS-Tool beginnt, hat schon sehr viel Detail auf dem Tisch – aber noch nicht geklärt, welches Unternehmen er da eigentlich absichern will.

Der sinnvollere Einstieg in die ISO 27001 ist ein Zoom-in. Sie beginnen weit über dem Unternehmen und holen das Bild dann schrittweise näher heran: erst die relevanten Themen, dann die beteiligten Akteure, dann deren Anforderungen und Schutzinteressen. Erst danach bestimmen Sie, welcher Teil des Unternehmens in den Anwendungsbereich des ISMS gehört.

Das klingt zunächst abstrakter als eine hübsche Richtlinienvorlage. Praktisch erspart es Ihnen aber sehr viel Kokolores im weiteren Projekt.

Die kurze Antwort

Beginnen Sie nicht mit Dokumenten und auch nicht mit einer Liste aus Anhang A. Beginnen Sie mit dem Unternehmen:

1. Welche internen und externen Themen beeinflussen das Unternehmen und seine Informationssicherheit?
2. Welche interessierten Parteien bewegen sich im Umfeld dieser Themen?
3. Welche Anforderungen stellen diese Parteien?
4. Welche Schutzinteressen stecken hinter diesen Anforderungen?
5. Welche Anforderungen werden durch das ISMS berücksichtigt?
6. Welche Leistungen, Prozesse, Organisationseinheiten, Standorte, Systeme und Abhängigkeiten braucht es dafür?

Das Ergebnis dieser Kette ist kein aus dem Bauch geratener Scope. Es ist ein begründeter Anwendungsbereich.

Der Zoom beginnt weit über dem Unternehmen

Stellen Sie sich eine Kartenanwendung vor. Ganz am Anfang sehen Sie nicht den einzelnen Schreibtisch, den Server oder die Firewall. Sie sehen erst einmal das Unternehmen in seiner Umgebung: Markt, Kunden, Gesetzgeber, Technik, Mitarbeiter, Lieferanten, Strategie, Kultur und wirtschaftliche Lage.

Genau dort setzt Abschnitt 4.1 der ISO 27001 an. Die Organisation soll die externen und internen Themen bestimmen, die für ihren Zweck relevant sind und sich darauf auswirken, ob das ISMS seine beabsichtigten Ergebnisse erreicht.

Das Wort Themen ist dabei wenig gnädig. Es sagt nicht von selbst, woran man denken soll. Eine sehr brauchbare Konkretisierung lieferte Abschnitt 2.2.3 der inzwischen zurückgezogenen ISO 9000:2015. Dort wurde der Kontext einer Organisation als Zusammenspiel innerer und äußerer Faktoren erklärt. Als interne Blickrichtungen wurden beispielsweise Werte, Kultur, Wissen und Leistung genannt; extern ging es unter anderem um gesetzliche, technologische, wettbewerbliche, marktbezogene, kulturelle, soziale und wirtschaftliche Umfelder.

Die aktuelle ISO 9000:2026 fasst den Grundgedanken knapper: Zum Kontext gehören interne und externe Themen, die beeinflussen können, wie eine Organisation ihre Ziele festlegt und erreicht. Für den Workshop bleibt die ältere Aufzählung trotzdem eine ausgezeichnete Denkhilfe. Man muss ja nicht so tun, als wäre eine hilfreiche Checkliste plötzlich wertlos geworden, nur weil die Normausgabe gewechselt hat.

Zoomstufe 1: Welche Themen beeinflussen uns?

Jetzt sammeln Sie. Noch keine Anforderungen, noch keine Maßnahmen und bitte auch noch keine Firewallmodelle. Zunächst geht es um Faktoren, die für das Unternehmen und seine Informationssicherheit eine Rolle spielen.

Interne Themen können zum Beispiel sein:

• starkes Wachstum und viele neue Mitarbeiter,
• eine sehr informelle Unternehmenskultur,
• erhebliche Abhängigkeit von einzelnen Wissensträgern,
• veraltete Eigenentwicklungen,
• eine geplante Umstrukturierung,
• knappe personelle oder finanzielle Ressourcen,
• eine strategische Verlagerung in die Cloud,
• besonders sensible Forschungs-, Kunden- oder Gesundheitsdaten.

Externe Themen können unter anderem sein:

• neue oder geänderte gesetzliche Anforderungen,
• eine veränderte Bedrohungslage,
• technische Umbrüche,
• steigende Sicherheitsanforderungen von Kunden,
• Abhängigkeit von wenigen Cloud- oder Telekommunikationsanbietern,
• Fachkräftemangel,
• eine wirtschaftlich angespannte Branche,
• politische oder geografische Risiken an wichtigen Standorten.

Nicht jedes allgemein interessante Thema gehört in die Liste. Das neue Café gegenüber ist vermutlich nett, aber für das ISMS belanglos. Wenn allerdings der einzige Eingang zum Rechenzentrum wegen einer Großbaustelle monatelang nicht erreichbar sein wird, sieht die Sache anders aus.

Mehr zur sauberen Ermittlung finden Sie in unserem Artikel zum Kontext der Organisation.

Zoomstufe 2: Wer bewegt sich in diesen Themen?

Nun gehen Sie näher heran. Abschnitt 4.2 fragt nach den interessierten Parteien, die für das ISMS relevant sind. Der häufigste Fehler besteht darin, einfach eine Standardliste abzuschreiben: Kunden, Mitarbeiter, Behörden, Lieferanten, Geschäftsführung. Fertig.

So entsteht eine Liste, aber noch kein Verständnis.

Nützlicher ist die Frage: Wer handelt im Umfeld der gerade ermittelten Themen, wer ist davon betroffen oder wer stellt dazu Anforderungen?

Plötzlich wabern die Themen nicht mehr frei im Workshopraum herum. Sie bekommen Akteure. Und damit lässt sich weiterarbeiten.

Was eine interessierte Partei ist und wie man relevante von bloß irgendwie vorhandenen Parteien unterscheidet, erklären wir ausführlicher im Artikel ISO 27001: Was sind interessierte Parteien?.

Zoomstufe 3: Was wollen diese Parteien konkret?

Die Feststellung „Der Kunde ist eine interessierte Partei“ bringt fast nichts. Interessant wird es erst bei der nächsten Frage: Was erwartet oder verlangt dieser Kunde?

Beispiele:

• Ein Kunde verlangt vertraglich eine Verfügbarkeit von 99,9 Prozent.
• Eine Behörde verlangt die Meldung bestimmter Vorfälle innerhalb einer vorgegebenen Frist.
• Mitarbeiter erwarten, dass ihre Personal- und Gehaltsdaten nicht im ganzen Unternehmen einsehbar sind.
• Die Geschäftsführung erwartet, dass ein Ausfall nicht die Existenz des Unternehmens gefährdet.
• Ein Cloud-Anbieter verlangt, dass privilegierte Kundenzugänge mit Mehrfaktorauthentifizierung abgesichert werden.
• Ein Versicherer verlangt bestimmte technische und organisatorische Schutzmaßnahmen als Voraussetzung für den Versicherungsschutz.

Anforderungen können aus Gesetzen, Verträgen, behördlichen Vorgaben, Kundenvereinbarungen, internen Entscheidungen oder berechtigten Erwartungen stammen. Schreiben Sie deshalb nicht nur den Namen der Partei auf. Halten Sie fest, was diese Partei tatsächlich verlangt und woher Sie das wissen.

Zoomstufe 4: Welches Schutzinteresse steckt dahinter?

Jetzt wird die Verbindung zur Informationssicherheit deutlich. Fragen Sie bei jeder relevanten Anforderung: Was soll hier eigentlich geschützt werden?

Bei der Verfügbarkeit der SaaS-Plattform ist es offensichtlich die Verfügbarkeit. Bei Gehaltsdaten steht die Vertraulichkeit im Vordergrund. Bei Abrechnungsdaten kann die Integrität entscheidend sein. Häufig sind mehrere Schutzziele gleichzeitig betroffen.

Diese Übersetzung ist keine zusätzliche Tabellenpflicht aus Abschnitt 4.2. Sie ist eine praktische Methode. Sie hilft, schwammige Erwartungen in etwas zu verwandeln, das später für Risikobeurteilung, Sicherheitsziele und Maßnahmenauswahl brauchbar ist.

Aus „Der Kunde erwartet einen professionellen Betrieb“ wird dann beispielsweise:

• Unbefugte dürfen Kundendaten nicht lesen.
• Änderungen an Abrechnungsdaten müssen nachvollziehbar und korrekt sein.
• Der Dienst muss auch bei Ausfällen definierter Komponenten verfügbar bleiben.
• Sicherheitsvorfälle müssen erkannt, bewertet und fristgerecht kommuniziert werden.

Das ist erheblich belastbarer als das Wort professionell mit einem Haken dahinter.

Zoomstufe 5: Was berücksichtigt unser ISMS?

Abschnitt 4.2 verlangt nicht nur das Ermitteln relevanter Anforderungen. Das Unternehmen muss auch bestimmen, welche dieser Anforderungen durch das ISMS berücksichtigt werden.

Das ist eine echte Entscheidung – aber kein Wunschkonzert. Eine verbindliche gesetzliche oder vertragliche Pflicht verschwindet nicht, weil sie unbequem ist. Bei Erwartungen ohne verbindlichen Charakter kann dagegen durchaus entschieden werden, dass sie nicht Teil des ISMS werden. Diese Entscheidung sollte nachvollziehbar sein.

Praktisch bietet sich eine einfache Tabelle an:

Hier trennt sich das ISMS langsam vom allgemeinen Weltgeschehen. Der Zoom wird schärfer.

Zoomstufe 6: Jetzt lässt sich der Anwendungsbereich ableiten

Erst an dieser Stelle ist der Scope dran. Abschnitt 4.3 verlangt, Grenzen und Anwendbarkeit des ISMS festzulegen. Dabei müssen die Themen aus 4.1, die Anforderungen aus 4.2 sowie Schnittstellen und Abhängigkeiten zu Tätigkeiten anderer Organisationen berücksichtigt werden.

Der Anwendungsbereich ist deshalb nicht einfach „die IT“ und auch nicht das, was sich möglichst bequem zertifizieren lässt. Er muss die Leistungen und Tätigkeiten abdecken, mit denen das Unternehmen die berücksichtigten Anforderungen erfüllt.

Je nach Organisation gehören dazu beispielsweise:

• marktgerichtete Dienstleistungen oder Produkte,
• die dafür notwendigen Geschäftsprozesse,
• beteiligte Organisationseinheiten,
• relevante Standorte,
• eingesetzte Informationssysteme und Infrastruktur,
• zentrale Unterstützungsleistungen wie Personal, IT oder Facility Management,
• Schnittstellen und Abhängigkeiten zu ausgelagerten Dienstleistern.

Ein Cloud-Anbieter liegt vielleicht außerhalb Ihrer Organisation. Die Abhängigkeit von ihm liegt aber keineswegs außerhalb der Realität. Sie muss bei der Bestimmung des Anwendungsbereichs berücksichtigt werden.

Wie man den Scope sinnvoll begrenzt, erläutern wir in ISO 27001: Anwendungsbereich klein halten. Für die Formulierung auf dem Zertifikat gibt es zusätzlich unseren Praxisartikel ISO 27001 Scope formulieren.

Ein Beispiel einmal vollständig durchgezoomt

Nehmen wir einen Anbieter, der eine SaaS-Lösung für Krankenhäuser entwickelt und betreibt.

Auf der höchsten Flugebene erkennt das Unternehmen unter anderem diese Themen: sensible Gesundheitsdaten, hohe Verfügbarkeitsanforderungen, starke Abhängigkeit von einem Cloud-Anbieter und zunehmende Anforderungen der Krankenhauskunden.

Damit verbunden sind unter anderem Krankenhäuser, Nutzer, Patienten, der Cloud-Anbieter, Mitarbeiter, Aufsichtsbehörden und die Geschäftsführung.

Aus diesen Parteien ergeben sich konkrete Anforderungen: Schutz der Patientendaten, vertraglich zugesagte Verfügbarkeit, kontrollierte administrative Zugriffe, nachvollziehbare Änderungen, geregelte Vorfallmeldungen und die Fähigkeit, den Betrieb nach Störungen wiederherzustellen.

Die Anforderungen betreffen Vertraulichkeit, Integrität und Verfügbarkeit. Das Unternehmen entscheidet, welche davon durch sein ISMS berücksichtigt werden müssen. Bei gesetzlichen und vertraglichen Vorgaben ist diese Entscheidung erwartbar wenig überraschend.

Nun lässt sich der Anwendungsbereich herleiten: Entwicklung, Betrieb und Support der SaaS-Lösung gehören hinein. Ebenso die hierfür relevanten Teile von IT, Personal und Lieferantensteuerung. Der Cloud-Anbieter wird nicht zum eigenen Unternehmen umdeklariert, aber seine Schnittstelle und die Abhängigkeit von ihm müssen im ISMS behandelt werden.

So entsteht ein Scope aus geschäftlicher Wirklichkeit. Nicht aus dem Wunsch, möglichst wenige Leute zum Audit einzuladen.

Was dieser Zoom-in verhindert

Die Methode verhindert einige beliebte Fehlstarts:

Mit Vorlagen beginnen: Eine Richtlinie kann sprachlich perfekt sein und trotzdem nicht zu Verantwortlichkeiten, Kultur oder Arbeitsweise des Unternehmens passen.

Mit einem Tool beginnen: Ein Tool kann Informationen verwalten. Es kann nicht entscheiden, welche Erwartungen Ihre Kunden haben oder welches Geschäft Sie schützen wollen.

Mit Anhang A beginnen: Die Controls sind wichtig. Sie ersetzen aber weder den Kontext noch die Anforderungen interessierter Parteien noch die Risikobeurteilung.

Den Scope einfach möglichst klein zeichnen: Ein kleiner Scope ist nicht automatisch ein guter Scope. Wenn entscheidende Tätigkeiten, Schnittstellen oder Abhängigkeiten fehlen, ist er nur kunstvoll an der Realität vorbeiformuliert.

Sofort Risiken sammeln: Ohne Kontext und Schutzinteressen entstehen schnell universelle Risiken wie „Hackerangriff“ oder „Datenverlust“. Für ein brauchbares ISO 27001 Risikomanagement braucht man genaueres Futter.

So kann der erste Workshop aussehen

Für den ersten Termin brauchen Sie keinen fertigen Dokumentensatz. Sie brauchen die richtigen Leute und gute Fragen. Wer beteiligt sein sollte, behandeln wir ausführlich in ISO 27001: Wer gehört ins Projektteam?.

Für den Zoom-in können Sie mit diesen Fragen arbeiten:

1. Was verändert sich gerade intern und extern rund um unser Geschäft?
2. Welche dieser Veränderungen können Informationssicherheit oder Geschäftsfähigkeit beeinflussen?
3. Wer stellt in diesem Umfeld Anforderungen an uns?
4. Wo sind diese Anforderungen festgehalten?
5. Welche Informationen, Systeme, Dienstleistungen oder Abläufe sollen dadurch geschützt werden?
6. Welche Anforderungen berücksichtigen wir im ISMS – und warum?
7. Welche Leistungen und Prozesse erfüllen diese Anforderungen?
8. Welche Standorte, Systeme, Mitarbeiter und Lieferanten braucht es dafür?
9. Wo verlaufen echte Schnittstellen und Abhängigkeiten?
10. Welcher organisatorische Bereich bleibt nach dieser Ableitung als sinnvoller Scope übrig?

Das ist kein Workshop, in dem ein Berater die Antworten erraten sollte. Das Unternehmen muss zu seinem eigenen Geschäft, seinen Verpflichtungen und seinen Abhängigkeiten stehen. Der Berater kann die Methode führen, nachhaken und Widersprüche sichtbar machen. Die geschäftliche Wirklichkeit beisteuern muss das Unternehmen selbst.

Woran ein Auditor die Ableitung erkennt

Ein Auditor wird nicht nur prüfen, ob irgendwo ein Satz mit Anwendungsbereich überschrieben ist. Interessant ist, ob die Kette zusammenpasst:

• Sind die relevanten internen und externen Themen nachvollziehbar?
• Wurden daraus relevante interessierte Parteien und Anforderungen bestimmt?
• Ist erkennbar, welche Anforderungen durch das ISMS berücksichtigt werden?
• Passt der Scope zu den Leistungen, Prozessen, Standorten und Abhängigkeiten?
• Werden Änderungen an Kontext, Parteien und Anforderungen regelmäßig betrachtet?
• Liefert diese Grundlage brauchbare Eingaben für Risiken, Ziele und Maßnahmen?

Wenn zwischen den Listen keine erkennbare Verbindung besteht, sieht man schnell drei unabhängig gepflegte Tabellen. Wenn die Ableitung funktioniert, sieht man ein Unternehmen, das verstanden hat, warum sein ISMS so zugeschnitten ist.

Der Leitsatz dazu ist einfach: Ein guter ISMS-Scope wird nicht am Anfang geraten. Er bleibt am Ende übrig, wenn Sie von relevanten Themen über Akteure und Anforderungen immer weiter in Ihr Unternehmen hineinzoomen.

Interesse geweckt?

Sie möchten Ihr ISO 27001 Projekt nicht mit Formularen beginnen, sondern mit einer belastbaren Ableitung? Sprechen Sie mit uns.