Professional Documents
Culture Documents
ITGC Primary Control Testing Procedures (1) With Notes
ITGC Primary Control Testing Procedures (1) With Notes
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).
Sample Sizes
For guidance on appropriate sample sizes refer to EY GAM Procedure 7.1, Section titled
Minimum Extent of Testing.
1
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
2
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.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,
3
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.)
4
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)
5
III. Logical Access
1. 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
6
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).
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:
7
6.1.1 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)
8
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.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).
10.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.
9
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.
10
Appendix A Primary Control Procedures
II Manage Change
Obtain a complete list of changes to the relevant components of the IT environment
1 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
2 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
3 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
4 regular basis (e.g. steering committee, management review of changes to
production).
Determine, both organizationally and logically, that different individuals within the
5 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
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 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.
7 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).
8 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
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