How to select and design test of controls in internal auditing

An organization should have controls in place that operates with the sole aim of preventing, detecting and correcting accounting misstatements caused by either accounting fraud or errors. It is our job as internal auditors to test those controls in order for us to make recommendations for improvements. Business organizations make significant investments into setting up and maintaining internal controls because not doing so will prove counter intuitive in other aspects of the business.

In today’s posts, I will be giving tips on how to select and design test of controls that any internal auditor can easily adopt. Control risk assessment is a major ingredient without which no meaningful risk based audit can ever be performed. This is so because control risk assessment governs the nature, timing and extent of substantive procedures that will be applied in the audit of a chosen process or segment.

We extensively talked about audit control objectives when we discussed how to audit an accounting information systems (AIS) – you may want to have a look at that article.

Let’s start by on one hand refreshing our mind on the concept of ‘entity level controls’ as captured by the COSO framework – which deals with; (a) collectively assessing the organizations control environment, (b) suitably assessing the organizations risk management process, (c) evaluating the adequacy of the information systems of the entity, (d) evaluating / testing the company’s control activities, then (e) observing/testing/ monitoring of controls applicable to the organization. See my earlier post on what is internal control for more on this.

And on the other hand reminding ourselves that ‘transaction level controls’ are designed to help reduce the risks of material misstatements due to error and/or fraud and above all, to ensure that processes are operating effectively and as intended. Transaction controls include but is not limited to all procedures used and relied upon by an entity to prevent fraud and errors from occurring or to detect those error and frauds that has already occurred which will then help motivate corrective actions.

Our focus here today is to explore how to select and design these transaction controls for optimal result.

Main objectives of controls are:

1. To prevent or detect material misstatements in financial statements and / or
2. To enhance and support automated systems like AIS in achieving their objectives.

Controls are further classified into:

1. Manual controls
2. Automated controls (systems and applications)
3. IT general controls
4. Semi-automated controls

How to select and design test of controls

Firstly, ensure that you base your approach on risk based audit philosophy where you start by gaining understanding of the nature of the entity’s business or operations. While gaining this understanding of the nature of the business, you are asking a very fundamental question that every good auditor (internal or external) asks at this point; what could possibly go wrong here? Asking these questions will help channel appropriate energy into those areas that are prove to having many anomalies. Having a good knowledge of accounting cycle helps in this regard.

The second thing to do as part of selecting and designing test of controls is to establish ‘assertions’ for each key components or high risk areas as identified in the first step above. For example, three key assertions made in sales cycle records are; (i) Occurrence or existence – sales did occur, (ii) Accuracy – sale are properly valued, (iii) Proper classification – sales transactions are correctly coded and classified. Knowing what these assertions are helps you as an auditor select and design the types (quantity and quality) of test of controls to be deployed.

The third step in building your test of controls is to identify controls that are in place to either prevent, detect or correct errors and frauds. A bank reconciliation is a very good example of a detective control that helps figure out an error or fraud after it might have occurred. You may have a look at this article on how to perform bank reconciliation using Microsoft excel formula if you don’t already know how to do so using excel. The use of reviews and exception reports are also useful detective controls that should form part of the tools in the war chest of internal auditors.

10 Fundamental bedrocks of test of controls – must have in test of control design

For test of control to be meaningful and useful, below are some of the fundamental issues that must be addressed by a test of control (remember that the aim of test of controls is to gather sufficient audit evidence);

1. Ensure that the system completely and accurately captures all relevant data
2. Ensure that test of controls is performed fairly regularly and consistently
3. Ensure that follow-ups and correctional procedures are taken very seriously
4. Ensure that cost of controls do not exceed the potential benefit to be derived from having such control
5. Ensure that all potentially significant errors are taken into consideration – this maybe challenging but doable.
6. Ensure that access is only granted to authorized people
7. Ensure that premises are under lock and keys when not manned by a security officer/ personnel
8. Ensure that no application (software) is changed without authorization and due process
9. Ensure that duties are adequately segregated.
10. Ensure that computer backups are taken

Many people that are relatively new in the field of audit usually get confused over which control to select for testing. You hear them say things like; there are too many controls, which do I test and at what frequency? Well, this is where professional judgement and experience comes into play. I will however give some tips in the next paragraph.

Factors to consider when selecting and designing test of controls

• Efficiency and effectiveness in gathering audit evidence: this simply means that we should strive to focus on controls that are more critical to our audit objective(s) and audit opinion
• Dual functions: the more assertions that a test of control is testing the better and more useful that control is.
• Value of assets involved: it will not make any economic sense to spend resources worth millions on testing controls around assets worth thousands
• Frequency of controls: how many times in a year are controls performed? A control performed daily for example will require more testing.
• Length of period under consideration: more tests is required for a process that takes longer time.
• Level of confidence placed on evidence: the more trust an auditor places on a control mechanism, the less tests is required.  
• Efficacy of controls when combined: lesser test is required when two or more controls are combined.
• Competence and qualifications of people operating or responsible for the control: we generally place high reliance on the output from systems that are manned by people that we perceived to possess the right skillsets.
• Prior experience: our past experience plays significant role in all that we do – designing a test of control will not be an exception.
• Time elapsed: it is important that test of controls is conducted early enough so as to allow for any adjustments in the level of substantive testing that is required.
• Control environment: tone at the top always dictates for other components of the overall control architecture of a business entity. The more supportive those charged with corporate governance are, the more likely your level of testing will be less.
• Gaps in control: there could be a period in a year when a company world have to make do with whatever resources they have. A good example is when a major control is bypassed simply because a key staff whose responsibility it is to ensure that the said control is operational.
• Level of access given to system users: more testing is required when there is evidence that users have multiple access. I have for example consulted for a small business where accounting department staff have access to raise an LPO (Local Purchase Order), generate GRV (Goods Received Voucher) and also process customer invoice. The worst part is that they did not see anything wrong with it. Needless to say that a lot more test of control is required here.
• Change in computer system: a lot of businesses especially the small to medium businesses do not understand the risks involved in not having a clear policy on computer applications program.

Techniques for testing controls

1. Enquiry
2. Observation
3. Inspection of physical evidence
4. Re-performance

Importance of test of controls documentation

• Very handy in time of litigation
• It shows tests performed
• Allows another auditor to replicate result
• Helps to review results and recommendations before finalizing

I hope you enjoyed reading this article on how to select and design test of controls as much as I enjoyed writing it. You can also check out my article on planning for audit engagement for further insights.