„Das ist doch nur Papier!“ – die Bedeutung von Informationssicherheit durch wirksame Policies

„Ganz ehrlich – das mit den Policies ist doch nur Papier.“

Der Satz fällt in einem Projekt-Kickoff mit der IT-Leitung eines mittelständischen Unternehmens. Wir sitzen seit zehn Minuten zusammen, reden über Rollen, über ISMS, über erste Schritte. Dann kommt dieser Moment, fast beiläufig, aber mit Nachdruck.

Ich höre solche Aussagen oft – und ehrlich gesagt: Ich verstehe sie. In vielen Unternehmen sind Richtlinien Dokumente, die geschrieben werden, weil ein Audit das fordert. Niemand liest sie. Manchmal nicht mal die, die sie unterschreiben. Policies wirken wie ein bürokratischer Anhang an die eigentliche Arbeit – und genau deshalb werden sie oft unterschätzt.

Aber: Gerade weil sie so nüchtern daherkommen, sind sie oft entscheidend. Nicht, weil sie alles regeln – sondern weil sie klären, worauf man sich verlassen kann, wenn’s ernst wird. In diesem Artikel geht es darum, warum Policies mehr sind als Papier. Und wie sie gerade in kleinen Unternehmen Orientierung schaffen können – wenn man sie richtig angeht.

---

Warum Informationssicherheit wichtig ist – und warum Policies dabei oft unterschätzt werden

Wichtiger Hinweis:
Diese Form der kompakten Policies ist ein pragmatischer Einstieg – besonders hilfreich für Organisationen, die bislang gar keine formellen Sicherheitsregeln etabliert haben.
Sie ersetzt jedoch keine framework-konforme Dokumentation, wie sie z. B. die NIS2-Richtlinie oder ISO 27001 erfordert.

Wer unter NIS2 fällt (z. B. als mittleres oder großes Unternehmen in einem kritischen Sektor), braucht zusätzlich:

• eine vollständige, versionierte Policy-Struktur,
• Rollen- und Verantwortlichkeitszuweisungen,
• dokumentierte Freigaben und regelmäßige Reviews,
• sowie eine Integration in das übergeordnete ISMS.

Die hier beschriebenen Mini-Policies sind bewusst niedrigschwellig gedacht – als Lern-, Kommunikations- und Strukturhilfe. Sie legen den Grundstein. Aber sie sind nicht auditfest – und sollten später erweitert oder ersetzt werden.

---

Warum das ein Problem ist – und kein Einzelfall

Wenn jemand sagt, „Das ist doch nur Papier“, steckt dahinter selten Ignoranz. Meist ist es Frustration oder schlicht Pragmatismus. In vielen Unternehmen – vor allem im Mittelstand – ist Informationssicherheit keine Vollzeitaufgabe. Policies werden „halt gemacht“, weil irgendeine Norm es verlangt oder weil ein Audittermin näher rückt. Und dann geraten sie in Vergessenheit.

Das Problem: Policies wirken oft wie tote Dokumente, weil sie ohne Leben geschrieben wurden.

• Sie spiegeln nicht die Realität im Unternehmen.
  
• Sie sind in Sprache und Umfang für niemanden lesbar, der operativ arbeitet.
  
• Und sie sagen zwar, was „sollte“ – aber nicht, was tatsächlich getan wird.
  

Drei Denkfehler tauchen dabei besonders häufig auf:

1. „Wenn wir’s nicht exakt so machen, dürfen wir es nicht dokumentieren.“
   – Das Gegenteil ist richtig: Policies sollen den gewollten Zustand beschreiben – und der darf ruhig ambitionierter sein als der heutige Ist-Zustand.
   
2. „Policies sind für Auditoren, nicht für uns.“
   – Klar, Auditoren prüfen Policies. Aber eigentlich sollten sie ein Werkzeug für die Mitarbeitenden sein – nicht gegen sie.
   
3. „Wir sind zu klein für sowas.“
   – Gerade kleine Unternehmen profitieren von klaren Regeln, weil sie nicht alles über Meetings und Mailketten regeln können.
   

Und was oft übersehen wird:
Fehlende oder irrelevante Policies bedeuten Entscheidungsunsicherheit.
Wer im Ernstfall nicht weiß, woran er sich halten soll – oder wer überhaupt entscheiden darf – verliert Zeit. Und in der Informationssicherheit ist verlorene Zeit oft verlorene Sicherheit.

