| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-WIKI-02 |
| Dokumentenart | Lesehilfe / Verfahrensbeschreibung |
| Verantwortlich | ISMS-Beauftragte/r |
| Fachlich geprüft durch | Qualitätsmanagement und IT-Leitung |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf |
| Version | 0.1 |
| Stand | 23.07.2026 |
| Gültig ab | Nach Freigabe |
| Nächste Prüfung | Spätestens zwölf Monate nach Freigabe |
| Schutzklasse | Intern |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere dokumentierte Information nach Kapitel 7.5 |
| TISAX-Bezug | Dokumentation, Nachvollziehbarkeit und Wirksamkeitsnachweise |
Diese Seite erklärt den Aufbau und die Nutzung des ISMS-Wikis. Sie beschreibt:
Die Lesehilfe gilt für alle gelenkten ISMS-Dokumente, Register, Berichte, Vorlagen und Nachweise im Wiki.
Das Wiki ist die zentrale Informations- und Navigationsstelle für das Informationssicherheitsmanagementsystem. Es enthält verbindliche Regelungen, aktuelle Arbeitsstände, Verweise auf Register sowie Links zu geschützten Nachweisen.
Dabei gelten folgende Grundsätze:
| Bereich | Inhalt |
|---|---|
| Start und Navigation | Einstieg, Geltungsbereich, Lesehilfe und Mapping |
| Führung und Steuerung | Leitlinien, Rollen, Ziele und Dokumentenlenkung |
| Risiken und Compliance | Risiken, SoA, Rechtsanforderungen und Ausnahmen |
| Organisation und Assets | Prozesse, Informationen, Systeme, Personal und Lieferanten |
| Sicherheitsregelungen | Verbindliche organisatorische und technische Regelungen |
| Vorfälle und Notfälle | Meldung, Reaktion, Notfallvorsorge und Wiederanlauf |
| TISAX | Assessment Scope, Bewertungsziele und Selbsteinschätzung |
| Nachweise | Durchführungs- und Wirksamkeitsnachweise |
| Audit und Verbesserung | Audits, Maßnahmen, Kennzahlen und Managementbewertung |
| Vorlagen und Archiv | Arbeitsvorlagen und ersetzte Dokumentstände |
Interne Wiki.js-Links beginnen mit einem führenden Schrägstrich und enthalten keinen Sprachpräfix:
[Geltungsbereich und Standorte](/ISMS/00-Start-und-Navigation/Geltungsbereich-und-Standorte)
Links werden auf die führende Wiki-Seite gesetzt. Anhänge, Nachweisdateien und externe Dokumente werden eindeutig als solche bezeichnet.
Für die Suche eignen sich insbesondere:
Titel und Schlagwörter sollen einheitlich und ohne unnötige Abkürzungen verwendet werden.
| Dokumentenart | Zweck | Beispiel | Verbindlichkeit |
|---|---|---|---|
| Leitlinie | Grundsätze und Verpflichtung der Leitung | Informationssicherheitsleitlinie | Nach Freigabe verbindlich |
| Policy/Richtlinie | Verbindliche thematische Vorgaben | Richtlinie zur Zugriffskontrolle | Nach Freigabe verbindlich |
| Verfahren/Maßnahme | Rollen und konkreter Ablauf | Berechtigungsvergabe | Nach Freigabe verbindlich |
| Register | Aktueller strukturierter Bestand | Asset- oder Risikoregister | Freigegebener Stand maßgeblich |
| Bericht | Bewertung eines Zeitraums oder Ereignisses | Auditbericht | Nach Abschluss und Freigabe gültig |
| Nachweis | Belegt die tatsächliche Durchführung | Restore-Testprotokoll | Nach Prüfung als Nachweis verwendbar |
| Vorlage | Noch nicht ausgefülltes Arbeitsmittel | Lieferantencheckliste | Nicht selbst als Nachweis geeignet |
| Arbeitsstand | Vorläufige Bearbeitung | Maßnahmenentwurf | Nicht verbindlich |
| Externes Dokument | Anforderung oder Information Dritter | Vertrag, Norm oder Kundenanforderung | Nach jeweiliger Rechts-/Vertragslage |
Jede gelenkte Seite enthält einen Metadatenblock. Die Felder haben folgende Bedeutung:
| Feld | Bedeutung |
|---|---|
| Dokumenten-ID | Eindeutige Kennzeichnung des Dokuments |
| Dokumentenart | Art und Zweck der Seite |
| Verantwortlich | Rolle für Inhalt und regelmäßige Prüfung |
| Fachlich geprüft durch | Rolle, die Inhalt und Umsetzbarkeit bewertet |
| Freigabe durch | Rolle mit formaler Freigabebefugnis |
| Status | Aktueller Stand im Dokumentenlebenszyklus |
| Version | Eindeutiger Bearbeitungs- oder Freigabestand |
| Stand | Datum der letzten inhaltlichen Änderung |
| Gültig ab | Beginn der verbindlichen Anwendung |
| Nächste Prüfung | Spätester Termin für die erneute Bewertung |
| Schutzklasse | Vorgabe für Zugriff, Weitergabe und Speicherung |
| ISO-Bezug | Zuordnung zum ISO-27001-Managementsystem |
| TISAX-/VDA-ISA-Bezug | Zuordnung zum Assessment und den anwendbaren Kriterien |
Fehlende Pflichtangaben werden als offener Punkt behandelt und vor der Freigabe ergänzt.
| Status | Bedeutung | Darf angewendet werden? | Erforderliche Aktion |
|---|---|---|---|
| Entwurf | Inhalt wird erstellt oder grundlegend überarbeitet | Nein, nur zur Abstimmung | Bearbeiten und fachlich prüfen |
| In Prüfung | Entwurf liegt den benannten Prüfern vor | Noch nicht als verbindliche Regelung | Prüfung dokumentieren |
| Freigegeben | Inhalt wurde geprüft und formal genehmigt | Ja, ab dem angegebenen Gültigkeitsdatum | Anwenden und regelmäßig überprüfen |
| Überarbeitung erforderlich | Inhalt ist teilweise veraltet oder weist eine wesentliche Lücke auf | Nur nach dokumentierter Bewertung | Risiko bewerten und Überarbeitung terminieren |
| Gesperrt | Inhalt darf vorübergehend nicht angewendet werden | Nein | Ursache klären und Ersatzregelung benennen |
| Archiviert | Dokument wurde durch einen neueren Stand ersetzt oder außer Kraft gesetzt | Nein | Nur als historischer Nachweis verwenden |
Ein Dokument ist nur dann verbindlich, wenn:
Ein farbiger Hinweis, ein gesetztes Kontrollkästchen oder der technische Veröffentlichungsstatus in Wiki.js genügt allein nicht als Freigabenachweis.
Wurde das nächste Prüfdatum überschritten, ist das Dokument nicht automatisch unwirksam. Die dokumentenverantwortliche Person muss jedoch unverzüglich:
Bei wesentlichen Zweifeln erhält die Seite den Status „Überarbeitung erforderlich“ oder „Gesperrt“.
Der Status eines Dokuments ist vom Bearbeitungsstatus einzelner Maßnahmen, Risiken oder Auditfeststellungen zu unterscheiden.
| Fachstatus | Bedeutung |
|---|---|
| Offen | Noch nicht begonnen oder entschieden |
| In Bearbeitung | Umsetzung wurde begonnen |
| Zur Wirksamkeitsprüfung | Umsetzung gemeldet, Wirksamkeit noch nicht bestätigt |
| Wirksam abgeschlossen | Umsetzung und Wirksamkeit wurden nachgewiesen |
| Risiko akzeptiert | Restrisiko wurde durch eine befugte Stelle befristet oder dauerhaft akzeptiert |
| Überfällig | Zieltermin wurde ohne wirksamen Abschluss überschritten |
| Nicht anwendbar | Begründete und freigegebene Nichtanwendbarkeit |
„Umgesetzt“ oder „Abgeschlossen“ ist nicht gleichbedeutend mit „wirksam“. Ein wirksamer Abschluss benötigt einen geeigneten Nachweis und eine nachvollziehbare Prüfung.
| Änderung | Beispiel | Bedeutung |
|---|---|---|
| Entwurfsstand | 0.1, 0.2 | Noch nicht freigegebene Bearbeitung |
| Hauptversion | 1.0, 2.0 | Erstfreigabe oder wesentliche inhaltliche Änderung |
| Nebenversion | 1.1, 1.2 | Begrenzte inhaltliche Ergänzung oder Korrektur |
| Redaktionelle Korrektur | Nach interner Festlegung | Keine Änderung der verbindlichen Aussage |
Jede Änderung wird in der Änderungshistorie mit Datum, Anlass und verantwortlicher Person dokumentiert.
Eine erneute fachliche Prüfung und Freigabe ist insbesondere erforderlich bei:
| Schritt | Verantwortung | Ergebnis/Nachweis |
|---|---|---|
| Dokument erstellen oder ändern | Dokumentenverantwortliche Person | Entwurf und Änderungshistorie |
| Inhalt fachlich prüfen | Benannte fachliche Prüfstelle | Prüfvermerk oder dokumentierte Rückmeldung |
| Schnittstellen prüfen | Betroffene Prozess-/Systemverantwortliche | Bestätigung oder offene Punkte |
| Freigabe entscheiden | Benannte Freigabestelle | Freigabe mit Name/Rolle und Datum |
| Veröffentlichen | Wiki-Administration oder Dokumentenverantwortliche | Freigegebene Wiki-Seite |
| Betroffene informieren | Dokumentenverantwortliche Person | Kommunikations- oder Schulungsnachweis |
| Wirksamkeit überwachen | Prozess- und ISMS-Verantwortliche | Kennzahl, Stichprobe, Audit oder Test |
Offene fachliche Widersprüche dürfen nicht durch eine rein technische Veröffentlichung übergangen werden.
Werden widersprüchliche Aussagen festgestellt, gilt nicht automatisch die zuletzt bearbeitete Wiki-Seite. Folgende Reihenfolge ist zu prüfen:
Bei einem Widerspruch sind:
Widersprüche, fehlende Nachweise und nicht erreichte Ziele bleiben bis zur Klärung sichtbar.
| Schutzklasse | Beispielinhalt | Grundsatz |
|---|---|---|
| Öffentlich | Freigegebene Außendarstellung | Veröffentlichung nach Freigabe |
| Intern | Allgemeine Richtlinien und Prozessbeschreibungen | Zugriff für berechtigte Beschäftigte |
| Vertraulich | Risiken, Verträge, detaillierte Systeminformationen | Zugriff nach Aufgabe und Need-to-know |
| Streng vertraulich | Kritische Schwachstellen, Schlüsselmaterial, Prototypdetails | Stark eingeschränkter, protokollierter Zugriff |
Die konkrete Klassifizierung richtet sich nach der Informationsklassifizierung.
Wiki-Berechtigungen werden nach Rollen vergeben. Die technische Administration begründet keine automatische fachliche Leseberechtigung für vertrauliche Inhalte.
Ein Nachweis muss mindestens erkennen lassen:
Personenbezogene, kundenbezogene oder sicherheitskritische Nachweise werden nicht ungeschützt auf allgemein lesbaren Wiki-Seiten abgelegt. Die Wiki-Seite kann stattdessen einen kontrollierten Verweis auf die geschützte Ablage enthalten.
Eine leere Vorlage oder ein geplanter Termin ist kein Durchführungsnachweis.
Externe Dokumente wie Normen, Gesetze, Kundenanforderungen, Verträge und Herstellerinformationen werden mit Quelle, Version beziehungsweise Stand und Verantwortlichkeit erfasst.
| Prüfaspekt | Anforderung |
|---|---|
| Quelle | Offizielle oder vertraglich maßgebliche Quelle |
| Aktualität | Version oder Abrufstand dokumentieren |
| Anwendbarkeit | Bezug zum Unternehmen oder ISMS bewerten |
| Zugriff | Berechtigung und gegebenenfalls Lizenz beachten |
| Änderung | Auswirkungen auf Dokumente, Risiken und Maßnahmen prüfen |
Normtexte und lizenzpflichtige Kataloge werden nicht vollständig in das Wiki kopiert. Stattdessen werden die eigenen Regelungen und die erforderlichen Zuordnungen dokumentiert.
Fehler, veraltete Inhalte, defekte Links und Verbesserungsvorschläge werden an die dokumentenverantwortliche Person oder das ISMS-Team gemeldet.
Die Meldung sollte enthalten:
Bei einem möglichen Sicherheitsrisiko ist zusätzlich der Meldeweg für Sicherheitsvorfälle zu verwenden.
Vor einer Freigabe wird mindestens geprüft:
| Prüffrage | Mindestanforderung |
|---|---|
| Ist der Titel eindeutig? | Genau eine Hauptüberschrift und ein eindeutiger Dokumententitel |
| Ist der Status nachvollziehbar? | Status, Version, Stand, Verantwortung und Freigabe sind angegeben |
| Ist der Inhalt vollständig? | Zweck, Geltungsbereich, Rollen, Regelungen und Nachweise sind beschrieben |
| Funktionieren die Links? | Interne und externe Verweise wurden geprüft |
| Stimmen Tabellen und Angaben überein? | Keine widersprüchlichen Werte oder fehlerhaften Tabellen |
| Sind offene Punkte sichtbar? | Lücken sind benannt, bewertet und terminiert |
| Ist die Schutzklasse angemessen? | Zugriff und Inhalt passen zur Klassifizierung |
| Wurde die Änderung dokumentiert? | Änderungshistorie ist aktualisiert |
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Beispieldokument angelegt | ISMS-Beauftragte/r | Ausstehend | – |