Change Management Policy

Document owner: VP Engineering, with CISO as co-owner Version: 3.0 Effective date: January 1, 2026 Last updated: January 15, 2026 Classification: Public — Trust Center Review cadence: Annual review; updates as needed for significant process changes Company: Acme Cloud, Inc. Address: 1200 Market Street, Suite 400, San Francisco, CA 94103, USA Primary contacts: trust@acmecloud.com | security@acmecloud.com | privacy@acmecloud.com

---

Definitions and Key Terms

Term	Definition
Change	Any addition, modification, or removal of anything that could have an effect on IT services, configurations, or infrastructure components
Change Management	The process responsible for controlling the lifecycle of all changes, enabling beneficial changes with minimum disruption to IT services
Change Advisory Board (CAB)	A group that supports the assessment, prioritization, authorization, and scheduling of changes
Emergency Change Advisory Board (ECAB)	A subset of CAB authorized to make rapid decisions on emergency changes
Request for Change (RFC)	A formal proposal for a change to be made, containing all information required to assess and approve the change
Change Window	Pre-approved time periods during which changes may be implemented with reduced risk
Change Freeze	A period during which changes are restricted or prohibited, typically around high-risk business periods
Rollback	The process of reversing a change to restore the previous state
Forward Schedule of Changes (FSC)	A schedule containing details of all approved changes and their proposed implementation dates
Post-Implementation Review (PIR)	A review conducted after a change has been implemented to verify it has met its objectives
Configuration Item (CI)	Any component that needs to be managed to deliver an IT service
Configuration Management Database (CMDB)	A database containing information about configuration items and their relationships
Impact Assessment	Evaluation of the potential effects of a proposed change on services, infrastructure, and business operations
Standard Change	A pre-authorized change that is low risk, relatively common, and follows an established procedure
Normal Change	A change that follows the standard change management process requiring CAB assessment
Emergency Change	A change that must be implemented as quickly as possible to resolve an incident or prevent imminent failure
Major Change	A high-risk or high-impact change requiring extended assessment and executive approval
Blue-Green Deployment	A deployment technique using two identical production environments to enable zero-downtime releases
Canary Release	A deployment technique where changes are gradually rolled out to a subset of users before full deployment
Feature Flag	A technique allowing features to be enabled or disabled without deploying new code
Immutable Infrastructure	Infrastructure components that are replaced rather than modified for changes

---

Scope and Purpose

This Change Management Policy establishes the processes, controls, and responsibilities for managing changes to Acme Cloud, Inc.'s production systems, infrastructure, applications, and services. The policy applies to all changes that could affect the confidentiality, integrity, or availability of customer data, production services, or security controls. The purpose is to ensure that standardized methods and procedures are used for efficient and prompt handling of all changes, minimizing the impact of change-related incidents upon service quality, and improving day-to-day operations.

In-Scope Systems and Changes

Category	Examples	Change Types
Production Applications	Customer-facing SaaS platform, APIs, web applications	Code deployments, configuration changes, feature releases
Production Infrastructure	AWS resources, databases, networking, load balancers	Infrastructure modifications, scaling, region changes
Security Systems	WAF, authentication services, encryption, monitoring	Security configurations, access control changes, certificate rotations
Database Systems	PostgreSQL (RDS), Redis, Elasticsearch	Schema changes, index modifications, replication changes
Integration Points	Third-party APIs, webhooks, SSO configurations	API version changes, endpoint modifications, authentication updates
Monitoring & Observability	Datadog, alerting rules, dashboards	Alert threshold changes, monitoring coverage changes
Development Infrastructure	CI/CD pipelines, build systems, staging environments	Pipeline changes, build configuration, test infrastructure
Corporate IT	Identity providers, productivity tools, access management	User provisioning, policy changes, tool configuration

Out-of-Scope

Category	Governance
Customer-side configurations	Customer responsibility per shared responsibility model
Development environment (non-production)	Standard development practices; not subject to CAB
Documentation updates	Content management processes
Non-technical business processes	Business process governance

