Versicherung, Großkunde oder Audit verlangen dein IT-Sicherheitskonzept – und im Unternehmen gibt es keins. Dieser Leitfaden zeigt die Kapitelstruktur, ordnet die TOM nach Art. 32 DSGVO zu und sagt ehrlich, wie viel Arbeit dahintersteckt.
Die Anfrage kommt fast immer von außen: Die Cyberversicherung schickt einen Fragebogen. Ein Großkunde macht die Verlängerung des Rahmenvertrags von einem Sicherheitsnachweis abhängig. Die Datenschutzaufsicht fragt nach getroffenen Maßnahmen. Immer fällt derselbe Satz: „Schicken Sie uns bitte Ihr IT-Sicherheitskonzept.“
Und in den meisten mittelständischen Unternehmen gibt es genau das nicht. Es gibt eine Firewall, ein Backup, einen Virenschutz und einen Dienstleister, der sich kümmert. Was fehlt, ist das Dokument, das erklärt, warum ausgerechnet diese Maßnahmen getroffen wurden, wovor sie schützen und wer dafür geradesteht. Genau das ist ein IT-Sicherheitskonzept: keine zusätzliche Technik, sondern die nachvollziehbare Begründung deiner bestehenden Technik.
Rechtlich sitzt der Hebel in Art. 32 DSGVO: Die Vorschrift verlangt „geeignete technische und organisatorische Maßnahmen“, die zum Risiko passen – und Art. 5 Abs. 2 ergänzt die Rechenschaftspflicht. Du musst die Einhaltung nachweisen können, und nachweisen heißt dokumentieren. Fällt dein Unternehmen unter das NIS2-Umsetzungsgesetz, kommen dokumentierte Risikomanagementmaßnahmen hinzu.
Dieser Leitfaden behandelt bewusst nicht, welche Schutzmaßnahmen du brauchst – das steht im Ratgeber Cybersicherheit für KMU. Hier geht es um die Ebene darüber: wie du das Konzept strukturierst, erstellst und so pflegst, dass es zwei Jahre später noch etwas wert ist.
266,6 Mrd. €
Jährlicher Schaden durch Cyberangriffe für die deutsche Wirtschaft
Bitkom Wirtschaftsschutz 2024
81 %
der Unternehmen waren innerhalb von 12 Monaten von Datendiebstahl, Spionage oder Sabotage betroffen
Bitkom Wirtschaftsschutz 2024
10 Mio. €
oder 2 % des weltweiten Jahresumsatzes: Bußgeldrahmen bei Verstößen gegen Art. 32 DSGVO
Art. 83 Abs. 4 DSGVO
ca. 29.500
Unternehmen in Deutschland fallen unter die NIS2-Pflichten
Schätzung des BMI zum NIS2-Umsetzungsgesetz
Ein IT-Sicherheitskonzept – oft auch Informationssicherheitskonzept genannt – ist das Dokument, das vier Fragen für dein Unternehmen beantwortet: Was schützen wir? Wovor? Womit? Und wer ist dafür verantwortlich? Es beschreibt nicht nur den Zustand, sondern begründet ihn.
Der Unterschied zwischen Konzept und Maßnahmenliste ist genau diese Begründung. Eine Liste sagt: Wir haben eine Firewall, MFA und tägliche Backups. Ein Konzept sagt: Unser Warenwirtschaftssystem hat sehr hohen Verfügbarkeitsbedarf, weil ein Tagesausfall die Auslieferung stoppt; deshalb liegt die Wiederherstellungszeit bei vier Stunden, deshalb gibt es eine zweite Backup-Kopie außer Haus, deshalb wird der Restore halbjährlich getestet. Die erste Variante beantwortet keine einzige Prüferfrage, die zweite fast alle.
Genauso wichtig ist die Abgrenzung nach außen. Vier Dokumente werden in der Praxis regelmäßig als Ersatz vorgelegt – keines erfüllt den Zweck. Der häufigste Kandidat ist der Befundbericht einer IT-Auditierung: nützlich als Grundlage, aber eine Momentaufnahme und kein Regelwerk.
Regelt den Ernstfall: Wer ruft wen an, in welcher Reihenfolge fahren Systeme wieder hoch, welche Wiederanlaufzeiten gelten. Dein Sicherheitskonzept verweist darauf – ersetzen kann es das Handbuch nicht.
Blickt nur auf personenbezogene Daten: Rechtsgrundlagen, Löschfristen, Betroffenenrechte. Bei den TOM überschneidet es sich, deckt aber nie deine gesamte IT ab.
Ein Managementsystem mit Zertifizierungsanspruch, Auditzyklen und eigenem Dokumentenapparat. Für die meisten KMU überdimensioniert – ein schlankes Konzept ist der pragmatische Einstieg.
Eine Momentaufnahme mit Befundliste – der wichtigste Input für dein Konzept, aber selbst keines: Sie sagt, was ist, nicht was gelten soll und warum.
Diese Gliederung deckt ab, was Versicherer, Auditoren und Kundenfragebögen sehen wollen. Wenn du eine IT-Sicherheitskonzept-Vorlage suchst: Das ist sie – als Struktur, die du mit deiner Realität füllst, nicht als Datei, die du blind ausfüllst. Kapitel 2 setzt eine belastbare Infrastrukturanalyse voraus – ohne Inventar bleibt alles Weitere Schätzung.
Welche Standorte, Netze, Systeme und Personengruppen deckt das Konzept ab – und was ist bewusst ausgeschlossen, etwa ein Produktionsnetz oder eine Tochtergesellschaft? Dazu die übergeordneten Ziele.
Server, Arbeitsplätze, mobile Geräte, Netzwerkkomponenten, Fachanwendungen, Cloud-Dienste und Datenbestände – vollständig inventarisiert, dazu jeder externe Dienstleister mit Zugriff. Ohne Inventar ist jede Bewertung geraten.
Jedes System und jeder Datenbestand wird nach Vertraulichkeit, Integrität und Verfügbarkeit eingestuft – typischerweise in drei Stufen. Diese Einstufung entscheidet, wie viel Schutzaufwand wo gerechtfertigt ist.
Keine abstrakte Gefahrenliste, sondern durchgespielte Fälle: verschlüsselter Fileserver, kompromittiertes Cloud-Konto, Ausfall der Internetanbindung, gestohlenes Notebook. Je Szenario Eintrittswahrscheinlichkeit, Schadenshöhe und Restrisiko.
Netzwerksegmentierung, Endpoint-Schutz, Verschlüsselung, Zugriffskontrolle mit Multi-Faktor-Authentifizierung, Patch-Management, Backup und Protokollierung – jeweils mit Bezug auf das Risiko, das sie abdecken.
Passwort- und Geräterichtlinie, Regeln für Homeoffice und Fernwartung, Berechtigungsvergabe, Onboarding und Offboarding sowie die Steuerung externer Dienstleister inklusive Auftragsverarbeitung.
Wer entscheidet, wer setzt um, wer prüft – mit Namen und Vertretung, nicht mit Funktionsbezeichnungen. Dazu die Schnittstelle nach außen: Was übernimmt der IT-Dienstleister vertraglich, was bleibt bei dir?
Meldewege bei Sicherheitsvorfällen, Erreichbarkeiten außerhalb der Geschäftszeiten, Wiederherstellungszeiten je System und der Nachweis, dass Restores getestet wurden.
Wer wird wann worin geschult, wie werden neue Mitarbeitende eingewiesen, wie wird das dokumentiert? Awareness wirkt gegen Angriffe, die technisch völlig unauffällig aussehen.
In Kapitel 5 und 6 steckt der größte Schreibaufwand. Für die technische Seite lohnt es sich, auf vorhandene Detailkonzepte zu verweisen, statt alles zu wiederholen – etwa auf die Netzwerkabsicherung aus dem Ratgeber zur Firewall für Unternehmen oder auf ein bestehendes Berechtigungskonzept aus dem Bereich Zugriffsschutz. Ein Sicherheitskonzept darf auf mitgeltende Dokumente verweisen – solange klar ist, wo sie liegen und wer sie pflegt.
Und dann fehlt noch ein Kapitel, das fast jede Vorlage stiefmütterlich behandelt – und das trotzdem darüber entscheidet, ob dein Konzept in zwei Jahren noch etwas taugt.
Art. 32 DSGVO nennt keine Produkte, sondern Schutzziele. Genau diese Struktur arbeiten Prüfer, Versicherer und Auditoren ab – deshalb solltest du dein TOM-Kapitel exakt so gliedern.
| Anforderung aus Art. 32 DSGVO | Technische Maßnahmen (Beispiele) | Organisatorische Maßnahmen (Beispiele) |
|---|---|---|
| Pseudonymisierung und VerschlüsselungArt. 32 Abs. 1 lit. a | Festplattenverschlüsselung aller Endgeräte, verschlüsselte Backups, Transportverschlüsselung, VPN für Remote-Zugriffe | Richtlinie zur Datenklassifizierung, Freigabeprozess für Datenexporte, Regeln für Wechseldatenträger |
| VertraulichkeitArt. 32 Abs. 1 lit. b | Rollenbasierte Berechtigungen, Multi-Faktor-Authentifizierung, Passwortmanager, Netzwerksegmentierung | Berechtigungskonzept mit Rezertifizierung, Onboarding- und Offboarding-Prozess, Verschwiegenheitsverpflichtungen |
| IntegritätArt. 32 Abs. 1 lit. b | Protokollierung sicherheitsrelevanter Ereignisse, unveränderbare Backup-Kopien, E-Mail-Authentifizierung per SPF, DKIM, DMARC | Vier-Augen-Prinzip bei kritischen Änderungen, dokumentierter Änderungsprozess, Freigaberegeln für Zahlungen |
| VerfügbarkeitArt. 32 Abs. 1 lit. b | Redundante Internetanbindung, unterbrechungsfreie Stromversorgung, Monitoring mit Alarmierung, Patch-Management | Vereinbarte Reaktions- und Wiederherstellungszeiten, Wartungsfenster, Eskalationswege, Vertretungsregelungen |
| Belastbarkeit der SystemeArt. 32 Abs. 1 lit. b | Kapazitätsreserven bei Speicher, Rechenleistung und Bandbreite, Schutz vor Überlast, getrennte Testumgebung | Kapazitätsplanung im IT-Budget, Prüfung der Lastreserven bei jedem Systemwechsel |
| WiederherstellbarkeitArt. 32 Abs. 1 lit. c | Backup nach der 3-2-1-Regel, mindestens eine unveränderbare Kopie, definierte Wiederherstellungsziele | Schriftliche Restore-Prozedur, protokollierte Wiederherstellungstests, Verantwortliche je System |
| Regelmäßige Überprüfung und BewertungArt. 32 Abs. 1 lit. d | Wiederkehrende Schwachstellenanalyse, Auswertung von Sicherheitsmeldungen, Reporting zum Patch-Status | Jährlicher Review-Termin, Auditplan, Maßnahmenliste mit Fristen und Nachverfolgung |
Zwei Punkte werden regelmäßig unterschätzt. Erstens die Belastbarkeit: die einzige Anforderung, die nicht auf Angriffe zielt, sondern auf Lastspitzen und Wachstum – und genau deshalb fällt sie in fast jedem selbst geschriebenen Konzept unter den Tisch. Zweitens die Wiederherstellbarkeit: Sie fordert nicht nur ein Backup, sondern die belegte Fähigkeit, Daten „rasch“ wiederherzustellen – wie das architektonisch aussieht, steht in der 3-2-1-Regel der Datensicherung.
Wichtig ist außerdem die Formulierung „unter Berücksichtigung des Stands der Technik“ in Art. 32 Abs. 1: Was heute angemessen ist, kann in drei Jahren unzureichend sein. Deshalb gehört zu jeder TOM-Zeile ein Prüfdatum.
Ein Sicherheitskonzept ist kein Projekt mit Enddatum, sondern ein Dokument mit Lebenszyklus. Der Unterschied zwischen belastbarem Konzept und Schubladen-Dokument entsteht hier – nicht in den neun Kapiteln davor.
Mindestens einmal jährlich, mit Termin im Kalender und einer namentlich benannten Person. Ein Review ohne Termin findet nicht statt.
Neues Kernsystem, neuer Standort, Dienstleisterwechsel, Sicherheitsvorfall oder geänderte Rechtslage. Steht das im Konzept, muss darüber nicht diskutiert werden.
Versionsnummer, Datum, Änderungshistorie und dokumentierte Freigabe durch die Geschäftsführung. Ohne Freigabe ist das Dokument ein Entwurf.
Zu jeder Maßnahme gehört ein Beleg: Konfigurationsnachweis, Restore-Protokoll, Berechtigungsliste, Schulungsnachweis, Vertragsanlage. Prüfer glauben Anlagen, nicht Absichtserklärungen.
Ohne internen Verantwortlichen, der diesen Zyklus trägt, ist die Pflege der schwächste Punkt deines Konzepts. In vielen Häusern übernimmt der IT-Dienstleister diesen Part – bei Managed IT Services gehören Dokumentation, Patch-Nachweise und regelmäßige Berichte ohnehin zum Betrieb und lassen sich direkt als Anlage verwenden.
So läuft die Erstellung in der Praxis ab – ohne Zertifizierungsapparat, aber mit prüfbarem Ergebnis.
Alle Systeme, Datenbestände, Zugänge, Standorte und externen Dienstleister werden inventarisiert. Der unbeliebteste, aber tragende Schritt: Jede spätere Bewertung steht und fällt mit dieser Liste.
Im Workshop mit Geschäftsführung und Fachbereichen wird eingestuft, welche Systeme geschäftskritisch sind und welche Szenarien realistisch drohen. Die Fachbereiche wissen am besten, was ein Ausfall kostet.
Welche Maßnahmen existieren bereits, welche sind vorhanden aber nicht dokumentiert, wo klaffen echte Lücken? Ergebnis ist eine priorisierte Liste offener Punkte mit Aufwandsschätzung.
Die Kapitelstruktur wird gefüllt, Nachweise als Anlagen ergänzt, Verantwortlichkeiten namentlich eingetragen. Zum Schluss die formale Freigabe mit Version und Datum.
Offene Punkte werden mit Terminen und Verantwortlichen abgearbeitet, der jährliche Review steht im Kalender. Ab hier ist das Konzept ein Arbeitsdokument statt einer Abgabe.
Für ein KMU mit 10 bis 50 Arbeitsplätzen, einem Standort und überschaubarer Anwendungslandschaft liegt der reine Erstellungsaufwand erfahrungsgemäß bei 40 bis 80 Personenstunden. Der größte Block ist nicht das Schreiben, sondern Bestandsaufnahme und Abstimmung. Mit mehreren Standorten oder regulierten Fachanwendungen verdoppelt sich das schnell.
In Eigenleistung kostet das Konzept kein externes Budget, aber die Zeit genau der Personen, die ohnehin keine haben. Der Vorteil ist real: Niemand kennt eure Prozesse besser. Die typischen Risiken sind Betriebsblindheit, fehlende Vergleichsbasis – und dass das Dokument bei 70 Prozent liegen bleibt, sobald das Tagesgeschäft zurückkommt.
Mit externer Begleitung liegt die Erstellung je nach Größe und Komplexität typischerweise zwischen 3.000 und 8.000 EUR. Der interne Aufwand verschwindet nicht, er schrumpft auf Interviews, Freigaben und Zuarbeit. Bezahlt wird Struktur, Vergleichbarkeit – und die Wahrscheinlichkeit, dass das Dokument fertig wird.
Was du in beiden Varianten nicht tun solltest: eine Vorlage aus dem Netz laden, den Firmennamen einsetzen und das Ergebnis als Nachweis einreichen. Ein Muster liefert die Gliederung, nie den Inhalt.
Orientierungswerte für ein Unternehmen mit 10–50 Arbeitsplätzen an einem Standort und ohne Zertifizierungsanspruch. Der tatsächliche Aufwand hängt von Standortzahl, Fachanwendungen und Regulierungsdruck ab.
Diese Muster begegnen uns regelmäßig, wenn wir vorhandene Konzepte neuer Kunden prüfen. Jeder einzelne Punkt reicht aus, damit ein Dokument im Ernstfall nichts trägt.
Vorlage herunterladen, Firmennamen einsetzen, fertig. Das liest sich sauber – und fällt auseinander, sobald jemand nachfragt, wie viele Server ihr betreibt oder welche Fachanwendung geschäftskritisch ist. Ein Konzept ohne Bezug zur realen Infrastruktur ist ein Formblatt, kein Nachweis.
Jedes Kapitel muss mindestens einen Satz enthalten, der nur auf dein Unternehmen zutrifft: ein konkretes System, ein konkreter Standort, ein konkreter Name.
Eine Aufzählung von Schutzmaßnahmen beantwortet die entscheidende Prüferfrage nicht: Warum reicht genau das aus? Ohne den Bogen von Schutzbedarf über Risiko zur Maßnahme bleibt jede Liste eine Behauptung – und ist gegenüber Versicherung oder Großkunde nicht verteidigbar.
Jede Maßnahme mit dem Risiko verknüpfen, das sie adressiert – und benennen, welches Restrisiko ihr bewusst tragt.
„Die IT kümmert sich darum“ ist keine Zuständigkeit, sondern eine Hoffnung. Tritt der Vorfall ein, ist niemand konkret verantwortlich. Besonders kritisch ist die Schnittstelle zum externen Dienstleister: Beide Seiten nehmen an, die jeweils andere überwache das System.
Namentliche Verantwortliche mit Vertretung eintragen und die Aufgabenteilung mit dem IT-Dienstleister schriftlich abgrenzen – inklusive der Punkte, die niemand übernimmt.
Version 1.0, freigegeben vor drei Jahren, seitdem zwei Standorte dazugekommen und der Fileserver in die Cloud umgezogen. Ein Konzept, das den Ist-Zustand nicht mehr beschreibt, ist schlechter als keines: Es dokumentiert schwarz auf weiß, dass ihr eine Regel hattet und sie nicht eingehalten habt.
Review-Termin fest im Kalender, Änderungshistorie im Dokument und eine kurze Liste von Ereignissen, die eine außerplanmäßige Prüfung auslösen.
Im Konzept steht, dass Backups getestet werden. Auf Nachfrage gibt es kein Protokoll. Genau hier kippt ein Audit, ein Versicherungsfall oder ein Kundenfragebogen – nicht weil die Maßnahme fehlt, sondern weil sie nicht belegbar ist.
Ein Anlagenverzeichnis führen: Restore-Protokolle, Berechtigungslisten, Schulungsnachweise, Dienstleisterverträge, Konfigurationsstände – jeweils mit Datum.
Bei der IT-Auditierung neuer Kunden liegt oft bereits ein Sicherheitskonzept vor. Das Problem ist selten die Technik – Firewall, Backup und Endpoint-Schutz sind meist vorhanden. Das Problem ist die Lücke zwischen Dokument und Realität: Systeme, die nach der Erstellung dazugekommen sind. Verantwortliche, die das Unternehmen längst verlassen haben. Restore-Tests, die beschrieben, aber nie protokolliert wurden.
Als IT-Dienstleister aus Kaarst bei Düsseldorf betreuen wir überwiegend Unternehmen zwischen 10 und 150 Arbeitsplätzen – genau die Größe, in der ein vollständiges ISMS unrealistisch ist, ein sauberes Sicherheitskonzept aber absolut machbar. Unsere Erfahrung: Nicht das erste Erstellen ist die Hürde, sondern der zweite Durchgang ein Jahr später.
Mehr über Shoobridge erfahrenKein Gesetz verlangt wörtlich ein Dokument namens „IT-Sicherheitskonzept“. Verlangt wird das Ergebnis: Art. 32 DSGVO fordert geeignete technische und organisatorische Maßnahmen, Art. 5 Abs. 2 DSGVO verpflichtet dich, deren Einhaltung nachzuweisen. Im Anwendungsbereich des NIS2-Umsetzungsgesetzes kommen dokumentierte Risikomanagementmaßnahmen hinzu. Ein strukturiertes Konzept ist der praktikabelste Weg, diesen Nachweis zu führen.
Für ein KMU mit 10 bis 150 Arbeitsplätzen liegen sinnvolle Konzepte meist zwischen 20 und 40 Seiten inklusive Anlagenverzeichnis. Länge ist kein Qualitätsmerkmal: Ein 15-seitiges Dokument, in dem jede Maßnahme begründet und belegt ist, hält jeder Prüfung besser stand als 90 Seiten Sicherheitslehre.
Als Gliederung ja, als Inhalt nein. Ein Muster spart dir die Struktur – die Kapitel in diesem Artikel erfüllen genau diesen Zweck. Die eigentliche Arbeit sind Bestandsaufnahme und Risikobewertung, und die kann dir keine Datei abnehmen. Konzepte aus der Vorlage fallen beim ersten Rückfragen-Durchgang auf.
Die technischen und organisatorischen Maßnahmen sind ein Kapitel deines Sicherheitskonzepts, nicht sein Ersatz. Die TOM beschreiben, womit geschützt wird; das Konzept liefert den Rahmen darum: Geltungsbereich, Schutzbedarf, Risiken, Zuständigkeiten, Prüfzyklus. Wer nur eine TOM-Liste vorlegt, kann nicht begründen, warum diese Maßnahmen angemessen sind – und genau das fragt Art. 32 DSGVO ab. Welche Maßnahmen inhaltlich sinnvoll sind, steht im Ratgeber Cybersicherheit für KMU beschrieben.
Die Geschäftsführung. Sie trägt die Verantwortung für angemessene Schutzmaßnahmen und kann sie nicht an die IT delegieren – unter NIS2 haftet sie dafür sogar persönlich. Praktisch heißt das: Datum, Unterschrift und Versionsnummer auf dem Deckblatt. Ohne diese Freigabe ist das Dokument formal ein Entwurf.
Mindestens einmal jährlich – dazu anlassbezogen, sobald sich Wesentliches ändert: neues Kernsystem, neuer Standort, Dienstleisterwechsel, Sicherheitsvorfall oder neue rechtliche Anforderungen. Wichtig ist die Änderungshistorie: Sie belegt, dass das Konzept gelebt wird und nicht nur existiert.
In den allermeisten KMU nicht. Eine ISO-27001-Zertifizierung ist ein vollständiges Managementsystem mit externen Audits und laufendem Dokumentationsaufwand – sinnvoll, wenn Kunden oder Ausschreibungen sie verlangen. Für DSGVO-Nachweise, Cyberversicherungen und die meisten Kundenfragebögen genügt ein gepflegtes Sicherheitskonzept.
Wir schauen uns dein vorhandenes Konzept an oder erstellen mit dir die Struktur von Grund auf – inklusive Bestandsaufnahme und Maßnahmenplan. Erstgespräch kostenlos und unverbindlich.
