Request for Change

Request for Change (RFC) is a formal proposal to introduce a specific change to an IT service, system, infrastructure component, or other controlled part of the technology environment. It identifies the change being requested, why it is needed, and the information required to evaluate its likely impact, risk, feasibility, and authorization requirements. Within IT service management, an RFC is an input to the change enablement practice rather than permission to perform the work.

In plain terms, the RFC asks the organization to consider making a controlled change. It gives the people responsible for assessment and approval a sufficiently clear description of the proposal and its consequences. It may be submitted through an ITSM application, an electronic form, or another approved channel; the level of detail should reflect the change's scope and potential impact. Submitting an RFC does not mean that the change has been approved, scheduled, implemented, or shown to be successful.

The term is also commonly written change request. A conceptual distinction exists between the RFC, which initiates a proposal, and the change record, which preserves decisions and evidence throughout the change's lifecycle. In practice, some organizations and ITSM tools use a single change-request record for both purposes. The IRS, for example, defines its change request as the record used to propose, assess, authorize, implement, and track a change. The important distinction is between the request to change and the authorization and execution of the change, even when these are tracked in one system.

Purpose and place in service change governance

An RFC makes a proposed change visible before its consequences become operational facts. A request can originate from a service owner seeking a new capability, an engineer addressing a technical weakness, an incident or problem investigation identifying a permanent fix, a security requirement, a supplier dependency, or a business initiative. The requester describes the need; the organization's change process determines how the proposal is assessed and whether it may proceed.

An RFC connects the business reason for a change with its technical and operational implications. A service owner may understand the required outcome but not all infrastructure dependencies. Conversely, an engineering team may know how to deploy a change without knowing that a proposed maintenance window conflicts with a business-critical event. A useful request exposes both perspectives early enough for an informed decision.

Within change enablement, the RFC is therefore an initiation and decision-support artifact. It is not a substitute for a business case where investment approval is required, a detailed engineering plan, a technical test report, or a formal decision by the assigned change authority. The supporting evidence can be attached to, or referenced from, the request. The IRS change management policy describes separate concepts for the change request, authorization, record, model, and review, illustrating why their functions should remain clear even when one system stores them together.

Information contained in an RFC

There is no universal RFC form that every organization must use. Its information requirements should be sufficient for the relevant change model and the potential consequences of the proposed change. Common elements include the following.

Information element	What it establishes	Why it matters
Identity and origin	A request identifier, requester, responsible owner, submission date, and triggering need	Makes the proposal traceable and identifies who can clarify its purpose
Proposed change and desired outcome	What will be added, modified, removed, or restored and what the change should achieve	Allows reviewers to judge the request against a specific objective
Business and service justification	Expected benefit, required outcome, deadline, and consequences of doing nothing	Helps distinguish genuine need from preference or avoidable urgency
Scope and affected items	Services, applications, environments, users, and relevant configuration items	Exposes dependencies and the potential reach of failure
Risk and impact information	Likely failure conditions, security or compliance effects, business disruption, and mitigations	Supports a proportionate assessment rather than an arbitrary approval route
Implementation and verification approach	Proposed work, prerequisite tests, responsible teams, expected results, and monitoring	Shows whether the change can be executed and checked with reasonable confidence
Recovery and contingency	Rollback or alternative restoration approach, decision points, and recovery responsibilities	Makes the response to an unsuccessful implementation visible before execution
Timing and dependencies	Preferred implementation window, competing work, service constraints, and notifications	Reveals conflicts and required coordination
Supporting evidence	Links to risk reviews, technical designs, test results, incident or problem records, and other approvals	Gives reviewers access to relevant detail without duplicating every source document

These elements are not all necessarily complete at the moment of submission. A request may begin with a defined need and be enriched during assessment. What matters is that the evidence required for a particular decision is available before that decision is taken. A high-impact change may need a documented technical evaluation and a full recovery test; a low-risk change may require much less material.

From submission to authorization

An RFC enters a controlled decision path. The path and record states depend on the organization, its change models, and the type of change requested. The following sequence describes the main functions rather than prescribing a mandatory ITIL workflow.

