- Ein ISMS ist kein einmaliges Projekt, sondern ein lebendiger Managementprozess nach dem PDCA-Zyklus (Plan-Do-Check-Act).
- Ohne sichtbare Unterstützung der Geschäftsführung scheitert jedes ISMS — Budget, Ressourcen und klare Kommunikation sind Pflicht.
- Die neun Schritte umfassen: Management-Commitment, Scope, Rollen, Risikobewertung, SoA, Maßnahmen, Schulungen, Audit und kontinuierliche Verbesserung.
- Ein Unternehmen mit 100 Mitarbeitern kann ein zertifizierungsfähiges ISMS in 9 bis 12 Monaten aufbauen.
- Die häufigsten Stolperfallen: zu großer Scope, fehlende Verantwortlichkeiten und Dokumentation ohne gelebte Praxis.
Was ist ein ISMS und warum brauchst du eines?
Ein Informationssicherheits-Managementsystem (ISMS) ist weit mehr als eine Sammlung von Richtlinien in einem Ordner. Es ist ein systematischer Ansatz, um die Vertraulichkeit, Integrität und Verfügbarkeit deiner Informationen dauerhaft zu schützen. Die internationale Norm ISO 27001 definiert die Anforderungen dafür und hat sich als globaler Standard etabliert.
Warum sollte sich ein Unternehmen mit 50 bis 500 Mitarbeitern damit beschäftigen? Die Gründe sind handfest. Kunden und Geschäftspartner verlangen zunehmend einen Nachweis für Informationssicherheit. Cyberangriffe treffen den Mittelstand genauso hart wie Konzerne, oft härter, weil die Reserven kleiner sind. Regulierung wie NIS2 oder branchenspezifische Vorgaben (TISAX, KRITIS) machen ein ISMS in vielen Fällen ohnehin zur Pflicht. Und nicht zuletzt: Ein gut aufgesetztes ISMS spart langfristig Geld, weil Sicherheitsvorfälle seltener werden und die Reaktion darauf schneller funktioniert.
Der entscheidende Punkt ist dabei, dass ein ISMS kein reines IT-Thema ist. Es betrifft Prozesse, Menschen, physische Sicherheit und Organisation. Genau deshalb braucht es einen strukturierten Ansatz, der über das reine Installieren von Firewalls hinausgeht.
Die PDCA-Logik als roter Faden
Das gesamte ISMS folgt dem PDCA-Zyklus, also dem Kreislauf aus Plan, Do, Check und Act. Dieses Modell stammt ursprünglich aus dem Qualitätsmanagement und eignet sich hervorragend für die Informationssicherheit, weil es kontinuierliche Verbesserung in die DNA des Systems einbaut.
Plan bedeutet, dass du die Grundlagen schaffst: Scope definieren, Risiken bewerten, Maßnahmen planen. Do heißt, dass du diese Maßnahmen umsetzt und im Alltag verankerst. Check steht für die regelmäßige Überprüfung durch Audits, Kennzahlen und Management Reviews. Und Act bedeutet, dass du aus den Erkenntnissen Konsequenzen ziehst und das System weiterentwickelst.
Dieser Zyklus läuft nicht einmal durch und ist dann erledigt. Er dreht sich fortlaufend weiter und sorgt dafür, dass dein ISMS mit dem Unternehmen wächst und sich an neue Bedrohungen anpasst. Die folgenden neun Schritte orientieren sich an dieser Logik und führen dich durch den kompletten Aufbau.
Schritt 1: Unterstützung der Geschäftsführung sichern
Ohne die Geschäftsführung geht gar nichts. Das ist keine Floskel, sondern eine der härtesten Lektionen, die Unternehmen beim ISMS-Aufbau lernen. ISO 27001 fordert in Kapitel 5 explizit das Commitment der obersten Leitung, und zwar nicht als Unterschrift auf einem Dokument, sondern als aktive, sichtbare Unterstützung.
Was bedeutet das konkret für ein Unternehmen mit rund 100 Mitarbeitern? Die Geschäftsführung muss erstens ein Budget bereitstellen. Plane realistisch mit einem halben bis ganzen Stellenanteil für den Informationssicherheitsbeauftragten (ISB) und einem Projektbudget für Tools, externe Beratung und Schulungen. Bei einem Unternehmen dieser Größe sprechen wir von 30.000 bis 80.000 Euro im ersten Jahr, je nach Ausgangslage und Zertifizierungsambitionen.
Zweitens muss die Geschäftsführung das ISMS intern kommunizieren. Wenn die Belegschaft den Eindruck hat, dass Informationssicherheit nur ein Steckenpferd der IT-Abteilung ist, wird die Akzeptanz minimal sein. Eine klare Ansage von oben, dass Informationssicherheit strategische Priorität hat, verändert die Dynamik grundlegend.
Drittens braucht die Geschäftsführung eine Informationssicherheitsleitlinie, die sie selbst unterschreibt und veröffentlicht. Dieses Dokument beschreibt auf ein bis zwei Seiten die Sicherheitsziele, die Verpflichtung zur kontinuierlichen Verbesserung und die grundsätzliche Verantwortung aller Mitarbeitenden.
Praxistipp: Bereite für die Geschäftsführung eine kompakte Entscheidungsvorlage vor, die den Business Case klar macht. Zeige auf, welche Kunden ein ISMS erwarten, welche regulatorischen Anforderungen bestehen und was ein Sicherheitsvorfall das Unternehmen kosten würde. Führungskräfte denken in Risiken und Chancen, nicht in Kontrollkatalogen.
Schritt 2: Geltungsbereich (Scope) definieren
Der Scope legt fest, welche Teile deines Unternehmens das ISMS abdeckt. Hier werden früh die Weichen gestellt, und ein falscher Scope ist einer der häufigsten Gründe für gescheiterte ISMS-Projekte.
Für ein mittelständisches Unternehmen empfiehlt sich in der Regel, mit dem gesamten Unternehmen als Scope zu starten, sofern es sich auf wenige Standorte und eine überschaubare Organisationsstruktur beschränkt. Die Alternative, nur einzelne Abteilungen oder Prozesse einzubeziehen, klingt verlockend, führt aber zu Abgrenzungsproblemen. Wo hört die IT-Abteilung auf und wo fängt der Vertrieb an, wenn beide dasselbe CRM nutzen?
Der Scope muss dokumentiert werden und folgende Aspekte berücksichtigen: die internen und externen Themen, die relevant für das ISMS sind (z. B. Branche, regulatorisches Umfeld, Marktanforderungen), die Anforderungen interessierter Parteien (Kunden, Aufsichtsbehörden, Mitarbeitende, Lieferanten) sowie die Schnittstellen und Abhängigkeiten zu Bereichen, die möglicherweise außerhalb des Scopes liegen.
Ein Beispiel: Ein Softwareunternehmen mit 100 Mitarbeitern, verteilt auf zwei Büros und mit Remote-Arbeit, definiert seinen Scope als "Entwicklung, Betrieb und Vertrieb der SaaS-Plattform XY einschließlich aller unterstützenden Prozesse an den Standorten München und Berlin sowie im Remote-Betrieb." Das ist konkret, nachvollziehbar und lässt keinen Raum für Interpretationen.
Schritt 3: Rollen besetzen — ISB, Risikoeigner und Asset-Owner
Ein ISMS funktioniert nur, wenn klar ist, wer wofür zuständig ist. Die drei wichtigsten Rollen sind der Informationssicherheitsbeauftragte, die Risikoeigner und die Asset-Owner.
Der Informationssicherheitsbeauftragte (ISB) ist die zentrale Figur. Er koordiniert den gesamten ISMS-Aufbau, pflegt die Dokumentation, bereitet Audits vor und ist Ansprechpartner für alle Fragen zur Informationssicherheit. In einem Unternehmen mit 100 Mitarbeitern kann das eine dedizierte Stelle sein oder eine Rolle, die jemand mit 50 bis 70 Prozent seiner Arbeitszeit ausfüllt. Wichtig ist, dass der ISB nicht gleichzeitig der IT-Leiter ist, denn er muss die IT auch kritisch überprüfen können. Wenn das personell nicht anders machbar ist, braucht es zumindest eine klare Rollentrennung und externe Unterstützung für Audits.
Risikoeigner sind die Personen, die für bestimmte Risiken verantwortlich sind und über die Behandlung dieser Risiken entscheiden. Das sind typischerweise Abteilungsleiter oder Prozessverantwortliche. Der Vertriebsleiter ist beispielsweise Risikoeigner für Risiken rund um Kundendaten im CRM, die Entwicklungsleiterin für Risiken in der Softwareentwicklung. Risikoeigner müssen ihre Risiken kennen, die Maßnahmen mittragen und regelmäßig Restrisiken bewerten.
Asset-Owner verwalten die konkreten Informationswerte (Assets) des Unternehmens. Ein Asset kann ein Server sein, eine Datenbank, ein Geschäftsprozess oder ein Papierdokument. Der Asset-Owner weiß, welche Daten auf dem System liegen, wer Zugriff braucht und wie kritisch ein Ausfall wäre. In einem 100-Personen-Unternehmen fallen viele Asset-Owner-Rollen mit den Risikoeigner-Rollen zusammen, was völlig in Ordnung ist, solange es dokumentiert wird.
Lege eine RACI-Matrix an, die für jeden Bereich die Verantwortlichkeiten klärt: Wer ist verantwortlich (Responsible), wer rechenschaftspflichtig (Accountable), wer wird konsultiert (Consulted) und wer informiert (Informed)?
Schritt 4: Risikobewertung durchführen
Die Risikobewertung ist das Herzstück deines ISMS. Hier identifizierst du, was schiefgehen kann, wie wahrscheinlich das ist und welche Auswirkungen es hätte. ISO 27001 gibt dir bei der Methodik Freiheiten, aber der Prozess muss wiederholbar, nachvollziehbar und dokumentiert sein.
Zunächst brauchst du ein Asset-Inventar. Liste alle Informationswerte auf, die für dein Unternehmen wichtig sind: Kundendaten, Quellcode, Produktionspläne, Mitarbeiterdaten, Finanzdaten, IT-Systeme, Netzwerkkomponenten, physische Standorte. Bei einem 100-Mitarbeiter-Unternehmen kommt dabei schnell eine Liste mit 80 bis 150 Assets zusammen.
Dann bewertest du die Assets hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit. Eine einfache dreistufige Skala (niedrig, mittel, hoch) reicht für den Anfang. Die Kundendatenbank hat vermutlich hohe Anforderungen an Vertraulichkeit und Verfügbarkeit. Die interne Telefonliste eher niedrige.
Im nächsten Schritt identifizierst du Bedrohungen und Schwachstellen. Was könnte den Assets schaden? Ransomware-Angriffe, Fehlkonfigurationen, Mitarbeiterfehler, Hardwareausfälle, Naturereignisse, Social Engineering. Welche Schwachstellen machen diese Bedrohungen wahrscheinlicher? Fehlende Backups, veraltete Software, keine Multi-Faktor-Authentifizierung, ungeschulte Mitarbeitende.
Dann bestimmst du die Eintrittswahrscheinlichkeit und die Schadenshöhe für jedes Risikoszenario. Multipliziere beides zu einem Risikowert und lege Schwellenwerte fest: Welcher Risikowert ist akzeptabel? Welcher erfordert Maßnahmen? Welcher ist so hoch, dass sofort gehandelt werden muss?
Ein pragmatischer Ansatz für den Mittelstand: Arbeite mit einer 5×5-Matrix (Eintrittswahrscheinlichkeit und Auswirkung jeweils von 1 bis 5). In ISMS Lite ist diese Matrix vorkonfiguriert und berechnet den Risikowert sowie das Restrisiko automatisch. Risiken ab einem Wert von 12 behandelst du aktiv, Risiken ab 20 haben höchste Priorität. Diese Schwellenwerte definierst du in deiner Risikobewertungsmethodik, die ebenfalls dokumentiert werden muss.
Am Ende dieses Schritts hast du ein Risikoregister mit allen identifizierten Risiken, ihrer Bewertung und einer Entscheidung zur Risikobehandlung. Bedenke dabei, dass dieses Risikoregister selbst zu den sensibelsten Dokumenten deines Unternehmens gehört und die Frage der Datensouveränität bei der Wahl des Speicherorts eine wichtige Rolle spielt. Reduzieren (Maßnahme umsetzen), Übertragen (z. B. Versicherung), Vermeiden (Aktivität einstellen) oder Akzeptieren (bewusst tragen).
Schritt 5: Statement of Applicability erstellen
Das Statement of Applicability (SoA) ist eines der wichtigsten Dokumente im ISMS und gleichzeitig eines der am häufigsten unterschätzten. Es listet alle 93 Maßnahmen (Controls) aus dem Anhang A der ISO 27001:2022 auf und dokumentiert für jede einzelne, ob sie anwendbar ist oder nicht und warum.
Das SoA ist keine reine Checkbox-Übung. Für jede Maßnahme musst du begründen, ob und wie sie umgesetzt wird. "Nicht anwendbar" ist eine legitime Aussage, aber sie braucht eine nachvollziehbare Begründung. Wenn du keine Softwareentwicklung betreibst, kannst du Controls zur sicheren Entwicklung ausschließen. Aber du solltest genau prüfen, ob das wirklich stimmt, denn auch Makros in Excel-Sheets oder Konfigurationen in No-Code-Tools können als Entwicklung gelten.
Für ein typisches 100-Mitarbeiter-Unternehmen sind erfahrungsgemäß 70 bis 85 der 93 Controls relevant. Die Anwendbarkeitserklärung verknüpft jede Maßnahme mit den Risiken, die sie adressiert, und mit dem aktuellen Umsetzungsstand. Das macht das SoA zu einer Art Landkarte deines ISMS: Auf einen Blick siehst du, wo du stehst und wo noch Lücken bestehen.
Konkret enthält das SoA für jede Maßnahme: die Kontrollnummer und Bezeichnung (z. B. A.8.1 User Endpoint Devices), ob sie anwendbar ist (ja/nein), die Begründung bei Ausschluss, den Umsetzungsstatus (vollständig, teilweise, geplant, nicht umgesetzt), den Verweis auf die zugehörige Richtlinie oder den Nachweis und die Referenz zum Risiko, das damit behandelt wird.
Schritt 6: Richtlinien und Maßnahmen umsetzen
Jetzt geht es ans Eingemachte. Die Risiken sind bewertet, die Maßnahmen im SoA definiert, und nun müssen sie in die Praxis umgesetzt werden. Das bedeutet: Richtlinien schreiben, technische Maßnahmen implementieren und organisatorische Prozesse etablieren.
Richtlinien sind das dokumentierte Regelwerk deines ISMS. Ein typisches mittelständisches Unternehmen braucht zwischen 15 und 25 Richtlinien. Die wichtigsten sind: Informationssicherheitsleitlinie (Schritt 1), Richtlinie zur Risikobewertung, Zugangs- und Zugriffskontrollrichtlinie, Klassifizierungsrichtlinie für Informationen, Richtlinie für den Umgang mit Sicherheitsvorfällen, Backup-Richtlinie, Richtlinie für mobile Geräte und Remote-Arbeit, Lieferantenmanagement-Richtlinie und Business-Continuity-Richtlinie.
Beim Schreiben dieser Richtlinien gilt: So kurz wie möglich, so lang wie nötig. Niemand liest eine 40-seitige Zugriffskontrollrichtlinie. Zwei bis fünf Seiten pro Richtlinie reichen in den meisten Fällen. Schreibe in einer Sprache, die auch Nicht-Techniker verstehen. Und sorge dafür, dass die Richtlinien auffindbar und versioniert sind, idealerweise in einem zentralen System und nicht verstreut über verschiedene SharePoint-Ordner.
Technische Maßnahmen betreffen die IT-Infrastruktur: Multi-Faktor-Authentifizierung einführen, Verschlüsselung für Laptops und mobile Geräte aktivieren, Netzwerksegmentierung umsetzen, Patch-Management-Prozess etablieren, Backup-Konzept implementieren und testen, Logging und Monitoring einrichten. Priorisiere nach Risikowert: Die Maßnahmen für die höchsten Risiken kommen zuerst.
Organisatorische Maßnahmen sind oft schwieriger als technische, weil sie menschliches Verhalten betreffen: Clean-Desk-Policy, Besucherregelungen, Prozess für Mitarbeiter-Ein- und -Austritt (Onboarding/Offboarding von Zugriffsrechten), Regelungen zur Informationsklassifizierung und Vorgaben zur sicheren Entsorgung von Datenträgern.
Führe für jede Maßnahme einen Verantwortlichen und eine Frist ein. ISMS Lite verknüpft Maßnahmen direkt mit den Risiken und Controls, die sie adressieren, und erinnert automatisch an ablaufende Fristen. Ohne beides bleiben Maßnahmen auf ewig im Status "geplant".
Schritt 7: Schulungen und Awareness-Programm
Du kannst die beste technische Infrastruktur aufbauen, aber wenn deine Mitarbeitenden auf jeden Phishing-Link klicken, bringt das alles wenig. Schulungen und Awareness sind ein Pflichtbestandteil von ISO 27001 und einer der wirkungsvollsten Hebel für mehr Sicherheit.
Grundschulung für alle Mitarbeitenden: Jede Person im Unternehmen muss die Basics kennen: Was ist Phishing und wie erkenne ich es? Warum sind starke Passwörter und MFA wichtig? Was mache ich, wenn ich einen Sicherheitsvorfall bemerke? Wie gehe ich mit vertraulichen Informationen um? Wie funktioniert die Clean-Desk-Policy?
Diese Grundschulung sollte beim Onboarding stattfinden und danach mindestens einmal jährlich aufgefrischt werden. In einem 100-Mitarbeiter-Unternehmen reicht dafür ein 60- bis 90-minütiges Format, entweder als Präsenzschulung oder als E-Learning mit anschließendem kurzen Test.
Rollenspezifische Schulungen gehen tiefer: Die IT-Abteilung braucht Schulungen zu sicherer Konfiguration und Incident Response. Führungskräfte müssen verstehen, was ihre Verantwortung als Risikoeigner bedeutet. Der Einkauf sollte wissen, wie Lieferanten hinsichtlich Informationssicherheit bewertet werden.
Laufende Awareness geht über einzelne Schulungstermine hinaus. Phishing-Simulationen (monatlich oder quartalsweise), kurze Security-Tipps im Intranet oder per E-Mail, ein klar kommunizierter Meldeweg für verdächtige Aktivitäten und die regelmäßige Kommunikation von aktuellen Bedrohungen halten das Thema präsent.
Dokumentiere alles: Wer wurde wann geschult, welche Inhalte wurden vermittelt, wie war die Teilnahmequote? Diese Nachweise brauchst du für Audits und Management Reviews. Ein einfaches Schulungsregister in Tabellenform reicht aus.
Schritt 8: Internes Audit und Management Review
Das interne Audit ist die Nagelprobe für dein ISMS. Hier wird systematisch geprüft, ob das System funktioniert, ob Richtlinien eingehalten werden und ob es Lücken zwischen Dokumentation und Realität gibt.
Interne Audits müssen mindestens einmal jährlich stattfinden, besser ist ein rollierender Auditplan, der verschiedene Bereiche über das Jahr verteilt prüft. Der Auditor muss unabhängig sein, das heißt, er darf nicht den Bereich prüfen, für den er selbst verantwortlich ist. In einem 100-Mitarbeiter-Unternehmen kann das intern durch Cross-Audits gelöst werden (der ISB auditiert die IT, die Qualitätsmanagerin auditiert den ISB) oder du holst einen externen Auditor für ein bis zwei Tage im Jahr.
Der Auditprozess umfasst die Auditplanung (Scope, Zeitplan, Prüfkriterien), die Durchführung (Interviews, Dokumentenprüfung, Stichproben), den Auditbericht mit Feststellungen und den Maßnahmenplan für gefundene Abweichungen. Unterscheide zwischen Hauptabweichungen (schwerwiegend, gefährden die ISMS-Wirksamkeit), Nebenabweichungen (kleinere Mängel) und Verbesserungsmöglichkeiten (Empfehlungen ohne Abweichung).
Das Management Review findet mindestens einmal jährlich statt. Die Geschäftsführung prüft gemeinsam mit dem ISB den Zustand des ISMS und trifft strategische Entscheidungen. Das Review hat definierte Inputs: Ergebnisse interner Audits, Status der Risiken und Maßnahmen, Sicherheitsvorfälle seit dem letzten Review, Kennzahlen zur ISMS-Performance, Feedback von Mitarbeitenden und Stakeholdern, Veränderungen im Unternehmensumfeld und der Bedrohungslage.
Die Outputs des Management Reviews sind konkrete Entscheidungen: Welche Ressourcen werden bereitgestellt? Welche Risiken werden neu bewertet? Welche strategischen Ziele ändern sich? Diese Entscheidungen werden protokolliert und dienen als Input für den nächsten PDCA-Zyklus.
Schritt 9: Kontinuierliche Verbesserung leben
Der letzte Schritt ist eigentlich kein letzter Schritt, sondern eine dauerhafte Haltung. Kontinuierliche Verbesserung (KVP) bedeutet, dass du Erkenntnisse aus Audits, Vorfällen, Kennzahlen und Veränderungen im Umfeld systematisch nutzt, um dein ISMS weiterzuentwickeln.
Konkret heißt das: Jede Nichtkonformität aus einem Audit wird mit einer Ursachenanalyse versehen. Es reicht nicht, den Fehler zu beheben, du musst verstehen, warum er aufgetreten ist, und sicherstellen, dass er nicht wiederkehrt. Wenn ein Mitarbeiter einen Laptop im Zug verloren hat und die Festplatte nicht verschlüsselt war, ist die Korrektur offensichtlich (Verschlüsselung nachrüsten). Die Ursachenanalyse geht tiefer: Warum war die Verschlüsselung nicht aktiv? War die Richtlinie unklar? Hat das Onboarding versagt? Fehlt ein technischer Kontrollmechanismus?
Definiere ISMS-Kennzahlen, die dir zeigen, wie gut das System funktioniert: Anzahl der Sicherheitsvorfälle pro Quartal, durchschnittliche Reaktionszeit bei Vorfällen, Anteil der geschulten Mitarbeitenden, Anteil der umgesetzten Maßnahmen aus dem Risikobehandlungsplan, Ergebnisse von Phishing-Simulationen (Klickrate) und Anzahl offener Audit-Findings.
Diese Kennzahlen fließen in das Management Review ein und zeigen der Geschäftsführung, ob sich die Investition in Informationssicherheit auszahlt. Trends sind dabei wichtiger als absolute Zahlen: Sinkt die Klickrate bei Phishing-Simulationen über die Quartale? Werden Maßnahmen schneller umgesetzt als im Vorjahr? Dann ist dein ISMS auf dem richtigen Weg.
Realistischer Zeitplan für ein Unternehmen mit 100 Mitarbeitern
Wie lange dauert der ISMS-Aufbau? Die ehrliche Antwort: Es kommt darauf an. Aber für ein typisches Unternehmen mit 100 Mitarbeitern, einer IT-Abteilung mit drei bis fünf Personen und ohne vorheriges ISMS kannst du mit folgendem Zeitplan rechnen:
Monate 1 bis 2 — Fundament legen: Geschäftsführung überzeugen und Commitment sichern, ISB benennen und mit Ressourcen ausstatten, Scope definieren, Projektplan aufsetzen, Informationssicherheitsleitlinie erstellen und veröffentlichen.
Monate 3 bis 4 — Bestandsaufnahme: Asset-Inventar erstellen, Risikobewertungsmethodik festlegen, erste Risikobewertung durchführen. Gleichzeitig: vorhandene Dokumentation sichten und Gap-Analyse gegen ISO 27001 durchführen.
Monate 5 bis 7 — Aufbauen und dokumentieren: SoA erstellen, Richtlinien schreiben (priorisiert nach Risikobewertung), technische Maßnahmen planen und umsetzen, organisatorische Prozesse definieren, Schulungskonzept entwickeln.
Monate 8 bis 9 — Verankern: Erste Schulungsrunde für alle Mitarbeitenden, rollenspezifische Schulungen durchführen, Richtlinien im Alltag leben und anpassen, technische Maßnahmen abschließen.
Monate 10 bis 11 — Prüfen: Internes Audit durchführen, Findings beheben, Management Review durchführen, ISMS-Dokumentation finalisieren.
Monat 12 — Optionale Zertifizierung: Externe Zertifizierungsstelle beauftragen (frühzeitig, da Vorlaufzeiten von 2 bis 3 Monaten üblich sind). Stufe-1-Audit (Dokumentenprüfung) und Stufe-2-Audit (Vor-Ort-Prüfung) durchlaufen.
Dieser Zeitplan setzt voraus, dass der ISB das Thema mit hoher Priorität betreibt und mindestens 50 Prozent seiner Arbeitszeit dafür aufwenden kann. Mit externer Beratung lässt sich der Zeitplan um ein bis zwei Monate verkürzen, weil Erfahrung und Vorlagen die Dokumentationsphase beschleunigen. Ohne dedizierte Ressourcen dauert es entsprechend länger, 15 bis 18 Monate sind dann realistischer.
Typische Stolperfallen beim ISMS-Aufbau
Nach hunderten von ISMS-Projekten im Mittelstand kristallisieren sich immer wieder dieselben Fehler heraus. Kenne sie, bevor sie dich ausbremsen.
Zu großer Scope am Anfang. Wer alles auf einmal absichern will, verzettelt sich. Besser: Starte mit einem klar abgegrenzten Bereich, sammle Erfahrung und erweitere dann. Das gilt besonders für Unternehmen mit mehreren internationalen Standorten oder stark heterogenen Geschäftsbereichen.
Dokumentation ohne gelebte Praxis. Ein ISMS, das nur auf dem Papier existiert, übersteht kein Audit. Noch schlimmer: Es schützt auch nicht. Auditor:innen prüfen ausdrücklich, ob Richtlinien den Mitarbeitenden bekannt sind und ob sie tatsächlich eingehalten werden. Wenn die Zugriffskontrollrichtlinie vorschreibt, dass Zugänge bei Mitarbeiteraustritt am selben Tag gesperrt werden, aber in der Praxis manchmal Wochen vergehen, ist das eine Hauptabweichung.
Fehlende Verantwortlichkeiten. Wenn Risiken keinem Eigner zugeordnet sind, fühlt sich niemand zuständig. Das gleiche gilt für Maßnahmen ohne Deadline und Verantwortlichen. Alles, was niemandem gehört, bleibt liegen.
Copy-Paste-Richtlinien. Vorlagen sind ein guter Startpunkt, aber sie müssen auf dein Unternehmen angepasst werden. Ein Auditor erkennt sofort, ob eine Richtlinie aus einer Vorlage kommt und nie angepasst wurde, spätestens wenn Firmennamen, Abteilungsbezeichnungen oder Systemlandschaften nicht zum Unternehmen passen.
IT als Einzelkämpfer. Informationssicherheit betrifft das gesamte Unternehmen. Wenn nur die IT-Abteilung sich darum kümmert, fehlen die organisatorischen Maßnahmen, die Einbindung der Fachabteilungen und am Ende das Verständnis der Geschäftsführung. Binde von Anfang an HR, Einkauf, Facility Management und die Fachbereiche mit ein.
Keine Nachverfolgung. Maßnahmen definieren ist einfach, sie nachzuverfolgen erfordert Disziplin. Richte dir einen festen Rhythmus ein, monatlich oder quartalsweise, in dem du den Status aller offenen Maßnahmen prüfst. Ohne diesen Rhythmus schleicht sich schleichend ein Maßnahmenstau ein, der kurz vor dem Audit zu Panik führt.
Perfektionismus statt Pragmatismus. Dein ISMS muss beim ersten Durchlauf nicht perfekt sein. Es muss funktionieren und den PDCA-Zyklus durchlaufen. Die Verbesserung kommt mit jeder Iteration. Ein gutes ISMS in sechs Monaten schlägt ein perfektes ISMS, das nie fertig wird.
Fazit: ISMS aufbauen ist ein Marathon, kein Sprint
Ein ISMS aufzubauen ist machbar, auch für Unternehmen, die bei null starten. Der Schlüssel liegt in der richtigen Reihenfolge, ausreichenden Ressourcen und der Bereitschaft, Informationssicherheit als dauerhaften Prozess statt als einmaliges Projekt zu begreifen.
Die neun Schritte in diesem Leitfaden geben dir einen erprobten Fahrplan. Doch das beste Framework hilft wenig, wenn die Werkzeuge nicht stimmen. Wer Risikobewertungen in Excel-Tabellen pflegt, Richtlinien in Word-Dokumenten verwaltet und Maßnahmen über E-Mail nachverfolgt, verbringt mehr Zeit mit Administration als mit echter Sicherheitsarbeit.
Weiterführende Artikel
- Geltungsbereich (Scope) definieren: Was gehört ins ISMS und was nicht?
- Statement of Applicability (SoA) erstellen: Controls auswählen und begründen
- Die wichtigsten ISMS-Rollen: ISB, CISO, Risikoeigner – wer macht was?
- Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
- Informationssicherheitsrichtlinie schreiben: Aufbau, Inhalt und Beispiel
Ein spezialisiertes ISMS-Tool für den Mittelstand macht den Unterschied: Risiken, Maßnahmen, Assets und Dokumente an einem Ort, strukturiert nach ISO 27001 und jederzeit auditbereit. So kannst du dich auf das konzentrieren, was wirklich zählt: die Sicherheit deiner Informationen.
