Change Requests¶
Change requests are submitted through the Request Services page under the Change Requests category. All changes to systems within the authorization boundary must be formally documented through a change request to maintain compliance with FedRAMP and CMMC change management requirements.
Change Request Form¶
The change request form captures the full scope of a proposed change, including its type, category, justification, risk assessment, and implementation plan.
Form Fields¶
| Field | Purpose |
|---|---|
| Change Type | Classifies the nature and urgency of the change (see below) |
| Category | Identifies the operational domain and specific activity (see below) |
| Summary | Brief description of what is being changed |
| Impact | Rich text field to describe the scope of impact on systems, users, and services |
| Justification | Why this change is necessary, tying back to compliance requirements, security findings, or operational needs |
| Risk | Assessment of risk associated with the change |
| Change Plan | Step-by-step description of how the change will be executed |
| Test Plan | How the change will be validated after implementation |
| Implementation Plan | Detailed execution plan including sequencing and dependencies |
| Backout Plan / Rollback | Steps to reverse the change if issues arise during or after implementation |
| Communication Plan | Who needs to be notified before, during, and after the change |
| Affected Assets | Systems, components, or infrastructure impacted by the change (select from the asset inventory) |
| Change Schedule | Start date/time, target completion date/time, and estimated duration |
Change Types¶
The Change Type field classifies the nature of the change being requested. Selecting the correct type ensures proper review, approval routing, and audit documentation.
| 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 that auditors can verify |
| Adaptive | Changes made in response to environmental shifts such as vendor updates, dependency upgrades, or infrastructure adjustments | Aligns with FedRAMP CM-4 (impact analysis); requires assessment of how external changes affect the 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 under the continuous monitoring program |
| Certification Class Change | Changes likely to alter the FedRAMP Certification class of the entire offering (for example Class B to Class C) | Cannot proceed under the Significant Change Notification rules; requires a new assessment |
| Impact Categorization | Legacy -- retained so historical change requests keep their original classification. For new changes affecting the offering's class, use Certification Class Change | Not used for new changes |
| 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 that must be implemented immediately to address active security incidents, outages, or zero-day vulnerabilities | FedRAMP CM-3 allows for emergency changes with expedited approval, but requires full documentation after the fact |
Categories¶
The Category field identifies the operational domain and specific activity for the change. This categorization supports accurate reporting and audit trail requirements.
Continuous Monitoring¶
| Category | Description |
|---|---|
| Flaw Remediation | Patching, vulnerability remediation, and security fixes identified through scanning or assessment. Directly supports FedRAMP SI-2 and CMMC SI.L2-3.14.1 flaw remediation requirements |
Engineering¶
| Category | Description |
|---|---|
| Configuration | Changes to system settings, security baselines, or hardening configurations. Supports FedRAMP CM-6 and CMMC CM.L2-3.4.2 security configuration settings requirements |
| Deployment | Deploying new components, services, or infrastructure within the authorization boundary |
| Development | Code changes, feature development, or application modifications within the system |
| Maintenance | Scheduled system maintenance, hardware replacements, or infrastructure upkeep. Supports FedRAMP MA-2 controlled maintenance requirements |
| Testing | Security testing, penetration testing, or validation activities that may affect production systems |
Approval Workflow¶
Change requests follow the approval workflow described in the Approvals section: the Change Approvers CAB reviews and approves first, and when your organization has a designated end user with the Change Approver role, the request is then forwarded to them for final sign-off. Approval processes can be customized to suit your organization's needs.