Change Management

---

Change management is a process for approving, preparing, supporting, and managing new or updated business processes or technologies.

• minimizes the risk of configuration drift and unscheduled downtime by
  • implementing changes in a planned and controlled way
• the need to change is either:
  • reactive
    • change is forced on the organization
  • proactive
    • change is initiated internally
• changes can be categorized according to:
  • their potential impact
  • level of risk
    • e.g., major, significant, minor, normal
• formalize in governance

IT Change Management

IT change management refers to a structured approach for managing modifications to an IT system, ensuring changes are controlled, efficient, and secure.

• goal is to maintain the availability, confidentiality, and integrity of IT systems throughout the change processes

Phases

IT Change Management Phases

Phase	Description	Example
1. Request	Initiate the change process by completing required documentation	Request an update for a server to improve performance
2. Evaluation	Assess the change to minimize risks and impacts	Evaluate the server update impact on other systems and applications
3. Planning	Determine the change type and priority, schedule roll-out, and develop contingency plans	Schedule the server update during a maintenance window with a backout plan
4. Approval	Secure approvals from stakeholders to prevent downtime and change failures	Obtain necessary approvals from IT manager and server owner for the update
5. Implementation	Execute the planned change	Update the server during scheduled maintenance window
6. Review	Evaluate the change post-implementation, classifying the change as successful, failed, or incomplete	Review the server’s post-implementation performance to identify deviations from expected results

Control Measures

Control	Description	Example
Allow/deny lists	Rules for permitting/denying access to resources	Allow vendor IP access during software update
Restricted activities	Temporary limitations on certain functions during updates	Disable user account creation during critical OS updates
Downtime/restart planning	Assessing and scheduling system unavailability	Schedule database maintenance during off-peak hours
Legacy application management	Considerations for systems using older technologies	Assess legacy payroll application security before integration with new system
Dependency mapping	Understanding how systems are interconnected	Identify web services’ dependencies on database updates

Request For Change

• A change request is generated when:
  • a fault needs to be fixed
  • new business needs or processes are identified
  • there is room for improvement in an existing SOP or system

Request for Change (RFC) document captures the formal need and procedure for implementing a change.

• is then considered at the appropriate level
• affected stakeholders notified
• should include:
  • purpose of the change
    • business case
    • benefits
    • risks
  • scope of the change
    • # of users/devices/etc affected
    • cost and timescales

Change Advisory Board

• major or significant changes may need to be managed as a separate project and require approval through a Change Advisory Board (CAB)
  • aka change management board (CMB) or change control board (CCB)
• composed of representatives of all stakeholders within an org
  • IT, security, legal, management, finance, acquisition, HR, general users
• responsible for reviewing change and exception requests
• meet often enough to ensure changes and exception requests are not delayed
  • but not often enough such that it becomes work
• can meet ad hoc basis
  • but members can forget processes

Process

1. CMB meetings
   • CMB meets to review and analyze change and exception requests
   • authorizes or disallows requests
   • can task security to perform security analysis of impact of a potential request
   • can require funding additional budget funding from requestor for costs of change
2. CMB testing
   • if CMB authorizes request, new modification must be tested before deployment
   • conduct in sandbox network that mimics production environment
   • test all impact on security, interoperability, and functionality
3. Deployment
   • modification is made in accordance with guidance and reported to CMB upon completion
4. Documentation
   • all modifications to the environment are documented and reflected in asset inventory

Ticketing

• configuration changes should only be made when there is a service ticket authorizing the change
  • thus all network personnel activity is recorded in job logs
  • in a fully documented environment, each task is governed by a standard operating procedure (SOP)
    • sets out the principal goals and considerations for performing a task and identifies lines of responsibility and authorization for performing it
    • may contain detailed steps for completing a task in an approved way
    • may present these steps as work instructions
• ticket system facilitates request process tracking
  • ticket:
    • documents request and approval
    • identifies stakeholders plus change and rollback plans
    • monitors progress through implementation and testing of the change