Primary Control Testing Procedures

IT General Controls
I. Introduction
Tests of IT general controls (ITGC) are performed to determine whether management has
effective IT general controls in place that help to provide reasonable assurance that application
and IT-dependent manual controls continue to function effectively over time when a Controls
Strategy is planned for the related significant classes of transactions and significant disclosures,
and that the completeness and accuracy of electronic audit evidence can continue to be relied
upon once a basis for that reliance has been established.
We perform tests of the ITGCs on which we are relying to obtain evidence that they are
operating effectively. The following framework provides the foundation for the development of
our relevant ITGC testing procedures. We would expect the procedures in Appendix A to be
performed in most cases. However, there may be situations in which we would not perform
some or all tests of ITGCs. Examples of such testing scenarios are:
Application of our top-down, risk-based approach, often in the context of an integrated
audit, may lead us to vary the nature of our testing based upon the relevance of
application and/or IT-dependent manual controls.
Where there is an ineffective design, implementation, or operating effectiveness of one or
more ITGC(s).
The entity may have applications to which no changes were made. We may not need to
perform the manage change testing procedures identified in Section II for those
applications where we are able to confirm that changes have not occurred.
The entity may have outsourced relevant ITGC procedures to a third-party that provides a
service auditors report. We may be able to rely on the testing performed by the service
auditor once a basis for that reliance is established.
Internal audit may perform testing on our behalf or on behalf of management. We may
be able to rely on the testing performed by internal audit once a basis for that reliance is
established.
For procedures not performed, our rationale should be documented in our working papers to
explain why the procedure was not performed and the rationale should include how the IT
general control objectives were met. The procedures may also corroborate the completeness of
the ITGCs identified within the Documentation of IT General Controls (DITGC U109).
The ITGC testing guidance includes the following categories:

Manage Change (Section II)

Logical Access (Section III)
IT Operations (Section IV) (Optional for Non-Integrated Audit)
The ITGC testing procedures are documented in Appendix A
Sample Sizes
For guidance on appropriate sample sizes refer to EY GAM Procedure 7.1, Section titled
Minimum Extent of Testing.

II. Manage Change

1. Control Objective: To provide reasonable assurance that only appropriately
authorized, tested, and approved changes are made to the applications, interfaces,
database management system (DBMS), and operating systems that support relevant
application and IT-dependent manual controls within significant processes.
INTERFACES with financial impact are included
DBMS- Production database ang inaaudit
RELEVANT APPLICATION with financial impact
2. Define Test Approach: In order to determine the most appropriate testing approach,
we should understand and document in the DITGC the different processes used for
managing changes. To assist with this, the DITGC should document and we walkthrough
the different processes for the following types of changes and components of the IT
environment:
a. UNDESTANDING THE PROCESS THROUGH INTERVIEW (hindi muna
idodocument sa ITGC sa NOTES muna)
* IT Head
*IT Manager
b. WALKTHROUGH before Testing
Documents Change request form, test results, migration form
2.1.

Type of changes:

2.1.1 Program Development/Acquisition Development and

implementation of new applications or systems
2.1.2 Program change Changes being made to existing applications,
interfaces and the DBMS
2.1.3 Maintenance to System Software - Technical changes made to the
DBMS, operating systems, and other system software (e.g., patches,
operating system upgrades)
2.1.4 Emergency Changes Changes made in an emergency situation.
2.1.5
Configuration/Parameter Changes Relates to changes being made
to the overall configuration and parameter settings to the various
components of the IT environment. This includes the initial setup of the
configuration settings for new programs or system software.
PROGRAM CHANGES additional functionality (programmer)
EMERGENCY CHANGES special process pwedeng mahuli ang documentation ng approval,
authorization at testing
CONFIGURATION/ PARAMETER hindi ginagawa ng programmer ginagawa ng
administrator (ex. Change sa Settings 3 way match to 4 way match)

2.2. Components of the IT environments in scope, as defined/developed during

