IS Audit/Assurance Program

Change Management

IS Audit/Assurance Program
Change Management
Column Name Description
Process Sub-area An activity within an overall process influenced by the enterprise's
policies and procedures that takes inputs from a number of sources,
manipulates the inputs and produces outputs

Ref. Risk Specifies the risk this control is intended to addressed

Control Objectives A statement of the desired result or purpose that must be in place to
address the inherent risk in the review areas within scope

Controls The means of managing risk, including policies, procedures, guidelines,

practices or organizational structures, which can be of an administrative,
technical, management or legal nature

(c) ISACA 2016 All Rights Reserved 1

 IS Audit/Assurance Program
Change Management

Control Type Controls can be automated (technical), manual (administrative) or

physical.

Automated/technical controls are things managed or performed by

computer systems.
Manual/administrative controls are usually things that employees can or
cannot do.
Physical controls include locks, fences, mantraps and even geographic
specific controls.

Control Classification Another way to classify controls is by the way they address a risk
exposure.

Preventive controls should stop an event from happening.

Detective controls should identify an event when it is happening and
generate an alert that prompts a corrective control to act.
Corrective controls should limit the impact of an event and help resume
normal operations within a reasonable time frame.
Compensating controls are alternate controls designed to accomplish the
intent of the original controls as closely as possible when the originally
designed controls cannot be used due to limitations of the environment.

Control Frequency Control activities can occur in real-time, daily, weekly, monthly, annually,
etc.

Testing Step Identifies the steps being tested to evaluate the effectiveness of the
control under review

(c) ISACA 2016 All Rights Reserved 2

 IS Audit/Assurance Program
Change Management

Ref. COBIT 5 Identifies the COBIT 5 process related to the control objective or control
activities

Ref. Specifies frameworks and/or standards that relate to the control under
Framework/Standards review (e.g., NIST, HIPAA, SOX, ISO)

Ref. Workpaper The evidence column usually contains a reference to other documents
that contain the evidence supporting the pass/fail mark for the audit step.

Pass/Fail Document preliminary conclusions regarding the effectiveness of controls.

Comments Free format field

(c) ISACA 2016 All Rights Reserved 3

 IS Audit/Assurance Program
Change Management

Program
ment
Instructions
To make the audit program manageable, it is recommended to break out
the scope of the audit into sub-areas. The auditor can modify this field to
entity-specific names and terms. ISACA has used the most commonly used
terms as the basis to develop this audit program.

This field can be used to input a reference/link to risk described in the

entity's risk register or enterprise risk management (ERM) system, or to
input a description of the risk a particular control is intended to address.

This field should describe the behaviors, technologies, documents or

processes expected to be in place to address the inherent risk that is part
of the audit scope.

An IS audit manager can review this information to determine whether

the review will meet the audit objectives based on the risk and control
objectives included in the audit program.

This field should describe in detail the control activities expected to be in

place to meet the control objective. Control activities can be in roles and
responsibilities, documentation, forms, reports, system configuration,
segregation of duties, approval matrices, etc.

An IS audit manager performing a quality control review must decide

whether an auditor has planned to identify enough controls on which to
base an assessment and whether the planned evidence is sufficiently
objective.

(c) ISACA 2016 All Rights Reserved 4

 IS Audit/Assurance Program
Change Management

Specify whether the control under review is automated, manual, physical

or a combination. This information is useful in determining the testing
steps necessary to obtain assessment evidence.

Specify whether the control under review is preventive, detective,

corrective or compensating. This information will be helpful when defining
testing steps and requesting evidence.

Specify whether the control under review occurs in real-time, daily,

weekly, monthly, annually, etc. This information will be helpful when
defining testing steps and requesting evidence.

This field should describe in detail the steps necessary to test control
activities and collect supporting documentation. The auditor can modify
this field to meet entity-specific needs. ISACA has used a set of generic
steps develop this audit program.

An IS audit manager may determine if the proposed steps are adequate to

review a particular control.

(c) ISACA 2016 All Rights Reserved 5

 IS Audit/Assurance Program
Change Management

Input the COBIT 5 process or practice that relates to this control.

Input references to other frameworks used by the entity as part of their

compliance program.

Specify the location of supporting documentation detailing the audit steps

and evidence obtained.

An IS audit manager performing a quality control review must decide

