- Ein ISMS in sechs Monaten aufzubauen ist ambitioniert, aber machbar, wenn die Geschäftsführung von Anfang an mitzieht und Ressourcen bereitstellt.
- Die größten Zeitfresser sind nicht technische Maßnahmen, sondern die Bestandsaufnahme vorhandener Prozesse und die Abstimmung zwischen Abteilungen.
- Excel-basierte Risikoanalysen stoßen spätestens bei 80 Assets an ihre Grenzen und werden zum Engpass im Projekt.
- Awareness-Schulungen wirken am besten, wenn sie früh starten und konkrete Beispiele aus dem eigenen Unternehmen verwenden.
- Parallelbetrieb von alten und neuen Prozessen in Monat 4 und 5 ist essenziell, um die Lücke zwischen Papier und gelebter Praxis zu schließen.
Die Ausgangslage: Ein Unternehmen unter Zugzwang
Die SecuTech GmbH ist ein fiktives, aber sehr realitätsnahes Unternehmen. Ein IT-Dienstleister mit 100 Mitarbeitern, drei Standorten in Deutschland, und einem Kundenstamm, der zunehmend unbequeme Fragen stellt. Der größte Kunde, ein Automobilzulieferer, hatte in der letzten Vertragsverhandlung ein ISO-27001-Zertifikat zur Bedingung für die Vertragsverlängerung gemacht. Zwei weitere Kunden hatten umfangreiche Sicherheitsfragebögen geschickt, die das Team nur mit erheblichem Aufwand beantworten konnte. Die Botschaft war eindeutig: Ohne nachweisbare Informationssicherheit würde es schwierig, im Geschäft zu bleiben.
Die Geschäftsführung entschied sich im Oktober für den Aufbau eines ISMS mit dem Ziel, innerhalb von sechs Monaten zertifizierungsfähig zu sein. Nicht zertifiziert, das wäre unrealistisch, denn der Zertifizierungsaudit braucht Vorlauf und einen Auditor. Aber so aufgestellt, dass ein externer Auditor grünes Licht geben könnte.
Was folgt, ist der Bericht über diese sechs Monate. Ungefiltert, mit allem, was schiefgelaufen ist, und den Lehren, die das Team daraus gezogen hat.
Monat 1: Grundlagen legen und Realität checken
Was geplant war
Die ersten vier Wochen sollten der Vorbereitung dienen: Projektteam zusammenstellen, Scope definieren, Bestandsaufnahme starten und die Informationssicherheitsleitlinie verabschieden. Klingt überschaubar.
Was tatsächlich passiert ist
Die Projektleitung übernahm der IT-Leiter, zusätzlich zu seinen normalen Aufgaben. Das war der erste Fehler, auch wenn das erst später klar wurde. Er stellte ein Kernteam zusammen: sich selbst als designierten ISB, eine Mitarbeiterin aus der Qualitätssicherung, einen Systemadministrator und den Datenschutzbeauftragten. Die Geschäftsführung beauftragte zusätzlich einen externen Berater für zwei Tage pro Woche.
Die Scope-Definition dauerte drei Meetings statt eines. Die zentrale Frage war, ob der kleine Entwicklungsstandort in Leipzig mit seinen 12 Mitarbeitern einbezogen werden sollte. Leipzig nutzte teilweise eigene Systeme und hatte eigene Prozesse. Der Berater empfahl, Leipzig zunächst auszuklammern und den Scope auf den Hauptstandort plus den zweiten Bürostandort zu beschränken. Diese Entscheidung sparte vermutlich zwei Monate, weil die Harmonisierung der Leipziger Systeme ein Projekt für sich gewesen wäre.
Die Bestandsaufnahme offenbarte Überraschendes. Es gab bereits Richtlinien, verstreut in einem SharePoint, in einer Wissensdatenbank und in den Köpfen einzelner Personen. Manche davon waren vier Jahre alt und nie aktualisiert worden. Andere waren aktuell, aber niemandem außerhalb der IT bekannt.
Die Informationssicherheitsleitlinie wurde in der letzten Woche des Monats finalisiert. Der Geschäftsführer unterschrieb sie, und sie wurde im Intranet veröffentlicht. Das war ein guter symbolischer Startpunkt.
Lehre aus Monat 1
Nimm dir für die Bestandsaufnahme doppelt so viel Zeit wie geplant. In jedem Unternehmen gibt es mehr vorhandene Dokumentation als gedacht, aber sie ist verstreut, veraltet oder unbekannt. Diese Bestände zu sichten, bevor man neue Dokumente erstellt, spart später massive Doppelarbeit.
Monat 2: Assets erfassen und Risiken bewerten
Was geplant war
Alle informationsverarbeitenden Assets erfassen, Schutzbedarf festlegen und die erste vollständige Risikobewertung durchführen. Das Team wollte dafür eine Excel-Vorlage des Beraters nutzen.
Was tatsächlich passiert ist
Die Asset-Erfassung wurde zur ersten echten Belastungsprobe. Der Systemadministrator begann mit den offensichtlichen Assets: Server, Firewalls, Switches, Laptops. Dann kamen die Anwendungen: ERP, CRM, Ticketsystem, Zeiterfassung, E-Mail, Kollaborationsplattform, diverse Cloud-Dienste. Dann die Datenbestände: Kundendaten, Vertragsdokumente, technische Dokumentation, Quellcode, Personaldaten.
Nach zwei Wochen standen 187 Assets in der Excel-Tabelle. Das war mehr als erwartet und stellte das Team vor ein Problem: Für jedes Asset musste der Schutzbedarf in den Dimensionen Vertraulichkeit, Integrität und Verfügbarkeit bewertet werden, und anschließend eine Risikobewertung mit Bedrohungen, Schwachstellen, Eintrittswahrscheinlichkeiten und Schadenshöhen erstellt werden.
Die Excel-Tabelle wurde schnell unübersichtlich. Verknüpfungen zwischen Assets und Risiken ließen sich nur über Freitextfelder oder separate Tabellenblätter abbilden. Wenn sich ein Risiko auf mehrere Assets bezog, musste es mehrfach eingetragen oder umständlich referenziert werden. In der dritten Woche war die Datei 4 MB groß und reagierte spürbar langsam.
Die Risikobewertung selbst verlief besser als erwartet, weil der externe Berater einen Workshop-Ansatz wählte. Statt jeden Risikoeigner einzeln zu befragen, setzte er thematische Workshops an: einen für Infrastruktur, einen für Anwendungen, einen für organisatorische Risiken. In jeweils drei Stunden bewertete das Team die Risiken gemeinsam. Das hatte den Nebeneffekt, dass die Beteiligten die Risiken anderer Bereiche kennenlernten und Zusammenhänge sichtbar wurden.
Am Ende des Monats standen 94 identifizierte Risiken, davon 23 mit hohem und 8 mit kritischem Risiko. Die kritischen betrafen vor allem fehlende Netzwerksegmentierung, unzureichendes Backup-Konzept und fehlende Multi-Faktor-Authentifizierung für privilegierte Zugänge.
Lehre aus Monat 2
Excel funktioniert für die erste Risikobewertung, aber es skaliert nicht. Spätestens wenn Risiken, Assets und Maßnahmen miteinander verknüpft werden müssen und verschiedene Personen gleichzeitig daran arbeiten, wird ein spezialisiertes Tool unverzichtbar. Das Team wechselte in Monat 3 auf ein ISMS-Tool, was eine Woche Migrationsaufwand bedeutete. Rückblickend hätte es sich gelohnt, von Anfang an mit dem Tool zu arbeiten. Ein spezialisiertes ISMS-Tool wie ISMS Lite hätte die Verknüpfung zwischen Assets, Risiken und Maßnahmen von Tag eins an sichergestellt.
Monat 3: Statement of Applicability und Maßnahmenplanung
Was geplant war
Das Statement of Applicability (SoA) erstellen, also entscheiden, welche der 93 Controls aus Anhang A der ISO 27001 anwendbar sind. Anschließend für jedes anwendbare Control den Umsetzungsstand bewerten und Maßnahmen ableiten.
Was tatsächlich passiert ist
Die erste Woche ging für die Migration der Risikobewertung von Excel in das neue ISMS-Tool drauf. Der Berater hatte dringend geraten, diesen Schritt jetzt zu machen, nicht später. Die Migration war mühsam: Risikobewertungen mussten manuell übertragen und dabei teilweise neu strukturiert werden. Aber danach lief die Arbeit deutlich flüssiger.
Das SoA erstellte der ISB zusammen mit dem Berater in zwei intensiven Arbeitstagen. Von den 93 Controls wurden 87 als anwendbar eingestuft. Die sechs ausgeschlossenen betrafen Bereiche, die für das Unternehmen keine Relevanz hatten, etwa die physische Sicherheit von Rechenzentren, weil alle Server bei einem externen Hoster standen.
Die Bewertung des Umsetzungsstands offenbarte ein gemischtes Bild. Etwa 40 Prozent der Controls waren bereits teilweise umgesetzt, oft ohne dass das bewusst war. Es gab eine Passwortrichtlinie, die in Active Directory technisch durchgesetzt wurde. Es gab ein Backup-Konzept, das allerdings nie getestet worden war. Es gab Zugriffsberechtigungen, die aber bei Mitarbeiterwechseln nicht konsequent angepasst wurden.
Die anderen 60 Prozent reichten von "Ansätze vorhanden, aber nicht dokumentiert" bis "komplett fehlend". Die größten Lücken lagen in den Bereichen Lieferantenbewertung, Logging und Monitoring, Änderungsmanagement und Schulung.
Für jede Lücke definierte das Team eine oder mehrere Maßnahmen mit Verantwortlichem, Frist und Priorität. Am Ende standen 68 Maßnahmen auf der Liste. Das war eine ehrliche, aber auch einschüchternde Zahl. Der Berater ordnete die Maßnahmen in drei Kategorien: Quick Wins (umsetzbar in unter einer Woche), mittelfristige Maßnahmen (ein bis drei Monate) und strategische Maßnahmen (dauerhaft).
Lehre aus Monat 3
Das SoA ist kein Dokument, das man einmal ausfüllt und dann ablegt. Es ist das zentrale Steuerungsinstrument des ISMS und muss bei jeder Änderung aktualisiert werden. Wer das SoA von Anfang an als lebendiges Dokument behandelt, hat es im Audit deutlich leichter. Außerdem ist die Kategorisierung der Maßnahmen nach Aufwand und Wirkung essenziell, damit das Team nicht an allen 68 Maßnahmen gleichzeitig arbeitet.
Monat 4: Richtlinien schreiben und Quick Wins umsetzen
Was geplant war
Alle erforderlichen Richtlinien erstellen, die Quick-Win-Maßnahmen umsetzen und mit den Awareness-Schulungen beginnen.
Was tatsächlich passiert ist
Dieser Monat war der arbeitsintensivste des gesamten Projekts. Das Team musste parallel an drei Fronten arbeiten: Richtlinien schreiben, technische Maßnahmen umsetzen und Schulungen vorbereiten.
Bei den Richtlinien half die Bestandsaufnahme aus Monat 1. Einige vorhandene Richtlinien konnten überarbeitet statt neu geschrieben werden. Die Passwortrichtlinie brauchte nur ein Update. Die Zutrittskontrolle für den Serverraum war dokumentiert und aktuell. Aber für Themen wie Lieferantenbewertung, Änderungsmanagement, Kapazitätsplanung und Kryptografie musste alles von Grund auf erstellt werden.
Der ISB machte hier einen Fehler, der typisch ist: Er versuchte, perfekte Richtlinien zu schreiben. Mehrseitige Dokumente mit detaillierten Verfahrensanweisungen, Flussdiagrammen und Anhängen. Der Berater bremste ihn nach der dritten Richtlinie: "Ein Auditor will sehen, dass die Richtlinie existiert, dass sie angemessen ist und dass sie gelebt wird. Zehn Seiten, die niemand liest, sind schlechter als zwei Seiten, die jeder kennt."
Dieses Umdenken beschleunigte die Arbeit erheblich. Das Team definierte ein Standardformat: maximale Länge von drei Seiten, einheitliche Struktur mit Zweck, Geltungsbereich, Verantwortlichkeiten, Regelungen und Kontrolle. Insgesamt entstanden 14 Richtlinien in diesem Monat.
Die Quick Wins liefen parallel und zeigten schnelle Wirkung. MFA wurde für alle Admin-Accounts und VPN-Zugänge aktiviert. Die Firewall-Regeln wurden bereinigt (dabei fielen drei Regeln auf, die noch auf einen Server verwiesen, der seit zwei Jahren abgeschaltet war). Automatische Bildschirmsperren wurden per Gruppenrichtlinie durchgesetzt. Der Serverraum erhielt eine Zutrittskontrolle mit Protokollierung.
Die erste Awareness-Schulung fand als Präsenzveranstaltung für alle Mitarbeiter statt. Der ISB hatte einen Vortrag vorbereitet, der mit einer Live-Demo einer Phishing-Attacke begann. Er zeigte, wie er in 15 Minuten eine täuschend echte Login-Seite für das Unternehmens-Intranet erstellt hatte. Das wirkte: Die Aufmerksamkeit im Raum war sofort da. Nach dem Vortrag meldeten sich mehrere Mitarbeiter mit Fragen und Hinweisen auf verdächtige E-Mails, die sie in der Vergangenheit erhalten hatten.
Lehre aus Monat 4
Richtlinien müssen praxistauglich sein, nicht akademisch. Kurze, klare Dokumente mit konkreten Regeln, die jeder versteht, schlagen umfangreiche Werke, die ungelesen im Intranet verstauben. Und bei Schulungen gilt: Ein einziges konkretes Beispiel aus der eigenen Firma wirkt stärker als zwanzig generische Folien über Cyberbedrohungen.
Monat 5: Prozesse verankern und testen
Was geplant war
Die neuen Prozesse in den Arbeitsalltag integrieren, Incident-Management und Change-Management aufsetzen und die ersten Restore-Tests für Backups durchführen.
Was tatsächlich passiert ist
Monat 5 war der Monat der unbequemen Wahrheiten. Die Richtlinien existierten, die technischen Maßnahmen waren großteils umgesetzt, aber die Frage war: Lebte das Team die Prozesse auch?
Der erste Härtetest kam beim Incident-Management. Ein Mitarbeiter meldete eine verdächtige E-Mail. Die Meldung ging an den ISB, der den definierten Prozess startete: E-Mail analysieren, Absender und Links prüfen, Bewertung vornehmen, Ergebnis dokumentieren und dem Melder Feedback geben. Der Prozess funktionierte, aber er dauerte vier Stunden statt der angepeilten zwei, weil die Zuständigkeiten zwischen ISB und IT-Team nicht klar genug definiert waren. Das führte zu einer Anpassung des Prozesses: Die Erstanalyse übernahm ab sofort der Helpdesk, und nur bei bestätigten Vorfällen wurde der ISB einbezogen.
Die Backup-Restore-Tests offenbarten ein ernstes Problem. Das tägliche Backup der Fileserver lief zuverlässig, aber als das Team einen vollständigen Restore eines virtuellen Servers testete, dauerte der Vorgang 14 Stunden statt der erwarteten 4. Der Grund: Die Backup-Lösung war auf inkrementelle Sicherungen konfiguriert, und der letzte Vollbackup lag drei Wochen zurück. Die Recovery-Zeit von 14 Stunden war für kritische Systeme inakzeptabel. Das Backup-Konzept wurde überarbeitet: wöchentliche Vollbackups und eine neue Aufbewahrungsrichtlinie.
Das Change-Management war der schwierigste Prozess. Bisher hatten Administratoren Änderungen an Systemen nach eigenem Ermessen vorgenommen, oft ohne Dokumentation. Der neue Prozess sah vor, dass jede Änderung an produktiven Systemen einen Change-Request durchlaufen musste: Beschreibung, Risikobewertung, Genehmigung, Durchführung, Dokumentation. Die Administratoren empfanden das als bürokratische Bremse. Es brauchte zwei Teambesprechungen und eine deutliche Ansprache durch die Geschäftsführung, bis der Prozess akzeptiert und konsequent genutzt wurde.
Am Ende des Monats organisierte der ISB eine Tabletop-Übung: Ein simulierter Ransomware-Angriff, bei dem das Krisenteam die Reaktion durchspielte. Die Übung dauerte zwei Stunden und förderte drei blinde Flecken zutage: Es fehlte eine aktuelle Kontaktliste für den Notfall (die vorhandene enthielt zwei Mitarbeiter, die nicht mehr im Unternehmen waren), der alternative Kommunikationskanal war nicht eingerichtet, und niemand wusste, wo der Vertrag mit dem externen Forensik-Dienstleister lag.
Lehre aus Monat 5
Prozesse auf Papier und Prozesse in der Praxis sind zwei verschiedene Dinge. Der einzige Weg, die Lücke zu schließen, ist Testen, Testen und nochmals Testen. Jeder Test, der ein Problem aufdeckt, ist ein Gewinn, denn im Ernstfall oder im Audit wäre es eine Hauptabweichung.
Monat 6: Internes Audit und Feinschliff
Was geplant war
Internes Audit durchführen, Feststellungen beheben, Management Review abhalten und die Dokumentation für den Zertifizierungsaudit vorbereiten.
Was tatsächlich passiert ist
Für das interne Audit engagierte das Unternehmen einen externen Auditor. Das war bewusste Entscheidung: Ein interner Auditor hätte zwar die Unabhängigkeit gewährleisten müssen, aber bei einem Unternehmen dieser Größe ist es schwierig, jemanden zu finden, der nicht direkt am ISMS beteiligt ist und trotzdem genug Fachwissen hat. Der externe Auditor brachte frische Perspektive und Erfahrung aus anderen Zertifizierungsverfahren mit.
Das Audit dauerte drei Tage und ergab 4 Hauptabweichungen, 11 Nebenabweichungen und 7 Empfehlungen. Die Hauptabweichungen betrafen:
-
Fehlende Risikoneubewertung nach der Umsetzung von Maßnahmen. Das Team hatte Risiken bewertet und Maßnahmen umgesetzt, aber nicht dokumentiert, wie sich die Risikobewertung nach der Maßnahmenumsetzung verändert hatte.
-
Unvollständige Lieferantenbewertung. Drei kritische IT-Dienstleister waren noch nicht bewertet worden, darunter der Hosting-Provider, bei dem die gesamte Infrastruktur lief.
-
Lücken in der Protokollierung. Sicherheitsrelevante Ereignisse wurden auf einzelnen Systemen geloggt, aber nicht zentral zusammengeführt. Eine Korrelation von Ereignissen über Systemgrenzen hinweg war nicht möglich.
-
Kein formaler Prozess für die Überprüfung von Zugriffsrechten. Zugriffsrechte wurden bei Eintritt vergeben, aber eine regelmäßige Rezertifizierung existierte nicht.
Jede Hauptabweichung wurde mit einer konkreten Korrekturmaßnahme, einem Verantwortlichen und einer Frist versehen. Zwei der vier Abweichungen konnten innerhalb von zwei Wochen behoben werden. Die Lieferantenbewertung brauchte etwas länger, weil die Fragebögen an die Dienstleister verschickt und deren Antworten ausgewertet werden mussten. Die zentrale Protokollierung wurde als mittelfristige Maßnahme eingeplant, mit einem Zwischenschritt: manuelle wöchentliche Log-Reviews für die kritischsten Systeme.
Das Management Review fand in der letzten Woche statt. Die Geschäftsführung erhielt einen kompakten Bericht über den ISMS-Status: Risikosituation, Maßnahmenstatus, Audit-Ergebnisse, Vorfälle und Kennzahlen. Der Geschäftsführer war überrascht, wie viel das Team in sechs Monaten erreicht hatte, aber auch, wie viele offene Punkte noch auf der Liste standen.
Lehre aus Monat 6
Ein internes Audit durch eine externe Person lohnt sich, besonders beim ersten Durchlauf. Die frische Perspektive deckt blinde Flecken auf, die das Team selbst nicht sieht. Und Hauptabweichungen im internen Audit sind kein Desaster, sie sind der Normalfall. Entscheidend ist, dass du sie systematisch behebst und die Korrektur nachweisen kannst.
Die Bilanz nach sechs Monaten
Was das Projekt gekostet hat
Die ehrliche Kostenaufstellung für die SecuTech GmbH:
- Externer Berater (2 Tage/Woche, 6 Monate): 48.000 Euro
- ISMS-Tool (Jahreslizenz): 3.600 Euro
- Externer interner Auditor (3 Tage): 4.500 Euro
- Technische Maßnahmen (MFA, Logging, Backup-Erweiterung): 12.000 Euro
- Schulungen und Awareness (extern + intern): 5.000 Euro
- Interne Personalkosten (geschätzt, ISB 50 %, Team 20 %): ca. 80.000 Euro
Gesamtkosten: rund 153.000 Euro, wobei der größte Posten die internen Personalkosten waren. Das ist eine erhebliche Investition, die sich aber durch den gesicherten Großkunden und drei neue Kundenanfragen, die explizit auf die ISO-27001-Konformität Bezug nahmen, bereits im ersten Jahr amortisierte.
Was gut gelaufen ist
Die Unterstützung der Geschäftsführung war von Anfang an da und blieb konstant. Das hat dem Projekt über die schwierigen Phasen hinweggeholfen, besonders als das Change-Management auf Widerstand stieß.
Der Workshop-Ansatz bei der Risikobewertung war ein Volltreffer. Statt monatelanger Einzelbefragungen waren die Risiken in zwei Wochen bewertet, und das Team hatte ein gemeinsames Verständnis der Risikosituation.
Die frühen Quick Wins (MFA, Firewall-Bereinigung, Bildschirmsperre) erzeugten sichtbare Fortschritte und hielten die Motivation hoch, auch wenn die großen Brocken noch kamen.
Was nicht gut gelaufen ist
Der ISB in Doppelfunktion war ein Dauerproblem. Der IT-Leiter konnte dem ISMS-Projekt nie die volle Aufmerksamkeit widmen, die es brauchte. Ab Monat 3 wurde ein zweiter Mitarbeiter halbtags abgestellt, um zu unterstützen. Rückblickend hätte das von Anfang an passieren müssen.
Die Excel-Phase in Monat 2 hat das Projekt um mindestens zwei Wochen zurückgeworfen. Die Migration ins ISMS-Tool war vermeidbar gewesen, wenn die Toolentscheidung früher gefallen wäre.
Die Awareness-Schulung als einzelne Veranstaltung war ein guter Start, aber nicht nachhaltig. Bis Monat 5 hatten viele Mitarbeiter die Inhalte schon wieder vergessen. Ein kontinuierliches Programm mit monatlichen Kurzeinheiten wäre effektiver gewesen.
Was noch offen ist
Nach sechs Monaten ist das ISMS aufgebaut, aber nicht abgeschlossen. Offene Punkte, die in den kommenden Monaten bearbeitet werden müssen:
- Zentrale Logging-Lösung (SIEM) einführen
- Regelmäßige Rezertifizierung von Zugriffsrechten automatisieren
- Standort Leipzig in den Scope aufnehmen
- Awareness-Programm auf monatliche Einheiten umstellen
- Lieferantenbewertung für alle kritischen Dienstleister abschließen
- Zweite Tabletop-Übung mit erweitertem Szenario durchführen
Was du aus diesem Bericht mitnehmen kannst
Die SecuTech GmbH ist fiktiv, aber die Erfahrungen sind es nicht. Sie basieren auf typischen Mustern, die bei ISMS-Projekten im Mittelstand immer wieder auftreten. Hier die wichtigsten Erkenntnisse, destilliert auf das Wesentliche:
Starte mit dem Scope, nicht mit dem Tool. Die Versuchung ist groß, zuerst ein Tool auszuwählen und dann den Scope drumherum zu definieren. Mach es umgekehrt: Verstehe, was du absichern willst, und wähle dann das Werkzeug, das dazu passt.
Plane den ISB als echte Rolle, nicht als Nebenjob. Ein ISMS aufzubauen und gleichzeitig die IT zu leiten ist wie zwei Vollzeitjobs parallel. Mindestens 50 Prozent der Arbeitszeit müssen für das ISMS reserviert sein, in den intensiven Phasen eher 80 Prozent.
Nutze Workshops statt Einzelbefragungen. Die gemeinsame Risikobewertung im Workshop erzeugt bessere Ergebnisse in kürzerer Zeit und schafft gleichzeitig ein geteiltes Risikoverständnis im Team.
Perfektionismus ist der Feind des Fortschritts. Ein ISMS, das nach dem ersten Durchlauf zu 80 Prozent steht und gelebt wird, ist mehr wert als eines, das zu 100 Prozent dokumentiert ist, aber nur auf dem Papier existiert. Der PDCA-Zyklus ist dein Freund: Was jetzt noch nicht perfekt ist, wird im nächsten Durchlauf besser.
Teste alles, was du dokumentierst. Jeder Restore-Test, jede Tabletop-Übung, jeder Prozessdurchlauf deckt Schwächen auf, die du am Schreibtisch nicht siehst. Lieber im Test scheitern als im Ernstfall.
Rechne mit Widerstand bei organisatorischen Maßnahmen. Technische Controls sind einfach umzusetzen, weil sie niemanden fragen. Aber wenn Prozesse sich ändern, wenn plötzlich Change-Requests geschrieben oder Vorfälle dokumentiert werden müssen, betrifft das Menschen. Und Menschen brauchen Erklärung, Unterstützung und manchmal eine klare Ansage von der Geschäftsführung.
Sechs Monate sind ambitioniert, aber machbar. Die SecuTech GmbH hat es geschafft, und dein Unternehmen kann es auch. Der Schlüssel ist nicht, alles beim ersten Mal perfekt zu machen, sondern anzufangen und dranzubleiben.
Weiterführende Artikel
- ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern
- Was kostet ein ISMS? Budget, Ressourcen und versteckte Kosten
- ISB extern oder intern? Vor- und Nachteile beider Modelle
- Vom Excel-ISMS zum Tool: Migrationsleitfaden ohne Datenverlust
- Internes ISMS-Audit: Planung, Durchführung und Nachbereitung