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 |
| Impact Categorization | Changes that affect the FIPS 199 categorization or security impact level of a system or its data | 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 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¶
By default, change requests follow the two-stage approval workflow described in the Approvals section. The Change Advise Board (CAB) reviews and approves the request on the technical side first, before it is forwarded to the designated end user with the Change Approver role for final sign-off. Approval processes can be customized to suit your organization's needs.