ISMS

ISO 27001 A.5.1: Informationssicherheitsrichtlinien richtig aufsetzen

TL;DR
  • A.5.1 fordert eine von der Geschäftsleitung verabschiedete Informationssicherheitsleitlinie sowie themenspezifische untergeordnete Richtlinien, die den Rahmen für alle weiteren Controls setzen.
  • Die Leitlinie definiert Schutzziele, Geltungsbereich, Rollen und Verantwortlichkeiten auf strategischer Ebene. Operative Details gehören in die untergeordneten Richtlinien.
  • Für ein Unternehmen mit rund 100 Mitarbeitenden reichen typischerweise 8 bis 12 untergeordnete Richtlinien, die in einer klaren Hierarchie zur Leitlinie stehen.
  • Ein dokumentierter Review-Zyklus mit mindestens jährlicher Überprüfung ist Pflicht. Anlassbezogene Reviews nach Sicherheitsvorfällen oder organisatorischen Änderungen kommen hinzu.
  • Die beste Richtlinie nützt nichts, wenn sie niemand kennt. Kommunikation, Schulung und Bestätigung durch die Mitarbeitenden sind essenziell für die Wirksamkeit.

Die Mutter aller Controls

Wenn du den Annex A der ISO 27001:2022 aufschlägst, steht A.5.1 ganz vorn. Das ist kein Zufall. Informationssicherheitsrichtlinien sind das organisatorische Fundament, auf dem alle technischen und operativen Maßnahmen aufbauen. Ohne dokumentierte Richtlinien fehlt der Bezugsrahmen: Wer darf was? Was ist erlaubt, was verboten? Woran orientieren sich Administratoren bei der Konfiguration von Systemen, Mitarbeitende beim Umgang mit Daten und Führungskräfte bei der Freigabe von Budgets?

A.5.1 trägt den Titel „Policies for information security" und fordert im Kern zwei Dinge: eine übergeordnete Informationssicherheitsleitlinie, die von der Geschäftsleitung genehmigt und veröffentlicht wird, sowie themenspezifische untergeordnete Richtlinien, die konkrete Regelungen für einzelne Bereiche treffen. Beide müssen regelmäßig überprüft, bei Bedarf aktualisiert und an alle relevanten Personen kommuniziert werden.

Das klingt überschaubar, aber in der Praxis scheitern überraschend viele Unternehmen genau an diesem Control. Nicht weil die Anforderung so komplex wäre, sondern weil die Richtlinienlandschaft entweder zu dünn, zu aufgebläht oder schlicht nicht gepflegt ist.

Was der Standard konkret fordert

Die ISO 27002:2022, also der Implementierungsleitfaden zu Annex A, beschreibt die Anforderungen an A.5.1 detailliert. Die Kernpunkte lassen sich in vier Dimensionen zusammenfassen.

Dimension 1: Strategische Leitlinie

Die Geschäftsleitung muss eine Informationssicherheitsleitlinie verabschieden, die den strategischen Rahmen für das gesamte ISMS setzt. Diese Leitlinie enthält die Schutzziele des Unternehmens (typischerweise Vertraulichkeit, Integrität und Verfügbarkeit), den Geltungsbereich, das Bekenntnis zur kontinuierlichen Verbesserung und die grundlegenden Verantwortlichkeiten.

Wichtig: Die Leitlinie ist ein strategisches Dokument und kein technisches Handbuch. Sie beschreibt das „Was" und „Warum", nicht das „Wie". Technische Details wie Passwortlängen, Firewall-Regeln oder Backup-Intervalle gehören in die untergeordneten Richtlinien.

Dimension 2: Themenspezifische Richtlinien

Unterhalb der Leitlinie braucht es Richtlinien für spezifische Themenbereiche. Der Standard nennt als Beispiele unter anderem Zugangskontrolle, physische Sicherheit, Asset Management, Informationstransfer, sichere Konfiguration, Malware-Schutz, Backup, Kryptografie, Netzwerksicherheit, Incident Management und Lieferantenbeziehungen.

Welche Richtlinien du genau brauchst, hängt von deinem Geltungsbereich und deiner Risikolandschaft ab. Es gibt keine feste Anzahl, die der Standard vorschreibt. Was er allerdings vorschreibt, ist die Konsistenz: Alle untergeordneten Richtlinien müssen sich aus der übergeordneten Leitlinie ableiten und mit ihr im Einklang stehen.

