CHANGE MANAGEMENT

CONTROLS ASSESSMENT
CHECKLIST

Presentation by: Arsalan Khalid

 Presentation Overview
• Introduction. What is Change management; Why is it important;
Change management concepts (Types of changes, Sources of changes,
Scope of changes); About the Checklist

• Part A – Understanding the process. Required documents; Normal

change management process; Emergency change management process

• Part B – Controls assessment. Control objectives, their risks and audit

steps to assess those control objectives

• Part C – Overall conclusion. IS auditor’s overall view to the assessment

of controls

• Further Concepts to Part A. Integral detailed concepts that need to be

understood in relation to part A, having understood the three parts.
 Process AI6 – Manage Changes
AI6.1 Change Standards and Procedures
Set up formal change management procedures to handle in a standardized
manner all requests (including maintenance and patches) for changes to
applications, procedures, processes, system and service parameters, and
the underlying platforms.
 
AI6.2 Impact Assessment, Prioritization and Authorization
Assess all requests for change in a structured way to determine the impact
on the operational system and its functionality. Ensure that changes are
categorized, prioritized and authorized.
 
AI6.3 Emergency Changes
Establish a process for defining, raising, testing, documenting, assessing
and authorizing emergency changes that do not follow the established
change process.
 …contd
 AI6.4 Change Status Tracking and Reporting
Establish a tracking and reporting system to document rejected changes,
communicate the status of approved and in-process changes, and complete
changes. Make certain that approved changes are implemented as planned.
 
AI6.5 Change Closure and Documentation
Whenever changes are implemented, update the associated system and
user documentation and procedures accordingly.
 Presentation Overview
• Introduction. What is Change management; Why is it important;
Change management concepts (Types of changes, Sources of changes,
Scope of changes); About the Checklist

• Part A – Understanding the process. Required documents; Normal

change management process; Emergency change management process

• Part B – Controls assessment. Control objectives, their risks and audit

steps to assess those control objectives

• Part C – Overall conclusion. IS auditor’s overall view to the assessment

of controls

• Further Concepts to Part A. Integral detailed concepts that need to be

understood in relation to part A, having understood the three parts.
 What is Change Management?
Change management is set of processes executed within the organization’s
IT department designed to manage the enhancements, updates and
incremental fixes to production systems, which include:
• Infrastructure changes (servers, cabling, routers, firewalls, etc.).
• System upgrades (applications, operating systems and databases).
• Application code revisions.

Collectively, we refer to these as “IT changes”. All organizations have to deal

with IT changes effectively. When changes fail or are poorly controlled, the
impact on the business can range from minor inconvenience to events that
hinder the achievement of business objectives, including the ability to
comply with relevant laws and regulations.
Why is Change management important?
When IT systems play a pervasive role throughout an entity, having an
ineffective IT change management possesses pervasive risks. For instance
consider the following:
• Lost opportunities. The entity is unable to deploy effective and efficient
services to its internal and external customers/stakeholders. This
occurs when having to commit resources to unplanned work, as a
consequence of unmanaged changes. Unplanned work can be manifest
as lost/unbudgeted time, lost/unbudgeted resources (people, capital),
and unbudgeted costs. These lost opportunities result in intangible
costs.
• Unauthorized, untracked changes create potential exposure for fraud.
• Business requirements can be misinterpreted with respect to required
IT changes, and thus poorly or inadequately implemented.
• Given that changes are not likely to be evaluated with respect to one
another, there is a lack of change prioritization, resulting in either
working on the wrong things or working on something that is less
important. The work may be done out of the intended sequence,
resulting in rework and duplication of effort.
 …contd
• There is little to no ability to forecast the impact of a change on
existing business processes.
• Resources regularly are diverted to rework, as a result of having to
address the unintended consequences of unmanaged changes.
• There is high turnover in technical staff and evidence of “burnout” in
key staff.
• Ad hoc, chaotic, urgent behavior requires regular intervention of
technical experts/heroes; a high percentage of time is spent in
“firefighting” mode on reactive tasks.

Conversely, an effective IT change management process leads to following

benefits
 …contd
• Adequate resources can be committed with the confidence that they
are sufficient, and based on tracked historical performance resulting in
services that satisfy internal and external customers/stakeholders.
• Change management controls (embedded in well defined IT
operational processes) are used to help ensure the consistency and
predictability necessary to achieve business goals that rely on these
processes. In other words, IT staff understands how effective change
management supports meeting business objectives.
• Increasingly, more time and resources are devoted to strategic IT
issues, due to the organization having mastered tactical (day-to-day
operational) concerns.
• Effective change management serves as an essential control for IT
governance.
• Preventive and detective controls are automated, allowing for easier
and more accurate reporting to regulatory authorities, requiring fewer
manual inspections by the entity.
 …contd
• Timely identification and resolution of operational problems, including
security incidents. There is a decreasing demand for customer support
center/help desk resources.
• Effective tradeoffs are performed regularly, balancing the risk and cost
of change with the opportunity. Changes are scheduled and prioritized
accordingly.
• Resources (time, effort, capital) are applied to implement selected
changes, with little to no wasted effort (high change success rate);
resources rarely are diverted to unplanned work.
• Variances in production configurations are detected early so as to incur
the lowest cost and least impact.
• The enterprise regularly demonstrates operational excellence with
respect to change management. IT is able to return to a known,
reliable, trusted operational state quickly when problems arise with a
new change or configuration.
Change management concepts
TYPES OF CHANGES
• Normal Changes: Changes that must go through assessment,
authorization and Change Control Board (CCB) agreement before
implementation e.g., Patch management of Server OS.
• Emergency Changes: Highly critical changes needed to restore failed
high availability or widespread service failure (e.g., server crash), or
that will prevent such a failure from imminently occurring.
• Standard Changes: Pre-authorized repetitive, low-risk, well-tested
changes. Often these are operational maintenance changes e.g., Patch
management of client OS.
 … contd
