Free Change Management Policy Builder

1. Purpose

This policy establishes requirements and procedures for managing changes to production systems and infrastructure. The goal is to implement changes safely, minimize service disruptions, maintain system integrity, and satisfy SOC 2 compliance requirements.

2. Scope

Applies to all changes affecting production systems, infrastructure, applications, databases, network configurations, and security controls. Includes code deployments, infrastructure modifications, configuration updates, and emergency changes. Covers all personnel involved in planning, approving, implementing, or testing changes.

3. Roles

• Chief Technology Officer (CTO) – owns this policy, approves major architectural changes, oversees change management process
• Change Advisory Board (CAB) – reviews and approves high-risk changes, evaluates change impact, provides cross-functional input
• Engineering Managers – review and approve changes from their teams, ensure testing is complete, verify rollback plans
• Change Requestor – documents change requirements, impact assessment, testing plan, and rollback procedures
• Change Implementor – executes approved changes, follows documented procedures, records deployment details
• DevOps/SRE Team – maintains change management tools, monitors deployments, assists with rollbacks if needed

4. Core Principles

• Document everything – all changes must be tracked in the change management system
• Test before deploying – changes must pass testing before production deployment
• Segregation of duties – change approvers must be independent from implementors
• Communicate impact – customer-facing changes must be communicated proactively
• Plan for failure – every change needs a documented rollback plan

5. Change Classification

Standard Changes (Low Risk)

• Pre-approved routine changes with established procedures
• Minor configuration updates, routine security patches
• Well-documented, low-risk, repeatable procedures
• Approval: Engineering Manager approval required
• Examples: Applying OS security patches, updating SSL certificates, routine database maintenance

Normal Changes (Medium Risk)

• Most application and infrastructure changes
• Code deployments, feature releases, configuration modifications
• Changes with moderate business or technical impact
• Approval: Engineering Manager + DevOps Lead approval required
• Examples: Feature releases, API changes, infrastructure scaling, dependency upgrades

Major Changes (High Risk)

• Significant architectural changes, major system upgrades
• Changes affecting multiple systems or customer-facing services
• High business impact or technical complexity
• Approval: CAB approval required (includes CTO, Security, Product, Operations)
• Examples: Database migrations, infrastructure redesigns, major version upgrades, security architecture changes

Emergency Changes

• Urgent changes required to resolve critical production issues
• Security vulnerabilities requiring immediate remediation
• Approval: CTO or designated on-call executive approval
• Post-implementation: Full change documentation and CAB review within 48 hours

6. Change Management Workflow

All changes must follow this workflow:

Step 1: Change Request

Create change request in change management system (Jira, ServiceNow, GitHub, etc.) including:

• Change description and business justification
• Change type (Standard, Normal, Major, Emergency)
• Systems affected and dependencies
• Implementation plan with step-by-step procedures
• Rollback plan if deployment fails
• Testing completed (unit tests, integration tests, staging validation)
• Risk assessment and mitigation strategy
• Customer impact analysis
• Proposed implementation date and time

Step 2: Testing

• All changes must pass testing in non-production environment before production deployment
• Test results documented and attached to change request
• Failed tests must be resolved before proceeding to approval

Step 3: Approval

• Standard Changes: Engineering Manager approval
• Normal Changes: Engineering Manager + DevOps Lead
• Major Changes: CAB approval (CTO, Security Lead, Product Lead, Operations Lead)
• Emergency Changes: CTO or on-call executive
• Approvers must be independent of requestor and implementor

Step 4: Implementation

• Changes implemented only by authorized personnel
• Follow documented implementation procedures
• Record actual start time, completion time, and any deviations
• Maintain audit trail in change management system

Step 5: Verification

• Verify change was successful and systems are operating normally
• Conduct smoke tests and health checks
• Monitor logs and metrics for anomalies
• If verification fails, execute rollback plan immediately

Step 6: Documentation

• Update change request with deployment results
• Document any issues encountered and resolutions
• Close change request only after verification is complete
• Retain change records for minimum 3 years

7. Segregation of Duties

