ASSURANCE MATTERS

UNDERSTANDING AND EVALUATING

CONFIGURATION CHANGES
JUNE 2017/ ISSUE 05 - FOR INTERNAL USE ONLY

Introduction
IT applications used by entities may be configured internally (by the IT department, users
IN THIS ISSUE
or data owners) or externally (by application suppliers); application configuration changes
may range from limited changes (e.g., simple user preference changes) through to those Risk associated with
with a significant impact on financial reporting (e.g., user access management, inventory configuration changes
costing parameters, fixed asset amortisation settings, ageing report parameters, automated Understanding the difference
application control settings, and application workflow settings). As a result, configuration between configuration
changes have an impact on how we approach the audit of an entity. changes and programmed
Configuration changes are as important for smaller off-the-shelf packaged applications application changes
that do not allow for modification of the source code, as for large Enterprise Resource Evaluating how configuration
Planning (ERP) systems that have been customised to meet an entity’s needs. settings impact financial
Therefore, we assess relevant controls over configuration changes in order to: reporting
• Provide a sufficient basis for the consistent operation of Control Activities Relevant to Configuration settings and
the Audit (CARA), and / or system-generated IPE

• Establish the reliability of configurable Information Produced by the Entity (IPE) that Access rights to configuration
we do not plan to test substantively. settings
Configuration management
In some organisations, configuration changes may be administered by the IT Department,
in a cloud environment or
in which case controls over configuration changes would typically be assessed as part of
outsourced services
our work on Information Technology General Controls (ITGCs). In other circumstances,
configuration changes may be performed by the accounting department, in which case we Auditor identification
would typically consider configuration changes through our assessment of the design and and documentation of
implementation of controls in each of the cycles. configuration settings

Risk associated with configuration changes And more...

The main risk associated with configuration changes with regards to financial reporting
is that unauthorised changes could be made that impact internal controls and ultimately
financial reporting. These unauthorised changes could include invalid configuration changes
as well as potentially valid changes that were made without appropriate authorisation.
Understanding the difference between configuration changes and CONTACT
programmed application changes
Questions related to this topic are to be
The main difference between configuration changes (settings) and application changes directed to your Regional Audit Advisor
(changes in the application source code (program code) using programming language) can (RAA) or submitted via email to
be described as: audit@bdo.global.

• Configuration changes are mostly parameter changes, without changes of program ASSURANCE MATTERS
code, to the setting options that were previously predefined in the application. These Assurance Matters are issued by the
changes can be performed by users who can access the setting options menu or Global Assurance Department and
screens in the application; distributed to the International A&A
Coordinators.
• Changes of programmed application features requires the involvement of a
programmer in order to make changes to the program code. © Brussels Worldwide Services BVBA, June
2017
Programmed application changes have advantages (e.g., better control over application
features – see examples below) as well as disadvantages (e.g., cost of changes, the need for
additional controls over program changes and development, and less end user flexibility).
The following examples further highlight the differences between configuration changes
and programmed application changes.
 2

