Identify, Evaluate and Document

IT General Controls (ITGCs)

Agenda

► Introduction
► IT Processes
Manage change
Manage access
Manage IT operations
► Evaluating ITGCs
► Information produced by entity
► Responding to ineffective ITGCs

Page 2
IT Controls

► IT Entity Level Controls

► IT General Controls

► Transaction-level Controls (Application

Controls or Business Process Controls)

Page 35
IT entity level controls

CONTROL ENVIRONMENT
IT Organization, IT Strategic Planning,
RISK ASSESSMENT
The entity’s identification, analysis and management
of relevant risks

CONTROL ACTIVITIES
IT Policies, Guidelines, Standards and Procedures

INFORMATION & COMMUNICATION

The entity’s identification, capture and exchange of
information
MONITORING ACTIVITIES
IT Governance

Source: COSO 2013

Page 36
 Controls in an IT Environment

IT Entity Level Controls

Support the continued functioning of

IT General Controls automated aspects of prevent controls and
detect and correct controls
Type of control

Transaction-level Controls

Manual controls
Manual

IT-dependent manual controls

Automated
Application controls

Prevent Detect and correct

Misstatement in the financial statements

Objective of control

Page 37
IT general controls

► Testing an application control or IT-dependent manual

control normally gives assurance that the control operated
effectively at that point in time.

► But how do we gain assurance that these controls

operated in a consistent and reliable fashion over the
financial year, or that they will continue to operate going
forward?

► How do we gain assurance on the integrity of Information

Produced by the Entity (IPE)?

Page 38
IT general controls – definition

Pervasive controls over the IT environment that support the

continued functioning of application and IT-dependent
manual controls and integrity of electronic audit evidence.

Page 39
IT processes covered in FAIT

►Manage change
► Manage access
► Manage IT operations

Page 40
Manage change ITGCs

Only authorized, tested and approved changes

are made to components of the technology
infrastructure.

Page 41
Manage change

► Determine components of IT Infrastructure in scope:

► Application systems (including system interfaces)
► Database Management System
► Operating Systems
► Network systems

Page 42
Identifying types of change

► What does manage changes mean?

► Application Software
► New system implementation
► Changes to existing system
► Addition of new functionality to an existing system
► New or changed interfaces connecting applications or systems
► Emergency fixes

► System Software
► New system software implementation
► System software changes
► Software upgrades
► Software patches
► Technical changes to the database

Page 43
Focus of external financial audit

► Why are system changes significant to the audit?

► Changes may affect operation of automated controls (application
or IT dependent manual) and could impact on the overall audit
strategy
► Accuracy of processing
► Accuracy/integrity of data
► Consistency of accurate processing over time
► Changes in application systems may directly introduce errors in
data that impact Financial Statements and/or electronic audit
evidence
► Changes in system software could result in issues related to data
confidentiality, integrity and availability

Page 44
What are the risks?

► Authorization
► Inappropriate system changes may be requested
► Impact of requested change on other business units may not have
been considered
► System change may be made to perpetrate fraud
► Testing
► Undetected and uncorrected program bugs
► System change does not meet users’ requirements
► Processing errors may be introduced
► Leads to problems in other parts of the system
► Unauthorized code introduced may not detected

Page 45
Manage changes:
Recommended controls

► Changes are authorized

► Changes are tested
► Changes are approved
► Changes are monitored
► Segregation of incompatible duties exists within the
manage change environment

Page 46
Authorization - What are the risks?

► Authorization
► Inappropriate system changes may be requested

► Impact of requested change may not have been

considered

► Change may be made to perpetrate fraud

Page 47
Change are authorized

MC1: Changes are

authorized

Post-
Initiation Implementation

“DEV” “TEST” “STAGE” “PROD”

Program change environments

Ø Business-initiated requests Some authorization considerations

Ø IT-initiated requests Ø Business need
Ø Emergency fixes Ø Impact of change on business and other systems
Ø Effort and cost required

Page 48
Testing - What are the risks?

► Testing
► Undetected and uncorrected program bugs
► System change may not meet users’
requirements
► Processing errors may be introduced
► May leads to problems in other modules/
systems
► Unauthorized code introduced may not
detected

