Change Management Policy

Digital Benefits Pte Ltd (WiBiz) Version: 1.0 Effective Date: 15 April 2026 Owner: CEO / Head of Operations Review Cycle: Annual (next review: April 2027) Classification: Internal

1. Purpose

This policy establishes a structured process for managing changes to WiBiz production systems, infrastructure, configurations, and code. It ensures changes are planned, tested, approved, documented, and reversible, minimising risk to client operations and data integrity.

2. Scope

This policy applies to all changes affecting:

• Production application code (all Vercel-deployed services, API endpoints, cron jobs)
• CRM platform configurations (workflows, automations, sub-account templates, snapshots)
• Infrastructure components (DNS, domain routing, server configurations, LaunchAgents)
• Third-party integration configurations (payment processors, automation platforms, voice services)
• Database schemas and data migrations
• Security controls, access permissions, and authentication mechanisms
• Client-facing AI knowledge bases and bot configurations

All WiBiz employees, contractors, and partners who modify production systems must comply with this policy.

3. Change Classification

3.1 Standard Changes

Pre-approved, low-risk, repeatable changes that follow a documented procedure. No additional approval required per instance.

Examples:

• Adding a new client sub-account from an approved template
• Updating AI knowledge base content within an existing client account
• Routine SSL certificate renewals (automated)
• Adding new team member accounts with standard role permissions
• Deploying pre-approved content updates to existing pages

3.2 Normal Changes

Changes that require review and approval before implementation. These carry moderate risk or affect multiple systems.

Examples:

• New feature deployments to production applications
• Workflow or automation logic changes affecting client accounts
• Integration configuration changes (payment, automation, voice)
• Infrastructure changes (DNS records, domain routing, server configs)
• Database schema modifications
• Changes to onboarding form logic or sub-account provisioning
• New third-party service integrations

3.3 Emergency Changes

Changes required to restore service, fix a critical security vulnerability, or resolve an issue causing active data loss or client impact. These follow an expedited approval process.

Examples:

• Hotfix for a production outage affecting client operations
• Patching an actively exploited security vulnerability
• Reverting a deployment that caused service degradation
• Fixing a data integrity issue in production

4. Change Request Process

4.1 Request

All Normal and Emergency changes must be documented before implementation. The change request must include:

• Description: What is being changed and why
• Classification: Standard, Normal, or Emergency
• Systems affected: Which applications, services, or client accounts are impacted
• Risk assessment: What could go wrong (Low / Medium / High)
• Rollback plan: How to reverse the change if it fails
• Testing completed: What testing was performed and the results
• Implementation window: Proposed date and time for deployment
• Requestor: Name and role of the person requesting the change

Change requests are submitted via the designated project management channel (Discord thread or task tracker).

4.2 Review

All Normal changes are reviewed for:

• Technical correctness and completeness
• Impact on existing client operations
• Adequacy of the rollback plan
• Compliance with security policies
• Testing evidence

4.3 Approval

No Normal or Emergency change proceeds without documented approval. Verbal approvals for emergencies must be followed by written confirmation within 48 hours.

4.4 Implementation

Changes are implemented according to the approved plan:

• Deploy during approved implementation window
• Follow the documented deployment steps
• Monitor for errors during and immediately after deployment
• Confirm successful deployment before closing the change

4.5 Verification

Post-implementation verification is mandatory:

• Confirm the change achieves its intended outcome
• Verify no unintended side effects on related systems
• Check client-facing services remain operational
• Document verification results

5. Testing Requirements

5.1 Pre-Production Testing

All Normal changes must be tested before production deployment:

5.2 Production Verification

After deployment, verify:

• Core functionality works as expected (manual spot check minimum)
• No error spikes in application logs
• Client-facing endpoints respond correctly
• Automated workflows fire as expected (where applicable)

6. Rollback Procedures

Every Normal and Emergency change must have a documented rollback plan before implementation.

6.1 Code Deployments (Vercel)