Dimension 3: Genehmigung und Kommunikation

Richtlinien müssen durch die zuständige Leitungsebene genehmigt und an alle relevanten internen und externen Parteien kommuniziert werden. „Relevant" bedeutet, dass nicht jeder jede Richtlinie kennen muss, aber jeder Mitarbeitende muss die Leitlinie und die für seine Tätigkeit relevanten untergeordneten Richtlinien kennen und verstanden haben.

Die Kommunikation muss nachweisbar sein. Ein PDF im Intranet reicht technisch gesehen, aber ein Auditor wird fragen, wie du sicherstellst, dass die Mitarbeitenden die Richtlinien tatsächlich gelesen und verstanden haben.

Dimension 4: Regelmäßige Überprüfung

Richtlinien müssen in geplanten Intervallen und bei wesentlichen Änderungen überprüft werden. Der Standard gibt kein festes Intervall vor, aber ein jährlicher Review-Zyklus hat sich als Best Practice etabliert. Darüber hinaus müssen Richtlinien anlassbezogen überprüft werden, wenn sich die Bedrohungslage ändert, nach Sicherheitsvorfällen, bei organisatorischen Veränderungen oder bei neuen regulatorischen Anforderungen.

Die Richtlinienarchitektur für rund 100 Mitarbeitende

Ein Unternehmen mit rund 100 Mitarbeitenden braucht eine Richtlinienlandschaft, die umfassend genug ist, um den Standard zu erfüllen, aber schlank genug, um in der Praxis gelebt zu werden. Zu viele Richtlinien führen dazu, dass niemand mehr den Überblick hat. Zu wenige führen dazu, dass wichtige Bereiche ungeregelt bleiben.

Ebene 1: Die Informationssicherheitsleitlinie

Die Leitlinie ist ein Dokument von typischerweise 3 bis 5 Seiten. Sie enthält folgende Elemente:

Zweck und Geltungsbereich: Warum gibt es diese Leitlinie, und für wen gilt sie? Der Geltungsbereich sollte mit dem ISMS-Scope übereinstimmen, also alle Standorte, Geschäftsprozesse, Systeme und Personen umfassen, die unter das ISMS fallen.

Schutzziele: Die Definition der Informationssicherheitsziele auf strategischer Ebene. Neben den klassischen Schutzzielen Vertraulichkeit, Integrität und Verfügbarkeit können hier auch Authentizität, Verbindlichkeit oder Datenschutz als Ziele formuliert werden.

Verpflichtung der Geschäftsleitung: Eine explizite Aussage, dass die Geschäftsleitung die Informationssicherheit unterstützt und die notwendigen Ressourcen bereitstellt. Dieser Abschnitt ist wichtig, weil er die Grundlage für Budgetentscheidungen und die Durchsetzung von Maßnahmen bildet.

Rollen und Verantwortlichkeiten: Wer ist für Informationssicherheit verantwortlich? Typischerweise werden hier der Informationssicherheitsbeauftragte (ISB), die Geschäftsleitung, die IT-Leitung und die Mitarbeitenden genannt, jeweils mit ihren grundlegenden Pflichten.

Verweis auf untergeordnete Richtlinien: Die Leitlinie verweist auf die themenspezifischen Richtlinien und macht so die Hierarchie transparent.

Konsequenzen bei Verstößen: Ein Hinweis darauf, dass Richtlinienverstöße Konsequenzen haben. Die Details zum Disziplinarverfahren gehören in die untergeordneten Richtlinien oder in die Personalordnung, aber der Grundsatz muss in der Leitlinie verankert sein.

Versionierung und Genehmigung: Datum, Version, Genehmigungsvermerk durch die Geschäftsleitung.

Ebene 2: Themenspezifische Richtlinien

