ISO 27001 für KMU: Was wirklich gefordert ist – und was nicht

Ein Kunde schickt einen Lieferantenfragebogen, und in Zeile 14 steht: „Verfügen Sie über eine Zertifizierung nach ISO 27001?“ Oder eine Ausschreibung setzt sie schlicht voraus. Für viele mittelständische Unternehmen ist das der erste echte Kontakt mit der Norm – und die erste Reaktion ist fast immer dieselbe: „Dafür sind wir zu klein. Wir haben ja nicht mal eine eigene IT-Abteilung.“

Diese Reaktion ist verständlich, aber sie beruht auf einem Missverständnis. ISO 27001 verlangt keine Konzern-IT. Sie verlangt, dass Sie wissen, welche Informationen Sie schützen müssen, welche Risiken dabei bestehen und was Sie dagegen tun. Dieser Artikel zeigt, was die Norm konkret fordert – und mindestens genauso wichtig: was sie nicht fordert.

ISO 27001 ist kein IT-Projekt

Der häufigste Denkfehler: ISO 27001 wird als Katalog technischer Sicherheitsmaßnahmen gelesen, den man abarbeitet. Firewall, Virenschutz, Backup – Haken dran, fertig.

Tatsächlich ist ISO 27001 eine Norm für ein Managementsystem für Informationssicherheit (ISMS). Die eigentlichen Anforderungen stehen in den Kapiteln 4 bis 10 und beschreiben einen Führungsprozess: Kontext verstehen, Verantwortung festlegen, Risiken beurteilen, Maßnahmen planen, umsetzen, messen, verbessern. Wer schon mit ISO 9001 arbeitet, erkennt die Struktur sofort wieder – sie ist bei allen modernen ISO-Managementsystemnormen identisch.

Erst danach kommt der berühmte Anhang A mit seinen Sicherheitsmaßnahmen. Und der ist ausdrücklich ein Referenzverzeichnis, das im Zusammenhang mit der Risikobehandlung nach Abschnitt 6.1.3 zu verwenden ist – keine Checkliste zum Abhaken. Dazu gleich mehr.

Praktisch heißt das: Ein ISO-27001-Projekt gehört nicht allein in die IT. Es betrifft Personal (Onboarding, Offboarding, Vertraulichkeitsvereinbarungen), Einkauf (Dienstleister und Cloud-Anbieter), Vertrieb (Kundenanforderungen) und vor allem die Geschäftsführung.

Der Kern: Geltungsbereich, Risiken, Erklärung zur Anwendbarkeit

Wenn Sie nur drei Dinge aus der Norm mitnehmen, dann diese:

1. Der Geltungsbereich (Abschnitt 4.3). Sie legen fest, welche Bereiche, Standorte, Prozesse und Systeme das ISMS umfasst. Der Geltungsbereich muss als dokumentierte Information verfügbar sein. Er ist die wichtigste Stellschraube für den Aufwand: Ein sauber begründeter Scope – etwa „Entwicklung und Betrieb der SaaS-Plattform am Standort X“ – ist deutlich schlanker als „das gesamte Unternehmen“. Wichtig ist nur, dass er zu dem passt, was Ihre Kunden von Ihnen erwarten. Ein Zertifikat, das ausgerechnet den Prozess ausklammert, für den der Kunde Sie beauftragt, hilft niemandem.

2. Die Risikobeurteilung (Abschnitt 6.1.2). Sie legen Risikokriterien fest – darunter Akzeptanzkriterien – und beurteilen damit Risiken für Vertraulichkeit, Integrität und Verfügbarkeit der Informationen in Ihrem Geltungsbereich. Zu jedem Risiko gehört ein Risikoeigentümer. Die Norm schreibt keine bestimmte Methode vor. Sie verlangt nur, dass wiederholte Beurteilungen konsistente, valide und vergleichbare Ergebnisse liefern. Für ein KMU reicht dafür in aller Regel eine nachvollziehbar aufgebaute Tabelle.

3. Die Erklärung zur Anwendbarkeit (Statement of Applicability, SoA). Das ist das zentrale Dokument der Norm – und dasjenige, das jeder Auditor als Erstes sehen will. Laut Abschnitt 6.1.3 d) muss es enthalten: die notwendigen Maßnahmen, die Begründung für ihre Aufnahme, die Angabe, ob sie umgesetzt sind oder nicht, und die Begründung für den Ausschluss von Maßnahmen aus Anhang A.

Dazu kommen ein Risikobehandlungsplan sowie die Freigabe dieses Plans durch die Risikoeigentümer – einschließlich der ausdrücklichen Akzeptanz der verbleibenden Restrisiken. Genau dieser Punkt wird oft übersehen: Restrisiken darf man tragen, aber jemand muss die Entscheidung bewusst und nachweisbar treffen.

Die 93 Maßnahmen aus Anhang A – und warum Sie nicht alle brauchen

Anhang A der ISO/IEC 27001:2022 enthält 93 Maßnahmen in vier Themenbereichen:

• 37 organisatorische Maßnahmen (A 5.1–5.37): Richtlinien, Rollen, Lieferantenbeziehungen, Umgang mit Sicherheitsvorfällen, Kontinuitätsplanung
• 8 personenbezogene Maßnahmen (A 6.1–6.8): Überprüfung vor der Einstellung, Vertraulichkeitsvereinbarungen, Sensibilisierung, Verfahren nach Beendigung des Arbeitsverhältnisses
• 14 physische Maßnahmen (A 7.1–7.14): Zutritt, Arbeitsplatzsicherheit, Entsorgung von Datenträgern, Arbeiten außerhalb des Büros
• 34 technologische Maßnahmen (A 8.1–8.34): Zugriffsrechte, Verschlüsselung, Protokollierung, Schwachstellenmanagement, sichere Entwicklung

Die entscheidende Frage lautet nicht „Wie setzen wir alle 93 um?“, sondern: Welche Maßnahmen sind nötig, um die Risiken zu behandeln, die Sie in Schritt 2 identifiziert haben? Die Norm geht in 6.1.3 genau diesen Weg – erst die notwendigen Maßnahmen bestimmen, dann mit Anhang A abgleichen und prüfen, ob nichts Notwendiges übersehen wurde.

Zwei Konsequenzen daraus, die in der Praxis regelmäßig für Überraschung sorgen:

Sie dürfen Maßnahmen ausschließen – wenn Sie den Ausschluss im SoA begründen. Ein Unternehmen ohne eigene Softwareentwicklung braucht die Maßnahmen zur sicheren Entwicklung nicht anzuwenden. Das ist kein Schummeln, das ist der von der Norm vorgesehene Weg.

Anhang A ist nicht abschließend. Die Norm stellt ausdrücklich klar, dass weitere Maßnahmen aufgenommen werden können, wenn sie nötig sind. Wenn Ihre Risikobeurteilung etwas zutage fördert, wofür Anhang A keine passende Maßnahme kennt, definieren Sie eine eigene.

Was Sie wirklich dokumentieren müssen

Die Liste der von der Norm ausdrücklich geforderten Dokumente und Nachweise ist kürzer, als die meisten erwarten:

• Geltungsbereich des ISMS (4.3)
• Informationssicherheitsleitlinie (5.2)
• Prozess der Risikobeurteilung und der Risikobehandlung (6.1.2, 6.1.3)
• Erklärung zur Anwendbarkeit und Risikobehandlungsplan (6.1.3)
• Informationssicherheitsziele (6.2)
• Nachweise der Kompetenz der beteiligten Personen (7.2)
• Ergebnisse der Risikobeurteilungen und der Risikobehandlung (8.2, 8.3)
• Ergebnisse der Überwachung und Messung (9.1)
• Auditprogramm und Auditergebnisse (9.2)
• Ergebnisse der Managementbewertung (9.3)
• Nichtkonformitäten und Korrekturmaßnahmen mit ihren Ergebnissen (10.2)

Dazu kommt eine offene Anforderung: dokumentierte Information in dem Umfang, den Sie für die Wirksamkeit Ihres ISMS als notwendig bestimmen (7.5.1). Die Norm merkt selbst an, dass dieser Umfang von Organisation zu Organisation unterschiedlich ausfallen kann – abhängig von Größe, Tätigkeit, Prozessen und Kompetenz der Mitarbeitenden. Ein 30-Personen-Betrieb braucht hier nachweislich weniger Papier als ein Konzern.

Was ISO 27001 nicht fordert

Genauso hilfreich wie die Anforderungsliste ist die Liste der Dinge, die viele für Pflicht halten – die aber keine ist:

• Kein ISMS-Handbuch. Die Norm kennt keine Anforderung an ein Handbuch. Ein Satz gut geführter Einzeldokumente reicht völlig.
• Kein hauptamtlicher Informationssicherheitsbeauftragter. Gefordert ist, dass die oberste Leitung Verantwortlichkeiten und Befugnisse zuweist und kommuniziert – insbesondere für die Normkonformität des ISMS und für die Berichterstattung an die Leitung (5.3). Ob das eine Vollzeitrolle, eine Teilzeitaufgabe oder ein externer Dienstleister übernimmt, steht nicht in der Norm.
• Keine bestimmte Software. Es gibt kein vorgeschriebenes ISMS-Tool. Tabellen und ein sauber strukturiertes Dokumentenablagesystem erfüllen die Anforderungen ebenso – ein Tool wird erst dann sinnvoll, wenn die Menge an Maßnahmen und Nachweisen unübersichtlich wird.
• Keine vorgeschriebene Risikomethode. Kein Pflicht-Scoring, keine Pflicht-Matrix. Gefordert sind definierte Kriterien und reproduzierbare Ergebnisse.
• Nicht alle 93 Maßnahmen. Siehe oben – begründete Ausschlüsse sind vorgesehen.
• Kein Penetrationstest als generelle Pflicht. In den Kapiteln 4 bis 10 kommt er nicht vor. Anhang A verlangt allerdings Schwachstellenmanagement (A 8.8) und Sicherheitstests in der Entwicklung (A 8.29) – wenn diese Maßnahmen für Sie anwendbar sind, brauchen Sie dafür ein belastbares Vorgehen. Ein jährlicher Pentest ist dann eine mögliche Antwort, aber nicht die einzige.

