> ## Documentation Index
> Fetch the complete documentation index at: https://docs.blevinsholdings.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Change Management SOP
> Process for requesting, evaluating, approving, and implementing changes to systems and infrastructure at Blevins Holdings.
SOP owner: IT / Operations — Last reviewed: \[Date] — ID: SOP-IT-002
## Overview
The Change Management process ensures that changes to systems, processes, and infrastructure are introduced in a controlled and coordinated manner to minimize disruption and risk. All significant changes require formal review and approval before implementation.
**Why this matters:** Uncontrolled changes are one of the most common causes of system outages and security incidents. A structured change management process reduces risk, improves predictability, and creates an audit trail.
**Key stakeholders:**
| Role | Responsibility |
| --------------------------- | ----------------------------------------------------------------- |
| Change requester | Submits the Change Request; owns the change |
| IT Security | Reviews security implications; required for all high-risk changes |
| Change Advisory Board (CAB) | Reviews and approves high-risk changes |
| Department head | Approves low- and medium-risk changes for their area |
| Operations | Maintains the change register; coordinates scheduling |
***
## What requires a Change Request
A formal Change Request (CR) is required for any change that could affect the availability, security, or integrity of production systems or core business processes. Examples include:
* Deploying new software or infrastructure to production
* Modifying access controls or authentication systems
* Changes to network configuration, firewall rules, or VPN settings
* Migrating data between systems
* Updating integrations or APIs that affect business-critical workflows
* Retiring or replacing a system used by employees or clients
**What does not require a CR:**
* Routine maintenance within a pre-approved maintenance window
* Emergency changes to restore service (these are documented retroactively — see [Emergency Changes](#emergency-changes))
* Minor content or configuration changes with no system-level impact (e.g., updating a document)
When in doubt, raise a CR. The review process is lightweight for low-risk changes.
***
## Change categories
Changes are categorized by risk level:
| Category | Description | Approval required |
| ------------- | ------------------------------------------------------------------------- | ---------------------------------------- |
| **Standard** | Pre-approved, routine changes with well-understood steps and low risk | Department head (pre-approved templates) |
| **Low** | Minor changes with limited scope, reversible, minimal impact if they fail | Department head |
| **Medium** | Moderate scope and impact; risk is manageable but warrants IT review | IT lead + Department head |
| **High** | Broad impact, difficult to reverse, or high risk if something goes wrong | Change Advisory Board (CAB) |
| **Emergency** | Unplanned change required immediately to restore service | Post-implementation review required |
***
## Process steps
**Who:** Change requester
All changes begin with a formal Change Request (CR) submitted through \[change management system — link to be added]. The CR must include:
* **Change description** — What is changing and why
* **Business justification** — The purpose and expected outcome
* **Scope** — Systems, services, or data affected
* **Proposed implementation date and time** — Including time zone
* **Rollback plan** — Specific steps to reverse the change if it fails
* **Testing approach** — How the change will be validated before and after
* **Named approvers** — Based on the risk category
Changes must not be implemented before receiving the required approvals. Unauthorized changes are a policy violation and may result in disciplinary action.
**Who:** IT / Operations
IT or Operations reviews the CR and assigns a risk category (Standard, Low, Medium, High). The requester is notified of the assigned category and any additional information needed before review can proceed.
If the requester disagrees with the risk categorization, they may escalate to the IT Lead or Head of Operations for a final determination.
**Who:** Approvers per risk category
Approvers review the CR and may:
* **Approve** — Change proceeds on the proposed schedule
* **Approve with conditions** — Change may proceed subject to specific requirements (e.g., additional testing, restricted window)
* **Defer** — Change should be rescheduled (e.g., conflicts with a business-critical period)
* **Reject** — Change cannot proceed as submitted; requester must revise and resubmit
High-risk changes reviewed by the CAB are assessed in a scheduled CAB meeting. The CAB meets \[weekly / on-demand — to be defined]. The CAB composition includes IT Security, Operations, and relevant department heads.
**Who:** Change requester + Operations
Once approved, Operations schedules the change and communicates to affected stakeholders:
* **Maintenance window** — When the change will occur
* **Expected impact** — Any downtime or degraded service
* **Contact point** — Who to notify if something goes wrong
* **Rollback trigger** — Under what conditions the change will be reversed
High-impact changes require notification at least **48 hours** in advance. Routine low-risk changes may be communicated same-day.
**Who:** Change requester (with IT support as needed)
The change is implemented per the approved CR. During implementation:
* Follow the documented steps exactly
* Monitor for unexpected behavior in real time
* Keep the rollback plan ready to execute
* Log any deviations from the plan in the CR
If anything unexpected occurs, escalate immediately to IT and consider executing the rollback plan.
**Who:** Change requester + IT
Within **5 business days** of implementation, the requester documents the outcome in the CR:
* Did the change achieve its intended result?
* Were there any unexpected side effects?
* Did the rollback plan need to be executed? If so, why?
* What would be done differently next time?
Operations marks the CR as Closed (successful), Closed (rolled back), or Escalated if issues remain unresolved.
***
## Emergency changes
An emergency change is an unplanned change required immediately to restore a degraded or down service. Emergency changes bypass normal approval gates but must be documented retroactively.
**Procedure for emergency changes:**
1. Notify the IT Lead and On-Call contact before making any change
2. Document what is being changed and why (verbally or in writing)
3. Implement the minimum change required to restore service
4. Submit a retroactive CR within **24 hours** of the change
5. Schedule a post-incident review within 5 business days
Emergency changes are reviewed in the next CAB meeting to determine whether a follow-up action is needed.
***
## Change Advisory Board (CAB)
The CAB reviews high-risk changes and provides a structured forum for assessing risk, coordinating scheduling, and sharing learnings. CAB members include:
* Head of IT / CTO (chair)
* IT Security Lead
* Head of Operations
* Representatives from affected business units (as needed)
CAB decisions are documented in the change register. The CAB schedule and meeting notes are maintained by Operations at \[link — to be added].
***
*SOP owner: IT / Operations*