ISO 27001 Richtlinien: Welche Richtlinien Sie brauchen und wie Sie sie schreiben

Richtlinien sind das Rueckgrat jedes ISO 27001 Informationssicherheits-Managementsystems (ISMS). Sie uebersetzen die Sicherheitsabsichten des Managements in dokumentierte Verpflichtungen, die das Verhalten der Mitarbeiter leiten, Kontrollziele definieren und Auditoren etwas Konkretes geben, gegen das sie pruefen koennen. Ohne gut strukturierte, durchsetzbare Richtlinien existiert Ihr ISMS nur in der Theorie.

Viele SaaS-Unternehmen gehen ISO 27001 Richtlinien falsch an. Sie laden generische Vorlagen herunter, ersetzen den Firmennamen und gehen davon aus, dass sie fertig sind. Das schafft zwei Probleme. Erstens spiegeln die Richtlinien nicht wider, wie die Organisation tatsaechlich arbeitet, was bedeutet, dass Mitarbeiter sie ignorieren. Zweitens erkennen Zertifizierungsauditoren die Diskrepanz sofort — sie haben die gleichen Vorlagen hundertfach gesehen und wissen, wenn eine Richtlinie nicht fuer die Organisation geschrieben wurde, die sie vorlegt.

Dieser Leitfaden behandelt die Anforderungen an dokumentierte Information in ISO 27001, jede verbindliche und empfohlene Richtlinie, wie Sie Richtlinien strukturieren und schreiben, die fuer SaaS-Unternehmen funktionieren, und wie Sie den Genehmigungs-, Kommunikations- und Ueberpruefungslebenszyklus verwalten, den der Standard verlangt.

Was ISO 27001 ueber dokumentierte Information sagt

ISO 27001 verwendet den Begriff “dokumentierte Information” anstelle von “Dokumente” oder “Aufzeichnungen”. Dies geschieht bewusst — der Standard schreibt keine bestimmten Dokumentformate, Namenskonventionen oder Strukturen vor. Er verlangt, dass bestimmte Informationen dokumentiert, gepflegt und kontrolliert werden, aber wie Sie diese Informationen organisieren, liegt bei Ihnen.

Klausel 7.5 legt die uebergreifenden Anforderungen an dokumentierte Information fest. Sie besagt, dass Ihr ISMS dokumentierte Information umfassen muss, die vom Standard selbst verlangt wird, plus alle zusaetzliche dokumentierte Information, die Ihre Organisation als notwendig fuer die ISMS-Wirksamkeit erachtet.

Was der Standard ausdruecklich verlangt

Die folgende dokumentierte Information wird direkt durch ISO 27001:2022 Klauseln vorgeschrieben:

• ISMS-Anwendungsbereich (Klausel 4.3) — Die Grenzen und Anwendbarkeit Ihres ISMS
• Informationssicherheitsrichtlinie (Klausel 5.2) — Die uebergeordnete Richtlinie, die die Managementausrichtung ausdrueckt
• Risikobewertungsprozess (Klausel 6.1.2) — Wie Sie Informationssicherheitsrisiken identifizieren, analysieren und bewerten
• Risikobehandlungsprozess (Klausel 6.1.3) — Wie Sie Kontrollen zur Behandlung identifizierter Risiken auswaehlen und implementieren
• Informationssicherheitsziele (Klausel 6.2) — Messbare Ziele fuer Ihr Sicherheitsprogramm
• Kompetenznachweise (Klausel 7.2) — Nachweis, dass Personen, die sicherheitsrelevante Arbeit verrichten, kompetent sind
• Operative Planung und Steuerung (Klausel 8.1) — Dokumentation der Prozesse, die zur Erfuellung der Sicherheitsanforderungen benoetigt werden
• Ergebnisse der Risikobewertung (Klausel 8.2) — Output aus abgeschlossenen Risikobewertungen
• Ergebnisse der Risikobehandlung (Klausel 8.3) — Output aus Risikobehandlungsaktivitaeten
• Ergebnisse der Ueberwachung und Messung (Klausel 9.1) — Nachweise der Leistungsbewertung
• Internes Auditprogramm und -ergebnisse (Klausel 9.2) — Auditplaene, Kriterien, Umfang und Ergebnisse
• Ergebnisse des Management-Reviews (Klausel 9.3) — Output aus Management-Review-Sitzungen
• Nichtkonformitaeten und Korrekturmassnahmen (Klausel 10.1) — Aufzeichnungen gefundener Probleme und wie sie adressiert wurden
• Erklaerung zur Anwendbarkeit (Klausel 6.1.3 d) — Auflistung aller Annex A Kontrollen mit Begruendung fuer Einbeziehung oder Ausschluss

Dies ist das Mindestset. Die meisten Organisationen benoetigen deutlich mehr dokumentierte Information, um nachzuweisen, dass ihr ISMS wirksam operiert.

Die Erklaerung zur Anwendbarkeit als Richtlinienlandkarte

Die Erklaerung zur Anwendbarkeit (SoA) verdient besondere Aufmerksamkeit, da sie als Bruecke zwischen Ihren Risikobehandlungsentscheidungen und den Richtlinien fungiert, die diese Entscheidungen umsetzen. Fuer jede Annex A Kontrolle, die Sie als anwendbar deklarieren, benoetigen Sie dokumentierte Information, die beschreibt, wie diese Kontrolle implementiert wird. In der Praxis bedeutet dies, dass Ihre SoA Ihre Richtlinienliste bestimmt — jede anwendbare Kontrolle sollte auf eine Richtlinie, ein Verfahren oder einen Standard zurueckfuehrbar sein, der sie regelt.

Verbindliche Richtlinien

ISO 27001 stellt keine nummerierte Liste erforderlicher Richtliniendokumente bereit. Stattdessen erfordern bestimmte Klauseln und Annex A Kontrollen implizit oder explizit Richtlinien-Dokumentation. Die folgenden Richtlinien gelten als verbindlich fuer die Zertifizierung.

1. Informationssicherheitsrichtlinie

Klauselreferenz: 5.2, A.5.1

Dies ist das uebergeordnete Dokument Ihres ISMS. Es etabliert die Verpflichtung der Organisation zur Informationssicherheit, gibt die Richtung fuer alle untergeordneten Richtlinien vor und wird von der obersten Leitung unterzeichnet.

Was sie enthalten muss:

• Zweck und Anwendungsbereich des ISMS
• Eine Verpflichtung zur Erfuellung geltender Sicherheitsanforderungen
• Eine Verpflichtung zur kontinuierlichen Verbesserung des ISMS
• Einen Rahmen fuer die Festlegung von Informationssicherheitszielen
• Zuweisung der Gesamtverantwortung fuer Informationssicherheit

Was sie nicht enthalten sollte: Detaillierte operative Verfahren, spezifische technische Konfigurationen oder Kontrollimplementierungen. Die Informationssicherheitsrichtlinie ist ein strategisches Dokument. Halten Sie sie auf einem ausreichend hohen Niveau, damit sie nicht bei jeder Aenderung einer technischen Kontrolle angepasst werden muss.

