IT Knowledge Topic

Program Changes

August 2020

For Internal Use Only

Document disclaimer
This document is for reference information only. The use of this material is optional. It does not modify the
audit methodology or guidance set out in the relevant manual.
If there is a mandatory/specified approach (or document) for your local member firm, please use that. If
you are unsure of your member firm’s policy for use of this document it is recommended you contact your
relevant Risk or Methodology team, including DPP resources.

This document may not cover all risks or considerations related to the specified topic. These materials are
provided for consideration and should be assessed for use, if appropriate, on an engagement-specific basis.
Wherever possible, audit work is documented directly in eAudIT/KPMG Clara workflow.
This document should not be put on file.

This document is a resource for engagement teams to use as they plan their IT audit work in relation to
Program Changes (PC) at the entity they are auditing. This document should not be retained in the audit
workpapers.
NOTE: This document is one of a series of IT Knowledge documents. To understand fully all the
considerations covered in this document, teams may wish to refer to other IT Knowledge documents. 

*Note on applicability: The new audit methodology set out in the KPMG Audit Execution Guide (KAEG)
introduces a number of significant changes to our methodology. One significant change that impacts on IRM
work is that to link automated controls to GITCs, engagement teams identify the layers of technology that
impact each relevant automated control, the risks arising from IT (RAFITs) within each layer, and the GITC(s)
that address each RAFIT. This approach is supported in the new audit tool that replaces eAudIT: KPMG Clara
workflow (KCw). 
This document is drafted to be used by teams applying both KAM and KAEG, as far as possible terminology
used is methodology independent, but where necessary the terminology of RAFITs and layers of
technology is used. These are implicit in the KAM audit approach and explicit in KAEG. For more information
on KAEG and KCw see the following site https://intra.ema.kpmg.com/sites/AUDIT/KPMG_Clara_workflow/
Pages/Guidance.aspx.
There is further guidance on certain terminology differences in KAM Alert 20-001.

© 2020 KPMG International Cooperative (“KPMG International”), a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567
Overview
This document provides a high- level overview of program change controls and is split into three sections:
1. Overview of Program Changes,
2. General considerations when obtaining an understanding of the program change process, and
3. Example test considerations.

Overview of Program Changes

Program change controls are controls established — Emergency changes – these can be emergency
by management to ensure that changes to existing changes to both application and infrastructure layers,
systems/IT applications are authorized, tested, though emergency changes are more common at
approved, properly implemented, and change details are the application layer, as changes to the infrastructure
documented1. Effective program change controls could are more pervasive and typically require more upfront
minimize the likelihood of disruptions, unauthorized planning.
alterations, and errors.
Some of the typical key control points in the change
The goal of change management is to help manage the management process relevant to an IRM audit are:
risks associated with the introduction of new elements
— Change management policy – A change
and other modifications into an IT environment,
management policy is developed and maintained.
particularly in development, project management,
This policy is expected to be followed for all
procurement, outsourcing, service testing, and
types of changes, including how to address
operational areas. Prevention of unauthorized,
emergency changes. Changes requiring immediate
inappropriate and ad hoc changes is at the heart of
implementation should be properly handled on a
the change management process. Essentially, all
timely basis, with minimal impact to systems and IT
changes are individually reviewed and approved prior to
applications related to the financial reporting process.
implementation. Management defines an appropriate
program change model, or workflow, for change — Change Request Initiation and Approval –
requests based on their potential business impact and Requests for changes are standardized and subject
urgency. An assigned review authority either approves to management review and approval. Authorization of
the change and schedules it for implementation or system, IT application and infrastructure changes by
rejects the change and returns it to the requestor with an appropriate level of business and IT management
an explanation. This basic workflow can be expanded or prior to development helps to determine that changes
contracted, in relation to the nature of the change. will meet the user requirements and support the
financial reporting objectives. Changes are categorized
Change management process generally comprises the and prioritized and specific procedures are in place to
following types of changes made to an IT system handle urgent matters. Change requestors are kept
— Application changes informed about the status of their request.
– System upgrades — Documentation of Changes – Documentation
– Enhancements includes a brief functional description of the change;
date the change was implemented; who made the
– Bug fixes change; who authorized the change (if multiple
– Configuration changes people can authorize changes); and what technical
elements were affected by the change.
— Infrastructure changes – includes vendor patches,
— Testing and User signoff – Change is thoroughly
root changes, upgrades and/or new development
tested in a testing (nonproduction) environment, not
relevant to the following:
only for the change itself but also for any impact on
– Operating system (OS) other IT elements not directly part of the change.
– Database — Testing Environment – Organizations may have
two, three or more separate environments for
– Network
development, testing and production. The test
– Hardware and production environments are generally the
same environments with the exception of size.
1 KAM 32.1212 – IT environments and IT controls

