Change Management Audit/Assurance Program
ISACA®
With more than 86,000 constituents in more than 160 countries, ISACA (www.isaca.org) is a recognized worldwide
leader in IT governance, control, security and assurance. Founded in 1969, ISACA sponsors international
conferences, publishes the ISACA Journal®, and develops international information systems auditing and control
standards. It also administers the globally respected Certified Information Systems Auditor™ (CISA®) designation,
earned by more than 60,000 professionals since 1978; the Certified Information Security Manager ® (CISM®)
designation, earned by more than 10,000 professionals since 2002; and the new Certified in the Governance of
Enterprise IT™ (CGEIT™) designation.
Disclaimer
ISACA has designed and created Change Management Audit/Assurance Program (the “Work”), primarily as an
informational resource for audit and assurance professionals. ISACA makes no claim that use of any of the Work
will assure a successful outcome. The Work should not be considered inclusive of all proper information, procedures
and tests or exclusive of other information, procedures and tests that are reasonably directed to obtaining the same
results. In determining the propriety of any specific information, procedure or test, audit/assurance professionals
should apply their own professional judgment to the specific circumstances presented by the particular systems or IT
environment.
Reservation of Rights
© 2009 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced, modified,
distributed, displayed, stored in a retrieval system or transmitted in any form by any means (electronic, mechanical,
photocopying, recording or otherwise) without the prior written authorization of ISACA. Reproduction and use of
all or portions of this publication are permitted solely for academic, internal and noncommercial use, and
consulting/advisory engagements, and must include full attribution of the material’s source. No other right or
permission is granted with respect to this work.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
E-mail: info@isaca.org
Web site: www.isaca.org
ISBN 978-1-60420-075-1
Change Management Audit/Assurance Program
Printed in the United States of America
© 2009 ISACA. All rights reserved. Page 2
Change Management Audit/Assurance Program
ISACA wishes to recognize:
Author
Norm Kelson, CISA, CGEIT, CPA, The Kelson Group, USA
Expert Reviewers
Dinesh O. Bareja, CISA, India
Robert B. Brenis, CISA, CGEIT, MCP, PMP, Skoda Minotti, USA
Sandeep Godbole, CISA, CISM, CISSP, Syntel, India
Jimmy Heschl, CISA, CISM, CGEIT, KPMG, Austria
Samuel Chiedozie Isichei, CISA, CISM, CISSP, Protiviti, USA
Bharath Nallapu, CISA, PMP, Smith, Nallapu & Associates LLP, USA
Kathy A. Rogers, CISA, USA
ISACA Board of Directors
Lynn Lawton, CISA, FBCS, FCA, FIIA, KPMG LLP, UK, International President
George Ataya, CISA, CISM, CGEIT, CISSP, ICT Control SA, Belgium, Vice President
Howard Nicholson, CISA, CGEIT, City of Salisbury, Australia, Vice President
Jose Angel Pena Ibarra, CGEIT, Consultoria en Comunicaciones e Info. SA & CV, Mexico, Vice President
Robert E. Stroud, CA Inc., USA, Vice President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Vice President
Frank Yam, CISA, CIA, CCP, CFE, CFSA, FFA, FHKCS, FHKIoD, Focus Strategic Group Inc., Hong Kong, Vice
President
Marios Damianides, CISA, CISM, CA, CPA, Ernst & Young, USA, Past International President
Everett C. Johnson Jr., CPA, Deloitte & Touche LLP (retired), USA, Past International President
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Director
Tony Hayes, Queensland Government, Australia, Director
Jo Stewart-Rattray, CISA, CISM, CSEPS, RSM Bird Cameron, Australia, Director
Assurance Committee
Gregory T. Grocholski, CISA, The Dow Chemical Company, USA, Chair
Pippa G. Andrews, CISA, ACA, CIA, Amcor, Australia
Richard Brisebois, CISA, CGA, Office of the Auditor General of Canada, Canada
Sergio Fleginsky, CISA, ICI, Uruguay
Robert Johnson, CISA, CISM, CISSP, Executive Consultant, USA
Anthony P. Noble, CISA, CCP, Viacom Inc., USA
Robert G. Parker, CISA, CA, CMC, FCA, Deloittte & Touche LLP (retired), Canada
Erik Pols, CISA, CISM, Shell International - ITCI, Netherlands
Vatsaraman Venkatakrishnan, CISA, CISM, CGEIT, ACA, Emirates Airlines, UAE
© 2009 ISACA. All rights reserved. Page 3
Change Management Audit/Assurance Program
Table of Contents
I.
II.
III.
IV.
V.
VI.
Introduction ............................................................................................................................... 4
Using This Document ............................................................................................................... 5
Controls Maturity Analysis ....................................................................................................... 8
Assurance and Control Framework........................................................................................... 9
Executive Summary of Audit/Assurance Focus ..................................................................... 11
Audit/Assurance Program ....................................................................................................... 14
1. Planning and Scoping the Audit.......................................................................................... 14
2. Understanding Supporting Infrastructure............................................................................ 16
3. Identify Change Need ......................................................................................................... 18
4. Production Library Management ........................................................................................ 21
5. Move to Production............................................................................................................. 24
6. Emergency Changes............................................................................................................ 28
7. Change Management Governance ...................................................................................... 32
VII. Maturity Assessment ............................................................................................................... 33
VIII. Assessment Maturity vs. Target Maturity ............................................................................... 35
I. Introduction
Overview
ISACA has developed the IT Assurance FrameworkTM (ITAFTM) as a comprehensive and good-practicesetting model. ITAF provides standards that are designed to be mandatory and are the guiding principles
under which the IT audit and assurance profession operates. The guidelines provide information and
direction for the practice of IT audit and assurance. The tools and techniques provide methodologies,
tools and templates to provide direction in the application of IT audit and assurance processes.
Purpose
The audit/assurance program is a tool and template to be used as a road map for the completion of a
specific assurance process. The ISACA Assurance Committee has commissioned audit/assurance
programs to be developed for use by IT audit and assurance practitioners. This audit/assurance program is
intended to be utilized by IT audit and assurance professionals with the requisite knowledge of the subject
matter under review, as described in ITAF, section 2200—General Standards. The audit/assurance
programs are part of ITAF, section 4000—IT Assurance Tools and Techniques.
Control Framework
The audit/assurance programs have been developed in alignment with the IT Governance Institute
(ITGI) framework, Control Objectives for Information and related Technology (COBIT®)—specifically
COBIT 4.1—using generally applicable and accepted good practices. They reflect ITAF sections 3400—
IT Management Processes, 3600—IT Audit and Assurance Processes, and 3800—IT Audit and Assurance
Management.
Many organizations have embraced several frameworks at an enterprise level, including the Committee of
Sponsoring Organizations of the Treadway Commission (COSO) Internal Control Framework. The
importance of the control framework has been enhanced due to regulatory requirements by the US
Securities and Exchange Commission (SEC) as directed by the US Sarbanes-Oxley Act of 2002 and
similar legislation in other countries. They seek to integrate control framework elements used by the
general audit/assurance team into the IT audit and assurance framework. Since COSO is widely used, it
© 2009 ISACA. All rights reserved. Page 4
Change Management Audit/Assurance Program
has been selected for inclusion in this audit/assurance program. The reviewer may delete or rename these
columns to align with the enterprise’s control framework.
IT Governance, Risk and Control
IT governance, risk and control are critical in the performance of any assurance management process.
Governance of the process under review will be evaluated as part of the policies and management
oversight controls. Risk plays an important role in evaluating what to audit and how management
approaches and manages risk. Both issues will be evaluated as steps in the audit/assurance program.
Controls are the primary evaluation point in the process. The audit/assurance program will identify the
control objectives and the steps to determine control design and effectiveness.
Responsibilities of IT Audit and Assurance Professionals
IT audit and assurance professionals are expected to customize this document to the environment in
which they are performing an assurance process. This document is to be used as a review tool and starting
point. It may be modified by the IT audit and assurance professional; it is not intended to be a checklist or
questionnaire. It is assumed that the IT audit and assurance professional holds the Certified Information
Systems Auditor (CISA) designation, or has the necessary subject matter expertise required to conduct the
work and is supervised by a professional with the CISA designation and necessary subject matter
expertise to adequately review the work performed.
II. Using This Document
This audit/assurance program was developed to assist the audit and assurance professional in designing
and executing a review. Details regarding the format and use of the document follow.
Work Program Steps
The first column of the program describes the steps to be performed. The numbering scheme used
provides built-in work paper numbering for ease of cross-reference to the specific work paper for that
section. The physical document was designed in Microsoft® Word. The IT audit and assurance
professional is encouraged to make modifications to this document to reflect the specific environment
under review.
Steps 1 and 2 are part of the fact gathering and pre-fieldwork preparation. Because the pre-fieldwork is
essential to a successful and professional review, the steps have been itemized in this plan. The first-level
steps, e.g., 1.1, are in bold type and provide the reviewer with a scope or high-level explanation of the
purpose for the substeps.
Beginning in step 3, the steps associated with the work program are itemized. To simplify the use of the
program, the audit/assurance program describes the audit/assurance objective—the reason for performing
the steps in the topic area. The specific controls follow and are shown in blue type. Each review step is
listed below the control. These steps may include assessing the control design by walking through a
process, interviewing, observing or otherwise verifying the process and the controls that address that
process. In many cases, once the control design has been verified, specific tests need to be performed to
provide assurance that the process associated with the control is being followed. Test objectives are
shown in green type. The specific test process follows the test objective.
The maturity assessment, which is described in more detail later in this document, makes up the last
section of the program.
© 2009 ISACA. All rights reserved. Page 5
Change Management Audit/Assurance Program
The audit/assurance plan wrap-up—those processes associated with the completion and review of work
papers, preparation of issues and recommendations, report writing and report clearing—has been
excluded from this document, since it is standard for the audit/assurance function and should be identified
elsewhere in the enterprise’s standards.
COBIT Cross-reference
The COBIT cross-reference provides the audit and assurance professional with the ability to refer to the
specific COBIT control objective that supports the audit/assurance step. The COBIT control objective
should be identified for each audit/assurance step in the section. Multiple cross-references are not
uncommon. Processes at lower levels in the work program are too granular to be cross-referenced to
COBIT. The audit/assurance program is organized in a manner to facilitate an evaluation through a
structure parallel to the development process. COBIT provides in-depth control objectives and suggested
control practices at each level. As the professional reviews each control, he/she should refer to COBIT 4.1
or the IT Assurance Guide: Using COBIT for good-practice control guidance.
COSO Components
As noted in the introduction, COSO and similar frameworks have become increasingly popular among
audit and assurance professionals. This ties the assurance work to the enterprise’s control framework.
While the IT audit/assurance function has COBIT as a framework, operational audit and assurance
professionals use the framework established by the enterprise. Since COSO is the most prevalent internal
control framework, it has been included in this document and is a bridge to align IT audit/assurance with
the rest of the audit/assurance function. Many audit/assurance enterprises include the COSO control
components within their report and summarize assurance activities to the audit committee of the board of
directors.
For each control, the audit and assurance professional should indicate the COSO component(s) addressed.
It is possible, but generally not necessary, to extend this analysis to the specific audit step level.
The original COSO internal control framework contained five components. In 2004, COSO was revised
as the Enterprise Risk Management (ERM) Integrated Framework and extended to eight components. The
primary difference between the two frameworks is the additional focus on ERM and integration into the
business decision model. ERM is in the process of being adopted by large enterprises. The two
frameworks are compared in figure 1.
Figure 1—Comparison of COSO Internal Control and ERM Integrated Frameworks
Internal Control Framework
ERM Integrated Framework
Control Environment: The control environment sets the tone of an
organization, influencing the control consciousness of its people. It is
the foundation for all other components of internal control, providing
discipline and structure. Control environment factors include the
integrity, ethical values, management’s operating style, delegation of
authority systems, as well as the processes for managing and
developing people in the organization.
Internal Environment: The internal environment encompasses the
tone of an organization, and sets the basis for how risk is viewed and
addressed by an entity’s people, including risk management
philosophy and risk appetite, integrity and ethical values, and the
environment in which they operate.
Objective Setting: Objectives must exist before management can
identify potential events affecting their achievement. Enterprise risk
management ensures that management has in place a process to set
objectives and that the chosen objectives support and align with the
entity’s mission and are consistent with its risk appetite.
Event Identification: Internal and external events affecting
achievement of an entity’s objectives must be identified,
distinguishing between risks and opportunities. Opportunities are
channeled back to management’s strategy or objective-setting
processes.
© 2009 ISACA. All rights reserved. Page 6
Change Management Audit/Assurance Program
Figure 1—Comparison of COSO Internal Control and ERM Integrated Frameworks
Internal Control Framework
ERM Integrated Framework
Risk Assessment: Every entity faces a variety of risks from external
and internal sources that must be assessed. A precondition to risk
assessment is establishment of objectives, and thus risk assessment is
the identification and analysis of relevant risks to achievement of
assigned objectives. Risk assessment is a prerequisite for determining
how the risks should be managed.
Control Activities: Control activities are the policies and procedures
that help ensure management directives are carried out. They help
ensure that necessary actions are taken to address risks to achievement
of the entity's objectives. Control activities occur throughout the
organization, at all levels and in all functions. They include a range of
activities as diverse as approvals, authorizations, verifications,
reconciliations, reviews of operating performance, security of assets
and segregation of duties.
Information and Communication: Information systems play a key
role in internal control systems as they produce reports, including
operational, financial and compliance-related information that make it
possible to run and control the business. In a broader sense, effective
communication must ensure information flows down, across and up
the organization. Effective communication should also be ensured with
external parties, such as customers, suppliers, regulators and
shareholders.
Monitoring: Internal control systems need to be monitored—a
process that assesses the quality of the system’s performance over
time. This is accomplished through ongoing monitoring activities or
separate evaluations. Internal control deficiencies detected through
these monitoring activities should be reported upstream and corrective
actions should be taken to ensure continuous improvement of the
system.
Risk Assessment: Risks are analyzed, considering the likelihood and
impact, as a basis for determining how they could be managed. Risk
areas are assessed on an inherent and residual basis.
Risk Response: Management selects risk responses–avoiding,
accepting, reducing or sharing risk—developing a set of actions to
align risks with the entity’s risk tolerances and risk appetite.
Control Activities: Policies and procedures are established and
implemented to help ensure the risk responses are effectively carried
out.
Information and Communication: Relevant information is
identified, captured and communicated in a form and time frame that
enable people to carry out their responsibilities. Effective
communication also occurs in a broader sense, flowing down, across
and up the entity.
Monitoring: The entirety of enterprise risk management is monitored
and modifications made as necessary. Monitoring is accomplished
through ongoing management activities, separate evaluations or both..
Information for figure 1 was obtained from the COSO web site www.coso.org/aboutus.htm.
The original COSO internal control framework addresses the needs of the IT audit and assurance
professional: control environment, risk assessment, control activities, information and communication,
and monitoring. As such, ISACA has elected to utilize the five-component model for these audit/
assurance programs. As more enterprises implement the ERM model, the additional three columns can be
added, if relevant. When completing the COSO component columns, consider the definitions of the
components as described in figure 1.
Reference/Hyperlink
Good practices require the audit and assurance professional to create a work paper for each line item,
which describes the work performed, issues identified and conclusions. The reference/hyperlink is to be
used to cross-reference the audit/assurance step to the work paper that supports it. The numbering system
of this document provides a ready numbering scheme for the work papers. If desired, a link to the work
paper can be pasted into this column.
Issue Cross-reference
This column can be used to flag a finding/issue that the IT audit and assurance professional wants to
further investigate or establish as a potential finding. The potential findings should be documented in a
work paper that indicates the disposition of the findings (formally reported, reported as a memo or verbal
finding, or waived).
Comments
The comments column can be used to indicate the waiving of a step or other notations. It is not to be used
in place of a work paper describing the work performed.
© 2009 ISACA. All rights reserved. Page 7
Change Management Audit/Assurance Program
III. Controls Maturity Analysis
One of the consistent requests of stakeholders who have undergone IT audit/assurance reviews is a desire
to understand how their performance compares to good practices. Audit and assurance professionals must
provide an objective basis for the review conclusions. Maturity modeling for management and control
over IT processes is based on a method of evaluating the organization, so it can be rated from a maturity
level of nonexistent (0) to optimized (5). This approach is derived from the maturity model that the
Software Engineering Institute (SEI) of Carnegie Mellon University defined for the maturity of software
development.
The IT Assurance Guide Using COBIT, Appendix VII—Maturity Model for Internal Control, in figure 2,
provides a generic maturity model showing the status of the internal control environment and the
establishment of internal controls in an enterprise. It shows how the management of internal control, and
an awareness of the need to establish better internal controls, typically develops from an ad hoc to an
optimized level. The model provides a high-level guide to help COBIT users appreciate what is required
for effective internal controls in IT and to help position their enterprise on the maturity scale.
Maturity Level
0 Non-existent
1 Initial/ad hoc
2 Repeatable but
Intuitive
3 Defined
4 Managed and
Measurable
5 Optimized
Figure 2—Maturity Model for Internal Control
Status of the Internal Control Environment
Establishment of Internal Controls
There is no recognition of the need for internal control.
Control is not part of the organization’s culture or mission.
There is a high risk of control deficiencies and incidents.
There is some recognition of the need for internal control.
The approach to risk and control requirements is ad hoc and
disorganized, without communication or monitoring.
Deficiencies are not identified. Employees are not aware of
their responsibilities.
Controls are in place but are not documented. Their operation
is dependent on the knowledge and motivation of individuals.
Effectiveness is not adequately evaluated. Many control
weaknesses exist and are not adequately addressed; the
impact can be severe. Management actions to resolve control
issues are not prioritized or consistent. Employees may not be
aware of their responsibilities.
Controls are in place and adequately documented. Operating
effectiveness is evaluated on a periodic basis and there is an
average number of issues. However, the evaluation process is
not documented. While management is able to deal
predictably with most control issues, some control
weaknesses persist and impacts could still be severe.
Employees are aware of their responsibilities for control.
There is an effective internal control and risk management
environment. A formal, documented evaluation of controls
occurs frequently. Many controls are automated and regularly
reviewed. Management is likely to detect most control issues,
but not all issues are routinely identified. There is consistent
follow-up to address identified control weaknesses. A
limited, tactical use of technology is applied to automate
controls.
An enterprisewide risk and control program provides
continuous and effective control and risk issues resolution.
Internal control and risk management are integrated with
enterprise practices, supported with automated real-time
monitoring with full accountability for control monitoring,
risk management and compliance enforcement. Control
evaluation is continuous, based on self-assessments and gap
and root cause analyses. Employees are proactively involved
in control improvements.
There is no intent to assess the need for internal control.
Incidents are dealt with as they arise.
There is no awareness of the need for assessment of what is
needed in terms of IT controls. When performed, it is only on
an ad hoc basis, at a high level and in reaction to significant
incidents. Assessment addresses only the actual incident.
Assessment of control needs occurs only when needed for
selected IT processes to determine the current level of control
maturity, the target level that should be reached and the gaps
that exist. An informal workshop approach, involving IT
managers and the team involved in the process, is used to
define an adequate approach to controls for the process and to
motivate an agreed-upon action plan.
Critical IT processes are identified based on value and risk
drivers. A detailed analysis is performed to identify control
requirements and the root cause of gaps and to develop
improvement opportunities. In addition to facilitated
workshops, tools are used and interviews are performed to
support the analysis and ensure that an IT process owner
owns and drives the assessment and improvement process.
IT process criticality is regularly defined with full support
and agreement from the relevant business process owners.
Assessment of control requirements is based on policy and
the actual maturity of these processes, following a thorough
and measured analysis involving key stakeholders.
Accountability for these assessments is clear and enforced.
Improvement strategies are supported by business cases.
Performance in achieving the desired outcomes is
consistently monitored. External control reviews are
organized occasionally.
Business changes consider the criticality of IT processes and
cover any need to reassess process control capability. IT
process owners regularly perform self-assessments to confirm
that controls are at the right level of maturity to meet
business needs and they consider maturity attributes to find
ways to make controls more efficient and effective. The
organization benchmarks to external best practices and seeks
external advice on internal control effectiveness. For critical
processes, independent reviews take place to provide
assurance that the controls are at the desired level of maturity
and working as planned.
© 2009 ISACA. All rights reserved. Page 8
Change Management Audit/Assurance Program
The maturity model evaluation is one of the final steps in the evaluation process. The IT audit and
assurance professional can address the key controls within the scope of the work program and formulate
an objective assessment of the maturity levels of the control practices. The maturity assessment can be a
part of the audit/assurance report, and used as a metric from year to year to document progression in the
enhancement of controls. However, it must be noted that the perception of the maturity level may vary
between the process/IT asset owner and the auditor. Therefore, an auditor should obtain the concerned
stakeholder’s concurrence before submitting the final report to management.
At the conclusion of the review, once all findings and recommendations are completed, the professional
assesses the current state of the COBIT control framework and assigns it a maturity level using the sixlevel scale. Some practitioners utilize decimals (x.25, x.5, x.75) to indicate gradations in the maturity
model. As a further reference, COBIT provides a definition of the maturity designations by control
objective. While this approach is not mandatory, the process is provided as a separate section at the end of
the audit/assurance program for those enterprises that wish to implement it. It is suggested that a maturity
assessment be made at the COBIT control level. To provide further value to the client/customer, the
professional can also obtain maturity targets from the client/customer. Using the assessed and target
maturity levels, the professional can create an effective graphic presentation that describes the
achievement or gaps between the actual and targeted maturity goals. A graphic is provided on the last
page of this document (section VII), based on sample assessments.
IV. Assurance and Control Framework
ISACA IT Assurance Framework and Standards
Change management is included in ITAF. ITAF section 3630—Auditing IT General Controls—refers to
the management of software in production and the promotion of software from a test environment into
production.
ISACA has long recognized the specialized nature of IT assurance and strives to advance globally
applicable standards. Guidelines and procedures provide detailed guidance on how to follow those
standards. IS Auditing Standard S15 IT Controls, IS Auditing Guidelines G23 System Development Life
Cycle (SDLC) Review Reviews and G38 Access Controls, and IS Auditing Procedure P10 Business
Application Change Control are relevant to this audit/assurance program.
ISACA Controls Framework
COBIT is an IT governance framework and supporting tool set that allows managers to bridge the gap
among control requirements, technical issues and business risks. COBIT enables clear policy development
and good practice for IT control throughout enterprises.
Utilizing COBIT as the control framework on which IT audit/assurance activities are based aligns IT
audit/assurance with good practices as developed by the enterprise.
The COBIT Acquire and Implement (AI) domain addresses good practices for systems development and
maintenance. AI6 Manage changes specifically addresses change management:
All changes, including emergency maintenance and patches, relating to infrastructure and
applications within the production environment are formally managed in a controlled manner.
Changes (including those to procedures, processes, system and service parameters) are logged,
assessed and authorised prior to implementation and reviewed against planned outcomes
following implementation. This assures mitigation of the risks of negatively impacting the stability
or integrity of the production.
© 2009 ISACA. All rights reserved. Page 9
Change Management Audit/Assurance Program
AI6 Manage changes provides the following guidance:
 AI6.1 Change standards and procedures