Die Klima-Ergänzung von 2024

Mit der Änderung ISO/IEC 27001:2022/Amd 1:2024 wurden zwei kleine, aber prüfrelevante Punkte ergänzt: Die Organisation muss bestimmen, ob der Klimawandel ein relevantes Thema ist (4.1). Und ein Hinweis stellt klar, dass interessierte Parteien Anforderungen mit Klimabezug stellen können (4.2).

Das ist kein verstecktes Umweltmanagementsystem. Es genügt, das Thema in der Kontextanalyse nachvollziehbar zu bewerten – und zu begründen, wenn es für Ihre Informationssicherheit keine Rolle spielt. Für Unternehmen mit eigenem Rechenzentrum oder klimasensiblen Standorten kann die Antwort allerdings durchaus „ja“ lauten, etwa mit Blick auf Verfügbarkeit und Notfallplanung.

Ein realistischer Fahrplan

Wenn Sie bei null anfangen, hat sich diese Reihenfolge bewährt:

1. Geltungsbereich klären. Was schützen wir, für wen, an welchen Standorten? Diese Entscheidung bestimmt den gesamten Projektumfang.
2. Gap-Analyse. Wo stehen Sie heute gegenüber Kapiteln 4–10 und Anhang A? Erfahrungsgemäß ist mehr vorhanden als gedacht, es ist nur nicht dokumentiert.
3. Leitlinie, Rollen, Ziele. Die Leitungsebene legt Rahmen und Verantwortlichkeiten fest – ohne diesen Schritt bleibt alles Weitere Papier.
4. Risiken beurteilen und behandeln. Risiken erfassen, bewerten, Maßnahmen bestimmen, mit Anhang A abgleichen, SoA und Behandlungsplan erstellen, Restrisiken freigeben lassen.
5. Maßnahmen umsetzen und Nachweise erzeugen. Hier entsteht der eigentliche Sicherheitsgewinn – und hier braucht es Zeit, weil Verhalten sich langsamer ändert als Dokumente.
6. Internes Audit und Managementbewertung. Beides muss vor dem Zertifizierungsaudit stattgefunden haben. Die Norm verlangt für interne Audits ausdrücklich Objektivität und Unparteilichkeit des Auditprozesses – wer die Maßnahmen selbst eingeführt hat, sollte sie nicht selbst auditieren.

Für ein mittelständisches Unternehmen ist ein Zeitraum von rund sechs bis zwölf Monaten bis zum Zertifizierungsaudit realistisch – abhängig vor allem davon, wie klar der Geltungsbereich ist und wie konsequent die Leitung das Thema trägt.

Drei Stolpersteine, die immer wieder auftauchen

Der Geltungsbereich wird zu spät ernst genommen. Er wird nebenbei formuliert und später mühsam korrigiert, weil ein Kunde etwas anderes erwartet hat. Klären Sie zuerst, was im Zertifikat stehen soll.

Das SoA wird aus einer Vorlage übernommen. Fremdbegründungen halten keinem Audit stand, weil sie nicht zu Ihrer Risikobeurteilung passen. Die Vorlage darf die Struktur liefern – die Begründungen müssen aus Ihrem Haus kommen.

Dienstleister werden vergessen. Cloud-Speicher, IT-Systemhaus, Lohnbuchhaltung, Entwicklungspartner: Ein großer Teil der Informationen kleiner Unternehmen liegt bei Dritten. Anhang A widmet den Lieferantenbeziehungen mehrere Maßnahmen – bei Audits ist das regelmäßig ein Schwerpunkt.

Fazit

ISO 27001 ist für mittelständische Unternehmen machbar, wenn man sie so liest, wie sie gemeint ist: als Führungsaufgabe mit einem risikobasierten Kern, nicht als 93-Punkte-Pflichtprogramm. Der Umfang ergibt sich aus Ihrem Geltungsbereich und Ihren Risiken – und den bestimmen Sie selbst.

Wenn Sie wissen möchten, wie groß der Abstand zwischen Ihrem heutigen Stand und den Normanforderungen tatsächlich ist, ist eine Gap-Analyse der schnellste Weg zu einer belastbaren Antwort. Den ungefähren Aufwand können Sie vorab mit dem Kostenrechner abschätzen. Und wenn Ihr ISMS bereits steht und nur noch das unabhängige interne Audit fehlt, übernehme ich das als externer Auditor.

Fragen zu Ihrem konkreten Fall? Schreiben Sie mir – ein erstes Gespräch kostet nichts.