---

Change Categories and Classifications

Change Type Classification

Change Type	Definition	Approval Authority	Lead Time	Documentation
Standard Change	Pre-authorized, low-risk, routine changes following established procedures	Pre-approved by CAB	None required	Template-based RFC
Normal Change	Changes requiring assessment and approval following standard process	CAB	Minimum 24 hours	Full RFC
Major Change	High-risk or high-impact changes requiring extended review	CAB + Executive Sponsor	Minimum 5 business days	Full RFC + Impact Assessment
Emergency Change	Urgent changes to restore service or prevent imminent failure	ECAB (reduced quorum)	Immediate	Retroactive RFC within 24 hours

Risk Classification Matrix

Risk Level	Criteria	Approval Requirements	Rollback Plan	Testing Requirements
Low	No customer impact; single component; automated rollback; <5 minutes execution	Change Lead	Automated	Automated tests pass
Medium	Limited customer impact; multiple components; manual rollback possible; <30 minutes	CAB approval	Documented manual procedure	Staging validation
High	Potential service disruption; critical systems; complex rollback; >30 minutes	CAB + CISO	Tested rollback procedure	Full regression
Critical	Security impact; data integrity risk; production database changes; irreversible	CAB + CTO + CISO	Verified rollback with backup	Full regression + canary

Impact Classification

Impact Level	Customer Effect	Affected Scope	Example Changes
Minimal	No noticeable customer impact	Single non-critical component	Log level change, dashboard update
Low	Degraded non-critical functionality	Single feature or endpoint	Minor UI change, error message update
Medium	Degraded critical functionality	Multiple features or single critical system	API response format change, authentication flow update
High	Service interruption or data access impact	Core platform or multiple critical systems	Database schema change, infrastructure migration
Critical	Complete service outage or data integrity risk	Entire platform	Major version upgrade, security vulnerability remediation

---

Change Advisory Board (CAB)

CAB Composition

Role	Member	Responsibilities	Voting
CAB Chair	VP Engineering	Meeting facilitation; final decision authority; conflict resolution	Yes
Security Representative	CISO or designee	Security impact assessment; compliance verification	Yes
SRE Lead	Director of SRE	Operations impact; availability assessment; rollback planning	Yes
Engineering Lead	Principal Engineer (rotating)	Technical assessment; implementation guidance	Yes
Product Representative	Product Manager (rotating)	Customer impact assessment; release coordination	Advisory
QA Representative	QA Lead	Testing coverage assessment; quality verification	Advisory
Scribe	Designated team member	Documentation; action tracking	No

CAB Meeting Schedule

Meeting Type	Frequency	Duration	Quorum Requirements	Purpose
Regular CAB	Weekly (Tuesday)	60 minutes	VP Engineering + 2 voting members	Review and approve normal/major changes
Ad-hoc CAB	As needed	30 minutes	VP Engineering + 1 voting member	Urgent but non-emergency changes
ECAB	As triggered	15 minutes	Any 2 voting members	Emergency change authorization
CAB Review	Monthly	90 minutes	All voting members	Process review; metrics analysis; improvement planning

CAB Decision Authority

Change Type	Approval Requirements	Escalation Path
Normal (Low Risk)	2 voting members including Change Lead	VP Engineering
Normal (Medium Risk)	CAB majority (3 of 4 voting members)	VP Engineering + CISO
Major	CAB majority + Executive Sponsor	CTO
Emergency	ECAB (2 voting members)	VP Engineering + CISO
Security-Impacting	Must include CISO approval	CTO
Data Schema Changes	Must include SRE Lead approval	VP Engineering

---

Change Management Process

Standard Change Process

Standard changes are pre-authorized changes that follow documented procedures and require minimal assessment.

