Types of RFCs (Request for Change)

Purpose:
This document defines and distinguishes the four RFC types used within the IT Change Management process. It is intended to guide change requestors, approvers, and stakeholders in identifying the appropriate classification for changes, based on impact, urgency, and risk.


Routine RFC

Definition: A Routine RFC is a recurring, low-impact change with a predictable outcome. These changes are often pre-approved and follow a defined procedure.

Criteria:

  • No expected service downtime

  • Low or no operational risk

  • Fully scripted or automated

  • Historical success rate is 100%

Approval Workflow:

  • Pre-approved by Change Manager

  • Logged in Freshservice via change template

Examples:

  • Antivirus definition updates

  • Automated cleanup scripts

  • Monthly MDM policy sync

Risk Classification:

  • NIST CSF: ID.RA-4, PR.IP-3

  • CIS Controls v8: Control 4.7, 10.4




Minor RFC

Definition: A Minor RFC involves limited technical risk or user impact. These are changes that require minimal coordination and are typically localized.

Criteria:

  • No or minimal downtime (<15 minutes)

  • Limited user or system impact

  • Requires communication to specific stakeholders

  • Easily reversible/backout plan

Approval Workflow:

  • Change Manager review

  • CAB Review and Approval

  • Submitted in Freshservice with impacted assets/users

Examples:

  • Server disk space increase

  • DNS record changes

  • SSL certificate renewals

Risk Classification:

  • NIST CSF: PR.MA-1, PR.IP-1

  • CIS Controls v8: Control 4.1, 12.1



Major RFC

Definition: A Major RFC introduces high risk to production services and may impact multiple systems, users, or departments. These must be carefully reviewed and planned.

Criteria:

  • Potential for system/service downtime

  • Business-critical systems impacted

  • Requires stakeholder coordination

  • Communication plan required

Approval Workflow:

  • CAB Review and Approval

  • Executive stakeholder notification (if required)

  • Full documentation in Freshservice (timeline, risk, mitigation, comms)

Examples:

  • Data center infrastructure changes

  • Email system migration

  • ERP software upgrade

Risk Classification:

  • NIST CSF: ID.RA-2, PR.IP-12, RS.CO-2

  • CIS Controls v8: Control 5.1, 8.3, 17.3



Emergency RFC

Definition: Emergency RFCs are fast-tracked changes to restore critical services or mitigate immediate risks. These are used only under severe urgency.

Criteria:

  • Immediate need to resolve a critical incident

  • Business operations are disrupted or at risk

  • Standard RFC process bypassed, but post-review required

Approval Workflow:

  • Requires CISO Approval

  • Post-implementation review required within 48 hours

  • Logged in Freshservice under Emergency template

Examples:

  • Zero-day vulnerability patching

  • Disaster recovery system failover

  • Emergency configuration changes to restore access

Risk Classification:

  • NIST CSF: DE.CM-7, RS.MI-3, RS.CO-5

  • CIS Controls v8: Control 8.7, 13.1, 17.4





Summary Table


RFC Type Risk Level Approval Required CAB Review Downtime Allowed Use Case Examples
Routine Low Pre-approved No None Patching non-prod systems
Minor Low-Med Yes Sometimes Minimal Disk increase, account updates
Major High Yes Yes Yes Core system migrations, network changes
Emergency Critical Fast-track Post-review Yes Incident response, urgent security patches



Notes for Requestors

  • All RFCs must be entered into Freshservice with adequate lead time, unless marked as Emergency.

  • Each RFC must include: Description, Impact, Rollback Plan, Communication Plan.

  • Emergency RFCs must be reviewed during the next CAB meeting.

Was this answer helpful? Yes No

Sorry we couldn't be helpful. Help us improve this article with your feedback.