1. Submit and register. The requester records the proposal through the authorized channel. The organization identifies the request, its origin, and the services or components involved.
2. Check completeness and route. A change coordinator or responsible team checks that the request is intelligible, not an obvious duplicate, and suitable for the proposed category. Missing information is returned for clarification.
3. Assess impact and readiness. Relevant service, engineering, operational, and security specialists evaluate the benefits, dependencies, risks, implementation approach, tests, timing, and recovery arrangements.
4. Make the authorization decision. The assigned change authority approves, conditionally approves, defers, rejects, or returns the proposal for further assessment within its delegated powers. A Change Advisory Board may supply advice where cross-functional review is valuable.
5. Implement and verify if authorized. Responsible teams perform the change under applicable conditions and record the outcome. The approval is a decision to proceed under defined circumstances, not proof of success.
6. Review and close the associated record. Results, deviations, incidents, recovery actions, and follow-up decisions are documented, including a Post-Implementation Review when required.

A request can be rejected for a valid reason without becoming an implementation failure. It may also be deferred pending testing, business approval, a safer deployment window, or a change in scope. A material revision can require renewed assessment because the original authorization may no longer cover the proposed work. California State University, East Bay, for example, documents returning RFCs when implementation information or restoration plans are incomplete and escalating high-risk proposals to an appropriate review body.

Who submits, assesses, and approves the request?

The roles associated with an RFC should be separated by responsibility and decision rights. A person who proposes a change is not automatically authorized to approve it, and the person who authorizes it need not perform the implementation.

Role	Relationship to the RFC	Important boundary
Requester or initiator	States the need and supplies the original proposal	May differ from the person who enters the request in the system
Change owner or coordinator	Maintains the request's completeness, routing, planning, and status	Does not necessarily hold final approval rights
Service owner and subject specialists	Explain business impact, dependencies, technical feasibility, and relevant risks	Their advice does not automatically replace formal authorization
Change authority	Makes the decision to authorize, defer, or reject within documented limits	Must have authority appropriate to the risk and scope
Change Advisory Board (CAB)	Provides cross-functional review where the proposed change warrants it	May be advisory or may hold delegated approval rights, depending on policy
Implementation team	Executes an authorized change, verifies results, and records exceptions	Execution accountability is distinct from the approval decision

Cornell University's current change enablement glossary distinguishes the individual requesting a change from the individual who actually submits the RFC. This is useful when a business representative raises the need but a technical coordinator prepares the formal submission. The exact assignment of change-manager, CAB, and approval responsibilities varies by enterprise and must be established by the organization's governing rules.

Relationship to standard, normal, and emergency changes

A Request for Change is not itself a change type. Change classification determines the review and authorization route, and the organization's record system determines how a request is created or logged.

Change class	Relationship to an RFC	Authorization implication
Standard Change	A qualifying action may be initiated through an approved request mechanism or template without a new case-by-case RFC	The defined change pattern is already authorized, provided the conditions remain satisfied
Normal Change	A new proposal ordinarily triggers an RFC or equivalent change request that is assessed for the individual case	The authorization decision is made at a level proportionate to risk
Emergency Change	An urgent proposal may be recorded through an expedited path, with some documentation completed afterwards where policy permits	Urgency can change timing and review arrangements but does not remove accountability

The distinction matters because a routine service request and an individually assessed change proposal may follow different operating paths. It would be wasteful to require a full RFC for every instance of an already authorized standard change; it would also be unsafe to use a standard-change label for an action outside the approved conditions. Stanford University illustrates these differences with separate processes for standard, normal/expedited, and emergency changes; its emergency path allows retrospective recording in defined circumstances. This is a local process example, not universal permission to bypass advance authorization.

Illustrative request

Consider a hypothetical organization proposing a change to the outbound network rules used by a payment-processing application. The requester wants to restrict connections to an approved supplier endpoint to reduce exposure, but the change could interrupt payment authorizations if the endpoint list is incomplete.

The RFC identifies the affected service and network devices, explains the security rationale, specifies the intended rule change, notes the expected business impact if connectivity fails, and points to testing evidence. It proposes a maintenance window, assigns a responsible engineer, defines monitoring checks for payment success, and identifies a tested way to restore the previous rules. The service owner confirms a period of lower business activity, while network and security specialists review the technical dependencies.