Für ein Unternehmen mit rund 100 Mitarbeitenden hat sich folgende Richtlinienstruktur als praxistauglich erwiesen:

  1. Richtlinie zur Zugangskontrolle: Regelt Berechtigungsvergabe, Passwortanforderungen, Multi-Faktor-Authentifizierung, privilegierte Zugänge und den Entzug von Berechtigungen.

  2. Richtlinie zur Nutzung von IT-Systemen (Acceptable Use Policy): Regelt, wie Mitarbeitende Firmengeräte, E-Mail, Internet und Cloud-Dienste nutzen dürfen. Enthält auch Regelungen zur privaten Nutzung.

  3. Richtlinie zum Informationstransfer: Regelt die sichere Übertragung von Informationen per E-Mail, Messenger, Dateifreigabe und physischem Transport.

  4. Richtlinie zur Klassifizierung von Informationen: Definiert Klassifizierungsstufen (z.B. öffentlich, intern, vertraulich, streng vertraulich) und den Umgang mit Informationen jeder Stufe.

  5. Richtlinie zur physischen Sicherheit: Regelt Zutrittskontrollen, Besuchermanagement, Serverraum-Sicherheit und den Schutz von Arbeitsplätzen.

  6. Richtlinie zum Umgang mit mobilen Geräten und Fernarbeit: Regelt BYOD, Homeoffice, VPN-Pflicht und den Umgang mit mobilen Datenträgern.

  7. Richtlinie zu Backup und Wiederherstellung: Regelt Backup-Intervalle, Aufbewahrungsfristen, Speicherorte und Restore-Tests.

  8. Richtlinie zur Kryptografie: Regelt zugelassene Algorithmen, Schlüssellängen, Schlüsselmanagement und Transportverschlüsselung.

  9. Incident-Management-Richtlinie: Regelt die Erkennung, Meldung, Eskalation und Nachbereitung von Sicherheitsvorfällen.

  10. Richtlinie zum Lieferantenmanagement: Regelt Sicherheitsanforderungen an Dienstleister und die Bewertung von Drittparteien.

Je nach Branche und Risikolandschaft können weitere Richtlinien hinzukommen, etwa zur Netzwerksicherheit, zum Patch Management, zur Softwareentwicklung oder zur Cloud-Nutzung. Die obige Liste deckt aber die wesentlichen Bereiche ab, die ein Auditor bei einem Unternehmen dieser Größe erwarten wird.

Ebene 3: Verfahrensanweisungen und Arbeitsanweisungen

Unterhalb der Richtlinien gibt es operative Dokumente, die konkrete Schritte beschreiben. Ein Beispiel: Die Richtlinie zur Zugangskontrolle schreibt vor, dass neue Mitarbeitende innerhalb von zwei Arbeitstagen nach Eintritt ihre Zugänge erhalten. Die Verfahrensanweisung beschreibt dann den konkreten Ablauf: Wer erstellt das Ticket, wer legt den Account an, welche Systeme werden konfiguriert, wer gibt frei?

Diese dritte Ebene ist für den Audit weniger kritisch als die Richtlinien selbst, aber sie stellt sicher, dass die Richtlinien in der Praxis umgesetzt werden.

Typische Audit-Findings bei A.5.1

Auditoren prüfen bei A.5.1 nicht nur, ob Richtlinien existieren, sondern auch, ob sie gelebt werden. Die folgenden Findings tauchen regelmäßig auf.

Finding 1: Leitlinie ohne Genehmigungsvermerk

Die Informationssicherheitsleitlinie liegt vor, ist aber nicht formal durch die Geschäftsleitung genehmigt. Es fehlt eine Unterschrift, ein Genehmigungsdatum oder ein dokumentierter Beschluss. Der Auditor wird daraus schließen, dass das Commitment der Geschäftsleitung nicht nachweisbar ist.

Vermeidung: Jede Richtlinie braucht ein Deckblatt oder einen Header mit Versionsnummer, Genehmigungsdatum und der Angabe, wer die Richtlinie genehmigt hat. Bei digitaler Genehmigung reicht ein dokumentierter Workflow mit Zeitstempel und Benutzerkennung.

Finding 2: Richtlinien seit Jahren nicht überprüft

Die Richtlinien existieren, aber das letzte Review liegt drei oder mehr Jahre zurück. In der Zwischenzeit hat das Unternehmen neue Cloud-Dienste eingeführt, die Homeoffice-Regelung geändert und einen Sicherheitsvorfall verarbeitet, ohne die Richtlinien anzupassen.

