The Hamster

Reference · IT service management

What Is an RFC in ITIL?

An RFC, or Request for Change, is the formal document that kicks off ITIL's change management process. It records exactly what needs to change in the IT environment, why the change is needed, who is proposing it, and what the expected impact and risk level are. Nothing is meant to be modified in a production environment without an RFC first being logged, assessed, and formally authorized — the mechanism that separates controlled change from ad-hoc tinkering.

Once logged, an RFC typically moves through a change advisory board, or CAB, which evaluates the risk, required resources, and potential conflicts with other planned changes before granting or denying authorization. ITIL distinguishes between standard changes (pre-approved, low-risk, and repeatable), normal changes (requiring full CAB assessment), and emergency changes (fast-tracked to resolve an active incident, but still subject to after-the-fact review). That tiered approach lets routine, low-risk changes move quickly while higher-risk changes still get the scrutiny a full RFC process is designed to provide.

A well-formed RFC references the configuration items (CIs) it touches — the specific servers, applications, or network devices recorded in a configuration management database (CMDB) — so the CAB can see exactly what is affected and trace any knock-on dependencies before approving the work. Impact and risk are typically scored on separate scales: impact reflects how many users or services would be affected if the change went wrong, while risk reflects how likely that failure is given the change's complexity and the team's familiarity with it. A change with high impact but a well-rehearsed rollback plan can carry less overall risk than a small change made against an unfamiliar system.

Every RFC also carries a back-out plan describing how to reverse the change if it does not go as expected, and most organizations close the loop with a post- implementation review (PIR) a set period after the change is deployed. The PIR checks whether the change achieved what it set out to do, whether it caused any incidents that were not anticipated, and whether the original impact and risk assessment held up — feeding lessons back into how future RFCs of a similar kind get evaluated.

Frequently Asked Questions

What does RFC stand for in ITIL?

Request for Change — the formal document that starts ITIL’s change management process, recording what needs to change, why, who is proposing it, and the expected impact and risk.

What is the difference between a standard, normal, and emergency change?

A standard change is pre-approved, low-risk, and repeatable, so it skips full board review. A normal change requires full change advisory board assessment. An emergency change is fast-tracked to resolve an active incident, but is still reviewed after the fact.

What does a change advisory board (CAB) actually evaluate?

Risk, required resources, and potential conflicts with other planned changes, plus which configuration items — servers, applications, network devices — the change touches, before granting or denying authorization.

What happens after a change is deployed?

Most organizations run a post-implementation review (PIR) a set period afterward, checking whether the change achieved its goal, whether it caused any unanticipated incidents, and whether the original impact and risk assessment held up.