Page 49
Changes are tested

Changes are tested

Changes are
authorized

Post-
Initiation Implementation

“DEV” “TEST” “STAGE” “PROD”

Program change environments

Testing Application Systems Considerations

Ø Unit/program testing Ø Thoroughness of test conditions/ scripts
Ø System integration testing and scope of tests
Ø Documentation of exceptions and results
Ø User Acceptance Testing
Ø Correction of all bugs/exceptions
Ø Performed in test environment
Testing System Software Ø Sign-offs
Page 50
Approval - What are the risks?

► Approval
► Premature migration of changed programs to production
environment
► Not all processing components (e.g., other modules, system
interfaces, system software) have been tested
► Not all exceptions have been corrected.

► Inappropriate or unauthorized program version may be migrated to

production

► Data for conversion may not have been fully cleansed or lack
integrity

► Users not properly trained to use the system

► System documentation not accurate, updated or consistent with

actual implementation.

Page 51
Changes are approved

Changes are
Changes are tested approved

Changes are
authorized

Post-
Initiation Implementation

“DEV” “TEST” “STAGE” “PROD”

Program change environments

Approval Considerations Ø System deployment strategies

Ø Data preparation and migration Ø Pilot
Ø User training Ø Parallel operation
Ø Documentation ØWave rollout
Ø Quality review Ø Big Bang rollout
Ø System transport to production
Page 52
Monitoring – What risks are addressed?

► Monitoring
► Significant delays in implementation of new or changed system
may not be addressed.

► Unauthorized transport of programs to production environment

may not be detected

► Expected benefits from system implementation may not be

achieved.

► New issues related to implemented system may not be identified

and addressed.

Page 53
Changes are monitored

Changes are
Changes are tested approved
Changes are
Changes are monitored
authorized

Post-
Initiation Implementation

“DEV” “TEST” “STAGE” “PROD”

Program change environments

Ø Status monitoring of change requests

Ø Post-review of transport/migration activities to production
Ø Independent post-implementation review
Page 54
Segregation of Duties

Changes are
Changes are tested approved
Changes are
Changes are monitored
authorized

Post-
Initiation Implementation

“DEV” “TEST” “STAGE” “PROD”

Program change environments

Segregation of duties

Authorization/Approval Development Migration QA/IA

Ø Requester vs. approver
Ø Programmers cannot migrate changes to PROD environment
Ø Person migrating changes does not have change development
responsibilities
Ø Person monitoring changes has no development responsibilities
Page 55
IT processes covered in FAIT

► Manage change

►Manage access
► Manage IT operations

Page 56
Manage access ITGCs

Software-based safeguards to ensure that only authorized

users are able to perform actions or access Information
Assets (i.e., hardware, software and data) based on
business need.

Page 57
What are the risks related to manage
access?
► Confidential/proprietary information may be disclosed to
unauthorized persons

► Integrity of data, applications, and other IT resources may

be impaired.

► IT operations may be disrupted or data, applications and

other IT resources may be destroyed.

Page 58
Manage access ITGCs
Guiding Principles in Implementing IT Security
► Principle of Least Privilege - giving a person or a process the minimal
authority necessary to accomplish the job or task

► Data classification - the level of security controls needed to protect

data is dependent on security classification (e.g., confidential, private,
public, or unclassified)

► Separation of Duties - dividing a task and authority for a specific

business process among multiple users to prevent exploitation and fraud
by allowing two people to complete a task.

► Defense in Depth is a concept used to describe layers of defense

strategies

Page 59
Manage access process components

► Users
Logical Security
► System Owners
► Security Officer ► Network security*
► OS security
► System People Technology
custodians/ ► Application security*
security ► DB security
administrators ► Security devices
Policies and Procedures

► Security Policy & Guidelines ► Authentication

► Security Baseline Standards
► Access rights
► Data Classification
► Security Awareness Programs ► Authority levels
► User Access Management
► System Configuration Maintenance
► Security Monitoring

Page 60
Understand the logical access path

► The logical (virtual) pathway by which