Vermeidung: Definiere einen Review-Kalender, in dem für jede Richtlinie das nächste Review-Datum steht. Ein jährlicher Zyklus ist üblich. Darüber hinaus sollte nach jedem größeren Vorfall, jeder Reorganisation und jeder neuen regulatorischen Anforderung ein anlassbezogener Review stattfinden.

Finding 3: Keine Nachweise über Kommunikation

Die Richtlinien sind erstellt und genehmigt, aber es gibt keine Nachweise, dass die Mitarbeitenden sie kennen. Kein Schulungsnachweis, keine Kenntnisnahmebestätigung, kein dokumentierter Verteilmechanismus.

Vermeidung: Nutze eine Kombination aus Kommunikationskanälen. Neue Richtlinien werden per E-Mail angekündigt, im Intranet oder ISMS-Tool veröffentlicht und in Schulungen vorgestellt. Jeder Mitarbeitende bestätigt die Kenntnisnahme, sei es per digitaler Unterschrift, per Klick im ISMS-Tool oder per dokumentierter Schulungsteilnahme.

Finding 4: Richtlinien ohne Bezug zur Leitlinie

Es existieren untergeordnete Richtlinien, die sich nicht erkennbar aus der Leitlinie ableiten. Die Leitlinie spricht von „angemessener Zugangskontrolle", aber die Zugangskontroll-Richtlinie verweist nirgends auf die Leitlinie und steht inhaltlich teilweise im Widerspruch.

Vermeidung: Jede untergeordnete Richtlinie sollte in der Einleitung auf die Leitlinie verweisen und ihren Beitrag zu den dort definierten Schutzzielen erklären. So entsteht eine sichtbare Hierarchie.

Finding 5: Richtlinien zu allgemein oder zu detailliert

Manche Unternehmen schreiben Richtlinien, die so allgemein sind, dass sie keine handlungsleitende Wirkung haben: „Passwörter müssen sicher sein." Andere versinken in technischen Details, die nach dem nächsten Systemwechsel nicht mehr stimmen: „Das Windows-Gruppenrichtlinienobjekt XY123 wird mit folgenden Parametern konfiguriert."

Vermeidung: Richtlinien formulieren Anforderungen, nicht technische Implementierungen. „Passwörter müssen mindestens 12 Zeichen lang sein und dürfen keine der 100 häufigsten Passwörter enthalten" ist eine gute Richtlinienanforderung. Wie das technisch durchgesetzt wird, gehört in die Verfahrensanweisung.

Der Review-Prozess in der Praxis

Ein funktionierender Review-Prozess besteht aus vier Schritten, die sich für ein Unternehmen mit rund 100 Mitarbeitenden pragmatisch umsetzen lassen.

Schritt 1: Review-Kalender pflegen

Erstelle eine Übersicht aller Richtlinien mit dem jeweiligen Erstellungsdatum, dem letzten Review-Datum und dem nächsten geplanten Review-Datum – in ISMS Lite wird dieser Review-Kalender automatisch gepflegt und erinnert dich rechtzeitig an fällige Überprüfungen. Bei 10 bis 12 Richtlinien kannst du den Zyklus so verteilen, dass pro Monat ein bis zwei Richtlinien zur Überprüfung anstehen. Das verhindert, dass du einmal im Jahr alle Richtlinien gleichzeitig überarbeiten musst.

Schritt 2: Verantwortlichkeiten zuweisen

Jede Richtlinie braucht einen Verantwortlichen (Owner), der den Review durchführt, und einen Genehmiger, der die überarbeitete Version freigibt. Der ISB koordiniert den Gesamtprozess, muss aber nicht jede Richtlinie selbst reviewen. Die Backup-Richtlinie kann der IT-Leiter verantworten, die Richtlinie zum Informationstransfer der Datenschutzbeauftragte.

Schritt 3: Änderungen dokumentieren

Jede Änderung an einer Richtlinie muss nachvollziehbar sein. Ein Änderungsprotokoll am Anfang der Richtlinie, das festhält, wann welche Abschnitte warum geändert wurden, reicht aus. Bei digitalen Dokumenten kann die Versionierung automatisch erfolgen.

Schritt 4: Kommunikation nach dem Review

Nach jeder wesentlichen Änderung müssen die betroffenen Mitarbeitenden informiert werden. Geringfügige redaktionelle Änderungen (Tippfehler, Formatierung) müssen nicht aktiv kommuniziert werden. Inhaltliche Änderungen schon. Wenn sich die Passwortanforderungen ändern, müssen das alle Mitarbeitenden wissen. Wenn sich die Backup-Intervalle ändern, reicht die Information an das IT-Team.

