GH GambleHub

Policy Change Log

1) Purpose and value

What for:
  • Transparent history of change: who, what, when and why.
  • Compliance with auditors/regulators (ISO 27001, SOC 2, PCI DSS, GDPR and local regulations).
  • Risk management: linking changes to risk assessments, incidents and CAPA plans.
  • A single source of truth for employees, providers and partners.

Result: operational and compliance risk is reduced, audits and investigations are accelerated, onboarding time is reduced.

2) Scope

The journal covers all "policy" and "standard" level documents:
  • Security and access: information security policy, incident management, vulnerabilities, keys/encryption, secret management, password policy, IAM.
  • Data and privacy: GDPR/DSAR/RTBF, storage and deletion, data classification, DLP, logs and audit.
  • Finance/AML/KYC: AML/KYB/KYC, sanction screening, proof of source of funds.
  • Operations: BCP/DRP, change management, release policy, RACI, SRE/SLO.
  • Legal/regulatory: local market requirements, advertising restrictions, responsible play.

3) Roles and Responsibilities (RACI)

R (Responsible): Policy Owner and Policy Editor.
A (Accountable): Document owner of the domain/CISO/Head of Compliance.
C (Consulted): Legal/DPO, Risk, SRE/Operations, Product, Data.
I (Informed): All employees, external contractors (if necessary).

Principles: dual-control per publication; segregation of duties; mandatory Legal/DPO consultations for PII/regulatory topics.

4) Change lifecycle

1. Initiative: trigger (regulatory requirement, audit funding, incident, penetration test, architecture change).
2. Draft - Change in Document Management System (Confluence/Git/Policy CMS).
3. Impact assessment: on processes, risk register, training, contracts, integrations.
4. Approval: Legal/DPO/Compliance/Tech/Operations, final owner approval.
5. Publication: version assignment, effective date, distribution.
6. Onboarding: training/acknowledgement, SOP/Runbook update.
7. Monitoring: compliance control, metrics, retrospective.

5) Log data model (required fields)

'policy _ id'is a constant policy ID.
'policy _ title'is the title of the document.
'change _ id'is the unique identifier of the change.
'version '- semantic version (MAJOR. MINOR. PATCH) or dated.

`change_type` — {MAJORMINORPATCHURGENTREGULATORY}.
`status` — {draftin_reviewapprovedpublishedeffective
'proposer '/' editor '/' approver '- users/groups.
`submitted_at` / `approved_at` / `published_at` / `effective_from`.
'summary '- a brief description of the change (≤ 300 characters).
'change _ log '- details: what has been changed and why.
'rationale '- justification (regulatory reference/incident/audit).
'risk _ ref'refers to the risk register/impact assessment.
'legal _ refs' - codes/standards (e.g. GDPR Art. 32, ISO A.8).
'impact _ scope '- who is affected (commands/processes/regions).
'training _ required '- yes/no + course reference.
'attaches' - diff/pdf, negotiation protocol.
'distribution _ list '- who to notify.
'ack _ required '- whether acknowledgement is required.
'hold _ flags' - Legal Hold/freeze (if applicable).
Example (YAML):
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) Version and change type requirements

MAJOR: changes mandatory requirements/controls, affects audit/risks; requires training and transition.
MINOR: refinements, examples, do not change control in essence.
PATCH: spelling/referencing edits; fast-track.
URGENT: urgent correction due to incident/vulnerability; publication on an expedited basis.
REGULATORY: updated due to new regulatory act/regulator letter.

Versioning: fix tags/releases; immutable PDF/HTML artifacts with hash.

7) Approval workflow

1. Draft → Review - Auto-check template, links and metadata.
2. Multi-review: Legal/DPO/Compliance/Tech/Operations (parallel/sequential).
3. Approval: domain owner + Accountable.
4. Publish: generating a release note, writing to the Journal, mailing, updating "effective_from".
5. Acknowledgement: collecting employee acknowledgement (LMS/HRIS).
6. Post-publish controls: SOP/contract/script update tasks.

Two-key rule: Publishing is only possible with 2 + approvals from the list of approved roles.

8) Legal Hold

When: investigation, legal request, regulatory review.
What we do: flag 'hold _ flags = ["legal"]', freeze deletion/version revisions, WORM archive, Hold activity log.
Hold withdrawal: Legal/DPO only; all actions are logged.