Phase	Activities	Owner	Duration
Identification	Confirm change matches standard change catalog entry	Change Requester	N/A
Request	Create RFC using standard change template; auto-approved	Change Requester	5 minutes
Implementation	Execute change following documented procedure	Change Implementer	Per procedure
Verification	Confirm successful implementation per checklist	Change Implementer	Per procedure
Closure	Close RFC; update CMDB if applicable	Change Requester	5 minutes

Standard Change Catalog

Standard Change ID	Description	Procedure	Risk Level	Auto-Approval
SC-001	Deploy application via CI/CD with passing tests	CI/CD pipeline execution	Low	Yes
SC-002	Certificate rotation (automated)	Certificate manager automation	Low	Yes
SC-003	Add non-sensitive environment variable	Environment configuration procedure	Low	Yes
SC-004	Scaling within pre-approved parameters	Auto-scaling policies	Low	Yes
SC-005	Feature flag toggle (existing flag)	Feature flag management procedure	Low	Yes
SC-006	Add monitoring alert (non-critical)	Alerting configuration procedure	Low	Yes
SC-007	Dependency update (patch version)	Dependency update procedure	Low	Yes
SC-008	DNS record addition (non-critical)	DNS management procedure	Low	Yes

Normal Change Process

Phase	Activities	Owner	Timeline
Request	Create RFC with required information; assign change lead	Change Requester	Day 1
Assessment	Impact assessment; risk classification; rollback planning	Change Lead	24-48 hours
Review	Technical review; security review if applicable	Peer reviewer	24 hours
Authorization	CAB review and approval	CAB	Next CAB meeting
Planning	Schedule implementation; notify stakeholders; prepare rollback	Change Lead	Pre-implementation
Implementation	Execute change within approved window	Change Implementer	Per schedule
Verification	Confirm successful implementation; execute validation tests	Change Implementer	Post-implementation
PIR	Post-implementation review for Medium/High risk	Change Lead	Within 5 days
Closure	Close RFC; update documentation; communicate completion	Change Lead	Within 24 hours

Emergency Change Process

Phase	Activities	Owner	Timeline
Declaration	Declare emergency; justify urgency; request ECAB	Incident Commander	Immediate
ECAB Convening	Assemble available ECAB members (minimum 2 voting)	On-call rotation	15 minutes
Rapid Assessment	Assess change impact; identify minimum viable change	Change Lead + ECAB	15-30 minutes
Authorization	ECAB approval with verbal authorization documented	ECAB	Immediate
Implementation	Execute emergency change with enhanced monitoring	Change Implementer	As needed
Stabilization	Verify service restoration; monitor for issues	Change Lead + SRE	Post-implementation
Documentation	Create retroactive RFC within 24 hours	Change Lead	24 hours
PIR	Mandatory post-implementation review	Change Lead	Within 3 days

---

Request for Change (RFC) Requirements

RFC Information Requirements by Change Type

Information Element	Standard	Normal	Major	Emergency
Change description	Required	Required	Required	Post-hoc
Business justification	Template	Required	Detailed	Post-hoc
Impact assessment	Pre-assessed	Required	Extended	Post-hoc
Risk classification	Pre-classified	Required	Required	Post-hoc
Implementation plan	Reference procedure	Required	Detailed	As available
Rollback plan	Reference procedure	Required	Tested plan	Best effort
Testing evidence	Pre-validated	Required	Extended validation	Post-hoc
Approval signatures	Auto-approved	CAB	CAB + Executive	ECAB verbal
Scheduled window	Any time	Approved window	Approved window	Immediate
Communication plan	N/A	As needed	Required	Incident comms

RFC Template Fields