If the proposal is assessed as a normal change, the assigned authority can approve it with conditions, return it for further testing, or defer it. After any authorized implementation, the record captures the actual outcome and whether restoration was needed. The example illustrates the RFC's function: it makes the proposed intervention and the decision basis visible without confusing the request with approval or the deployment itself. It is illustrative, not a report of an actual organizational change.

Distinct but related records and requests

Several ITSM artifacts use similar language. Their functions can overlap within software, but their principal purposes are different.

Entity	Distinguishing role
Request for Change (RFC)	Initiates a proposal for a controlled change and supplies information needed for assessment
Change Record	Maintains the history of a particular change, including classification, authorization, implementation, and review evidence
Service Request	Asks for an established service, access, information, or routine fulfillment; it may trigger an authorized standard change
Change Proposal	Describes a potential significant change at a broader justification or investment level when required
Change Model	Defines the agreed handling approach for a category of change, rather than requesting one particular change
Change Schedule	Coordinates planned change timing and helps identify conflicts across changes

The term change request is often used as a synonym for RFC and should ordinarily resolve to this same concept rather than become a competing definition page. In an integrated ITSM platform, one record may start as a request and then accumulate assessments, authorizations, implementation tasks, and closure evidence. This does not eliminate the distinctions among those functions. The IRS uses a unified change-request record for its lifecycle, while IT Process Maps explains the RFC as the request that precedes the full change record.

A service request is particularly easy to confuse with an RFC. A user asking for standard software access generally seeks fulfillment of a predefined service. A team proposing a new access-control design that could affect many applications is asking for a controlled change. One request may lead to the other, but they do not automatically require the same assessment or authorization.

Digital records and automation

An RFC need not be a separate document circulated by email. Modern ITSM systems can capture the proposal in a form, connect it to affected assets and services, route assessment work, apply policy-based gates, link test results, and retain authorization and deployment evidence. Links to engineering tickets, repositories, automated tests, deployment pipelines, or incident records can be more useful than copying the same information into another form. The IRS's 2026 change process explicitly incorporates integration with CI/CD activities while preserving risk-based evaluation and lifecycle traceability.

Automation changes the means of capturing and evaluating evidence, but it does not establish that every request is low risk. A system should distinguish pre-authorized patterns from requests requiring human judgment, and preserve who or what had authority to permit execution. For an automated approval, the relevant policy, scope, conditions, and decision trace should remain identifiable.

Common weaknesses and quality measures

An RFC can appear complete while failing to support a sound decision. Common weaknesses include vague change descriptions, missing affected services, untested recovery assumptions, deadlines presented as emergencies without evidence, risk assessments copied unchanged from unrelated changes, and approval obtained from someone without the required authority. Excessive form requirements create a different failure mode: teams may submit superficial responses or attempt to bypass the request route.

The quality of an RFC system can be examined through the proportion of requests returned for material omissions, elapsed time to an authorized decision, repeated reclassification, late discovery of affected dependencies, changes made outside their approval conditions, and the traceability of decisions to actual implementation evidence. These measures require clear definitions and segmentation by change type and risk; a slow decision may reflect poor routing, incomplete evidence, or necessary scrutiny of a consequential change.

A strong request makes the proposed change understandable and its decision basis auditable. It cannot guarantee a successful deployment. Review of outcomes belongs to the broader change enablement system, including its control evidence and learning from failed changes.

ITIL terminology and scope

The term Request for Change is associated with ITIL service transition and continues to appear in ITIL-aligned ITSM practice. ITIL 4's Change Enablement terminology often uses change request and change record as distinct concepts, and contemporary organizations may implement the request and full lifecycle through the same electronic record. Both usages are recognizable, provided it remains clear whether a statement concerns the initial proposal, an authorization decision, or the continuing record of execution.

This page concerns RFCs for changes to IT services and their supporting technology. It does not address requests to change a project contract, an engineering specification outside service management, or employees' adoption of a new organizational process. Those can have their own approval and record systems without being ITSM Requests for Change.

See also

• Change Enablement
• Change Authority
• Change Advisory Board
• Change Record
• Standard Change
• Normal Change
• Emergency Change
• Change Model
• Service Request
• Post-Implementation Review
• Release Management