# Standard Operating Procedure: Change Management

| Document ID | SOP-CHG-001 |
|-------------|-------------|
| Title | IT Change Management Process |
| Revision | 1.0 |
| Effective Date | [DATE] |
| Author | [AUTHOR] |
| Approved By | [APPROVER] |
| Department | IT Operations |

---

## 1. Purpose

To establish a controlled process for managing changes to IT infrastructure, applications, and services to minimize risk and ensure stability while enabling business agility.

## 2. Scope

This procedure applies to all changes to:
- Production servers and network infrastructure
- Databases and storage systems
- Applications and software
- Security configurations
- Cloud infrastructure and services
- Network and firewall rules

## 3. Responsibilities

### 3.1 Change Requester
- Submit complete RFC with business justification
- Coordinate with stakeholders
- Verify change success post-implementation

### 3.2 Change Manager
- Review and classify changes
- Schedule CAB meetings
- Track change metrics

### 3.3 Change Advisory Board (CAB)
- Review and approve/reject changes
- Assess risk and impact
- Prioritize conflicting changes

### 3.4 Technical Implementer
- Develop implementation plan
- Execute approved changes
- Document results

## 4. Definitions

| Term | Definition |
|------|------------|
| RFC | Request for Change - formal change proposal |
| CAB | Change Advisory Board - approval committee |
| ECAB | Emergency CAB - expedited approval for urgent changes |
| PIR | Post-Implementation Review |

## 5. Change Categories

### 5.1 Standard Changes
Pre-approved, low-risk, routine changes:
- Password resets
- User account creation
- Approved software installations
- Scheduled maintenance activities

### 5.2 Normal Changes
Require CAB review and approval:
- Application deployments
- Server configuration changes
- Network modifications
- Database changes

### 5.3 Emergency Changes
Require ECAB approval, used only for:
- Security incidents requiring immediate response
- Critical system failures
- Regulatory compliance issues

## 6. Procedure

### 6.1 Change Request Submission

1. **Complete RFC Form** (FRM-CHG-001)
   - Description of change
   - Business justification
   - Risk assessment
   - Implementation plan
   - Rollback plan
   - Testing plan
   - Affected systems/users

2. **Submit RFC**
   - Submit via ticketing system
   - Attach all supporting documentation
   - Identify change window preference

### 6.2 Change Assessment

| Risk Level | Criteria | Approval Required |
|------------|----------|-------------------|
| Low | Single system, no downtime, easy rollback | Change Manager |
| Medium | Multiple systems, planned downtime, tested rollback | CAB |
| High | Critical systems, extended downtime, complex rollback | CAB + Management |

### 6.3 CAB Review Process

1. **Pre-CAB Preparation**
   - Review all pending RFCs
   - Verify completeness
   - Identify conflicts with other changes

2. **CAB Meeting Agenda**
   - Review of failed/problematic changes
   - Assessment of new RFCs
   - Scheduling of approved changes
   - Review of change calendar

3. **Decision Outcomes**
   - **Approved**: Proceed as planned
   - **Approved with conditions**: Requires modifications
   - **Deferred**: Reschedule for later review
   - **Rejected**: Not approved, requires rework

### 6.4 Change Implementation

1. **Pre-Implementation**
   - [ ] Approval documented in ticket
   - [ ] Stakeholders notified
   - [ ] Backup completed
   - [ ] Rollback plan ready
   - [ ] Monitoring in place

2. **During Implementation**
   - [ ] Follow implementation plan exactly
   - [ ] Document each step
   - [ ] Test at defined checkpoints
   - [ ] Communicate status updates

3. **Post-Implementation**
   - [ ] Verify change success
   - [ ] Update documentation
   - [ ] Close RFC with results
   - [ ] Schedule PIR if required

### 6.5 Rollback Criteria

Initiate rollback if:
- Change causes unplanned outage
- Functionality fails verification
- Security vulnerability introduced
- Performance degradation exceeds threshold
- Change window expiring with incomplete work

### 6.6 Emergency Change Process

1. Obtain verbal ECAB approval (minimum 2 members)
2. Document decision and justification
3. Implement with minimal viable scope
4. Complete formal RFC within 24 hours
5. Conduct PIR for all emergency changes

## 7. Change Freeze Periods

No non-emergency changes permitted during:
- Month-end/quarter-end processing
- Major business events
- Holiday periods (as defined)
- Audit periods

## 8. Metrics and Reporting

| Metric | Target |
|--------|--------|
| Change success rate | >95% |
| Emergency change ratio | <5% |
| Unauthorized changes | 0 |
| Average approval time | <3 business days |

## 9. Related Documents

- FRM-CHG-001 Request for Change Form
- FRM-CHG-002 CAB Meeting Minutes
- SOP-INC-001 Incident Response Procedure

---

## Revision History

| Rev | Date | Description | Author |
|-----|------|-------------|--------|
| 1.0 | [DATE] | Initial release | [AUTHOR] |