Field	Description	Required For
RFC ID	Auto-generated unique identifier	All
Change Title	Brief descriptive title	All
Change Type	Standard/Normal/Major/Emergency	All
Risk Level	Low/Medium/High/Critical	All
Change Lead	Responsible individual	All
Implementation Team	Personnel involved in implementation	Normal, Major
Affected Systems	Configuration items impacted	All
Change Description	Detailed technical description	All
Business Justification	Why the change is needed	Normal, Major
Impact Assessment	Customer, service, and risk impact	Normal, Major
Implementation Plan	Step-by-step implementation procedure	Normal, Major
Rollback Plan	Steps to reverse the change	Normal, Major
Testing Summary	Tests performed and results	Normal, Major
Dependencies	Other changes or prerequisites	Normal, Major
Proposed Schedule	Implementation date and window	Normal, Major
Stakeholder Communication	Notification plan	Major
Approval Status	Authorization record	All

---

Implementation Standards

Change Windows

Window Type	Days	Hours (PT)	Purpose	Change Types Permitted
Primary Window	Tuesday-Wednesday	9:00 AM - 3:00 PM	Standard production changes	Normal, Major
Secondary Window	Monday, Thursday	10:00 AM - 2:00 PM	Lower-risk changes	Normal (Low-Medium risk)
Off-Hours Window	Wednesday	10:00 PM - 2:00 AM	High-impact changes requiring low traffic	Major
Emergency Window	Any	Any	Emergency changes only	Emergency
Prohibited Window	During freeze	N/A	No changes except emergency	Emergency only

Change Freeze Periods

Period	Duration	Rationale	Exceptions Process
Year-End Freeze	December 15 - January 5	Holiday period; reduced staffing	CTO approval required
Quarter-End Freeze	Last 3 business days of Q1-Q3	Financial close; customer reporting	VP Engineering + CISO approval
Major Customer Events	As announced	Customer-critical periods	VP Engineering approval

Deployment Strategies

Strategy	Description	Use Cases	Risk Level
Blue-Green	Deploy to inactive environment; switch traffic	Zero-downtime deployments; infrastructure changes	Medium
Canary	Deploy to small percentage of traffic; expand gradually	High-risk changes; feature validation	Medium-High
Rolling	Deploy incrementally across instances	Routine deployments; containerized workloads	Low-Medium
Feature Flags	Deploy code with feature disabled; enable progressively	Feature releases; A/B testing	Low
Immutable	Replace infrastructure entirely rather than modifying	Infrastructure changes; compliance-sensitive	Medium

Rollback Requirements

Risk Level	Rollback Requirements	Maximum Rollback Time
Low	Automated rollback or documented procedure	15 minutes
Medium	Documented and tested procedure; data backup if applicable	30 minutes
High	Tested procedure with dry run; verified backup; data validation	60 minutes
Critical	Tested procedure within 30 days; backup verification; staged rollback option	2 hours

---

Testing Requirements

Testing Matrix by Change Type

Testing Type	Standard	Normal (Low)	Normal (Medium/High)	Major
Unit Tests	Pre-validated	Required (pass)	Required (pass)	Required (pass)
Integration Tests	Pre-validated	Required (pass)	Required (pass)	Required (pass)
Security Scan	Pre-validated	As applicable	Required	Required
Staging Deployment	N/A	Optional	Required	Required
Performance Test	N/A	As applicable	Required for critical paths	Required
User Acceptance	N/A	N/A	As applicable	Required for UI changes
Rollback Test	Pre-validated	N/A	Required for High risk	Required
Canary Validation	N/A	N/A	Optional	Required for Critical

Pre-Deployment Checklist

Checkpoint	Description	Verification Method
CI Pipeline Pass	All automated tests passing	Pipeline status
Code Review Approved	Peer review completed and approved	PR approval
Security Scan Clear	No critical or high vulnerabilities	Scan report
Staging Validated	Change tested in staging environment	Validation checklist
Rollback Ready	Rollback procedure documented and artifacts available	Procedure review
Monitoring Configured	Relevant dashboards and alerts ready	Dashboard confirmation
Communication Sent	Stakeholders notified per communication plan	Notification record
Backup Verified	Required backups completed and verified	Backup confirmation

---

Monitoring and Communication

Change Notification Requirements