SaaS-Beispiel: Ihre Informationssicherheitsrichtlinie erklaert, dass die Organisation sich dem Schutz von Kundendaten verpflichtet, die ueber ihre Cloud-Plattform verarbeitet werden, dass Sicherheitsziele vierteljaehrlich vom Fuehrungsteam ueberprueft werden und dass der CTO fuer das Informationssicherheitsprogramm verantwortlich ist. Sie verweist auf die gesamte Suite untergeordneter Richtlinien (Zugriffskontrolle, Vorfallreaktion usw.), ohne deren Inhalt zu duplizieren.

Haeufige Audit-Feststellung: Die Richtlinie existiert, wurde aber seit der ersten Erstellung nie ueberprueft oder aktualisiert. Auditoren pruefen Ueberpruefungsdaten. Wenn Ihre Richtlinie drei Jahre alt ist und Ihr Unternehmen sich erheblich veraendert hat, werden sie es beanstanden.

2. Risikobewertungs- und Behandlungsmethodik

Klauselreferenz: 6.1.2, 6.1.3

Diese dokumentierte Methodik definiert, wie Ihre Organisation Informationssicherheitsrisiken identifiziert, analysiert, bewertet und behandelt. Es ist nicht das Risikoregister selbst — es ist die Prozessbeschreibung, die sicherstellt, dass Risikobewertungen konsistent und wiederholbar sind.

Was sie enthalten muss:

• Risikoidentifikationskriterien (was ein Risiko darstellt, asset-basierter vs. szenariobasierter Ansatz)
• Risikoanalysemethode (qualitativ, quantitativ oder semi-quantitativ)
• Eintrittswahrscheinlichkeits- und Auswirkungsskalen mit klaren Definitionen fuer jede Stufe
• Risikobewertungskriterien (wie Sie bestimmen, welche Risiken akzeptabel sind und welche eine Behandlung erfordern)
• Risikoakzeptanzkriterien und wer die Befugnis hat, Restrisiken zu akzeptieren
• Risikobehandlungsoptionen (mindern, uebertragen, akzeptieren, vermeiden) und Auswahlkriterien

Fuer eine detaillierte Anleitung zum Risikobewertungsprozess lesen Sie unseren ISO 27001 Risikobewertungs-Leitfaden.

SaaS-Beispiel: Sie verwenden eine 5x5 qualitative Risikomatrix. Die Eintrittswahrscheinlichkeit wird von Selten (1) bis Fast sicher (5) bewertet, basierend auf historischen Daten und Bedrohungsinformationen. Die Auswirkung wird von Vernachlaessigbar (1) bis Kritisch (5) bewertet, basierend auf finanziellen, operativen, reputationsbezogenen und regulatorischen Konsequenzen. Risiken mit einer Bewertung von 15 oder hoeher erfordern eine Behandlung. Risiken mit einer Bewertung von 9-14 erfordern eine dokumentierte Begruendung bei Akzeptanz. Der CTO hat die Befugnis, Risiken mit einer Bewertung von 14 oder weniger zu akzeptieren; Risiken mit einer Bewertung von 15 oder hoeher erfordern die Genehmigung des CEO.

3. Erklaerung zur Anwendbarkeit

Klauselreferenz: 6.1.3 d

Die Erklaerung zur Anwendbarkeit listet alle 93 Annex A Kontrollen aus ISO 27001:2022 auf mit einer Feststellung, ob jede anwendbar ist, der Begruendung fuer Einbeziehung oder Ausschluss und einem Verweis darauf, wie jede anwendbare Kontrolle implementiert wird.

Die SoA ist eines der wichtigsten Dokumente in Ihrem ISMS. Auditoren nutzen sie als ihre Landkarte — sie waehlen Kontrollen aus der SoA aus und testen, ob diese Kontrollen implementiert sind und wie beschrieben operieren.

Haeufige Audit-Feststellung: Die SoA sagt, eine Kontrolle sei implementiert, aber die referenzierte Richtlinie oder das Verfahren existiert nicht, oder es existiert, wird aber nicht befolgt. Jede Behauptung in Ihrer SoA muss ueberpruefbar sein.

4. Risikobehandlungsplan

Klauselreferenz: 6.1.3, 8.3

Der Risikobehandlungsplan dokumentiert die konkreten Massnahmen, die Sie ergreifen, um Risiken zu adressieren, die Ihre Akzeptanzkriterien ueberschreiten. Fuer jedes behandlungsbeduerftige Risiko identifiziert der Plan die zu implementierenden Kontrollen, die verantwortliche Person, den Zeitplan und die erforderlichen Ressourcen.

Was er enthalten muss:

• Identifizierte Risiken, die eine Behandlung erfordern (verknuepft mit dem Risikoregister)
• Gewaehlte Behandlungsoption fuer jedes Risiko
• Anzuwendende Kontrollen (mit Verweis auf Annex A oder andere Quellen)
• Implementierungseigentuemer und Zeitplan
• Erwartetes Restrisiko nach der Behandlung
• Statusverfolgung

Empfohlene Richtlinien fuer SaaS-Unternehmen

Ueber die verbindliche dokumentierte Information hinaus benoetigen SaaS-Unternehmen, die eine ISO 27001 Zertifizierung anstreben, zusaetzliche Richtlinien, um Annex A Kontrollen zu erfuellen und ein ausgereiftes ISMS nachzuweisen. Der genaue Satz haengt von Ihrer SoA ab, aber die folgenden Richtlinien werden von praktisch jedem Zertifizierungsauditor erwartet.

5. Zugriffskontrollrichtlinie

Annex A Referenz: A.5.15 (Zugriffskontrolle), A.5.16 (Identitaetsmanagement), A.5.17 (Authentifizierungsinformationen), A.5.18 (Zugriffsrechte), A.8.2 (Privilegierte Zugriffsrechte), A.8.3 (Einschraenkung des Informationszugriffs), A.8.5 (Sichere Authentifizierung)

Zugriffskontrolle ist einer der am intensivsten geprueften Bereiche in jedem ISO 27001 Audit. Ihre Zugriffskontrollrichtlinie definiert, wie die Organisation Benutzeridentitaeten, Authentifizierung, Autorisierung und den gesamten Lebenszyklus der Zugriffsrechte verwaltet. Fuer eine vertiefte Betrachtung der Implementierung lesen Sie unseren ISO 27001 Zugriffskontroll-Leitfaden.

Was sie abdeckt:

• Benutzerregistrierungs- und -abmeldungsprozess
• Rollenbasierte Zugriffskontrolle (RBAC) oder attributbasierte Zugriffskontrolle (ABAC) Modell
• Prinzip der geringsten Rechte
• Multi-Faktor-Authentifizierung (MFA) Anforderungen
• Privilegiertes Zugriffsmanagement (PAM)
• Dienstkonto- und API-Schluessel-Governance
• Haeufigkeit und Prozess periodischer Zugangspruefungen
• Deprovisionierungszeitrahmen bei Rollenwechsel oder Kuendigung

