IT Change Management Flashcards
IT Change Management Policy
Accurate Documentation;
Continuous Oversight;
Formal, Defined approval process;
Scope
Key Goals of IT Change Mgt
-Establish clearly defined best practice processes to ensure compliance with the SOX
requirements as measured using standard COBIT measurement elements
-Improve efficiency through the use of automated tools and a centralized data depository
-Improve communication through automated escalations and notifications
-Ensure proper level of approvals
-Reduce risk associated with completing changes
-Reduce the impact of changes on the IT and business organizations
IT Change Management Process
Formally Request a Change; Categorize and Prioritize the Change; Analyse and Justify the Change; Approve and Schedule the Change; Plan and Complete the Implementation of the Change; Post-Implementation Review
In Scope of Change Management Process
SDLC - changes through software development life cycle
Hardware – Installation, modification, removal or relocation of computing equipment.
Software – Installation, patching, upgrade or removal of software products
Database – Changes to databases or files
Application – Application changes being promoted to production
Moves, Adds, Changes and Deletes – Changes to system configuration.
Schedule Changes - Requests for creation, deletion, or revision to job schedules
Telephony – Installation, modification, de-installation, or relocation of PBX equipment/services
Desktop – modification or relocation of desktop
Generic and Miscellaneous Changes
Out of Scope
Some IT tasks performed do not fall under the policies and procedures of Change Management:
• Contingency/Disaster Recovery
• Changes to non-production elements or resources
• Changes made within the daily administrative process. Examples of daily administrative tasks
are:
– Password resets
– User adds/deletes
– User modifications
– Adding, deleting or revising security groups
– Rebooting machines when there is no change to the configuration of the system
– File permission changes
The Change Advisory Board (CAB) may modify the scope periodically
Creating a Request for Change (RFC)
Created by the Change Coordinator
Change Coordinators work with the Change
Initiators to identify:
• The Change Initiator’s name and contact information
• The Change Coordinator’s name and contact information
• An accurate description of the change required including the specific request, reason the change
is required and the required timeframe
• The priority and category of the change based on the information available
• Incident tracking number of any issue that relates to the change
• Description and clarification of any items to be changed, including identification of the
Configuration Item if known
• A cost-benefit analysis of the change and budgetary approval, if required
• Business impact and resource assessment
• Location of the release and a suggested implementation plan with timescale
• Impact on business continuity and contingency plans
• Risk involved in making the change
Assigning the Change Priority
Change Coordinator has authority to adjust the priority level: Emergency – A change to be implemented immediately, or leave organization open to significant risk (e.g.security patching). • High – A change important and implemented soon to prevent a significant negative impact to business processes • Routine – A change implemented to gain benefit from the changed service. • Low – A non urgent change, but would be advantageous.
Development Phase
Completing a risk and impact analysis
Developing specific change requirements
Identifying a back-out plan and receiving peer approval
Developing the Business Case Justification
Change Coordinator must develop a Business Case Justification:
- The requirements and detailed description of the change;
- Describe the impact the change will make on the business unit’s operation;
- Describe the effect the change may have upon the end user, business operation, and infrastructure
- Describe the impact on other services that run on the same infrastructure;
- Describe the effect of not implementing the Change;
- Estimate the IT, business and other resources required to implement the Change (costs, number and availability of people required);
- Estimate any additional ongoing resources if Change implemented
Technical Impact Analysis
Resource assigned based on type of change and complexity. Criteria a technical reviewer must consider:
- Evaluate the change plans to gauge the impact and effect of the change;
- Review the technical completeness of the change plan (anticipated assets changed, impact on start-up/shut down of systems, impact on disaster recovery plans);
- Evaluate the technical feasibility of the change (Performance, Capacity, Security, Operability);
- Validate technical aspects, feasibility, and plan
- Reviewer assigns technical impact level
Technical Impact - Low Level
- For routine categories
- IT resources one workgroup within same IT division
- Low complexity: no technical coordination required
- Low risk to system availability (system/service outage affecting clients during Non-Prime Time)
- Easy implementation and back-out
- No impacts to service level agreements
Technical Impact - Medium Level
- IT resources from more than one workgroup within same IT division
- Significant complexity: technical coordination one or more functional groups
- Moderate risk to system availability (outage exposure during Prime/Peak Times, outage primarily expected during Non-Prime Time)
- Some complexity to implementation and back-out plans - not expected to extend window timeframe
- Affects application, data or server security
- Impacts service level agreements and internal support required
Technical Impact - High Level
-IT resources from more than two workgroups, crosses IT divisions
-High complexity: complex technical coordination required with one or more functional groups
-High risk to system availability (outages expected during Prime/Peak Times)
-Complex implementation and back-out plans, back-out likely to extend the window
timeframe
-Affects security of data on infrastructure
-Impacts service level agreements (e.g. Business Prime/Peak Time)
-Outside vendor support is typically required
Business Risk and Impact Assessment
- Evaluate business risk/impact of both doing and not doing the change
- Analyse timing of the change to resolve any conflicts and minimize impact
- Ensure all affected parties are aware of the change and understand its impact
- Determine if the implementation of the change conflicts with the business cycle
- Ensure current business requirements and objectives are met.
Assigning a Risk Level for Change
Customer and/or Client Impact (H, M, L, No Risk) IT Resource Impact Implementation Complexity Duration of Change Security Service Level Agreement Impact
