On the Frontlines: Are You Testing Key Controls?

Let’s look at two processes to identify the key control in each:

1. Money needs to be wired to an external party. Someone needs to initiate the process by filling in a form. There are likely many fields and possibly some artifacts attached. Depending on the amount of money being wired, there may be more than one signature. Finally, the instructions are received by the wire room clerk. The clerk or supervisor reviews the instructions, confirms the authenticity of the approvers’ signatures and their levels of authority. When they are satisfied that the instructions are legitimate, the money is sent.
2. Computer software was modified, and the new version needs to be installed. Someone initiates the process by filling in a change ticket. There are likely many fields describing the change and possibly some artifacts attached. Depending on the risk level assigned to the change, there may be more than one signature. Finally, the change ticket is received by the IT operator who reviews the instructions, confirms the authentication of the approvers’ signatures and their levels of authority. When the IT operator is satisfied that the change ticket is legitimate, the new version is installed and the old one is deleted.

The two scenarios are somewhat similar and overly simplified, but not unrealistic. Each process has many tasks, but only one task should be labeled the key control. If a control task is not performed early in the process, a later control task may stop a mistake from occurring. In our scenarios, the last control task occurs right before the money is sent or the modified software is installed. Therefore, if you only have time to test one control task, it would be the last one, because this control task immediately precedes the point of no return. This is not to say that other controls are unimportant or may be eliminated. However, it may guide the presentation of the issue and its risk level.

It is likely that you will report the failure of a non-key control if the process is important to the organization. How you present it though will be critical to the organization’s perceived value of your department. If you state that the risk of not performing the control is severe financial loss or computational failure, your constituents will protest that control tasks later in the process would prevent the negative outcome. If your tests did not identify non-performance of the later control tasks, you may come across as having escalated the probability of a negative event.

So why do so many auditors write it that way? One or more of these reasons may apply to a scenario:

• The auditor hasn’t assessed the cumulative effect of the control tasks embedded in the process.
• The auditor doesn’t have the depth of experience to estimate the probability of a negative event.
• The auditor chooses to protect himself from criticism in case something goes wrong one day. “Don’t blame me. I told you that control was important.”

The problem with crying wolf for everything is that the auditor will not be taken seriously when there really is an issue worth crying about.