SaaS-Beispiel: Alle Produktionsumgebungszugriffe erfordern MFA. Dienstkonten werden ueber Terraform mit zeitlich begrenzten Anmeldeinformationen provisioniert. Zugangspruefungen werden vierteljaehrlich mit automatisierten Exporten aus Ihrem Identitaetsanbieter durchgefuehrt. Die Deprovisionierung muss innerhalb von 24 Stunden nach Kuendigungsbenachrichtigung erfolgen.

6. Asset-Management-Richtlinie

Annex A Referenz: A.5.9 (Inventar von Informationen und zugehoerigen Werten), A.5.10 (Akzeptable Nutzung), A.5.11 (Rueckgabe von Werten), A.5.12 (Klassifizierung von Informationen), A.5.13 (Kennzeichnung von Informationen)

Diese Richtlinie regelt die Identifizierung, Klassifizierung, Kennzeichnung und akzeptable Nutzung von Informationswerten. Fuer SaaS-Unternehmen umfassen “Werte” Cloud-Infrastruktur, Code-Repositories, Datenbanken, SaaS-Tools und geistiges Eigentum.

Was sie abdeckt:

• Anforderungen an das Asset-Inventar und Pflegehaeufigkeit
• Informationsklassifizierungsschema (z.B. Oeffentlich, Intern, Vertraulich, Eingeschraenkt)
• Kennzeichnungsregeln fuer jede Klassifizierungsstufe
• Regeln zur akzeptablen Nutzung von Organisationswerten (einschliesslich BYOD)
• Verfahren zur Asset-Rueckgabe bei Mitarbeiteraustritt

SaaS-Beispiel: Sie klassifizieren Daten in vier Stufen. Kundenproduktionsdaten sind Eingeschraenkt. Interne Geschaeftsdokumente sind Vertraulich. Firmenblogbeitraege sind Oeffentlich. Jede Klassifizierungsstufe wird auf spezifische Handhabungsanforderungen abgebildet — Eingeschraenkte Daten muessen im Ruhezustand und bei der Uebertragung verschluesselt sein, der Zugriff erfordert die Genehmigung des Dateneigentuemers, und sie duerfen nicht ausserhalb genehmigter Produktionsumgebungen gespeichert werden.

7. Personalsicherheitsrichtlinie

Annex A Referenz: A.6.1 (Ueberpruefung), A.6.2 (Beschaeftigungsbedingungen), A.6.3 (Informationssicherheitsbewusstsein), A.6.4 (Disziplinarverfahren), A.6.5 (Verantwortlichkeiten nach Beendigung)

Diese Richtlinie deckt die Sicherheitsaspekte des gesamten Mitarbeiterlebenszyklus ab — von der Ueberpruefung vor Einstellung ueber das Onboarding, die laufende Beschaeftigung bis zur Kuendigung.

Was sie abdeckt:

• Anforderungen an Hintergrundpruefungen (Umfang und Haeufigkeit)
• Vertraulichkeits- und Sicherheitsverpflichtungen in Arbeitsvertraegen
• Anforderungen an Sicherheitsbewusstseins-Schulungen (initial und wiederkehrend)
• Erwartungen an akzeptables Verhalten und Disziplinarverfahren bei Verstoessen
• Kuendigungs- und Austrittsverfahren (Zugriffswiderruf, Asset-Rueckgabe, Wissenstransfer)

SaaS-Beispiel: Alle Mitarbeiter durchlaufen eine Hintergrundpruefung vor ihrem Startdatum. Sicherheitsbewusstseins-Schulung wird innerhalb der ersten Arbeitswoche und danach jaehrlich absolviert. Alle Mitarbeiter unterzeichnen eine Vertraulichkeitsvereinbarung bezueglich Kundendaten. Bei Kuendigung wird die IT innerhalb von 4 Stunden benachrichtigt, und alle Zugriffe werden vor Ende des letzten Arbeitstages des Mitarbeiters widerrufen.

8. Vorfallmanagement-Richtlinie

Annex A Referenz: A.5.24 (Planung und Vorbereitung des Informationssicherheits-Vorfallmanagements), A.5.25 (Bewertung und Entscheidung zu Informationssicherheitsereignissen), A.5.26 (Reaktion auf Informationssicherheitsvorfaelle), A.5.27 (Lernen aus Informationssicherheitsvorfaellen), A.5.28 (Beweissicherung), A.6.8 (Meldung von Informationssicherheitsereignissen)

Diese Richtlinie definiert, wie Ihre Organisation Informationssicherheitsvorfaelle erkennt, meldet, bewertet, darauf reagiert und daraus lernt.

Was sie abdeckt:

• Definitionen von Sicherheitsereignissen und -vorfaellen (und die Unterscheidung zwischen ihnen)
• Schweregrad-Klassifizierungsschema (z.B. P1-P4)
• Meldekaenaele und Verantwortlichkeiten (wer was, an wen und wie schnell meldet)
• Eskalationsverfahren basierend auf dem Schweregrad
• Eindaemmungs-, Beseitigungs- und Wiederherstellungsschritte
• Anforderungen an die Beweissicherung
• Nachbesprechungsprozess nach Vorfaellen
• Externe Benachrichtigungspflichten (Regulierungsbehoerden, Kunden, Strafverfolgung)

SaaS-Beispiel: Jeder Mitarbeiter, der ein Sicherheitsereignis vermutet, meldet es sofort ueber den #security-incidents Slack-Kanal. Der diensthabende Sicherheitsingenieur sichtet innerhalb von 30 Minuten. P1-Vorfaelle (bestaetigte Datenschutzverletzung, aktiver Einbruch) loesen einen War Room aus und erfordern eine Kundenbenachrichtigung innerhalb von 72 Stunden. Jeder P1- und P2-Vorfall erhaelt eine schriftliche Nachbesprechung innerhalb von fuenf Werktagen.

9. Geschaeftskontinuitaetsrichtlinie

Annex A Referenz: A.5.29 (Informationssicherheit waehrend Stoerungen), A.5.30 (IKT-Bereitschaft fuer Geschaeftskontinuitaet), A.8.13 (Informationssicherung), A.8.14 (Redundanz von Informationsverarbeitungseinrichtungen)

Diese Richtlinie legt fest, wie die Organisation die Informationssicherheit waehrend stoerenden Ereignissen aufrechterhaelt und die Verfuegbarkeit kritischer Dienste sicherstellt.

Was sie abdeckt:

• Anforderungen an die Geschaeftsauswirkungsanalyse (BIA)
• Wiederherstellungszeitziele (RTO) und Wiederherstellungspunktziele (RPO) fuer kritische Dienste
• Sicherungsrichtlinie (Umfang, Haeufigkeit, Aufbewahrung, Tests)
• Disaster-Recovery-Verfahren
• Test- und Uebungsplan
• Kommunikationsplan waehrend Stoerungen

SaaS-Beispiel: Produktionsdatenbanken werden stuendlich gesichert mit einem RPO von 1 Stunde und einem RTO von 4 Stunden. Sicherungen werden in einer separaten AWS-Region gespeichert und monatlich durch eine vollstaendige Wiederherstellung in eine Staging-Umgebung getestet. Disaster-Recovery-Tischuebungen werden vierteljaehrlich durchgefuehrt. Die Statusseite wird innerhalb von 15 Minuten nach jeder Dienststoerung aktualisiert.