© 2020 KPMG International Cooperative (“KPMG International”), a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567
Overview of Program Changes (Continued)
If cost prohibits having three environments, testing — Configuration changes – Configuration changes
and development could take place in the same are application settings or minor changes to a field,
environment; but development activity would need form or menu options that are specific to the users
to be closely managed (stopped) during acceptance or the business needs. Configuration settings
testing. Some large organization may also have a within an application are a key component of many
quality assurance or pre-production environment information systems, and may be subject to change
in between test and production environments. control procedures to maintain the integrity of the
Management’s use of a development and test application controls. Configuration settings may
environment which is separate from the production affect the design, implementation and/or operating
environment helps to ensure that only authorized/ effectiveness of application controls.
appropriate changes are made and that the changes
Completeness of the population of program changes
will not have a negative effect on the information
processing and application controls when promoted We consider the listing of all changes implemented
into the production (live) environment. during the period under audit as information provided by
— Version Control – Production source code is the entity, as this is used by the engagement team in the
controlled in a way that only the latest version is execution of our audit procedures. As such, the nature of
being updated for a change. Previous changes may procedures performed to address the completeness of
be inadvertently lost when a new change is moved the population of program changes considers the results
into production. Version control may also help in of other general IT control testing, and may include2:
being able to effectively back out a change that has — gaining an understanding of the nature of the system
unintended side effects. used for capturing and documenting program
— Deployment to production – Changes deployed to changes, considering its degree of automation and
production are approved by authorized individuals prior configurability
to migration. Changes are deployed to the production
— determining the completeness of change control logs
environment by authorized individuals only, and
developers do not have access to deploy changes to — assessing the degree to which changes are identified
production. This prevents developers making further and logged, and whether this process can be
changes to code once the change has been tested and bypassed
approved. Only a limited number of personnel should
— assessing the authorization controls over change
have access to migrate changes to the production
control software and software libraries
environment to ensure that this process is controlled
such that only authorized, tested and properly — determining whether the population includes
approved changes are migrated into production. changes for each relevant system.
— Postimplementation review – Changes deployed in
production are reviewed and verified once completed
to confirm if the change was made appropriately and
as requested.

General Considerations
When assessing change management controls, we Example questions for obtaining an understanding of
enquire about the approach taken by the entity across the change management process and controls:
the organization. Consideration for controls related to
— Is there a change management policy that covers all
these topics is not just at the application layers of the
potential changes to be made to an IT environment -
IT system level but also includes the OS and database
application, OS, network and database?
layers (see types of changes described in the overview
section of this document) based on the relevant IT — Which group(s) within the IT organization are involved
automated controls. Considerations noted below, apply in the change management process?
to all the different IT layers that are part of an IT system
– application, OS, network and database.

2 KAM 32. 9180 – IT environments and IT controlsand IT controls