---

Wie ich das Thema auflöse – und was in der Praxis funktioniert

Wenn ich in Projekten mit solchen Aussagen konfrontiert werde – „Das ist doch nur Papier“ –, antworte ich oft mit einer Rückfrage:
„Was würde passieren, wenn heute jemand ein verdächtiges E-Mail-Anhängsel öffnet?“
Meist kommt dann ein kurzes Zögern. Dann eine Antwort wie: „Dann rufen wir den Admin an.“ Oder: „Dann machen wir einen Screenshot und melden’s der IT.“
Aber was genau, wer genau, und auf welcher Grundlage – das ist oft unklar.

Und genau hier beginnt der Wert einer Policy. Nicht als Kontrolle. Sondern als Orientierung.

Was eine gute Policy wirklich ist – und was nicht

Viele stellen sich unter einer Policy ein kompliziertes PDF vor, das auf dem SharePoint verstaubt. Aber das ist nicht das Ziel.
Eine gute Policy ist wie eine Landkarte mit eingezeichneten Wegen:

• Sie zeigt, wo die Grenzen verlaufen – und warum.
  
• Sie klärt, wer entscheidet – und wer nicht.
  
• Sie ist kein Regelwerk für Spezialfälle, sondern ein Dokument, das Grundsätze und Erwartungen für den sicheren Umgang mit Informationen im Arbeitsalltag definiert – also Orientierung gibt, ohne zu überfordern.
  

Wichtig ist dabei die Abgrenzung:

• Policy = Absicht und Rahmen.
  
• Prozessbeschreibung = Wie es läuft.
  
• Arbeitsanweisung = Wer genau was tut.
  In vielen Unternehmen wird das vermischt – und damit unbrauchbar.
  

Was funktioniert – ganz konkret

In der Praxis hat sich für mich eine simple Faustregel bewährt: Gerade in KMU, wo die Bedeutung von Informationssicherheit oft unterschätzt wird, helfen einfache, klar formulierte Regeln.
Lieber drei kurze Policies, die wirklich gelesen werden, als zehn perfekte, die niemand kennt.

Hier ein Beispiel aus einem KMU mit rund 120 Mitarbeitenden:

• Vor dem Projekt: Es gab keine formellen Sicherheitsdokumente.
  
• Nach dem Projekt: Drei Policies – jeweils eine Seite, je mit einem konkreten Ziel:
  
  • Policy zur Passwortverwendung – Klartext: Passwortmanager erlaubt, Mindestlänge, auf verpflichtende Rotation wird verzichtet. Stattdessen wird auf starke Passwörter in Verbindung mit Multi-Faktor-Authentifizierung (MFA) gesetzt.
    
  • Policy für Homeoffice-Arbeit – Welche Geräte, welche Verbindungen, welche Verantwortung.
    
  • Policy zur Meldekette bei Vorfällen – Was ist ein Sicherheitsvorfall, an wen melden, was vermeiden.
    

Das Entscheidende:

• Die Texte wurden gemeinsam mit den Führungskräften formuliert.
  
• Sie wurden im Intranet veröffentlicht – mit einer Kurzfassung per E-Mail.
  
• Es gab kein verpflichtendes Training – aber eine Handvoll „Was wäre wenn?“-Beispiele zur Einführung.
  

Ergebnis: Innerhalb von zwei Monaten gab es die erste echte Rückmeldung nach einem Phishing-Vorfall – nach Meldekette, mit Screenshot, in Sekunden. Vorher wäre das nie passiert.

Fünf Prinzipien für Policies, die wirken

Die Vorteile von Informationssicherheitsrichtlinien zeigen sich erst dann, wenn sie konkret im Alltag wirken – hier sind fünf Prinzipien, die genau das ermöglichen:

1. Schlank vor formal – Eine gute Policy passt auf eine Seite, wenn sie auf das Wesentliche fokussiert.
   
2. Klar vor vollständig – Lieber verständlich als vollständig, lieber gelesen als ignoriert.
   
3. Zusammen erstellt – Beteiligung sorgt für Akzeptanz.
   
4. Explizit veröffentlichen – Eine Policy ohne Sichtbarkeit ist ein Phantom.
   
5. Immer mit Fallbezug – „Was passiert, wenn…“ ist oft der beste Einstieg.

Was Du mitnehmen kannst