Kommunikation: Von der Richtlinie zum gelebten Standard

Die häufigste Schwachstelle bei A.5.1 ist nicht die Dokumentation, sondern die Kommunikation. Viele Unternehmen haben saubere Richtlinien in einem Ordner liegen, aber die Mitarbeitenden wissen nichts davon oder haben sie einmal bei der Einstellung unterschrieben und seitdem vergessen.

Initiale Einführung

Wenn du eine Richtlinie neu einführst, solltest du sie in einer Schulung oder zumindest in einer Informationsveranstaltung vorstellen. Erkläre nicht nur den Inhalt, sondern auch den Kontext: Warum gibt es diese Richtlinie? Was sind die Risiken, die sie adressiert? Was ändert sich für die Mitarbeitenden im Alltag?

Laufende Erinnerung

Einmal pro Jahr sollte jeder Mitarbeitende die für ihn relevanten Richtlinien erneut bestätigen. Das kann im Rahmen der jährlichen Awareness-Schulung geschehen oder als separater Prozess. Der Effekt ist zweifach: Erstens frischen die Mitarbeitenden ihr Wissen auf. Zweitens hast du einen dokumentierten Nachweis für den Auditor.

Onboarding neuer Mitarbeitender

Neue Mitarbeitende müssen die Leitlinie und die für ihre Rolle relevanten Richtlinien als Teil des Onboarding-Prozesses erhalten und bestätigen. Die Kenntnisnahme sollte vor dem ersten Arbeitstag am System erfolgen oder zumindest innerhalb der ersten Woche.

Erreichbarkeit

Die Richtlinien müssen jederzeit auffindbar sein. Ein zentrales Verzeichnis im Intranet, im ISMS-Tool oder in einem geteilten Dateisystem ist Pflicht. Wenn ein Mitarbeitender eine Richtlinie sucht und sie nicht innerhalb von zwei Minuten findet, ist die Veröffentlichung gescheitert.

Wie ISMS Lite den Nachweis unterstützt

ISMS Lite bietet für die Umsetzung von A.5.1 mehrere Funktionen, die den Aufwand erheblich reduzieren.

KI-gestützte Richtlinienerstellung: Du startest nicht mit einem leeren Blatt, sondern nutzt die lokale KI, um aus den hinterlegten A.5-Controls und deren Umsetzungsempfehlungen einen Richtlinienentwurf zu generieren. Den Entwurf passt du an deine Organisation an.

Versionierung und Genehmigung: Jede Richtlinie wird versioniert, und der Genehmigungsprozess ist dokumentiert. Du siehst auf einen Blick, welche Version aktuell ist, wer sie genehmigt hat und wann das geschehen ist.

Review-Kalender: ISMS Lite erinnert dich automatisch, wenn eine Richtlinie zur Überprüfung ansteht. Du siehst auf dem Dashboard, welche Richtlinien überfällig sind und welche demnächst zur Prüfung anstehen.

Kenntnisnahme-Workflow: Du kannst Richtlinien an Mitarbeitende oder Gruppen zuweisen und nachverfolgen, wer die Kenntnisnahme bestätigt hat. Ausstehende Bestätigungen werden eskaliert.

Audit-Trail: Alle Änderungen, Genehmigungen und Kenntnisnahmen werden protokolliert und lassen sich als Nachweis für den Auditor exportieren.

Praxisbeispiel: Richtlinienlandschaft für einen IT-Dienstleister mit 80 Mitarbeitenden

Ein mittelständischer IT-Dienstleister mit 80 Mitarbeitenden, zwei Standorten und einer ISO-27001-Zertifizierung hat seine Richtlinienlandschaft wie folgt aufgebaut:

Leitlinie: 4 Seiten, vom Geschäftsführer unterschrieben, definiert drei Schutzziele (Vertraulichkeit, Integrität, Verfügbarkeit), benennt den ISB und verweist auf 10 untergeordnete Richtlinien.

Untergeordnete Richtlinien: Zugangskontrolle, Acceptable Use, Kryptografie, physische Sicherheit, Backup, Incident Management, Lieferantenmanagement, Klassifizierung, mobile Geräte und Fernarbeit, Netzwerksicherheit.

