Sicherheitskonzept schreiben: Aufbau und Vorlage für den Mittelstand

Was ist ein IT-Sicherheitskonzept?

Ein IT-Sicherheitskonzept beschreibt, wie ein Unternehmen seine Informationswerte, also Daten, Systeme, Anwendungen und Prozesse, vor identifizierten Risiken schützt. Es ist das Dokument, das die Brücke schlägt zwischen der übergeordneten Informationssicherheitsrichtlinie (die sagt: „Wir schützen unsere Informationen") und den konkreten Maßnahmen (die sagen: „So machen wir das").

In der Praxis verwenden viele Unternehmen die Begriffe Sicherheitskonzept, Sicherheitsleitlinie und Sicherheitsrichtlinie synonym. Das führt zu Verwirrung, besonders im Audit. Deshalb lohnt sich eine klare Abgrenzung.

Abgrenzung: Leitlinie, Richtlinie, Konzept

Informationssicherheitsleitlinie (Policy): Das Dachdokument des ISMS. Sie formuliert die Grundsätze der Informationssicherheit, das Bekenntnis der Geschäftsführung und die übergeordneten Ziele. Die Leitlinie ist kurz (typischerweise zwei bis fünf Seiten), strategisch und richtet sich an alle Mitarbeiter. Sie ändert sich selten.

Themenspezifische Richtlinien (Policies): Konkretisierungen der Leitlinie für einzelne Themen: Passwortrichtlinie, Zugriffskontrollrichtlinie, Backup-Richtlinie. Sie definieren verbindliche Regeln für einen bestimmten Bereich und richten sich an die betroffenen Mitarbeiter oder Teams. Typischer Umfang: drei bis acht Seiten pro Richtlinie.

Sicherheitskonzept: Das operative Gesamtdokument, das den Ist-Zustand der Sicherheit beschreibt, die Risikoanalyse zusammenfasst und die ergriffenen und geplanten Maßnahmen dokumentiert. Es bezieht sich auf einen definierten Geltungsbereich (das gesamte Unternehmen oder ein Teilbereich) und ist deutlich umfangreicher als eine einzelne Richtlinie. Typischer Umfang: 25 bis 50 Seiten.

Der entscheidende Unterschied: Die Leitlinie sagt „Was wollen wir erreichen?", die Richtlinien sagen „Was sind die Regeln?", und das Sicherheitskonzept sagt „So sieht unsere Sicherheitslage aus, und das tun wir, um sie zu verbessern."

Wer braucht ein Sicherheitskonzept?

Grundsätzlich profitiert jedes Unternehmen von einem strukturierten Sicherheitskonzept. Verpflichtend wird es in mehreren Kontexten:

• ISO 27001: Die Norm fordert ein dokumentiertes ISMS, dessen Kern ein Sicherheitskonzept ist (auch wenn die Norm den Begriff so nicht verwendet).
• NIS2: Artikel 21 fordert Risikoanalysen und Sicherheitskonzepte als erste der zehn Mindestmaßnahmen.
• BSI IT-Grundschutz: Das Sicherheitskonzept ist expliziter Bestandteil der Vorgehensweise.
• DSGVO: Artikel 32 fordert technische und organisatorische Maßnahmen (TOMs), die in einem Sicherheitskonzept zusammengefasst werden können.
• Branchenspezifische Anforderungen: KRITIS, TISAX, BAIT und andere Regularien fordern vergleichbare Dokumentation.

Selbst wenn keine regulatorische Pflicht besteht, ist ein Sicherheitskonzept ein wertvolles Werkzeug. Es zwingt dazu, die eigene Sicherheitslage systematisch zu betrachten und Maßnahmen bewusst zu planen, statt nur auf Vorfälle zu reagieren.

BSI-Empfehlung: Sicherheitskonzepte im IT-Grundschutz

Das BSI beschreibt im IT-Grundschutz-Kompendium eine strukturierte Vorgehensweise zur Erstellung von Sicherheitskonzepten. Auch wenn du keine BSI-Zertifizierung anstrebst, liefert diese Vorgehensweise einen bewährten Rahmen, an dem du dich orientieren kannst.

Die BSI-Vorgehensweise in Kurzform