Audience	Change Type	Timing	Channel	Content
Engineering Team	All	24 hours before	Slack #engineering	Summary, timing, impact
SRE Team	Normal (Medium+), Major	48 hours before	Slack #sre + email	Full RFC details
Customer Success	Customer-impacting	72 hours before	Email + Slack	Customer communication plan
Customers	Service-affecting	Per communication plan	Status page, email	Status update
Executive Team	Major	5 days before	Email	Summary, risk, timeline

Implementation Monitoring

Monitoring Type	Trigger	Duration	Escalation
Real-Time Dashboards	All production changes	During implementation + 30 minutes	Anomaly detection
Enhanced Alerting	Medium+ risk changes	Implementation + 2 hours	Automatic paging
Extended Monitoring	High/Critical risk	Implementation + 24 hours	On-call team
Canary Metrics	Canary deployments	Until full rollout	Automatic rollback triggers

---

Post-Implementation Review

PIR Requirements

Change Type	PIR Required	PIR Timing	PIR Scope
Standard	No	N/A	N/A
Normal (Low)	Optional	As needed	Informal retrospective
Normal (Medium)	Yes	Within 5 business days	Standard PIR
Normal (High)	Yes	Within 3 business days	Extended PIR
Major	Yes	Within 5 business days	Extended PIR
Emergency	Yes	Within 3 business days	Extended PIR + Root Cause

PIR Content

Section	Content	Owner
Change Summary	What was changed and why	Change Lead
Implementation Results	Success/partial/failed; actual vs. planned timing	Change Implementer
Issues Encountered	Problems during implementation; workarounds applied	Implementation Team
Customer Impact	Any customer-visible effects	Customer Success
Metrics	Performance impact; error rate changes; availability impact	SRE
Lessons Learned	What worked well; what could be improved	All participants
Action Items	Follow-up tasks with owners and due dates	Change Lead

---

Metrics and Reporting

Key Performance Indicators

Metric	Definition	Target	FY2025 Actual
Change Success Rate	Successful changes / Total changes	>98%	99.2%
Emergency Change Rate	Emergency changes / Total changes	<5%	3.1%
Change-Related Incidents	Incidents caused by changes / Total changes	<2%	1.4%
Mean Time to Implement	Average time from approval to completion	<4 hours	2.8 hours
Rollback Rate	Rolled back changes / Total changes	<3%	1.8%
CAB Cycle Time	Time from RFC submission to CAB decision	<72 hours	48 hours
Post-Implementation Review Compliance	PIR completed on time / PIR required	>95%	97%
Change Backlog	Changes awaiting CAB approval	<20	12 average

Monthly Change Statistics (FY2025 Average)

Change Category	Count	Success Rate	Rollback Rate
Standard Changes	847	99.8%	0.2%
Normal Changes (Low Risk)	142	99.3%	0.7%
Normal Changes (Medium Risk)	38	97.4%	2.6%
Normal Changes (High Risk)	8	100%	0%
Major Changes	4	100%	0%
Emergency Changes	6	94.4%	5.6%
Total Monthly Average	1,045	99.2%	0.8%

---

Numbered Policy Statements

1. Universal Applicability: All changes to production systems, infrastructure, security controls, and customer-impacting services must follow this change management policy regardless of urgency or organizational level of the requester.

2. Classification Requirement: All changes must be classified by type (Standard, Normal, Major, Emergency) and risk level (Low, Medium, High, Critical) prior to implementation.

3. Authorization Mandate: No change may be implemented without appropriate authorization as defined by the change type and risk classification matrices in this policy.

4. Documentation Requirement: All changes must be documented in the change management system with a valid Request for Change (RFC) prior to implementation, except emergency changes which require retroactive documentation within 24 hours.

5. CAB Authority: The Change Advisory Board has authority to approve, defer, reject, or request modifications to all normal and major changes.

6. ECAB Emergency Authority: Emergency changes may be authorized by ECAB with reduced quorum (2 voting members) when immediate action is required to restore service or prevent imminent failure.

