Change Management Policy

Structured procedures for planning, reviewing, approving, and implementing changes to IT systems and infrastructure

Last Updated: September 2026

Policy Statement

POPS.GG (CASH.BH LTD) maintains a formal Change Management Policy to ensure that all changes to production systems, infrastructure, applications, and configurations are planned, reviewed, approved, tested, and implemented in a controlled manner that minimizes risk to business operations and security.

This policy establishes a standardized framework for managing changes throughout their lifecycle, from initial request through implementation, validation, and documentation. All IT personnel and stakeholders must follow these procedures to maintain system stability, security, and compliance.

Policy Objectives

  • Risk Mitigation: Reduce risks associated with system changes
  • Service Stability: Minimize disruption to business services
  • Security Protection: Prevent security vulnerabilities from unauthorized changes
  • Compliance: Meet regulatory and audit requirements
  • Documentation: Maintain accurate records of all changes
  • Accountability: Establish clear ownership and approval chains
  • Continuous Improvement: Learn from changes to improve processes

Scope

Changes Subject to This Policy

  • Infrastructure: Servers, network equipment, firewalls, load balancers
  • Applications: Production application code, configurations, databases
  • Cloud Services: Cloud infrastructure, services, and configurations
  • Security Systems: Firewalls, IDS/IPS, encryption, access controls
  • Data: Database schema changes, data migrations
  • Integrations: Third-party integrations, APIs, webhooks
  • DNS & Certificates: Domain configurations, SSL certificates
  • Monitoring: Monitoring tools, alerting configurations

Exclusions (Pre-Approved Changes)

The following are pre-approved standard changes with documented procedures:

  • Routine security patches for non-critical systems
  • Password resets following standard procedures
  • User account creation/deletion following HR processes
  • Scheduled backup verifications
  • Standard monitoring configuration updates

Note: Even pre-approved changes must be documented and may require notification

Change Classification

Emergency Change

Definition: Urgent changes required to resolve critical incidents or security vulnerabilities

Approval Required:

Company director (sole technical owner); verbal approval acceptable

Lead Time:

Immediate (0-4 hours)

Examples:

  • Critical security vulnerability patch
  • Production system failure recovery
  • Active security incident remediation
  • Emergency rollback of failed change

Post-Implementation:

Full documentation and review by the company director within 48 hours

Major Change (High Risk)

Definition: Significant changes with potential for widespread impact

Approval Required:

Company director (sole technical owner)

Lead Time:

Proportional to risk; scheduled in advance where practicable

Examples:

  • Major application releases or upgrades
  • Infrastructure architecture changes
  • Database migrations
  • Network topology changes
  • Security system reconfigurations
  • Cloud platform migrations

Standard Change (Medium Risk)

Definition: Routine changes with moderate impact and known procedures

Approval Required:

Company director (sole technical owner)

Lead Time:

Proportional to risk

Examples:

  • Application configuration changes
  • Non-critical software updates
  • Monitoring configuration changes
  • DNS record updates
  • SSL certificate renewals

Minor Change (Low Risk)

Definition: Low-risk changes with minimal impact

Approval Required:

Company director (sole technical owner); contractors may implement under the director’s approval

Lead Time:

Proportional to risk

Examples:

  • Development build changes
  • Documentation updates
  • Monitoring alert threshold adjustments
  • Development tool configurations

Change Management Process

1Change Request (RFC)

All changes must be initiated with a formal Request for Change (RFC):

  • Requestor Information: Name, department, contact information
  • Change Description: Detailed description of proposed change
  • Business Justification: Reason for change and expected benefits
  • Systems Affected: All systems, applications, and services impacted
  • Risk Assessment: Potential risks and impact analysis
  • Dependencies: Related systems, services, or other changes
  • Implementation Plan: Step-by-step procedure
  • Testing Plan: How change will be tested and validated
  • Rollback Plan: Procedure to reverse change if needed
  • Schedule: Proposed implementation date and time

2Initial Review & Risk Assessment

Technical Review

  • Feasibility assessment by technical team
  • Impact analysis on dependent systems
  • Resource requirements (time, personnel, tools)
  • Implementation complexity evaluation

Security Review

  • Security implications and vulnerabilities
  • Compliance impact (UK GDPR)
  • Access control and authentication changes
  • Data protection considerations

Business Impact Analysis

  • Service availability impact
  • User impact and communication needs
  • Financial implications
  • Regulatory or contractual impacts

Risk Classification

Change classified as Emergency, Major, Standard, or Minor based on review findings

3Approval Process

Change Approval

Approver: All changes are approved by the company director (sole technical owner); contractors may implement under the director’s approval

Frequency: Reviewed as changes are proposed; lead time is proportional to risk and major changes are scheduled in advance where practicable

Required for: All Major changes

Decision Criteria: Risk vs. benefit, business priority, resource availability, timing

Approval Authority Matrix

Emergency:

Company director

Major:

Company director

Standard:

Company director

Minor:

Company director (contractors may implement under approval)

4Planning & Scheduling

  • Change Window Selection: Scheduled during approved maintenance windows
  • Resource Allocation: Assign implementation team and responsibilities
  • Communication Plan: Stakeholder notifications and status updates
  • Coordination: Identify and coordinate with dependent changes
  • Change Freeze: Respect change freeze periods (year-end, major events)
  • Blackout Dates: No production changes during business-critical periods

