What is a request for change?
A request for change, usually shortened to RFC, is the formal proposal that starts the change management process. Before anyone touches a production system, a requester submits an RFC describing the change, and nothing proceeds until it has been assessed and approved. Most organizations raise RFCs as tickets in an IT service management tool, so each one gets a change number that follows the work through approval, implementation and closure.
What an RFC contains
- A description of the change and the business reason for it
- The systems, services and users it affects
- The requester and the change owner
- The proposed date and maintenance window
- The risk rating and impact analysis
- Test results from a test or staging environment
- Implementation steps and a backout plan, with the trigger for using it
- The change type: standard, normal or emergency
Example RFC
| Field | Entry |
|---|---|
| Change | CHG-5521: disable TLS 1.0 and 1.1 on the customer portal load balancer |
| Reason | Deprecated protocols flagged by the quarterly vulnerability scan |
| Affects | Customer portal; two partner integrations that may still connect with TLS 1.0 |
| Window | Sunday 01:00 to 03:00 |
| Testing | Passed in staging; both partners confirmed TLS 1.2 support in writing |
| Backout | Reapply the saved TLS profile, about 5 minutes; trigger is any partner connection failure |
Because the RFC names the partner integrations, the change owner contacts both partners before the window instead of discovering the dependency when their connections start failing.
What happens after submission
The RFC moves into assessment, where reviewers rate the risk and check the impact analysis, test evidence and backout plan. Low-risk standard changes are pre-approved and follow a standard operating procedure. Normal changes go to the change manager or, above a set risk level, to the change advisory board, which can approve, approve with conditions, defer or reject. An emergency RFC gets expedited approval and its documentation is completed afterward. After implementation, the RFC records verification and closure, so the change history shows who asked for what and who approved it.
Request for change vs. Request for Comments
RFC has two meanings in IT. In change management it is a request for change. In networking it is a Request for Comments: the numbered documents, mostly from the IETF, that define internet protocols, such as RFC 8446 for TLS 1.3. If an answer option or an acronym list spells RFC out as Request for Comments, let the context decide: a change waiting for approval is a request for change, and a protocol specification is a Request for Comments.
Request for change on the CompTIA Security+ exam
The request for change is the first step of the approval process taught under objective 1.2, the change management scenario objective. When a question asks what a technician should do FIRST before a non-standard production change, submitting a change request is the usual answer, and a request that arrives without test results or a backout plan should be deferred. Distractors include making the change now and documenting it later, which is acceptable only through the emergency process, and having the CAB implement the change, since the board approves work and doesn't perform it.