Password policy
One of the ITGCs designed to prevent unauthorised use of application is the use of passwords to authenticate users. The
password policy may be hard-coded, meaning a programmer has previously included lines of code that define password
policy characteristics (e.g. passwords are a minimum of 6 characters in length, include alpha and numeric values and are
changed every 60 days). On the other hand, the application may include a menu option, providing the system administrator with the
ability to set up and adjust password policies according to the entity’s needs. The main difference is increased flexibility for an entity
– changing hard-coded parameters may be more expensive, time consuming, and can only be done by a programmer familiar with the
program code.
Automatic journal entry numbering
Some Application may include a hard-coded feature for automatic journal entry numbering; if the numbering has to be
changed to include more characters or to follow a new business rule (e.g., to start from a certain digit or change the journal
entry number field to be a manual field that can be edited by users), programming is required to change the program code
accordingly. However, if the journal entry numbering is determined through the use of parameters included within specially designed
menus, users with access to those menus may change journal numbering rules simply by adjusting the relevant radio buttons or
choosing a value from a drop down list.
Inventory management
Some financial applications, especially if it is a bespoke system designed according to an entity’s requirements, might have
the inventory valuation method built-in within the program code (also referred to as ‘hard-coded’), meaning the application
calculates inventory values only according to, for example, the FIFO method. Any change in the entity’s accounting policy on inventory
valuation, would require engaging a programmer or contacting the application provider to develop and implement modified program
code. Other applications may provide an integrated menu that allows users, with privileged application access, to choose their preferred
inventory valuation method; this means that the program code for whether the system uses FIFO, LIFO, weighted average cost or other
methods has already been developed by programmers, and all the entity needs to do is select a valuation method through the menu
options.
Evaluating how configuration settings impact financial reporting
Some configuration settings may be purely related to user preferences, making the user experience with the application more flexible
and convenient. Such configuration changes include, for example, adjusting a user-defined quick access menu or populating certain
fields with default values (e.g., if a user produces a certain report frequently, they might configure the report to use predefined values,
such as the accounting period or a range of selected accounts). The main attribute of such user preferences configurations is that they
only influence the specific user experience within the application.
Additional user interface configurations may exist within the application and can be customised centrally for all users. Such
configurations are also designed only for the convenience of users (e.g., date and number formats, language and left to right vs. right
to left preferences), and do not influence the processing or the outputs of the application.
There are, however, some configuration settings that can influence the input, processing and output of the data in the application or
the IPE produced from it (system-generated IPE).
The following are some examples of typical configuration settings that may have an impact on financial reporting, and thus our financial
audit:
Accounts receivable
• Duplicate invoice numbers are not allowed;
• Credit limit parameters;
• Customer terms in the customer master file (e.g. giving a client a 3% discount if they pay their invoice prior to 30 days); and
• Ageing criteria for outstanding invoices (e.g. affecting how current items go from ‘less than 30 days’ to ‘31 to 60 days’).
General ledger and journals
• Journal entries, invoices and other internal documentation are automatically numbered;
• Journal entries must balance;
• Prior to posting, journal entries require approval from a user other than the creator of the entry;
• The ability to post a journal entry to a closed financial reporting period; and
• Sub-ledger mapping to the General Ledger.
Inventory / purchases / fixed assets
• 3-way match of approved purchase order, goods received note, and vendor invoice;
• Pricing and quantity tolerances to compare values per approved purchase order to vendor invoice (pricing and quantity) and
receiving reports (quantity);
• Changing the inventory valuation method;
• Changing the ageing criteria for finished goods; and
• Changing the fixed assets depreciation method.
 3

Financial assets
• Treasury or corporate bond amortisation method;
• Interest calculation parameters; and
• Loan loss provisioning parameters.
Payroll
• Salary calculation method (e.g., monthly, weekly, daily or per hour); and
• Application parameters (e.g., contribution percentage, tax levels, etc.).
Configuration settings and system-generated IPE
Configuration settings which influence the input, processing and output of transactional data in the application may eventually alter the
content of system-generated IPE which management may rely on for financial reporting and we may use as audit evidence. However,
in most systems, frequently used predefined reports (e.g., trial balance, accounts receivable or accounts payable listings, inventory
counts, etc.) are usually coded into the programs which generate the actual reports and cannot be changed via configuration settings.
Configuration settings that might have a significant impact on financial reporting are, according to chapter 14 of the BDO Audit
Manual, indicators of a complex IT application. If we are unsure if configuration settings may affect financial reporting or IPE, we are
encouraged to consult with an IS audit specialist to establish whether configuration settings affect system-generated IPE that we do
not plan to test substantively.
User-generated IPE which allows for a temporary modification of certain fields in order to print or extract data without changes in the
application database (i.e., date range, transaction type, company code, etc.) is not considered a configuration setting (i.e., a standard
report that is utilized in the month-end close process where the date or period is changed every month).
Access rights to configuration settings
Access to change and update configuration settings is generally limited to users with privileged application access such as a user with
‘Administrator’ access rights in an application. However, application access privileges which allow changes to configuration settings
may also be granted to other users depending on the specific application. These broader application access privileges may be granted
to individuals in the IT department, other users, external suppliers or all users. As more users are granted access privileges to change
configuration settings, the risk of malicious or inadvertent configuration changes generally increases. When accounting personnel
perform the administration over configuration changes in addition to the processing of transactions impacted by such configurations,
this can also impact segregation of duties.
Configuration management in a cloud environment or outsourced services
While obtaining an understanding of the system of internal controls, we may identify cycles within the entity’s business activities
that are outsourced (i.e., managed by a third party) or hosted in a cloud environment (e.g., Software as a Service or SaaS1). Where
configuration changes are not managed or controlled by the entity directly, we would ordinarily consider whether:
• Data or transactions generated by these applications impact IPE;
• The entity has implemented additional controls (i.e. manual or automated);
• The relationship between an entity and its service provider has been formally agreed through a service level agreement (SLA) or
similar documentation;
• The entity receives periodic information about changes in configuration settings for approval, or if the service provider informs the
entity about configuration changes made;
• The entity has had previous issues or errors due to configuration changes made by the provider; and
• The third party has internal controls over its maintenance of the application. Such controls at the service provider may be validated
through an attestation report (e.g., SOC 1 or ISAE 3402 reports on controls at the service organization).
Auditor identification and documentation of configuration settings
From an audit perspective, the first step in addressing the relevance of configuration changes to financial reporting information systems
and our audit is to determine whether any significant configuration changes were made during the period and review logical access
controls of privileged users (for example, by reviewing a log of changes within the system or by reviewing a list of change requests
and users who performed them). Then our assessment regarding the impact of configuration changes that might significantly affect
financial reporting would ordinarily consider:
• Volume and type of configuration settings: While every accounting system might have configuration settings, not all of these
settings affect financial reporting, and thus do not necessarily make the IT application complex or have an impact on our audit;
• Number of users with access to change configuration settings: The likelihood of potentially unauthorised or incorrectly
performed configuration changes generally increases for entities with a significant number of users with privileged (e.g.,
‘Administrator’) access rights; and