• All deployments are tied to Git commits. Rollback by reverting to the previous commit and redeploying, or by using Vercel's instant rollback to a prior deployment.
• Rollback must be executable within 15 minutes of identifying a problem.

6.2 CRM Configuration Changes

• Before modifying any workflow, automation, or pipeline, document the current state (screenshot or export).
• Rollback by restoring the documented prior configuration.

6.3 Database Changes

• All schema migrations must include a corresponding rollback migration.
• Data modifications must be preceded by a backup of affected records.

6.4 Integration Changes

• Record prior configuration values before modification.
• Rollback by restoring the prior configuration.

7. Change Documentation

All changes must be documented with:

• Date and time of implementation
• Who implemented the change
• What was changed (description and affected systems)
• Why it was changed (business justification or incident reference)
• Approval reference
• Testing evidence (screenshots, test results, or log excerpts)
• Verification result (pass/fail)
• Any issues encountered and their resolution

Documentation is stored in the project management system or the relevant project repository. Change records must be retained for a minimum of 12 months.

8. Emergency Change Process

When an emergency change is required:

1. Identify and escalate: Report the issue immediately to the CEO or Head of Operations via the fastest available channel (Discord, phone, WhatsApp).
2. Verbal approval: Obtain verbal approval from the CEO or Head of Operations. If neither is reachable within 30 minutes, the most senior available team member may authorise the change.
3. Implement the fix: Deploy the minimum change required to resolve the issue. Do not bundle unrelated changes.
4. Document within 48 hours: Complete a full change record within 48 hours, including:
   • Root cause analysis
   • What was changed
   • Who approved (and how)
   • Impact assessment
   • Preventive measures to avoid recurrence
5. Post-implementation review: Conduct a review within 5 business days to assess whether the emergency change introduced any new risks or requires follow-up work.

9. Change Freeze Periods

Changes to production systems are restricted during the following periods:

• Client Signal Launch windows: No unrelated production changes during the 3-business-day Signal Launch period for any client. Only changes directly supporting that launch are permitted.
• Major deployment windows: When a significant platform release is in progress, no unrelated changes are permitted until the release is verified stable.
• Holiday periods: Production changes are discouraged during public holidays (Singapore and Philippines) unless they are Emergency changes.

The CEO or Head of Operations may declare additional freeze periods as needed. Freeze periods are communicated to the team at least 24 hours in advance (except for emergency freezes).

10. Version Control Requirements

10.1 Code

• All application source code must be stored in Git (GitHub).
• All changes to production code must be made via commits with descriptive messages.
• Direct edits to production code outside of version control are prohibited.
• Production deployments must reference a specific Git commit or tag.

10.2 Configuration

• CRM workflow and automation configurations must be documented when changed (screenshot or export).
• Infrastructure configurations (DNS, server settings, LaunchAgent plists) must be version-controlled or documented in the operations repository.
• Integration credentials and API keys are managed via environment variables in the deployment platform (Vercel), not in source code.

10.3 Documents

• All internal policies, SOPs, blueprints, and operational documents must carry a version number. Every edit increments the version.

11. Post-Implementation Review

11.1 Routine Review

All Normal changes classified as Medium or High Risk require a post-implementation review within 5 business days. The review covers:

• Was the change implemented as planned?
• Did the change achieve its intended outcome?
• Were there any unintended consequences?
• Are any follow-up actions required?

11.2 Emergency Change Review

All Emergency changes require a post-implementation review within 5 business days. The review additionally covers:

• Root cause of the emergency
• Whether the emergency could have been prevented
• Whether the emergency process was followed correctly
• Preventive measures for the future

11.3 Monthly Summary

A monthly summary of all changes (Standard, Normal, Emergency) is compiled and reviewed by the CEO or Head of Operations to identify trends, recurring issues, or process improvement opportunities.

12. Compliance

Failure to follow this policy may result in:

• Revocation of production access
• Disciplinary action
• Mandatory retraining on change management procedures

13. Related Policies

• Information Security Policy
• Access Control Policy
• Incident Response Policy
• Network Security Policy
• Data Protection and Privacy Policy

Document Control