–
Control objective—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.
–
Value drivers:
- An agreed-upon standardized approach for managing changes in an efficient and effective
manner
- Changes reviewed and approved in a consistent and coordinated way
- Formally defined expectations and performance measurements
–
Risk drivers:
- Inappropriate resource allocation
- No tracking of changes
- Insufficient control over emergency changes
- Increased likelihood of unauthorized changes being introduced to key business systems
- Failure to comply with compliance requirements
- Unauthorized changes
- Reduced system availability
 AI6.2 Impact assessment, prioritization and authorization
–
Control objective—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.
–
Value drivers:
- An agreed-upon and standardized approach for assessing impacts in an efficient and
effective manner
- Formally defined change impact expectations based on business risk and performance
measurement
- Consistent change procedure
–
Risk drivers:
- Unintended side effects
- Adverse effects on capacity and performance of the infrastructure
- Lack of priority management of changes
 AI6.3 Emergency changes
–
Control objective—Establish a process for defining, raising, testing, documenting, assessing
and authorizing emergency changes that do not follow the established change process.
–
Value drivers:
- An agreed-upon and standardized approach for managing changes in an efficient and
effective manner
- Formally defined emergency change expectations and performance measurement
- Consistent procedure for emergency changes
–
Risk drivers:
- Inability to respond effectively to emergency change needs
- Additional access authorization not terminated properly
- Unauthorized changes applied, resulting in compromised security and unauthorized access
to corporate information
 AI6.4 Change status tracking and reporting
