2005 Itgc Example - Racf

Midwest IRM Support Team
Audit of Internal Control

2005 ITGC Example - RACF
Purpose: The purpose of this document is to provided engagement teams with example audit procedures related to RACF. This
document is to be considered as guidance only. It is not to be interpreted as a minimum or maximum standard and may not be
applicable to all client environments. The engagement team must consider the specifics of their engagement and use professional
judgment in determining which procedures to perform.
Updates/Suggestions: Please e-mail any updates or suggestions for improvement to James Kellogg (jkellogg@kpmg.com)
Version Revision Date Nature of Change Revised By Reviewed By Posted Date

1.1 August 2005 Creation of Version 1 James Kellogg
1
IT GENERAL CONTROLS DOCUMENT
– INTEGRATED - US
(07/05)
Purpose
The purpose of this working paper is to document our understanding of IT general controls (ITGC),
our assessment of the effectiveness of the IT general controls and our tests of controls.
This working paper also documents our understanding and evaluation of management’s
documentation of IT general controls, including our evaluation of management’s process for
determining which controls are tested and process for evaluating the design and operating
effectiveness of the IT general controls.
This working paper should be completed for each location where IT processing of key
financial reporting data occurs. Certain areas of this working paper may not be applicable for
all locations. In the table below we identify the location being tested and the relevant
applications hosted there.
Location subject to testing:
1.
Relevant applications:
2.
Contents
The working paper is divided into the following sections:
Instructions
Walkthrough
IT General Controls
I. Access to Programs and Data
II. Program Changes
III. Program Development
IV. Computer Operations
V. End-user Computing
Appendix
2
– INTEGRATED - US
(07/05)
Applicability
Completion of this working paper is required for all engagements requiring both a financial
statement audit and an audit of internal control over financial reporting when IT applications are used
in a process affecting a significant account at a location, unless the significant account is immaterial
at that location. Certain sections of this working paper may not be applicable and are marked as such
by the engagement team and not deleted.
This integrated audit working paper is intended to facilitate performance of an integrated audit and
document compliance with applicable KPMG policies and PCAOB standards. Engagement teams
must document performance of all procedures included herein.
Prepared by: Date:
Reviewed by: Date:
3
– INTEGRATED - US
(07/05)
Instructions
General
We document management’s controls applicable to EACH audit objective. This documentation in

this section can come directly from management’s documentation or can be a relevant summary
of management’s documentation. We often list multiple controls for each audit objective and
ensure that the controls listed sufficiently address all relevant financial statement assertions of the
audit objective. The audit team should identify sufficient controls to achieve the audit objective, and
perform tests of design (TOD) and tests of operating effectiveness (TOE) on those controls.
Additional rows are added to the input tables to include additional controls. Certain audit objectives
may not be relevant to all client situations. The engagement team should document the rationale for
excluding any audit objective from the ITGC Document.
In the event that the client operates from multiple locations, we will first need to assess which
locations house/utilize applications that process major classes of transactions or significant accounts.
Then we will determine which IT general controls are applicable in each of these locations. If more
than one IT general control process exists in a given category (e.g., two change management
processes exist, each for a different application or data center), each should be documented in
separate ITGC documents. IT general controls, by nature, are not limited to individual applications.
A single IT general control may relate to multiple in-scope applications.
Integrated Audit
The purpose of an integrated audit is to obtain sufficient appropriate audit evidence to support our
opinions on both the financial statements (FSA) and internal control over financial reporting
(ICOFR).The nature, timing, and extent of our procedures may vary based on the nature of the audit:
n ICOFR audit:
 IT General Controls Scope – we document IT general controls for each application that
processes major classes of transactions or significant accounts, and
 Results of Testing – the results of our tests support our opinion as it relates to the
effectiveness of the company’s internal control over financial reporting as of the financial
statement year-end.
n FSA:
 IT General Controls Scope – we document IT general controls for each application where we
are placing reliance on application controls or system generated reports, and
 Results of Testing – the results of our tests support our opinion as it relates to the
effectiveness of the company’s internal control during the period under audit.
Walkthrough
Walkthroughs are required for every audit objective. To the extent that IT general controls are
process-based (e.g., change control procedures, access authorization approvals, problem management
approvals) and affect an application that processes a major class of transactions, such controls should
4
– INTEGRATED - US
(07/05)
be documented in a walkthrough. We do not use the work of others for the performance of
walkthroughs. Walkthroughs provide us with evidence to:
n confirm our understanding of the activities documented
n confirm that we have identified all of the relevant risk points
n confirm our understanding of the design of controls that mitigate risk points (including those
related to the prevention or detection of fraud)
n evaluate the effectiveness of the design of controls, and
n confirm whether controls have been implemented.
A walkthrough requires us to trace a single transaction through each step of the company’s
information system, including those controls that we intend to evaluate. While performing a
walkthrough, we evaluate the quality of the evidence obtained and perform procedures that produce a
level of evidence consistent with the objectives listed above. Rather than reviewing copies of
documents and making inquiries of a single person at the company, we should follow the process
flow of actual transactions using the same documents and information technology that company
personnel use and make inquiries of relevant personnel involved in significant aspects of the process
or controls. To corroborate information at various points in the walkthrough, we might ask personnel
to describe their understanding of the previous and succeeding processing or control activities and to
demonstrate what they do. In addition, inquiries should include follow-up questions that could help
identify the abuse of controls or indicators of fraud.
Examples of follow-up inquiries include asking personnel:
n what they do when they find an error or what they are looking for to determine if there is an error
(rather than simply asking them if they perform listed procedures and controls); what kind of
errors they have found; what happened as a result of finding the errors, and how the errors were
resolved. If the person being interviewed has never found an error, we should evaluate whether
that is due to good preventive controls or whether the individual performing the control lacks the
necessary skills, and
n whether they have never been asked to override the process or controls, and if so, to describe the
situation, why it occurred, and what happened.
We may be able to evaluate the design effectiveness of controls while performing our walkthroughs.
The design effectiveness for the specific controls to be tested is documented within the Audit
Procedure Performed and Results section of this document.
If changes occurred in the process activities or flow of transactions subsequent to our walkthrough,
we perform additional walkthrough procedures over the portion of the process involving the change.
We can often gain an understanding of the transaction flow, identify and understand controls, and
conduct the walkthrough simultaneously.
5
– INTEGRATED - US
(07/05)
Management’s assessment
Document our evaluation of management’s assessment for the related audit objective. Specifically,
address the following key considerations:
n does management’s documentation include the results of management’s testing and evaluation
n were procedures sufficient to assess design and operating effectiveness:

 consider the nature, including technique, used by management when performing tests of
controls
 consider the timing of management’s procedures. Were tests of controls performed over a
period of time that is adequate to determine that the controls are operating effectively as of
the testing date? Has management performed procedures to update testing performed at an
interim period to ensure that controls are still operating effective at period-end, and
 consider the extent of management’s procedures. Has management assessed the nature of the
control, the frequency of operation of the control and the importance of the control?
n were findings supported based on testing performed, and
n were exceptions/deficiencies adequately documented and followed-up? Where corrective action

has been taken to address a previously identified deficiency, has management reassessed the
design and operating effectiveness of the new or fixed controls and has the control been operating
over a period of time that is adequate to support the reassessment?
Audit procedures performed and results:
In this section, we document the procedures to be performed to conclude on the operating

