Change Management SOP¶

Purpose¶

This SOP defines the process for proposing, reviewing, approving, testing, and deploying changes to Trove's systems and infrastructure. It ensures that changes are made in a controlled, consistent, and documented way - reducing the risk of outages, security incidents, or data loss caused by poorly managed changes.

This process is a required control under SOC 2 and ISO 27001 and provides the audit trail needed to demonstrate that changes are reviewed and approved before reaching production.

Scope¶

This SOP applies to all changes to Trove's:

Application code and features
Infrastructure and cloud configuration (AWS, DuploCloud)
Third-party integrations and API connections
Security configurations and access controls
Platform content and configuration (e.g. storefront settings, system defaults)

It does not cover minor content edits, internal documentation updates, or changes to tools that do not interact with customer data or platform infrastructure.

Change Categories¶

All changes are classified into one of three categories:

Standard Change¶

A planned, low-risk change that follows the normal development and deployment workflow. This is the most common type.

Examples: - New features or enhancements - Bug fixes (non-urgent) - Dependency or library updates - Infrastructure configuration changes

Process: Full workflow - PR review → staging/development → CTO approval → production.

Emergency Change (Hotfix)¶

An urgent change required to resolve a critical issue that cannot wait for the standard workflow. Typically triggered by a P1 or P2 incident.

Examples: - Fixing a live production outage - Patching an actively exploited security vulnerability - Reverting a deployment that has caused critical failures

Process: Abbreviated workflow - CTO approves deployment directly to production. Full review and documentation completed retrospectively within 48 hours.

Infrastructure Change¶

A change to cloud infrastructure, environment configuration, or access controls that is not directly tied to a code deployment.

Examples: - AWS resource provisioning or decommissioning - DuploCloud environment configuration changes - IAM role or permission changes - SSL certificate renewals or updates

Process: Same as Standard Change - must be reviewed and approved by the CTO before being applied to production.

Standard Change Workflow¶

Step 1 - Raise a Pull Request¶

The engineer creates a pull request (PR) on GitHub with a clear description of: - What is being changed and why - Any risks or potential side effects - How the change has been tested locally

Step 2 - Peer Review¶

The PR is reviewed by at least one other engineer where possible. The reviewer checks for: - Code quality and correctness - Security considerations - Potential impact on other parts of the platform

Step 3 - CTO Approval¶

The CTO reviews and approves the PR before it is merged. For significant changes, the CTO may request additional testing or documentation before approving.

Step 4 - Deploy to Staging / Development¶

The approved change is deployed to the development/staging environment and tested to confirm it behaves as expected. This includes: - Functional testing of the changed feature or fix - Regression checks on related functionality - Confirmation that no unexpected side effects are introduced

Step 5 - CTO Sign-Off for Production¶

Once staging testing is complete, the CTO gives final sign-off for the change to be promoted to production.

Step 6 - Deploy to Production¶

The change is deployed to production following the workflow defined in the Git Branching & Deployment Workflow.

Step 7 - Post-Deployment Verification¶

After deployment, the engineer confirms the change is working correctly in production and monitors for any unexpected behaviour. Any issues are reported immediately.

Emergency Change (Hotfix) Workflow¶

The engineer notifies the CTO of the critical issue and proposed fix
The CTO approves the hotfix and authorises direct deployment to production
The fix is deployed and verified in production
Within 48 hours, the engineer documents the change retrospectively - including what was changed, why, and the approval received
A post-deployment review is conducted to assess whether the issue could have been prevented

See also: Deployment Windows & Release Policy for restrictions on deployments during the peak season freeze period. Emergency hotfixes that address live production issues are still permitted during the freeze.

Deployment Freeze¶

No standard changes or infrastructure changes may be deployed to production between October 1st and January 1st. This freeze period protects platform stability during peak gifting season.

Emergency changes remain permitted during the freeze with CTO approval.

See Deployment Windows & Release Policy for full details.

Change Log¶

All standard and infrastructure changes must be recorded. Emergency changes must be documented retrospectively within 48 hours.

Field	Detail
Date
Change type	Standard / Emergency / Infrastructure
Description
Systems affected
Raised by
Reviewed by
CTO approval
Staging tested	Yes / No / N/A
Deployed to production
Post-deployment verified	Yes / No
Issues encountered

Review Cycle¶

This SOP will be reviewed annually or when significant changes are made to Trove's development or deployment processes.

Last reviewed: April 2026 Owner: CTO