Computer System Controls

1 Types of control activities

YouTube videoLoad YouTube video

There are two broad groupings of control activities in information processing

• General IT controls
  

• Information processing controls
  

General IT controls include controls over the access to the computer and its records, the development of programs, prevention of unauthorised changes to systems, maintaining backup files, antivirus programs and firewall defences. Such controls are 'general' because they support many applications (e.g. inventory management, payroll processing, trade receivables, etc).

It is probably worth pointing out at this stage the dangers that are inherent in poor development or unauthorised changes in programs. For example if I wanted to commit a fraud through the salary system, there are two ways. First I could change my salary (i.e. change data) so that every time I was paid, I would be paid too much. That’s an easy but very obvious way of committing a fraud. The second way is to change the salaries program so that when my personnel number is being processed, my salary is increased. That needs a simple ‘if – then’ statement: if my personnel number then increase salary by, say, 25%. Numerically that will work just as well, but will be a 'better' fraud because it will be much more difficult to detect how it was done.

Although this has been dramatised using fraud, the greater potential of improperly authorised program changes lies in simple mistakes. If you alter a program, for example, the wages and salary income tax calculations or the VAT calculations, so the amounts of tax are incorrectly calculated, then the organisation can be liable for very large penalty payments to the tax authorities.

Information processing controls are "designed to ensure the integrity of the accounting records" (i.e. transactions occurred, are authorised and completely and accurately processed and recorded). They may be:

• Manual or automated
  

• Preventative or detective.
  

Examples of specific applications include sales, purchases, wages and salaries. You need controls over:

• The initiation of input
  

• Recording the transactions
  

• Processing of transactions
  

• Reporting output
  

2 Input controls

Control over input is particularly important as once a transaction gets into a computerised system, often there is no further human intervention. Therefore, if incorrect data is input, there is a high chance that it will be processed to its conclusion. Think GIGO ('garbage in, garbage out').

Input controls generally aim to ensure completeness (C) and/or accuracy (A). Methods include:

As described, these input controls may be described as preventative.

3 Controls over standing data

Standing data, sometimes called reference data, is data which doesn’t change very much but which is used or referred to many times. A good example is the selling price of a product or wage rate for an employee or discount rate for a customer. The problem is that once these amounts are put in, they tend not to be examined continually by employees. A price once set up could last for many months and if it’s wrong can affect many invoices. So you have this rather unfortunate situation where the data once input is then subsequently largely ignored by the people involved, but it is capable of producing errors over and over and over again.

The only way we can be sure that that data is correct is to take deliberate steps to check it. So some organisations print out their standing data, perhaps 10% every month, and distribute that to people who should know whether or not it is correct. These people sign off the print-outs to certify that the data appears to be right.

4 Processing controls

With respect to processing controls, really we want to know what processing has been done, and ideally we would like some indication if processing appears to be odd or out of sequence. As a simple example, let’s say that the wages and salary accountant is off sick towards the end of the month. How do you know whether or not that month’s payroll has been run? You don’t want to do it twice, but if you don’t do it at all employees will be very upset. Therefore, some kind of trace needs to be kept of what processing has been done, when it was done and, ideally, showing by whom.

Run logs and transaction logs can do this. Run logs give a high-level description of the processing which has been performed. For example it might say monthly salaries run 29th of July, 1:45 p.m. initiated by J. Smith.

Run logs should be scrutinized regularly by a responsible official to look for runs which appeared to be odd, out of sequence or initiated by unexpected people. Transaction logs are also sometimes produced. These are much more detailed printouts of exactly what transactions have been input and processed. For example, a transaction log might simply be a printout of all dispatches which have been turned into invoices in the week or all timesheets which have been submitted. These would not normally be scrutinized as a matter of course, but can be looked at if the run logs appear to show something which is suspicious.

5 Output controls

Output controls ensure that the results of the processing are complete and accurate. When batch processing is used, agreeing the total of the output to the pre-determined control total of the input is a control over the completeness and accuracy of processing the data. If it does not agree, it must be investigated. An ‘exception report’ may show:

• ‘data no file’ giving rise to rejected transactions (e.g. a payslip for a new employee not generated because the employee is not yet on the payroll), or
  

• ‘file no data’ flagging that input may be missing (e.g. no hours for an employee who has left but has not yet been taken off the payroll).
  

Controlled resubmission of rejected transaction is also an output control.

Output controls should also ensure that the results of processing are properly distributed. Output may be seen on a VDU/screen (that would be soft output), or could be printed (that’s hard output). Control over access to output can be established by the use of passwords if displayed on a VDU. If it’s printed, then you rely on the normal confidential ways of distributing confidential printed material: it should be put in envelopes, there should be a check on the number of copies produced, the date of production of the printout should also be present otherwise you can get confused between different editions, and the pages should be numbered. If the pages aren’t numbered, you won’t know whether or not you got all the printout, some printouts put ‘End of Report’ at the bottom of the last page so users know that some pages haven’t become detached.