Verbindlichkeitsregel: Ein Dokument ist erst verbindlich, wenn es fachlich geprüft, durch die befugte Rolle freigegeben, eindeutig versioniert, mit einem Gültigkeitsdatum versehen und in der freigegebenen Fassung verfügbar ist.
Wiki.js-Regel: Speichern, Bearbeiten oder technisch „Veröffentlichen“ in Wiki.js ist keine formale Freigabe. Auch Seitenhistorie, farbige Hinweise, Tags oder Kontrollkästchen ersetzen keinen nachvollziehbaren Freigabenachweis.
Beispieldokument: Rollen, Workflows, Fristen, Berechtigungen und Ablagen sind als Muster für die „Muster GmbH“ angelegt. Sie müssen vor der Freigabe an die tatsächliche Organisation und Wiki.js-Konfiguration angepasst und getestet werden.
| Feld | Wert |
|---|---|
| Dokumenten-ID | ISMS-MA-01-01 |
| Dokumentenart | Verfahren zur Dokumenten- und Nachweislenkung |
| Wiki.js-Pfad | /ISMS/01-Fuehrung-und-Steuerung/Dokumentenlenkung |
| Verantwortlich | ISMS-Beauftragte/r |
| Fachlich geprüft durch | Dokumenten-Owner, Prozessverantwortliche, Qualitätsmanagement, IT/Wiki-Administration und Datenschutz |
| Freigabe durch | Geschäftsführung |
| Status | Entwurf – Workflow, Berechtigungen und Freigaben nicht operationalisiert |
| 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 |
| ISO-Bezug | ISO/IEC 27001:2022, insbesondere Kapitel 7.5, 9.1 und 10 sowie Annex A 5.1 und 5.37 |
| VDA-ISA-Bezug | ISA 6.0.3; dokumentierte Informationen und Nachweise über alle betroffenen Fragen |
Dieses Verfahren regelt den gesamten Lebenszyklus dokumentierter Informationen im ISMS:
Ziel ist, dass relevante Personen zur richtigen Zeit auf die richtige, gültige und angemessen geschützte Information zugreifen können.
Das Verfahren gilt für:
Es gilt unabhängig davon, ob Informationen:
geführt werden.
| Begriff | Zweck |
|---|---|
| Dokumentenlenkung | stellt richtige Erstellung, Prüfung, Freigabe, Verteilung, Änderung und Archivierung sicher |
| Aufzeichnungs-/Nachweislenkung | schützt Ergebnisse tatsächlich durchgeführter Tätigkeiten vor unzulässiger Veränderung oder Verlust |
| Informationsklassifizierung | bestimmt Schutz bei Zugriff, Speicherung, Weitergabe und Löschung |
| Wissensmanagement | macht erforderliches Wissen verfügbar und erhält es |
| Konfigurations-/Change Management | steuert technische oder operative Änderungen |
Die Verfahren wirken zusammen. Eine technische Änderung kann beispielsweise gleichzeitig eine Anpassung gelenkter Dokumente und neue Nachweise erfordern.
| Dokumentenart | Zweck | Beispiel | Verbindlichkeit |
|---|---|---|---|
| Leitlinie | Grundsätze und Verpflichtung der Leitung | Informationssicherheitsleitlinie | nach Freigabe verbindlich |
| Policy/Richtlinie | thematische Vorgaben | Informationsklassifizierung | nach Freigabe verbindlich |
| Verfahren/Maßnahme | Rollen und konkreter Ablauf | Risikobewertung oder Incident Response | nach Freigabe verbindlich |
| Arbeitsanweisung | konkrete ausführbare Tätigkeit | Wiederanlauf-Runbook | nach Freigabe verbindlich |
| Register | aktueller strukturierter Bestand | Asset-, Risiko- oder Rollenregister | freigegebener beziehungsweise gelenkter Stand maßgeblich |
| Plan | zukünftige Maßnahmen und Ressourcen | Audit- oder Maßnahmenplan | nach Freigabe als Plan verbindlich |
| Bericht | Bewertung eines Zeitraums oder Ereignisses | Auditbericht oder Managementbewertung | nach Abschluss und Freigabe gültig |
| Nachweis/Aufzeichnung | belegt tatsächliche Durchführung | Restore-Test- oder Schulungsnachweis | nach Prüfung als Nachweis verwendbar |
| Vorlage | unausgefülltes Arbeitsmittel | Lieferantencheckliste | nicht selbst als Nachweis geeignet |
| Arbeitsstand | vorläufige Bearbeitung | Maßnahmenentwurf | nicht verbindlich |
| externes Dokument | Anforderung oder Information Dritter | Norm, Gesetz, Vertrag oder Kundenanforderung | nach maßgeblicher Rechts-/Vertragslage |
| Rolle | Verantwortung |
|---|---|
| Geschäftsführung | Leitlinien, wesentliche Verfahren und Befugnisrahmen freigeben |
| Dokumenten-Owner | fachlichen Inhalt, Aktualität, Review, Änderungen und Kommunikation verantworten |
| Dokumentenpflege/Autor | Entwurf, Metadaten, Verlinkung und Änderungshistorie pflegen |
| fachlich Prüfende | Richtigkeit, Vollständigkeit, Umsetzbarkeit und Anforderungen bewerten |
| Schnittstellenprüfende | Auswirkungen auf Prozesse, Systeme, Risiken, Verträge und andere Dokumente prüfen |
| freigebende Rolle | Verbindlichkeit im festgelegten Befugnisrahmen entscheiden |
| ISMS-Beauftragte/r | Methodik, Register, Fälligkeiten, Konsistenz und Eskalationen koordinieren |
| Wiki-Administration | Technik, Rechte, Backup und Verfügbarkeit betreiben; keine automatische Fachfreigabe |
| Nachweis-Owner | Schutz, Vollständigkeit, Aufbewahrung und Auffindbarkeit von Aufzeichnungen sicherstellen |
| Nutzende | gültige Fassung anwenden und Fehler beziehungsweise Widersprüche melden |
| Auditfunktion | Dokumentenlenkung und ausgewählte Nachweise objektiv prüfen |
Die Rollen und Verantwortlichkeiten legen das übergeordnete Befugnismodell fest.
Alle gelenkten Dokumente werden in einem Register geführt.
| Pflichtfeld | Beschreibung |
|---|---|
| Dokumenten-ID | eindeutige Kennzeichnung |
| Titel | verständliche Bezeichnung |
| Dokumentenart | Leitlinie, Verfahren, Register, Bericht und weitere |
| Wiki.js-Pfad/Ablage | führende Fassung |
| Dokumenten-Owner | fachliche Ergebnisverantwortung |
| fachlich Prüfende | bestätigte Prüffunktionen |
| freigebende Rolle | Befugnis zur Freigabe |
| Status | aktueller Dokumentenlebenszyklus |
| Version | eindeutiger Bearbeitungs-/Freigabestand |
| Stand/Gültigkeit | Änderungsdatum und Beginn der Anwendung |
| nächste Prüfung | spätester Reviewtermin |
| Schutzklasse | Zugriff und Handhabung |
| ISO-/ISA-Bezug | Anforderungen und Mapping |
| ersetzte/ersetzende Fassung | historische Verknüpfung |
| Nachweise | Prüf-, Freigabe- und Kommunikationsreferenzen |
| Dokumenten-ID | Titel | Owner | Status | Version | gültig ab | nächste Prüfung | Schutzklasse | führender Pfad | Freigabenachweis |
|---|---|---|---|---|---|---|---|---|---|
[ISMS-XXX] |
[Titel] |
[Rolle] |
[Status] |
[Version] |
[Datum] |
[Datum] |
[Klasse] |
[Link] |
[Referenz] |
| Präfix | Verwendung |
|---|---|
| ISMS-LT | Leitlinie |
| ISMS-RL | Richtlinie/Policy |
| ISMS-MA | Maßnahme, Methode oder Verfahren |
| ISMS-REG | Register |
| ISMS-PLAN | Plan |
| ISMS-BER | Bericht |
| ISMS-NW | Nachweis/Aufzeichnung |
| ISMS-VOR | Vorlage |
| TISAX-REG | TISAX-spezifisches Register |
| TISAX-MA | TISAX-spezifische Maßnahme/Verfahren |
Beispiel:
ISMS-MA-01-01
Nummernbereiche und Vergabe werden zentral gepflegt. Eine einmal vergebene Dokumenten-ID wird nach Archivierung nicht für einen anderen Inhalt erneut verwendet.
Jede gelenkte Wiki-Seite enthält mindestens:
| Feld | Bedeutung |
|---|---|
| Dokumenten-ID | eindeutige Kennzeichnung |
| Dokumentenart | Art und Zweck |
| Wiki.js-Pfad | führende Seite |
| Verantwortlich | Dokumenten-Owner |
| fachlich geprüft durch | Prüffunktion |
| Freigabe durch | befugte Freigabestelle |
| Status | Dokumentenlebenszyklus |
| Version | eindeutiger Stand |
| Stand | Datum der letzten inhaltlichen Änderung |
| Gültig ab | Beginn der verbindlichen Anwendung |
| nächste Prüfung | spätester Reviewtermin |
| Schutzklasse | Handhabungs- und Zugriffsvorgabe |
| ISO-Bezug | Zuordnung zu ISO/IEC 27001 |
| VDA-ISA-Bezug | verwendete ISA-Version und Themenbezug |
Je nach Dokumentenart werden ergänzt:
Fehlende Pflichtmetadaten werden vor Freigabe ergänzt oder als dokumentierter Sonderfall entschieden.
| Status | Bedeutung | verbindlich anwendbar? | erforderliche Aktion |
|---|---|---|---|
| Entwurf | Inhalt wird erstellt oder wesentlich überarbeitet | Nein | bearbeiten und zur Prüfung vorbereiten |
| In Prüfung | benannte Prüffunktionen bewerten den Entwurf | Nein | Rückmeldungen und Entscheidung dokumentieren |
| Freigegeben | formal geprüft und genehmigt | Ja, ab Gültigkeitsdatum | anwenden, kommunizieren und regelmäßig prü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, Ersatzregel und Kommunikation festlegen |
| Archiviert | ersetzt oder außer Kraft gesetzt | Nein | nur als historischer Nachweis verwenden |
Ein Dokument ist nur verbindlich, wenn:
Der Dokumentenstatus ist vom Status enthaltener Risiken, Maßnahmen oder Feststellungen zu unterscheiden.
| Fachstatus | Bedeutung |
|---|---|
| Offen | noch nicht begonnen oder entschieden |
| In Bearbeitung | Umsetzung wurde begonnen |
| Zur Wirksamkeitsprüfung | Umsetzung gemeldet, Wirkung noch nicht bestätigt |
| Wirksam abgeschlossen | Umsetzung und Wirksamkeit sind nachgewiesen |
| Risiko akzeptiert | Restrisiko wurde durch befugte Rolle entschieden |
| Überfällig | Zieltermin ohne wirksamen Abschluss überschritten |
| Nicht anwendbar | begründete und freigegebene fachliche Nichtanwendbarkeit |
Ein freigegebenes Risikoregister kann offene oder überfällige Risiken enthalten. Umgekehrt wird eine Maßnahme nicht allein durch die Freigabe des Dokuments wirksam.
| Version | Bedeutung |
|---|---|
| 0.1, 0.2, 0.x | nicht freigegebene Entwurfsstände |
| 1.0 | erste freigegebene Hauptversion |
| 1.1, 1.2 | begrenzte inhaltliche Ergänzung oder Korrektur |
| 2.0, 3.0 | wesentliche Änderung mit erneuter vollständiger Freigabe |
Redaktionelle Korrekturen ohne Bedeutungsänderung werden nach einer freigegebenen Regel dokumentiert. Sie dürfen nicht genutzt werden, um eine inhaltliche Änderung ohne Prüfung einzuführen.
Eine erneute fachliche Prüfung und Freigabe ist insbesondere erforderlich bei:
Jede gelenkte Seite enthält eine Änderungshistorie.
| Version | Datum | Änderung | erstellt/geändert durch | Prüfung | Freigabe | Freigabedatum |
|---|---|---|---|---|---|---|
[0.1] |
[Datum] |
[Beschreibung und Anlass] |
[Rolle] |
[Rolle/Status] |
[Rolle/Status] |
[Datum/–] |
Die Beschreibung nennt die wesentliche Änderung und nicht nur „aktualisiert“.
| Phase | Aktivität | Ergebnis |
|---|---|---|
| 1. Bedarf | Anlass, Ziel, Owner und Dokumentenart bestimmen | dokumentierter Bedarf |
| 2. Erstellung | Vorlage verwenden, Inhalt und Metadaten erstellen | Entwurf |
| 3. Prüfung | Fachlichkeit, Schnittstellen, Anforderungen und Umsetzbarkeit bewerten | Prüfvermerk/offene Punkte |
| 4. Freigabe | Befugte Rolle entscheidet über Version und Gültigkeit | Freigabenachweis |
| 5. Veröffentlichung | freigegebene Fassung bereitstellen und schützen | führende gültige Seite |
| 6. Kommunikation | Betroffene informieren und gegebenenfalls schulen | Kommunikations-/Schulungsnachweis |
| 7. Anwendung/Überwachung | Nutzung, Fragen, Abweichungen und Wirkung verfolgen | Betriebs-/Wirksamkeitsnachweise |
| 8. Review/Änderung | turnus- oder anlassbezogen prüfen | Bestätigung oder neue Version |
| 9. Ablösung/Archiv | ungültige Fassung kennzeichnen und schützen | Archivnachweis |
| 10. Löschung | Aufbewahrung, Legal Hold und Nachweis prüfen | Lösch-/Vernichtungsnachweis |
Vor Erstellung werden festgelegt:
Die Vorlage für gelenkte Wiki-Seiten wird verwendet oder begründet angepasst.
| Prüffeld | Leitfrage |
|---|---|
| Zweck/Scope | Ist klar, für wen, was und wo die Regel gilt? |
| Richtigkeit | Sind Aussagen fachlich korrekt und aktuell? |
| Anforderungen | Sind relevante ISO-, ISA-, Kunden-, Rechts- und Vertragsbezüge berücksichtigt? |
| Rollen | Sind Verantwortung, Befugnis, Stellvertretung und Eskalation klar? |
| Umsetzbarkeit | Sind Prozess, Technik, Ressourcen und Kompetenz vorhanden? |
| Risiken | Entstehen Widersprüche, Lücken oder neue Risiken? |
| Schnittstellen | Passen andere Dokumente, Register, Systeme und Prozesse? |
| Nachweise | Ist erkennbar, wie Umsetzung und Wirksamkeit belegt werden? |
| Schutz | Stimmen Klasse, Zugriff, Anhänge und Weitergabe? |
| Verständlichkeit | Ist die Regel für Zielgruppen eindeutig und anwendbar? |
| Status/Metadaten | Sind Version, Stand, Review und Änderungshistorie vollständig? |
| Links | Sind interne und externe Verweise korrekt und erreichbar? |
| Feld | Eintrag |
|---|---|
| Dokument/Version | [ID/Version] |
| Prüfumfang | [vollständig/Teilbereich] |
| prüfende Rolle | [Rolle] |
| Prüfdatum | [Datum] |
| Ergebnis | [freigabefähig/offene Punkte/nicht freigabefähig] |
| Einschränkungen | [Beschreibung] |
| offene Punkte | [Referenzen, Owner, Termine] |
| Nachweis | [geschützter Link] |
Eine Kommentarauflösung in Wiki.js ist nur dann Prüfbeleg, wenn Rolle, Version, Inhalt und Ergebnis nachvollziehbar bleiben.
| Feld | Eintrag |
|---|---|
| Dokumenten-ID/Titel | [ID/Titel] |
| freigegebene Version | [Version] |
| Prüfnachweise | [Referenzen] |
| Freigabeentscheidung | [freigegeben/abgelehnt/mit Auflagen] |
| Auflagen | [Beschreibung, Owner, Termin] |
| freigebende Rolle | [Rolle] |
| Freigabedatum | [Datum] |
| gültig ab | [Datum] |
| nächste Prüfung | [Datum] |
| ersetzte Fassung | [Version/Referenz] |
| Nachweisablage | [geschützter Pfad] |
Name, Rolle, Datum und Version müssen eindeutig zuordenbar sein. Eine vorbereitete Freigabezeile mit „Ausstehend“ ist kein Freigabenachweis.
Nach formaler Freigabe:
Die technische Veröffentlichung erfolgt erst nach der formalen Entscheidung oder wird als klarer Entwurf gekennzeichnet.
Interne Links:
/,/de/-Sprachpräfix,Beispiel:
[Rollen und Verantwortlichkeiten](/ISMS/01-Fuehrung-und-Steuerung/Rollen-und-Verantwortlichkeiten)
Vor Freigabe werden tote, falsche und auf Entwürfe führende Links bewertet.
Die Wiki.js-Historie unterstützt Nachvollziehbarkeit, ersetzt aber nicht:
Bei freigegebenen Fassungen werden Version, Inhalt und Freigabenachweis so referenziert, dass der freigegebene Stand reproduzierbar bleibt. Je nach Risiko kann ein zusätzlicher geschützter Export oder Freigabe-Snapshot vorgesehen werden.
Das Wiki.js-Feld Script beziehungsweise benutzerdefinierter Seiten-Code wird für normale ISMS-Dokumente nicht benötigt.
Skripte, eingebettetes HTML oder aktive Inhalte dürfen nur eingesetzt werden, wenn:
| Prüffeld | Eintrag |
|---|---|
| Seite/Funktion | [Referenz] |
| Zweck | [Begründung] |
| Codequelle/Version | [Quelle] |
| Datenzugriffe/Übertragungen | [Beschreibung] |
| Sicherheits-/Datenschutzprüfung | [Ergebnis] |
| Test und Rückfall | [Nachweis] |
| technische Freigabe | [Rolle/Datum] |
Ungeprüfter Code wird nicht eingefügt, um Darstellungs- oder Komfortprobleme kurzfristig zu umgehen.
Bei neuen oder wesentlich geänderten Dokumenten wird entschieden:
| Änderungstyp | mögliche Kommunikation |
|---|---|
| redaktionell ohne Bedeutungsänderung | Änderungsvermerk, gegebenenfalls keine separate Information |
| begrenzte fachliche Änderung | gezielte Information betroffener Rollen |
| wesentliche neue/änderte Regel | Information, Schulung und gegebenenfalls Verständnisnachweis |
| kritische Sofortänderung | unverzügliche Handlungsanweisung, später formalisieren |
Die Verteilung einer Nachricht ist kein automatischer Nachweis, dass die Regel verstanden und umgesetzt wurde.
Der Dokumenten-Owner prüft zum festgelegten Termin:
| Entscheidung | Folge |
|---|---|
| unverändert gültig | Reviewnachweis und nächstes Prüfdatum aktualisieren |
| redaktionelle Anpassung | Änderung nach freigegebener Regel dokumentieren |
| inhaltliche Änderung | neue Version, Prüfung und Freigabe |
| Überarbeitung erforderlich | Risiko, Owner und Termin festlegen |
| Sperrung | Anwendung stoppen und Ersatzregel kommunizieren |
| Archivierung | außer Kraft setzen und historisch sichern |
Eine Verlängerung des Reviewdatums ohne inhaltliche Prüfung ist kein Review.
Ein überschrittenes Prüfdatum macht ein Dokument nicht automatisch ungültig. Unverzüglich werden jedoch:
Bei wesentlichen Zweifeln wird Überarbeitung erforderlich oder Gesperrt verwendet.
| Überfälligkeitsfeld | Eintrag |
|---|---|
| Dokument/Version | [ID/Version] |
| Fälligkeit | [Datum] |
| Risikobewertung | [Ergebnis] |
| Zwischenentscheidung | [weiter nutzen/eingeschränkt/gesperrt] |
| Owner/Termin | [Rolle/Datum] |
| Freigabe/Eskalation | [Rolle] |
Eine außerplanmäßige Prüfung wird insbesondere ausgelöst durch:
| Feld | Eintrag |
|---|---|
| Änderungs-ID | [DOC-CHG-NNN] |
| Dokument/Version | [ID/Version] |
| Anlass | [Anforderung/Vorfall/Verbesserung] |
| Beschreibung | [gewünschte Änderung] |
| Auswirkungen | [Prozesse, Systeme, Risiken, Schulung] |
| Dringlichkeit | [normal/dringend/notfall] |
| Owner | [Rolle] |
| Entscheidung/Termin | [Rolle/Datum] |
Ist eine sofortige Änderung zum Schutz von Menschen, Informationen oder Betrieb erforderlich:
Eine Notfalländerung wird nicht dauerhaft ohne nachgelagerte Lenkung betrieben.
Technische Änderungen an IT-, OT-, Cloud- und Produktivsystemen werden ergänzend nach IT-Betrieb und Änderungen gesteuert. Die Freigabe einer Dokumentenänderung ersetzt keine technische Change-Freigabe und umgekehrt.
Bei widersprüchlichen Dokumenten gilt nicht automatisch die zuletzt bearbeitete Seite.
Zu prüfen sind:
Bis zur Klärung:
Dokumente werden nach der Informationsklassifizierung behandelt.
| Klasse | Wiki-/Ablagegrundsatz |
|---|---|
| Öffentlich | erst nach ausdrücklicher Veröffentlichungsfreigabe |
| Intern | Zugriff für berechtigte Personen im vorgesehenen Scope |
| Vertraulich | Zugriff nach Aufgabe und Need-to-know |
| Streng vertraulich | stark eingeschränkter, nachvollziehbarer Zugriff; gegebenenfalls außerhalb des allgemeinen Wikis |
Wiki-Administrationsrechte begründen keine automatische fachliche Leseberechtigung für vertrauliche Inhalte. Technisch notwendige privilegierte Zugriffe werden besonders geschützt und protokolliert.
Anhänge werden mit der führenden Seite verknüpft und mindestens mit folgenden Angaben gelenkt:
| Feld | Mindestinhalt |
|---|---|
| Bezeichnung/Referenz | eindeutiger Dateiname beziehungsweise Anhang-ID |
| Zugehöriges Dokument | Dokumenten-ID und Version |
| Inhalt/Zweck | verständliche Beschreibung |
| Version/Stand | eindeutige Fassung |
| Schutzklasse | Zugriff und Weitergabe |
| Owner | fachliche Verantwortung |
| Prüfung/Freigabe | erforderlicher Status |
| Aufbewahrung | Frist und Ablage |
Ein neuer Anhang darf nicht unbemerkt die Aussage einer bereits freigegebenen Seite ändern.
Ein Nachweis muss mindestens erkennen lassen:
Nachträgliche Korrekturen:
Leere Vorlagen, geplante Termine, E-Mail-Ankündigungen oder nicht ausgeführte Checklisten sind keine Nachweise der Durchführung.
Personenbezogene, kundenbezogene, prototypenbezogene oder sicherheitskritische Nachweise werden nicht ungeschützt auf allgemein lesbaren Wiki-Seiten abgelegt.
Die Wiki-Seite kann stattdessen referenzieren:
| Referenzfeld | Inhalt |
|---|---|
| Nachweis-ID | eindeutige Kennzeichnung |
| Art/Ergebnis | knappe Beschreibung ohne unnötige Details |
| Datum/Version/Scope | Zuordnung zur geprüften Aktivität |
| Owner | verantwortliche Rolle |
| geschützter Ablageort | kontrollierter Link oder Systemreferenz |
| Schutz/Aufbewahrung | Klasse, Zugriff und Frist |
Externe Dokumente wie Normen, Gesetze, Verträge, Kundenanforderungen und Herstellerinformationen werden gelenkt.
| Prüfaspekt | Anforderung |
|---|---|
| Quelle | offizielle oder vertraglich maßgebliche Quelle |
| Titel/Referenz | eindeutige Bezeichnung |
| Version/Stand | Ausgabe, Änderungsstand oder Abrufdatum |
| Owner | Rolle für Beobachtung und Bewertung |
| Zugriff/Lizenz | zulässige Nutzung und Verteilung |
| Relevanz | betroffene Prozesse, Risiken, Dokumente und Controls |
| Änderungsmonitoring | Quelle, Turnus oder Auslöser |
| Auswirkungsprüfung | erforderliche Anpassungen und Termine |
Ein Link auf eine Website belegt weder den maßgeblichen Stand noch die Anwendbarkeit.
Ein archiviertes Dokument enthält beziehungsweise referenziert:
Archivierte Dokumente:
Vor Löschung werden geprüft:
| Löschfeld | Eintrag |
|---|---|
| Dokument/Nachweis | [ID/Version] |
| Grundlage | [Frist/Entscheidung] |
| geprüfte Sperren | [Legal Hold/Audit/Vertrag] |
| Umfang/Ablagen | [Systeme, Kopien, Backups] |
| Methode | [Löschung/Vernichtung] |
| durchgeführt/geprüft | [Rollen/Datum] |
| Nachweis | [Referenz] |
Wiki.js-Seiten, Konfiguration, Anhänge und erforderliche Freigabenachweise werden entsprechend Schutzbedarf und Wiederanlaufzielen gesichert.
Mindestens geprüft werden:
Ein erfolgreicher Backup-Job allein ist kein Wiederherstellungsnachweis.
Die Dokumentenlenkung unterstützt:
Alle 46 Informationssicherheitsfragen des ISA-Reiters „Informationssicherheit“ müssen umgesetzt und bewertet werden. Es gibt keine individuelle Auswahl „anwendbar/nicht anwendbar“ wie in der ISO-Statement-of-Applicability.
Dokumente und Nachweise werden kontrollfragenbezogen referenziert. Ein freigegebenes Dokument belegt nicht automatisch, dass die jeweilige Frage vollständig umgesetzt oder der angegebene Reifegrad erreicht ist.
| Kennzahl | Definition | Zielwert im Entwurf |
|---|---|---|
| Dokumente nach Status | Anzahl Entwurf, In Prüfung, Freigegeben, Überarbeitung, Gesperrt und Archiviert | Transparenz; konkrete Schwellen festzulegen |
| überfällige Reviews | Dokumente nach Prüfdatum ohne bestätigte Reviewentscheidung | 0 kritische |
| fehlende Pflichtmetadaten | gelenkte Dokumente mit unvollständiger Kennzeichnung | [Festzulegen] |
| fehlende Freigabenachweise | als freigegeben bezeichnete Dokumente ohne belastbaren Nachweis | 0 |
| fehlerhafte interne Links | nicht erreichbare oder falsche Wiki-Verweise | [Festzulegen] |
| ungeklärte Widersprüche | dokumentierte Konflikte ohne Entscheidung/Termin | 0 kritische |
| Nachweise ohne Owner/Ablage | unzureichend zugeordnete Nachweise | [Festzulegen] |
| externe Dokumente überfällig | Quellen ohne fristgerechte Aktualitätsprüfung | [Festzulegen] |
| Notfalländerungen ohne Nachprüfung | vorläufige Änderungen ohne formale Nachbearbeitung | 0 |
Der aktuelle Entwurfsbestand wird nicht ohne vollständiges Dokumentenregister als quantitativ vollständig oder konform bewertet.
| Prüfaspekt | Methode | Turnus im Entwurf | Verantwortung |
|---|---|---|---|
| Dokumentenregister | Vollständigkeits- und Fälligkeitsprüfung | regelmäßig | ISMS/Dokumentenpflege |
| Freigaben | Stichprobe Version, Rolle, Datum und Gültigkeit | risikoorientiert | ISMS/Audit |
| Wiki-Berechtigungen | Rollen- und Klassifizierungsabgleich | regelmäßig | IT/Owner |
| Links/Anhänge | automatisierte Prüfung und Stichprobe | regelmäßig | Wiki-Administration/Dokumentenpflege |
| externe Quellen | Aktualitäts- und Auswirkungsprüfung | nach festgelegtem Turnus | jeweiliger Owner |
| Nachweise | Schutz-, Vollständigkeits- und Änderungsstichprobe | risikoorientiert | Owner/Audit |
| Archiv | aktuelle/archivierte Trennung und Wiederauffindbarkeit | mindestens jährlich | ISMS/Wiki-Administration |
| Restore | Wiederherstellung von Seite, Anhang und Rechten | nach Wiederanlaufplan | IT/BCM |
Fehler, veraltete Inhalte, Widersprüche oder Verbesserungsvorschläge werden gemeldet mit:
Sicherheitskritische Fehler oder Offenlegungen werden zusätzlich über den Meldeweg für Sicherheitsvorfälle gemeldet.
| Thema | Verknüpfte Seite |
|---|---|
| Lesehilfe und Statusmodell | Lesehilfe und Dokumentenstatus |
| Rollen/Befugnisse | Rollen und Verantwortlichkeiten |
| Klassifizierung | Informationsklassifizierung |
| Anforderungen | Rechts- und Vertragskataster |
| Kontrollzuordnung | Statement of Applicability |
| TISAX-Mapping | ISO-TISAX-Mapping |
| Vorlagen | Dokumentenvorlagen |
| Audits | Auditprogramm |
| Korrekturen | Abweichungen und Korrekturmaßnahmen |
| Managementbewertung | Managementbewertung |
| Wiederanlauf | Wiederanlaufplanung |
| Nachweis | Mindestinhalt | Ablage im Entwurf |
|---|---|---|
| Dokumentenregister | ID, Owner, Status, Version, Review und Pfad | [System/Pfad] |
| Prüfvermerke | Version, Scope, Rolle, Ergebnis und offene Punkte | [geschützter Pfad] |
| Freigaben | Version, Rolle, Datum, Gültigkeit und Auflagen | [geschützter Pfad] |
| Kommunikation/Schulung | Zielgruppe, Änderung, Versand/Teilnahme und Ergebnis | [geschützter Pfad] |
| Reviewentscheidungen | Aktualität, Risiko, Entscheidung und nächster Termin | [System/Pfad] |
| Änderungsanträge | Anlass, Auswirkungen, Entscheidung und Umsetzung | [System/Pfad] |
| Archiv-/Löschprotokolle | Ablösung, Aufbewahrung, Löschung und Nachweis | [geschützter Pfad] |
| Link-/Berechtigungs-/Restore-Prüfungen | Scope, Ergebnis, Abweichung und Maßnahme | [geschützter Pfad] |
| Prüffrage | Status Entwurf |
|---|---|
| Sind Dokumentenarten, ID-Schema und Pflichtmetadaten bestätigt? | Nein |
| Sind Dokumenten-Owner, Prüfer und Freigabestellen benannt? | Nein |
| Sind Befugnisse und Funktionstrennung dokumentiert? | Nein |
| Ist das Dokumentenregister eingerichtet und vollständig? | Nein |
| Ist der Workflow Entwurf–Prüfung–Freigabe–Archiv technisch/organisatorisch umgesetzt? | Nein |
| Sind Freigabenachweise eindeutig mit Versionen verknüpft? | Nein |
| Sind Wiki.js-Rollen und Schutzklassen angemessen umgesetzt? | Nein |
| Sind Seite, Anhänge, Historie und Skriptnutzung geregelt? | Nein |
| Sind Review-, Überfälligkeits- und Eskalationsregeln operationalisiert? | Nein |
| Sind externe Dokumente und Normversionen gelenkt? | Nein |
| Sind Nachweis-, Archiv-, Aufbewahrungs- und Löschregeln umgesetzt? | Nein |
| Sind Backup und Restore angemessen getestet? | Nein |
| Sind Kennzahlen, Stichproben und Auditprüfung eingerichtet? | Nein |
| Liegen fachliche Prüfung und Geschäftsführungsfreigabe vor? | Nein |
Das Verfahren darf erst als wirksam umgesetzt bezeichnet werden, wenn Workflow, Rollen, Register, Berechtigungen, Freigabenachweise, Archiv und Wiederherstellung praktisch eingerichtet und geprüft sind.
| Version | Datum | Änderung | Erstellt/geändert durch | Freigabe | Freigabedatum |
|---|---|---|---|---|---|
| 0.1 | 23.07.2026 | Musterverfahren für Dokumenten-, Nachweis- und Wiki.js-Lenkung erstellt | ISMS-Beauftragte/r | Ausstehend | – |
Für dieses Beispiel wird der dokumentierte Arbeitsstand ISA 6.0.3 verwendet. Vor einer realen Bewertung sind die anzuwendende ISA-Version, der Assessment Scope, die tatsächliche Wiki.js-Konfiguration und die formalen Freigabebefugnisse zu bestätigen.