Change Type Description
Application Changes made to application systems, including new implementations
or functional updates, application development tools and utilities,
location / directory changes, interfaces to other applications, updates to
web site pages, URL links, etc.
Operating System Upgrades, migrations, installation, de-installs of system level software –
(operating system, utilities, middleware, tools) and configurations
(servers, disk arrays, etc.) that impact the operational environment.
Database Upgrades, migrations, installation, de-install of database software and
database utilities as well as database configurations changes
configurations (servers, disk arrays, etc.) that impact the operational
environment.
Procedures Changes / updates to processing schedule and sequences (including
runbooks), scripts for back ups, batch processes, etc. Documentation
updates that require notification and distribution to other groups.
Security Changes / updates to security authorization and authentication to
forms, processes and documents and just deal with impact analysis.
Changes / updates to the data center or university firewalls.
Scheduled Outages Changes / Updates to planned events (e.g. system maintenance,
backup times)
 … contd (change reviewer assignment)
Component Name Location/Phon
e
Servers – Linux (hardware / operating
system / utilities)
Servers – Unix (hardware / operating
system / utilities)
Servers – Windows
(hardware / operating system / utilities)
Storage Area Network
Networking – LAN
Networking – WAN
Networking – Routers / Hubs
Security - Software Updates
Security – Firewall
Security – Authentication (LDAP)
Database (Oracle)
Database (SQL Server)
Content Management Tools
Middleware Tools
Application Server – Oracle
Application – Portal
……………
 …contd
SOURCES OF CHANGES: Factors that may require change to
production environment are:
• External environment (competitive market, stakeholders /
shareholders, changing risks).
• Regulatory environment.
• Business objectives, goals, strategies, requirements,
processes, and shifts in priorities.
• Vendors (new products, upgrades, patches, and
vulnerabilities), partners and suppliers.
• Results of an audit, risk assessment, and other type of
evaluation or assessment.
• Operational problems.
• Changes in performance or capacity requirements.
 …contd
SCOPE OF CHANGES: An effective change management process
encompasses within its scope, any and all alterations to all IT-
based assets on which business services depend (i.e.,
production environment IT based assets). Assets subject to
change management include:
• Hardware: mainframes, servers and SAN / LAN / WAN
devices
• Software: operating systems and applications.
• Information, data, and data structures: files and databases.
• Security controls: anti-virus software, firewalls, and
intrusion protection / detection systems.
• Policies and processes / procedures.
• Roles / responsibilities: authorization, authority to act, and
access controls.
 About The Checklist
This checklist focuses on IT operational change management, beginning
when upgrades or updates to IT assets (infrastructure, applications) are
identified for movement to production and ending when such assets are
retired from the production environment. This includes application
maintenance and emergency change controls, and excludes the changes
that occur during system / software development life cycle (usually termed
as SDLC). This checklist is divided in three parts.
• Part A tends to develop the understanding of IS auditor about the
change management process; here, IS auditor should obtain the
documentation and develops the understanding of the process by
referring to documentation, interviews and walkthroughs
• Part B discusses the control objectives governing the change
management process, and mentions the audit steps / tests IS auditor
need to perform in order to have assurance regarding that control
objective
• Part C is overall conclusion IS auditor arrives at on the basis of tests
performed in Part B.
 …contd
The term, change management, as used in the checklist, excludes the
process of configuration management. Configuration management is
concerned with identifying, controlling, maintaining, and verifying the
versions (hence called configuration) of all IT components (hardware,
software, associated documentation). However, the change management
process must interact with the configuration management process (and
related controls) when changes are made to configurations.

After reading this checklist, IS auditor will:

• Become familiar with the concept of change management, and have a
working knowledge of IT change management processes.
• Be able to recognize red flags and indicators that IT environments have
related to change management.
• Understand the preventive, detective, and corrective controls within a
change management process.
• Be in a position to effectively audit the IT change management process.
 Presentation Overview
• Introduction. What is Change management; Why is it important;
Change management concepts (Types of changes, Sources of changes,
Scope of changes); About the Checklist

• Part A – Understanding the process. Required documents; Normal

change management process; Emergency change management process

• Part B – Controls assessment. Control objectives, their risks and audit

steps to assess those control objectives

• Part C – Overall conclusion. IS auditor’s overall view to the assessment

of controls

• Further Concepts to Part A. Integral detailed concepts that need to be

understood in relation to part A, having understood the three parts.
 Required documents

