Overview
The Change Request and Approval Process is the formal method for requesting, reviewing, approving, and tracking changes to systems, applications, or infrastructure. It ensures that all changes are authorized, assessed for risk, and implemented in alignment with SOC 2 CC8.1 requirements.
Step-by-Step Process
Identify need for change
The requester identifies a required change to a system, application, or configuration and confirms it is not an emergency change. The output of this step is a clear description of the change scope, purpose, and impacted systems.
Role: Engineer
Create change request record
The requester logs a new change request in the approved change management tool, completing all required fields. The output is a uniquely tracked change request with a creation date and requester identified.
Role: Engineer
Document impact and risk
The requester documents the expected impact, risk level, rollback plan, and testing approach within the change record. The output is a completed risk and impact assessment tied to the change request.
Role: Engineer
Review change request
The Engineering Lead reviews the change request for completeness, risk appropriateness, and alignment with standards. The output is a review decision recorded in the tool, either requesting updates or proceeding to approval.
Role: Engineering Lead
Approve or reject change
The Engineering Lead formally approves or rejects the change within the tool before any implementation begins. The output is a dated approval or rejection status linked to the change request.
Role: Engineering Lead
Implement approved change
The assigned engineer implements the approved change according to the documented plan. The output is a completed change with references to code commits, configuration updates, or deployment records.
Role: Engineer
Verify and close change
The Engineering Lead or delegate verifies successful implementation and closes the change request. The output is a closed change record with completion date and verification notes.
Role: Engineering Lead
What You Need Before Starting
- Access to approved change management tool (Jira, GitHub Issues, or ServiceNow)
- Description of proposed system or application change
- List of impacted systems or services
- Defined rollback or remediation plan
Evidence Your Auditor Expects
- Change request ticket showing creation date, requester, and description
- Screenshot or export of approval status with approver name and timestamp
- Linked code commit or pull request with merge date
- Change request closure record with completion date and verification notes
How This Looks In Your Tools
Jira
Navigate to Projects > Select Project > Create Issue and choose the issue type “Change” or “Task” as defined by your workflow. Complete required fields including Description, Impact, Risk Level, and Rollback Plan, then click Create.
To approve, the Engineering Lead opens the issue, reviews the details, and updates the Status field to “Approved” using the workflow transition (e.g., Transition > Approve). Approval comments should be added in the Comments section, and implementation evidence can be linked under the Development or Attachments panel before transitioning the issue to “Done.”
GitHub Issues
Go to the relevant repository and select Issues > New Issue, then choose the “Change Request” issue template if configured. Complete all template sections including change description, risk, impact, and rollback plan, then submit the issue.
For approval, the Engineering Lead reviews the issue and records approval by adding an “Approved” label and an approval comment with date. Implementation evidence is linked by referencing pull requests or commits (e.g., #PR123), and the issue is closed once the change is verified.
ServiceNow
Navigate to Change > Create New and select the appropriate change type (e.g., Normal Change). Complete mandatory fields including Description, Risk, Impact, Implementation Plan, and Backout Plan, then submit the change record.
The Engineering Lead opens the change record, reviews the details, and uses the Approve button or approval workflow to record approval. After implementation, update the State to “Closed” and complete the Close Notes and Close Code fields to finalize the record.
Common Audit Findings
- Changes implemented without documented approval
- This occurs when teams implement changes before formal approval is recorded in the tool. Prevent this by enforcing workflow rules that block implementation or closure without an approval status.
- Incomplete risk or impact assessments
- Auditors often see missing or vague risk documentation due to rushed submissions. Use mandatory fields and standardized templates to ensure assessments are completed before review.
- Lack of linkage between change requests and code changes
- When commits or pull requests are not linked, auditors cannot verify implementation. Require ticket IDs in commit messages or enforce linking in the change record.
- Change requests not formally closed
- Open or stale change tickets indicate weak change governance. Schedule periodic reviews to ensure all implemented changes are verified and closed promptly.