Richtlinienänderungsprotokoll

1) Zweck und Wert

• Eine transparente Geschichte des Wandels: Wer, was, wann und warum.
• Einhaltung der Anforderungen von Auditoren/Regulierungsbehörden (ISO 27001, SOC 2, PCI DSS, DSGVO und lokale Vorschriften).
• Risikomanagement: Verknüpfung von Änderungen mit Risikobewertungen, Vorfällen und CAPA-Plänen.
• Eine einzige Quelle der Wahrheit für Mitarbeiter, Anbieter und Partner.

Die Folge: Betriebs- und Compliance-Risiken werden reduziert, Audits und Untersuchungen beschleunigt, Onboarding-Zeiten verkürzt.

2) Geltungsbereich (Umfang)

• Sicherheit und Zugriff: IP-Richtlinie, Incident Management, Schwachstellen, Schlüssel/Verschlüsselung, Geheimhaltung, Passwortrichtlinie, IAM.
• Daten und Datenschutz: DSGVO/DSAR/RTBF, Speicherung und Löschung, Datenklassifizierung, DLP, Protokolle und Audit.
• Finanzen/AML/KYC: AML/KYB/KYC, Sanktionsscreening, Bestätigung der Geldquelle.
• Aktivitäten: BCP/DRP, Change Management, Release Policy, RACI, SRE/SLO.
• Legal/regulatorisch: lokale Anforderungen der Märkte, Werbebeschränkungen, verantwortungsvolles Spielen.

3) Rollen und Verantwortung (RACI)

R (Responsible): Richtlinieneigentümer und -editor.
A (Accountable): Dokumenteninhaber der Domain/CISO/Head of Compliance.
C (Consulted): Legal/DPO, Risk, SRE/Operations, Product, Data.
I (Informiert): Alle Mitarbeiter, externe Auftragnehmer (falls erforderlich).

Grundsätze: Dual-Control pro Publikation; Trennung der Pflichten; obligatorische Rechtsberatung/DSB für PII/regulatorische Themen.

4) Lebenszyklus der Veränderung

1. Initiative: Auslöser (regulatorische Anforderung, Audit-Feinding, Incident, Pentest, Architekturänderung).
2. Entwurf: Änderung im Dokumentenmanagementsystem (Confluence/Git/Policy CMS).
3. Bewertung der Auswirkungen: auf Prozesse, Risikoregister, Ausbildung, Verträge, Integrationen.
4. Abstimmung: Legal/DPO/Compliance/Tech/Operations, abschließende Genehmigung durch den Eigentümer.
5. Veröffentlichung: Versionszuordnung, Datum des Inkrafttretens, Versand.
6. Onboarding: Training/Handshake, SOP/Runbook Update.
7. Monitoring: Compliance-Kontrolle, Metriken, Retrospektive.

5) Protokolldatenmodell (Pflichtfelder)

'policy _ id' ist die persistente ID der Richtlinie.
'policy _ title' ist der Name des Dokuments.
'change _ id' ist die eindeutige ID der Änderung.
'version' ist die semantische Version (MAJOR. MINOR. PATCH) oder datiert.

yaml change_id: POL-SEC-001-2025-11-01-M01 policy_id: POL-SEC-001 policy_title: Access Control Policy version: 2. 0. 0 change_type: MAJOR status: approved submitted_at: 2025-10-18T14:20:00Z approved_at: 2025-10-29T10:05:00Z published_at: 2025-10-30T09:00:00Z effective_from: 2025-11-15 proposer: d. kovalenko editor: secops. editors approver: ciso summary: Review roles and JIT access, enter quarterly-review.
rationale: "SOC Audit 2: CAPA-2025-17; incident # INC-5523"
risk_ref: RSK-AC-2025-004 legal_refs: ["ISO27001 A.5, A.8", "GDPR Art. 32"]
impact_scope: ["Prod Ops", "Payment Ops", "Affiliates"]
training_required: true attachments:
- link: confluence://AC-Policy-v2-diff
- link: git://policy-repo/pol-sec-001@v2. 0. 0 distribution_list: ["all@company", "ops@company", "vendors:payments"]
ack_required: true hold_flags: []

