Chapter Six Control &AIS
Chapter Six Control &AIS
Preventive Controls: Prevention is the first line of defense in the control structure. Preventive
controls are passive techniques designed to reduce the frequency of occurrence of undesirable
events. Preventive controls force compliance with prescribed or desired actions and thus screen
out abnormal events. When designing internal control systems, an ounce of prevention is most
certainly worth a pound of cure. Preventing errors and fraud is far more cost-effective than
detecting and correcting problems after they occur. The vast majority of undesirable events can
be blocked at this first level. For example, a well-designed source document is an example of a
preventive control. The logical layout of the document into zones that contain specific data, such
as customer name, address, items sold, and quantity, forces the clerk to enter the necessary data.
The source documents can therefore prevent necessary data from being omitted. However, not all
problems can be anticipated and prevented.
Detective Controls: Detective controls form the second line of defense. These are devices,
techniques, and procedures designed to identify and expose undesirable events that elude
preventive controls. Detective controls reveal specific types of errors by comparing actual
occurrences to pre-established standards. When the detective control identifies a departure from
standard, it sounds an alarm to attract attention to the problem. For example, assume a clerk
entered the following data on a customer sales order:
Quantity Price Total
. 10 $10 $1,000
Before processing this transaction and posting to the accounts, a detective control should
recalculate the total value using the price and quantity (i.e. $100). Thus the error in total price
would be detected.
Corrective Controls: Corrective controls are actions taken to reverse the effects of errors
detected in the previous step. There is an important distinction between detective controls and
corrective controls. Detective controls identify anomalies and draw attention to them; corrective
controls actually fix the problem. For any detected error, however, there may be more than one
feasible corrective action, but the best course of action may not always be obvious. For example,
in viewing the error above, your first inclination may have been to change the total value from
$1,000 to $100 to correct the problem. This presumes that the quantity and price values on the
document are correct; they may not be for instance the quantity could be 100 units. At this point,
we cannot determine the real cause of the problem; we know only that one exists. Linking a
corrective action to a detected error, as an automatic response, may result in an incorrect action
that causes a worse problem than the original error. For this reason, error correction should be
viewed as a separate control step that should be taken cautiously.
6.2.1 Application Controls: The objectives of application controls are to ensure the validity,
completeness, and accuracy of financial transactions. These controls are designed to be
application-specific. Examples include: A cash disbursements batch balancing routine that
verifies that the total payments to vendors reconciles with the total postings to the accounts
payable subsidiary ledger. An account receivable check digits procedure that validates customer
account numbers on sales transactions. A payroll system limit check that identifies employee time
card records with reported hours worked in excess of the predetermined normal limit. Application
controls are associated with specific applications, such as payroll, purchases and cash
disbursements systems. These fall into three broad categories: input controls, processing controls,
and output controls.
6.2.1.1 Input Controls: Input controls are programmed procedures (routines) that perform tests on
transaction data to ensure that they are free from errors. Input control routines should be designed
into the system at different points, depending on whether transaction processing is real time or
batch. Input controls in real-time systems are placed at the data collection stage to monitor data as
they are entered from terminals. Batch systems often collect data in transaction files, where they
are temporarily held for subsequent processing. In this case, input control tests are performed as a
separate procedure (or run) prior to the master file update process
6.2.1.2 Processing Controls: After passing through the data input stage, transactions enter the
processing stage of the system. Processing controls are programmed procedures and may be
divided into three categories: batch controls, run-to-run controls, and audit trail controls.
6.2.1.3 Output Controls: Output controls are a combination of programmed routines and other
procedures to ensure that system output is not lost, misdirected, or corrupted and that privacy is
not violated. Exposures of this sort can cause serious disruptions to operations and may result in
financial losses to a firm. For example, if the checks a firm’s cash disbursements system produces
are lost, misdirected, or destroyed, trade accounts and other bills may go unpaid. This could
damage the firm’s credit rating and result in lost discounts, interest, or penalty charges. If the
privacy of certain types of output is violated, a firm could have its business objectives
compromised or could become exposed to litigation.
6.2.2 General controls: The second broad group of controls that COSO identifies is general controls.
They are so named because they are not application-specific but, rather, apply to all systems.
General controls have other names in other frameworks, including general computer controls and
information technology controls. Whatever name is used, they include controls over IT
governance, IT infrastructure, security and access to operating systems and databases, application
acquisition and development, and program changes. Whereas general controls do not control
specific transactions, they have an effect on transaction integrity. For example, consider an
organization with poor database security controls. In such a situation, even data processed by
systems with adequate built in application controls may be at risk. An individual who is able to
circumvent database security (either directly or via a malicious program), may then change, steal,
or corrupt stored transaction data. Thus, general controls are needed to support the functioning of
application controls, and both are needed to ensure accurate financial reporting.
6.2.2.1 IT Governance Control: IT governance is a broad concept relating to the decision rights and
accountability for encouraging desirable behavior in the use of IT. Though important, not all
elements of IT governance relate specifically to control issues that SOX addresses and that are
outlined in the COSO framework. In this section, we consider three governance issues that do:
organizational structure of the IT function. The discussion on each of these governance issues
begins with an explanation of the nature of risk and a description of the controls needed to
mitigate the risk.
6.2.2.2 Organizational structure: control Previous sections have stressed the importance of
segregating incompatible duties within manual activities. Specifically, operational tasks should
be separated to: 1. Segregate the task of transaction authorization from transaction processing.
2. Segregate record keeping from asset custody. 3. Divide transaction-processing tasks among
individuals so that fraud will require collusion between two or more individuals. The tendency in
an IT environment is to consolidate activities. A single application may authorize, process, and
record all aspects of a transaction. Thus, the focus of segregation control shifts from the
operational level (transaction processing tasks that computer programs now perform) to
higher level organizational relationships within the IT function. The interrelationships among
systems development, application maintenance, database administration, and computer
operations activities are of particular concern. The following section examines organizational
control issues within the context of two generic models. (i.e. the centralized model and the
distributed model).