10. Lieferanten- und Drittanbieterrichtlinie

Annex A Referenz: A.5.19 (Informationssicherheit in Lieferantenbeziehungen), A.5.20 (Adressierung der Informationssicherheit in Lieferantenvereinbarungen), A.5.21 (Management der Informationssicherheit in der IKT-Lieferkette), A.5.22 (Ueberwachung, Ueberpruefung und Aenderungsmanagement von Lieferantendiensten), A.5.23 (Informationssicherheit bei der Nutzung von Cloud-Diensten)

Diese Richtlinie regelt, wie Ihre Organisation Drittanbieter-Lieferanten bewertet, einbindet, ueberwacht und verabschiedet, die auf Ihre Daten oder die Daten Ihrer Kunden zugreifen, diese verarbeiten oder speichern.

Was sie abdeckt:

• Methodik und Haeufigkeit der Lieferantenrisikobewertung
• Sicherheitsanforderungen fuer Lieferantenvereinbarungen (Datenschutz, Vorfallbenachrichtigung, Pruefungsrechte)
• Due-Diligence-Prozess fuer neue Lieferanten (Sicherheitsfrageboegen, Ueberpruefung von SOC 2/ISO 27001 Berichten)
• Laufende Ueberwachungsrhythmus (jaehrliche Ueberpruefung, kontinuierliche Ueberwachung fuer kritische Lieferanten)
• Sub-Auftragsverarbeiter-Management
• Sicherheitsanforderungen an Cloud-Dienstanbieter

SaaS-Beispiel: Alle Lieferanten, die Kundendaten verarbeiten, durchlaufen vor dem Onboarding eine Sicherheitsbewertung. Kritische Lieferanten (Infrastruktur, Identitaet, Zahlungsabwicklung) werden jaehrlich ueberprueft und muessen ein aktuelles SOC 2 Type II oder ISO 27001 Zertifikat vorlegen. Lieferantenvereinbarungen umfassen Datenverarbeitungsklauseln, Verletzungsbenachrichtigung innerhalb von 48 Stunden und das Recht auf Auditierung.

11. Kryptographierichtlinie

Annex A Referenz: A.8.24 (Einsatz von Kryptographie)

Diese Richtlinie definiert den Ansatz der Organisation zur Verwendung kryptographischer Kontrollen zum Schutz der Vertraulichkeit, Integritaet und Authentizitaet von Informationen.

Was sie abdeckt:

• Verschluesselungsanforderungen nach Datenklassifizierungsstufe
• Genehmigte kryptographische Algorithmen und Mindestschluesselllaengen
• Schluesselverwaltungsverfahren (Erzeugung, Verteilung, Speicherung, Rotation, Widerruf, Vernichtung)
• TLS/SSL-Anforderungen fuer Daten in der Uebertragung
• Verschluesselung im Ruhezustand Anforderungen
• Zertifikatsmanagement

SaaS-Beispiel: Alle Daten in der Uebertragung verwenden TLS 1.2 oder hoeher. Kundendaten im Ruhezustand werden mit AES-256 verschluesselt. Datenbank-Verschluesselungsschluessel werden ueber AWS KMS mit automatischer jaehrlicher Rotation verwaltet. SSH-Schluessel erfordern ED25519 oder RSA-4096. Zertifikate werden ueber ACM mit automatisierter Erneuerung verwaltet.

12. Physische Sicherheitsrichtlinie

Annex A Referenz: A.7.1 bis A.7.14

Fuer SaaS-Unternehmen, die vollstaendig in der Cloud operieren, ist die physische Sicherheitsrichtlinie oft eng auf Bueroeinrichtungen und Mitarbeiterendpunkte begrenzt. Die physische Sicherheit der Cloud-Infrastruktur wird typischerweise durch die eigenen Zertifizierungen des Cloud-Anbieters abgedeckt.

Was sie abdeckt:

• Buerozutrittskontrolle (Zutrittskarten, Besuchermanagement)
• Sicherheitsbereiche (Serverraeume falls vorhanden, eingeschraenkte Buerozonen)
• Ausruestungssicherheit (Laptop-Verschluesselung, Bildschirmsperre, sichere Entsorgung)
• Sicherheitsanforderungen fuer Remote-Arbeit
• Clean-Desk- und Clean-Screen-Richtlinie

SaaS-Beispiel: Ihre physische Sicherheitsrichtlinie erkennt an, dass die Produktionsinfrastruktur auf AWS laeuft (physische Sicherheit durch die eigenen ISO 27001 und SOC 2 Zertifizierungen von AWS geregelt). Die Richtlinie konzentriert sich auf Buerozutritt (Kartenzugang erforderlich, Besucher muessen begleitet und protokolliert werden), Endpunktsicherheit (FileVault/BitLocker-Verschluesselung obligatorisch, Bildschirmsperre nach 5 Minuten) und Remote-Arbeit (VPN erforderlich fuer den Zugriff auf interne Tools, Arbeit darf nicht auf oeffentlichen Computern durchgefuehrt werden).

13. Betriebssicherheitsrichtlinie

Annex A Referenz: A.8.6 (Kapazitaetsmanagement), A.8.7 (Schutz gegen Malware), A.8.8 (Management technischer Schwachstellen), A.8.9 (Konfigurationsmanagement), A.8.15 (Protokollierung), A.8.16 (Ueberwachungsaktivitaeten)

Diese Richtlinie umfasst die taeglichen operativen Sicherheitskontrollen, die Ihre Systeme sicher und beobachtbar halten.

Was sie abdeckt:

• Aenderungsmanagement und Bereitstellungsprozesse
• Kapazitaetsplanung
• Trennung von Entwicklungs-, Test- und Produktionsumgebungen
• Malware-Schutz fuer Endpunkte
• Schwachstellenmanagement (Scanhaeufigkeit, Patching-SLAs nach Schweregrad)
• Protokollierungs- und Ueberwachungsanforderungen
• Konfigurationsmanagement und Haertungsbaselines

SaaS-Beispiel: Kritische Schwachstellen (CVSS 9.0+) muessen innerhalb von 72 Stunden gepatcht werden. Hohe Schwachstellen (CVSS 7.0-8.9) innerhalb von 30 Tagen. Alle Produktionssysteme senden Logs an ein zentralisiertes SIEM mit 90-Tage-Aufbewahrung. Entwicklungs-, Staging- und Produktionsumgebungen sind mit separaten AWS-Konten isoliert. Endpoint-Detection-and-Response (EDR) Software laeuft auf allen Mitarbeiter-Laptops.

14. Kommunikationssicherheits- und Datentransferrichtlinie

Annex A Referenz: A.5.14 (Informationsuebertragung), A.8.20 (Netzwerksicherheit), A.8.21 (Sicherheit von Netzwerkdiensten), A.8.22 (Netzwerksegmentierung), A.8.23 (Webfilterung)

