Access to Programs and Data

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). Example control considerations: 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 organizations 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 unauthorized/inappropriate access.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

Example Controls: B.1 The organization has established an authentication mechanism for in-scope information systems that provides individual accountability. Example control considerations: 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. Example control considerations: 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. Example control considerations: 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 users 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).

Example control considerations: defined access requirements for financial reporting data outside of the application. 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. 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. Example control considerations:

B.6

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

n n

user access request forms (hard copy or electronic) should be completed and retained in a central location for all user changes, and 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. Example control considerations: 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. Example control considerations: 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. Example control considerations: 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.

B.10

Physical Access to computer facilities that house the financial applications is restricted to appropriate personnel.

Example control considerations: 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

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 organizations relevant financial reporting applications or data. Example control considerations: 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. Example control considerations: 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 C.3 C.4 I.D Changes to access rights are performed immediately after the user is terminated to minimize the likelihood of system abuse or sabotage. Security administration personnel effectively communicate changes to access rights to appropriate management. The organization has controls in place to ensure proper management of data access settings (e.g., data file permission) Audit Objective: Determine that effective control processes are in place to monitor the maintenance of access rights to the organizations 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

Example control considerations: 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).

Example control considerations: 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 Example control considerations: 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. Example control considerations: 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 organizations 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

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 reporting objectives. 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. Example control considerations: 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. Example control considerations: 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.

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.

Example control considerations: 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. Example control considerations: 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. Example control considerations: test documentation for completed and approved testing should be maintained, and test documentation for failed tests need not be maintained in the repository. 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

n n II.C

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:

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

C.1

The organization has an established policy that limits production changes to change management personnel. Example control considerations: changes to production libraries/directories are logged by security software, and modify access to the production environment is limited to change management personnel. 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

n n II.D

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. Example control considerations: 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

E.2

All emergency changes are subjected to an appropriate testing methodology. Example control considerations: 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. Example control considerations: 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.

III.

Program Development

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 reporting objectives. Example Controls: A.1 The organization has adopted a formal process for the acquisition or development of IT infrastructure and information systems. Example control considerations: 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. Example control considerations: 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

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. Example control considerations: 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. Example control considerations: 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-offs? B.3 SDLC and Project management was used for all development projects that would have an impact on the financial reporting process. Example control considerations: 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. Example control considerations: 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. Example control considerations:

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

III.C

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. 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 companys existing systems. Example Controls: C.1 The SDLC includes appropriate testing and user acceptance phases Example control considerations: 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 Example control considerations: 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).

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

C.3

Thorough integration testing is performed to ensure that new systems implementation do not impact related applications and the integrity of their controls. Example control considerations: 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. Example control considerations: 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. Example control considerations: 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 the data. Comprehensive conversion procedures have been established and followed in converting Example control considerations: 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

IV.

Computer Operations

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 Example control considerations: 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. Example control considerations: 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. Example control considerations: 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

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

n n n n n n A.4

errors and console messages rerun, checkpoint, back up and restart or recovery procedures disk allocation housekeeping job control language instructions, and job overrides or emergency changes. Operating procedures are documented and followed.

Example control considerations: 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 IV.B Monitoring procedures are designed to provide reasonable assurance around completeness and timeliness of system and data processing. 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 personnel. Responsibility for performing the backup procedures has been assigned to appropriate

Example control considerations: 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. Example control considerations: 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. Example control considerations: n offsite facility is sufficiently remote from the client location (e.g., 50 miles).

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/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. Example Controls: C.1 C.2 C.3 MTBF). IV.D The backup and recovery procedures for in-scope systems are tested periodically. Offsite storage for in-scope systems has been tested to ensure that the data is re-usable. Backup media is replaced periodically (consistent with manufacturers guidance for 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. Example control considerations: 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. Example control considerations: n automated monitoring software may be used n operations personnel may be assigned to monitor system consoles

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

n a third party monitoring vendor may be used to monitor the environment, and n use of virus and patch management systems.

E.2

All incidents and failures are logged and tracked through to resolution. Example control considerations: 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 resolution.

All incidents and failures reported by users are logged, investigated to brought to

Example control considerations: 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

V.

End-user Computing

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: I. Access to Programs and Data 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. III. Program Development 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.

IT GENERAL CONTROLS DOCUMENT INTEGRATED (04/05)

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