Verbindlichkeitsregel: Diese Politik wird erst nach fachlicher Prüfung, dokumentierter Freigabe durch die Geschäftsführung und Erreichen des Gültigkeitsdatums verbindlich.
Hierarchiehinweis: Die Informationssicherheitsleitlinie beschreibt die übergeordnete Haltung und Verpflichtung der Geschäftsführung. Diese Informationssicherheitspolitik konkretisiert daraus organisationsweit geltende Mindestregeln. Themenrichtlinien, Verfahren und Arbeitsanweisungen setzen diese Regeln weiter um.
Beispieldokument: Die Politik ist für die fiktive „Muster GmbH“ formuliert. Unternehmensdaten, Rollenbesetzung, technische Rahmenbedingungen, Anforderungen, Gültigkeit und Freigaben sind vor der Einführung organisationsbezogen zu prüfen und anzupassen.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-RL-01-01 |
| Dokumentenart | Informationssicherheitsrichtlinie / übergeordnete Policy |
| Wiki.js-Pfad | /ISMS/01-Fuehrung-und-Steuerung/Informationssicherheitspolitik |
| Verantwortlich | Geschäftsführung |
| Dokumentenpflege | ISMS-Beauftragte/r |
| Fachlich geprüft durch | IT-/OT-Leitung, Datenschutz, Compliance, Personal, Einkauf, BCM und Qualitätsmanagement |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – organisatorische und technische Umsetzung noch nicht vollständig bewertet |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe |
| Nächste Prüfung | Spätestens zwölf Monate nach Freigabe sowie anlassbezogen |
| Schutzklasse | Intern; externe Kurzfassung nur nach gesonderter Freigabe |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 5.1, 5.2, 5.3, 6, 7, 8, 9 und 10 sowie Annex A 5.1 |
| VDA-ISA-Bezug | ISA 6.0.3, insbesondere Kapitel 1.1 „Information Security Policies“ und alle betroffenen Kontrollfragen |
Diese Politik legt die organisationsweit verbindlichen Grundregeln für den Schutz von Informationen, unterstützenden Assets, Geschäftsprozessen und Leistungen fest.
Sie bildet den Rahmen für:
| Dokumentebene | Zweck | Beispiel |
|---|---|---|
| Leitlinie | Haltung, Verpflichtung und strategischer Rahmen der Geschäftsführung | Informationssicherheitsleitlinie |
| Politik/Richtlinie | organisationsweit verbindliche Mindestregeln | diese Informationssicherheitspolitik |
| Themenrichtlinie | konkrete Vorgaben für ein Sicherheitsgebiet | Zugriff, Klassifizierung oder Lieferanten |
| Verfahren | Rollen und geregelter Ablauf | Risikobewertung oder Incident Response |
| Arbeitsanweisung | konkrete ausführbare Tätigkeit | Wiederherstellungs-Runbook |
| Nachweis | Beleg tatsächlicher Durchführung und Wirkung | Prüf-, Test- oder Freigabeprotokoll |
Bei Widersprüchen gilt nicht automatisch das jüngere Dokument. Der Widerspruch wird an Dokumenten-Owner und ISMS eskaliert; bis zur Klärung gilt die freigegebene höherrangige beziehungsweise strengere anwendbare Anforderung, soweit dies rechtlich und vertraglich zulässig ist.
Diese Politik gilt für:
Der konkrete organisatorische, räumliche und technische ISMS-Scope ist unter Geltungsbereich und Standorte festgelegt.
Vertragliche oder kundenspezifische Anforderungen außerhalb des formalen ISMS-Scopes bleiben einzuhalten, wenn sie auf die betreffende Tätigkeit anwendbar sind.
Alle Personen im Geltungsbereich müssen:
Führungskräfte stellen sicher, dass die Anforderungen in ihrem Verantwortungsbereich umgesetzt, verstanden und überwacht werden.
| Schutzziel | Zielsetzung |
|---|---|
| Vertraulichkeit | Informationen sind nur berechtigten Personen und Systemen zugänglich |
| Integrität | Informationen, Systeme und Prozesse sind richtig, vollständig und vor unberechtigter Veränderung geschützt |
| Verfügbarkeit | Informationen, Systeme und Leistungen stehen innerhalb der festgelegten Anforderungen zur Verfügung |
| Authentizität | Identitäten, Informationen und Kommunikationspartner sind verlässlich zuordenbar |
| Nachvollziehbarkeit | sicherheitsrelevante Handlungen und Entscheidungen können angemessen belegt werden |
| Verbindlichkeit | relevante Erklärungen und Transaktionen können nicht unbemerkt bestritten oder verändert werden |
Schutzbedarf, geschäftliche Kritikalität sowie Rechts-, Vertrags-, Kunden-, Datenschutz- und Prototypenschutzanforderungen bestimmen das erforderliche Schutzniveau.
Die Geschäftsführung:
Aufgaben können delegiert werden. Die Gesamtverantwortung der Geschäftsführung wird dadurch nicht aufgehoben.
Rollen, Verantwortlichkeiten, Befugnisse und Stellvertretungen werden dokumentiert, kommuniziert und regelmäßig überprüft.
Dabei gilt:
Das verbindliche Rollenmodell wird unter Rollen und Verantwortlichkeiten geführt.
Aus Leitlinie, Kontext, Risiken und Anforderungen werden messbare Informationssicherheitsziele abgeleitet.
Für jedes Ziel werden mindestens festgelegt:
Ein Plan, eine Aktivität oder ein fehlender Vorfall gilt nicht automatisch als Zielerreichung. Die operative Steuerung erfolgt unter Informationssicherheitsziele.
Informationssicherheitsrisiken werden:
Ein vorhandenes Dokument, ein Fertigstatus oder eine geplante Kontrolle gilt nicht automatisch als wirksame Risikobehandlung.
Maßgeblich sind:
Die Organisation ermittelt, bewertet und überwacht anwendbare:
Anforderungen werden Ownern, Kontrollen, Nachweisen und Reviewterminen zugeordnet. Änderungen werden auf Auswirkungen geprüft. Die zentrale Steuerung erfolgt über das Rechts- und Vertragskataster.
Informationen und unterstützende Assets werden:
Private oder nicht genehmigte Systeme, Speichermedien und Dienste dürfen nicht zur Verarbeitung geschäftlicher Informationen verwendet werden, sofern keine ausdrücklich genehmigte Regelung besteht.
Das führende Register ist das Asset-Inventar.
Informationen werden anhand ihres Schutzbedarfs klassifiziert und entsprechend behandelt.
Die Klassifizierung beeinflusst insbesondere:
Vor einer externen Weitergabe werden Empfänger, Zweck, Berechtigung, Übertragungsweg und erforderliche Vereinbarungen geprüft. Einzelheiten regelt die Informationsklassifizierung.
Zugriffe auf Informationen, Systeme, Räume und Dienste werden nach geschäftlicher Erforderlichkeit und Schutzbedarf gesteuert.
Mindestens gelten folgende Regeln:
Die operative Steuerung erfolgt über die Regelung Zugriff und Berechtigungen. Eine Rollenbeschreibung oder technische Kontenliste allein gilt nicht als Nachweis für angemessene und wirksame Berechtigungen.
Informationssicherheit wird über den gesamten Beschäftigungs- und Beauftragungszyklus berücksichtigt:
Personenbezogene Prüf- und Nachweisdaten werden zweckgebunden, angemessen geschützt und nicht unnötig im allgemeinen Wiki veröffentlicht.
Standorte, Räume und physische Assets werden entsprechend Schutzbedarf und Risiken geschützt.
Hierzu gehören:
Besondere Kunden- oder Prototypenschutzanforderungen werden in den betroffenen Bereichen zusätzlich umgesetzt.
Die operative Ausgestaltung erfolgt in der Regelung Physische Sicherheit. Eine Richtlinienbeschreibung allein gilt nicht als Nachweis der tatsächlichen Umsetzung oder Wirksamkeit.
IT- und OT-Systeme werden nach dokumentierten Betriebs- und Sicherheitsanforderungen betrieben.
Mindestens werden risikobasiert geregelt:
OT- und Produktionsanforderungen werden unter Berücksichtigung von Sicherheit, Anlagenverfügbarkeit, Herstellerbedingungen und zulässigen Wartungsfenstern behandelt. Ein Produktionsbedarf rechtfertigt keine undokumentierte Dauerabweichung.
Technische Schwachstellen und Änderungen werden risikobasiert gesteuert.
Erforderlich sind:
Änderungen dürfen Sicherheitskontrollen nicht unbemerkt deaktivieren oder Nachweise unbrauchbar machen.
Die operativen Betriebs- und Change-Abläufe werden in IT-Betrieb und Änderungen festgelegt. Erkennung, Priorisierung, Behandlung, Ausnahmen und Wirksamkeitsprüfung technischer Schwachstellen werden in Schwachstellen- und Patchmanagement vertieft. Ein Change-Ticket oder eine Herstellerfreigabe allein gilt nicht als Nachweis einer sicheren und wirksamen Änderung.
Netzwerke und Kommunikationsverbindungen werden nach Schutzbedarf, Geschäftszweck und Risiko gestaltet und betrieben.
Hierzu gehören:
Kryptografische Verfahren werden eingesetzt, wenn Schutzbedarf, Risiko oder Anforderungen dies verlangen.
Auswahl und Betrieb berücksichtigen:
Selbst entwickelte oder ungeprüfte kryptografische Verfahren werden nicht produktiv eingesetzt.
Die operative Ausgestaltung erfolgt in der Regelung Kryptografie und Schlüssel. Konkrete Algorithmen, Schlüssellängen und Protokollparameter werden in einer regelmäßig überprüften technischen Baseline geführt.
Kritische Informationen, Systeme und Prozesse werden gegen Verlust und Ausfall geschützt.
Die Organisation:
Eine erfolgreiche Sicherung ohne geprüfte Wiederherstellbarkeit ist kein ausreichender Wirksamkeitsnachweis.
Mitgeltend sind:
Verdächtige Beobachtungen, Schwachstellen und Sicherheitsereignisse werden unverzüglich über den festgelegten Meldeweg gemeldet.
Die Behandlung umfasst risikobasiert:
Meldende Personen sollen keine eigenmächtigen Untersuchungen durchführen, Spuren löschen oder vertrauliche Vorfalldaten unkontrolliert weitergeben.
Maßgeblich sind:
Informationssicherheitsrisiken externer Leistungen werden über den gesamten Lebenszyklus gesteuert:
Auslagerung überträgt nicht die Verantwortung der Organisation für eigene Risiken, Anforderungen und Kundenverpflichtungen.
Informationssicherheit wird in Projekte, Beschaffungen und wesentliche Änderungen integriert.
Vor Freigabe oder Inbetriebnahme werden angemessen geprüft:
Eine Projektfreigabe ersetzt keine erforderliche Sicherheits-, Datenschutz- oder Betriebsfreigabe.
Bei Entwicklung oder Beschaffung von Systemen und Anwendungen werden Sicherheitsanforderungen über den Lebenszyklus berücksichtigt.
Dazu gehören abhängig vom Risiko:
Die operative Ausgestaltung erfolgt in Sichere Entwicklung. Das Dokument oder ein bestandener Einzeltest belegt ohne nachvollziehbare Anforderungen, Releases, Befundbehandlung und Produktivverifikation keine wirksame Umsetzung.
Cloud- und externe Verarbeitungsdienste dürfen nur nach geregelter Bewertung und Freigabe eingesetzt werden.
Die Detailanforderungen an Cloud-Freigabe, Shared Responsibility, Konfiguration, Notbetrieb und Exit stehen in Mobile Arbeit und Cloud.
Mindestens werden geprüft:
Die Freigabe eines Dienstes gilt nur für den bewerteten Scope und die genehmigte Nutzungsart.
Mobile Arbeit und mobile Geräte werden entsprechend Schutzbedarf und Risiko geregelt.
Zulässige Arbeitsorte, Geräte, Fernzugriffe, Verlustbehandlung und Cloud-Nutzung werden in Mobile Arbeit und Cloud konkretisiert.
Insbesondere gelten:
Sicherheitsrelevante Ereignisse werden im erforderlichen und zulässigen Umfang protokolliert und ausgewertet.
Dabei werden:
Protokolle werden nicht für unvereinbare Zwecke verwendet und nur berechtigten Rollen zugänglich gemacht.
ISMS-Dokumente und Nachweise werden nach der Dokumentenlenkung erstellt, geprüft, freigegeben, geändert und archiviert.
Dabei gilt:
Die Dokumentenvorlagen unterstützen eine einheitliche Struktur.
Die Auswahl und Umsetzung von ISO-27001-Annex-A-Maßnahmen wird im Statement of Applicability dokumentiert.
Dabei gilt:
Für das TISAX-Assessment und die VDA-ISA-Selbsteinschätzung gilt:
Die offizielle ISA-Arbeitsmappe bleibt für Kontrollumfang, Bewertungslogik und Ergebnis maßgeblich.
Mitgeltend sind:
Ausnahmen von Sicherheitsvorgaben:
Gesetzliche, behördliche, vertragliche und Kundenpflichten können nicht durch eine interne Ausnahme aufgehoben werden. Das Verfahren ist unter Ausnahmen und Risikoakzeptanzen geregelt.
Alle Personen erhalten vor oder mit Übernahme ihrer Aufgaben angemessene Informationen, Unterweisungen und Schulungen.
Das Programm berücksichtigt:
Teilnahme allein belegt nicht, dass Anforderungen verstanden und wirksam angewendet werden. Wirkung wird durch geeignete Übungen, Tests, Stichproben oder Verhaltensindikatoren bewertet.
Beschäftigte und externe Personen sollen erkennbare:
unverzüglich über die festgelegten Wege melden.
Gutgläubige Meldungen werden unterstützt. Meldungen werden vertraulich, fair und ohne vorschnelle Schuldzuweisung behandelt. Vorsätzliche Falschmeldungen oder bewusste Verstöße können nach den geltenden rechtlichen und vertraglichen Regeln behandelt werden.
Die Umsetzung dieser Politik wird unter anderem bewertet durch:
| Prüffeld | mögliche Methode | Nachweis |
|---|---|---|
| Informationssicherheitsziele | Soll-Ist-Vergleich und Trend | Zielregister und Managementbericht |
| Risiken und Maßnahmen | Review von Restrisiken, Terminen und Wirkung | Risikoregister und Behandlungsplan |
| Berechtigungen | Stichproben und Rezertifizierung | Prüfprotokoll |
| Schwachstellen und Änderungen | Frist-, Risiko- und Ausnahmenauswertung | Tickets und technische Berichte |
| Vorfälle | Anzahl, Schwere, Reaktionszeit und Ursachen | Incident-Berichte |
| Lieferanten | Leistungs-, Risiko- und Nachweisreview | Lieferantenbewertung |
| Kontinuität | Übungen und Wiederherstellungstests | Test- und Übungsberichte |
| Awareness | Teilnahme, Lernerfolg und Verhaltensindikatoren | Schulungsnachweise |
| Compliance | Kontrollen, Rechtsreview und Audits | Prüf- und Auditberichte |
| TISAX | Reifegrad und Nachweisqualität je Kontrollfrage | ISA-Selbsteinschätzung |
Kennzahlen, Formeln, Zielwerte und Datenquellen werden vor Verwendung freigegeben. Fehlende oder unzuverlässige Daten werden als „nicht bewertbar“ und nicht als positives Ergebnis dargestellt.
Das ISMS wird durch geplante, risikobasierte und objektive Audits bewertet.
Festgestellte Abweichungen:
Die Steuerung erfolgt über:
Die Geschäftsführung bewertet das ISMS regelmäßig und anlassbezogen. Eingaben umfassen insbesondere:
Entscheidungen, Ressourcen, Verantwortlichkeiten und Termine werden nachvollziehbar dokumentiert. Die Seite Managementbewertung bildet den zentralen Nachweisrahmen.
Nach Freigabe wird die Politik:
Interne Sicherheitsdetails, Schwachstellen, personenbezogene Informationen oder vertrauliche Nachweise werden nicht in einer externen Fassung veröffentlicht.
Kommunikation und erforderliche Kenntnisnahmen werden angemessen nachgewiesen.
Verstöße werden sachlich, risikobasiert und unter Beachtung der geltenden rechtlichen, arbeitsrechtlichen und vertraglichen Regeln behandelt.
Mögliche Reaktionen sind:
Fachliche Sicherheitsrollen entscheiden nicht eigenständig über arbeitsrechtliche Sanktionen.
Diese Politik wird mindestens jährlich sowie anlassbezogen geprüft.
Anlässe sind insbesondere:
Wesentliche Änderungen werden fachlich geprüft, erneut freigegeben und den betroffenen Personen mitgeteilt.
| Thema | Dokument |
|---|---|
| Managementrahmen | Informationssicherheitsleitlinie |
| ISMS-Scope | Geltungsbereich und Standorte |
| Kontext und Anforderungen | Kontext und interessierte Parteien |
| Rollen | Rollen und Verantwortlichkeiten |
| Ziele | Informationssicherheitsziele |
| Dokumentensteuerung | Dokumentenlenkung |
| Risiken | Methodik der Risikobewertung |
| ISO-Anwendbarkeit | Statement of Applicability |
| Compliance | Rechts- und Vertragskataster |
| Ausnahmen | Ausnahmen und Risikoakzeptanzen |
| Assets | Asset-Inventar |
| Klassifizierung | Informationsklassifizierung |
| Vorfälle | Incident Response |
| Kontinuität | Notfallvorsorge und BCM |
| TISAX | VDA-ISA-Selbsteinschätzung |
| Audit | Auditprogramm |
| Verbesserung | Abweichungen und Korrekturmaßnahmen |
| Vorlagen | Dokumentenvorlagen |
| Nachweis | Mindestinhalt |
|---|---|
| fachliche Prüfung | Version, Prüfumfang, prüfende Rollen, Ergebnis und offene Punkte |
| Freigabe | eindeutige Version, befugte Rolle, Datum, Gültigkeit und Auflagen |
| Kommunikation | Zielgruppe, Inhalt, Datum und erforderliche Kenntnisnahme |
| Schulung | Zielgruppe, Lerninhalt, Teilnahme und angemessene Wirksamkeitsbewertung |
| Regelprüfung | Scope, Quellen, Ergebnis, Änderungen und nächster Termin |
| Kontrollen | Prüfmethode, Stichprobe, Ergebnis, Abweichung und Maßnahme |
| Managementbewertung | bewertete Eingaben, Entscheidungen, Ressourcen, Owner und Termine |
Eine Wiki.js-Seitenhistorie, ein Kommentar oder eine Checkbox ist nur dann als Nachweis geeignet, wenn Version, Rolle, Inhalt, Zeitpunkt und Ergebnis verlässlich zugeordnet und gegen unbemerkte Änderung geschützt sind.
| Prüffrage | Status Entwurf |
|---|---|
| Ist das Verhältnis zwischen Leitlinie, Politik und Themenregelungen freigegeben? | Nein |
| Sind Geltungsbereich und Zielgruppen organisationsbezogen bestätigt? | Nein |
| Sind Rollen, Befugnisse und Stellvertretungen operationalisiert? | Nein |
| Sind alle gesetzlichen, vertraglichen und Kundenanforderungen bewertet? | Nein |
| Sind die geforderten Sicherheitsprozesse praktisch eingerichtet? | Nicht vollständig bewertet |
| Sind themenspezifische Richtlinien und Verfahren vorhanden und konsistent? | Teilweise; Gesamtprüfung offen |
| Sind Kontrollen, Kennzahlen und Wirksamkeitsnachweise festgelegt? | Nicht vollständig |
| Sind alle 46 TISAX-Informationssicherheitsfragen bewertet? | Nein |
| Sind Kommunikation und Schulung vorbereitet? | Nein |
| Liegen fachliche Prüfung und Geschäftsführungsfreigabe vor? | Nein |
Das Vorhandensein dieser Politik darf nicht als Nachweis einer vollständigen Umsetzung oder Wirksamkeit verwendet werden.
Mit ihrer dokumentierten Freigabe setzt die Geschäftsführung diese Informationssicherheitspolitik für den festgelegten Geltungsbereich in Kraft.
| Freigabefunktion | Name | Datum | Entscheidung | Nachweisreferenz |
|---|---|---|---|---|
| Geschäftsführung | [Name] |
[TT.MM.JJJJ] |
Ausstehend | [geschützter Pfad] |
Aktueller Freigabestatus: Entwurf – eine formale Freigabe liegt nicht vor.
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Musterpolitik für Informationssicherheit erstellt | ISMS-Beauftragte/r | Ausstehend | – |
Für dieses Beispiel wird der dokumentierte Arbeitsstand ISA 6.0.3 verwendet. Vor der Freigabe sind die tatsächlich anzuwendende ISA-Version, der ISMS- und Assessment-Scope sowie die organisationsbezogene Umsetzung aller Anforderungen zu bestätigen.