Following are the important documents that IS auditor need to collect from relevant
official of the entity and understand, BEFORE conducting the audit of the change
management process
• Organization Chart.
• Logical and physical process flowcharts and system diagrams.
• IT change management policies and procedures.
• Workflow diagrams depicting the IT change management process.
• Listing of personnel and organization chart(s) showing participants in change
management, process owners, especially those responsible for authorizing,
developing / preparing and implementing changes.
• Naming conventions for application production and QA source, executable,
command language and copy libraries/directories.
• Naming conventions for system software production and QA source, executable,
parameter and command language libraries/directories.
• Information regarding third-party service providers involved in the process, including
relevant SLAs and contracts.
• Inventory and descriptions of production environment elements in change
management scope (for example, network devices, servers, libraries, databases
 …contd

• Sample reports showing how change management request is lodged, and how
change management process is escalated including how the said reporting is done
i.e., metrics, standards, and service level commitments are reported to
management.
• Service desk problem reports and analyses.
• Most recent self-assessment, results and action plans.
• A report listing the total number of changes during time period under review (e.g.,
last 6 months):
• Hardware: emergency/non-emergency
• Software: emergency/non-emergency.
• (Electronic) copy of all change management logs and forms.
• Change reviewer assignment list
• Current vendor documentation for any library management or change control
software in use.

On the basis of above mentioned documentation, IS auditor should understand the

design and operation of both normal change management process and emergency
change management process. IS auditor should conduct interviews and perform
walkthroughs where relevant. Consider the following diagram for normal change
management process
Normal change management process
 …contd

Change Status
Open Initial status upon completing forms and submitting to
Change Manager
Reviewed Updated status after reviewers have assessed change
and provided feedback (prior to CCB decision)
Approved Updated status after CCB has discussed change and
approved / scheduled change for implementation
Rejected Updated status after CCB has discussed change and
denied the request
Failed Updated status after change implementation has been
attempted and failed
Implemented Updated status after changed implementation has been
successful
Closed Updated status after change has been reviewed for
closure by the CCB.
 …contd
Change request
• The Change Request (CR) form is completed and signed by department / individual
requesting a change.
• After appropriate business approvals / sign-offs have been acquired, the CR is
forwarded to the Change Manager or equivalent

Change manager
• The Change Manager validates the CR for completeness and logs the CR information
into the Change Control Log for tracking. Incomplete CR’s are returned to the
requestor for update and re-submission.
• The Change Manager evaluates the nature of the request and makes preliminary
assignments as to Change Type, Change Priority and Change Impact.

Change reviewer
• The CR is forwarded to the appropriate Change Reviewer(s) to assess the Change
impact.
• The Change Reviewer(s) evaluate the request and describe how the change impacts
the infrastructure and other related components. In many cases, the original change
requestor becomes part of the impact assessment process to provide additional
input and guidance. In addition, the change reviewer(s) also validates the change
priority and change type. (The Change Impact Table, Change Priority Table can be
used as tools to assess the change.
 …contd

• Change Reviewer(s) respond within the timeframe specified by the Change Manager.
Timeframe is dependent on the priority of the request.
• The Change Reviewer(s) provide feedback to the Change Manager to update the
Change Control Log and provide the status of the CR to the requestor.

Change Control Board

• The Change Control Board (CCB) meets on a regular schedule to review new change
requests and receive status updates on outstanding requests. The Change Manager
is responsible for coordinating and chairing the meeting.
• The Change Manager provides information from the Change Request form as well as
the impact assessment input provided by the Change Reviewers to create a CCB
Agenda for the meeting.
• Changes are reviewed and validated as to Change Impact and Change Priority by the
CCB.
• Changes assessed with Minor Impact by the Change Reviewer(s) may be approved
and scheduled for implementation by the Change Manager and do not require CCB
approval according to the policy of the organization. (All such scheduled changes
must be reported to the Board as part of the meeting.)
• The CCB reviews all other changes in detail, discusses and evaluates each request as
to objective, reasons, impact, cost, time and benefits. Each Board member
represents their department and provides guidance on the change requests.
 …contd

• The CCB also reviews multiple requests to coordinate implementations and

“package” requests into a single release schedule (e.g. three applications areas
requesting migration to a new version of a database).
• All changes occur to the staging and production environments on a pre-defined
schedule. The Change Control Board determines how to schedule the change within
the pre-defined schedule based on other planned changes, estimates to complete
the updates, testing, implementation and available resources. (Priority Impact Action
Matrix)

Change Implementer
• The CCB approves or rejects the change request documenting reasons for the
decision. Approved changes are scheduled for staging and production
implementation. The Change Manager updates the Change Control Log and provides
the final status to the requestor.
• If the schedule changes (request delays or changes in priorities) the CCB review the
impact and reschedules the change at the next CCB meeting.
• Scheduled change requests are released to the staging platform and staging tests are
performed as per the implementation and test plans by the Change Implementer.
(Staging tests include, but are not limited to: installation scripts, data conversion,
load/stress, rollback/recovery, fail-over, etc. The Change Implementer signs off on
the results of the testing of each report.)
 …contd

• Staging test results are reviewed with the CCB at the next CCB meeting. The results
are reviewed by re-examining the impact assessments verifying that each impact has
been tested for and/or verified by the Change Implementer(s). Successful staging
test results are released for Production Implementation. The Change Manager
updates the Change Control Log with the status.
• Production Implementation results are reviewed with the CCB at the next CCB
meeting. Successful Implementation results recorded in the Change Control Log.
• On a periodic basis, the Change Manager produces a report to communicate all
implementations to all involved groups through a standard distribution list. The
Change Manager also reviews the Change Control Log and Change Request Forms to
analyze for trends on type, frequency and size of changes.
 Change priority and impact table
Change Priorities
Priority 1 - Emergency Causes loss of service or severe usability problems to a large number of
users, or some equally serious problem. Immediate action is required.
(Emergency changes) Resources are allocated immediately to implement authorized change.
Impact - Major Typical situations are virus attacks, server security violations from outside
the enterprise (through internet / firewall) or crashes of mission critical
systems. Implementation in the production environment has priority against
all other scheduled and pending activities of the required staff. The
implemented change must still be logged by the change manager and
reported to the CCB.

Priority 2 - High Priority Severely affects some users or impacts a large number of users. Typically
given the highest priority when being considered by the CCB for staging
(Normal change) and implementation scheduling. Typical situations for this level of priority
Impact - Major are the preventive protection (e. g. against new viruses) or fixing poorly
developed and installed mission critical systems. All information of the
change request form has to be delivered and tests in the staging
environment have to be performed. The CCB may evaluate scheduling of
the change outside of the next scheduled release or upgrade.

Priority 3 - Medium No severe impact but does require resources for both staging and
Priority implementation. Typically is assigned for scheduled maintenance changes
and/or functionality improvements to applications. Preventive fixes or
(Normal change) improvements on the IT infrastructure (e. g. required capacity
improvements notified through monitoring processes) are typically allocated
Impact - Medium in this level. No special resources are required for integration testing and
deployment.

Priority 4 - Low Priority A change is justified and necessary but can wait until the next scheduled
release or upgrade. To be allocated resources as schedules permit.
(Standard change) Changes in this level are planned through the defined update cycle for
Impact - Low software releases and hardware upgrades or the implementation plans of
new services
 Impact analysis criteria

When Change reviewer or CCB are assessing/analyzing the impact of the change under
consideration, following aspects should be considered:
Aspect Description
Business congruence and Assess statements as to regulatory or mandated requirements
Benefits
– cost reduction potential
– revenue generation potential
– improvement of business processes
– improvement to technology infrastructure (efficiency, effectiveness)

Applications and Interfaces Impact to applications running in the infrastructure environment

Contingency/Disaster Recovery Impact to existing contingency or disaster recovery plans

Cost/Effort Estimates Cost and effort /resource estimates required to implement the change

Interdependencies Other projects or change requests which depend upon this request
and/or are required for successful implementation
Performance and Capacity Implications on infrastructure performance and capacity of change

Risk Implications of failure of the change based on size and scope of the
request
Security Implications for user or system security
Technical information Sufficiency of the technical information available to assess the change

Urgency of request Level of urgency – should be implemented in immediately, near term,

long term, etc..
Users Impact on users of the applications and/or infrastructure
Composition of CCB

The official with overall responsibility of the change management –

the change manager (CCB member) - will normally chair the CCB
and potential members include:
• User group representative(s)
• System administration
• Applications developers/maintainers
• Quality assurance
• Specialists / technical consultants
• Services and operations staff, e.g. Service Desk, test
management.
• Facilities / office services staff (where changes may affect
moves / accommodation and vice versa)
• Contractor’s or third parties’ representatives, e.g. in
outsourcing situations.
Emergency change management process
 …contd

On occasion, changes of an “emergency” or critical nature may be required to quickly

address production issues/outages. Emergencies usually occur as a result of problems
and enter the Change Management process from a request from a Problem Manager
(who gets the required information from problem log).
 
In the case of emergency changes a streamlined process is used to allow the fastest
possible response while still maintaining the proper levels of approval, logging,
monitoring, communication and closure of all change related activities.

The emergency change procedure supports the implementation of urgent fixes or updates
to the production platforms of the IT infrastructure. Emergency changes follow a
streamlined process that still provides for review, approval and logging of changes. To
speed processing recovery, many details are captured after the fact.

Change request
• The Emergency Change Request (ECR) form is completed by any person /
department requesting an emergency change to the entity IT Infrastructure and is
submitted to the Change Reviewer.
 …contd

Change reviewer
• The Change Reviewer evaluates the nature of the request and evaluates the urgency
of the change using the definitions of Change Type, Change Impact and Change
Priority. In many cases, the original change requestor becomes part of the impact
assessment process to provide additional input and guidance. In most cases, the
Change Reviewer for an ECR is the Change Requestor’s supervisor or an assigned
resource within the IT Infrastructure.
• The Change Reviewer(s) also evaluates how the change impacts the infrastructure.
The Change Reviewer may elect to involve other members of the Infrastructure
Group or the wider CCB if the change is evaluated as Major Impact (multiple
systems, etc.).
• The Change Reviewer(s) approves the ECR and updates the ECR Log to record key
information regarding the change. The ECR is forwarded to the Change
Implementers for implementation. (Note: the Change Implementers may be the
original Change Requestor).
 …contd

Change implementer
• The Change Implementer completes the change and provides information to the
Change Reviewer to update and close out the ECR Log and Change Management
documentation.
• The Change Reviewer forwards the ECR log to the Change Manager for update to the
Change Control Log. The Change Manager provides an update status to the CCB
during the next scheduled CCB meeting.

Question – Devise a standard change process.

Change request – Change reviewer (No entry in ECCL, just approval) – Change
implementer – Change manager (change control log) - CCB
 Presentation Overview
• Introduction. What is Change management; Why is it important;
Change management concepts (Types of changes, Sources of changes,
Scope of changes); About the Checklist

• Part A – Understanding the process. Required documents; Normal

change management process; Emergency change management process

• Part B – Controls assessment. Control objectives, their risks and audit

steps to assess those control objectives

• Part C – Overall conclusion. IS auditor’s overall view to the assessment

of controls

• Further Concepts to Part A. Integral detailed concepts that need to be

understood in relation to part A, having understood the three parts.
Control objective(s)
• Only appropriate changes are approved,
• Only approved changes are implemented, and
• Implemented changes meet the business requirement
(COBIT AI6.2, AI6.4, AI6.5)

Risks/Exposure(s)
Inappropriate and unapproved changes could result in bugs, errors
and unpredictable business solutions that would not meet the
users' requirements.
 Audit steps/tests

While performing walkthrough of change management process,

ensure that following elements are explicitly elaborated:
• Who RAISED the change
• What is the REASON for the change?
• What is the RETURN required from the change (the change
benefits)?
• What are the RISKS involved in the change (the problems
caused and their severity)?
• What resources are REQUIRED to deliver the change (the
change costs)?
• Who is RESPONSIBLE for the build, test and implementation of
the change?
• What is the RELATIONSHIP between this change and other
changes (the effectiveness and efficiency with which the
change has been implemented)?
 …contd

For sample of changes, review that change request is lodged using a standard
change request form (which may be electronic). At a minimum, the form should
include:
• A unique control number (preferably system generated) to allow system
administrator to easily track the status of the change
• The requestor's name, department
• Date of request,
• Date the change is needed,
• Reason for the change,
• Name of modules/applications/systems that need to be changed.
• A cost justification analysis
• Expected Benefits of the change.
• Priority of the request,
• A thorough description of the Change request,
• A description of any anticipated effects on other systems or programs,
• Fallback procedures in case the changes cause the failure of the system.
• Evidence that change request form has been reviewed and authorized by
user management/Head of the relevant department.
 …contd

Review whole case of each change selected in above sample, and ensure that following
activities are evident from the case:
• Create and record
• Review
• Assess and evaluate
• Authorize
• Plan
• Coordinate
• Review
• Close

Import the complete population of change request in data analysis application such as
ACL, and ensure that data analysis confirms that business process as identified in earlier
part is followed, and that audit trail is complete. Also perform the following tests:
• Data integrity verification
• Completeness
• Sequence
• Validity
• Duplicate
• Logical relationship
• Trend analysis for systems having unusually high number of changes
 …contd

Ensure estimated time of completion and budgeted costs are communicated.

Evaluate the process used to control and monitor change requests

For sample of changes, ensure that before final approval:

 Requirements are verified as meeting the business case for the change.
 Requirements have been met as evidenced by the testing.
 Testing has adequately demonstrated the change will not harm the production
environment.

For sample of changes, ensure that:

 Controls ensure that the components implemented into production are the
same as the components developed, tested, and approved.
 Source and executables implemented into production match one another.
 Post-implementation review assesses its effectiveness and measures it against
the business case applied in initiating the change.
Control objective
Emergency changes are implemented in a way that preserves
transparency. (COBIT AI6.3)

Risks/Exposure(s)
Lack of an emergency change process could result in the
unauthorized migration of code into production. This may result in
delays in production processing, hence, user dissatisfaction.
Further, emergency changes may bypass and/or compromise
existing change controls
 Audit steps/tests

Determine that IT change management policies and procedures define parameters for
emergency changes. Existing policies and procedures must control these changes when
they circumvent the normal process of technical, operational and management
assessment prior to implementation.

Perform a walkthrough for emergency change procedures to make sure emergency

changes can be implemented quickly, effectively, and in a way that preserves
accountability, traceability, and independent review.

Select a sample of emergency changes during the audit period and ensure that:
• The change was needed for a true emergency i.e., the change was not masked as
emergency change
• Emergency procedures were followed.
• Procedures require that emergency changes be supported by appropriate
documentation (e.g., evidence of management approval, code review) within one
business day after the emergency is resolved.
• Emergency changes are made through the use of emergency Ids. Ensure a process
exists to enable and disable them.
• Ensure an audit trail exists of all emergency ID usage and that it is independently
reviewed.
 …contd

• Appropriate management of affected areas is notified promptly.

• Unapproved changes were detected, and exceptions were raised and resolved
promptly. Any necessary cleanup was completed promptly
• User manuals are updated with changes affecting the user interface, the program
functioning, security, and other changes.
• Ensure back-out procedures exist for emergency changes. These procedures should
outline the process used to back code out of the production.
• Determine the number of emergency changes made during the audit period under
review. Analyze the volume of emergency access requests and determine if it
appears to be excessive. In which case adequate controls need to be implemented.
• Determine if emergency fixes are closed out in a reasonable amount of time.
Control objective
IT changes are implemented in appropriate sequence without
interfering with other changes. (COBIT AI6.4, AI6.5)

Risks/Exposure(s)
Production system may not run effectively and efficiently in
presence of changes that are interfering with each other.
 Audit steps/tests

For sample of changes ensure that there exists control that ensure:
• Standard Changes are implemented periodically as releases
rather than as isolated modifications to the production
environment.
• Normal changes that are lodged by different user departments
are implemented in appropriate sequence with full business
case justification of priority
• Changes that may affect one another are synchronized
appropriately (for example, only one programmer at a time is
modifying a given module).
Control objective
Changes are implemented accurately and as intended. (COBIT AI6)

Risks/Exposure(s)
Lack of a change control process could result in un-tested /
unauthorized migration of code into production. This could result in
delays in production processing, hence, user dissatisfaction. Also,
this could result in unauthorized changes adversely affecting
application processing to produce unintended results.
 Audit steps/tests

Select a sample of non-emergency changes (application/ system) that have

occurred during the period of review from the source program library directory.
Using the sample selected, verify the following:
 
• All changes have been formally initiated, completely documented, and
approved by the system owner.
• All changes have documentation stating code is ready to be moved from
development to testing / Quality Assurance with the authorized approvals.
• All changes have documentation stating that they have been received and
reviewed by a Quality Assurance type function and approved by the User
prior to installation into production.
• Review User test documentation for adequacy and proper signoff.
• Documentation exists showing a source comparison was performed prior to
installation into production ensuring consistency between source and object
code (if applicable).
 …contd

In distributed systems, such as client / server architecture,

additional challenge is ensuring that changed programs are
deployed to all input nodes. Ensure that policies and procedures
provide accordingly. Also ensure that following issues are
adequately dealt in client / server architecture:
• Controls to be exercised over conversion of data
• Training of staff who will be using the changed software
• Support to be provided to users of the changed system
• Reduction of the risk associated with changing all nodes at the
same time, and having to back them all out if something goes
wrong
• All nodes are running same version of the software
Control objective
IT operations can recover efficiently and effectively from change
related problems. (COBIT AI6)

Risks/Exposure(s)
Information system may come at halt, if not recovered fully from
unsuccessful change, hence affecting daily operations of entity.
Further it may cause inconsistency among existing processes
 Audit steps/tests

Review IT change management policies and procedures to ensure

that changes must have adequate back-out documentation before
being staged to production.

For sample of changes, ensure that changes must thoroughly

document what was changed, when and by whom. Each change
must carry an accurate disposition at all times (for example, in
development, implemented, backed-out, canceled, etc.) This
documentation must be reliably accurate and easily accessible.
Control objective
Change and problem management processes are integrated.

Risks/Exposure(s)
In case of lack of integration, Production operations may not
recover efficiently from problems caused by changes.
 Audit steps/tests

Review change management procedures to make sure each change

explicitly records any problem(s) it is designed to address. Further,
review how the problem was escalated.

For selected problems from software library, ensure that each

problem-record explicitly records any change found to have caused
or contributed to the problem.
Control objective
Where IT functions are outsourced, SLA is monitored and
compliance is ensured

Risks/Exposure(s)
Lack of monitoring and supervision of compliance may lead to
ineffective and inefficient change management process.
 Audit steps/tests

When the organization is considering outsourcing IT functions to a service provider, verify

that the organization’s expectations are identified clearly in service level agreements
(SLAs) and contracts. It is important that IS auditor ensures that following issues are taken
into consideration regarding the change management process:
• Who is responsible internally for managing day to-day changes arising from requests
to make changes?
• How does the organization know when changes are made by the service provider
outside of the agreed-upon change management process?
• What control does the organization have over the service provider to ensure it is not
charged for unauthorized or unreasonable changes? How does the organization
know if such changes occur?
• What prevents the provider from approving changes outside of the required change
window time periods, with a consequent impact on service (applications not
available when needed) and cost (or loss of revenue)?
• Who is responsible for ensuring that major business changes affecting IT are properly
casted, approved, planned, controlled, implemented, and periodically reviewed?
 …contd

• Has the provider considered the impacts on infrastructure

(system and network) and information security as part of
evaluating each change?
• Has the organization identified who in the organization sits on
the provider’s change control committees?
• Who monitors compliance with the SLAs?
Control objective
Whether adequate preventive, detective and corrective controls
(including segregation of duties and audit trail) are present within
the process of change management process. (COBIT AI6.1)

Risks/Exposure(s)
Lack of segregation of duties could result in inconsistent and
unauthorized change in production environment affecting the data
integrity.
 Audit steps / tests

Review the policies and procedures, and perform walkthroughs along with
interviews, to identify whether the following controls are present in change
management process:
 
PREVENTIVE CONTROLS:
 Change authorization.
• There should exist documentation showing the authorized owners for all the
business processes and supporting IT systems, with assigned levels of
authorizations.
 Segregation of duties.
• Documentation showing clear assignment and separation of roles and
responsibilities of the change stakeholders should exist, including change
authorization, scheduling, implementation, and review.
• There should exist clear policies describing the categories and tiers of changes
and the levels of formality, approval, and rigor associated with moving changes
within each category from the initiation to the implementation stage.
• Access to development and test environment should only be allowed to change
preparer and change implementer
• No change should be made in production
• Training and awareness programs to promote a culture of change management.
 …contd

Supervision and monitoring.

• There should be formal documentation showing that the change process is being
monitored, supervised, and enforced effectively. At any point in time, there should
be a published list of authorized changes, as well as a list of unauthorized changes,
generated by reconciling actual production changes against the authorized changes.
• Change management meeting minutes may also show newly authorized and
scheduled change requests. Each change request should have a unique identifier and
a responsible individual.
DETECTIVE CONTROLS.
 
Supervision and monitoring:
• Automated methods to detect changes made in production should be in place and
reviewed independently. These could be audit logs of changes or utilities that scan
production infrastructure for changes.
• Changes to production equipment should be traceable to work logs, work tickets,
and change orders. These should identify the date, time, implementer, and system
along with details of the changes made.
• Changes should be reviewed to ensure there is no variance between the planned
change and implemented change. Variances are reported and explained.
 …contd

CORRECTIVE AND RECOVERY CONTROLS.

• Any changes made outside of the change management process should be identified.
Appropriate documentation should describe rationale and corrective actions taken.
• Post-implementation reviews should be performed of changes made, based on the
degree of change, importance of the business activities undergoing change, and
significance of the potential risks to the business.
• When changes fail, change implementer should rule out change first in the repair
cycle by accessing authorized and scheduled changes, as well as reviewing
production changes on the affected infrastructure.

Perform a walkthrough to determine following issues, and ensure that the findings remain
relevant to the sample selected:
 
Determine if programs can be checked out by more than one programmer
simultaneously. Verify a process exists to support concurrent development.
• Does the change management software have a checkout feature?
• Is the feature used?
• If the feature is not used, how are simultaneous checkouts controlled?

Determine if a version control process exists to ensure the correct module was copied
from production.
 …contd

Determine how the programmer is made aware of all the modules that need to be
changed.
 
Ensure history records are kept of code check-ins / outs, and deletions, which are made to
the production library. Determine if a work order number is associated with the history
record (this should be traceable back to the initial request)
 
Verify a process exists that requires programming management to review the source
documentation or code [if applicable] to ensure changes are appropriate and meet the
departments programming and documentation standards.
 
Ensure all changes are applied to a copy of the latest production version of code.
 
Verify code is modified / developed in an area separate from testing and production.
 
Verify code is tested in staging environment (a testing region which is separate from
development and production).
 
Determine how code is moved into the staging environment.
 …contd

Determine who moves the code into the staging environment.

 
Determine a process exists to "freeze" code once migrated into the testing/quality
assurance environment. This ensures no further changes can be made to the code while
awaiting User acceptance.
 
Determine to what extent the User is involved in the testing process (e.g., preparation of
tests and data).
 
Ensure the test results are reviewed and approved by the User. Verify the method of User
acceptance (e.g., verbal, written).
 
Determine that any changes resulting from user testing triggers a complete re-testing of
the relevant business process.
 
Verify the existence of back-out procedures. These procedures should outline the process
used to back code out of the testing region, in the event the User does not approve the
original changes and additional modifications are necessary.
 …contd

Verify procedures exist to ensure the approved code from the test environment is the
version moved into production.
 
Determine who is responsible for migration of code into production.
 
Determine how code is implemented into the production environment.
 
Determine if a process exists to reconcile changes scheduled for implementation to those
changes actually implemented. Verify who performs this process and how often the
process takes place.
 …contd

Import the complete population of change request in data analysis application such as
ACL and ensure that data analysis confirms the segregation of duties and other controls as
mentioned in this checklist
Process Performed by whom Segregated from
Change request  User management, See *
 IT operations/control group,
 System administration.
Change approval  Change manager (Chair of CCB) See *
Change preparation  Departmental staff of relevant change See *
and testing implementer
Change  System administration See *
implementation/  Database administration
deployment to  Network administration,
production  Network engineering,
 SAN administration
Change reviewer  R&D Change preparer
 Internal Audit and
 Quality assurance Change implementer
 Designated member of CCB
Change audit  Internal Audit , All the rest
 External auditors

* The requester, approver, preparer and implementer are NOT performed by same department/ section. Where a member
of these departments is also part of CCB, he is to remain independent of request, approval, preparation and
implementation.
Control objective
A clear audit trail exists within change management process.

Risks/Exposure(s)
Cause of bottlenecks cannot be identified incase error occurs.
Hence problem escalation becomes slow and time consuming
 Audit steps/tests

Review audit trail technology and related processes. No individual

should have ongoing access rights to delete or modify the audit
trails. The audit trails should be managed so as to keep them
available for convenient review in the short term and for
investigation in the long term.

For sample of changes, ensure that there exist procedures for

reviewing audit trails of changes to production elements in scope.
Ensure they require timely, independent review, follow-up of
exceptions, and evidence of review.
 Presentation Overview
• Introduction. What is Change management; Why is it important;
Change management concepts (Types of changes, Sources of changes,
Scope of changes); About the Checklist

• Part A – Understanding the process. Required documentation; Normal

change management process; Emergency change management process

• Part B – Controls assessment. Control objectives, their risks and audit

steps to assess those control objectives

• Part C – Overall conclusion. IS auditor’s overall view to the assessment

of controls

• Further Concepts to Part A. Integral detailed concepts that need to be

understood in relation to part A, having understood the three parts.
Having audited the change management process, IS auditor should consider
whether the change management process provide for:
• Business case information to guide prioritization of change efforts.
• Structured risk and impact assessment considering all possible impacts
on the operational system and its functionality.
• Categorization and prioritization of changes.
• Specific handling of emergency changes.
• Communication to change requesters regarding the status of their
request.
• Requirements definition of change.
• Testing (including unit, regression, system, integration, capacity /
performance, and user acceptance testing as appropriate).
• Appropriate generation and / or modification of related documentation.
• Adequate communication of pending changes to affected parties,
including management, users, developers, security administrators, IT
operations, and help desk staff.
• Appropriate segregation of development, test, and production
environments.
• Adequate consideration of controls implications (for example, including
information security management early on).
• Adequate consideration of business continuity effects.
• Responsibilities for investigating failures, together with the incident
resolution process.
• Controls defined throughout the process of change.
 Presentation Overview
• Introduction. What is Change management; Why is it important;
Change management concepts (Types of changes, Sources of changes,
Scope of changes); About the Checklist

• Part A – Understanding the process. Required documents; Normal

change management process; Emergency change management process

• Part B – Controls assessment. Control objectives, their risks and audit

steps to assess those control objectives

• Part C – Overall conclusion. IS auditor’s overall view to the assessment

of controls

• Further Concepts to Part A. Integral detailed concepts that need to be

understood in relation to part A, having understood the three parts.
 Roles and Responsibilities
Role Responsibilities Role Responsibilities
Change  Monitors all change activities in the entity IT Change  Initiates a request for change
Manager Infrastructure environment Requestor  Modifies a change request
 Receives request for change from change  Acquires business/management approvals for
requestors change
 Tracks changes to closure Change  Analyzes the change request for validity, feasibility
 Receives, logs and allocates a priority, in Control Board  Accepts or Rejects a request for change
collaboration with the requestor to all CR’s  Assigns the request for change to change reviewers
 Distributes CR’s to Change Reviewer for for impact analysis
impact assessment  Assigns request to change implementor for
 Schedules CR reviews for CCB meeting, implementing accepted change requests
issues agenda and circulates CR’s to CCB  Approves changes implementation
members in advance of meetings to allow prior
consideration Change  Review requested changes
 Chairs all CCB meetings Reviewer  Analyze the impact of implementing the requested
 Updates the Change Control Log with all change
progress, including any actions taken to  Assess resource and timing requirements for change
correct problems and/or to take opportunities Change  Implement the approved change as requested
to improve service quality Implementers  Provide status of change implementation.
 Reviews all implemented Changes to ensure  Responsible for Back out/roll back failed changes
that they have met their objectives. Refers
back any changes that have been backed out Change  Prepare the change as directed by implementer
or have failed prepares  Conducts staging tests
 Closes CR’s
Change  Review requested changes
 Produces regular and accurate management
Reviewer  Analyze the impact of implementing the requested
reports
change
 Updates list of CCB members, Change
 Assess resource and timing requirements for change
Reviewers and administrative forms
 Change reviewer assignments
Component Name Location/Phone

Servers – Linux (hardware/operating

system/utilities)
Servers – Unix (hardware/operating
system/utilities)

Servers – Windows
(hardware/operating system/utilities)

Storage Area Network

Networking – LAN
Networking – WAN
Networking – Routers/Hubs

Security - Software Updates

Security - Firewall
Security – Authentication (LDAP)
Database (Oracle)

Database (SQL Server)

Content Management Tools

Middleware Tools
Application Server - Oracle
Application – Portal
……………

……………
 CCB meeting agenda

Change Control Board Meeting – Sample Agenda

 
i. Introduction/Roll Call
ii. Review past meeting minutes
iii. Emergency Change Requests installed in production
• Review Emergency Change Control Log
iv. Minor Impact Changes installed in production
• Review Change Control Log
v. Status updates to open Change Requests
• Review Change Control Log
• Update Staging and Implementation Schedules if needed
vi. New Change Requests
• Review Change Request
• Discuss Impact
• Approve/Reject
vii. Open topics
viii. Assigning responsibilities for open/pending issues
ix. Close Meeting
 Change Request Form
Change Description/ CR Filename:
Change Request No.: Project:
Requested by: Date:
Department/ location Telephone:
Description of the change:
Change needed by (date):
Reason for the change:
Requestor Sign off:
Approval of Request:
Change Impact Evaluation (use page 2 for details)
Change Application Database
Type Hardware Procedures
Network Security
Operating System/Utilities Schedule Outage
Change Urgent Change Minor
Priority High Impact Medium
Medium Major
Low
Environment(s)
Impacted:
Estimated Resources: [cost or effort]
Resource requirements:
(personnel , h/w, s/w )
Test Plan Description
Rollback Description
Change Approval or Rejection
Change Request Status Accepted Rejected
Comments:
Change scheduled for (date):
Implementation assigned to (names):
CCB Sign off:
Change Implementation
Staging test results:
Implementation test results:
Date of Implementation
Implementor Sign Off Date
 …contd

Change Impact Assessment Change Request No:

Component Change Effort / Impact description Test Test
Reviewer Cost Description Performed
Name Date
 Elements discussed in CRF
Change Description
Change Request Number (CR) A sequential number assigned to record change
Project Name of the project under which CR is being requested (if applicable)
Requested by Name of person requesting change
Date Submission date of CR
Department/location telephone Department/location/telephone of change requestor
Description of change Detailed text describing nature of change
Change needed by (date) Date by which change needs to be implemented (if applicable)
Reason for change Detailed text describing reasons and benefits to making the change
Change requestor signature
Approval signature
Change Impact Evaluation
Change Impacts Assessment as to what components and how the change impacts the existing staging and
production infrastructure (detailed)
Change Priority Assessment of the urgency of the request to evaluate scheduling and resource assignment.
Environment Impacted Logical names/tables of servers/networks being impacted by change
Estimated Resources Estimates as to the effort and/or cost required (both internal and external) to prepare and
implement the change into the staging and production infrastructure
Testing Plan Description of the test plan to validate changes in the staging and production infrastructure
Rollback Plan Description of the plan to restore the environment to pre-change status in the event the change
fails
Description of Change Components Detailed list of impact of change on production environment
Change Approval or Rejection
Change Status Status of the CR (Open, Reviewed, Scheduled, Approved, Implemented, Failed)
Comments Reasons (if any) from Change Control Board as to status
Date Scheduled Dates for staging and production implementation
Change Implementers Name of person/department assigned to manage change implementation
CCB Signoff Approval of representative of Change Control Board
Change Implementation
Staging Results Description of staging results/date of completion
Implementation Results Description of production implementation results/date of completion
Implementation sign off
 Change Control Log

Change Request CR Filename Requested By Request Date Department/ Description of Change Environment
Nbr Location
Telephone

Change Priority Change Status Date Change Staging Results Notes Date Implementation
Scheduled Implementers Implemented Results Notes
Elements discussed in Change Control Log
(CCL)
Change Control Log (CCL)
Change Request Number A sequential number assigned to record change
Requested by Name of person requesting change
Request Date Submission date of CR
Department/location telephone Department/location/telephone of change requestor

Description of change Detailed text describing nature of change

Environment Impacted Logical names/tables of servers/networks being impacted by
change

Reason for change Detailed text describing reasons and benefits to making the
change

Change Priority Assessment of the urgency of the request to evaluate

scheduling and resource assignment.

Change Status Status of the CR (Open, Reviewed, Approved, Scheduled,

Implemented, Failed)

Date Scheduled Dates for staging and production implementation

Change Implementers Name of person/department assigned to manage change
implementation

Staging Results Description of staging results/date of completion

Date Implemented Description of production implementation results/date of
completion
 Emergency Change Request Form
Change Description/ CR Filename
Change Request No.: Project:
Requested by: Date:
Department/ location Telephon
e:
Description of the change:

Reason for the change:

Requestor Sign off:

Approval of Request:

Change Impact Evaluation

Change Application Database
Type
Hardware Procedures
Network Security
Operating System/Utilities Outage/Schedule
Change Urgent Cha Minor
Priority nge
High Impa Medium
Medium ct Major
Low

Environment(s)
Impacted:
Change Request Status Accepted Rejected
Comments:

Change scheduled for (date):

Implementation assigned to (names):

Change Implementation
Date of
Implementation
Implementor Sign Off Date
 Elements discussed in ECRF
Change Description
Emergency Change Request A sequential number assigned to record change (logged by the Change
Number (ECR) Manager after the fact)
Project Name of the project under which CR is being requested (if applicable)

Requested by Name of person requesting change

Date Submission date of CR
Department / location telephone Department/location/telephone of change requestor

Description of change Detailed text describing nature of change

Reason for change Detailed text describing reasons and benefits to making the change

Change requestor sign off Approval of request

Change Assessment
Change Impacts Assessment as to what components and how the change impacts the
existing staging and production infrastructure

Change Priority Always set to Urgent

Environment Impacted Logical names/tables of servers/networks being impacted by change

Change Approvals
Change Request Status of the CR (Accepted, Rejected)
Comments Reasons (if any) from Change Control Board as to status

Date Scheduled Dates for staging and production implementation

Change Implementers Name of person/department assigned to manage change
implementation
CCB Signoff Approval of representative of Change Control Board
 Emergency Change Control Log

Change Request ECR Filename Requested By Request Date Department/ Location Telephone
No.

Description of Environment Change Change Status Date Implemented

Change Priority
 Elements discussed in Emergency Change Control Log
(ECCL)

Emergency Change Control Log

Change Request Number A sequential number assigned to record
change (start with E)
Requested by Name of person requesting change
Request Date Submission date of CR
Environment Impacted Logical names/tables of servers/networks
being impacted by change
Department/location Department/location/telephone of change
telephone requestor
Description of change Detailed text describing nature of change
Change Priority Assessment of the urgency of the request to
evaluate scheduling and resource
assignment.
Change Status Status of the CR (Open, Implemented, Failed)
Date Implemented Description of production implementation
results/date of completion
QUESTIONS and RECAP