–
Control objective—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.
–
Value drivers:
© 2009 ISACA. All rights reserved. Page 10
Change Management Audit/Assurance Program
-

An agreed-upon and standardized approach for managing changes in an efficient and
effective manner
- Formally defined expectations and performance measurement
- Consistent change procedure
–
Risk drivers:
- Insufficient allocation of resources
- Changes not recorded and tracked
- Undetected unauthorized changes to the production environment
AI6.5 Change closure and documentation
–
Control objective—Whenever changes are implemented, update the associated system and user
documentation and procedures accordingly.
–
Value drivers:
- An agreed-upon and standardized approach for documenting changes
- Formally defined expectations
- Consistent change and documentation procedures
–
Risk drivers:
- Increased dependence on key individuals
- Configuration documentation failing to reflect the current system configuration
- Lack of documentation of business processes
- Failure of updates for hardware and software changes
V. Executive Summary of Audit/Assurance Focus
Change Management Introduction
Change management is the process that ensures that system software (operating systems and supporting
applications), application software and configuration files are introduced into production in an orderly and
controlled manner.
Change management relies upon several other processes, including those for:
 Systems development methodology (SDM)—The SDM manages applications development and
applications programming to ensure appropriate design, testing, programming oversight and user
acceptance. It is also used to manage systems software management and configuration. The specific
applications and systems software processes may differ, but they should subscribe to similar controls.
 Systems request process—This process is normally a part of the SDM, and is the formal request for