the risk assessment process:
2.2.1 Applications
2.2.2 Interfaces (IT controlled)
2.2.3 DBMS
2.2.4 Operating Systems/Networks
2.3. The testing approach should consolidate common processes and/or change
management tools used in the different components of the IT environment so we
can limit the number of populations we test as part of our ITGC testing. We
should establish a basis for concluding each change process is common via
inquiry and observation, inspection of evidence resulting from the performance
of the controls, or in some cases, reperformance of the controls.
Application SAP
Know the Process - Same change on the process 1 test
3. Population Identification and Sampling Approach: Based on the test approach
defined, obtain a complete list of the changes to the relevant components of the IT
environments from the beginning of the audit period through the date of our test (change
management list). To the extent possible, the listing should be further segregated to only
include those changes and components of the IT environment in scope (see II.2.2, i.e.,
those that support application and IT-dependent manual controls or produce significant
electronic audit evidence).
OBJECTIVITY! - never change the sample, nor edit random sample
Population given by the client
list of changes- from OS and database?
3.1. The

preferred method of selecting a change management sample (see II.2.3)

is to obtain a list directly from a change management system that indicates
all changes actually made from the beginning of our audit period through
the date of our testing. Determine that the list of changes is complete.
3.2. In the event a system generated list is not available, then a combination of
the following is considered:
3.2.1 Obtain the client's list of changes, either a manually maintained
listing or from an automated tracking system like Remedy.
3.2.2 Determine that the list of changes is complete. Obtain a list of
actual changes by looking for executable modules with a compile date
within the audit period (in many cases this may only be the last change to
the module; however for purposes of the completeness test, this is
adequate). Select a sample of the changes during the period from this list
and verify that the change is on the client's list of changes obtained in
II.3.2.1.
Selection of population
1. Obtain a list from the change management system
2. If not available,

2.1 obtain the clients list of changes manually or from automated tracking system
2.2 Determine that the list is complete
2.3 Obtain a list of actual changes by looking for modules example logbooks
2.4 Select a sample from the changes
2.5 Verify the change if it is on the clients list of changes
3.3. If there are no changes, determine that changes have not occurred by
determining the last compile date for the IT component in scope (see II.2.2)
to determine there was no change during the audit period.
4. Test Changes: Select an appropriate sample of changes from the list obtained above
and determine the change was appropriately authorized, tested, and approved:
4.1. Authorized Determine if the change requested has been appropriately
authorized. (Note: Depending on company policy and in some situations, such as
minor changes, perhaps defined as those requiring less than 40 hours of
programmer time, changes may not require specific authorizations).
4.2. Tested Determine whether users performed testing to confirm the change
functions as intended. Otherwise confirm that other appropriate testing did
occur. (Note: in some situations, such as infrastructure changes, IT only testing
may be acceptable depending on the clients policy.)
4.3. Approved Determine if application owners and IT personnel approved
changes prior to being moved into production. (Note: in some situations, such as
infrastructure changes, IT only approval may be acceptable.)
4.4. Monitoring Determine if the change process is monitored on a regular
basis (e.g. steering committee, management review of changes to production.)
*Change request form, test results. And migration form
*kailangang walang nangyari na Unauthorized Changes
5. Test Segregation of Incompatible Duties: Determine that individuals performing the
manage change controls do not have conflicting duties.
5.1. Determine both organizationally and logically that different individuals
within the organization perform the following duties:
5.1.1 Request/Approve the development or change
5.1.2 Program the development or change
5.1.3 Move changes in and out of production
5.1.4 Monitor the development or changes
5.2. In cases where segregation of incompatible duties can not be attained due
to organizational structures or other reasons, another control can be used to
provide assurance that no unauthorized changes are occurring. The control
should be designed to detect when the other change controls in place have been
circumvented because of the segregation of incompatible duties issues.
Examples of controls can be:

5.2.1 Change log review to determine that only approved changes were
moved into production, while confirming the change log is complete
5.2.2
Change control meetings that discuss and follow-up on recent
changes that are to be moved or have been moved into production
5.3. NOTE: Certain change types may not lend themselves to segregation of
duties (e.g., minor patches to operating systems)

III. Logical Access

