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.