Change Management Request Form
Purpose
A structured change request form for model updates with impact assessment, testing evidence, and approval chain.
Related Controls
1. Change Request Information
Capture essential metadata about the change request.
Change Request ID: CR-[NNN]
Date Submitted: [DATE]
Requestor: [NAME], [ROLE TITLE], [DEPARTMENT]
System Affected: [SYSTEM NAME]
Change Type: Model Update / Configuration Change / Prompt Modification / Integration Change / Infrastructure Change
Priority: Low / Medium / High / Emergency
Requested Implementation Date: [DATE]
Change Window: [START TIME] — [END TIME]
2. Change Description & Rationale
Describe what is changing and why the change is needed.
Description of Change
[Provide a clear, specific description of what is being changed. Include model versions, configuration values, prompt modifications, or other technical details.]
Business Rationale
[Explain why this change is needed — business driver, bug fix, performance improvement, security patch, regulatory requirement.]
Expected Outcome
[What measurable improvement or fix will this change deliver? How will success be measured?]
Alternatives Considered
- [ALTERNATIVE — Why rejected]
- [ALTERNATIVE — Why rejected]
- No change — [Impact of not making this change]
3. Impact Assessment
Evaluate the scope and risk of the proposed change.
Scope of Impact
- Users affected: [Number / groups / all]
- Systems affected: [List downstream systems]
- Data affected: [Data types, volumes]
- Service disruption expected: Yes / No — If yes, duration: [ESTIMATE]
Risk Assessment
- Risk of change: Low / Medium / High
- Risk of not changing: Low / Medium / High
- Potential failure modes:
1. [FAILURE MODE — Likelihood — Impact]
2. [FAILURE MODE — Likelihood — Impact]
Performance Impact
- Latency change: Expected [increase/decrease/no change] by [X]ms
- Throughput change: Expected [increase/decrease/no change] by [X]%
- Resource utilization change: [DESCRIPTION]
4. Testing Summary
Document evidence that the change has been tested.
Tests Completed
- [ ] Unit tests — [X/Y] passing
- [ ] Integration tests — [X/Y] passing
- [ ] AI-specific tests (prompt injection, output quality, bias) — [X/Y] passing
- [ ] Performance/load tests — meets SLA targets
- [ ] Regression tests — no regressions detected
- [ ] User acceptance testing — approved by [NAME]
Test Environment
- Tested in: [ENVIRONMENT NAME]
- Test data representative of production: Yes / No
- Test duration: [DURATION]
Test Evidence
[Link to test results, dashboards, or attach screenshots]
5. Rollback Plan
Define exactly how to revert this change if problems occur.
Rollback Procedure
- [STEP — e.g., "Revert model version to v[PREVIOUS] via deployment pipeline"]
- [STEP — e.g., "Restore previous configuration from backup"]
- [STEP — e.g., "Verify system health via monitoring dashboard"]
- [STEP — e.g., "Notify stakeholders of rollback"]
Rollback Trigger Criteria
- Error rate exceeds [X]% for more than [Y] minutes
- Latency exceeds [X]ms at p95 for more than [Y] minutes
- Any security alert triggered
- Customer-reported issues exceeding [X] within first hour
Rollback Owner
- Primary: [NAME] — [PHONE]
- Backup: [NAME] — [PHONE]
Estimated Rollback Time:** [X] minutes
6. Approval Chain
Track approvals from all required reviewers.
| Role | Name | Decision | Date | Comments |
|---|---|---|---|---|
| Peer Reviewer | [NAME] | Approve / Reject | [DATE] | |
| Technical Lead | [NAME] | Approve / Reject | [DATE] | |
| Security Review | [NAME] | Approve / Reject | [DATE] | |
| System Owner | [NAME] | Approve / Reject | [DATE] | |
| Change Manager | [NAME] | Approve / Reject | [DATE] |
Emergency Change Addendum
For emergency changes (P1 production incidents), the following expedited process applies:
- Verbal approval from System Owner + Security is sufficient to proceed
- Written approvals must be completed within 24 hours post-implementation
- Emergency change review must be conducted within 5 business days
- All emergency changes are reported to the AI Governance Committee at the next meeting