Itgc Primary Control Testing Procedures(1) With Notes.docx

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

1

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

Type of changes:

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

2

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

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

3

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

4

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

5

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

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

6

3.2.5

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

7

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

8

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

9

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

10

Appendix A – Primary Control Procedures

Index ITGC Primary Control Procedures II 1

2

3

4

5

III 1 2

3

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

11

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

7

8

IV 1

2

3

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

Requesting access, approving access, setting up access, and monitoring access violations/violation attempts



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

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

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

12

Index ITGC Primary Control Procedures identified, resolved, reviewed and analyzed in a timely manner.

13