9) Privacy and local regulation

Minimizing PII in the log (store employee ID instead of e-mail, if possible).
Retention periods = "retention schedules" (policy records are usually 5-7 years).
DSAR/RTBF: the log is excluded from deletion if there is a legal duty of custody; we fix the legal basis.

10) Integrations

Confluence/Docs/Git: source of edits and artifacts (diff, PDF).
IAM/SSO: employee roles and attributes Audit log access.
LMS/HRIS: training, tests, acknowledgement.
GRC/IRM: relationship with risks, controls, CAPA/plans.
SIEM/Logs: audit of journal operations (who viewed/exported).
Ticketing (Jira/YouTrack): initiating tasks and release checklists.

11) Metrics and SLO

Coverage:% of current policies with last log entry (target ≥ 99%).
Time-to-Publish: median time from 'submitted _ at' to 'published _ at' (target ≤ 14 days; urgent ≤ 48 hours).
Ack-rate: the proportion of employees who confirmed the acquaintance (target ≥ 98% in 14 days).
Audit-readiness: the proportion of policies with a full set of artifacts (diff, PDF, signatures) (100% goal).
Exceptions closed:% closed exceptions/deviations by date.
Access audit: 0 unauthorized log access incidents.

12) Dashboard (minimum set of widgets)

Feed of recent publications and enactments.
Status map by domain (Security, Data, AML, Ops).
Heat map of delays in approval.
Time-to-Publish/Time-in-Review histogram.
Ack-rate by department and role.
List of open REGULATORY/URGENT changes.

13) Procedures and templates

Markdown record template:

{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}
Issue checklist:
  • All required fields and artifact references filled in
  • Impact assessed and risks updated
  • Dual-control
  • Immutable package generated (PDF + hash)
  • Mailings and ack campaign configured
  • Updated SOP/Runbooks/contracts (if required)

14) Access control and security

RBAC Read/Create/Approve/Archive roles.
Just-in-Time: temporary publish/export authority.
Encryption: TLS in-transit, KMS at-rest; banning anonymous exports.
Audit: logs of all operations, alerts for unusual actions (mass exports, frequent edits).

15) Implementation by steps

MVP (2-4 weeks):

1. Directory of policies and their owners.

2. Single record template + required fields.

3. Registry in Confluence/Notion or simple Policy-CMS; exporting immutable PDF.

4. Basic workflow of approvals and ack campaign via mail/LMS.

5. Access roles and activity logging.

Phase 2 (4-8 weeks):
  • Integration with Git for diff and semantic versioning.
  • GRC-links with risks/controls, reports for audit.
  • KPI/SLO dashboard, automatic reminders by date.
Phase 3 (8-12 weeks):
  • API/webhooks for external systems, rule-as-code pattern matching.
  • Legal Hold + WORM archive, cryptographic signatures of release packages.
  • Multi-jurisdictionality (tags by market/language/version).

16) Frequent mistakes and how to avoid them

Out-of-journal changes: Deny unrecorded publications, automatic checks.
No rationale/references: make the field mandatory + source templates (regulator, audit, incident).
No ack control: Integrate LMS/HRIS and track KPIs.
Mix drafts and publications - Use separate spaces/branches.
Access "all": strict RBAC, export read audit.

17) Glossary (brief)

Policy - a management document with mandatory requirements.
Standard/Procedure/SOP - granularity and execution order.
CAPA - corrective and preventive actions.
Acknowledgement (ack) - confirmation of familiarization by the employee.
Legal Hold - legal freeze of changes/deletions.

18) The bottom line

The policy change log is not only a "history of edits," but a managed process with clear roles, a data model, access controls, legal fixation, and metrics. Its mature implementation accelerates audits, reduces nonconformance risks, and increases operational discipline throughout the organization.

Contact

Get in Touch

Reach out with any questions or support needs.We are always ready to help!

Start Integration

Email is required. Telegram or WhatsApp — optional.

Your Name optional
Email optional
Subject optional
Message optional
Telegram optional
@
If you include Telegram — we will reply there as well, in addition to Email.
WhatsApp optional
Format: +country code and number (e.g., +380XXXXXXXXX).

By clicking this button, you agree to data processing.