Change Request Form

Property	Value
Document ID	TPL-004
Version	1.0
Status	Draft
Owner	IT Operations Manager
Last Updated	2026-01-11
Next Review	2027-01-11
Related Controls	SOC 2: CC8.1 / ISO 27001: A.8.32

---

1. Purpose

This form documents change requests for information systems, ensuring proper authorization, testing, and approval before implementation. All production changes must be documented using this form or equivalent ticketing system.

---

2. When to Use

Use this form for:

• Application deployments
• Infrastructure changes
• Configuration changes
• Database changes
• Network changes
• Security changes
• Emergency changes (post-approval)

---

3. Change Request Form

Section A: Change Identification

Field	Value
Change ID	CHG-[YYYY]-[XXXX]
Request Date	_________________________________
Requestor Name	_________________________________
Requestor Email	_________________________________
Requestor Department	_________________________________

---

Section B: Change Classification

Change Type (select one):

Type	Description	Approval Required	☐
Standard	Pre-approved, low-risk, routine	Pre-approved	☐
Normal	Planned change, known risk	Manager + CAB (if needed)	☐
Emergency	Urgent fix for outage/security	Emergency approval (post-doc)	☐
Major	High-risk, significant impact	CAB + Executive	☐

Change Category (select one):

Category	☐
Application / Code Deployment	☐
Database Change	☐
Infrastructure (Servers/VMs)	☐
Network / Firewall	☐
Cloud Configuration	☐
Security / Access	☐
Integration / API	☐
Other: _____________	☐

---

Section C: Change Details

Change Title:

_____________________________________________________________________________

Description of Change: (What is being changed?)

_____________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________

Reason for Change: (Business justification)

_____________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________

Affected Systems/Services:

System/Service	Environment	Impact
	Prod / Stage / Dev
	Prod / Stage / Dev
	Prod / Stage / Dev

---

Section D: Schedule

Field	Value
Proposed Start Date/Time	_________________________________
Proposed End Date/Time	_________________________________
Estimated Duration	_________________________________
Maintenance Window	Yes / No
Downtime Expected	Yes / No
Downtime Duration	_________________________________

---

Section E: Risk Assessment

Risk Level (select one):

Level	Criteria	☐
Low	Minimal impact, easily reversible, no customer impact	☐
Medium	Some impact, reversible, limited customer impact	☐
High	Significant impact, complex rollback, customer impact	☐
Critical	Major impact, difficult rollback, widespread impact	☐

Risk Factors:

Factor	Yes/No	Details
Affects production?
Affects customer data?
Affects security controls?
Requires downtime?
First-time change?
Complex dependencies?

---

Section F: Implementation Plan

Pre-Implementation Steps:

#	Step	Owner	Duration
1
2
3

Implementation Steps:

#	Step	Owner	Duration
1
2
3
4
5

Post-Implementation Steps:

#	Step	Owner	Duration
1	Verify change successful
2	Monitor for issues
3	Notify stakeholders

---

Section G: Testing

Testing Completed:

Test Type	Completed	Date	Tester	Result
Unit tests	Yes / No / N/A			Pass / Fail
Integration tests	Yes / No / N/A			Pass / Fail
Staging deployment	Yes / No / N/A			Pass / Fail
Security scan	Yes / No / N/A			Pass / Fail
Performance test	Yes / No / N/A			Pass / Fail
User acceptance	Yes / No / N/A			Pass / Fail

Testing Evidence Location: ________________________________

---

Section H: Rollback Plan

Rollback Trigger: (What conditions would trigger rollback?)

_____________________________________________________________________________
_____________________________________________________________________________

Rollback Steps:

#	Step	Owner	Duration
1
2
3

Estimated Rollback Time: _________________________________

Rollback Verification: (How will we confirm rollback is complete?)

_____________________________________________________________________________

---

Section I: Communication

Stakeholders to Notify:

Stakeholder	Pre-Change	During	Post-Change	Method
Customers	Yes / No	Yes / No	Yes / No
Support Team	Yes / No	Yes / No	Yes / No
Engineering	Yes / No	Yes / No	Yes / No
Management	Yes / No	Yes / No	Yes / No

Communication Message (Pre-Change):

_____________________________________________________________________________
_____________________________________________________________________________

---

4. Approval Section

Section J: Approvals Required

Role	Required	Name	Approved	Date
Technical Lead	Yes		Yes / No
Security Review	Yes / No		Yes / No
Change Manager	Yes		Yes / No
CAB	Yes / No		Yes / No
Business Owner	Yes / No		Yes / No

CAB Meeting Date (if required): _________________________________

Approval Notes:

_____________________________________________________________________________
_____________________________________________________________________________

---

5. Implementation Record

Section K: Implementation Results

Field	Value
Actual Start Time	_________________________________
Actual End Time	_________________________________
Implemented By	_________________________________
Implementation Status	Success / Partial / Failed / Rolled Back

Implementation Notes:

_____________________________________________________________________________
_____________________________________________________________________________
_____________________________________________________________________________

Issues Encountered:

_____________________________________________________________________________
_____________________________________________________________________________

Post-Implementation Verification:

• Change verified working as expected
• No errors in logs
• Monitoring shows normal operation
• Affected users/stakeholders notified

---

Section L: Change Closure

Field	Value
Closure Date	_________________________________
Closed By	_________________________________
Final Status	Completed / Completed with Issues / Failed / Cancelled

Lessons Learned:

_____________________________________________________________________________
_____________________________________________________________________________

---

6. Emergency Change Section

For Emergency Changes Only

Section M: Emergency Justification

Field	Value
Nature of Emergency	_________________________________
Business Impact if Not Implemented	_________________________________
Verbal Approval Obtained From	_________________________________
Verbal Approval Date/Time	_________________________________

Emergency changes require full documentation within 24 hours and review at the next CAB meeting.

---

7. Quick Reference: Change Categories

Category	Lead Time	Approval	Examples
Standard	None	Pre-approved	Routine patching, scheduled jobs
Normal (Low)	3 days	Manager	Minor feature, non-prod changes
Normal (Medium)	5 days	Manager + Security	Config changes, dependencies
Normal (High)	10 days	CAB	Database changes, architecture
Emergency	Immediate	Post-approval	Outage fix, security incident
Major	10+ days	CAB + Exec	Major releases, migrations

---

8. Attachments Checklist

• Technical specification
• Test results
• Rollback script (if applicable)
• Communication template
• Related tickets/issues

---

9. Related Documents

• Change Management Policy (POL-006)
• Secure Configuration Standards (PROC-003)
• Incident Report Form (TPL-003)

---

10. Version History

Version	Date	Author	Changes
1.0	2026-01-11	IT Operations	Initial release

---

This document is classified as INTERNAL. Unauthorized distribution is prohibited.