7. Testing Obligation: All changes affecting production systems must pass required testing validation appropriate to their risk level before implementation.

8. Rollback Readiness: All Normal and Major changes must have documented rollback procedures. High and Critical risk changes must have tested rollback procedures.

9. Change Window Compliance: Non-emergency changes must be implemented within approved change windows unless specific exception is granted by CAB.

10. Change Freeze Compliance: Changes during freeze periods require explicit exception approval per the exceptions process defined in this policy.

11. Post-Implementation Review: Changes classified as Medium risk or higher, and all emergency changes, require documented Post-Implementation Review within specified timeframes.

12. Incident Linking: Changes that cause incidents must be documented in the incident record, and incidents that require emergency changes must reference the emergency RFC.

13. Continuous Improvement: The change management process shall be reviewed monthly using metrics analysis and quarterly through process improvement initiatives.

14. Training Requirement: All personnel authorized to submit or implement changes must complete change management training annually and demonstrate understanding of this policy.

---

Framework Appendix

Compliance Mapping

Requirement	SOC 2 Criteria	ISO 27001 Control	HIPAA Provision	Implementation
Change authorization	CC8.1	A.12.1.2	§164.312(c)(1)	CAB approval process
Change documentation	CC8.1	A.12.1.2	§164.312(b)	RFC system
Change testing	CC8.1	A.12.1.4	§164.312(d)	Testing requirements
Segregation of duties	CC8.1	A.12.1.4	§164.312(a)(1)	Role separation
Emergency change process	CC8.1	A.12.1.2	§164.312(a)(2)(ii)	ECAB procedures
Change audit trail	CC8.1	A.12.1.2	§164.312(b)	Change logs

ITIL Alignment

ITIL Process	Policy Implementation	Process Owner
Change Management	Full process implementation	VP Engineering
Release Management	Deployment strategies; release coordination	Engineering Leads
Configuration Management	CMDB updates; CI tracking	SRE
Incident Management	Emergency change linkage	Security + SRE
Problem Management	PIR integration; root cause analysis	Engineering

---

Related Trust Center documents

incident response, security overview, sdlc policy, access control, business continuity, compliance frameworks

---

Document revision history

Version	Date	Author	Summary of changes
1.0	2024-06-01	Legal & Compliance	Initial Trust Center publication
2.0	2025-03-15	GRC Program	SOC 2 Type II alignment refresh; expanded subprocessors
2.5	2025-09-01	Security Engineering	Encryption standards update; ISO 27001 mapping
3.0	2026-01-15	Trust Center Program	Full procurement-grade expansion; 34-document set

---

Contact

Acme Cloud, Inc. 1200 Market Street, Suite 400 San Francisco, CA 94103, USA

Channel	Email	Use case
Trust & procurement	trust@acmecloud.com	Security questionnaires, trust reviews
Security	security@acmecloud.com	Incidents, vulnerabilities, control questions
Privacy	privacy@acmecloud.com	DSRs, privacy assessments
Legal	legal@acmecloud.com	Contractual, DPA, legal notices

---

Change Management Contacts

Contact	Role	Availability	Use Case
change-management@acmecloud.com	CAB Administration	Business hours	RFC questions, process guidance
VP Engineering	CAB Chair	Business hours	Escalations, exceptions
CISO	Security approval	Business hours + on-call	Security-impacting changes
SRE On-Call	Emergency changes	24/7	ECAB activation, emergency implementation

---

Appendix: Change Management Tools

Tool	Purpose	Integration
Jira Service Management	RFC creation and tracking; workflow automation	SSO; Slack notifications
GitHub	Code changes; PR-based reviews	CI/CD pipeline trigger
Datadog	Change monitoring; deployment tracking	Automatic deployment annotations
PagerDuty	ECAB notification; on-call routing	Automatic escalation
Slack	Real-time communication; change notifications	Bot integrations
Confluence	Procedure documentation; runbooks	Linked from RFCs

Document Version: 3.0 Last Updated: January 15, 2026