Clicki Change Management Policy
Purpose
This Change Management Policy defines how Clicki Referrals manages changes to systems, applications, infrastructure, and configurations. The objective is to ensure that changes are planned, reviewed, tested, approved, and deployed in a controlled manner to reduce risk, prevent service disruption, and protect customer data.
Scope
This policy applies to all changes affecting Clicki production and non-production environments, including application code, infrastructure, configurations, integrations, workflows, and security controls.
Policy Statement
All changes to Clicki systems must follow a defined process that includes appropriate review, testing, and approval before deployment to production. Changes must be traceable, auditable, and reversible where feasible.
Change Categories
Standard Changes
Low-risk, repeatable changes with predefined procedures and minimal impact.
Examples:
Routine updates
Configuration adjustments with known outcomes
Normal Changes
Planned changes that require review and approval prior to implementation.
Examples:
Feature releases
Infrastructure updates
Integration changes
Emergency Changes
Changes required to resolve incidents, vulnerabilities, or critical service issues.
Examples:
Security patches
Incident remediation actions
Change Management Process
1. Change Request
All non-trivial changes must be documented prior to implementation. Documentation may include pull requests, tickets, or deployment records.
At a minimum, change records should include:
Description of the change
Systems or components affected
Risk and impact assessment
Rollback or mitigation plan
2. Review and Approval
Code changes must be reviewed by at least one other qualified individual before deployment
High-risk or production-impacting changes may require additional approval from a senior engineer or designated approver
Changes must not be self-approved without review unless explicitly defined as a standard change
3. Testing
Changes should be tested in non-production environments where feasible
Testing should validate expected functionality and identify unintended effects
Critical changes should include validation steps before full rollout
4. Deployment
Deployments must follow controlled processes (e.g., CI/CD pipelines)
Production deployments should be monitored for errors, performance issues, or unexpected behavior
Deployments should be traceable to a specific change record or code revision
5. Rollback and Recovery
Changes should include a rollback or mitigation strategy
If a change introduces risk or instability, it must be reverted or mitigated promptly
Rollback procedures should be tested or known in advance where feasible
6. Post-Deployment Monitoring
Systems must be monitored after changes are deployed
Metrics, logs, and alerts should be reviewed to confirm stability
Issues identified post-deployment must trigger investigation and potential rollback
Emergency Changes
Emergency changes may bypass standard approval steps when necessary to restore service or address critical security issues.
Requirements:
Changes must be documented as soon as practical
Actions taken must be logged or recorded
A post-change review must be conducted
Access and Segregation
Only authorized personnel may deploy changes to production
Production deployments should be limited to approved individuals or automated pipelines
Separation of duties should be maintained where feasible (e.g., reviewer vs deployer)
Change Logging and Auditability
All changes must be traceable to an identifiable source (e.g., user, commit, pipeline)
Deployment logs and change history should be retained
Significant changes should be auditable for review and compliance purposes
Third-Party Changes
Changes involving third-party systems or integrations must:
Be reviewed for impact on data handling and security
Be tested where feasible
Follow the same approval and documentation standards
Security and Configuration Changes
Changes affecting authentication, authorization, secrets, infrastructure, or security controls require heightened scrutiny.
Must include explicit review
Must not expose credentials or weaken security posture
Must follow secure configuration practices
Prohibited Activities
The following are prohibited unless explicitly authorized:
Deploying unreviewed code to production
Making undocumented changes to production systems
Bypassing CI/CD processes without justification
Introducing hard-coded credentials or secrets
Enforcement
Failure to follow this policy may result in access restrictions, rollback of changes, or other appropriate actions.
Exceptions
Exceptions must be documented, justified, and approved by authorized personnel.
Ownership and Review
This policy is owned by Clicki management and/or the designated security owner. It must be reviewed at least annually or after significant changes to systems or processes.