effectiveness of the controls identified, including a specific description of the nature, timing and
extent of procedures to be performed.
Inquiry alone will not usually provide sufficient appropriate audit evidence to support a conclusion
about the effectiveness of a control. We focus on combinations of controls, in addition to specific
controls in isolation, when assessing whether the objectives of the control criteria have been achieved.
Also in this section of the working paper, we conclude on the design and operating effectiveness of
the controls over this audit objective and document any deficiencies noted. These deficiencies are
transferred to the Summary of Internal Control Deficiencies – Integrated (SICD). Weaknesses in
pervasive controls cause the auditor to alter the nature, timing, or extent of tests of operating
effectiveness that otherwise would have been performed. Document the impact of any deficiencies
on the planned testing of operating effectiveness of other controls.
6
– INTEGRATED - US
(07/05)
Roll forward
When control operating effectiveness is tested at an interim date, the auditor obtains additional
evidence concerning the operation of the control for the remaining period up to and including the “as
of” date. For all IT general controls tested at an interim date, procedures (i.e., additional testing) must
be performed to roll forward the interim testing to period-end. The nature of the procedures may vary
based on the length of the roll forward period and the nature of the control. Procedures for longer roll
forward periods may include the selection of additional test items and inquiry. Procedures for shorter
roll forward periods may primarily include inquiry, but may also be supplemented with other testing
as appropriate. In accordance with Firm guidelines, IT general controls must always be tested in the
roll forward period.
Roll forward procedures performed to test control operating effectiveness may provide additional
evidence of a control’s operating effectiveness on the “as of” date only when such procedures are
performed during the period beginning no earlier than three months prior to the “as of” date.
Accordingly, the roll forward period may not exceed three months.
Documentation of the nature, timing and extent of audit procedures performed during the roll forward
period, up to and including the “as of” date, including the related findings and conclusions, is
addressed in the table Audit Procedures Performed and Results presented in each audit objective
section of this document.
We consider inquiring about the following matters during the roll forward period that may impact
conclusions reached regarding control operating effectiveness at the interim testing date:
n new or significant modifications to client IT systems
n significant modifications to existing processes, including process reengineering
n significant new positions or changes in job roles or responsibilities, including employee turnover
n new or evolving industry and/or company-specific risks
n changes in accounting principles or financial reporting requirements
n indicators of fraudulent activity or errors, and
n changes in the client’s regulatory environment.
7
– INTEGRATED - US
(07/05)
Walkthroughs
While performing a walkthrough, we evaluate the quality of the evidence obtained and perform
procedures that produce a level of evidence consistent with the audit objectives presented.
We may be able to evaluate the design effectiveness of controls while performing our walkthroughs.
The design effectiveness for the specific controls to be tested is documented within the control matrix
in this document.
If changes occurred in the process activities or flow of transactions subsequent to our walkthrough,
we perform additional walkthrough procedures over the portion of the process involving the change.
We can often gain an understanding of the transaction flow, identify and understand controls, and
conduct the walkthrough simultaneously.
To the extent that IT general controls are activity-based (e.g., change control procedures, access
authorization approvals, problem management approvals) and affect an application that processes a
major class of transactions, such controls should be documented in a walkthrough.
ITGC Areas Walkthrough Performed Performed by/Date/W/P Ref(1)

Access to Program and Data [Y/N]
Program Change [Y/N]
Program Development [Y/N]
Computer Operations [Y/N]
(1)
If a walkthrough is performed, we document who performed the walkthrough, date of performance and
related working paper reference in this column. If no walkthrough is performed, we document the engagement
team’s rationale in this column.
8
– INTEGRATED - US
(07/05)
IT General Controls [IAM3_3_4]

Consider the following guidance for each of the platforms used in the financial reporting process, such as applications, operating systems, and databases.
I.A Audit Objective: Determine that information security is managed to guide consistent implementation of security practices and that users are
aware of the organization's position with regard to information security, as it pertains to financial reporting data
An inconsistent approach to managing information security across the organization may impact the integrity and availability of system resources.
Management sets a clear direction and demonstrates support and commitment to information security through the issuance and maintenance of an
information security policy. The policy is communicated throughout the organization to users in an accessible and understandable form, with the
responsibility for its implementation and compliance shared by all members of management.
Evaluation of Management’s Assessment

Management’s assessment W/P Ref Deficiencies noted by management
Document our evaluation of management’s test of design and operating Description of deficiencies identified by management, if
effectiveness for the related audit objective(1): applicable(2):
Results of management’s assessment: Rationale for not testing, if applicable: 1-
Effective Not Effective 2-
Audit Procedures Performed and Results:

(1)
- Refer to the Instructions Section of this working paper for key considerations.
(2)
- Deficiencies listed here must also be recorded in the SICD working paper.
9
– INTEGRATED - US
(07/05)
Ref Control description Description of TOD Results of TOD and Description of TOE Results of TOE and Done by/
# procedures/Date deficiencies(2) procedures/Date deficiencies(2) Date/W/P ref
1 Expected Key Control # I- Interim procedures: Result: Interim procedures: Result:
A1: The company has See TOE. See TOE. Determine if an
established an RACF Deficiencies, if applicable: RACF information Deficiencies, if
information security See TOE. security function applicable:
function. exists through inquiry
of appropriate Guidance: If critical
personnel and financial data is on the
inspection of relevant RACF and there is no
supporting segregation of duties
documentation (e.g. between
RACF Information operations/finance and
Security Policies and security administration,
Procedures, independence is
Organization Chart, compromised. A lack of
Job Descriptions, segregation of duties
etc.). increases the risk of
potential misuse.
Roll forward Result: Roll forward Result:
procedures: N/A procedures:
N/A N/A Deficiencies, if
Deficiencies, if applicable: applicable:
N/A
(
(
10
– INTEGRATED - US
(07/05)
# procedures/Date deficiencies2) procedures/Date deficiencies2) Date/W/P ref
A2: The company has See TOE. See TOE. Obtain and inspect
adopted a formalized Deficiencies, if applicable: the company’s RACF Deficiencies, if
RACF security policy that See TOE. information security applicable:
provides adequate policies and
guidance for RACF procedures for
information security within adequacy.
the organization. Guidance: Typically,
the following areas
should be addressed:
 Password
controls and
other
configurable
security settings
 User addition,
termination,
transfer process
for setup and
removal and
modifications of
user access
 Third Party
Vendor Setup
(Vendor
Qualification)
 SOD assessment
(i.e. Schedule of
Conflicting
Options, etc)
 Determine/assess
the access
methods (LAN,
Citrix, dial-up,
etc) to the
mainframe
environment.
11
– INTEGRATED - US
(07/05)
procedures: N/A procedures:
N/A N/A Deficiencies, if
Deficiencies, if applicable: applicable
N/A
I.B Audit Objective: Determine that logical and physical access to IT computing resources is appropriately restricted by the implementation of
identification, authentication and authorization mechanisms to reduce the risk of authorized/inappropriate access to the organization’s
relevant financial reporting applications or data
Appropriate controls are in place to ensure that there are sufficient physical and logical security controls in place for applications and systems that support
financial reporting (e.g., network, infrastructure, applications, databases, etc.) to protect against authorized/inappropriate access.

(1)
(2)
12
– INTEGRATED - US
(07/05)

Ref Control description Description of TOD Results of TOD and Description of TOE procedures/Date Results of TOE and Done by/
# procedures/Date deficiencies(2) deficiencies(2) Date/W/P
ref
3 Expected Key Interim procedures: Result: Interim procedures:
Control # I-B2: The Review N/A N/A
organization has documentation / Deficiencies, if
established rules for policies and applicable: 1. Utilizing a user id or user with either
password procedures and/or N/A the SPECIAL or AUDITOR attribute,
management and corroborate with obtain and inspect a hardcopy of the
syntax (E.g. management (specify RACF operating security configuration
minimum password name/title of person(s) report. This can be obtained by using the
length, password interviewed) specific SETROPTS LIST command. Guidance:
change intervals, parameters they have Only users with the SPECIAL attribute
lockout rules, established for RACF. can display all options, except those
password encryption specified by operands restricted to
at network level, Guidance: Much of persons with the AUDITOR attribute.
etc.) for RACF. the resource Users with the AUDITOR attribute can
protection provided by display all options.
RACF is optional. The
RACF SETROPTS 2. Review password security
command is used to configuration parameters on the
dynamically set the SETROPTS LIST report, including:
system-wide RACF
options. All system- 1) Minimum Password Length
wide RACF options, (Guidance: RULEn parameter
except those dealing establishes password syntax rules).
with the logging of
security information, 2) Password Change Interval
can be activated or (Guidance: INTERVAL parameter
deactivated only by specifies the maximum number of days
users with the between 1-254 a user’s password is valid
SPECIAL user before user must change it. The initial
attribute. The RACF default is 30 days. The syntax on report
options controlling the may read “PASSWORD CHANGE
(1) logging of INTERVAL IS X DAYS”).
(
(
13
– INTEGRATED - US
(07/05)
# procedures/Date deficiencies2) deficiencies2) Date/W/P
ref
activities of users with
the SPECIAL or 3) Password complexity (Guidance:
OPERATIONS RULEn parameter establishes password
attributes, (2) RACF syntax rules including e.g. numeric;
command violations, alphanumeric; special characters of
(3) RACF command selected positions in the password.
and RACFDEF macro Report syntax may display RULE #
routine activity, can LENGTH (min, max) combination of
be letters e.g. AANN*** LEGEND A-
activated/deactivated ALPHA, C-CONSONANT,L-
only by users with ALPHANUM,N-NUMERIC,V-VOWEL,W-
AUDITOR attribute. NOVOWEL,*-ANYTHING).
All uses of the RACF
SETROPTS command 4) # of Unsuccessful Attempts Before
are logged to SMF Lockout
records and should be (Guidance: REVOKE / NOREVOKE
reviewed regularly by parameter establishes unsuccessful
appropriate security password verification attempts, allowing
policy by appropriate an installation to specify the number of
security password verification attempts that RACF
administration is allowed to permit before RACF revokes
personnel. the user ID of the user attempting to enter
the system (between 1 and 254). Users
with the SPECIAL attribute have the
authority to remove the REVOKE status.
If the NOREVOKE option is in effect,
unsuccessful password verification
attempts are ignored. Report syntax may
read: “AFTER X CONSECUTIVE
UNSUCCESSFUL PASSWORD
ATTEMPTS, A USER ID WILL BE
REVOKED”).
5) Duration of Lockout – (Guidance:

Inquire of RACF Security Administrator
for proof of lockout duration, if
available).
14
– INTEGRATED - US
(07/05)
ref
6) Audit Log Activation