whether an auditor has tested enough controls on which to base an
assessment and whether the obtained evidence is sufficiently objective to
support a pass or fail conclusion.

Specify whether the overall control is effective (Pass) or not effective (Fail)
based on the results of the testing.

Document any notes related to the review of this Process Sub-area or

specific control activities.

(c) ISACA 2016 All Rights Reserved 6

 Audit/Assurance Program
Change Management

IS Audit/Assurance Program
Change Management
Ref. Control Control Control
Process Sub-area Risk Control Objectives Controls Type Class Frequency

Governance CO1. The change management process is subject C1. Management receives timely reports,
to management oversight to ensure the summarizing change management activities, key
consistent and timely processing of changes. performance indicators and escalation of issues
requiring management attention.

C2. A management steering committee is

responsible for and reviews change management
issues.

(c) ISACA 2016 All Rights Reserved Governance, Page 7

 Audit/Assurance Program
Change Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/ Workpaper Fail Comments
Standards
1. Identify the reports that management receives, and the frequency and scope of the reports. BAI06.03
2. Determine if service level agreements (SLAs) are in use. If so, verify that the reports summarize
SLA attainment and/or deficiency.
3. Determine the escalation process for change management processes operating outside of
normal conditions.
4. Test objective: To verify the effectiveness of management’s monitoring and resolution of change
management issues:
- Select several periods.
- Review management reports, minutes of management meetings and resolution plans to
document management’s oversight of change management activities.
- Verify compliance with escalation procedures and the attainment of SLAs.
- Determine the circumstances and resolution of escalated situations.

1. Determine the management committee responsible for change management BAI06.03;

2. Determine if change management stakeholders are members of the steering committee MEA01
3. Determine if the scope of the committee includes review of staffing levels, performance
indicators, etc., to ensure a stable operational team.

(c) ISACA 2016 All Rights Reserved Governance, Page 8

 Audit/Assurance Program
Change Management

IS Audit/Assurance Program
Change Management
Ref. Control Control Control
Process Sub-area Risk Control Objectives Controls Type Class Frequency

Identify Change Needs CO1. Only changes that are authorized, evaluated C1. Management classifies, reviews and approves
and prioritized and the have resources required change requests. This control ensures that
should enter the change process. management has considered and approved the
changes in the queue.

(c) ISACA 2016 All Rights Reserved Identify Changes, Page 9

 Audit/Assurance Program
Change Management

C2. Requested changes comply with the review

and prioritization process.

(c) ISACA 2016 All Rights Reserved Identify Changes, Page 10

 Audit/Assurance Program
Change Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/ Workpaper Fail Comments
Standards
1. Obtain the enterprise’s documented standards, processes, procedures and guidelines for BAI06.01
identifying, classifying and approving change requests.
2. Determine if a process exists to classify change requests as an infrastructure or application
change.
3. Determine if a process exists to perform a risk assessment focused on the impact of the change
on other systems or applications.
4. Determine if there is a process to perform impact analysis on changes to ensure business
process’s integrity and availability.
5. Determine if there is a process for performing an analysis of any compliance issues that would be
affected by the change request.
6. Determine if a resource budget is assigned to each change request.
7. Determine if a list exists of appropriate change requesters for each application.
8. Verify that the appropriate approvers within IT operations, IT systems development and the
business owner have approved the change and their approval is documented.
9. Determine if the change requests are subject to prioritization. If prioritization is performed,
determine if appropriate members of management review the priority assignation and
authorization regularly.

(c) ISACA 2016 All Rights Reserved Identify Changes, Page 11

 Audit/Assurance Program
Change Management

1. Obtain the enterprise’s documented standards, processes, procedures and guidelines for BAI06.01
identifying, classifying and approving change requests.
2. Determine if a process exists to classify change requests as an infrastructure or application
change.
3. Determine if a process exists to perform a risk assessment focused on the impact of the change
on other systems or applications.
4. Determine if there is a process to perform impact analysis on changes to ensure business
process’s integrity and availability.
5. Determine if there is a process for performing an analysis of any compliance issues that would be
affected by the change request.
6. Determine if a resource budget is assigned to each change request.
7. Determine if a list exists of appropriate change requesters for each application.
8. Verify that the appropriate approvers within IT operations, IT systems development and the
business owner have approved the change and their approval is documented.
9. Determine if the change requests are subject to prioritization. If prioritization is performed,
determine if appropriate members of management review the priority assignation and
authorization regularly.