1. Strukturanalyse: Erfasse die relevanten Informationswerte, Geschäftsprozesse und IT-Systeme innerhalb des Geltungsbereichs.
2. Schutzbedarfsfeststellung: Bewerte für jeden Informationswert den Schutzbedarf hinsichtlich Vertraulichkeit, Integrität und Verfügbarkeit.
3. Modellierung: Ordne den Informationswerten die passenden BSI-Bausteine zu.
4. IT-Grundschutz-Check: Prüfe den Umsetzungsstatus der Sicherheitsanforderungen aus den Bausteinen.
5. Risikoanalyse: Für Assets mit erhöhtem Schutzbedarf eine ergänzende Risikoanalyse durchführen.
6. Konsolidierung und Umsetzung: Maßnahmen konsolidieren, priorisieren und umsetzen.

Für den Mittelstand ist die vollständige BSI-Vorgehensweise oft zu aufwendig. Die Konzepte und die Struktur lassen sich aber sehr gut vereinfachen und in ein pragmatisches Sicherheitskonzept überführen.

Aufbau und Gliederung: Das Sicherheitskonzept Schritt für Schritt

Die folgende Gliederung ist als Vorlage gedacht. Sie deckt alle wesentlichen Aspekte ab, die ein Auditor erwartet, und lässt sich an die Größe und Komplexität deines Unternehmens anpassen. Zu jedem Abschnitt findest du eine Erklärung, was hineingehört und warum.

1. Einleitung und Dokumentenhistorie

Was hineingehört:

• Zweck des Dokuments
• Zielgruppe (wer muss es lesen)
• Bezug zur Informationssicherheitsleitlinie
• Versionstabelle mit Datum, Version, Änderung und Freigeber
• Nächster geplanter Prüftermin

Warum: Die Einleitung stellt den Kontext her. Der Auditor sieht sofort, ob das Dokument aktuell ist und wer es freigegeben hat. Die Versionstabelle ist keine Formalität. Sie beweist, dass das Dokument regelmäßig überprüft und bei Bedarf aktualisiert wird.

Umfang: 1 bis 2 Seiten

2. Geltungsbereich (Scope)

Was hineingehört:

• Welche Organisationseinheiten, Standorte und Geschäftsprozesse sind abgedeckt
• Welche IT-Systeme, Netzwerke und Anwendungen fallen in den Scope
• Explizite Ausschlüsse mit Begründung
• Bezug zum ISMS-Scope (wenn ein ISMS vorhanden ist)

Warum: Der Geltungsbereich definiert die Grenzen des Sicherheitskonzepts. Alles innerhalb dieser Grenzen muss durch Maßnahmen geschützt werden. Alles außerhalb muss begründet ausgeschlossen sein. Ein unpräziser Scope ist eines der häufigsten Audit-Probleme.

Beispiel für den Scope eines 100-Mitarbeiter-IT-Dienstleisters:

Das Sicherheitskonzept umfasst den gesamten Geschäftsbetrieb der Muster GmbH am Hauptstandort München sowie den Nebenstandort Berlin. Eingeschlossen sind alle internen IT-Systeme, die Kundenprojekte betreffenden Entwicklungs- und Betriebsumgebungen, die Büroinfrastruktur, die Remote-Arbeitsplätze der Mitarbeiter sowie die Kommunikationsinfrastruktur. Ausgeschlossen sind die von Kunden selbst betriebenen Systeme, auf die wir keinen administrativen Zugriff haben, sowie das private IT-Equipment der Mitarbeiter, das nicht für dienstliche Zwecke genutzt wird.

Umfang: 1 bis 2 Seiten

3. Schutzziele und Informationsklassifizierung

Was hineingehört:

• Definition der drei Schutzziele: Vertraulichkeit, Integrität, Verfügbarkeit (CIA)
• Ggf. erweiterte Schutzziele: Authentizität, Zurechenbarkeit, Nicht-Abstreitbarkeit
• Klassifizierungsschema (z. B. öffentlich, intern, vertraulich, streng vertraulich)
• Beispiele für jede Klassifizierungsstufe
• Handhabungsregeln pro Stufe (Speicherung, Weitergabe, Entsorgung)

Warum: Die Schutzziele bilden das Fundament der Risikobewertung. Die Klassifizierung bestimmt, welche Schutzmaßnahmen für welche Daten angemessen sind. Ohne klare Klassifizierung fehlt die Grundlage für differenzierte Schutzmaßnahmen, und alles wird entweder überschützt (teuer und unpraktikabel) oder unterschützt (riskant).

Umfang: 2 bis 3 Seiten

4. Asset-Übersicht und Schutzbedarfsfeststellung