Review-Zyklus: Jede Richtlinie wird einmal pro Jahr überprüft. Der Kalender verteilt die Reviews so, dass pro Quartal zwei bis drei Richtlinien fällig sind. Zusätzlich findet nach jedem Sicherheitsvorfall ein anlassbezogener Review der betroffenen Richtlinien statt.

Kommunikation: Neue Mitarbeitende erhalten die Leitlinie und die für ihre Rolle relevanten Richtlinien im Onboarding. Jährlich bestätigen alle Mitarbeitenden die Kenntnisnahme im Rahmen der Awareness-Schulung. Inhaltliche Änderungen werden per E-Mail kommuniziert.

Das Ergebnis: Im letzten Überwachungsaudit gab es zu A.5.1 keine Feststellungen. Der Auditor konnte anhand der Dokumentation in ISMS Lite nachvollziehen, dass alle Richtlinien aktuell, genehmigt, kommuniziert und von den Mitarbeitenden bestätigt waren.

Häufige Fehler und wie du sie vermeidest

Fehler 1: Die Richtlinie kopieren statt anpassen. Es ist verlockend, eine Vorlage aus dem Internet zu übernehmen und nur den Firmennamen einzusetzen. Ein erfahrener Auditor erkennt das sofort, weil die Richtlinie generische Formulierungen enthält, die nicht zum Unternehmen passen. Nutze Vorlagen als Ausgangspunkt, aber passe sie an deine Realität an.

Fehler 2: Zu viele Richtlinien auf einmal einführen. Wenn du 12 Richtlinien gleichzeitig veröffentlichst, werden die Mitarbeitenden überfordert. Besser ist eine gestaffelte Einführung: Erst die Leitlinie und die wichtigsten drei bis vier Richtlinien, dann schrittweise die weiteren.

Fehler 3: Richtlinien in juristischer Sprache verfassen. Richtlinien sollen von allen Mitarbeitenden verstanden werden, nicht nur von Juristen. Kurze Sätze, klare Anweisungen, konkrete Beispiele. Wenn ein Mitarbeitender nach dem Lesen nicht weiß, was er tun oder lassen soll, ist die Richtlinie wirkungslos.

Fehler 4: Kein Owner für die Richtlinie. Wenn niemand verantwortlich ist, wird die Richtlinie nicht gepflegt. Jede Richtlinie braucht einen benannten Verantwortlichen, der den Review durchführt und Änderungen anstößt.

Fehler 5: Review ohne Substanz. Manche Unternehmen ändern bei jedem Review nur das Datum und die Versionsnummer, ohne den Inhalt tatsächlich zu prüfen. Ein guter Review fragt: Stimmt der Inhalt noch? Haben sich Prozesse geändert? Gab es Vorfälle, die eine Anpassung erfordern? Gibt es neue regulatorische Anforderungen?

Von A.5.1 zu den weiteren Controls

A.5.1 ist das Fundament, aber kein Selbstzweck. Die Richtlinien, die du hier erstellst, bilden den Rahmen für alle weiteren Controls in Annex A. Die Zugangskontroll-Richtlinie setzt den Rahmen für A.5.15 bis A.5.18, die Kryptografie-Richtlinie für A.8.24, die Incident-Management-Richtlinie für A.5.24 bis A.5.28.

Wenn du die Richtlinienlandschaft sauber aufbaust, erleichterst du dir die Umsetzung und den Nachweis aller folgenden Controls erheblich. Wenn du sie nachlässig aufbaust, wirst du bei jedem weiteren Control Schwierigkeiten haben, weil der Bezugsrahmen fehlt.

Beginne daher mit A.5.1, und investiere die Zeit, die es braucht. Eine saubere Richtlinienarchitektur ist keine bürokratische Pflichtübung, sondern ein echtes Steuerungsinstrument, das dir im Alltag und im Audit hilft.

Weiterführende Artikel

Richtlinienlandschaft aufbauen

ISMS Lite enthält alle A.5-Controls mit konkreten Umsetzungsempfehlungen. Die lokale KI generiert dir daraus Richtlinienentwürfe, die du per Versionierung und integriertem Review-Workflow freigibst.

Jetzt installieren