Change Execution¶
Step-by-step procedures for executing changes within the GRC-ITSM platform, from ticket creation through post-change review and closure.
Overview
Every change to systems within the authorization boundary follows a structured workflow: create, approve, schedule, implement, review, and close. The GRC-ITSM platform enforces this workflow through ticket stages and approval gates, producing the audit trail required by FedRAMP CM-3 (Configuration Change Control), CM-4 (Impact Analyses), and CMMC CM.L2-3.4.3 (System Change Management) / CM.L2-3.4.4 (Security Impact Analysis).
Governing policy
This playbook executes the Change Management Policy and Procedures, which defines the binding policy statements, change types, and framework citations behind these steps.
1. Create the Change Request¶
Navigate to the Change Management area and create a new change request ticket. Select the appropriate change type and category, then fill out all required fields.
Change Type¶
Select the type that best describes the change being proposed:
| Change Type | When to Use |
|---|---|
| Routine Recurring | Minor incremental patching or updates: endpoint signature updates, OS patching, software library updates, vulnerability remediation |
| Adaptive | Improvements and new functionality that are larger than incremental but typically transparent to end users: OS version upgrades, container or VM updates, complex library migrations |
| Transformative | Significant changes that may be breaking or introduce security changes to the environment; these trigger Significant Change Notifications on fixed business-day clocks and additional review |
| Certification Class Change | Changes likely to alter the FedRAMP Certification class of the entire offering (for example Class B to Class C); requires a new assessment rather than a Significant Change Notification |
| Impact Categorization | Legacy -- retained so historical change requests keep their original classification. For new changes affecting the offering's class, use Certification Class Change |
| Interim Requirement | Changes driven by compliance directives, BODs, or emergency security guidance |
| Emergency | Critical changes for active security incidents, outages, or zero-day vulnerabilities |
Category¶
Select the operational domain for the change (e.g., Flaw Remediation, Configuration, Deployment, Development, Maintenance, Testing).
Required Fields¶
| Field | What to Provide |
|---|---|
| Summary | Brief description of what is being changed |
| Impact | 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 (Low, Medium, High) |
| Change Plan | How you plan to make the change |
| Test Plan | How to validate the change was successful |
| Implementation Plan | Technical steps for executing the change |
| Backout Plan | How to reverse the change if needed |
| Communication Plan | Any special communication considerations |
| Security Impact Analysis | What impact to security this change has (satisfies FedRAMP CM-4 and CMMC CM.L2-3.4.4) |
| Affected Assets | Systems, components, or infrastructure impacted, selected from the asset inventory |
| Change Schedule | Start date/time, target completion date/time, and estimated duration |
Start and Target Dates
Always set start and target dates, even for routine changes. These dates drive the scheduling phase and allow the change to appear on the Change Management calendar for conflict detection.
2. Link Related Tickets¶
Before submitting for approval, link any related tickets to the change request. This is particularly important for patch windows where multiple issues are being addressed in a single change.
- Open the change request and use the Link Tickets function
- Select any POA&M items (issue tickets) or other tickets that will be addressed during this change
- Linked tickets appear on the change request's related items section, providing traceability between the change and the findings it addresses
Link Before Approval
Linking related tickets should be done before requesting approval so that the Change Approvers CAB can see the full scope of what the change covers.
3. Request Approval¶
Once the change request is complete and related tickets are linked, submit it for approval:
- Click Request Approval on the change request
- Optionally add a note explaining any context the approvers should know
- Adjust the priority if needed (e.g., for emergency changes)
- Send to the approvers
The ticket status changes to Waiting Approval and the approval workflow begins.
Approval Flow¶
The change request is approved by the Change Approvers CAB, with an optional organizational stage when your organization has designated an end-user approver:
| Stage | Who Reviews | How |
|---|---|---|
| CAB Review | Change Approvers CAB members (role-based membership) | Review and approve via the platform or email notification |
| Organizational Approval (optional) | Designated end user with the Change Approver role, where one exists | Review and approve via the self-service portal or email |
CAB members receive an email notification and can approve directly from the email or by logging into the platform and accepting the request. If an end user in your organization holds the Change Approver role, the request is then forwarded to them for final sign-off; otherwise CAB approval completes the process.
Approval processes are highly customizable. See Approval Processes for details on configuring approval workflows to suit your organization's needs.
Emergency Changes
For emergency changes addressing active security incidents, outages, or zero-day vulnerabilities, implement the change immediately to address the threat. Document the change retroactively and submit for post-hoc approval. FedRAMP CM-3 allows emergency changes with expedited approval but requires full documentation after the fact.
4. Scheduling¶
After approval, the change request moves to the Scheduling phase. The start and target dates provided during creation determine when the change is scheduled.
- If the dates need to change, update the Start Date and Target Date on the ticket before proceeding
- The change will appear on the Change Management Calendar, which provides visibility into all scheduled changes and helps avoid conflicts with other maintenance windows
5. Implement the Change¶
When the change window begins:
- Click Initiate Change on the ticket to signal that implementation is underway
- Execute the change according to the implementation plan documented on the ticket
- Add private notes throughout the process to document actions taken, decisions made, and any issues encountered
- If problems arise, refer to the backout plan documented on the ticket and add notes explaining what happened
Document as You Go
Add private notes at each significant step during implementation. These notes become part of the audit trail and provide evidence that the change was executed according to the approved plan.
6. Complete and Review¶
When implementation is finished:
- Click Complete Change to indicate the work is done - the ticket moves to the Review phase
- Validate that the change was successful using the test plan documented on the ticket
- Record whether the change was successful or if any issues were encountered
- Once review is complete, click Complete Change a second time to close the ticket
Post-Change Validation¶
Before closing, confirm:
- The change was implemented according to the approved plan
- The test plan was executed and results were documented
- Any linked issue tickets have been updated to reflect remediation
- Private notes capture the full timeline of implementation actions
- No unexpected side effects or security impacts were observed
Workflow Summary¶
The full change execution lifecycle follows these stages:
| Stage | Status | Action |
|---|---|---|
| Create | New | Fill out all required fields and link related tickets |
| Approval | Waiting Approval | CAB reviews; organizational approver signs off where one is designated |
| Scheduling | Scheduling | Confirm or adjust change window dates |
| Implementation | Implementation | Click Initiate Change, execute the plan, document actions |
| Review | Review | Click Complete Change, validate success, document results |
| Closure | Closed | Click Complete Change again to close the ticket |