Review & Freigabeprozess

Ein zentrales Ziel von Kopexa ist es, Governance und Auditfähigkeit zu gewährleisten.
Dafür gibt es einen klaren Review- und Freigabeprozess für alle Dokumente.

Warum ein Reviewprozess?

• Auditnachweis: Prüfer wollen sehen, dass Policies formell freigegeben und regelmäßig überprüft werden.
• Governance: Klare Trennung zwischen Entwurf (Draft) und veröffentlichten (Published) Versionen.
• Transparenz: Jede Änderung wird versioniert und mit einem Genehmigungs-Trail versehen.
• Qualität: Policies werden durch mehrere Augenpaare geprüft, bevor sie verbindlich sind.

Status-Lifecycle

Jedes Dokument durchläuft folgende Stati:

1. Entwurf (Draft):

   • Inhalt wird erstellt/bearbeitet.
   • Kollaborative Bearbeitung möglich (Rich Text Editor).
   • Noch nicht verbindlich.

2. Zur Überprüfung eingereicht:

   • Draft wird für Review markiert.
   • Prüfer (Reviewer) werden zugewiesen.
   • Reviewer erhalten eine Benachrichtigung.

3. Genehmigt / Veröffentlicht:

   • Reviewer haben das Dokument geprüft und freigegeben.
   • Der Draft wird zur Published-Version.
   • Audit-Trail vermerkt wer, wann und was genehmigt hat.

4. Änderungen angefordert:

   • Reviewer können Änderungen fordern.
   • Draft bleibt im Bearbeitungsstatus und wird nach Anpassung erneut eingereicht.

Rollen & Verantwortlichkeiten

• Author: Erstellt und bearbeitet Drafts.
• Reviewer: Prüft Inhalt, kann freigeben oder Änderungen anfordern.
• Owner: Fachlich verantwortliche Person für das Dokument (z. B. ISB).

Best Practice: Jeder freigegebene Policy-Draft sollte mindestens einen Reviewer und einen Owner haben.

Audit-Trail & Versionierung

• Jede Version (Draft & Published) wird revisionssicher gespeichert.
• Alte Versionen bleiben für Audits sichtbar.
• Alle Genehmigungen und Kommentare werden protokolliert.

Published-Dokumente

Nach Freigabe wird ein Dokument als „Published“ geführt:

• Kann gemappt werden (Assets, Kontrollen, Risiken, Lieferanten).
• Kann in Audits als Evidence genutzt werden.
• Unterliegt einem Reviewzyklus (siehe Mapping & Zyklen).

Beispiel: Review in der Praxis

1. Draft: „Informationssicherheitsleitlinie“ erstellt.
2. Reviewer (ISB) weist Feedback zu Wortlaut aus.
3. Änderungen übernommen, erneut eingereicht.
4. ISB genehmigt, Status auf Veröffentlicht.
5. Mapping zu Assets, Controls und jährlicher Reviewzyklus gesetzt.

Verwandte Themen

• Dokument anlegen
• Mapping & Reviewzyklen
• Warum Dokumente mehr sind als Uploads