Diese Richtlinie regelt, wie Informationen innerhalb und ausserhalb der Organisation uebertragen werden und wie die Netzwerksicherheit aufrechterhalten wird.

Was sie abdeckt:

• Genehmigte Kanaele fuer die Informationsuebertragung nach Klassifizierungsstufe
• E-Mail-Sicherheitsanforderungen
• Netzwerksegmentierungsregeln
• Drahtlose Netzwerksicherheit
• Remote-Zugriffsanforderungen (VPN, Zero Trust)
• Datenuebertragungsvereinbarungen mit externen Parteien

Wie man eine ISO 27001 Richtlinie strukturiert

Eine einheitliche Richtlinienstruktur ist keine formale Anforderung, verbessert aber die Nutzbarkeit erheblich und demonstriert Reife. Wenn jede Richtlinie der gleichen Vorlage folgt, wissen Mitarbeiter, wo sie Informationen finden, und Auditoren koennen Ihre Dokumentation effizient navigieren.

Empfohlene Richtlinienabschnitte

1. Dokumentkontrollblock

Jede Richtlinie sollte mit Metadaten beginnen:

• Richtlinientitel und eindeutige Kennung (z.B. POL-ISP-001)
• Versionsnummer
• Richtlinieneigentuemer (Name und Rolle)
• Genehmiger (Name und Rolle)
• Datum des Inkrafttretens
• Naechstes Ueberpruefungsdatum
• Klassifizierungsstufe (typischerweise Intern oder Vertraulich)

2. Zweck

Ein bis zwei Absaetze, die erklaeren, warum diese Richtlinie existiert und welches Problem sie adressiert. Dies sollte die Frage beantworten: “Warum sollte mich diese Richtlinie interessieren?”

Beispiel: “Diese Zugriffskontrollrichtlinie legt die Anforderungen fuer die Verwaltung des Benutzerzugriffs auf Informationssysteme und Daten ueber den gesamten Zugangslebenszyklus fest. Sie existiert, um unautorisierten Zugriff zu verhindern, das Prinzip der geringsten Rechte aufrechtzuerhalten und sicherzustellen, dass Zugriffsrechte angemessen bleiben, wenn Mitarbeiter in die Organisation eintreten, sich innerhalb der Organisation bewegen oder die Organisation verlassen.”

3. Anwendungsbereich

Definieren Sie genau, fuer wen und was die Richtlinie gilt. Seien Sie spezifisch bei Ein- und Ausschluessen.

Beispiel: “Diese Richtlinie gilt fuer alle Mitarbeiter, Auftragnehmer und Drittbenutzer, die auf [Firmenname] Informationssysteme zugreifen. Sie umfasst alle Produktionssysteme, Unternehmensanwendungen und Cloud-Dienste innerhalb des ISMS-Anwendungsbereichs, wie in der ISMS-Anwendungsbereichserklaerung (DOC-ISMS-001) definiert. Sie umfasst nicht den physischen Zugang zu Bueroeinrichtungen, der durch die Physische Sicherheitsrichtlinie (POL-PHY-001) geregelt wird.”

4. Richtlinienaussagen

Der Kern des Dokuments. Jede Richtlinienaussage sollte sein:

• Klar und eindeutig — Kein Interpretationsspielraum
• Messbar — Sie koennen die Einhaltung objektiv feststellen
• Realistisch — Mit aktuellen Ressourcen und Technologie erreichbar
• Zurechenbar — Jemand ist fuer die Einhaltung verantwortlich

Formulieren Sie Richtlinienaussagen als Anforderungen, nicht als Vorschlaege. Verwenden Sie “muss” und “soll” fuer verbindliche Anforderungen, “sollte” fuer Empfehlungen und “kann” fuer Erlaubnisse.

5. Rollen und Verantwortlichkeiten

Definieren Sie, wer wofuer verantwortlich ist. Verwenden Sie Rollentitel, keine einzelnen Namen, damit die Richtlinie Personalwechsel uebersteht.

Beispiel:

• Informationssicherheitsmanager: Pflegt diese Richtlinie, fuehrt jaehrliche Ueberpruefungen durch und berichtet den Compliance-Status an die Fuehrung
• IT-Betriebsteam: Implementiert die in dieser Richtlinie definierten technischen Kontrollen
• People Operations: Benachrichtigt die IT innerhalb von 4 Stunden ueber Mitarbeiterkuendigungen
• Alle Mitarbeiter: Halten diese Richtlinie ein und melden vermutete Verstoesse

6. Verwandte Dokumente

Listen Sie die Standards, Verfahren und anderen Richtlinien auf, die diese Richtlinie unterstuetzen oder mit ihr verbunden sind. Dies schafft Rueckverfolgbarkeit in Ihrem Dokumentationsrahmen.

7. Definitionen und Abkuerzungen

Definieren Sie alle Begriffe, die moeglicherweise mehrdeutig sind. Dies ist besonders wichtig, wenn sowohl technische als auch nicht-technische Zielgruppen die Richtlinie lesen.

8. Ueberpruefungs- und Revisionshistorie

Eine Tabelle, die jede Revision zeigt: Datum, Version, Autor und eine kurze Beschreibung der Aenderungen.

Richtlinien fuer SaaS-Unternehmen schreiben

SaaS-Unternehmen haben ausgepragte Merkmale, die beeinflussen sollten, wie Richtlinien geschrieben werden. Das Ignorieren dieser Merkmale produziert Richtlinien, die technisch konform, aber operativ nutzlos sind.

Schreiben Sie fuer Ihren tatsaechlichen Workflow. Wenn Ihr Engineering-Team 20 Mal am Tag ueber eine CI/CD-Pipeline in die Produktion deployt, sollte Ihre Aenderungsmanagement-Richtlinie diesen Prozess beschreiben — nicht ein traditionelles Change Advisory Board, das sich woechentlich trifft. Auditoren bestrafen keine modernen Praktiken. Sie bestrafen Diskrepanzen zwischen dem, was Sie dokumentieren, und dem, was Sie tun.

Seien Sie spezifisch bei Cloud-Diensten. Generische Verweise auf “Server” und “Rechenzentren” signalisieren, dass eine Richtlinie fuer eine andere Art von Unternehmen geschrieben wurde. Benennen Sie Ihre Cloud-Anbieter. Referenzieren Sie spezifische Dienste (AWS RDS, Azure AD, GCP Cloud Run). Diese Spezifitaet hilft Mitarbeitern zu verstehen, was die Richtlinie in der Praxis bedeutet, und hilft Auditoren, die Einhaltung zu ueberpruefen.

Halten Sie Richtlinien praegnant. Eine 50-seitige Zugriffskontrollrichtlinie signalisiert Buerokratie, nicht Reife. Auditoren und Mitarbeiter bevorzugen gleichermassen Dokumente, die gruendlich, aber nicht wortreich sind. Wenn ein Abschnitt ueber eine Seite hinauswaechst, ueberlegen Sie, ob die Details in ein unterstuetzendes Verfahren oder einen Standard gehoeren statt in die Richtlinie selbst.