5Testing & Validation

Pre-Production Testing (Required for Major/Standard)

  • Changes are tested in a development build before deployment
  • Performance testing for infrastructure changes
  • Security testing for security-related changes
  • User acceptance testing (UAT) when applicable

Test Results Documentation

  • Test scenarios executed
  • Pass/fail results
  • Performance metrics
  • Issues identified and resolved

6Implementation

Pre-Implementation Checklist

  • Verify approval received and documented
  • Confirm all stakeholders notified
  • Ensure implementation team available
  • Verify rollback plan tested and ready
  • Take backup of affected systems
  • Confirm monitoring in place to detect issues

During Implementation

  • Follow documented implementation procedure
  • Document all steps taken in real-time
  • Monitor systems continuously for issues
  • Maintain communication channel with stakeholders
  • Escalate immediately if issues arise

Implementation Window Requirements

Major Changes:

Off-hours (weekends/evenings)

Standard Changes:

Approved maintenance windows

Emergency:

As needed (24/7)

Minor:

Business hours acceptable

7Post-Implementation Validation

  • Smoke Testing: Verify basic functionality working
  • Monitoring Review: Check metrics, logs, alerts for anomalies
  • Performance Validation: Confirm performance meets expectations
  • Security Verification: Validate security controls functioning
  • User Validation: Confirm users can access services
  • Rollback Decision: Determine if change should remain or rollback

8Documentation & Closure

  • Implementation Summary: What was done, when, by whom
  • Deviations: Any changes from the planned procedure
  • Issues Encountered: Problems and their resolutions
  • Final Status: Success, failed, or rolled back
  • Configuration Updates: Update the deployment notes
  • Documentation Updates: Update runbooks, procedures, diagrams
  • Lessons Learned: What went well, what could improve
  • Stakeholder Notification: Final communication to all stakeholders

Rollback Procedures

Rollback Criteria

Changes must be rolled back if:

  • Critical functionality is broken or unavailable
  • Security vulnerability introduced
  • Performance degradation beyond acceptable thresholds
  • Data corruption or loss detected
  • Integration failures affecting business operations
  • Cannot resolve issues within defined rollback window

Rollback Requirements

  • Rollback Plan: Documented procedure required for all Major/Standard changes
  • Rollback Testing: Rollback procedure verified in a development build before deployment
  • Rollback Window: Maximum time before rollback decision must be made
  • Rollback Authority: Implementer can initiate; the company director approves
  • Communication: Immediate notification to stakeholders if rollback needed
  • Post-Rollback: Root cause analysis and improvement plan required

Rollback Time Limits

Major Changes

4 hours - if not stable, must rollback

Standard Changes

2 hours - rollback if issues persist

Emergency Changes

1 hour - immediate rollback if worse

Data Migrations

Defined per change (restore from backup)

Change Windows & Freeze Periods

Standard Change Windows

Production Changes

  • Low-traffic hours where possible
  • Emergency: Any time

Development Builds

  • Business hours acceptable
  • Coordinate with contractors where involved
  • Avoid during testing cycles

Change Freeze Periods

No non-emergency changes allowed during:

  • Holiday Season: December 20 - January 5
  • Black Friday / Cyber Monday: Week of Thanksgiving
  • Major Marketing Campaigns: Announced in advance
  • Business-Critical Events: As designated by management

Emergency security patches and incident response changes are exempt from freeze periods

Documentation Requirements

Change Records

All changes must be documented in git history and the deployment log with:

  • Change ID: Unique identifier for tracking
  • Title & Description: Clear, concise change summary
  • Requestor & Implementer: Names and roles
  • Systems Affected: Complete list of impacted systems
  • Risk Level: Classification and risk score
  • Approval Chain: Who approved and when
  • Implementation Details: Actual steps performed
  • Validation Results: Post-implementation testing outcomes
  • Issues & Resolutions: Problems encountered and fixes
  • Attachments: Scripts, configurations, screenshots

Retention: Change records retained for 7 years for audit and compliance purposes

Performance Metrics & KPIs

Change management effectiveness measured by:

  • Change Success Rate: % of changes completed successfully without rollback
  • Emergency Change Rate: % of changes classified as emergency
  • Rollback Rate: % of changes requiring rollback
  • Change-Related Incidents: Incidents caused by changes
  • Mean Time to Implement: Average time from approval to completion
  • Approval Cycle Time: Time from submission to approval
  • Change Volume: Number of changes by type and period
  • Unauthorized Changes: Changes implemented without proper approval

Target: 95% change success rate, <5% emergency changes, <3% rollback rate

Policy Governance

Roles & Responsibilities

Change Manager

Overall process ownership, change coordination, metrics reporting, continuous improvement

Company Director (sole technical owner)

Holds the Change Manager role; approves all changes, policy exceptions and escalations

Implementers (director or contractors under the director’s approval)

Change execution, testing, documentation, incident response during implementation

All Staff

Follow change management procedures, report unauthorized changes, participate in process improvement

Policy Review & Updates

  • Annual comprehensive policy review
  • Periodic review of process effectiveness by the company director
  • Updates following significant incidents or changes
  • Incorporation of industry best practices
  • All policy changes approved by the company director and communicated to staff and contractors

Contact Information

Change Management

Change Manager

Email: change-management@pops.gg

Emergency Changes

For urgent emergency changes:

Contact: the company director (change-management@pops.gg)