users gain access to software and data
► The logical access path often includes
multiple layers of hardware and User
software security which users must
successfully pass through to gain
access to IT resources/assets (applying
Defense in Depth principle)
Data
► Understanding of logical access path
helps us identify technologies that need
to be examined and tested.

Page 61
Logical access path
Business
users IT users

Central
DB Buffer

Central DB

Page 62
Manage access:
Recommended controls
► General system security settings are appropriate. (T, PP)
► Password settings are appropriate.(T, PP)
► Access to privileged IT functions is limited to appropriate individuals.(T,
PP)
► Access to system resources and utilities is limited to appropriate
individuals. (T, PP)
► User access is authorized and appropriately established. (T,P, PP)
► Physical access to computer hardware is limited to appropriate
individuals.
► Logical access process is monitored. (T, P)
► Segregation of incompatible duties exists within logical access
environment.(P)

Page 63
General security settings

► Security Mode
► Disable
► Enable – warning vs. active mode
► Trust mode
► Audit logging – enabled? What are logged?
► Default accounts and passwords – there are no default accounts
with default passwords or default accounts are renamed and
passwords have been changed
► Generic accounts – access is limited or none

The EY Mercury work plans provide sufficient coverage for this control. For a walkthrough, we
document any baselines, policies, or inquiry with the client and note that these settings will be
tested using EY Mercury workplans.

Page 64
Password settings

Security settings for user authentication

► Minimum password length (e.g., 8 characters)
► Password composition (e.g., alpha/numeric characters, not words in
dictionary)
► Frequency of Forced Password change (e.g., 90 days)
► Number of passwords that must be used prior to using a password
again (e.g., 8 unique passwords)
► Number of unsuccessful log on attempts allowed before lockout (e.g.,
3 attempts)
► Unlocking of blocked accounts (e.g., manually performed by security
administrator)
► Idle session time out (e.g., 10 minutes)
► Logging of unsuccessful login attempts

Page 65
Privileged Users

Who are Privileged users:

► Users with full system access rights (e.g., system administrator, DB
administrator)
► Users with access rights to security administration functionality

► Users with access to sensitive system functions (e.g., sensitive

utilities and tools, ACCESS ALL)

► Testing should cover privileged user rights for all relevant technical
components of the logical access path that support the key controls.
► Determine if the users’ privileged access rights are appropriate based
on their job responsibility
► Determine if the number of privileged users appears appropriate.
► Determine how system activities of privileged users are controlled
(e.g, logged, monitored?)

Page 66
System resources and utilities

► Identify and obtain a list of critical/sensitive resources,

including data modification utilities associated with the
relevant applications that could affect the integrity of the
financial data if not appropriately secured.

Resources Utilities
Databases SQL Plus
Security files SuperZap
System DFU
configuration/
parameters
System logs
► Determine that access rights granted to these resource
sand utilities are appropriate.
Page 67
User Access Management
► New hires & transfers
► Users are granted access rights on the basis of an approved request. and
limited only to access required to carryout their job responsibilities.
► Unique user ID is assigned to each user. No group IDs exist and shared
by multiple users.
► Changes to users’ access should be approved and their role re-evaluated
to prevent “role creep” which is caused by incremental additions to access
over time, causing segregation of duties risks.

► Periodic review
► Users’ access rights should be periodically reviewed to ensure that they
remain appropriate..
► The review should cover access rights to all elements of the IT
infrastructure (i.e., computing, networking, databases).
► Frequency of the review should be assessed to determine the design
effectiveness.

Page 68
User Access Management – cont’d
► Terminations and resignations
► Access rights should be promptly disabled and/or removed once users
leave the company.
► If there is no or ineffective periodic review, extended testing of
terminations and resignations is performed

► Monitoring of User Access:

► Access violations are reported and investigated.
► Logged access (e.g., privilege user activities) are reviewed for propriety
► Logged intrusions are investigated and corrective action are taken

NOTE: Review and testing should cover UAM processes for BOTH
INTERNAL AND EXTERNAL SYSTEM USERS.