Was hineingehört:

• Übersicht der wesentlichen Informationswerte (kritische Geschäftsprozesse, Daten, IT-Systeme, Anwendungen, Netzwerke)
• Zuordnung eines Eigentümers (Asset Owner) zu jedem Asset
• Schutzbedarf pro Asset in den drei Dimensionen (Vertraulichkeit, Integrität, Verfügbarkeit)
• Bewertungsskala (z. B. normal / hoch / sehr hoch nach BSI-Methodik)
• Begründung für die Einstufung

Warum: Du kannst nur schützen, was du kennst. Die Asset-Übersicht ist die Landkarte deines Sicherheitskonzepts. Die Schutzbedarfsfeststellung bestimmt, wie viel Schutz jedes Asset benötigt, und verhindert sowohl Über- als auch Unterschutz.

Tipp: Du musst hier nicht jedes einzelne System auflisten. Fasse gleichartige Systeme zusammen (z. B. „Arbeitsplatzrechner der Verwaltung") und bewerte sie als Gruppe. Individuelle Bewertungen sind nur dort nötig, wo sich der Schutzbedarf einzelner Systeme deutlich vom Rest der Gruppe unterscheidet.

Umfang: 3 bis 6 Seiten (abhängig von der Anzahl der Assets)

5. Risikoanalyse

Was hineingehört:

• Beschreibung der Risikobewertungsmethodik (Eintrittswahrscheinlichkeit und Schadenshöhe, Bewertungsskala, Risikomatrix)
• Identifizierte Risiken mit Beschreibung, betroffenen Assets, Eintrittswahrscheinlichkeit, Schadenshöhe und resultierendem Risikowert
• Risikoakzeptanzkriterien: Welches Risikoniveau ist akzeptabel, was muss behandelt werden?
• Bezug zur Schutzbedarfsfeststellung: Risiken für Assets mit hohem oder sehr hohem Schutzbedarf erfordern eine vertiefte Analyse.

Warum: Die Risikoanalyse ist das Herzstück des Sicherheitskonzepts. Sie liefert die sachliche Begründung für jede Maßnahme. Ohne Risikoanalyse basieren Schutzmaßnahmen auf Bauchgefühl statt auf einer systematischen Bewertung, und im Audit fehlt die Nachvollziehbarkeit.

Darstellungsform: Eine Risikomatrix (Heatmap) mit Eintrittswahrscheinlichkeit auf einer Achse und Schadenshöhe auf der anderen ist die verbreitetste Darstellung. Ergänze sie um eine tabellarische Aufstellung der Einzelrisiken mit Risiko-ID, Beschreibung, betroffenen Assets, Bewertung und Behandlungsentscheidung.

Umfang: 4 bis 8 Seiten

6. Technische Maßnahmen

Was hineingehört:

• Netzwerksicherheit: Firewall-Architektur, Netzwerksegmentierung, IDS/IPS, VPN
• Endpunktschutz: Virenschutz, Festplattenverschlüsselung, Patch-Management, Hardening
• Serversicherheit: Betriebssystem-Härtung, Zugriffsbeschränkung, Logging
• Anwendungssicherheit: Sichere Konfiguration, Update-Management, Webanwendungsschutz
• Verschlüsselung: Transportverschlüsselung (TLS), Verschlüsselung im Ruhezustand, E-Mail-Verschlüsselung
• Authentifizierung: Passwortrichtlinie, Multi-Faktor-Authentifizierung, SSO
• Monitoring und Logging: Was wird protokolliert, wie lange, wer wertet aus
• Backup und Recovery: Backup-Strategie, Aufbewahrungsfristen, Restore-Tests

Warum: Die technischen Maßnahmen bilden den operativen Kern des Sicherheitskonzepts. Sie beschreiben, welche Schutzmechanismen konkret implementiert sind oder implementiert werden. Jede Maßnahme sollte auf mindestens ein Risiko aus der Risikoanalyse zurückführbar sein.

Wichtig: Beschreibe die Maßnahmen auf einem Abstraktionsniveau, das zum Sicherheitskonzept passt. Detaillierte technische Konfigurationen (Firewall-Regelsätze, GPO-Einstellungen) gehören in Arbeitsanweisungen oder Betriebshandbücher, nicht ins Sicherheitskonzept. Das Konzept beschreibt das „Was und Warum", nicht das „Wie im Detail".

Umfang: 5 bis 10 Seiten

7. Organisatorische Maßnahmen

Was hineingehört:

• Sicherheitsorganisation: ISB, CISO, Rollen und Verantwortlichkeiten
• Personalsicherheit: Sicherheitsüberprüfung bei Einstellung, Geheimhaltungsvereinbarungen, Onboarding/Offboarding
• Schulung und Awareness: Schulungsprogramm, Frequenz, Zielgruppen
• Dokumentenlenkung: Versionierung, Freigabe, Prüfzyklen
• Zugangskontrolle: Berechtigungskonzept, Rezertifizierung, Least Privilege
• Lieferantenmanagement: Bewertung, vertragliche Anforderungen, Monitoring
• Physische Sicherheit: Zutrittskontrole, Besucherregelungen, Clean-Desk-Policy
• Compliance: Regulatorische Anforderungen (DSGVO, NIS2, branchenspezifisch)

Warum: Technik allein schützt nicht. Die organisatorischen Maßnahmen stellen sicher, dass die technischen Maßnahmen in einem funktionierenden Rahmen betrieben werden. Ein Berechtigungskonzept nützt wenig, wenn es keinen Prozess gibt, der bei Mitarbeiteraustritt die Sperrung der Zugänge sicherstellt.

Umfang: 4 bis 8 Seiten

8. Notfallvorsorge und Incident Response

Was hineingehört:

• Verweis auf den detaillierten Incident-Response-Plan (falls als separates Dokument vorhanden)
• Zusammenfassung des Vorgehens bei Sicherheitsvorfällen: Erkennung, Bewertung, Eindämmung, Beseitigung, Wiederherstellung, Nachbereitung
• Eskalationsstufen und Kommunikationswege
• Meldepflichten (NIS2: 24h/72h/1 Monat; DSGVO: 72h bei Datenpannen)
• Verweis auf Business-Continuity-Plan und Wiederanlaufplan
• Kontaktliste: Interne Ansprechpartner, CERT, BSI, externe Dienstleister, Rechtsanwalt

Warum: Ein Sicherheitskonzept, das nicht beschreibt, was bei einem Vorfall passiert, ist unvollständig. Die Notfallvorsorge verbindet das präventive Sicherheitskonzept mit der reaktiven Vorfallsbehandlung. Im Ernstfall muss jeder wissen, was zu tun ist, ohne erst das komplette Sicherheitskonzept durchlesen zu müssen.

Umfang: 2 bis 4 Seiten (Zusammenfassung mit Verweis auf Detaildokumente)

9. Verantwortlichkeiten und Governance

Was hineingehört:

• RACI-Matrix oder vergleichbare Darstellung: Wer ist verantwortlich (Responsible), rechenschaftspflichtig (Accountable), wird konsultiert (Consulted) und informiert (Informed) für jeden Bereich des Sicherheitskonzepts
• Berichtslinien: Wer berichtet an wen, in welchem Rhythmus
• Gremien: Sicherheitsausschuss, Management-Review, ggf. Krisenstab
• Eskalationswege bei Konflikten (z. B. wenn ein Fachbereich eine Maßnahme ablehnt)

Warum: Klare Verantwortlichkeiten verhindern, dass Aufgaben in Zuständigkeitslücken fallen. Die RACI-Matrix ist ein bewährtes Mittel, um auf einen Blick zu sehen, wer für was zuständig ist, und sie ist eine der ersten Dinge, die ein Auditor anfordern wird.

Umfang: 2 bis 3 Seiten

10. Maßnahmenplan und Umsetzungsstatus

Was hineingehört:

• Tabellarische Übersicht aller Maßnahmen aus den Abschnitten 6 und 7
• Pro Maßnahme: ID, Beschreibung, zugeordnetes Risiko, Verantwortlicher, Frist, Status (umgesetzt / in Umsetzung / geplant / offen)
• Priorisierung (kritisch, hoch, mittel, niedrig)
• Budget und Ressourcenbedarf (soweit bekannt)

Warum: Der Maßnahmenplan transformiert das Sicherheitskonzept von einem beschreibenden Dokument in ein Steuerungsinstrument. Ohne ihn bleibt das Konzept Theorie. Mit ihm wird es zum Fahrplan für die Umsetzung, und der Auditor kann den Fortschritt nachvollziehen.

Tipp: Verlinke den Maßnahmenplan mit dem Risikoregister. Jede Maßnahme sollte auf ein oder mehrere Risiken verweisen, und jedes Risiko mit einer Bewertung oberhalb des akzeptablen Niveaus sollte mindestens eine zugeordnete Maßnahme haben.

Umfang: 2 bis 4 Seiten (Tabelle)

11. Prüfzyklus und Aktualisierung

Was hineingehört:

• Regelprüfung: Wie oft wird das Sicherheitskonzept überprüft (Empfehlung: mindestens jährlich)
• Anlassbezogene Prüfung: Bei welchen Ereignissen wird eine außerplanmäßige Prüfung ausgelöst (z. B. nach einem Sicherheitsvorfall, bei wesentlichen Änderungen der IT-Landschaft, bei neuen regulatorischen Anforderungen, nach einem Audit)
• Verantwortlicher für die Prüfung
• Freigabeprozess für aktualisierte Versionen

Warum: Ein veraltetes Sicherheitskonzept ist schlimmer als gar keins, weil es ein falsches Sicherheitsgefühl vermittelt. Der definierte Prüfzyklus stellt sicher, dass das Dokument mit der Realität Schritt hält.

Umfang: 1 Seite

Beispielgliederung auf einen Blick

Hier die komplette Gliederung in Kurzform als Referenz:

IT-Sicherheitskonzept der Muster GmbH

1.  Einleitung und Dokumentenhistorie
    1.1 Zweck und Zielgruppe
    1.2 Bezug zur Informationssicherheitsleitlinie
    1.3 Versionstabelle

2.  Geltungsbereich
    2.1 Eingeschlossene Bereiche
    2.2 Ausschlüsse und Begründungen

3.  Schutzziele und Informationsklassifizierung
    3.1 Schutzziele (CIA)
    3.2 Klassifizierungsschema
    3.3 Handhabungsregeln

4.  Asset-Übersicht und Schutzbedarfsfeststellung
    4.1 Kritische Geschäftsprozesse
    4.2 Informationswerte und IT-Systeme
    4.3 Schutzbedarfsfeststellung

5.  Risikoanalyse
    5.1 Risikobewertungsmethodik
    5.2 Identifizierte Risiken
    5.3 Risikomatrix
    5.4 Risikoakzeptanzkriterien

6.  Technische Maßnahmen
    6.1 Netzwerksicherheit
    6.2 Endpunktschutz
    6.3 Serversicherheit
    6.4 Verschlüsselung
    6.5 Authentifizierung und Zugriffskontrolle
    6.6 Monitoring und Logging
    6.7 Backup und Recovery

7.  Organisatorische Maßnahmen
    7.1 Sicherheitsorganisation
    7.2 Personalsicherheit
    7.3 Schulung und Awareness
    7.4 Lieferantenmanagement
    7.5 Physische Sicherheit
    7.6 Compliance

8.  Notfallvorsorge und Incident Response
    8.1 Vorgehen bei Sicherheitsvorfällen
    8.2 Eskalation und Kommunikation
    8.3 Meldepflichten
    8.4 Business Continuity (Verweis)

9.  Verantwortlichkeiten und Governance
    9.1 RACI-Matrix
    9.2 Berichtslinien und Gremien
    9.3 Eskalationswege

10. Maßnahmenplan und Umsetzungsstatus

11. Prüfzyklus und Aktualisierung
    11.1 Regelprüfung
    11.2 Anlassbezogene Prüfung
    11.3 Freigabeprozess

Anhänge:
A.  Glossar
B.  Referenzierte Dokumente
C.  Kontaktliste Notfall

Umfang und Detailtiefe: Was ist angemessen?

Die häufigste Frage bei der Erstellung eines Sicherheitskonzepts lautet: Wie detailliert muss es sein? Die Antwort hängt von mehreren Faktoren ab.

Unternehmensgröße als Orientierung

Diese Zahlen sind Richtwerte. Ein 100-Mitarbeiter-Unternehmen mit einfacher IT-Landschaft (ein Standort, Standard-Office-IT, keine Eigenentwicklung) kommt mit 25 Seiten aus. Dasselbe Unternehmen mit einer komplexen IT-Landschaft (mehrere Standorte, Cloud und On-Premises, eigene Softwareentwicklung, internationale Kunden) braucht eher 45 bis 50 Seiten.

Häufige Fehler bei der Detailtiefe

Zu wenig Detail: Das Sicherheitskonzept listet nur Überschriften auf, ohne substanziellen Inhalt. „Netzwerksicherheit wird durch eine Firewall gewährleistet" reicht nicht. Welche Firewall-Architektur? Welche Segmentierung? Welche Regelwerks-Philosophie? Der Auditor will sehen, dass du dir Gedanken gemacht hast.

Zu viel Detail: Das Sicherheitskonzept enthält Firewall-Regeln, IP-Adressen, Konfigurationsparameter. Das macht es zum Sicherheitsrisiko (wenn es in falsche Hände gerät) und zum Pflegealbtraum (bei jeder Konfigurationsänderung muss das Konzept aktualisiert werden). Technische Details gehören in Betriebshandbücher und Arbeitsanweisungen, nicht ins Sicherheitskonzept.

Der richtige Mittelweg: Beschreibe im Sicherheitskonzept das Prinzip und die Architektur, nicht die Konfiguration. Statt „Firewall-Regel: permit tcp 10.0.1.0/24 10.0.2.0/24 eq 443" schreibst du: „Das Produktionsnetz ist vom Office-Netz durch eine Firewall getrennt. Der Datenverkehr zwischen den Zonen ist auf die für den Geschäftsbetrieb notwendigen Protokolle und Ports beschränkt. Die Regeln werden quartalsweise überprüft."

Modularer Aufbau

Bei wachsender Komplexität kann es sinnvoll sein, das Sicherheitskonzept modular aufzubauen. Das übergeordnete Sicherheitskonzept enthält die Abschnitte 1 bis 5 sowie 8 bis 11 vollständig. Die Abschnitte 6 und 7 werden in Teilkonzepte ausgelagert:

• Teilkonzept Netzwerksicherheit
• Teilkonzept Cloud-Sicherheit
• Teilkonzept Standort Berlin (physische Sicherheit)
• Teilkonzept Softwareentwicklung

Jedes Teilkonzept referenziert das übergeordnete Sicherheitskonzept und wird eigenständig versioniert und freigegeben. Der Vorteil: Änderungen in einem Bereich erfordern nicht die Aktualisierung des Gesamtdokuments. Der Nachteil: Es entsteht eine Dokumentenhierarchie, die gepflegt werden muss.

Aktualisierung: Wann und wie

Ein Sicherheitskonzept ist kein statisches Dokument. Es muss mit der Entwicklung des Unternehmens, der Bedrohungslage und der IT-Landschaft Schritt halten.

Regelmäßige Überprüfung

Plane mindestens eine jährliche Überprüfung des gesamten Sicherheitskonzepts. Der beste Zeitpunkt ist nach dem Management-Review, weil dann die Erkenntnisse aus dem Review direkt einfließen können. Die Überprüfung muss nicht zwangsläufig zu Änderungen führen. Es reicht, wenn du dokumentierst, dass die Überprüfung stattgefunden hat und das Konzept weiterhin aktuell ist.

Anlassbezogene Aktualisierung

Folgende Ereignisse sollten eine außerplanmäßige Überprüfung und ggf. Aktualisierung auslösen:

• Sicherheitsvorfall: Jeder relevante Vorfall kann Schwächen im Sicherheitskonzept offenlegen, die behoben werden müssen.
• Wesentliche IT-Änderungen: Migration in die Cloud, Einführung neuer Geschäftsanwendungen, Standortwechsel, Übernahme eines anderen Unternehmens.
• Neue regulatorische Anforderungen: Änderungen an NIS2, DSGVO oder branchenspezifischen Vorschriften.
• Audit-Feststellungen: Wenn ein internes oder externes Audit Abweichungen identifiziert, die das Sicherheitskonzept betreffen.
• Organisatorische Veränderungen: Umstrukturierungen, neue Geschäftsbereiche, Fusion oder Ausgründung.

Änderungsmanagement

Änderungen am Sicherheitskonzept folgen dem Dokumentenlenkungsverfahren:

1. Entwurf der Änderung durch den ISB oder den zuständigen Fachverantwortlichen
2. Review durch betroffene Stakeholder
3. Freigabe durch den ISB (bei wesentlichen Änderungen durch die Geschäftsführung)
4. Aktualisierung der Versionstabelle
5. Kommunikation der Änderungen an die betroffenen Mitarbeiter
6. Archivierung der Vorgängerversion

Von der Vorlage zum fertigen Konzept

Du hast jetzt eine vollständige Gliederung und weißt, was in jeden Abschnitt gehört. Der nächste Schritt ist die tatsächliche Erstellung. Hier ein pragmatischer Ansatz, der sich im Mittelstand bewährt hat.

Schritt 1: Scope und Assets (Woche 1 bis 2)

Beginne mit dem Geltungsbereich und der Asset-Übersicht. Beide Abschnitte legen das Fundament. Sprich mit den Fachbereichen, um ein realistisches Bild der IT-Landschaft und der Geschäftsprozesse zu bekommen. Eine erste Asset-Übersicht muss nicht perfekt sein, sie muss vollständig genug sein, um die Risikoanalyse zu unterstützen.

Schritt 2: Risikoanalyse (Woche 3 bis 5)

Führe die Risikobewertung durch, basierend auf den identifizierten Assets und deren Schutzbedarf. Binde die IT-Abteilung und die Fachbereiche ein. Risiken, die nur aus IT-Perspektive bewertet werden, verfehlen regelmäßig die geschäftliche Relevanz.

Schritt 3: Maßnahmen dokumentieren (Woche 5 bis 8)

Dokumentiere die bestehenden technischen und organisatorischen Maßnahmen. Identifiziere die Lücken zwischen dem Ist-Zustand und dem Soll-Zustand (abgeleitet aus der Risikoanalyse). In ISMS Lite kannst du Maßnahmen direkt mit den identifizierten Risiken verknüpfen und den Umsetzungsstatus pro Control nachverfolgen. Erstelle den Maßnahmenplan für die Lücken.

Schritt 4: Zusammenführung und Review (Woche 8 bis 10)

Führe alle Abschnitte zusammen, ergänze die Rahmenkapitel (Einleitung, Schutzziele, Verantwortlichkeiten, Prüfzyklus) und lasse das Gesamtdokument von den relevanten Stakeholdern reviewen.

Schritt 5: Freigabe und Kommunikation (Woche 10 bis 12)

Lasse das Sicherheitskonzept von der Geschäftsführung freigeben und kommuniziere es an die betroffenen Personen. Das Sicherheitskonzept selbst muss nicht allen Mitarbeitern bekannt gemacht werden, wohl aber die daraus abgeleiteten Richtlinien und Verhaltensregeln.

Zwölf Wochen für ein erstes Sicherheitskonzept sind realistisch, wenn du dedizierte Zeit dafür aufwenden kannst. Wenn das Sicherheitskonzept parallel zum Tagesgeschäft entsteht, plane eher 16 bis 20 Wochen. Das erste Konzept ist immer das aufwendigste. Die jährliche Aktualisierung geht deutlich schneller, weil du nur noch die Änderungen einarbeiten musst.

Das Sicherheitskonzept als lebendiges Dokument

Ein Sicherheitskonzept, das in einer Schublade liegt und einmal jährlich pflichtbewusst hervorgeholt wird, verfehlt seinen Zweck. Es sollte das Referenzdokument sein, auf das bei jeder sicherheitsrelevanten Entscheidung zurückgegriffen wird. Wenn ein neues System eingeführt wird, schaut man ins Sicherheitskonzept: Passt die Maßnahme zum Schutzbedarf? Wenn ein Vorfall eintritt, schaut man ins Sicherheitskonzept: War dieses Risiko identifiziert? Waren die Maßnahmen angemessen?

Halte das Konzept deshalb so schlank und praxisnah wie möglich. Jede Seite, die keinen Mehrwert liefert, ist eine Seite, die niemand liest. Und ein Dokument, das niemand liest, kann auch niemanden schützen.

Weiterführende Artikel

• Risikobewertung im ISMS: Methodik, Matrix und Praxisbeispiel
• Schutzbedarfsfeststellung: Vertraulichkeit, Integrität und Verfügbarkeit bewerten
• ISMS-Dokumentation: Welche Dokumente du wirklich brauchst (und welche nicht)
• ISMS aufbauen: Der komplette Leitfaden für Unternehmen mit 50 bis 500 Mitarbeitern
• NIS2-Checkliste: Alle Anforderungen auf einen Blick

Starte mit dem Geltungsbereich und der Asset-Übersicht. Sobald du weißt, was du schützen musst, folgen Risikoanalyse und Maßnahmen fast von selbst. Das Sicherheitskonzept wächst mit deinem Unternehmen und deinem ISMS. Es muss beim ersten Durchlauf nicht perfekt sein, aber es muss existieren, aktuell sein und tatsächlich genutzt werden.