TEST DATA

Test data Sample of data that are created and used for the purpose of testing the application system.It is costlier to test the entire program or system. Hence, auditors should concentrate on those parts of the program where the payoffs will be the highest. 1. Test data need to be designed before they are put to use. 2. Two approaches of test data designs are black box testing (specification based) and white box testing (program based). 3. Black box testing seeks to determine whether the application outputs what is supposed to. This is found through interaction with users, understanding the functional specifications. 4. White box testing focuses on finding if there are any defective execution paths in a program. This is done through selecting those parts of the program that deem to be material from the viewpoint of an audit.

Test Data Techniques

Test data techniques are methods of conducting audit procedures by entering data (for example, a sample of transactions) into the computer system, and comparing the results obtained with predetermined results. Examples of this are outlined below:

1. Test data can be developed by the auditor to test specific controls in computer programs, such as on-line password and data access controls. 2. Test data in the form of test transactions can be selected from previously processed transactions or can be created by the auditor to test specific programmed procedures of the computer program. These test transactions are generally processed separately from normal processing. 1. Test data in the form of test transactions can be used in a live mode, where a dummy unit (for example, a department or employee) is established to which test transactions are posted during normal processing. This technique, when integrated into normal processing so as to operate on a continuous basis over a period of time, is known as an integrated test facility (ITF). When using this technique, the auditor should ensure that the impact of test transactions is subsequently eliminated from the computer files.

Test Data Checking The test data that are utilized to execute transactions for the purpose of analyzing the system need to qualify the following checks-Have the methods for creating test data been appropriate for this system? Has sufficient test data been developed to adequately test the application software? Further the success of these tests directly influence these queries as, Have all the testing techniques indicated in the test plan been scheduled for execution during testing phase? Have the expected results from testing been determined? Has a process been established to determine variance / deviation between expected results and actual results? Have both the expected and actual results been documented when theres a deviation between the two?

Audit procedures to control test data applications may include

1. Controlling the sequence of submissions of test data where it spans several processing cycles 2. Performing test runs containing small amounts of test data before submitting the main audit test data 3. Predicting the results of the test data and comparing it with the actual test data output, for the individual transactions and in total 4. Confirming that the current version of the programs was used to process the test data; and 5. Testing whether the programs used to process the test data were the programs the entity used throughout the applicable audit period.

Test data generation

Test data are designed through test tools such as correctness proof, data flow analysis and control flow analysis. The stream of data that are generated by these tools is called as the test data pack. PARALLEL PROCESSING 1. Parallel processing is a concept associated with the operating system and microprocessor. The processors time and capabilities are shared amongst competing processes on a time-sharing basis by the operating system. 2. In a multiprogramming (given as parallel programming) system, multiple programs submitted by users were each allowed using. 3. The processor for a short time. To users it appeared that all the programs were executing at the same time. 4. Parallel processing may be taken to mean Parallel simulation in the light of the topic being discussed. 5. Parallel simulation, imitates the application under review. It must be written to perform the same steps as the application so that results can be compared 6. If the real system and the parallel yield the same output, then you would have confidence that the real system is OK.

THE PHASES OF AN AUDIT The planning phase

1. Gathering information: To be able to evaluate the security of a system the auditor first

of all has to gain adequate knowledge of the system being evaluated. Some information needed in this connection could be e.g :

The purpose of the system The structure of the system Security policies and plans Information about the organization and its procedures

2. Risk assessment: After gaining an understanding of the entitys operations, the auditor

must assess the risk associated with this entity, as well as the audit of it. The risk assessment will determine the extent of the audit of this entity, as well as which areas the audit should focus on. Above we have taken for granted that a database system is the area of focus for the audit. In real life this would be determined from a risk assessment. If we choose to concentrate on a database system, the risk assessment might also help guide us as to how we approach this audit. One approach might be to start the audit by focusing on the applications used in connections with the database. Another approach could be to start by focusing on the database itself and evaluate controls independent from each individual application.

Evaluating and testing controls

During this phase the auditor should obtain detailed information on policies and procedures of importance to the internal controls in the areas being evaluated. The auditor needs to perform tests of these control activities to determine if they are operating effectively. FISCAM identifies six categories of controls that the auditor should consider. These are briefly:

Entity wide security program: FISCAM emphasizes the importance of an entity wide program for security planning and management as the foundation of a security structure for a company. The program should establish the frame work and a continuing cycle for risk assessment, the development and implementation of effective security procedures, and the monitoring of the effectiveness of these procedures.

Access control: These controls limit or detect access to computer resources. As the focus of this paper ,the audit of this category of controls is described in more detail in section 9.3

Application software development and change controls: An entity should have procedures and policies that prevent unauthorized programs, or modifications to an existing program from being implemented.

System software controls: The auditor need to evaluate controls that limits and monitor access to the powerful programs and sensitive files that control the computer hardware and secure applications supported by the systems.

Segregation of duties: These controls are defined as the policies, procedures, and an organizational structure established so that one individual cannot control key aspects of computer- related operations and thereby conduct unauthorized actions or gain unauthorized access to assets or records.

Service continuity: These controls help to ensure that when unexpected events occur, critical operations continue without interruption or are promptly resumed and critical and sensitive data are protected.

Reporting phase

During this phase the auditor will draw conclusions on the controls that have been evaluated, and the effects on the entity as whole. The auditor would make a report to present his conclusion. The manner and recipient of the report would be dependent on the situation and the auditors role in relation to the auditee.

CONCLUSION An auditor should evaluate a wide range of controls when conducting an audit of a database system, and it has only been possible to cover some of them in this paper. The paper should illustrate that Oracle databases, while not unbreakable as claimed in Oracles advertising, contain a wide array of possibilities to implement a secure system. How secure the system will be in practice, does however as always depend on how the system is implemented and specific procedures established by the entity.