6) Anforderungen an Version und Änderungsarten

MAJOR: ändert die obligatorischen Anforderungen/Kontrollen, beeinflusst die Prüfung/Risiken; erfordert Ausbildung und Übergangszeit.
MINOR: Präzisierungen, Beispiele, ändern die Kontrolle nicht wesentlich.
PATCH: Rechtschreib-/Linkkorrekturen; fast-track.
URGENT: dringende Bearbeitung aufgrund eines Vorfalls/einer Schwachstelle; Veröffentlichung in beschleunigter Reihenfolge.
REGULATORY: Aktualisierung aufgrund eines neuen regulatorischen Aktes/regulatorischen Schreibens.

Versionierung: Tags/Releases fixieren; immutable PDF/HTML Artefakte mit Hash.

7) Workflow der Verhandlung

1. Draft → Review: Automatische Überprüfung von Vorlagen, Links und Metadaten.
2. Multi-Review: Legal/DPO/Compliance/Tech/Operations (parallel/sequenziell).
3. Approval: Inhaber der Domain + Accountable.
4. Publish: Generierung einer Release Note, Eintrag im Journal, Mailing, Update "effective_from".
5. Acknowledgement: Erfassung von Mitarbeiterquittierungen (LMS/HRIS).
6. Post-publish controls: Aufgaben zur Aktualisierung von SOPs/Verträgen/Skripten.

Zwei-Schlüssel-Regel: Die Veröffentlichung ist nur mit 2 + Genehmigungen aus der Liste der genehmigten Rollen möglich.

8) Rechtliche Fixierung und Einfrieren (Legal Hold)

Wann: Untersuchung, gerichtliche Untersuchung, behördliche Überprüfung.
Was wir tun: Flag 'hold _ flags = [„legal“]', Löschstopp/Revisionen der Version, WORM-Archiv, Aktivitätsprotokoll von Hold.
Hold Rückzug: nur Legal/DPO; Alle Aktionen werden protokolliert.

9) Privatsphäre und lokale Regelungen

Minimierung der PII im Log (Mitarbeiter-ID statt E-Mail, wenn möglich).
Aufbewahrungsfristen = „Aufbewahrungszeitpläne“ (policy records in der Regel 5-7 Jahre).
DSAR/RTBF: das Protokoll ist von der Löschung ausgeschlossen, wenn eine gesetzliche Aufbewahrungspflicht besteht; Wir fixieren die Rechtsgrundlage.

10) Integration

Confluence/Docs/Git: Quelle von Bearbeitungen und Artefakten (diff, PDF).
IAM/SSO: Rollen und Attribute der Mitarbeiter; Überwachung des Zugriffs auf das Protokoll.
LMS/HRIS: Training, Tests, Handshake.
GRC/IRM: Zusammenhang mit Risiken, Kontrollen, SARA/Plänen.
SIEM/Logs: Audit der Aktivitäten auf dem Logbuch (wer gesehen/exportiert hat).
Ticketing (Jira/YouTrack): Initiierung von Aufgaben und Freigabeprüflisten.

11) Metriken und SLOs

Coverage:% der aktuellen Policies mit dem letzten Log-Eintrag (Ziel ≥ 99%).

Time-to-Publish: Mediane Zeit von 'submitted _ at' bis' published _ at'(Ziel ≤ 14 Tage; urgent ≤ 48 Stunden)

Ack-Rate: Anteil der Mitarbeiter, die die Einarbeitung bestätigt haben (Ziel ≥ 98% in 14 Tagen).
Audit-readiness: Anteil der Richtlinien mit einem vollständigen Satz von Artefakten (diff, PDF, Signaturen) (Ziel 100%).
Ausnahmen geschlossen:% geschlossene Ausnahmen/Terminabweichungen.
Access audit: 0 Vorfälle von unbefugtem Zugriff auf das Protokoll.