(c) ISACA 2016 All Rights Reserved Identify Changes, Page 12

 Audit/Assurance Program
Change Management

IS Audit/Assurance Program
Change Management
Ref. Control Control Control
Process Sub-area Risk Control Objectives Controls Type Class Frequency

Production Library CO1. Production libraries should be secure, C1. Access to production source is limited on a
Management allowing only authorized personnel to access the need-to-know basis. Programmers are limited to
production libraries. Management must provide READ access; only change management staff
oversight of access to libraries, good-practice members are assigned WRITE access.
separation of duties, and synchronization of
source and executable libraries.

C2. 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.

(c) ISACA 2016 All Rights Reserved Production Library Management, Page 13
 Audit/Assurance Program
Change Management

CO2. The production executable libraries contain C3. Access to production executable libraries is
the computer code to process the programs. limited on a "need-to-know" basis. Programmers
Access needs to be limited and monitoring are limited to READ access; only change
processes need to be in place to effectively management staff members are assigned WRITE
oversee change activities affecting the executable access.
libraries.

C4. 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.

C5. 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.

(c) ISACA 2016 All Rights Reserved Production Library Management, Page 14
 Audit/Assurance Program
Change Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/ Workpaper Fail Comments
Standards
1. Through interviews, observation and review of documentation, determine the controls limiting BAI03.03;
access to the production source libraries. DSS02.03;
2. Determine if there is a separation of duties table identifying the access levels and to whom they BAI07.06
are assigned.
3. Verify that ID access logs, including date and time stamps, are maintained and reviewed on a
regular basis.
4. Determine if access control lists are reviewed and updated regularly.
5. Test objective: To verify that access to the production source libraries is provided on a need-to-
know basis
6. Obtain the access control list for production source library.
7. Review the list and identify any personnel not in change management with WRITE access to the
library.
8. Obtain the access logs and identify unauthorized or suspicious access to production library.
9. Verify documented management review of the access control list and unusual activity logs.
Ensure periodic review.

1. Through interviews, observation and review of documentation, determine how version control BAI03.03;
operates and if it can be overridden. DSS02.03;
2. Through interviews, observation and review of documentation, determine if the functionality BAI07.06;
exists to roll back an update and restore a program to its previous version. DSS05.05

(c) ISACA 2016 All Rights Reserved Production Library Management, Page 15
 Audit/Assurance Program
Change Management

1. Through interviews, observation and review of documentation, determine the controls limiting BAI03.03;
access to the production executable libraries. DSS02.03;
2. Determine if there is a separation of duties table identifying the access levels and to whom they BAI07.06;
are assigned. DSS05.05
3. Determine if ID access logs, including date and time stamps, are maintained and reviewed on a
regular basis.
4. Determine if access control lists are reviewed and updated regularly.
5. Test objective: To verify that access to the production executable libraries is provided on a
need-to-know basis:
- Based on risk, select the production executable libraries to be tested.
- Obtain the access control list for production executable libraries.
- Review the list and identify any personnel not in change management with WRITE access to the
libraries.
- Obtain the access log and identify unauthorized or suspect access to production libraries.
- Verify documented management review of the access control list and unusual activity logs.

1. Through interviews, observation and review of documentation, determine how version control BAI10.01-02;
operates and if version control can be overridden. BAI10.04;
2. Through interviews, observation and review of documentation, determine if the functionality BAI07.02;
exists to roll back an update program to its previous version. DSS02.01

1. Through interviews, observation and review of documentation, determine what control BAI07.06
techniques are utilized to ensure complete and accurate transmission of program changes.
2. Test objective: To verify the accuracy of distribution of executables to remote processors:
- Select a sample of executables.
- Determine the size, date and time of the executables to be distributed as they reside in the
master executable library.
- For the selected executable, determine the date and time transmitted and the size of the file at
the distributed computer.
- Evaluate the timeliness and completeness of the distribution.

(c) ISACA 2016 All Rights Reserved Production Library Management, Page 16
 Audit/Assurance Program
Change Management

IS Audit/Assurance Program
Change Management
Ref. Control Control Control
Process Sub-area Risk Control Objectives Controls Type Class Frequency

Move to Production CO1. The move to the production process should C1. Program changes require sign-off by the
be controlled and documented. Access should be appropriate stakeholders prior to being moved
limited to authorized change management into production.
personnel. Only authorized changes should have
been made to production programs, and the
move process should ensure synchronization of
the source and executable libraries.