change services.
 Incident management—This process addresses problem tickets initiated by computer operations
(processing errors or program failures), help desk (user-identified processing problems) or other
stakeholders. Incidents or problem tickets should be considered unusual occurrences requiring
monitoring and follow-up.
 Information security issues—These issues are generated by information security, operations, help
desk or end users.
 Software library controls—The software libraries are the repositories of the applications programs
(source code), configuration files, executable programs (computer executable code), report generators,
etc. Access to these repositories must be restricted to authorized individuals and must be monitored
for unauthorized access.
 Software distribution controls—In a distributed infrastructure, software executable programs must be
distributed to the down-line computer systems.
The definitive control over change management is the promotion to production or move to production
process. Once a program has been tested and approved for migration or promotion to the production
© 2009 ISACA. All rights reserved. Page 11
Change Management Audit/Assurance Program
environment, the program is subject to final approvals and moved to protected production source and
executable libraries. The documentation of the change is the change control document, often referred to as
a “move to production ticket” or “promotion to production ticket.” This documentation is the final
approval for the entry into production.
Business Impact and Risk
Systems and application software process enterprise data. The enterprise relies on the integrity of these
subsystems to operate their applications and to be in alignment with the business’s goals, objectives and
instructions. Good-practice change management provides business management with the assurance that
only authorized and tested changes to business processes and the supporting infrastructure are
implemented.
Change management is an essential component of the IT operational infrastructure. Failure to implement
good-practice change management may result in:
 Unauthorized business process changes being introduced into the operations
 Financial statements being materially misstated
 Unintended side effects
 Inconsistent processing results
 Changes not being recorded and tracked
 Emergency changes being implemented without adequate oversight, resulting in the introduction of
erroneous processes, unauthorized business processes and inefficiencies
 Lack of priority management of changes
 Inability to respond effectively to emergency change needs
 Additional access authorization not being terminated properly
 Unauthorized changes being applied, resulting in compromised security and unauthorized access to
corporate information
 Failure to comply with compliance requirements
 Changes not being adequately prioritized or aggregated, resulting in lost productivity, late
implementation of required changes, or redundancy
 Adverse effects on capacity and performance of the infrastructure
 System or application failure, resulting in lack of availability
 Reduced system availability
 Security intrusions
 Insufficient allocation of resources
Objective and Scope
Objective—Perform a review of the change management process to provide management with assurance
that the process is controlled, monitored and is compliance with good practices.
Scope—The review will focus on the program change management processes. It will rely on the system’s
development methodology to provide a design, development and testing methodology, and the system’s
request and incident management processes to provide input to the change management system. All
processes affecting these functions prior to the system’s request or incident/problem ticket entering the
change management process are outside the scope of this review.
Minimum Audit Skills
The IT audit and assurance professional must have an understanding of the good-practice change
management processes. Professionals holding CISA certification should have these skills. Technical skills
© 2009 ISACA. All rights reserved. Page 12
Change Management Audit/Assurance Program
necessary to perform some audit steps may require specific understanding of operating systems
environments in use, the library management systems and computer-assisted audit techniques (CAATs).
© 2009 ISACA. All rights reserved. Page 13
Change Management Audit/Assurance Program
VI. Audit/Assurance Program
1. PLANNING AND SCOPING THE AUDIT
1.1 Define audit/assurance objectives.
The audit/assurance objectives are high level and describe the overall audit goals.
ME2.1
1.1.1 Review the audit/assurance objectives in the introduction to this audit/assurance
program.
1.1.2 Modify the audit/assurance objectives to align with the audit/assurance universe,
annual plan and charter.
1.2 Define boundaries of review.
The review must have a defined scope. The reviewer must understand the operating
environment and prepare a proposed scope, subject to a later risk assessment.
1.2.1 Perform a high-level walkthrough of the change management functions within the
enterprise.
1.2.1.1 Determine what change management functions operate within the
enterprise.
1.2.1.2 Determine the applications and/or operating environments serviced by the
identified change management systems.
1.2.2 Establish initial boundaries of the audit/assurance review.
1.2.2.1 Where multiple change management systems exist, identify proposed
change management systems to be within scope.
1.2.2.2 Identify limitations and/or constraints affecting the audit of specific
systems.
1.2.2.3 Determine if integrity systems exist to provide assurance that changes
made to the systems are reconciled to authorized change tickets from the
change management systems.
© 2009 ISACA. All rights reserved. Page 14
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
1.3 Define assurance.
The review requires two sources of standards. The corporate standards, as defined in policy and
procedure documentation, establish the corporate expectations. At minimum, corporate
standards should be implemented. The second source, a good-practice reference, establishes
industry standards. Enhancements should be proposed to address gaps between the two.
1.3.1 Obtain company change management standards, if they exist.
1.3.2 Determine if COBIT or the IT Infrastructure Library (ITIL) or both will be used as a
good-practice reference.
1.4 Identify and document risks.
The risk assessment is necessary to evaluate where audit resources should be focused. In most
enterprises, audit resources are not available for all processes. The risk-based approach ensures
utilization of audit resources in the most effective manner.
1.4.1 For the applications and systems identified as potentially being in scope:
1.4.1.1 Identify the change control risks associated with the applications and
operating environment.
1.4.1.2 Assess the business risk of each operating environment, based on the
applications serviced.
1.4.2 Based on the risk assessment, identify changes to the scope.
1.4.3 Discuss the risks with IT, the business and operational audit management, and
adjust the risk assessment.
1.4.4 Based on the risk assessment, revise the scope.
1.5 Define the change process.
The initial audit approach is based on the reviewer’s understanding of the operating
environment and associated risks. As further research and analysis are performed, changes to
the scope and approach will result.
1.5.1 Identify the senior IT assurance resource responsible for the review.
© 2009 ISACA. All rights reserved. Page 15
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Control Activities
Information and
Communication
Monitoring
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
X
X
X
1.5.2 Establish the process for suggesting and implementing changes to the
audit/assurance program, and note the authorizations required.
1.6 Define assignment success.
The success factors need to be identified. Communication among the IT audit/assurance team,
other assurance teams and the enterprise is essential.
1.6.1 Identify the drivers for a successful review (this should exist in the assurance
function’s standards and procedures).
1.6.2 Communicate success attributes to the process owner or stakeholder, and obtain
agreement.
1.7 Define audit/assurance resources required.
The resources required are defined in the introduction to this audit/assurance program.
1.7.1 Determine audit/assurance skills necessary for review.
1.7.2 Estimate the total resources (hours) and time frame (start and end dates) required for
review.
1.8 Define deliverables.
The deliverable is not limited to the final report. Communication between the audit/assurance
teams and the process owner is essential to assignment success.
1.8.1 Determine the interim deliverables, including initial findings, status reports, draft
reports, due dates for responses and the final report.
1.9 Communications
The audit/assurance process is clearly communicated to the customer/client.
1.9.1 Conduct an opening conference to discuss the review objectives with the executive
responsible for operating systems and infrastructure.
2. UNDERSTANDING SUPPORTING INFRASTRUCTURE
2.1 Incident management system
The incident management system (often referred to as the problem tracking system) feeds the
change management system with requests resulting from system interruptions or user-
DS10.4
© 2009 ISACA. All rights reserved. Page 16
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
discovered issues.
2.1.1 If an audit of the incident management system has been performed previously,
obtain the work papers from that audit.
2.1.1.1 Review the previous findings and gain an understanding of the incident
management system and control issues that may affect the change
management process.
2.1.2 If a prior audit has not been performed or the environment has changed
significantly, obtain an understanding of the feeds from the incident management
system.
2.1.2.1 Determine if the feed is automated, directly interfacing with the change
management system.
2.1.2.2 Based on the review, determine if further investigation is required or if the
scope of change management will assume validity of the incident/problem
ticket.
2.2 Program library management
The program library management process controls access to and documentation of the program
source code and configuration files.
AI3.2
AI7.8
DS5.7
X
X
AI3.2
AI7.8
DS5.7
X
X
2.2.1 If prior assurance work has included a review of the program library management
system, obtain and review the work papers and follow up on the findings.
2.2.2 If no prior assurance work has been performed, obtain documentation and
descriptions of the various program library management systems in use within the
scope of the application/system software included in the audit.
2.3 Executable library security
The executable libraries include the compiled versions of the programs. This code is used by
the computer to process the data. The executable library will have similar controls as the
program library; however, it will have the added requirement that the program and executable
libraries must be synchronized (the program stored in the program library must, when
compiled, generate the same executable as the program stored in the executable library).
© 2009 ISACA. All rights reserved. Page 17
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Issue
HyperCrosslink
reference
2.3.1 Obtain the documentation describing how executable programs are stored on the
systems within the scope (operating systems store the programs differently).
2.3.2 If an outside vendor provides patches or executable programs to the enterprise
without providing the source, determine the distribution process for these programs.
2.4 Distributed executable distribution system
Similar to the executable library, in a distributed operating environment, the programs are
compiled centrally, but the executables are distributed to the various processing locations.
1.
AI3.2
AI7.8
DS5.7
X
2.
2.4.1 Obtain the documentation describing how distributed systems receive the executable
programs from the central programming location.
2.5 Systems development methodology
This methodology addresses the planning, design, development and testing of new and updated
software. Since systems requests resulting from the systems development methodology are
within scope, it is necessary to obtain an understanding of the request process.
3.
PO8.3
2.5.1 Obtain the documentation for the systems development process, including systems
requests, evaluation of the project, risk assessment, resource allocation, testing and
program quality assurance.
2.5.2 Obtain the documentation for change management relating to configuration
management, including change requests, evaluation of the effect of the change on
production systems, risk assessment, resource allocation, testing and system quality
assurance.
3. IDENTIFY CHANGE NEED
Audit/assurance objective: Only changes that are authorized, evaluated and prioritized and the
resources required should enter the change process.
3.1 Control: Management classifies, reviews and approves change requests. This control
ensures that management has considered and approved the changes in the queue.
3.1.1 Obtain the enterprise’s standards, procedures and guidelines for identifying,
classifying and approving change requests.
© 2009 ISACA. All rights reserved. Page 18
X
X
X
X
X
4.
5.
6.
Comments
Change Management Audit/Assurance Program
3.1.1.1 Information should be obtained by interviews, observation and reviewing
documentation.
3.1.1.1.1 Determine if a process exists to classify change requests as an
infrastructure or application change.
3.1.1.1.2 Determine if a process exists to perform a risk assessment focused
on the impact of the change on other systems or applications.
3.1.1.1.3 Determine if there is a process to perform an impact analysis on
changes to determine the effect the change would have on the
business process’s integrity and availability.
3.1.1.1.4 Determine if there is a process for performing an analysis of any
compliance issues that would be affected by the change request.
3.1.1.1.5 Determine if a resource budget is assigned to each change request.
3.1.1.1.6 Determine if a list exists of appropriate change requesters for each
application.
3.1.1.1.7 Verify that the appropriate approvers within IT operations, IT
systems development and the business owner have approved the
change and their approval is documented.
3.1.1.1.8 Determine if the change requests are subject to prioritization.
3.1.1.1.8.1 If prioritization is performed, determine if appropriate
members of management regularly authorize the
priority.
3.1.2 Test objective: To verify compliance with the review and prioritization process
3.1.2.1 Using the move ticket, obtain a population of requested changes.
3.1.2.1.1 When making the selection, select representative samples resulting
from emergency requests, systems requests and problem tickets.
© 2009 ISACA. All rights reserved. Page 19
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Issue
HyperCrosslink
reference
7.
Comments
Change Management Audit/Assurance Program
3.1.2.1.2 Stratify the selection of tickets to include a greater sample of
higher-risk application/software changes, but also include a lesser
number of medium- and low-risk changes.
3.1.2.1.3 For each selected ticket:
3.1.2.1.3.1 Trace the move request to the originating request
(systems request, problem ticket or emergency request
[if different]).
3.1.2.1.3.2 Determine if each ticket was classified as an
infrastructure or application change.
3.1.2.1.3.3 Determine if there was a risk assessment performed for
impact on other systems or applications.
3.1.2.1.3.4 Determine if an impact analysis was performed to
determine the effect the change would have on the
enterprise.
3.1.2.1.3.5 Determine if there was an analysis of any compliance
issues that would be affected by the change request.
3.1.2.1.3.6 Determine if a resource budget had been assigned to
the change request.
3.1.2.1.3.7 Determine if the appropriate approvers within IT
operations, IT systems development and the business
owner documented their approval of the change.
3.1.2.1.3.8 Determine if the change request had been subject to
prioritization.
3.1.2.1.3.8.1 If prioritization had been granted,
determine if appropriate management had
authorized the priority.
© 2009 ISACA. All rights reserved. Page 20
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
4. PRODUCTION LIBRARY MANAGEMENT
Audit/assurance objective: Production libraries should be secure, allowing only authorized
personnel to access the production libraries. Management must provide oversight of access to
libraries, good-practice separation of duties, and synchronization of source and executable libraries.
4.1 Production source library controls
The production source libraries contain the source language and configuration for the
production programs. Access needs to be limited and monitoring processes need to be in place
to effectively oversee change activities affecting the source libraries.
4.2 Control: Access to production source is limited on a need-to-know basis.
Programmers are limited to READ access; only change management staff members are
assigned WRITE access (except for emergency changes, described in Step 6).
AI3.2
AI7.8
DS5.7
4.2.1 Through interviews, observation and review of documentation, determine the
controls limiting access to the production source libraries.
4.2.1.1 Determine if there is a separation-of-duties table identifying the access
levels and to whom they are assigned.
4.2.1.2 Verify that ID access logs, including date and time stamps, are maintained
and reviewed on a regular basis.
4.2.1.3 Determine if access control lists are reviewed and updated regularly.
4.2.1.4 Test objective: To verify that access to the production source libraries
is provided on a need-to-know basis
4.2.1.4.1 Obtain the access control list for production source library.
4.2.1.4.2 Review the list and identify any personnel not in the change
management with WRITE access to the library.
4.2.1.4.3 Obtain the access log and identify unauthorized or suspect access
to production library.
4.2.1.4.4 Verify documented management review of the access control list
and unusual activity logs. Ensure periodic review.
© 2009 ISACA. All rights reserved. Page 21
X
X
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
4.3 Control: Production source libraries maintain version control, which provides a
history of all modifications and the ability to roll back the source to a previous version if
the new version is not functioning properly.
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
AI3.2
AI7.8
DS5.7
X
X
AI3.2
AI7.8
DS5.7
X
X
4.3.1 Through interviews, observation and review of documentation, determine how
version control operates and if it can be overridden.
4.3.2 Through interviews, observation and review of documentation, determine if the
functionality exists to roll back an update program to its previous version.
4.4 Production executable library controls
The production executable libraries contain the computer code to process the programs. Access
needs to be limited and monitoring processes need to be in place to effectively oversee change
activities affecting the executable libraries.
4.5 Control: Access to production executable libraries is limited to a need-to-know basis.
Programmers are limited to READ access; only change management staff members are
assigned WRITE access (except for emergency changes described in Step 6).
4.5.1 Through interviews, observation and review of documentation, determine the
controls limiting access to the production executable libraries.
4.5.1.1 Determine if there is a separation-of-duties table identifying the access
levels and to whom they are assigned.
4.5.1.2 Determine if ID access logs, including date and time stamps, are
maintained and reviewed on a regular basis.
4.5.1.3 Determine if access control lists are reviewed and updated regularly.
4.5.1.4 Test objective: To verify that access to the production executable
libraries is provided on a need-to-know basis
4.5.1.4.1 Based on risk, select the production executable libraries to be tested.
4.5.1.4.2 Obtain the access control list for production executable libraries.
4.5.1.4.2.1 Review the list and identify any personnel not in the
change management with WRITE access to the libraries.
© 2009 ISACA. All rights reserved. Page 22
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
4.5.1.4.2.2 Obtain the access log and identify unauthorized or
suspect access to production libraries.
4.5.1.4.2.3 Verify documented management review of the access
control list and unusual activity logs.
4.6 Control: Production executable libraries maintain version control, which provides a
history of all modifications and the ability to roll back the executable to a previous
version if the new version is not functioning properly.
AI7.5
DS9.1
X
X
AI7.8
X
X
4.6.1 Through interviews, observation and review of documentation, determine how
version control operates and if version control can be overridden.
4.6.2 Through interviews, observation and review of documentation, determine if the
functionality exists to roll back an update program to its previous version.
4.7 Control: Changes to the production executable libraries of distributed systems utilize
a scheduled transmission and acknowledgment process to ensure accurate, complete and
timely transmission of changes.
4.7.1 Through interviews, observation and review of documentation, determine what
control techniques are utilized to ensure complete and accurate transmission of
program changes.
4.7.2 Test objective: To verify the accuracy of distribution of executables to remote
processors
4.7.2.1 Select a sample of executables.
4.7.2.2 Determine the size, date and time of the executables to be distributed as
they reside in the master executable library.
4.7.2.3 For the selected executable, determine the date and time transmitted and
the size of the file at the distributed computer.
4.7.2.4 Evaluate the timeliness and completeness of the distribution.
© 2009 ISACA. All rights reserved. Page 23
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Control Activities
Information and
Communication
Monitoring
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
X
X
X
5. MOVE TO PRODUCTION
Audit/assurance objective: The move to the production process should be controlled and
documented. Access should be limited to authorized change management personnel. Only
authorized changes should have been made to production programs, and the move process should
ensure synchronization of the source and executable libraries.
5.1 Control: Program changes require sign-off by the appropriate stakeholders prior to
being moved into production.
AI6.2
AI6.5
5.1.1 Determine if the sign-off process, prior to a change moving into production,
includes the following:
5.1.1.1 The programming function indicates completion of testing, quality
assurance and documentation.
5.1.1.2 Users indicate satisfactory acceptance test, approval and knowledge of
implementation date.
5.1.1.3 IT operations indicates acceptance of documentation, scheduling changes,
backup changes, run-time changes, etc.
5.1.1.4 Information security indicates acceptance of information security changes.
5.1.1.5 Documentation (user, IT operations, backup/recovery business continuity
plan) is approved.
5.1.1.6 Test objective: To verify the sign-off process to ensure that all signoffs were completed before the move to production and the
appropriate personnel approved the move
5.1.1.6.1 Obtain a sample of routine move-to-production tickets for
applications and software changes in scope.
5.1.1.6.2 For each move ticket, verify timely approvals by:
5.1.1.6.2.1 The programming function indicates completion of
testing, quality assurance and documentation.
© 2009 ISACA. All rights reserved. Page 24
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
5.1.1.6.2.2 Users indicate satisfactory acceptance test, approval
and knowledge of implementation date.
5.1.1.6.2.3 IT operations indicates acceptance of documentation,
scheduling changes, backup changes, run-time changes,
etc.
5.1.1.6.2.4 Information security indicates acceptance of
information security changes.
5.1.1.6.2.5 Documentation indicates satisfactory reviews by users,
IT operations, backup/recovery business continuity
plan.
5.2 Control: Change management software is used to control the change process.
AI6.1
5.2.1 Through interviews, observation and review of documentation, determine the
automated change management process.
5.2.1.1 Walk through the process of entering a move ticket, approving the ticket,
compiling the program and moving it into production.
5.2.1.2 Determine the controls to identify and authenticate the approver’s authority
to move a program into production.
5.2.1.3 Determine the available logs and reports generated by the change
management system to trace and research program moves into production.
5.2.1.4 Determine if there are “back doors” that allow bypassing of the change
management software system.
5.2.1.5 Determine if logs and reports generated by the change management system
are reviewed by management and if such reviews are formally
documented.
5.2.2 Test objective: To verify that the change management software and user
controls are effective
© 2009 ISACA. All rights reserved. Page 25
X
X
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
5.2.2.1 Based on the reviewer’s understanding of the automated move process,
identify control points to test (consider automated authorization,
monitoring, logging capabilities, independent recompilation of programs,
etc.).
5.2.2.2 Select several change tickets.
5.2.2.3 Focusing on the control points identified in step 5.2.2.1, follow the selected
change tickets through the process, verifying compliance with identified
controls.
5.3 Control: Manual controls throughout the program move process prevent
unauthorized moves to production.
AI3.2
AI7.8
DS5.7
5.3.1 Document the process of moving the program from the test to the production
environment.
5.3.2 Document the process of independently recompiling the programs by someone other
than the programmer, and placing the programs in a production library.
5.3.3 Where there is a lack of separation of duties, document alternative controls
(program source and executable compares, log date and time verification, etc.) used
to ensure the integrity of the program move-to-production process.
5.3.4 Test objective: To verify the effectiveness of the manual change management
process
5.3.4.1 Identify key control points in the program change process (notification of
program ready for move to production, transfer of program from test to
production library, compilation of source, comparison of compilation and
executable dates, etc.).
5.3.4.2 Select a statistically valid sample size (at least 25 randomly selected moves
to production).
5.3.4.3 Trace the move to production against good practices and enterprise
standards. Focus on the documented evidence of management review.
© 2009 ISACA. All rights reserved. Page 26
X
X
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
5.4 Control: Management reviews program changes to ensure that only authorized
changes from the move ticket, systems request or incident log are included in the
modification.
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
AI6.1
AI6.5
X
X
AI6.5
DS9.2
X
X
5.4.1 Determine whether a comparison of source code before and after the modification is
included in the documentation.
5.4.2 Determine how management reviews the changes to ensure that only authorized
changes have been implemented.
5.4.3 Test objective: To verify the process of comparing authorized changes to
completed changes.
5.4.3.1 Select a sample (including emergency requests) from a population of move
tickets.
5.4.3.2 Obtain the change request supporting the move ticket.
5.4.3.3 Based on the change request, obtain an understanding of the changes
required.
5.4.3.4 Run a source code comparison of the previous and current programs to
identify the code changes.
5.4.3.5 Perform a “reasonableness” test, ensuring that the changes requested in the
systems request are the same changes implemented.
5.5 Control: The production source and executable libraries are synchronized, all
executable library entries are supported by a move ticket, and appropriate logging is
available to monitor and provide the ability to trace moves initiated by a move ticket to a
library update.
5.5.1 Determine how the compile process generates the date and time stamp of
compilation.
5.5.2 Determine that the executable library documents the date and time of update.
5.5.3 Determine the process that ensures that all executables in the library have move
tickets.
© 2009 ISACA. All rights reserved. Page 27
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Control Activities
Information and
Communication
Monitoring
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
X
X
X
5.5.4 Test objective: To verify that the production source and executable libraries
are synchronized
5.5.4.1 Select a sample (including emergency requests) from a population of move
tickets.
5.5.4.2 Verify that the source compilation date and time agrees with the date and
time of the executable.
5.5.4.3 Select a few programs from the move log and recompile the programs
using the production compilation process, but saving the executable to a
storage area controlled by the reviewer. Compare the executable generated
by the reviewer to the executable stored in the production executable
library, and identify differences.
5.5.5 Test objective: To verify that all executables have move-to-production tickets
5.5.5.1 Select several executable programs/modules from the production
executable library. Trace the executable to a move ticket.
6. EMERGENCY CHANGES
Audit/assurance objective: Emergency changes should be controlled, documented and initiated
only in true emergencies.
6.1 Control: Changes using the emergency change procedure are initiated only for
changes where time is of the essence.
AI6.3
6.1.1 Through interviews, observation and review of documentation, determine if there is
a definition for an emergency change.
6.1.2 Test objective: To verify that only necessary changes are made using the
emergency change procedure
6.1.2.1 Select a representative sample of emergency changes.
6.1.2.2 Using the definition of an emergency change, review the emergency
changes to determine if the changes were, in fact, emergencies.
© 2009 ISACA. All rights reserved. Page 28
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
6.2 Control: Emergency changes are adequately tested before being placed into
production.
X
X
AI6.3
X
X
AI6.3
X
Monitoring
Information and
Communication
AI6.3
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
Control Activities
COSO
6.2.1 Through interviews, observation and review of documentation, determine the
process used to review testing procedures before an emergency change is accepted
into production.
6.2.2 Determine if a list of authorized requesters for emergency changes exists.
6.2.3 Test objective: To verify that emergency change authorization was approved
prior to the introduction of the change into the production environment
6.2.3.1 Select emergency changes from several sources.
6.2.3.1.1 Review the existence of test results and management review.
6.3 Control: Emergency changes are authorized by an appropriate member of
management before being placed into production.
X
6.3.1 Through interviews, observation and review of documentation, determine the
process used to authorize emergency moves to production. Differentiate between
minor and major enhancements, operating system, configuration files and source
programs.
6.3.2 Test objective: To verify that change authorizations were documented prior to
the introduction of the change into the production environment
6.3.2.1 Select a representative sample of emergency changes.
6.3.2.2 Determine if the move into production was properly authorized.
6.4 Control: Special processes are in place to allow one-time execution of emergency
changes while keeping the integrity of the production libraries.
6.4.1 Determine if the emergency changes are executed from a temporary or test library,
or copied into the protected production library.
© 2009 ISACA. All rights reserved. Page 29
X
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
6.4.1.1 If programs are copied into the production libraries, identify the controls to
protect the libraries from unauthorized updates by the analyst/programmer
initiating the changes.
6.4.1.1.1 Determine if one-time passwords are utilized to protect libraries.
6.4.1.1.1.1 If one-time passwords are utilized, evaluate the
effectiveness of the one-time password controls to
ensure that the passwords are not reused and the
individual utilizing the password can be identified
easily.
6.4.1.1.2 If the controls to protect the production libraries do not include
one-time passwords, document and evaluate the effectiveness of
the other controls.
6.4.2 Test objective: To verify the effectiveness of the change control process that
ensures the integrity of the production libraries and application data.
6.4.2.1 Select a sample of emergency moves to production.
6.4.2.1.1 Determine if the program was run from an interim library or the
production library.
6.4.2.1.2 If the production library was used, determine if a one-time
password was retrieved.
6.4.2.1.3 Determine if the one-time password was disabled.
6.5 Control: Emergency changes are subject to the same quality assurance as normal
changes.
AI6.3
6.5.1 Through interviews, observation and review of documentation, determine the
process for reviewing emergency changes.
6.5.1.1 Determine what controls are in place to ensure that the data processed used
the updated program.
© 2009 ISACA. All rights reserved. Page 30
X
X
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
6.5.1.1.1 For high-risk applications, it may be necessary to perform a
comparison of the data to ensure that essential fields have not been
changed.
6.5.2 Through interviews, observation and review of documentation, determine after-thefact quality assurance procedures, recompilation procedures, etc., to align the
emergency change with standard move-to-production procedures.
6.5.2.1 Test objective: To verify the effectiveness of the change management
quality assurance process and appropriate authorization
6.5.2.1.1 Select a sample of emergency moves to production.
6.5.2.1.2 Review the sign-off process to ensure that all signoffs were
completed within a reasonable period after the move to production
and that the appropriate personnel approved the move.
6.5.2.1.2.1 The programming function indicates completion of
testing, quality assurance and documentation.
6.5.2.1.2.2 Users indicate satisfactory user acceptance test,
approval and knowledge of implementation date.
6.5.2.1.2.3 IT operations indicates acceptance of documentation,
scheduling changes, backup changes, run-time changes,
etc.
6.5.2.1.2.4 Information security indicates acceptance of
information security changes.
6.5.2.1.2.5 Documentation indicates satisfactory reviews by users,
IT operations, backup/recovery business continuity
plan.
6.5.2.1.3 Review the move to production and compile logs to determine if
the emergency program move was subject to recompilation and
was copied into the appropriate libraries.
© 2009 ISACA. All rights reserved. Page 31
Monitoring
Information and
Communication
Control Activities
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
Control Activities
Information and
Communication
Monitoring
COBIT
Crossreference
Audit/Assurance Program Step
Control
Environment
Risk Assessment
COSO
X
X
X
X
X
X
7. CHANGE MANAGEMENT GOVERNANCE
Control objective: The change management process is subject to management oversight to ensure
the consistent and timely processing of changes.
7.1 Control: Management receives timely reports, summarizing change management
activities, key performance indicators and escalation of issues requiring management
attention.
AI6.4
X
AI6.4
ME1
X
7.1.1 Identify the reports that management receives, and the frequency and scope of the
reports.
7.1.2 Determine if service level agreements (SLAs) are in use. If so, verify that the reports
summarize SLA attainment and/or deficiency.
7.1.3 Determine the escalation process for change management processes operating
outside of normal conditions.
7.1.4 Test objective: To verify the effectiveness of management’s monitoring and
resolution of change management issues
7.1.4.1 Select several periods.
7.1.4.2 Review management reports, minutes of management meetings and
resolution plans to document management’s oversight of change
management activities.
7.1.4.3 Verify compliance with escalation procedures and the attainment of SLAs.
7.1.4.4 Determine the circumstances and resolution of escalated situations.
7.2 Control: A management steering committee is responsible for and reviews change
management issues.
7.2.1 Determine the management committee responsible for change management.
7.2.2 Determine if change management stakeholders are members of the steering committee.
7.2.3 Determine if the scope of the committee includes review of staffing levels,
performance indicators, etc., to ensure a stable operational team.
© 2009 ISACA. All rights reserved. Page 32
X
Reference
Issue
HyperCrosslink
reference
Comments
Change Management Audit/Assurance Program
VII. Maturity Assessment
The maturity assessment is an opportunity for the reviewer to assess the maturity of the processes reviewed. Based on the results of audit/assurance review, and the
reviewer’s observations, assign a maturity level to each of the following COBIT control practices.
Assessed
Target
Maturity Maturity
COBIT Control Practice
AI6.1 Change Standards and Procedures
1. Develop, document and promulgate a change management framework that specifies the policies and
processes, including:
• Roles and responsibilities
• Classification and prioritization of all changes based on business risk
• Assessment of impact
• Authorization and approval of all changes by the business process owners and IT
• Tracking and status of changes
• Impact on data integrity (e.g., all changes to data files being made under system and application control
rather than by direct user intervention)
2. Establish and maintain version control over all changes.
3. Implement roles and responsibilities that involve business process owners and appropriate technical IT
functions. Ensure appropriate segregation of duties.
4. Establish appropriate record management practices and audit trails to record key steps in the change
management process. Ensure timely closure of changes. Elevate and report to management changes that
are not closed in a timely fashion.
5. Consider the impact of contracted services providers (e.g., of infrastructure, application development
and shared services) on the change management process. Consider integration of organizational change
management processes with change management processes of service providers. Consider the impact of
the organizational change management process on contractual terms and SLAs.
AI6.2 Impact Assessment, Prioritization and Authorization
1. Develop a process to allow business process owners and IT to request changes to infrastructure, systems
or applications. Develop controls to ensure that all such changes arise only through the change request
management process.
2. Categorize all requested changes (e.g., infrastructure, operating systems, networks, application systems,
purchased/packaged application software).
3. Prioritize all requested changes. Ensure that the change management process identifies both the business
and technical needs for the change. Consider legal, regulatory and contractual reasons for the requested
change.
4. Assess all requests in a structured fashion. Ensure that the assessment process addresses impact analysis
on infrastructure, systems and applications. Consider security, legal, contractual and compliance
© 2009 ISACA. All rights reserved. Page 33
Reference
Hyperlink
Comments
Change Management Audit/Assurance Program
Assessed
Target
Maturity Maturity
COBIT Control Practice
implications of the requested change. Consider also interdependencies among changes. Involve business
process owners in the assessment process, as appropriate.
5. Ensure that each change is formally approved by business process owners and IT technical stakeholders,
as appropriate.
AI6.3 Emergency Changes
1. Ensure that a documented process exists within the overall change management process to declare,
assess, authorize and record an emergency change.
2. Ensure that emergency changes are processed in accordance with the emergency change element of the
formal change management process.
3. Ensure that all emergency access arrangements for changes are appropriately authorized, documented
and revoked after the change has been applied.
4. Conduct a post-implementation review of all emergency changes, involving all concerned parties. The
review should consider implications for aspects such as further application system maintenance, impact
on development and test environments, application software development quality, documentation and
manuals, and data integrity.
AI6.4 Change Status Tracking and Reporting
1. Establish a process to allow requestors and stakeholders to track the status of requests throughout the
various stages of the change management process.
2. Categorize change requests in the tracking process (e.g., rejected, approved but not yet initiated,
approved and in process, and closed).
3. Implement change status reports with performance metrics to enable management review and monitoring
of both the detailed status of changes and the overall state (e.g., aged analysis of change requests).
Ensure that status reports form an audit trail so changes can subsequently be tracked from inception to
eventual disposition.
4. Monitor open changes to ensure that all approved changes are closed in a timely fashion, depending on
priority.
AI6.5 Change Closure and Documentation
1. Ensure that documentation—including operational procedures, configuration information, application
documentation, help screens and training materials—follows the same change management procedure
and is considered to be an integral part of the change.
2. Consider an appropriate retention period for change documentation and pre- and post-change system and
user documentation.
3. Update business processes for changes in hardware or software to ensure that new or improved
functionality is used.
4. Subject documentation to the same level of testing as the actual change.
© 2009 ISACA. All rights reserved. Page 34
Reference
Hyperlink
Comments
Change Management Audit/Assurance Program
VIII. Assessment Maturity vs. Target Maturity
A I6 .1 C hang e St and ar d s and Pr o ced ur es
5
4
3
2
A I6 .2 Imp act A ssessment , Pr io r it iz at io n
and A ut ho r iz at io n
A I6 .5 C hang e C lo sur e and D o cument at io n
1
0
Assessment
A I6 .4 C hang e St at us T r acking and R ep o r t ing
A I6 .3 Emer g ency C hang es
© 2009 ISACA. All rights reserved. Page 35
Target