Policies sind nicht das Ziel – aber sie sind ein Werkzeug. Eines, das oft unterschätzt wird, gerade weil es auf den ersten Blick so unaufgeregt wirkt.

Vier Gedanken, die helfen können, neu auf Policies zu blicken:

• Policies sind kein Selbstzweck. Sie geben Orientierung, wenn’s schnell gehen muss – und sorgen dafür, dass nicht jede Entscheidung neu ausgehandelt werden muss.
  
• Policies sind Ausdruck von Haltung. Wer Verantwortung trägt, muss auch benennen können, wofür. Eine Policy macht das sichtbar – nicht perfekt, aber verlässlich.
  
• Policies schützen vor Unsicherheit. Sie gehören zur Grundlage jeder Strategie, die die Bedeutung von Informationssicherheit ernst nimmt – gerade in kleinen Organisationen. Wenn klar ist, wer was darf, was gewünscht ist und wo die Grenzen liegen, entstehen Handlungsspielräume. Nicht durch Kontrolle, sondern durch Klarheit.
  
• Policies sind nicht das Ziel – aber sie sind ein Werkzeug.
  Besonders in Unternehmen ohne dediziertes ISMS können sie Struktur und Sicherheit schaffen.
  Aber Vorsicht: Wenn gesetzliche Vorgaben wie NIS2 gelten, braucht es mehr – dann müssen Policies systematisch, formal und revisionssicher aufgebaut sein.
  

Drei Fragen an Dich

• Wäre im Ernstfall klar, wie in Deinem Unternehmen gehandelt wird – oder müsste man improvisieren?
  
• Welche Regeln sind bekannt – und welche existieren nur in Köpfen oder alten E-Mails?
  
• Welche eine Policy müsste bei Euch wirklich gelebt werden – nicht nur abgeheftet?
  

Wenn Du Dich in diesen Fragen wiederfindest: Du bist nicht allein. Fast alle Organisationen ringen mit diesen Themen. Aber es gibt Wege, Policies einfach, pragmatisch und wirksam zu gestalten. Nicht für die Ablage – sondern für den Alltag.

---

Kompakte Policy-Vorlage (als Einstieg – nicht NIS2-konform)

Policies können überfordern. Vor allem, wenn man sich zum ersten Mal damit beschäftigt. Deshalb habe ich eine kleine Mini-Vorlage erstellt, die Dir hilft, schnell und verständlich die ersten Richtlinien zu formulieren.

Sie eignet sich besonders für Teams und Verantwortliche, die Orientierung schaffen wollen – ohne gleich ein vollumfängliches ISMS aufzubauen.

Wichtig: Diese Vorlage ist nicht auditfähig und nicht ausreichend, wenn Dein Unternehmen unter die NIS2-Richtlinie fällt (Sektor S2 oder vergleichbare Kritikalität).
Sie dient als Einstieg und als Grundlage für spätere Weiterentwicklung.

Was Du mit der Mini-Policy machen kannst

• Erste Regeln intern sichtbar machen
  
• Gemeinsam im Team Verantwortlichkeiten klären
  
• Lernen, wie Policies aufgebaut sind – ohne Floskeln oder Paragraphendeutsch

Hinweis zur Haftung: Unklare, veraltete oder fehlende Policies können im Ernstfall zu Fehlentscheidungen führen – und damit auch haftungsrechtlich relevant werden. Klare Richtlinien schaffen nicht nur Orientierung, sondern auch Schutz für die Organisation und ihre Verantwortungsträger.

Was sie nicht ersetzt:

• Eine vollständige Policy-Struktur im Rahmen eines ISMS
  
• Nachweisbare Sicherheitsrichtlinien gemäß NIS2
  
• Dokumente mit Freigabevermerk, Versionierung und Auditnachweisen

---

Was Du jetzt tun kannst

Quick-Check:
Gibt es bei Euch Policies, die jeder kennt und versteht?
Sind sie kurz, klar und praxisnah formuliert?
Wird im Alltag darauf Bezug genommen oder liegen sie nur im SharePoint?

Regekwerksbezug: Dieses Thema betrifft ISO 27001 Annex A.5 (Richtlinien für Informationssicherheit) und deren gelebte Umsetzung.

Wenn Ihr Policies erstellen wollt, startet mit einer Seite zu einem Thema, das alle betrifft – und erarbeitet sie gemeinsam, kurz und verständlich.

---