Previous Table of Contents Next


Identifying Responsibility Vulnerabilities. To represent a vulnerability, two actions must permit a single individual to both perform and conceal an act. If the event cannot be concealed, it should not be considered a vulnerability. There is, in addition, no vulnerability in the presence of a compensating control (e.g., an independent bank reconciliation) that would otherwise detect any irregularity.

Identifying Transaction Vulnerabilities. A vulnerability can be detected in the following situations:

  An action without a control appears on the data flow diagram
  A transaction without a control appears on one of the application system segments
  Risks that have been identified for which there appear to be inadequate controls
  Questions on one of the questionnaires have received negative responses

The area in which the vulnerability is perceived should be indicated on the workpaper for the identified business transaction, preferably with a brief written explanation rather than a checkmark.

Selecting the Vulnerabilities to be Tested. Once all personnel- and transaction-related vulnerabilities have been identified, the IT auditor must determine which of these vulnerabilities to pursue during the test steps of the audit. This determination is based on the following criteria:

  The magnitude of the vulnerability
  The amount of audit resources available for testing
  The IT auditor’s judgment regarding both the need for testing and the potential effect if the vulnerability is realized

To complete this task successfully, the IT auditor must ensure that all risks leading to vulnerabilities are identified. In addition, the IT auditor must have sufficient knowledge about the application to identify the significant vulnerabilities. It is equally important that even the most abstract vulnerability be able to be quantified.

TEST INTERNAL CONTROLS

The vulnerabilities that have been identified represent potential weaknesses in the internal control system. Vulnerabilities that have no controls need little testing; vulnerabilities with weak controls, on the other hand, should be tested. The IT auditor’s concern is that the controls be in place, working, and effective; all three factors are tested. The IT auditor may also test a control for which no vulnerability is perceived but that is relied on to reduce some risk. The controls to be tested are based on the IT auditor’s judgment, using the information collected in the previous steps.

The objective of this task is to develop a plan to test the internal controls selected in the previous step. It involves:

  Confirming the selection of controls to be tested
  Choosing the test method
  Determining who will be responsible for conducting the test
  Deciding when the test should be conducted
  Selecting the test process itself

Testing the control can be done in a static or dynamic mode. A static test usually involves evaluating a procedure or a program; depending on what the control is designed to do, the IT auditor will make an assessment as to whether the control achieves its desired objective. A dynamic test involves executing the control and examining the results. For a manual control, the transactions subject to that control must be examined; in an automated system, test data must be prepared or transactions found that are subject to the control.

The dynamic test is preferred if it can be easily arranged. Many situations are difficult to simulate; however, and these can be tested by a static evaluation. The IT auditor should be certain that the controls selected for testing are the key controls and that the correct type of test for the given control is selected. A static test involves a work program; a dynamic test involves either creating a test condition or finding a transaction that will test the control.

It is important that the limits of the control be tested. For example, if a control is designed to permit only codes A, B, and C to be entered, the test conditions must verify that all other codes are rejected. The IT auditor must therefore understand both the functioning of the control and the attributes of the data that needs controlling. The test should be designed to define the control objective being tested (there may be more than one test objective for a given control), define the test condition, and describe the expected results. In developing the tests, the IT auditor should ask the following questions about each control and develop conditions to answer them:

  Does the control reject values and codes that are not authorized?
  Is the control consistently applied?
  Does the control cover a wide range of conditions? Should each of those conditions be tested?
  Is this control related to another control? If so, should both be tested simultaneously?

The objectives of the control must be clearly understood, or the wrong test conditions will be prepared. In performing this task, the IT auditor also must ensure that test conditions are sufficient to test the control and that the right control is tested.

The IT auditor in charge should select the appropriate test program and assign it to an IT auditor who is responsible for its timely completion. Any special test preparation required should be indicated in the Comments column on the workpaper. When this task has been completed, the effectiveness or adequacy of the controls can be evaluated and the appropriate data tests performed. To complete this task successfully, the IT auditor must ensure that adequate computer time is available to conduct the tests and that the designed test works in production. The IT auditor must be alert to flaws in the test that produce correct results when, in fact, the control does not function properly.

EVALUATE INTERNAL CONTROL EFFECTIVENESS

Controls that are either not in place or not functioning can be identified by comparing the actual results with the expected results. When there is a discrepancy, the IT auditor should ascertain that the results are those of a valid test and that the expectation was correctly stated. Once the integrity of the test has been verified, the adequacy of the control can be evaluated.

Comparing Expected and Actual Results. If the expected and actual results of each test are the same and the IT auditor has a high degree of confidence in the reliability of the test, the control assessment can be developed and the next two parts of this task can be omitted. If the actual and expected results differ, however, the entire process should be performed.

Verifying Proper Test Functioning. If the expected and actual test results differ, it is important to confirm that the test was properly constructed and executed to avoid basing a recommendation on an invalid result. Unless fraud or a similar problem is suspected, the IT auditor may wish to ask user or IT personnel to confirm the proper functioning of the test.

Confirming Correctness of the Expected Result. An incorrect actual or expected result could lead to an improper finding. If the actual result is reasonable and has been so verified, the IT auditor should reconfirm the correctness of the expected result. The result can be checked with the user or IT person or by consulting the system documentation or company policies and procedures.

Developing a Control Assessment. When the actual and expected results differ and the actual result is incorrect, the control should be rated less than adequate. When the results agree, the assessment should be that the control is fully adequate. In some cases, there may be multiple conditions to test, in which all major conditions produce the expected results but have some minor conditions that present problems. Despite these problems, the IT auditor may decide to give an “adequate” assessment.

If the control is considered less than adequate, the IT auditor should recommend actions to be taken by the auditee. Even when a control has been given an assessment of adequate, the IT auditor may wish to make minor recommendations to strengthen the control; the IT auditor must be extremely careful that the information about the results expected from the execution of a control is accurate.


Previous Table of Contents Next