Page 69
Physical security
Physical access to the data center
► All access points (doors and windows) are secured
► Guards
► Access cards , biometrics
► Issuance and retrieval of security devices (e.g., access cards, tokens) are
properly controlled
► Determine if the access rights granted are appropriate based on their job
description/function
► Sensitive areas are monitored (e.g., by closed circuit television (CCTV)

Environmental controls in the data center, existence of:

► HVAC (humidity, ventilation, aircondition)

► Uninterruptible power supply (UPS) and generator sets

► Server racks

► Secured cabling

Page 70
Monitoring
Related to assessing the system security on a recurring
basis.
► Internal review of compliance with security policies (e.g.
Vulnerability Assessment, Attack and Penetration testing,
Internal IT Audit.)
► Periodic review of security policies, guidelines, baseline
standards and procedures
► Security patch management
► Anti-virus definition updates

Page 71
Segregation of duties
► For segregation of duties, the person setting-up the
access should be different from the person requesting,
approving, and monitoring.

Security Monitoring/
Request Authorize
administration Audit
System System/ security
Security office/
User administrator/
Internal audit
owner custodian

Page 72
IT processes covered in FAIT

► Manage change
► Manage access

►Manage IT
operations

Page 73
Manage IT operations

• Backup and Recovery - Data supporting financial information is

appropriately backed up so such data can be accurately and
completely recovered if there is a system outage or data integrity
issue

• Job Scheduling - Programs are executed as planned and

deviations from scheduled processing are identified and resolved in
a timely manner.

• Problem and Incident Management - IT operations problems

or incidents are identified, resolved, reviewed and analyzed in a
timely manner.

Page 74
Manage IT operations

► PCPs:
► Financial data has been backed up and is recoverable

► Deviations from scheduled processing are identified and resolved

► IT operations problems or incidents are identified, resolved,

reviewed and analyzed

Page 75
Back-up and recovery
► Vital information assets for ► Degree of backup:
back up: ► Differential (from last backup)
► Data ► Incremental (from full backup)
► Databases structures ► Full
► Applications (with ► Frequency of backups:
configurations) ► Daily
► System software with
► Weekly
configurations
► Monthly
► Method of backup
► Offsiting of back up files
► Physical (e.g., tapes, discs)
► Server replication/mirroring
► Testing of back up files
► Manual vs scheduled job ► Backup site

Page 76
Job scheduling

► Job scheduling applies to batch processing at data center

► Potential risks
► Unauthorized runs
► Erroneous files used
► Erroneous job sequence
► Aborted runs/job failures

► Scheduling
► Ability to create/change/delete job schedules should be restricted
► Monitoring
► Independent post review of job executions to ensure successful
completion of runs and note aborted runs, job failures, changes in
job schedule.
► Scheduled job failures should be handled as part of the incident
management process for successful resolution
Page 77
Problem and incident management

► Understand process and roles/responsibilities for

reporting, recording, escalating and resolving problems
and incidences.
► Obtain sufficient evidence to determine that problems or
incidents (e.g., from computer operations, users) are
identified, referred to appropriate group, escalated,
monitored and analyzed in a timely manner.
► Determine how they monitor and report incidences
► Inquire if there have been any major problems or incidents during
our initial meetings and during year-end update procedures.

Page 78
Evaluating ITGCs

► Objective: Evaluate the design and operating

effectiveness of controls.
► Design effectiveness:
► Identify and document IT general controls
► Walkthrough IT general controls
► Evaluate controls and identify design deficiencies
► Operational effectiveness:
► Test controls
► Evaluate controls and identify operational deficiencies
► Overall Evaluation of ITGC
► Responding to ineffective ITGC

Page 79
Information Produced by Entity

Information Produced by the Entity (IPE) is any information created by the entity using the
entity’s IT applications, end user computing (EUC) tools or other means (including
manually prepared information).

The concepts
It is used by related to IPE
management in We use IPE as a We use IPE as also apply to
population from audit evidence information
the performance produced by
of controls we which we select for substantive service
are testing items to test tests organizations

The risks related to IPE are applicable to all audit procedures, including ITGC and
application control testing.

Page 79
Risks related to the use of IPE

► Five risks to consider for IPE

1) The data processed by the IT application from which the IPE is
produced is not complete or accurate
2) The data extracted from the IT application into the IPE is not the
intended data or is not complete
3) The computations or categorizations performed in the creation of
the IPE from the IT application are inaccurate
4) The data output from the IT application to the EUC tool is modified
or lost in the transfer
5) Information added or changed (including computations and
categorizations) using the EUC tool is incomplete, inaccurate or
inappropriate