Verwenden Sie Sprache, die Ihr Team versteht. Wenn Ihr Team “deployen” statt “bereitstellen” sagt, verwenden Sie “deployen”. Wenn sie “Repo” statt “Repository” sagen, verwenden Sie “Repo”. Richtlinien, die unvertraute Sprache verwenden, werden ignoriert.

Setzen Sie erreichbare Verpflichtungen. Jede Richtlinienaussage wird zu einer testbaren Verpflichtung. Wenn Ihre Richtlinie sagt, Passwoerter muessen alle 30 Tage rotiert werden, muessen Sie beweisen, dass sie es werden. Wenn Ihre Richtlinie sagt, Zugangspruefungen finden vierteljaehrlich statt, brauchen Sie vier abgeschlossene Pruefungen pro Jahr. Die haeufigste einzelne Audit-Feststellung ueber alle ISO 27001 Zertifizierungen hinweg ist, dass Organisationen ihre eigenen festgelegten Anforderungen nicht erfuellen. Setzen Sie Standards, die Sie konsistent einhalten koennen, und heben Sie sie im Laufe der Zeit durch kontinuierliche Verbesserung an.

Genehmigung und Kommunikation

Richtliniengenehmigung

Klausel 5.2 verlangt, dass die Informationssicherheitsrichtlinie von der obersten Leitung genehmigt wird. In der Praxis erwarten Auditoren, dass alle ISMS-Richtlinien einen formalen Genehmigungsprozess durchlaufen.

Wer genehmigt: Der Genehmiger sollte jemand mit ausreichender Befugnis sein, die Organisation an die Anforderungen in der Richtlinie zu binden. Fuer die uebergeordnete Informationssicherheitsrichtlinie ist dies typischerweise der CEO, CTO oder ein Mitglied der Geschaeftsleitung. Fuer untergeordnete Richtlinien ist der Informationssicherheitsmanager oder CTO in der Regel angemessen.

Wie die Genehmigung dokumentiert wird: Halten Sie es einfach. Optionen umfassen:

• Digitale Signatur auf dem Richtliniendokument
• Genehmigung im Dokumentenmanagementsystem erfasst (mit Zeitstempel und Genehmiger-Identitaet)
• E-Mail- oder Slack-Bestaetigung erfasst und als Nachweis gespeichert
• Genehmigung ueber eine GRC-Plattform mit Audit-Trail

Was zaehlt, ist, dass Sie nachweisen koennen, wer die Richtlinie genehmigt hat, wann sie genehmigt wurde und welche Version genehmigt wurde.

Richtlinienkommunikation

Klausel 7.4 verlangt, dass Sie relevante Informationen ueber das ISMS an interne und, wo angemessen, externe Parteien kommunizieren. Fuer Richtlinien bedeutet dies:

• Alle Mitarbeiter muessen wissen, dass die Richtlinien existieren
• Mitarbeiter muessen Zugang zu den fuer ihre Rollen relevanten Richtlinien haben
• Neue Mitarbeiter muessen Richtlinieninformationen waehrend des Onboardings erhalten
• Wesentliche Richtlinienaenderungen muessen kommuniziert werden, wenn sie auftreten

Praktische Ansaetze fuer SaaS-Teams:

• Richtlinien an einem zentralen, zugaenglichen Ort speichern (Confluence, Notion, SharePoint oder eine GRC-Plattform)
• Benachrichtigung senden, wenn Richtlinien erstellt oder wesentlich aktualisiert werden
• Richtlinienueberpruefung in die Onboarding-Checkliste aufnehmen
• Jaehrliche Richtlinienbestaetigung von allen Mitarbeitern verlangen (mit Zeitstempeln dokumentiert)

Haeufige Audit-Feststellung: Richtlinien existieren in einem Dokumentenmanagementsystem, aber Mitarbeiter wussten nicht, dass sie existieren, oder konnten sie nicht finden. Auditoren koennen Mitarbeiter befragen und fragen, wo sie die Zugriffskontrollrichtlinie finden wuerden. Wenn der Mitarbeiter nicht antworten kann, ist das eine Kommunikationsluecke.

Richtlinienbestaetigung

Obwohl ISO 27001 nicht ausdruecklich unterschriebene Bestaetigung verlangt, sind sie ein starker Nachweis, dass die Kommunikation stattgefunden hat. Die meisten Zertifizierungsauditoren erwarten eine Form der Bestaetigung, insbesondere fuer kritische Richtlinien.

Implementieren Sie ein System, bei dem Mitarbeiter elektronisch bestaetigen, dass sie jede Richtlinie gelesen und verstanden haben. Verfolgen Sie Abschlussdaten und erinnern Sie Mitarbeiter, die ihre Bestaetigung noch nicht abgeschlossen haben. Dieser Nachweis ist direkt nuetzlich waehrend Audits.

Ueberpruefungsrhythmus und Lebenszyklus

Verbindliche Ueberpruefungshaeufigkeit

ISO 27001 verlangt, dass dokumentierte Information nach Bedarf ueberprueft und aktualisiert wird (Klausel 7.5.2). Obwohl der Standard keine Mindestfrequenz vorschreibt, ist die universelle Erwartung eine mindestens jaehrliche Ueberpruefung.

Empfohlener Rhythmus:

• Jaehrliche Ueberpruefung: Jede Richtlinie sollte mindestens einmal pro Jahr ueberprueft werden, auch wenn keine Aenderungen erforderlich sind. Dokumentieren Sie, dass die Ueberpruefung stattgefunden hat und die Richtlinie als aktuell bestaetigt wurde.
• Anlassgetriebene Ueberpruefung: Ueberpruefen und aktualisieren Sie Richtlinien bei signifikanten Aenderungen — organisatorische Umstrukturierungen, groessere Technologieaenderungen, neue regulatorische Anforderungen oder aus Sicherheitsvorfaellen gewonnene Erkenntnisse.
• Ueberpruefung nach Vorfaellen: Ueberpruefen Sie nach signifikanten Sicherheitsvorfaellen die relevanten Richtlinien, um festzustellen, ob Aenderungen erforderlich sind.

Der Ueberpruefungsprozess

Eine Richtlinienueberpruefung ist nicht nur das erneute Lesen des Dokuments und die Abzeichnung. Eine wirksame Ueberpruefung umfasst:

1. Relevanzpruefung: Adressiert die Richtlinie noch aktuelle Risiken und den Geschaeftskontext?
2. Genauigkeitspruefung: Stimmen die Richtlinienaussagen mit den tatsaechlichen Praktiken ueberein? Wenn Praktiken von der Richtlinie abgewichen sind, aktualisieren Sie entweder die Richtlinie oder korrigieren Sie die Praktiken.
3. Vollstaendigkeitspruefung: Sind neue Risiken, Technologien oder Vorschriften aufgetaucht, die die Richtlinie adressieren sollte?
4. Stakeholder-Input: Konsultieren Sie die Teams, die fuer die Umsetzung der Richtlinie verantwortlich sind. Sie wissen, wo die Luecken sind.
5. Genehmigung: Aktualisierte Richtlinien durchlaufen den gleichen Genehmigungsprozess wie neue Richtlinien.
6. Kommunikation: Wenn Aenderungen vorgenommen wurden, benachrichtigen Sie betroffene Mitarbeiter und fordern aktualisierte Bestaetigung an.

Versionskontrolle

Fuehren Sie eine klare Versionshistorie fuer jede Richtlinie. Sie muessen Auditoren zeigen koennen, welche Version waehrend eines bestimmten Zeitraums gueltig war. Dies ist besonders wichtig waehrend des Uebergangs, wenn Richtlinien aktualisiert werden — der Auditor muss ueberpruefen, dass die waehrend des Auditzeitraums gueltige Version die befolgte Version war.

Verwenden Sie ein konsistentes Versionierungsschema (z.B. 1.0, 1.1, 2.0) und speichern Sie fruehere Versionen, anstatt sie zu ueberschreiben. Eine GRC-Plattform oder ein Dokumentenmanagementsystem mit eingebauter Versionskontrolle eliminiert das Risiko, historische Versionen zu verlieren.

Richtlinien auf Annex A Kontrollen abbilden

Eines der nuetzlichsten Dinge, die Sie beim Aufbau Ihres Richtlinienrahmenwerks tun koennen, ist die Erstellung einer expliziten Zuordnung zwischen Ihren Richtlinien und den Annex A Kontrollen, die sie adressieren. Diese Zuordnung dient drei Zwecken:

1. Vollstaendigkeitssicherung: Sie koennen ueberpruefen, ob jede anwendbare Annex A Kontrolle durch mindestens eine Richtlinie adressiert wird
2. Auditeffizienz: Auditoren koennen schnell die fuer jede Kontrolle, die sie testen moechten, relevante Richtlinie finden
3. Lueckenidentifizierung: Sie koennen Kontrollen identifizieren, die in Ihrer SoA als anwendbar deklariert sind, aber keine unterstuetzende Dokumentation haben

Beispiel-Zuordnung

Annex A Kontrolle	Kontrolltitel	Primaere Richtlinie	Unterstuetzendes Verfahren
A.5.1	Richtlinien fuer Informationssicherheit	Informationssicherheitsrichtlinie	Richtlinienmanagement-Verfahren
A.5.9	Inventar von Informationen und zugehoerigen Werten	Asset-Management-Richtlinie	Asset-Inventar-Verfahren
A.5.15	Zugriffskontrolle	Zugriffskontrollrichtlinie	Benutzerprovisionierungs-Verfahren
A.5.24	Planung des Informationssicherheits-Vorfallmanagements	Vorfallmanagement-Richtlinie	Incident-Response-Verfahren
A.5.29	Informationssicherheit waehrend Stoerungen	Geschaeftskontinuitaetsrichtlinie	Disaster-Recovery-Verfahren
A.8.24	Einsatz von Kryptographie	Kryptographierichtlinie	Schluesselverwaltungs-Verfahren

Pflegen Sie diese Zuordnung als lebendes Dokument. Wenn Sie die Anwendbarkeit von Annex A Kontrollen in Ihrer SoA hinzufuegen oder aendern, aktualisieren Sie gleichzeitig die Richtlinienzuordnung. Wenn Sie eine Richtlinie aktualisieren, ueberpruefen Sie, ob die Zuordnung den Inhalt der Richtlinie noch korrekt widerspiegelt.

Richtlinien vs. Verfahren vs. Standards

Verstehen Sie die Hierarchie und halten Sie die Ebenen getrennt:

• Richtlinien geben an, was die Organisation tun wird und warum. Sie werden vom Management genehmigt und geben die Richtung vor. Sie aendern sich selten.
• Standards definieren spezifische messbare Anforderungen. Sie uebersetzen die Richtlinienabsicht in konkrete Masstaebe. Beispiel: “AES-256 fuer Daten im Ruhezustand.”
• Verfahren beschreiben Schritt fuer Schritt, wie eine Aufgabe ausgefuehrt wird. Sie sind operativ und koennen sich aendern, wenn sich Tools oder Prozesse weiterentwickeln.

Auditoren erwarten, dass diese Hierarchie in Ihrer Dokumentation widergespiegelt wird. Wenn eine Richtlinie auf ein Verfahren verweist, sollte das Verfahren existieren. Wenn ein Verfahren auf einen Standard verweist, sollte der Standard dokumentiert sein. Unterbrochene Verweise — Richtlinien, die auf nicht existierende Verfahren zeigen — sind eine haeufige Feststellung.

Haeufige Richtlinienfehler und wie man sie vermeidet

Vorlagen ohne Anpassung kopieren

Der am weitesten verbreitete Fehler. Generische Vorlagen enthalten Verweise auf physische Serverraeume, Bandsicherungsrotationen und Besucherbuecher, die nichts mit einem cloud-nativen SaaS-Unternehmen zu tun haben. Jede Richtlinienaussage sollte etwas beschreiben, das Ihre Organisation tatsaechlich tut oder tun wird.

Loesung: Verwenden Sie Vorlagen als Ausgangsrahmen und schreiben Sie dann jeden Abschnitt um, um Ihrer tatsaechlichen Umgebung, Ihren Tools und Ihren Workflows zu entsprechen. Wenn ein Abschnitt nicht zutrifft, entfernen Sie ihn, anstatt ihn als ambitionierten Text stehen zu lassen.

Zu viel versprechen

Organisationen schreiben Richtlinien, die einen Idealzustand beschreiben, anstatt ihre tatsaechliche Faehigkeit. Eine Richtlinie, die Sicherheitspruefungen jeder Codezeile, woechentliche Penetrationstests und Echtzeit-Bedrohungsjagd verlangt, klingt beeindruckend, schafft aber Verpflichtungen, die nahezu unmoeglich einzuhalten sind.

Loesung: Schreiben Sie Richtlinien, die Ihre aktuelle Faehigkeit widerspiegeln, mit einem klaren Plan, die Messlatte durch kontinuierliche Verbesserung anzuheben. Es ist weitaus besser, erreichbare Richtlinien zu haben, die Sie konsistent einhalten, als ambitionierte Richtlinien, die Sie konsistent verletzen.

Unter-Dokumentierung

Das entgegengesetzte Extrem — Richtlinien so vage, dass sie keine umsetzbare Anleitung bieten. “Das Unternehmen wird seine Daten schuetzen” ist eine Visionserlaerung, keine Richtlinie.

Loesung: Jede Richtlinienaussage sollte spezifisch genug sein, um sie zu testen. Fragen Sie: “Koennte ein Auditor feststellen, ob wir diese Aussage einhalten?” Wenn die Antwort nein ist, braucht die Aussage mehr Spezifitaet.

Den Ueberpruefungszyklus ignorieren

Richtlinien werden waehrend der initialen ISMS-Implementierung geschrieben und nie wieder besucht. Zwei Jahre spaeter hat das Unternehmen von AWS zu GCP migriert, sich verdoppelt und drei neue Produkte eingefuehrt, aber die Richtlinien beschreiben immer noch die urspruengliche Umgebung.