12) Dashboard (Mindestsatz von Widgets)

Das Band der letzten Veröffentlichungen und des Inkrafttretens.
Statuskarte nach Domains (Security, Data, AML, Ops).
Heatmap der Genehmigungsverzögerungen.
Das Histogramm Time-to-Publish/Time-in-Review.
Ack-Rate nach Abteilungen und Rollen.
Liste der offenen REGULATORY/URGENT-Änderungen.

13) Verfahren und Vorlagen

{policy_title} — {version}
Change ID: {change_id}      Type: {change_type}      Effective: {effective_from}
Summary: {summary}
Rationale: {rationale}
Impacts: {impact_scope}
Approvals: {approver} at {approved_at}
Artifacts: {links}
Training: {training_required}

• Alle Pflichtfelder und Artefakt-Links ausgefüllt
• Folgenabschätzung durchgeführt und Risiken aktualisiert
• Genehmigungen erhalten (Dual-Control)
• immutable-package gebildet (PDF + hash)
• Mailings und ack-Kampagne eingerichtet
• SOP/Runbooks/Verträge aktualisiert (falls erforderlich)

14) Zugangskontrolle und Sicherheit

RBAC: Rollen zum Lesen/Erstellen/Genehmigen/Archivieren.
Just-in-Time: Temporäre Veröffentlichungs-/Exportberechtigungen.
Verschlüsselung: TLS in-transit, KMS at-rest; Verbot anonymer Exporte.
Audit: Protokolle aller Operationen, Warnungen für ungewöhnliche Aktionen (Massenexporte, häufige Bearbeitungen).

15) Umsetzung in Schritten

1. Verzeichnis der Richtlinien und ihrer Eigentümer.

2. Einheitliche Eintragsvorlage + Pflichtfelder.

3. Registrierung in Confluence/Notion oder einem einfachen Policy-CMS; immutable PDF exportieren.

4. Basis-Workflow für Freigaben und ack-Kampagne per Mail/LMS.

5. Zugriffsrollen und Protokollierung von Aktionen.

• Integration mit Git für diff und semantische Versionierung.
• GRC-Verknüpfungen mit Risiken/Kontrollen, Berichte für Audits.
• KPI/SLO Dashboard, automatische Terminerinnerungen.

• API/Webhooks für externe Systeme, Rule-as-Code-Überprüfung der Musterkonformität.
• Legal Hold + WORM-Archiv, Krypto-Signatur-Release-Pakete.
• Multi-Jurisprudenz (Tags nach Märkten/Sprachen/Versionen).

16) Häufige Fehler und wie man sie vermeidet

Änderungen außerhalb des Journals: Verbot von Veröffentlichungen ohne Aufzeichnung, automatische Überprüfungen.
Keine rationale/Links: Feld obligatorisch machen + Quellvorlagen (Regulator, Audit, Incident).
Keine Ack-Kontrolle: LMS/HRIS integrieren und KPIs überwachen.
Mischen von Entwürfen und Publikationen: Verwenden Sie separate Räume/Zweige.
Zugang für „alle“: strenge RBAC, Export-Leseprüfung.

17) Glossar (kurz)

Policy ist ein Managementdokument mit verbindlichen Anforderungen.
Standard/Procedure/SOP - Detaillierung und Reihenfolge der Ausführung.
CAPA - Korrektur- und Vorbeugungsmaßnahmen.
Acknowledgement (ack) - Bestätigung der Einarbeitung durch den Mitarbeiter.
Legal Hold - gesetzliches Einfrieren von Änderungen/Löschungen.

18) Ergebnis

Das Policy Change Log ist nicht nur eine „Bearbeitungshistorie“, sondern ein überschaubarer Prozess mit klaren Rollen, Datenmodell, Zugriffskontrollen, gesetzlicher Fixierung und Metriken. Die ausgereifte Implementierung beschleunigt Audits, reduziert das Risiko von Inkonsistenzen und erhöht die operative Disziplin in der gesamten Organisation.