Skip to content

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).

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, typically requiring explicit notification and additional review
Impact Categorization Changes affecting the FIPS 199 categorization or security impact level of a system
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.

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 Advise Board (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:

  1. Click Request Approval on the change request
  2. Optionally add a note explaining any context the approvers should know
  3. Adjust the priority if needed (e.g., for emergency changes)
  4. Send to the approvers

The ticket status changes to Waiting Approval and the approval workflow begins.

Approval Flow

By default, the change request follows a two-stage approval process:

Stage Who Reviews How
CAB Review Change Advise Board members (agents) Review and approve via the platform or email notification
Organizational Approval Designated end user with the Change Approver role 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. After CAB approval, the request is forwarded to the end user assigned the Change Approver role - the designated point of contact who has authority to authorize changes.

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:

  1. Click Initiate Change on the ticket to signal that implementation is underway
  2. Execute the change according to the implementation plan documented on the ticket
  3. Add private notes throughout the process to document actions taken, decisions made, and any issues encountered
  4. 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:

  1. Click Complete Change to indicate the work is done - the ticket moves to the Review phase
  2. Validate that the change was successful using the test plan documented on the ticket
  3. Record whether the change was successful or if any issues were encountered
  4. 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, then organizational approver signs off
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