© 2020 KPMG International Cooperative (“KPMG International”), a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567
General Considerations (Continued)
— Is the change management process the same or – Who or which group(s) is authorized to approve
different for all IT system components – application, testing performed before change is deployed to
OS, network and database? production?
– If it is the same, how can that be evidenced for — How are changes deployed to production?
all systems in scope?
– Is there an automated deployment process?
– If the process is different, what are the
– Who or which group(s) is authorized to approve
differences?
changes before being deployed to production?
— Is there a change management workflow tool that is
— Who has access to deploy changes to production?
used across these systems and does the tool guide
the change management process? – Do developers have access to deploy changes to
production?
— Who or which group(s) is authorized to initiate
changes to the different IT system layers? – If developers have access to production, are
there periodic monitoring controls in place to
— Who or which group(s) is authorized to approve
monitor activities performed by developers in
changes to the different IT system layers?
production?
— Are there separate development, test and production
— Are postimplementation reviews performed for
environments?
every change deployed to production?
— Is there a source code management tool?
– If yes, who performs it and what is the
– Who has access to the source code? timeframe within which the review is required to
be performed?
– How are the code changes tracked?
– If the change is not approved by the reviewer,
– How is the code managed so that only the latest
what is the process to back-out the change or
version is updated and deployed to production?
make the necessary changes?
— Are the test and production environments the same?
— Are there periodic monitoring controls to validate
– If yes, how can that be evidenced and/or how that changes deployed in production followed the
is the test environment maintained to match required change management process?
production?
— Are vendors involved in the change management
— Are there any tools that assist in automated process?
deployment of changes?
– If yes, who is authorized to coordinate and
– If yes, how is access and segregation of duties approve changes made by vendors?
managed within the deployment tools?
– Do vendors have access to deploy changes to
— Is testing performed for all changes before they are the production?
deployed to production?
» If yes, how is the vendor access managed?
– Are test plans reviewed and approved before
– Is there a service organization report provided by
testing is performed?
the vendor for the change management process
– If yes, what are the different types of testing followed? Who is responsible for reviewing that
performed – development, QA, UAT, etc.? report to assess the adequacy of the controls
and any issues noted in the report?
— Is testing performed in a nonproduction
environment? — Is there an emergency change management process?
— Is testing approval required before a change is – If the process is different, what are the
approved to be deployed to production? differences and how is that documented,
controlled and managed?

© 2020 KPMG International Cooperative (“KPMG International”), a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567
Example Test Considerations
Note: Controls will vary based on the facts and circumstances of the particular audit engagement.
The information in this section is provided as example information only.

Example WCGW/RAFITs Illustrative Control Testing Considerations

Unapproved changes to All changes are authorized Evaluate that:
IT system programs and/ by appropriate individuals, — A complete and accurate population of changes
or configurations are before being deployed to from the source system(s) is available to select
implemented into the production. samples.
production environment.
Inquire, inspect, and/or observe to obtain
evidence that:
— Change management policy provides details on the
required controls.
— Change log is maintained to track details of the
change.
— List of individuals/group(s) who can authorize the
different types of change(s).
— Change records were authorized by appropriate
individuals/group(s) prior to being deployed to
production.
Changes to IT system All changes are tested and Evaluate that:
programs and/or IT approved by appropriate — A complete and accurate population of changes
system configurations individuals, before being from the source system(s) is available to select
do not function as deployed to production. samples.
intended.
Inquire, inspect, and/or observe to obtain
evidence that:
— Change management policy provides details on the
required controls.
— Change log is maintained to track details of the
change.
— Testing plans are prepared before testing is
performed, if applicable to the change.
— Testing was performed and change was approved
by appropriate individual/group(s) prior to being
deployed to production.

© 2020 KPMG International Cooperative (“KPMG International”), a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567
Example Test Considerations (Continued)

Example WCGW/RAFITs Illustrative Control Testing Considerations

Logical access to Changes are deployed to Evaluate that:
implement changes to production by authorized — A complete and accurate population of changes
IT system program or individuals based on their from the source system(s) is available to select
configurations into the job responsibilities. samples.
production environment
is unauthorized or not Inquire, inspect, and/or observe to obtain
commensurate with job evidence that:
responsibilities. — Change management policy provides details on the
required controls.
— Change log is maintained to track details of
changes.
— An approved list of individuals/IDs (system or
shared accounts) that have access to deploy
changes to the production environment is
maintained.
— Developers do not have access to production or
the deployment tool to deploy changes.
— Where a DevOps model is in place, the access and
authority levels of relevant personnel (including
developers) does not allow them to circumvent the
change management process.
— Where applicable, a postimplementation review is
performed.

© 2020 KPMG International Cooperative (“KPMG International”), a Swiss entity. Member firms of the KPMG network of independent firms are affiliated with KPMG International. KPMG
International provides no client services. No member firm has any authority to obligate or bind KPMG International or any other member firm vis-à-vis third parties, nor does KPMG International
have any such authority to obligate or bind any member firm. All rights reserved. NDP111567