• Change Requestor: Person requesting the change
• Change Approver: Must be different from requestor and implementor
• Change Implementor: Person deploying the change (can be same as requestor)

Key Rule: The person approving the change must be independent from both the person requesting it and the person implementing it. For small teams, this may require dual approval from two different engineering managers.

8. Communication Requirements

Internal Communication

• All changes communicated to relevant engineering teams via Slack/email 24 hours in advance
• Major changes announced in company-wide engineering meeting
• Emergency changes announced immediately to all affected teams

External/Customer Communication

• Customer-Impacting Changes: Published on status page (status.yourcompany.com) at least 48 hours in advance
• Maintenance Windows: Scheduled during lowest-traffic periods, communicated 1 week in advance
• Emergency Maintenance: Status page updated immediately with estimated duration and impact
• Post-Change: Status page updated with "All systems operational" after successful deployment

9. Change Advisory Board (CAB)

The CAB meets weekly to review upcoming major changes and monthly to review change metrics.

CAB Members:

• Chief Technology Officer (Chair)
• VP of Engineering
• Director of Security
• Director of Product
• Director of Operations
• Principal Engineers (as needed for specific changes)

CAB Responsibilities:

• Review and approve major changes before implementation
• Evaluate change risk and impact assessments
• Ensure adequate testing and rollback procedures
• Review emergency changes implemented since last meeting
• Analyze change metrics and failure rates
• Recommend improvements to change management process

10. Emergency Changes

Emergency changes are permitted to resolve critical production issues or security vulnerabilities:

• Approval: CTO or designated on-call executive must approve before implementation
• Documentation: Create change request documenting the emergency and actions taken
• Implementation: Follow rollback procedures to the extent possible given time constraints
• Post-Implementation Review: Complete full change documentation within 24 hours
• CAB Review: Present emergency change to CAB at next meeting for retrospective approval

Emergency Change Criteria:

• Critical production outage affecting customers
• Security vulnerability requiring immediate patching
• Data integrity issue requiring urgent remediation
• Regulatory compliance issue requiring immediate fix

11. Rollback Procedures

Every change must include a documented rollback plan:

• Rollback Triggers: Define specific criteria for initiating rollback (error rates, performance degradation, failed health checks)
• Rollback Steps: Document exact steps to revert the change
• Rollback Testing: Verify rollback procedures work in staging before production deployment
• Decision Authority: Engineering Manager or on-call engineer authorized to initiate rollback
• Rollback Time: All changes should be reversible within 15 minutes

12. Change Management Tools

Changes are tracked in our change management system:

• Primary Tool: [Jira/ServiceNow/GitHub Projects] for change requests and approvals
• Deployment Tracking: [GitHub Actions/Jenkins/CircleCI] for deployment automation and logs
• Status Page: [Statuspage.io/Custom] for customer communication
• Documentation: [Confluence/Notion] for change procedures and runbooks

13. Metrics and Monitoring

The CAB tracks the following metrics monthly:

• Change Volume: Number of changes by type (Standard, Normal, Major, Emergency)
• Change Success Rate: Percentage of changes completed without rollback
• Failed Changes: Number of changes requiring rollback and root causes
• Emergency Changes: Frequency and reasons for emergency changes
• Approval Time: Average time from request to approval
• Change-Related Incidents: Production incidents caused by changes

Success Criteria: 95% change success rate, less than 10% emergency changes

14. Training Requirements

• All engineers complete change management training during onboarding
• Engineering managers receive CAB training and change approval procedures
• Annual refresher training on change management policy and procedures
• New change management tools require training before rollout

15. Exceptions

Exceptions to this policy require CTO approval with documented business justification, compensating controls, and risk acceptance. Emergency changes are the only pre-approved exception, subject to post-implementation review.

16. Enforcement

Unapproved changes to production systems or failure to follow change management procedures may result in revocation of production access and management review.

17. References

• SOC 2 – System Operations and Change Management Controls
• [Your Company] Information Security Policy
• [Your Company] Deployment Procedures
• [Your Company] Incident Response Plan
• [Your Company] Access Management Policy

18. Revision History

Date	Version	Author	Description
[Date]	1.0	Chief Technology Officer	Initial release