Control Objective: To determine that only authorized persons have access to data and
applications (including programs, tables, and related resources) and that they can perform
only specifically authorized functions (e.g., inquire, execute, update). Note: the objective
of our logical access testing as part of IT general controls is to confirm there are effective
controls in place around adding, updating, deleting and restricting user access to financial
data and that access to that data is appropriately restricted. We need to consider whether
our IT logical access testing at the general controls level gives us sufficient evidence
regarding the appropriate restriction or segregation of incompatible, relevant accounting
functions. In some cases our IT general control testing, may not provide sufficient
evidence for us to specifically conclude on whether this access is appropriately restricted
or segregated. This is the case or situation where access controls at the application level
are important to our risk assessments and our conclusions on internal control over
financial reporting and we would perform specific testing on that access or segregation of
that access as part of application controls testing.
2. Define Test Approach: In order to determine the most appropriate testing approach,
we should understand and have documented in the DITGC the processes used for
managing security. To assist with this, the DITGC walkthrough should document the
different processes for authorizing access.
2.1. For each significant accounting application (i.e., those where we are
relying on application or IT-dependent manual controls or produce electronic
audit evidence) determine the criticality of each component of the logical access
path the client uses to secure access to financial data.
2.1.1 Application
2.1.2 Operating system, including the security software being used
2.1.3 DBMS
2.1.4 Network
2.1.5 Remote Access/Internet
1.

3. Test System Security Configurations:

3.1. Determine that the general settings are appropriate (e.g., OS/400 security
level of 30 or higher), based on the illustrative procedures defined in EYMercury
(TSRS' web-based tool designed to create customized technical workplans) if
available.
3.2. For each relevant component of the logical access path identified above,
obtain evidence of the organizations settings for the following security
configurations:
3.2.1 Minimum password length
3.2.2 Initial log-on uses a one time password
3.2.3 Password composition (e.g., alpha/numeric characters, not words
in dictionary)
3.2.4 Frequency of forced password changes

3.2.5

The number of unsuccessful log on attempts allowed before

lockout
3.2.6 Ability of users to assign their own passwords
3.2.7 Number of passwords that must be used prior to using a password
again
3.2.8 Idle session time out
3.2.9 Logging of unsuccessful login attempts
4. Test Privileged User Rights: Determine that the ability to perform sensitive IT
functions is limited to only appropriate individuals based on their job function by
performing the following:
4.1. Population Identification: Obtain a list of privileged user rights for the
relevant components (list from III.2.1) of the logical path that support the related
controls. Determine that it is complete.
4.1.1
Include users with the ability to access sensitive utilities when
identifying privileged user rights. A utility is a program or set of programs that allows a particular
task to be executed.
4.2. Review the lists of users with privileged rights and determine if the number
of users appears appropriate. Based on the volume of users and the critical
nature of this control, develop an appropriate test to determine if the users
sensitive access is appropriate based on their job description/function (this listing
should include the review of sensitive system accounts, e.g., SECOFR,
SECADM in an AS/400 environment).
5. Test Resource and Utility Security:
5.1. For application controls that depend on effective access restrictions,
identify and obtain a list of resources (e.g., datasets, accounting schema, master
files, transactional data), including utilities (e.g., SQL Plus, DFU, SuperZap)
associated with the relevant applications that could affect the effective
functioning of the control. Determine that access to the resource(s) is
appropriate.
6. Test User Access Authorization:
If the client has an effective, periodic user validation process (as determined when we
performed our walkthrough), obtain the periodic validation reports and select an
appropriate sample to determine that the users access had been appropriately validated
and test III.6.1, III.6.5 and III.7.
If the client does not have a strong periodic user validation process perform test III.6.1,
III.6.2, III.6.3, III.6.4, III.6.5 and III.7.
6.1. Test New User Set-up: Determine that employees are only granted access
to data that is appropriate based on their job function, by performing the
following:

Population Identification: Obtain a list of new users added during

the period under audit and determine that it is complete.
6.1.2
Select an appropriate sample and determine that there was
appropriate approval granting the new user access and that the users
access was appropriately established based on his/her job function and the
new user request form.
6.2. Test Terminated Users: Determine that terminated employees have been
removed timely from the systems to prevent unauthorized access to data, by
performing the following:
6.2.1 Population Identification: Obtain a list of terminated employees
during the period under audit and determine that it is complete.
6.2.2
Select an appropriate sample and determine if access had been
removed or deactivated timely from the systems.
6.3. Test Transferred Users: Determine that transferred employees are only
granted access that is appropriate based on their new job function and that access
for their previous function has been removed or deactivated, by performing the
following:
6.3.1 Population Identification: Obtain a list of transferred employees
for the period under audit and determine that it is complete.
6.3.2 Determine if the users access is appropriate based on his/her job
function and his/her previous access has been removed or deactivated.
6.4. Test Current Users: Determine that user access is appropriate, by performing
the following:
6.4.1
Population Identification: Obtain a list of current users and
determine that it is complete.
6.4.2
Select an appropriate sample and determine the users access rights
are appropriate by working with appropriate members of the audit team to
determine if the access appears appropriate based on their job
descriptions/functions.
Note: User access rights that are tested within the application control
procedures may overlap with these procedures; therefore a streamlined test
approach may be considered.
6.5. Test the Monitoring of User Access: Determine that an adequate level of
monitoring is being performed surrounding logical access, by performing the
following:
6.5.1 Identify relevant monitoring controls and test that the controls
functioned as expected over the audit period. These controls might
include:
(a) Violation or violation attempts reporting and review
(b) Review of logs (e.g., surrounding privileged user access)
6.1.1

7. Testing of Physical Security

7.1. Obtain a list of employees with access to the data center, determine it is
complete and review for appropriateness. Confirm that controls are in place to
restrict access to only those individuals.
8. Test Logical Access Monitoring
8.1. Obtain sufficient evidence to determine that the logical access process is
monitored on a regular basis (e.g., monitoring compliance with established
logical access control procedures, periodic review of logical access policies and
procedures).
9. Test Segregation of Incompatible Duties: Determine that individuals performing the
control activities over user access do not have conflicting duties; by performing the
following:
9.1. Determine both organizationally and logically that different individuals
perform the following duties related to logical access:
9.1.1 Requesting access, approving access, setting up access, and
monitoring access violations/violation attempts
9.1.2 Performing rights of a privileged user and monitoring use of a
privileged user
Define Test Scope: In order to determine the most appropriate testing scope, we
evaluate the criticality of each component of the logical access path the client uses to
secure access to financial data. In most environments:
10.1. III.3 through III.6 applies at the application level when the controls are
important in achieving the control objectives for relevant assertions for significant
accounts.
10.2. Not all of III.3 through III.6 may apply at the operating system and DBMS
levels when the controls are important in achieving the control objectives for
relevant assertions for significant accounts.
10.3. Few of the procedures in III.3 through III.6 likely apply at the network,
remote access, or internet levels when the controls are important in achieving the
control objectives for relevant assertions for significant accounts.
10.

IV. IT Operations (Optional for Non-Integrated Audits)

1. Backup and Recovery
Control Objective: To determine that the data supporting financial information is
properly backed-up so such data can be accurately and completely recovered if there is a
system outage or data integrity issue.
1.1. Define Test Approach:
1.1.1 Determine process for identifying data to be backed up
1.1.2 Determine that individuals who perform backups are not also
responsible for monitoring them
1.1.3 Select an appropriate sample of back-up activity and test that the
controls over back-ups are operating as expected.
1.1.4 Review the procedures for periodically testing that backups can be
restored.
2. Scheduling (if applicable)
Control Objective: Determine that programs are executed as planned and deviations from
scheduled processing are identified and resolved in a timely manner.
2.1. Define Test Approach:
2.1.1 Determine that only appropriate users have the ability to make
changes to the job schedule and only approved changes are made.
2.1.2 Determine that individuals who program/implement/monitor
scheduling do not have conflicting duties
2.1.3 Test a sample of errors (e.g., abends) from production processing.
For each, determine that an appropriate level of follow-up and resolution
occurred.
3. Problem and Incident Management (if applicable)
Control Objective: Determine that IT operations problems or incidents are identified,
resolved, reviewed, and analyzed in a timely manner.
3.1. Define Test Approach:
3.1.1 Walkthrough of this control in conjunction with the testing
performed in step IV.2 should be sufficient.

10

Appendix A Primary Control Procedures

Index ITGC Primary Control Procedures

II
1

III
1
2

Manage Change
Obtain a complete list of changes to the relevant components of the IT environment
since the beginning of the audit period through the date of our test. Select an
appropriate sample of changes from the list and determine that the change was
appropriately authorized.
Obtain a complete list of changes to the relevant components of the IT environment
since the beginning of the audit period through the date of our test. Select an
appropriate sample of changes from the list and determine that the change was
appropriately tested.
Obtain a complete list of changes to the relevant components of the IT environment
since the beginning of the audit period through the date of our test. Select an
appropriate sample of changes from the list and determine that the change was
appropriately approved.
Obtain sufficient evidence to determine that the change process is monitored on a
regular basis (e.g. steering committee, management review of changes to
production).
Determine, both organizationally and logically, that different individuals within the
organization perform the following duties:
Request/approve program development or program change
Program the development or change
Move programs in and out of production
Monitor program development and changes
Logical Access
Determine that the general system security settings are appropriate based on
minimum guidelines defined in our technology-specific guidance, if available
(EYMercury is a web-based tool designed to create customized technical workplans).
For each relevant technical component of the logical access path, obtain evidence of
the organizations settings for the following security configurations:
Minimum password length
Initial log-on uses a one time password
Password composition (e.g., alpha/numeric characters, not words in
dictionary)
Frequency of forced password changes
The number of unsuccessful log on attempts allowed before lockout
Ability of users to assign their own passwords
Number of passwords that must be used prior to using a password again
Idle session time out
Logging of unsuccessful login attempts
Obtain a list of privileged user rights for the relevant technical components of the
logical access path that support the key controls (e.g., users with full system access
or access to security administration functionality). Determine that it is complete.
Review the lists of users with privileged rights and determine if the number of users
appears appropriate. Based on the volume of users and the critical nature of this
control, develop a test to determine if the users privileged access is appropriate
based on their job description/function (this listing should include the review of

11

Index ITGC Primary Control Procedures

sensitive system accounts).
4
Identify and obtain a list of resources (e.g., datasets, security, accounting schema,
master files, transactional data), including utilities (e.g., SQL Plus, DFU, SuperZap)
associated with the relevant applications that could affect the accuracy of the
financial statements if not appropriately secured. Determine that access to the
resource(s) is appropriate.
5
Obtain the periodic user validation report(s) and select an appropriate sample to
determine that the users access had been appropriately validated 1. Test the
following:
New User Set-up
Obtain a list of new users added during the period under audit and determine
that it is complete. Select an appropriate sample and determine that there was
appropriate approval granting the new user access and that the users access
was appropriately established based on his/her job function and the new user
request form.
Monitoring of User Access
Identify relevant monitoring controls and test that the controls functioned as
expected over the audit period. These controls might include:
Violation or violation attempts reporting and review
Review of logs (i.e. surrounding privileged user access)
Determine that system settings are appropriately configured to capture
key system events and activities.
6

IV
1

Obtain a list of employees with access to the data center, determine it is complete,
and review for appropriateness. Confirm that controls are in place to restrict access
to only those individuals.
Obtain sufficient evidence to determine that the logical access process is monitored
on a regular basis (e.g., monitoring compliance with established logical access
control procedures, periodic review of logical access policies and procedures).
Determine, both organizationally and logically, that different individuals/system
resources perform the following duties related granting user access:

Requesting access, approving access, setting up access, and monitoring

access violations/violation attempts

Performing rights of a privileged user and monitoring use of a privileged

user

IT Operations (Optional for Non-Integrated Audits)

Determine process for identifying data to be backed up. Determine that individuals
who perform backups are not also responsible for monitoring them. Select an
appropriate sample of back-up activity and test that the ITGCs over back-ups are
operating as expected. Review the procedures for periodically testing that backups
can be restored.
Determine that only appropriate users have the ability to make changes to the job
schedule and only approved changes are made. Determine that individuals who
program/implement/monitor scheduling do not have conflicting duties. Test a
sample of errors from production processing. For each, determine that an
appropriate level of follow-up and resolution occurred.
Obtain sufficient evidence to determine that IT operations problems or incidents are

1 If the client does not have a strong periodic user validation process, test the termination
process, user transfer process, and current users in addition to testing new user set-up and,
monitoring of user access.

12

Index ITGC Primary Control Procedures

identified, resolved, reviewed and analyzed in a timely manner.

13