Document ID: SOC2-CHG-001 | Version: 1.0 | Date: March 2026 | Classification: Internal | Owner: Head of Engineering / CISO
Purpose
This policy governs all changes to production systems, infrastructure, and configurations to ensure that changes are authorised, tested, and reviewed before deployment. It implements CC8.1 of the SOC 2 Common Criteria.
1. Change Categories
| Category | Description | Examples | Approval Required |
|---|---|---|---|
| Standard | Pre-approved, low-risk, routine change with established procedure | Dependency updates, certificate renewal, config value changes | Self-approved (engineer) |
| Normal | Non-emergency change requiring review before deployment | New feature releases, infrastructure changes, schema migrations | Engineering Lead + QA |
| Major | Significant change with broad system impact or customer-facing effect | New service deployment, authentication changes, pricing logic | Engineering Lead + CISO |
| Emergency | Urgent change to resolve critical incident or security vulnerability | Hotfix for P1 incident, critical CVE patch | CISO verbal approval; post-hoc documentation within 24 hours |
2. Normal Change Process
- Submit — Engineer opens a change request in [ticketing system] with: description, scope, risk assessment, testing plan, rollback plan
- Review — Engineering Lead reviews technical approach; Security reviews risk for changes affecting auth, data access, or encryption
- Test — Change deployed to staging environment; automated and manual tests run; sign-off from QA
- Schedule — Change scheduled in maintenance window (avoid peak hours); stakeholders notified ≥24 hours in advance
- Deploy — Change deployed with engineer and reviewer available during deployment window
- Verify — Post-deployment verification: smoke tests, monitoring checks, customer-facing functionality confirmed
- Close — Change ticket updated with outcome; any incidents or deviations documented
3. Required Gates Before Production
| Gate | Requirement |
|---|---|
| Code review | Minimum two reviewers; at least one senior engineer |
| Automated tests | CI pipeline must pass with no failing tests |
| Security scan | SAST scan must have no critical/high findings unaddressed |
| Staging validation | Change tested in staging under production-equivalent conditions |
| Rollback plan | Documented rollback procedure must exist before deployment |
| Approval | Required approvals obtained per change category |
4. Rollback Procedure
Every production change must have a documented rollback plan before deployment. The rollback plan must include:
- Trigger condition (when to roll back)
- Rollback steps (specific commands or procedures)
- Rollback owner (who executes the rollback)
- Verification steps (how to confirm rollback was successful)
- Rollback time estimate
If a rollback is executed, it must be documented as an incident (minimum P3) with a post-incident review.
5. Emergency Change Process
When a change must bypass the normal process (P1 incident, active exploitation of critical vulnerability):
- Obtain verbal approval from CISO (or Engineering Lead if CISO unavailable)
- Implement minimum change required to resolve the issue
- Document the change in the emergency change log within 24 hours
- Conduct post-hoc review within 5 business days
- File change record with retroactive sign-off from CISO
Emergency changes that bypass standard gates are tracked separately and included in quarterly change management reports.
6. Prohibited Practices
- Deploying directly to production without code review
- Using production credentials in development or test environments
- Bypassing CI/CD pipeline for production deployments
- Making undocumented changes to production infrastructure
- Using shared accounts for production deployments (all changes must be attributable)
7. Change Log
All production changes are logged with: change ID, description, author, approvers, deployment date, outcome, and any incidents triggered. Change logs are retained for a minimum of 3 years.
8. Review
This policy is reviewed annually. The change management process is assessed during the annual SOC 2 audit.
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | March 2026 | [Author] | Initial issue |