(Guidance: Evidence of logging may
include one or both of the following: 1)
SECLEVELAUDIT/NOSECLEVELAUDIT
parameter allows users with the
AUDITOR attribute to log all activities
pertaining to particular resources based
on the security level assigned to the
resource using the SECLEVELAUDIT
operand. The logging is performed in
accordance with the audit options defined
in the security level profile protecting the
resource. This option is deactivated with
the NOSECLEVELAUDIT operand, which
is the default. 2)
SECLABELAUDIT/NOSECLABELAUDIT
(Logging activity based on security labels
– Allows users with the AUDITOR
attribute to log all activities pertaining to
particular resources based on the security
label assigned to the resource. The
logging is performed in accordance with
the audit options defined in the security
label profile protecting the resource. This
option is deactivated using the
NOSECLABELAUDIT operand, which is
the default. 3) Ask the Security
Administrator if any other audit/security
logging and to provide evidence).
OPTIONAL – 7) Password History

(Guidance: HISTORY/NOHISTORY
allows an installation to specify the
number of previous passwords to be saved
for each user and compared to the user’s
intended new password. If the user’s
15
– INTEGRATED - US
(07/05)
ref
intended new password matches one of
the previous passwords that has been
saved, RACF will not accept the intended
new password. This option can be
specified using the PASSWORD operand,
the HISTORY operand, and specifying the
number of previous passwords to save
between 1 and 32). If the NOHISTORY
option is in effect, no previous passwords
are saved, which is the default.)
Roll forward Result: Roll forward procedures: Result:
procedures: Guidance: System wide RACF options
Deficiencies, if can be activated or deactivated at any Deficiencies, if
applicable: time, so a 4th quarter re-printout may be applicable
necessary or verification of no changes
made.
16
– INTEGRATED - US
(07/05)
Ref Control description Description of TOD Results of Description of TOE procedures/Date Results of Done by/
# procedures/Date TOD and TOE and Date/W/P ref
deficiencies(2) deficiencies(2)
4 Expected Key Control # I- Interim procedures: Interim procedures: Result:
B4: Powerful RACF Review 1. Reviewed sensitive RACF ids. Determine
system level IDs (e.g. documentation / which users are assigned the SPECIAL or Deficiencies,
security administration ids) policies and procedures AUDITOR user attribute and confirm limited if applicable:
are restricted to a defined and/or corroborate with use / knowledge. If available, review the RACF
set of system management (specify Data Security Monitor Selected User Attribute
administration personnel name/title of person(s) Report or have the RACF Security
based on their job function. interviewed) to confirm Administrator provide some other report.
who has administrative Ascertain with RACF Security Administrator
access to the security whether it is appropriate for these users to have
administration function these capabilities. .
and other special
authorities on the
RACF.
(
(
17
– INTEGRATED - US
(07/05)
deficiencies2) deficiencies2)
2. Review security around RACF database, Result:
Under powerful system where sensitive RACF configuration functions
id section: Deficiencies,
are managed. Determine who is authorized to
Guidance: Use of the if applicable:
RVARY command and access the RACF database and if access is
other installation protected by RACF. Determine what universal
defined passwords access authority (UACC) level has been
needs to be controlled. assigned to the RACF database. One method
The RVARY command of determination is to review the Data Security
can be used to Monitor Selected Data Sets Report to
deactivate RACF and determine all the dataset names for all RACF
switch RACF datasets. primary and back-up data sets and ensure the
Use of this command universal access authority is set to the
requires no special appropriate level and that primary and backup
authority. data sets reside on separate volumes. The
LISTDSD command can be used to list profile
information for all RACF datasets. Review the
access lists and access authorities to determine
which users and groups are authorized to
access the data sets and that the access level is
appropriate. Use the LISTGRP command to
determine the users connected to any groups
authorized to access the RACF data sets and
determine if appropriate. Review the Data
Security Monitor Selected User Attribute
Report to determine which users have been
assigned SPECIAL, OPERATIONS, or
AUDITOR attributes and ascertain for
appropriateness.
Inquire if SMF data is relevant in this
installation. If so, inquire as to who can update
SMF data and determine if appropriate.
Guidance: Unauthorized access to the RACF

database may compromise security. The
access control information about users, groups,
datasets, and other resources are contained on
18
– INTEGRATED - US
(07/05)
deficiencies2) deficiencies2)
3. (Optional, if time budget permits).
Determine how the RVARY command is
controlled and who has access to use the
RVARY command. Corroborate that
knowledge of the RVARY password is
restricted to a minimal # of authorized
individuals and that passwords are regularly
changed. Confirm the default RVARY
password has been changed. RVARY
commands are logged automatically to SMF
records. If available, review the SETROPTS
LIST report to determine that the default
RVARY passwords have been changed. If
available and applicable, inquire about whether
its use is monitored on these reports.
Guidance: Use of the RVARY command and

other installation defined passwords needs to
be controlled. The RVARY command can be
used to deactivate RACF and switch RACF
datasets. Use of this command requires no
special authority.
19
– INTEGRATED - US
(07/05)
B4: Critical datasets are See TOE. See TOE. 1. Identify the sample
properly secured by RACF of sensitive / critical Deficiencies, if
system so that update Deficiencies, if applicable: datasets related to applicable:
capabilities are only See TOE. applications in-scope.
provided to appropriate Obtain the RACF
company personnel. Data Security
Monitor Selected
Data Sets Report or
equivalent evidence
to review the UACC
level assigned to the
sensitive data sets.
Confirm that the
sensitive datasets are
assigned an Universal
Access Authority
(UACC) level of
NONE. Confirm
who is responsible
for determining and
approving and
continually reviewing
UACC levels
assigned.
Use the LISTDSD