(c) ISACA 2016 All Rights Reserved Move to Production, Page 17

 Audit/Assurance Program
Change Management

C2. Change management software is used to

control the change process.

C3. Manual controls throughout the program

move process prevent unauthorized moves to
production.

(c) ISACA 2016 All Rights Reserved Move to Production, Page 18

 Audit/Assurance Program
Change Management

C4. Management reviews program changes to

ensure that only authorized changes from the
move ticket, systems request or incident log are
included in the modification.

C5. 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.

(c) ISACA 2016 All Rights Reserved Move to Production, Page 19

 Audit/Assurance Program
Change Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/ Workpaper Fail Comments
Standards
1. Determine if the sign-off process, prior to a change moving into production, includes the BAI06.01;
following: BAI06.02;
- The programming function indicates completion of testing, quality assurance and documentation. BAI06.03;
- Users indicate satisfactory acceptance test, approval and knowledge of implementation date BAI06.04;
- IT operations indicates acceptance of documentation, scheduling changes, backup changes, run- BAI07.06
time changes, etc.
- Information security indicates acceptance of information security changes.
- Documentation (user, IT operations, backup/recovery business continuity plan) is approved.
2. Test objective: To verify the sign-off process to ensure that all sign-offs were completed before
the move to production and the appropriate personnel approved the move
A. Obtain a sample of routine move-to-production tickets for applications and software changes in
scope
B. For each move ticket, verify timely approvals by:
- The programming function indicates completion of testing, quality assurance and documentation.
- Users indicate satisfactory acceptance test, approval and knowledge of implementation date.
- IT operations indicates acceptance of documentation, scheduling changes, backup changes, run-
time changes, etc.
- Information security indicates acceptance of information security changes.
- Documentation indicates satisfactory reviews by users, IT operations, backup/recovery business
continuity plan.

(c) ISACA 2016 All Rights Reserved Move to Production, Page 20

 Audit/Assurance Program
Change Management

1. Through interviews, observation and review of documentation, determine the automated BAI06.01;
change management process. BAI06.02;
2. Walk through the process of entering a move ticket, approving the ticket, compiling the program BAI06.03;
and moving it into production. BAI06.04
3. Determine the controls to identify and authenticate the approver’s authority to move a program
into production.
4. Determine the available logs and reports generated by the change management system to trace
and research program moves into production.
5. Determine if there are “back doors” that allow bypassing of the change management software
system.
6. Determine if logs and reports generated by the change management system are reviewed by
management and if such reviews are formally documented.
7. Test objective: To verify that the change management software and user controls are effective:
- 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.).
- Select several change tickets. Follow the selected change tickets through the process, verifying
compliance with identified controls.

BAI07.06

1. Document the process of moving the program from the test to the production environment.
2. Document the process of independently recompiling the programs by someone other than the
programmer, and placing the programs in a production library.
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.
4. Test objective: To verify the effectiveness of the manual change management process:
- 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.)
- Select a statistically valid sample size (at least 25 randomly selected moves to production).
- Trace the move to production against good practices and enterprise standards. Focus on the
documented evidence of management review.

(c) ISACA 2016 All Rights Reserved Move to Production, Page 21

 Audit/Assurance Program
Change Management

1. Determine whether a comparison of source code before and after the modification is included in BAI03.03;
the documentation. DSS02.03;
2. Determine how management reviews the changes to ensure that only authorized changes have DSS05.05
been implemented.
3. Test objective: To verify the process of comparing authorized changes to completed changes:
- Select a sample (including emergency requests) from a population of move tickets.
- Obtain the change request supporting the move ticket.
- Based on the change request, obtain an understanding of the changes required.
- Run a source code comparison of the previous and current programs to identify the code changes.
- Perform a “reasonableness” test, ensuring that the changes requested in the systems request are
the same changes implemented.

1. Determine how the compile process generates the date and time stamp of compilation. BAI06.04;
2. Determine that the executable library documents the date and time of update. BAI10.03
3. Determine the process that ensures that all executables in the library have move tickets.
4. Test objective: To verify that the production source and executable libraries are synchronized:
- Select a sample (including emergency requests) from a population of move tickets.
- Verify that the source compilation date and time agrees with the date and time of the executable.
- 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. Test objective: To verify that all executables have move-to-production tickets:
- Select several executable programs/modules from the production executable library. Trace the
executable to a move ticket.

(c) ISACA 2016 All Rights Reserved Move to Production, Page 22

 Audit/Assurance Program
Change Management

IS Audit/Assurance Program
Change Management
Ref. Control Control Control
Process Sub-area Risk Control Objectives Controls Type Class Frequency

Emergency Changes CO1. Emergency changes should be controlled, C1. Changes using the emergency change
documented and initiated only in true procedure are initiated only for changes where
emergencies. time is of the essence.

C2. Emergency changes are adequately tested

before being placed into production.

C3. Emergency changes are authorized by an

appropriate member of management before
being placed into production.

(c) ISACA 2016 All Rights Reserved Emergency Changes, Page 23

 Audit/Assurance Program
Change Management

C4. Special processes are in place to allow one-

time execution of emergency changes while
keeping the integrity of the production libraries.

(c) ISACA 2016 All Rights Reserved Emergency Changes, Page 24

 Audit/Assurance Program
Change Management

C5. Emergency changes are subject to the same

quality assurance as normal changes.

(c) ISACA 2016 All Rights Reserved Emergency Changes, Page 25

 Audit/Assurance Program
Change Management

Ref. Ref. Ref. Pass /

Testing Steps COBIT 5 Framework/ Workpaper Fail Comments
Standards
1. Through interviews, observation and review of documentation, determine if there is a definition BA06.02
for an emergency change.
2. Test objective: To verify that only necessary changes are made using the emergency change
procedure:
- Select a representative sample of emergency changes.
- Using the definition of an emergency change, review the emergency changes to determine if the
changes were, in fact, emergencies.

1. Through interviews, observation and review of documentation, determine the process used to BA06.02
review testing procedures before an emergency change is accepted into production.
2. Determine if a list of authorized requesters for emergency changes exists.
3. Test objective: To verify that emergency change authorization was approved prior to the
introduction of the change into the production environment:
- Select emergency changes from several sources.
- Review the existence of test results and management review.

1. Through interviews, observation and review of documentation, determine the process used to BA06.02
authorize emergency moves to production. Differentiate between minor and major enhancements,
operating system, configuration files and source programs.
2. Test objective: To verify that change authorizations were documented prior to the introduction
of the change into the production environment:
- Select a representative sample of emergency changes.
- Determine if the move into production was properly authorized.

(c) ISACA 2016 All Rights Reserved Emergency Changes, Page 26

 Audit/Assurance Program
Change Management

1. Determine if the emergency changes are executed from a temporary or test library, or copied BA06.02
into the protected production library.
2. 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.
3. Determine if one-time passwords are utilized to protect libraries.
4. 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.
5. If the controls to protect the production libraries do not include one-time passwords, document
and evaluate the effectiveness of the other controls.
6. Test objective: To verify the effectiveness of the change control process that ensures the
integrity of the production libraries and application data:
- Select a sample of emergency moves to production.
- Determine if the program was run from an interim library or the production library.
- If the production library was used, determine if a one-time password was retrieved.
- Determine if the one-time password was disabled.

(c) ISACA 2016 All Rights Reserved Emergency Changes, Page 27

 Audit/Assurance Program
Change Management

1. Through interviews, observation and review of documentation, determine the process for BA06.02
reviewing emergency changes.
2. Determine what controls are in place to ensure that the data processed used the updated
program
3. For high-risk applications, it may be necessary to perform a comparison of the data to ensure
that essential fields have not been changed
4. Through interviews, observation and review of documentation, determine after-the-fact quality
assurance procedures, recompilation procedures, etc., to align the emergency change with
standard move-to-production procedures
5. Test objective: To verify the effectiveness of the change management quality assurance process
and appropriate authorization
- Select a sample of emergency moves to production.
- 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.
- The programming function indicates completion of testing, quality assurance and documentation.
- Users indicate satisfactory user acceptance test, approval and knowledge of implementation date.
- IT operations indicates acceptance of documentation, scheduling changes, backup changes, run-
time changes, etc.
- Information security indicates acceptance of information security changes.
- Documentation indicates satisfactory reviews by users, IT operations, backup/recovery business
continuity plan.
6. 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.

(c) ISACA 2016 All Rights Reserved Emergency Changes, Page 28