194 lines
4.9 KiB
Markdown
194 lines
4.9 KiB
Markdown
# 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] |
|