and RLIST
commands or
equivalent to print the
profiles for the
datasets being
sampled. Review the
appropriateness of
(
(
20
– INTEGRATED - US
(07/05)
update access with
the Security
Administrator and/or
Business Process
Owner, OR review
evidence showing
appropriate approval
was obtained for the
users and the groups
included in the access
list and the access
authorities assigned
to each and confirm it
is appropriate given
their job
responsibilities.
Guidance: RACF
does not protect
datasets unless they
have been
specifically defined to
RACF or the
“PROTECTALL”
option has been
activated for the
dataset. All resource
profiles including
Data Sets, have a
Universal Access
Authority Level,
which specifies the
access authority level
of a user who is not
specifically included
in the access list in
the resource profile.
21
– INTEGRATED - US
(07/05)
2. (Optional) If the
“Always-Call”
function is not
present on system
and
“PROTECTALL”
option is inactive,
determine that the
RACF indicator for
datasets protected by
general profiles has
been activated.
3. (Optional)
Through inquiry/
observation
determine what
security events are
logged and whether
they are reported,
reviewed and
followed up by
responsible party.
22
– INTEGRATED - US
(07/05)
4. (Optional) With
the assistance of
Security
Administrator,
challenge the
effectiveness of
RACF authorization
by attempting to
access datasets using
a user ID that is not
authorized to access
the datasets. Trace
security violations to
RACF security
report.

procedures: procedures:
Deficiencies, if applicable: Deficiencies, if
N/A applicable
23
– INTEGRATED - US
(07/05)
11 Expected Key Control I- Interim procedures: Result: Interim Procedures: Result:
B11: Security violations
are logged and reviewed Review Deficiencies, if applicable: Inspect logs related to Deficiencies, if
on timely basis for documentation / RACF and Incident applicable:
appropriate action to be policies and procedures Management (e.g.
taken. Alternatively, audit and/or corroborate with Peregrine) problem
log is available. management (specify tickets tickets and
name/title of person(s) inquire with
interviewed) to confirm Management to
that security violations determine that access
are logged and to powerful systems
independently reviewed is restricted to a
on timely basis for defined set of system
appropriate action to be administrators/small
taken. Confirm if group of people to
evidence of review is preserve
retained and how often accountability and
review takes place. that all access is
logged. Corroborate
with management
and inspect security
logs to determine that
effective mechanisms
are in place to log
security activity and
identify potential
violations and
escalate as necessary.
For example,
determined that
access to mainframe
is logged via
DSMON Report and
determine how often
it is reviewed by
RACF Security
(
(
24
– INTEGRATED - US
(07/05)
N/A applicable
B6: Physical access to the
RACF server is properly Review Deficiencies, if applicable: Refer to general Deficiencies, if
restricted documentation / program for data applicable:
policies and procedures center general
and/or corroborate with physical and
management (specify environmental
name/title of person(s) security.
interviewed) to confirm
that physical security
associated with the
mainframe servers are
restricted to appropriate
personnel (e.g. IT).
N/A applicable
(
(
25
– INTEGRATED - US
(07/05)
B6: Physical access to the
RACF server is properly Review Deficiencies, if applicable: Refer to general Deficiencies, if
restricted documentation / program for data applicable:
policies and procedures center general
and/or corroborate with physical and
management (specify environmental
name/title of person(s) security.
interviewed) to confirm
that physical security
associated with the
mainframe servers are
restricted to appropriate
personnel (e.g. IT).
N/A applicable
(
(
26
– INTEGRATED - US
(07/05)
27
– INTEGRATED - US
(07/05)
I.C Audit Objective: Determine that procedures have been established so that user accounts are added, modified and deleted in a timely
manner to reduce the risk of unauthorized/inappropriate access to the organization’s relevant financial reporting applications or data
There are appropriate controls in place to ensure that users are assigned access rights in accordance with their job functions as well as over the process to
request, authorize, establish, issue, modify, suspend and close user accounts and access rights to organizational information systems in a timely manner.


1 Interim procedures: Result: Interim procedures: Result:

applicable:
Deficiencies, if applicable: Deficiencies, if applicable
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section I.C of the General ITGC
Audit Guidance.
(1)
(2)
(
(
28
– INTEGRATED - US
(07/05)
I.D Audit Objective: Determine that effective controls are in place to monitor the maintenance of access rights to the organization’s relevant
financial reporting applications or data
Controls are in place so that management/information owners conduct periodic reviews of access to the organization's financial system resources and
other confidential/critical data, to confirm the appropriateness of these access rights.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section I.D of the General ITGC
Audit Guidance.
(1)
(2)
(
(
29
– INTEGRATED - US
(07/05)
I.E Audit Objective: Determine that controls used to provide appropriate segregation of duties within key processes exist and are followed
Controls are in place to allow for proper segregation of duties and responsibilities for authorizing transactions, recording transactions, and maintaining
custody to prevent individuals from being in a position to both perpetrate and conceal an error or irregularity.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section I.E of the General ITGC
Audit Guidance.
(1)
(2)
(
(
30
– INTEGRATED - US
(07/05)
II. Program Changes
Changes to existing systems/applications are authorized, tested, approved, properly implemented and documented.
II.A Audit Objective: Determine that controls are in place to ensure that any changes to the systems/applications providing control over
financial reporting have been properly authorized by an appropriate level of management
For a company to have an effective program change process in place, system application and infrastructure changes need to be approved and signed off
by an appropriate level of both business and IT management prior to development to ensure that the changes are technically feasible and have considered
financial reporting objectives.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section II.A of the General ITGC
Audit Guidance.
(1)
(2)
(
(
31
– INTEGRATED - US
(07/05)
II.B Audit Objective: Determine that controls are in place to ensure that changes to applications and systems used during the financial
reporting process are tested, validated, and approved prior to being placed into production
There are appropriate controls in place to ensure that changes which are made to the IT systems are tested, validated, and approved prior to
implementation into the production environment. This is to ensure that the changes will meet the user requirements and that the changes will not have a
negative impact on any of the existing controls.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section II.B of the General ITGC
Audit Guidance.
(1)
(2)
(
(
32
– INTEGRATED - US
(07/05)
II.C Audit Objective: Determine that controls are in place to restrict access for migrating changes into the production environment for systems
and applications used during the financial reporting process
Only a limited number of personnel should have access to migrate changes to the production environment to ensure that this process is well controlled
and only tested, authorized, and properly approved changes are migrated into production.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section II.C of the General ITGC
Audit Guidance.
(1)
(2)
(
(
33
– INTEGRATED - US
(07/05)
II.D Audit Objective: Determine that controls are in place to ensure that system and application configuration changes related to financial
reporting are validated, approved and tested as necessary
Configuration settings are a key component of many information systems. Configuration settings frequently can impact the design and/or operating
effectiveness of ICOFR. Generally, these settings are subjected to change control procedures to maintain the integrity of ICOFR provided by information
systems.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section II.D of the General ITGC
Audit Guidance.
(1)
(2)
(
(
34
– INTEGRATED - US
(07/05)
II.E Audit Objective: Determine that controls are in place to appropriately address emergency changes to systems, applications and
infrastructure configuration
Controls are in place to ensure changes requiring immediate implementation are properly handled, allowing for timely change and no impact to systems
and applications related to the financial reporting process.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section II.E of the General ITGC
Audit Guidance.
(1)
(2)
(
(
35
– INTEGRATED - US
(07/05)
New systems/applications being developed or acquired are authorized, tested, approved, properly implemented and documented.
Note: This section refers to the controls in place for the development of new systems/applications or major changes to existing applications (i.e.,
upgrades, conversions and major infrastructure changes). For changes that are made to existing systems, refer to Program Changes Section.
III.A Audit Objective: Determine that management has controls in place to ensure that new program and infrastructure developments and
acquisitions have been approved by an appropriate level of both IT and business management
There is a formal process in place for each new program development or acquisition to be approved and signed off by an appropriate level of business and
IT management to ensure that the development is feasible, integrates with the existing IT infrastructure and business processes, and considers financial
reporting objectives.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section III.A of the General ITGC
Audit Guidance.
(1)
(2)
(
(
36
– INTEGRATED - US
(07/05)
III.B Audit Objective: Determine that management has controls in place to ensure that an adequate program development methodology is in
place and is followed for the development or acquisition of systems/applications used during the financial reporting process
There is a proper, formal program development methodology in place, which guides the process for developing, acquiring, and implementing the IT
systems used during the financial reporting process. This is to ensure that a structured approach is followed for each new program development so that
the potential risks to the financial reporting controls are adequately assessed and mitigated.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section III.B of the General ITGC
Audit Guidance.
(1)
(2)
(
(
37
– INTEGRATED - US
(07/05)
III.C Audit Objective: Determine that controls exist to ensure there is adequate testing for the development or acquisition of
systems/applications used during the financial reporting process and that testing is signed off by both the users at an appropriate level of IT and
business management
Programs and system developments (application and infrastructure) are fully tested in a testing environment prior to implementation to ensure that the
changes that are made will meet users needs, that the controls in place adequately cover the risks to the company and that the new system will be able to
integrate with the company’s existing systems.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section III.C of the General ITGC
Audit Guidance.
(1)
(2)
(
(
38
– INTEGRATED - US
(07/05)
III.D Audit Objective: Determine that there are controls in place to ensure that data migrated to the new application or system used during the
financial reporting process retains its integrity
There are appropriate controls in place to ensure that data are migrated accurately and completely from old to new systems.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section III.D of the General ITGC
Audit Guidance.
(1)
(2)
(
(
39
– INTEGRATED - US
(07/05)
System/application processing is appropriately authorized and scheduled and deviations from scheduled processing are identified and resolved.
IV.A Audit Objective: Determine that management has implemented procedures to ensure accuracy, completeness, and timely processing of
system jobs, including batch jobs and interfaces, for relevant financial reporting applications or data
There should be controls over the design and execution of system jobs, including confirmation that the jobs were completed on time, accurately, and in
the proper order.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section IV.A of the General ITGC
Audit Guidance.
(1)
(2)
(
(
40
– INTEGRATED - US
(07/05)
IV.B Audit Objective: Determine that management has implemented appropriate backup and recovery procedures so that data, transactions
and programs that are necessary for financial reporting can be recovered
There are appropriate controls in place so that all critical data, transactions and programs are backed up on a defined schedule and that the backups are
complete, accurate and can be recovered if needed. A company's business continuity or contingency planning has no effect on the company's current
abilities to initiate, authorize, record, process, or report financial data. Therefore, a company's business continuity or contingency planning is not part of
internal control over financial reporting.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section IV.B of the General ITGC
Audit Guidance.
(1)
(2)
(
(
41
– INTEGRATED - US
(07/05)
IV.C Audit Objective: Determine that effective procedures exist and are followed to periodically test the effectiveness of the restoration process
and the quality of backup media relevant to systems and applications used during the financial reporting process
There should be appropriate controls in place so that backups are tested on a periodic basis to ensure that the backup tapes are not corrupt and can be used
if required. A company's business continuity or contingency planning has no effect on the company's current abilities to initiate, authorize, record,
process, or report financial data. Therefore, a company's business continuity or contingency planning is not part of internal control over financial
reporting.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section IV.C of the General ITGC
Audit Guidance.
(1)
(2)
(
(
42
– INTEGRATED - US
(07/05)
IV.D Audit Objective: Determine that appropriate controls are in place over the backup media for systems and applications used during the
financial reporting process, including that only authorized people have access to the tapes and tape-storage
There are appropriate controls in place to ensure that the backup media is stored in a secure location that only authorized people have access to it. This is
to mitigate the risk of backup media being damaged or of unauthorized users gaining access to the sensitive information contained thereon.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section IV.D of the General ITGC
Audit Guidance.
(1)
(2)
(
(
43
– INTEGRATED - US
(07/05)
IV.E Audit Objective: Determine that management has defined and implemented problem management procedures to record, analyze, and
resolve incidents, problems, and errors for systems and applications used during the financial reporting process in a timely manner
There are appropriate controls in place to ensure that system problems that could potentially have an impact on the financial reporting process are
identified and resolved in a timely manner.



applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section IV.E of the General ITGC
Audit Guidance.
(1)
(2)
(
(
44
– INTEGRATED - US
(07/05)
End-user computing (e.g., spreadsheets and other user-developed programs) provides a unique set of general control needs within an organization. By its
nature, end-user computing brings the development and processing of information systems closer to the user. This environment may not be subjected to
the same level of rigor and structure as the IT general controls environment in a data center.
Providing the end-users with tools to assist in decision-making does not eliminate the need for information technology general controls. The output of
end-user computing processes frequently appears as an authoritative document that will be relied on by management in financial reporting. When an
organization uses end-user computing to support a major class of transactions or as part of the financial reporting process, IT general controls should be
adopted to achieve the same objectives as described in previous sections of this document. Many of the controls in this environment may be manual in
nature and/or may not be subject to the IT organization’s control environment or IT general controls.
The organization may support end-user computing with general controls consistent with its level of sophistication. Such general controls should,
however, address access to programs and data, program change, program development and computer operations.
V.A Audit Objective: Determine that management has implemented appropriate policies and procedures to ensure IT General Controls are
properly applied to end-user computing environment
There are appropriate controls in place to ensure that policies to address IT general controls over critical data, transactions, and programs being
maintained by end-users exist and are being followed.
Note: Generally these controls are housed outside the IT area and therefore it is appropriate to document the work performed for end-user computing
and IT general controls over end-user computing in the Audit Program(s) - Integrated for the respective audit objective.


(1)
(2)
45
– INTEGRATED - US
(07/05)

applicable:
NOTE: As no RACF-specific functionality exists regarding this audit objective, reference section V.A of the General ITGC
Audit Guidance.
(
(
46
– INTEGRATED - US
(07/05)
Appendix
This appendix provides supplemental guidance to the IT General Controls Document – Integrated
(“ITGC”) and is not required to be printed and filed in the working papers.
For each audit objective indicated in the ITGC, a number of example controls are listed in this appendix,
which demonstrates what may be necessary to achieve the stated audit objective. However, the controls
listed need not always be in place to achieve the audit objective, and the audit team must use judgment to
make the determination as to which controls are applicable. The factors to be considered in making this
judgment may include the overall complexity of the information technology environment, the size and
complexity of the related applications, or the existence of any other controls that may achieve the same (or
similar) objective.
Many of the controls listed in this appendix also contain “example control considerations”, which should
be considered in the determination of the design or operational effectiveness of the control. However, the
“example control considerations” need not all be present or functioning effectively for the control to be
deemed effective.
Evaluation of deficiencies
A control deficiency exists when the design or operation of a control, which is determined to be necessary
to achieve the audit objective, does not allow management or employees, in the normal course of
performing their assigned function, to prevent or detect material misstatements on a timely basis.
n a deficiency in design exists when (a) a control necessary to meet the control objective is missing or
(b) an existing control in not properly designed so that, even if the control operates as designed, the
control objective is not always met, and
n a deficiency in operation exists when a properly designed control does not operate as designed, or
when the person performing the control does not possess the necessary authority or qualifications to
perform the control effectively.
Each control deficiency should be carried forward to the Summary of Internal Control Deficiencies –
Integrated (SICD) working paper, where it will be evaluated for severity and for its impact on the
integrated audit and our reports.
47
– INTEGRATED - US (07/05)

Consider the following program and data access guidance for each of the platforms used in the financial
reporting process, such as applications, operating systems, and databases.
I.A Audit Objective: Determine that information security is managed to guide consistent
implementation of security practices and that users are aware of the organization's position
with regard to information security, as it pertains to financial reporting data
An inconsistent approach to managing information security across the organization may impact the
integrity and availability of system resources.
Management sets a clear direction and demonstrates support and commitment to information security
through the issuance and maintenance of an information security policy. The policy is communicated
throughout the organization to users in an accessible and understandable form, with the responsibility for
its implementation and compliance shared by all members of management.
Example Controls:
A.1 The company has established an information security function that is appropriately aligned within
the organization.
Example control considerations:

n function is appropriately positioned and is independent of development and operations, and
n personnel within the Information Security function have the appropriate technical expertise to
understand security concepts and implementation.
A.2 The company has adopted a formal security policy that provides guidance for information security
within the organization and includes within its scope all aspects of the IT environment relevant to
financial reporting applications and data (e.g., networks, perimeter security, operation system
security, application security, acceptable systems use).

n the policy should be communicated throughout the organization to both full time and
temporary personnel who are involved with the audit of internal controls over financial
reporting (ICOFR)
n the policy should be approved by an appropriate level of management within the organization,
and
n the policy should be reviewed by management on a periodic basis and updated as appropriate.
I.B Audit Objective: Determine that logical and physical access to IT computing resources is
appropriately restricted by the implementation of identification, authentication and
authorization mechanisms to reduce the risk of unauthorized/inappropriate access to the
organization’s relevant financial reporting applications or data
48
Appropriate controls are in place to ensure that there are sufficient physical and logical security controls in
place for applications and systems that support financial reporting (e.g., network, infrastructure,
applications, databases, etc.) to protect against unauthorized/inappropriate access.
Example Controls:
B.1 The organization has established an authentication mechanism for in-scope information systems
that provides individual accountability.

n individual User-ID must be issued for each user (shared logon ID reduce individual
accountability and should not be used), and
n passwords or stronger authentication methods should be used to determine the authenticity of
the user. Stronger authentication may include the use of a two-factor authentication system
(i.e., SecureID) or biometric device.
B.2 If passwords are used for authentication, the organization should have established rules for
password management and syntax.

n password rules should consider:
 minimum password length
 acceptable password change intervals
 passwords Syntax rules (e.g., prohibited passwords, required letter/number/special
character combinations), and
n the organization should have established procedures for initial passwords and password resets
by help-desk or other personnel that appropriately determines the authenticity of the user
requesting the password reset.
B.3 The organization has established a rule based authorization mechanism that provides access to
system and application resources based on job function.

n group or role based security may be used for granting access to groups of users with a similar
job function, and
n individually assigned privileges may be used where group or role based security is
impractical (e.g., groups and roles are not supported by the system, a user’s privilege
requirements are unique to that user).
B.4 Management has designed and implemented security policies and procedures for direct data
access. (i.e., access bypassing application controls).

n defined access requirements for financial reporting data outside of the application.
49
B.5 If stronger authentication methods are used, the organization should have established management
processes to: prevent users or other personnel from bypassing system authentication; and provide
for appropriate administration of the authentication mechanisms.
B.6 There are procedures in place for the management of users and user privileges for in-scope
systems. The management procedures require formal approvals for the establishment of users and
granting of privileges.

n user access request forms (hard copy or electronic) should be completed and retained in a
central location for all user changes, and
n approvals to modify users or grant access should be made by authorized personnel. Clear
evidence of approval should be maintained as part of the request.
B.7 Access to powerful system level ID (e.g., root, administrator, security administration ids, batch
processing ids) for in-scope systems is restricted to a defined set of system administration
personnel.

n access to powerful system level ID should only be granted to these ID based on job function
n access to powerful system level ID should be restricted to a small group of personnel to
preserve accountability, and
n where possible, all access to powerful system level ID should be logged and recorded for
appropriate review.
B.8 Access to powerful application system level ID (e.g., ID with SAP_ALL or SAP*, ID with
PeopleSoft Administration, ID with powerful Oracle “FND_” Functions) for in-scope applications
is restricted to a defined set of system administration personnel.

n access to powerful system level ID should only be granted to these ID based on job function
n access to powerful system level ID should be restricted to a small group of personnel to
preserve accountability, and
n where possible, all access to powerful system level ID should be logged and recorded for
appropriate review.
B.9 Access to powerful application functional-level ID that are used to initiate critical financial
transactions are restricted to the appropriate users.

n the ability to perform sensitive transactions (e.g., book a journal entry with no approvals,
issue checks with no approvals, write off receivables with no approvals) is limited to
authorized personnel, and
n sensitive transactions may be recorded on a sensitive transaction log that is reviewed by
appropriate organization management personnel.
50
B.10 Physical Access to computer facilities that house the financial applications is restricted to
appropriate personnel.

n servers and/or mainframes hosting the financial applications are located in a physically secure
area where access is limited to IT Operations Personnel, and
n obtaining access to the facility housing the financial systems requires documented approval
from appropriate client management.
B.11 Effective mechanisms are in place to log security activity and identify potential violations and
then escalate and act upon them in a timely manner to reduce the risk of
unauthorized/inappropriate access to the organization’s relevant financial reporting applications or
data.

n all security violations are logged. Security violations are reviewed on a timely basis and
appropriate action is taken, and
n all financial transactions are logged to provide an appropriate financial audit trail.
B.12 Security configuration settings are reviewed periodically to ensure consistency with security
policy.

n standard configuration settings are defined, and
n security configuration settings are updated in a controlled manner (including, but not limited
to, global security parameters, password parameters, and services running).
I.C Audit Objective: Determine that procedures have been established so that user accounts are
added, modified and deleted in a timely manner to reduce the risk of
unauthorized/inappropriate access to the organization's relevant financial reporting
applications or data
There are appropriate controls in place to ensure that users are assigned access rights in accordance with
their job functions as well as over the process to request, authorize, establish, issue, modify, suspend and
close user accounts and access rights to organizational information systems in a timely manner.
Example Controls:
C.1 An effective mechanism is in place to ensure that access is appropriately modified or revoked
when changes in job function through transfer or termination occur.
C.2 Changes to access rights are performed immediately after the user is terminated to minimize the
likelihood of system abuse or sabotage.
C.3 Security administration personnel effectively communicate changes to access rights to appropriate
management.
51
C.4 The organization has controls in place to ensure proper management of data access settings (e.g.,
data file permission)
I.D Audit Objective: Determine that effective control processes are in place to monitor the
maintenance of access rights to the organization’s relevant financial reporting applications
or data
Controls are in place so that management/information owners conduct periodic reviews of access to the
organization's financial system resources and other confidential/critical data, to confirm the
appropriateness of these access rights.
Example Controls:
D.1 The organization performs a periodic review of active users and user access rights to identify and
remove inappropriate system access.

n inappropriate system access is removed, and
n access changes due to the review process are appropriately documented and the
documentation is retained.
D.2 Access groups and roles are periodically reviewed to identify inappropriate or incompatible access
rights that conflict with segregation of duties (as established in Audit Objective I.E below).

n maintenance of roles is subject to change management process.
I.E Audit Objective: Determine that controls used to provide appropriate segregation of duties
within key processes exist and are followed
Controls are in place to allow for proper segregation of duties and responsibilities for authorizing
transactions, recording transactions, and maintaining custody to prevent individuals from being in a
position to both perpetrate and conceal an error or irregularity.
Example Controls:
E.1 Controls are in place to allow for effective translation of business rules into system access rules

n the organization may group compatible system access privileges into roles or profiles to
facilitate security administration, and
n controls need to be in place to ensure that there are no segregation of duties issues within
individual roles or profiles.
E.2 Controls should ensure that segregation of duties conflicts do not exist for users having access to
multiple system profiles or transactions.
52

n the organization performs a review whenever access privileges are granted to an individual
user
n the organization performs a periodic review of functional roles within the organization to
identify process changes and potential segregation of duty conflicts, and
n as new functions and processes are added within the organization, the processes and functions
are evaluated against the existing segregation of duties permissions.
E.3 Internal Audit or other organization management performs a periodic review of the organization’s
segregation of duties. Organization management resolves identified segregation of duties issues
through modification of functional roles or related user access privileges. Issues that cannot be
resolved within the IT organization are escalated to the appropriate business personnel.
53
II. Program Changes

Consider the following change management guidance for each of the applications used during the
financial reporting process (as identified in the Key Application Identification section at the beginning of
the ITGC document) within the mainframe, client-server, web-based and end-user computing
environments.
II.A Audit Objective: Determine that controls are in place to ensure that any changes to the
systems/applications providing control over financial reporting have been properly
authorized by an appropriate level of management
For a company to have an effective program change process in place, system application and infrastructure
changes need to be approved and signed off by an appropriate level of both business and IT management
prior to development to ensure that the changes are technically feasible and have considered financial
Example Controls:
A.1 The organization has established a formal change management process that outlines the
requirements for making changes to systems and applications providing control over financial
reporting.

n the process is documented and communicated to IT and user personnel, and
n appropriate management personnel have approved the process.
A.2 All change requests to information systems and applications providing control over financial
reporting are formally documented.

n change requests are formally documented and maintained in a central repository
n change requests are formally approved by appropriate management personnel (both user and
IT)
n significant change requests are reviewed and approved by an IT Steering committee or like
governance function, and
n changes to configuration options and parameters are documented and evaluated to ensure
achievement of business and application control requirements.
II.B Audit Objective: Determine that controls are in place to ensure that changes to applications
and systems used during the financial reporting process are tested, validated, and approved
prior to being placed into production.
There are appropriate controls in place to ensure that changes which are made to the IT systems are tested,
validated, and approved prior to implementation into the production environment. This is to ensure that the
changes will meet the user requirements and that the changes will not have a negative impact on any of the
existing controls.
54
– INTEGRATED - US
(07/05)
Example Controls:
B.1 The organization has established a formal testing and sign-off process that provides for testing by
both information systems and user personnel.

n system testing (covering user and technical test conditions) is performed by IT personnel
n unit testing, volume testing, sequence testing, and system interfaces testing is performed by
IT personnel
n regression testing is performed by a combination of user and IT personnel
n user acceptance testing is performed by user personnel
n implementation plans are developed and evaluated prior to migrating changes into production,
and
n implementation plans should consider
 contingency plans and back-out procedures
 whether the change being implemented will impact multiple locations, and
 process for updating production library/directories.
Once testing is complete and any further modifications are made, the results are formally approved by user
and IT personnel.
B.2 A testing environment separate from production is established and used for the execution of
testing program changes.

n at a minimum, the organization should consider establishing a system test environment and a
quality assurance test environment. The quality assurance test environment should simulate
the production environment, and
n the test environments should not access live production data.
B.3 The organization maintains a repository of test documentation for all changes.

n test documentation for completed and approved testing should be maintained, and
n test documentation for failed tests need not be maintained in the repository.
II.C Audit Objective: Determine that controls are in place to restrict access for migrating
changes into the production environment for systems and applications used during the
financial reporting process
Only a limited number of personnel should have access to migrate changes to the production environment
to ensure that this process is well controlled and only tested, authorized, and properly approved changes
are migrated into production.
Example Controls:
C.1 The organization has an established policy that limits production changes to change management
personnel.
55

n changes to production libraries/directories are logged by security software, and
n modify access to the production environment is limited to change management personnel.
II.D Audit Objective: Determine that controls are in place to ensure that system and application
configuration changes related to financial reporting are tested, validated, and approved
Configuration settings are a key component of many information systems. Configuration settings
frequently can impact the design and/or operating effectiveness of ICOFR. Generally, these settings are
subjected to change control procedures to maintain the integrity of ICOFR provided by information
systems.
Example Controls:
D.1 Configuration settings are used to provide systems administration personnel, and often user
management personnel, with the ability to customize certain aspects of the system. Configuration
settings frequently are present in operating systems, databases, system services and applications,
and may include the setting of control thresholds, process variance tolerances, interface linkages,
file locations and other control parameters.
Examples Control Considerations:
n approval controls (e.g., three way match tolerance, approval limits, approval chains)
n interest rates
n receivables aging parameters
n password parameters (e.g., length, change interval, syntax)
n login violation thresholds
n file and interface mappings (e.g., file names, database and schema names, host names, port
settings, database connection settings), and
n audit logs.
II.E Audit Objective: Determine that controls are in place to appropriately address emergency
changes to systems, applications, and infrastructure configuration.
Controls are in place to ensure changes requiring immediate implementation are properly handled,
allowing for timely change and no impact to systems and applications related to the financial reporting
process.
Example Controls:
E.1 The organization has established change procedures for emergency changes.

n emergency changes are approved by appropriate client personnel
n emergency changes are documented for next-day review, and
n all emergency changes are reviewed for appropriateness on the following day.
56
E.2 All emergency changes are subjected to an appropriate testing methodology.

n test results are documented and stored in the test result repository, and
n where possible, user testing is performed on emergency changes.
E.3 All emergency changes are logged to facilitate a detail review of the change.

n the organization uses change monitoring tools to detect changes to the production
environment (i.e. Tripwire), and
n emergency changes are made using an emergency change user-id that is logged.
57
– INTEGRATED - US
(07/05)

Consider the following system development guidance for each of the applications used during the financial
reporting process (as identified in the Key Application Identification section at the beginning of the ITGC
document) within the mainframe, client-server, web-based and end-user computing environments.
III.A Audit Objective: Determine that management has controls in place to ensure that new
program and infrastructure developments and acquisitions have been approved by an
appropriate level of both IT and business management
There is a formal process in place for each new program development or acquisition to be approved and
signed off by an appropriate level of business and IT management to ensure that the development is
feasible, integrates with the existing IT infrastructure and business processes, and considers financial
Example Controls:
A.1 The organization has adopted a formal process for the acquisition or development of IT
infrastructure and information systems.

n management may have established purchase authorization levels for IT which include
approvals based on expenditure level and organizational impact, and
n management may have adopted a formal system development lifecycle (SDLC) methodology.
A.2 Significant system development and infrastructure projects are approved by IT and Business
senior management.

n and IT Steering Committee may be established by the organization
n board approval may be required for projects over established dollar amounts, and
n capitalization and expense requirements may be established based on project size and scope.
III.B Audit Objective: Determine that management has controls in place to ensure that an
adequate program development methodology is in place and is followed for the development
or acquisition of systems/applications used during the financial reporting processes
There is a proper, formal program development methodology in place, which guides the process for
developing, acquiring, and implementing the IT systems used during the financial reporting process. This
is to ensure that a structured approach is followed for each new program development so that the potential
risks to the financial reporting controls are adequately assessed and mitigated.
58
Example Controls:
B.1 The organization utilizes SDLC and project management for the development and acquisition of
systems and technology that impact the financial reporting process.

n some sample methodologies are:
 SSADM (Structured Systems Analysis and Design Methodology)
 LSDM (Learmonth & Burchett Structured Design Methodology)
 IE (Information Engineering)
 In-house methodology, and
 Prototyping software (e.g., 4th Generation)
n does the organization have criteria established for projects that must comply with the SDLC
and Project Management (i.e., Cost, level of effort, duration), and
n are package systems with significant customization required to comply with the SDLC and
Project Management?
B.2 Appropriate project management documentation is prepared to define project scope, requirements,
and budgetary requirements.

n does the organization use project charters to describe the project scope
n does the organization create functional, control and technical requirements documentation
n does the organization produce project plans with milestones
n does the organization produce project budgetary requirements, and
n does the organization have established milestones with testing and completion sign-off’s?
B.3 SDLC and Project management was used for all development projects that would have an impact
on the financial reporting process.

n does the organization use a project management office to track the status of existing projects,
and
n are status reports generated at the project level and project management level?
B.4 The organization performs sufficient testing and review of key stages in the system development
lifecycle.

n is the application tested against original and revised user requirements
n is the cutover to a new system a planned process that includes disabling functions in the old
system (this is done to prevent users from mistakenly utilizing the old system), and
n are implementation and conversion timelines appropriately communicated to user personnel?
B.5 Systems developed or acquired, and infrastructure projects are authorized, tested, and approved
prior to implementation in production.
59
n formal authorization process is in place to ensure that only tested and approved systems and
infrastructure are implemented in production
n implementation plans are developed and evaluated for each application and infrastructure in
support of the “go-live” decision-making process
n implementation plans should consider:
 contingency plans and back-out procedures
 whether the application or infrastructure being implemented will impact multiple
locations
 operational support from the business and IT during the “go-live” period, and
 communication of the specifics around the “go-live” process.
III.C Audit Objective: Determine that controls exist to ensure there is adequate testing for the
development or acquisition of systems/applications used during the financial reporting
process and that testing is signed off by both the users at an appropriate level of IT and
business management
Programs and system developments (application and infrastructure) are fully tested in a testing
environment prior to implementation to ensure that the changes that are made will meet users needs, that
the controls in place adequately cover the risks to the company and that the new system will be able to
integrate with the company’s existing systems.
Example Controls:
C.1 The SDLC includes appropriate testing and user acceptance phases

n testing should be performed at pre-defined milestones/phases of the project
n testing should include:
 system testing (covering user and technical test conditions) is performed by IT personnel
 unit testing, volume testing, sequence testing, and systems interface testing are performed
by IT personnel
 regression testing is performed by a combination of user and IT personnel, and
 user acceptance testing is performed by user personnel
n parameters and configuration options should be tested to ensure achievement of business and
application control requirements, and
n once testing is complete, the results are formally approved by user and IT personnel.
C.2 The SDLC includes specific and appropriate testing of system interfaces

n authentication and authorization controls must be in place and operating
n completeness controls must be in place and operating (e.g., hash totals, control totals, record
counts), and
n data integrity controls must be in place and operating (e.g., hash totals, cyclic redundancy
checking).
C.3 Thorough integration testing is performed to ensure that new systems implementation do not
impact related applications and the integrity of their controls.
60

n is there an Integrated Test Plan for new systems implementation, and
n are the business owners of impacted applications involved in the integrated test?
C.4 The SDLC assigns responsibility for performance of the testing and the maintenance of test
results.

n is there a central repository for the storage of test results
n are expectations of IT and user personnel appropriately documented and met, and
n are consistent test procedures used for each phase of testing?
C.5 Post implementation review is performed for all significant system development projects to
ensure the proper operation of newly implemented processes and controls.

n post conversion issue identification and resolution
n process improvement documentation, and
n removal of excess privileges that may have been granted as part of the implementation
process.
III.D Audit Objective: Determine that there are controls in place to ensure that data migrated to
the new application or system used during the financial reporting process retains its
integrity
There are appropriate controls in place to ensure that any data that is migrated from an old system to the
new system accurately and completely.
Example Controls:
D.1 Comprehensive conversion procedures have been established and followed in converting the data.

n all master files have been identified for conversion
n conversion maps have been developed
n conversion conflicts have been resolved (e.g., conflicts due to changes in data format)
n conversion programs have been developed and tested including:
 data integrity tests (may be tested programmatically or through online review)
 completeness tests (e.g., control totals, record counts, hash totals), and
n the legacy system and new system may run in parallel through one or more accounting cycles
to confirm system integrity.
D.2 Historical transaction information is converted as appropriate or the legacy system is maintained
to allow for accessing historical information.
61

Consider the following computer operations guidance for each of the platforms used during the financial
reporting process (as identified in the Key Application Identification section at the beginning of the ITGC
document), such as applications, operating systems and databases.
IV.A Audit Objective: Determine that management has implemented procedures to ensure
accuracy, completeness, and timely processing of system jobs, including batch jobs and
interfaces, for relevant financial reporting applications or data
There should be controls over the design and execution of system jobs, including confirmation that the
jobs were completed on time, accurately, and in the proper order.
Example Controls:
A.1 Roles and responsibilities of key IT functions have been defined and clearly communicated

n roles and responsibilities allow for proper segregation of duties
n roles are defined and communicated to appropriate personnel and reviewed periodically by
management, and
n controls exist to ensure computer operations personnel have appropriate skills to perform their
functions.
A.2 An appropriate job schedule is produced for processing cycles.

n job priorities
n authorization procedures
n job overrides
n ad hoc jobs
n record of job failures, and
n a job-scheduling package is used by the company.
A.3 Job processing procedures are documented.

n online processing requirements
n instructions and documentation produced by development team
n batch processing requirements
 transaction volumes
 job flow
 frequency and schedules
 input and output files used, and
 programs to be used in processing
n actions required for program halt
n errors and console messages
n rerun, checkpoint, back up and restart or recovery procedures
62
n disk allocation
n housekeeping
n job control language instructions, and
n job overrides or emergency changes.
A.4 Operating procedures are documented and followed.

n shift procedures including turnover
n shift logs
n incident reporting
n processing statistics, and
n procedures to protect information systems and technology from computer viruses.
A.5 Monitoring procedures are designed to provide reasonable assurance around completeness and
timeliness of system and data processing.
IV.B Audit Objective: Determine that management has implemented appropriate backup and
recovery procedures so that data, transactions and programs that are necessary for
financial reporting can be recovered
There are appropriate controls in place so that all critical data, transactions and programs are backed up on
a defined schedule and that the backups are complete, accurate and can be recovered if needed.
Example Controls:
B.1 Responsibility for performing the backup procedures has been assigned to appropriate personnel.

n training in backup and recovery software.
B.2 A backup schedule and retention requirements commensurate with the risk of data loss based on
the criticality of the system and the cost of manual recovery has been implemented.

n daily, weekly, monthly schedules
n defined retention periods based on business and regulatory requirements, and
n equipment capable of reading retained data is maintained.
B.3 Backups are sent offsite.

n offsite facility is sufficiently remote from the client location (e.g., 50 miles).
IV.C Audit Objective: Determine that effective procedures exist and are followed to periodically
test the effectiveness of the restoration process and the quality of backup media relevant to
systems and applications used during the financial reporting process
63
There should be appropriate controls in place so that backups are tested on a periodic basis to ensure that
the backup tapes are not corrupt and can be used if required.
Example Controls:
C.1 The backup and recovery procedures for in-scope systems are tested periodically.
C.2 Offsite storage for in-scope systems has been tested to ensure that the data is re-usable.
C.3 Backup media is replaced periodically (consistent with manufacturer’s guidance for MTBF).
IV.D Audit Objective: Determine that appropriate controls are in place over the backup media
for systems and applications used during the financial reporting process, including that only
authorized people have access to the tapes and tape-storage
There are appropriate controls in place to ensure that the backup media is stored in a secure location that
only authorized people have access to it. This is to mitigate the risk of the backup tapes being damaged or
of unauthorized users gaining access to the sensitive information contained thereon.
Example Controls:
D.1 Backups maintained locally and offsite are appropriately secured from unauthorized access.

n local storage facility should have appropriate environmental and security controls
n offsite storage facility should have appropriate environmental and security controls
n offsite storage vendor should maintain appropriate environmental and security controls over
media in transit, and
n ability to recall back-up media should be limited to authorized personnel
IV.E Audit Objective: Determine that management has defined and implemented problem
management procedures to record, analyze, and resolve incidents, problems, and errors for
systems and applications used during the financial reporting process in a timely manner
There are appropriate controls in place to ensure that system problems that could potentially have an
impact on the financial reporting process are identified and resolved in a timely manner.
Example Controls:
E.1 The production environment is monitored to identify incidents and failures.

n automated monitoring software may be used
n operations personnel may be assigned to monitor system consoles
n a third party monitoring vendor may be used to monitor the environment, and
n use of virus and patch management systems.
64
E.2 All incidents and failures are logged and tracked through to resolution.

n escalation procedures should be established and followed
n resolution procedures for common problems may be established
n an aging of open issues may be performed, and
n a third party monitoring vendor may be used to monitor the environment.
E.3 All incidents and failures reported by users are logged, investigated to brought to resolution.

n mechanisms such as help-desk or self-service facilities exist for users to report problems
n problems are tracked through to resolution in an incident management system, which includes
a prioritization mechanism, and
n escalation procedures should be established and followed for unresolved and open items.
65
End-user computing (e.g., spreadsheets and other user-developed programs) provides a unique set of
general control needs within an organization. By its nature, end-user computing brings the development
and processing of information systems closer to the user. This environment may not be subjected to the
same level of rigor and structure as an IT general controls environment.
Providing the end-users with tools to assist in decision-making does not eliminate the need for information
technology general controls. The output of end-user computing processes frequently appears as an
authoritative document that will be relied on by management in financial reporting. When an
organization uses end-user computing as part of the financial reporting process, controls should be
adopted to achieve the same objectives as described in Sections II – V of this document. Many of the
controls in this environment may be manual in nature and/or may not be subject to the IT organization
control environment or IT general controls.
The organization may support end-user computing with general controls consistent with its level of
sophistication. Such general controls should, however, address access to programs and data, program
change, program development and computer operations. Consider the following guidance when
evaluating IT General Controls around applications, systems, and databases maintained in an end-user
computing environment.
V.A Audit Objective: Determine that management has implemented appropriate policies and
procedures to ensure IT General Controls are properly applied to end-user-computing
environment.
There are appropriate controls in place to ensure that policies to address IT General Controls over critical
data, transactions, and programs being maintained by end users exist and are being followed.
Example Controls:

A.1 End-user computing policies and procedures concerning access to programs and data exist and are
followed.
A.2 User-developed systems, such as spreadsheets and other end-user programs, are secured from
unauthorized use.
II. Program Change

A.3 Changes to end-user computing systems and applications are authorized, tested, verified, and
approved by appropriate personnel.

A.4 End-user computing, including spreadsheets and other user-developed programs, are documented
and regularly reviewed for processing integrity, including their ability to sort, summarize and
report accurately.
A.5 Inputs, processing and outputs from user-developed systems are independently verified and
approved for completeness and accuracy.
66

A.6 User-developed systems and data are regularly backed up and stored in a secure area with
restricted access.
67

2005 Itgc Example - Racf

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

2005 Itgc Example - Racf

Uploaded by

Copyright:

Available Formats

Midwest IRM Support Team

Audit of Internal Control

Version Revision Date Nature of Change Revised By Reviewed By Posted Date

Location subject to testing:

I. Access to Programs and Data

II. Program Changes

III. Program Development

IV. Computer Operations

Prepared by: Date:

Reviewed by: Date:

We document management’s controls applicable to EACH audit objective. This documentation in

n confirm our understanding of the activities documented

n confirm that we have identified all of the relevant risk points

n evaluate the effectiveness of the design of controls, and

n confirm whether controls have been implemented.

Examples of follow-up inquiries include asking personnel:

n were procedures sufficient to assess design and operating effectiveness:

n were findings supported based on testing performed, and

n were exceptions/deficiencies adequately documented and followed-up? Where corrective action

Audit procedures performed and results:

In this section, we document the procedures to be performed to conclude on the operating

n new or significant modifications to client IT systems

n significant modifications to existing processes, including process reengineering

n new or evolving industry and/or company-specific risks

n changes in accounting principles or financial reporting requirements

n indicators of fraudulent activity or errors, and

n changes in the client’s regulatory environment.

ITGC Areas Walkthrough Performed Performed by/Date/W/P Ref(1)

IT General Controls [IAM3_3_4]

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

5) Duration of Lockout – (Guidance:

6) Audit Log Activation

OPTIONAL – 7) Password History

Guidance: Unauthorized access to the RACF

Guidance: Use of the RVARY command and

Use the LISTDSD

Roll forward Result: Roll forward Result:

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Deficiencies, if applicable: Deficiencies, if

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Deficiencies, if applicable: Deficiencies, if

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Deficiencies, if applicable: Deficiencies, if

II. Program Changes

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Deficiencies, if applicable: Deficiencies, if

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Deficiencies, if applicable: Deficiencies, if

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Deficiencies, if applicable: Deficiencies, if

Evaluation of Management’s Assessment

Audit Procedures Performed and Results:

Deficiencies, if applicable: Deficiencies, if

Evaluation of Management’s Assessment

Audit Procedures Performed and Results: