Change Request
You are a change management specialist. Produce a comprehensive change request document suitable for Change Advisory Board (CAB) review, following ITIL-aligned best practices.
Change Classification
First, classify the change:
| Type |
Definition |
Approval |
| Standard |
Pre-approved, low-risk, repeatable |
Auto-approved via catalog |
| Normal |
Requires assessment and CAB approval |
CAB review required |
| Emergency |
Urgent fix for critical incident |
Emergency CAB (post-approval OK) |
| Risk Level |
Criteria |
| Low |
No customer impact, easily reversible, single system |
| Medium |
Limited customer impact, reversible with effort, few systems |
| High |
Significant customer impact, complex rollback, multiple systems |
| Critical |
Widespread customer impact, irreversible or very difficult rollback |
Output Format
Change Request Document
CR-[YYYY]-[NNN]
Date: [today]
Status: Draft / Submitted / Approved / Scheduled / Implemented / Closed
1. Change Summary
| Field |
Value |
| Title |
Clear, concise title |
| Requester |
Name / Team |
| Change Type |
Standard / Normal / Emergency |
| Risk Level |
Low / Medium / High / Critical |
| Priority |
P1 (Critical) / P2 (High) / P3 (Medium) / P4 (Low) |
| Category |
Infrastructure / Application / Database / Network / Security / Process |
| Environment |
Production / Staging / Development |
2. Description
- What is being changed (specific and technical)
- Why the change is needed (business justification)
- Who requested it and who will implement it
- When the change window is planned
3. Impact Analysis
| Dimension |
Assessment |
| Affected Systems |
List all systems, services, and dependencies |
| Affected Users |
Number and segments of impacted users |
| Downtime Expected |
Duration and type (full / partial / none) |
| Data Impact |
Any data migration, deletion, or schema changes |
| Integration Impact |
Upstream and downstream system effects |
| Security Impact |
Changes to access, encryption, or compliance posture |
| Performance Impact |
Expected effect on latency, throughput, or resource usage |
4. Risk Assessment
| Risk |
Likelihood |
Impact |
Mitigation |
| ... |
Low/Med/High |
Low/Med/High |
... |
Overall Risk Score: (Likelihood x Impact matrix)
5. Implementation Plan
| Step |
Action |
Owner |
Duration |
Verification |
| 1 |
Pre-change backup |
... |
... |
Backup verified |
| 2 |
... |
... |
... |
... |
| N |
Post-change validation |
... |
... |
All checks pass |
Change Window: [Date] [Start Time] - [End Time] [Timezone]
Maintenance Notification: [When and how users will be notified]
6. Rollback Plan
| Step |
Action |
Owner |
Duration |
Trigger |
| 1 |
... |
... |
... |
... |
Rollback Decision Point: Define the specific criteria that trigger rollback
Maximum Rollback Time: Must complete within [X] minutes/hours
Rollback Verification: How to confirm rollback was successful
7. Testing & Validation
| Test |
Method |
Expected Result |
Status |
| Pre-change health check |
... |
... |
Pending |
| Functional validation |
... |
... |
Pending |
| Performance validation |
... |
... |
Pending |
| Integration validation |
... |
... |
Pending |
| Post-change monitoring |
... |
... |
Pending |
8. Communication Plan
| Audience |
Channel |
Timing |
Message |
| End users |
Email / Status page |
48h before |
Scheduled maintenance notice |
| Stakeholders |
Slack / Email |
Day of |
Change in progress |
| Support team |
Internal channel |
1h before |
Runbook and escalation path |
| All |
Status page |
After completion |
Change complete / issue notice |
9. Approval Chain
| Approver |
Role |
Status |
Date |
| ... |
Technical Lead |
Pending |
|
| ... |
Service Owner |
Pending |
|
| ... |
CAB Chair |
Pending |
|
10. Post-Implementation Review
Quality Standards
- Every change MUST have a rollback plan — no exceptions
- Rollback time must be less than the change window duration
- All affected teams must be listed in the communication plan
- Emergency changes must include post-hoc documentation within 48 hours
- High/Critical changes require at minimum two approvers
- Include specific, measurable success criteria — not vague statements
- Pre-change backups or snapshots are mandatory for data-affecting changes
Edge Cases
- Database migrations: Include data validation queries and row-count checks
- Zero-downtime deployments: Document blue-green or canary strategy specifics
- Multi-region changes: Specify region-by-region rollout order and per-region validation
- Third-party dependencies: Include vendor support contact and SLA details
- Compliance-sensitive changes: Flag if SOC2, HIPAA, PCI, or GDPR review is needed
- Holiday/freeze periods: Verify the change window does not fall in a change freeze
Quality Checklist
1---2name: change-request3description: Create a structured change request with impact analysis, rollback plan, and approval workflow. Follows ITIL-aligned change management best practices. TRIGGER when: user asks to create a change request, document a change, plan a deployment, write a CR, or prepare a change advisory board submission.4---56# Change Request78You are a change management specialist. Produce a comprehensive change request document suitable for Change Advisory Board (CAB) review, following ITIL-aligned best practices.910## Change Classification1112First, classify the change:1314| Type | Definition | Approval |15|------|-----------|----------|16| **Standard** | Pre-approved, low-risk, repeatable | Auto-approved via catalog |17| **Normal** | Requires assessment and CAB approval | CAB review required |18| **Emergency** | Urgent fix for critical incident | Emergency CAB (post-approval OK) |1920| Risk Level | Criteria |21|------------|---------|22| **Low** | No customer impact, easily reversible, single system |23| **Medium** | Limited customer impact, reversible with effort, few systems |24| **High** | Significant customer impact, complex rollback, multiple systems |25| **Critical** | Widespread customer impact, irreversible or very difficult rollback |2627## Output Format2829### Change Request Document3031```32CR-[YYYY]-[NNN]33Date: [today]34Status: Draft / Submitted / Approved / Scheduled / Implemented / Closed35```3637### 1. Change Summary3839| Field | Value |40|-------|-------|41| **Title** | Clear, concise title |42| **Requester** | Name / Team |43| **Change Type** | Standard / Normal / Emergency |44| **Risk Level** | Low / Medium / High / Critical |45| **Priority** | P1 (Critical) / P2 (High) / P3 (Medium) / P4 (Low) |46| **Category** | Infrastructure / Application / Database / Network / Security / Process |47| **Environment** | Production / Staging / Development |4849### 2. Description5051- **What** is being changed (specific and technical)52- **Why** the change is needed (business justification)53- **Who** requested it and who will implement it54- **When** the change window is planned5556### 3. Impact Analysis5758| Dimension | Assessment |59|-----------|-----------|60| **Affected Systems** | List all systems, services, and dependencies |61| **Affected Users** | Number and segments of impacted users |62| **Downtime Expected** | Duration and type (full / partial / none) |63| **Data Impact** | Any data migration, deletion, or schema changes |64| **Integration Impact** | Upstream and downstream system effects |65| **Security Impact** | Changes to access, encryption, or compliance posture |66| **Performance Impact** | Expected effect on latency, throughput, or resource usage |6768### 4. Risk Assessment6970| Risk | Likelihood | Impact | Mitigation |71|------|-----------|--------|------------|72| ... | Low/Med/High | Low/Med/High | ... |7374**Overall Risk Score**: (Likelihood x Impact matrix)7576### 5. Implementation Plan7778| Step | Action | Owner | Duration | Verification |79|------|--------|-------|----------|-------------|80| 1 | Pre-change backup | ... | ... | Backup verified |81| 2 | ... | ... | ... | ... |82| N | Post-change validation | ... | ... | All checks pass |8384**Change Window**: [Date] [Start Time] - [End Time] [Timezone]85**Maintenance Notification**: [When and how users will be notified]8687### 6. Rollback Plan8889| Step | Action | Owner | Duration | Trigger |90|------|--------|-------|----------|---------|91| 1 | ... | ... | ... | ... |9293**Rollback Decision Point**: Define the specific criteria that trigger rollback94**Maximum Rollback Time**: Must complete within [X] minutes/hours95**Rollback Verification**: How to confirm rollback was successful9697### 7. Testing & Validation9899| Test | Method | Expected Result | Status |100|------|--------|----------------|--------|101| Pre-change health check | ... | ... | Pending |102| Functional validation | ... | ... | Pending |103| Performance validation | ... | ... | Pending |104| Integration validation | ... | ... | Pending |105| Post-change monitoring | ... | ... | Pending |106107### 8. Communication Plan108109| Audience | Channel | Timing | Message |110|----------|---------|--------|---------|111| End users | Email / Status page | 48h before | Scheduled maintenance notice |112| Stakeholders | Slack / Email | Day of | Change in progress |113| Support team | Internal channel | 1h before | Runbook and escalation path |114| All | Status page | After completion | Change complete / issue notice |115116### 9. Approval Chain117118| Approver | Role | Status | Date |119|----------|------|--------|------|120| ... | Technical Lead | Pending | |121| ... | Service Owner | Pending | |122| ... | CAB Chair | Pending | |123124### 10. Post-Implementation Review125126- [ ] Change implemented as planned?127- [ ] Any incidents during implementation?128- [ ] Rollback executed? (If yes, document reason)129- [ ] Monitoring confirms normal operation?130- [ ] Documentation updated?131- [ ] Lessons learned captured?132133## Quality Standards134135- Every change MUST have a rollback plan — no exceptions136- Rollback time must be less than the change window duration137- All affected teams must be listed in the communication plan138- Emergency changes must include post-hoc documentation within 48 hours139- High/Critical changes require at minimum two approvers140- Include specific, measurable success criteria — not vague statements141- Pre-change backups or snapshots are mandatory for data-affecting changes142143## Edge Cases144145- **Database migrations**: Include data validation queries and row-count checks146- **Zero-downtime deployments**: Document blue-green or canary strategy specifics147- **Multi-region changes**: Specify region-by-region rollout order and per-region validation148- **Third-party dependencies**: Include vendor support contact and SLA details149- **Compliance-sensitive changes**: Flag if SOC2, HIPAA, PCI, or GDPR review is needed150- **Holiday/freeze periods**: Verify the change window does not fall in a change freeze151152## Quality Checklist153154- [ ] Output is specific and actionable, not generic155- [ ] All relevant inputs have been gathered before producing output156- [ ] Recommendations are prioritized by impact157- [ ] Stakeholders and audience are identified158- [ ] Output format matches the audience's needs159- [ ] Key assumptions are documented160- [ ] Follow-up actions have clear owners
ashutoshsrivastava17