Loesung: Setzen Sie Kalendererinnerungen fuer jaehrliche Ueberpruefungen. Weisen Sie fuer jedes Dokument einen Richtlinieneigentuemer zu, der dafuer verantwortlich ist, es aktuell zu halten. Integrieren Sie die Richtlinienueberpruefung in den Umfang Ihres internen Audits.

Richtlinien nicht mit Nachweisen verknuepfen

Eine Richtlinie existiert, aber es gibt keinen Mechanismus, um die Einhaltung nachzuweisen. Die Zugriffskontrollrichtlinie verlangt vierteljaehrliche Zugangspruefungen, aber niemand fuehrt die Pruefungen durch und es gibt keine Aufzeichnungen.

Loesung: Definieren Sie fuer jede Richtlinienaussage, welcher Nachweis die Einhaltung demonstriert, und stellen Sie sicher, dass ein Prozess existiert, um diesen Nachweis zu generieren und aufzubewahren. Wenn Sie Ihre Zertifizierungs-Checkliste erstellen, verfolgen Sie jede Richtlinienanforderung zu ihrer Nachweisquelle zurueck.

Richtlinien vom Betrieb isolieren

Richtlinien leben in einem Confluence-Space, den niemand besucht. Das Engineering-Team hat nie die Aenderungsmanagement-Richtlinie gelesen, weil sie vom Compliance-Team ohne deren Input geschrieben wurde.

Loesung: Beteiligen Sie operative Teams an der Richtlinienerstellung. Schreiben Sie Richtlinien in der Sprache, die sie verwenden. Speichern Sie Richtlinien dort, wo sie bereits arbeiten. Wenn Ihr Team in Notion lebt, legen Sie Richtlinien in Notion ab. Wenn sie GitHub verwenden, erwaegen Sie die Verwaltung von Richtlinien als Markdown in einem Repository mit Pull-Request-basierten Review-Workflows.

Haeufig gestellte Fragen

Wie viele Richtlinien verlangt ISO 27001?

ISO 27001 gibt keine Anzahl vor. Der Standard verlangt bestimmte dokumentierte Information, und wie Sie diese Information in Richtlinien organisieren, ist Ihre Entscheidung. Ein kleines SaaS-Unternehmen koennte 10-15 Richtlinien haben, die alle Annex A Kontrollen abdecken. Eine groessere Organisation koennte 30 oder mehr haben. Was zaehlt, ist, dass jede anwendbare Annex A Kontrolle auf dokumentierte Richtlinienabdeckung zurueckfuehrbar ist, nicht die Dokumentenanzahl.

Kann ich mehrere Richtlinien in einem einzigen Dokument zusammenfassen?

Ja. Einige Organisationen fuehren ein einziges “Informationssicherheitshandbuch”, das alle Richtlinien in einem Dokument enthaelt. Andere teilen jedes Thema in ein separates Dokument auf. Beide Ansaetze sind akzeptabel. Der Ein-Dokument-Ansatz ist einfacher zu verwalten fuer kleine Teams. Der Mehr-Dokument-Ansatz skaliert besser, wenn die Organisation waechst und verschiedene Teams verschiedene Richtlinienbereiche besitzen.

Muessen Richtlinien ein bestimmtes Format haben?

Nein. ISO 27001 schreibt keine Dokumentformate vor. Richtlinien koennen in Word-Dokumenten, PDF-Dateien, Wiki-Seiten, Markdown-Dateien oder ueber eine GRC-Plattform verwaltet werden. Was zaehlt, ist, dass sie kontrolliert (versioniert, genehmigt, zugaenglich) und ueberprueft werden.

Wer sollte die Richtlinien schreiben?

Die Person, die sowohl den Sachbereich als auch die tatsaechlichen Praktiken der Organisation versteht. In den meisten SaaS-Unternehmen bedeutet dies eine Zusammenarbeit zwischen dem Sicherheits-/Compliance-Team und dem relevanten operativen Team. Das Sicherheitsteam liefert den Rahmen und die Kontrollziele. Das operative Team liefert die Implementierungsrealitaet. Ein Compliance-Berater kann die Bruecke zwischen beiden schlagen.

Wie lang sollte eine Richtlinie sein?

So lang wie noetig und nicht laenger. Eine typische gut geschriebene Richtlinie umfasst 3-8 Seiten. Wenn eine Richtlinie 10 Seiten ueberschreitet, ueberlegen Sie, ob einige Inhalte in ein unterstuetzendes Verfahren oder einen Standard gehoeren. Kuerze verbessert die Lesbarkeit und Akzeptanz. Allerdings opfern Sie nicht die Klarheit zugunsten der Praegnanz — wenn eine Richtlinienaussage einen Absatz Kontext braucht, um verstanden zu werden, fuegen Sie den Kontext hinzu.

Was ist der Unterschied zwischen ISO 27001 Richtlinien und SOC 2 Richtlinien?

Die zugrunde liegenden Kontrollen ueberschneiden sich erheblich, aber der Dokumentationsrahmen unterscheidet sich. ISO 27001 Richtlinien unterstuetzen ein ISMS und sind um Annex A Kontrollen herum organisiert. SOC 2 Richtlinien unterstuetzen eine Systembeschreibung und sind um Trust Service Criteria organisiert. Viele SaaS-Unternehmen, die beide Rahmenwerke anstreben, pflegen einen einzigen Richtliniensatz, der beide Standards erfuellt, mit einem Zuordnungsdokument, das zeigt, wie jede Richtlinie sowohl ISO 27001 Kontrollen als auch SOC 2 Kriterien adressiert.

Wie GRCTrail hilft

GRCTrail bietet SaaS-Teams eine vollstaendige Richtlinienmanagement-Loesung fuer die ISO 27001 Zertifizierung:

• ISO 27001-konforme Richtlinienvorlagen, die speziell fuer SaaS-Unternehmen geschrieben wurden und jede Annex A Kontrolle mit Sprache abdecken, die cloud-native Operationen widerspiegelt — keine Verweise auf Bandsicherungen oder physische Serverraeume
• Automatisierte Richtlinien-zu-Kontrollen-Zuordnung, die jede Annex A Kontrolle in Ihrer Erklaerung zur Anwendbarkeit auf die sie regelnde Richtlinie zurueckverfolgt und Luecken identifiziert, bevor Ihr Auditor es tut
• Eingebautes Richtlinien-Lebenszyklusmanagement mit Versionskontrolle, digitalen Genehmigungsworkflows, Mitarbeiter-Bestaetigung-Tracking und automatisierten Ueberpruefungserinnerungen, die sicherstellen, dass Ihre Richtlinien nie veralten

Starten Sie mit GRCTrail

Verwandte Leitfaeden

• Was ist ISO 27001? Ein praktischer Leitfaden fuer SaaS-Unternehmen
• ISO 27001 Anforderungen: Klauseln 4-10 verstehen
• ISO 27001 Annex A Kontrollen: Der vollstaendige Leitfaden
• ISO 27001 Zertifizierungs-Checkliste
• ISO 27001 Zugriffskontrolle: Anforderungen, Kontrollen und SaaS-Implementierung
• SOC 2 Richtlinien und Verfahren: Was Sie dokumentieren muessen