Change Request¶
Quick Summary
Formalizes any proposed change to systems within the authorization boundary, from routine patching to emergency security fixes to user access provisioning. Change requests capture the implementation plan, risk assessment, and rollback strategy, and require approval through the Change Advise Board before execution.
The Change Request ticket type is the formal mechanism for documenting and approving modifications to systems, configurations, infrastructure, and user access within the authorization boundary. Every change, whether it's a routine patch cycle, a new user onboarding, or an emergency response to a zero-day, flows through this ticket type to maintain the audit trail required by FedRAMP CM-3 and CMMC CM.L2-3.4.3.
Change Types¶
Each change request is classified by type, which determines the review rigor and approval routing:
| Change Type | Description | Compliance Context |
|---|---|---|
| Routine Recurring | Pre-approved, regularly scheduled changes such as patching cycles or certificate renewals | Supports FedRAMP CM-3 and CMMC CM.L2-3.4.3 by establishing predictable, documented change patterns |
| Adaptive | Changes in response to environmental shifts: vendor updates, dependency upgrades, or infrastructure adjustments | Aligns with FedRAMP CM-4 (impact analysis), requiring assessment of how external changes affect security posture |
| Transformative | Significant architectural or functional changes such as new service deployments, major upgrades, or boundary modifications | May constitute a FedRAMP Significant Change requiring notification and potentially reassessment |
| Impact Categorization | Changes that affect the FIPS 199 categorization or security impact level of a system | Directly tied to FedRAMP RA-2 and CMMC requirements; changes to impact levels can affect the entire authorization baseline |
| Interim Requirement | Changes driven by interim compliance directives, binding operational directives (BODs), or emergency security guidance | Supports timely response to CISA BODs and FedRAMP PMO directives that require action within defined timeframes |
| Emergency | Critical changes implemented immediately to address active security incidents, outages, or zero-day vulnerabilities | FedRAMP CM-3 allows emergency changes with expedited approval but requires full documentation after the fact |
User access requests - onboarding, offboarding, and modifications for both standard and privileged accounts - are also managed through the change request process, ensuring access control changes carry the same formal approval and documentation as system changes.
Approval Workflow¶
By default, change requests follow a two-stage approval workflow: the Change Advise Board (CAB) reviews and approves the request on the technical side first, then a designated end user with the Change Approver role provides final organizational sign-off. Emergency changes may follow an expedited path but still require full documentation after the fact.
Approval processes are highly customizable to suit your organization's needs. See the Approval Processes admin guide for configuration details.
Scope of Documentation¶
The change request form captures the full lifecycle of the proposed change:
- Justification - why the change is necessary, tied to compliance requirements, security findings, or operational needs
- Risk assessment - impact analysis aligned with FedRAMP CM-4
- Implementation plan - step-by-step execution including sequencing and dependencies
- Test plan - how the change will be validated after implementation
- Backout / rollback plan - steps to reverse the change if issues arise
- Communication plan - stakeholder notification before, during, and after
- Affected assets - systems and components impacted, selected from the asset inventory
See the Change Requests end-user guide for details on submitting change requests.