1
SaaS is a software distribution model in which a third-party provider hosts applications and makes them available to customers over the Internet.
 4

• Segregation of duties considerations: Inappropriate segregation of duties may occur where management or business users
involved in the processing of impacted transactions have the ability to make configuration setting changes in applications that
directly affect such processing and financial reporting.
If we identify CARA or IPE (that we do not plan to test substantively) that is modifiable by a configuration setting, regardless of whether
we plan to perform Tests of Controls (TOCs) or not, we would ordinarily assess the design and implementation of relevant ITGCs over:
• Change management of configuration settings; and
• Logical access controls over privileged application access (i.e., where access is appropriately restricted with no segregation of
duties issues) including consideration of compensating manual controls.
Assessing design and implementation of controls over configuration settings
For non-complex IT applications where such configuration changes are simply a matter of a user selecting from a limited number of
radio button choices, a financial statement auditor may be able to evaluate the impact of such settings on the financial statements, and
may well be able to evaluate the design and implementation of controls surrounding changes to such configuration settings.
However, for more complex IT applications with large volumes of settings, assistance from an IS audit specialist may be necessary to
evaluate such settings, including the potential use of computer assisted audit techniques (CAATs) or other tools to look for possible
changes to important configuration settings during the period.
These procedures may include obtaining a log of configuration changes made during the financial period and an assessment about
whether any changes have occurred in configurations related to the identified CARA and/or IPE that we do not plan to test substantively.
If we find the log of configuration changes to be reliable (i.e., the log has been shown to automatically track every configuration change
made during the period and it has not been manually altered or turned off) and it does not indicate any significant changes to the
assessed configuration settings, we may consider relying on our assessment of configuration settings from previous audits. If there is
no logging of relevant configuration changes made during the period or other controls that we can test, we would ordinarily perform
testing at various times throughout the period of the configuration settings and any changes made.
The impact of configuration control deficiencies on our audit response
Financial statement auditors and IS audit specialists are encouraged to work together to determine the impact of any identified ITGC
and application deficiencies, including those related to configuration changes, and the most appropriate audit response. In some
situations, the impact of configuration setting changes may lead to a modified audit response. For example, further assessments of the
design and implementation of CARA, or additional substantive testing procedures.
If ITGCs over configuration changes are lacking or deficient and/or privileged application access is considered to be excessive or
otherwise deficient, then audit engagement teams may raise an Engagement Team Discussion (ETD) point in APT so that the related
potential risks of material misstatement (RMMs) are discussed during the ETD.
Testing controls over configuration settings
In cases where TOCs over the management of configuration settings affecting financial reporting are planned, these tests may include
consideration of:
• Controls that restrict access to an appropriate group of people who are not motivated to make unauthorised or inappropriate
changes to such configuration settings;
• Manual controls validating system configurations and/or the system-generated IPE; and
• Existence of logs over such configuration changes and/or tools for continuous change and configuration management.
Summary
Configuration changes may significantly impact financial reporting (IPE and/or the operation of CARA) since they define the parameters
and rules that IT applications use to process and present financial information. A user with access rights to change configuration
settings could inappropriately affect the financial information. Therefore, if we identify changes to the IT applications’ configuration
settings that have a significant impact on financial reporting, we consider whether these changes lead to potential RMMs or could have
an impact on IPE and/or CARA. The importance of controls over configuration changes depends on several factors, such as the:
• Existence of automated or computer dependent CARA and/or IPE (that we do not plan to test substantively) that are affected by
configuration changes.
• Volume and impact of configuration settings available within the IT applications and the extent of changes made during the
period.
• Risks associated with changes to such configuration settings, including the likelihood of intentional or accidental changes to
significant settings.