At RevLab, we recognize that change is an integral part of maintaining a robust, reliable, and innovative IT environment. As a company entrusted with our customers' data and critical services, we are committed to ensuring that all changes to our IT systems, applications, infrastructure, and configurations are managed in a controlled, repeatable, and secure manner. The following IT Change Management Procedure outlines how changes are requested, evaluated, authorized, implemented, and monitored to minimize risks and ensure the highest levels of service continuity, security, and compliance.

​

Purpose and Objective

The purpose of this IT Change Management Procedure is to ensure that all changes to RevLab’s IT systems and infrastructure are authorized, documented, tested, and implemented in a way that:

​

• Protects the confidentiality, integrity, and availability of systems and data.

• Minimizes disruption to services and customers.

• Reduces risks associated with unauthorized or poorly executed changes.

• Ensures compliance with regulatory and industry standards, including SOC 1 and SOC 2 requirements.*

• Aligns with our commitment to providing an exceptional and secure experience for our customers.

​

Scope

This procedure applies to all changes made to RevLab’s IT systems, applications, databases, infrastructure, and configurations. This includes, but is not limited to:

​​

• Bug fixes

• New feature deployments

• System upgrades

• Configuration changes

• Patching

• Emergency fixes or updates

​

It applies to all RevLab employees, contractors, and third-party vendors involved in the management, development, or maintenance of IT systems and infrastructure.

​

Change Management Workflow

The IT Change Management process follows a standardized workflow to ensure consistency and accountability across all changes. The steps below outline the full lifecycle of a change request, from initiation to closure:

​

1. Change Request

• A change request is initiated and logged in the change management system (ticketing tool).

• The request must include detailed documentation, including:

  • Description of the change

  • Business justification

  • Impact assessment (e.g., risk to production, users, or customers)

  • Priority level

  • Stakeholders involved

  • Estimated timeline

​

2. Evaluation

• The change request is reviewed and assessed for:

  • Risk: How the change could impact system stability, security, or compliance.

  • Priority: Based on business needs and urgency.

  • Impact: Who will be affected (e.g., internal teams, customers) and the potential disruption to services.

​

3. Authorization

• The change is reviewed and authorized by the Change Advisory Board (CAB), IT management, or designated approvers.

• For small or low-risk changes, pre-approved processes may allow for expedited authorization.

• Emergency changes may bypass the full approval process but must be documented and reviewed retrospectively.

​

4. Planning

• A detailed change plan is created, including:

  • Requirements

  • Implementation steps

  • Testing strategy

  • Rollback plan (in case the change fails or causes unintended issues)

​

5. Peer Review

• All code changes are reviewed by a peer or independent reviewer to ensure:

  • Adherence to design and functionality requirements.

  • No security vulnerabilities or errors are introduced.

• Branch protection rules in the code repository enforce peer review before merging to the main branch.

​

6. Testing

• Manual and/or automated testing is conducted in a dedicated testing or staging environment. This includes:

  • Functional testing

  • Regression testing

  • Security vulnerability scanning

• If testing is not feasible (e.g., for emergency changes), a rollback plan must be documented and approved.

​

7. Approval for Deployment

• Once testing is complete and the change is validated, final approval is granted for deployment to production by IT management or the CAB.

​

8. Implementation

• The approved change is deployed to the production environment during a scheduled maintenance window, if applicable.

• Implementation is monitored for any issues or unexpected behavior.

​

9. Post-Implementation Review

• A post-implementation review is conducted to confirm:

  • The change functions as intended in the production environment.

  • No adverse effects occurred during deployment.

  • Any lessons learned are documented for future improvements.

​

10. Communication

• Internal and external stakeholders are notified of the change, as appropriate.

• Release notes are documented and shared to provide transparency about the update.

​

11. Closure

• Once the change has been successfully implemented and all documentation is complete, the change ticket is formally closed.

​

Emergency Changes​

Emergency changes follow an expedited version of the standard workflow to address critical issues that could impact business operations or security.

• Emergency changes must be documented in the change management system.

• Approval for emergency changes may be obtained retrospectively, but a rollback plan must always be in place.

• Emergency changes are reviewed after implementation to ensure compliance with change management policies.

​

Roles and Responsibilities​

To ensure accountability and segregation of duties, the following roles are defined in the IT Change Management process:

• Change Requestor: Responsible for initiating the change request and providing all required documentation.

• Change Approvers (CAB/IT Management): Responsible for reviewing, authorizing, and prioritizing change requests based on risk and impact.

• Change Implementer: Responsible for developing, testing, and deploying the approved change.

• Change Reviewer: Responsible for conducting peer reviews of code changes and ensuring compliance with standards.

• Change Manager: Oversees the end-to-end process, coordinates communication, and ensures proper documentation.

​

Key Controls​

The following controls are in place to mitigate risks and ensure the effectiveness of the IT Change Management process:

• Defined roles and responsibilities to maintain segregation of duties.

• Use of IT change management tools, including ticketing systems, code repositories (with version control), and automated testing tools.

• Separate environments for development, testing, staging, and production.

• Branch protection rules enforcing peer review and approval before deployment.

• Restricted access to production environments and systems.

• Comprehensive logging and audit trails for all changes.

• Post-implementation reviews to validate changes and identify lessons learned.

• Annual review of the IT Change Management Policy and Procedure to ensure alignment with industry standards and evolving business needs.

​

Continuous Improvement​

At RevLab, we are committed to continuous improvement. Our IT Change Management process is regularly evaluated and updated to reflect new threats, evolving technologies, and industry best practices. By embracing a culture of adaptability and innovation, we ensure that our systems remain secure, reliable, and aligned with our customers’ needs.

​

Conclusion​

Effective IT Change Management is essential to maintaining the trust and confidence of our customers and stakeholders. At RevLab, we have designed a structured, yet flexible, process to manage system changes while minimizing risk and disruption. By adhering to this procedure, we ensure that changes are executed in a secure, controlled, and compliant manner, supporting our mission to deliver innovative and reliable AI-cloud services.

​

​

* RevLab is presenting undergoing ISO27001 Security Management Standard certification and anticipates completion and certification in 2025.

​