Page 79
Considerations in Testing ITGCs
Centralized vs. Decentralized

► Centralized vs. Decentralized

► Aggregation of ITGC testing to reduce the number of
samples
► Situations where different IT applications have similar ITGCs
(e.g., common Manage Change ITGCs)
► Consider centralization and commonality of policies/procedures,
personnel, process and technology
► Outsourcing of IT Functions
► Establishing the population for sample selection
► Manage Change
► Logical Access – UAM
► Other ITGCs

Page 80
Effective IT general controls

Overall, when ITGCs are operating as intended, they:

► Do provide a basis for reliance that the systems are
operating consistently over time and are expected to
continue to operate going forward

► Do Not provide the basis for reliance that data processing

and reports are correct. We will need to also assess
transaction level controls (that include application and
ITDM controls) over SCOTs to obtain such reliance.

► Do provide basis for Test of One of Application Controls

Page 81
Ineffective ITGCs

What are the implications of ineffective IT general controls ?

► Application controls and IT-dependent user controls may not have
operated effectively over period under audit.

► Integrity of Information Produced by the Entity (IPE) and other

financial information may not be assured.

Page 82
Ineffective ITGCs

► Responding to ineffective ITGCs:

► We assess the effect of the ITGCs on our audit strategy.
► Possible procedures:
► Identify compensating ITGCs

Page 83
Compensating controls

► Examples of compensating IT controls can include:

Nature of exception Compensating control
No formal authorization of Transport of program changes to production
program changes in place. environment require the prior completion of UAT
and formal approval of business head and
Operations head.
Programmers are responsible for All transport activities are logged and post-
transporting program changes to reviewed by IT head.
the production environment
Non performance of periodic user Timely notification and revocation of access rights
access review of resigning/terminated/transferred employees.
Post review by Security Office of all logged
updates made by system custodian to user access
rights
► Compensating controls can be important for smaller
organizations or functions with limited segregation of
duties.
Page 84
Ineffective ITGCs

► Responding to ineffective ITGCs:

► We assess the effect of the ITGCs on our audit strategy.
► Possible procedures:
► Identify compensating ITGCs
► Perform substantive testing of ITGCs

Page 85
Substantive testing in the ITGC level

If one or more ITGCs are evaluated as ineffective, we may

be able to perform other substantive procedures to
support an effective evaluation regarding the continued
functioning of the affected application and ITDM controls and
reliance on sources of EAE.
Nature of exception Substantive procedures
Unauthorized personnel have Obtain and review a system listing of program
access rights to make program changes that occurred during the audit period
changes and perform procedures to obtain reasonable
assurance that only authorized changes were
made.
IT is not promptly notified on Obtain a list of all resigned/terminated
resignations/terminations to employees during the period under audit and
allow prompt revocation of verify if their user IDs have been disabled and
access rights. access rights revoked. Check if these users
accessed the system after their resignation/
termination date

Page 86
Ineffective ITGCs

► Responding to ineffective ITGCs:

► We assess the effect of the ITGCs on our audit strategy.
► Possible procedures:
► Identify compensating ITGCs
► Perform substantive testing of ITGCs
► Identify compensating/mitigating transaction-level
controls
► Perform direct and extended (not test of one) testing of
application and ITDM controls and EAEs

Page 87
Evaluating ITGCs with rationale indicators

IT-dependent
Manual or
application
R Control evaluation
control
Effective evaluation

Aggregate
ITGC evaluation for ITDM ITGC
or application control evaluation
Not Support

IT
processes
Manage change Logical access Other ITGCs evaluations
Ineffective Effective Effective

ITGC ITGC ITGC ITGC ITGC ITGC

ITGC operating
Effective Ineffective Effective Effective Effective Effective evaluations

Rationale required if higher layer

ITGC ITGC ITGC evaluation is effective and lower
Effective Effective Effective R
layer contains an Ineffective
evaluation

Page 88