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.

A. Batch controls: are used to manage the flow of high volumes of transactions through batch
processing systems. The objective of batch control is to reconcile system output with the input
originally entered into the system. This provides assurance that:

 All records in the batch are processed.

 No records are processed more than once.
 An audit trail of transactions is created from input through processing to the output stage
of the system.

Batch control begins at the data input stage and continues through all data processing phases of
the system. Batch control involves grouping together into batches similar types of transactions
(such as sales orders) and controlling them as a unit of work throughout data processing. To
achieve this, a batch control record is created when the batch of transactions is entered into the
179 system. This may be a user department action or a separate data control step. The control
record contains relevant information about the batch, such as:

 A unique batch number.

 A batch date.
 A transaction code (indicating the type of transactions, such as a sales order or cash
receipt).
 The number of records in the batch (record count).
 The total dollar value of a financial field (batch control total).
 The total of a unique nonfinancial field (hash total).

Figure 6.1. depicts a batch control record in relation to the batch of transactions it describes. The
data in the control record are used to assess the integrity of the batch during all subsequent
processing. For example, the batch control record in the figure shows a batch of 50 sales order

records with a total dollar value of $122,674.87 and a hash total of 4537838.

B. Run-to-run control: is the use of batch figures to monitor the batch as it moves from one
programmed procedure (run) to another. Thus at various points throughout processing and at
the end of processing, the batch totals are recalculated and compared to the batch control
record. This ensures that each run in the system processes the batch correctly and completely.
This application comprises four runs: (1) data input, (2) accounts receivable update, (3) inventory
update, and (4) output. At the end of the accounts receivable run, batch control figures are
recalculated and reconciled with the control totals passed from the data input run.

These figures are then passed to the inventory update run, where they are again recalculated,
reconciled, and passed to the output run. Errors detected in each run are flagged and placed in
an error file. The run batch control figures are then adjusted to reflect the deletion of these
records.

Errors detected during processing require careful handling, because these records may already
be partially processed. Simply resubmitting the corrected records to the system at the data input
stage may result in processing portions of these transactions twice.

C
.

Audit trail controls: in an IT environment ensure that every transaction can be traced through
each stage of processing from its economic source to its presentation in financial statements.
The following are examples of audit trail control.
 Transaction Logs: Every transaction the system successfully processes should be
recorded on a transaction log, which serves as a journal.

First, the transaction log is a permanent record of transactions, though the input transaction file
is typically a temporary file. Once processed, the records on the input file are erased to make
room for the next batch of transactions. Second, not all of the records in the input file may be
successfully processed. Some of them will fail tests during subsequent processing and will be
passed to an error file.

Log of Automatic Transactions: The system triggers some transactions internally. For
example, when inventory drops below the reorder point, the system automatically generates a
purchase order. To maintain an audit trail of these activities, all internally generated transactions
must be placed in a transaction log.

Transaction Listings: The system should produce a (hard-copy) transaction listing of all
successful transactions. These listings should go to the appropriate users to facilitate
reconciliation with input. In addition, the responsible end user should receive a detailed listing of
all internally generated transaction

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.
A. Controlling Hard Copy Output Batch systems usually produce hard copy, which typically
requires the involvement of intermediaries in its production and distribution.

Output Spooling: In large-scale data processing operations, output devices such as line
printers can become backlogged with many programs simultaneously demanding limited
resources. This can cause a bottleneck and adversely affect system throughput. To ease this
burden, applications are often designed to direct their output to a magnetic disk file rather than
print it directly. This is called spooling.

The creation of an output file as an intermediate step in the printing process presents an added
exposure. A computer criminal may use this opportunity to:

1. Access the output file and change critical data values (such as dollar amounts on checks).
The
2. printer program will then print the fallacious output as if the system produced it.
3. Access the file and change the number of copies of output to be printed. The extra copies
may
4. then be removed without notice during the printing stage.
5. Make a copy of the output file to produce illegal output reports.
6. Destroy the output file before output printing takes place.

Print Programs: When a printer becomes available, the print run program produces hard-copy
output from the output file. Print programs are often complex systems that require operator
intervention. Four common types of operator actions are:

1. Pausing the print program to load the correct type of output documents (check
stocks, invoices, or other special forms).
2. Entering parameters that the print run needs, such as the number of copies to be
printed.
3. Restarting the print run at a prescribed checkpoint after a printer malfunction.
4. Removing printed output from the printer for review and distribution.
Print program controls should be designed to deal with two types of exposures present in this
environment: (1) the production of unauthorized copies of output and (2) employee browsing of
sensitive data. Some print programs allow the operator to specify more copies of output than the
output file calls for, which allows for the possibility of producing unauthorized copies of output. At
the end of the run, the number of copies the output file specifies should be reconciled with the
actual number of output documents used.

Waste: Computer output waste is a potential source of exposure. Aborted reports and the carbon
copies from multipart paper need to be disposed of properly. Computer criminals disguised as
janitorial staff have been known to sift through trash cans searching for are Lesly discarded
output that is presumed to be of no value.

rom such trash, computer criminals may obtain information about a firm‘s market research, credit ratings of its
customers, or even trade secrets, which they can sell to a competitor.

To control against this threat, all sensitive computer output should be passed through a paper
shredder. Report Distribution: The primary risks associated with the distribution of sensitive
reports include their being lost, stolen, or misdirected in transit to the user. The following control
techniques can be used:

1. The reports may be placed in a secure mailbox to which only the user has the key.
2. The user may be required to appear in person at the distribution center and sign for the
report.
3. A security officer or special courier may deliver the report to the user

End-User Controls: Once in the hands of the user, output reports should be examined for correctness. Errors the user
detects should be reported to the appropriate computer services management. Such errors may be symptoms of an
improper systems design, incorrect procedures, errors accidentally inserted during systems maintenance, or
unauthorized access to data files or programs.

B. Controlling Digital Output

Digital output can be directed to the user‘s computer screen or printer. The primary output threat is the
interception, disruption, destruction, or corruption of the output message as it passes across the communications
network. This threat comes from two types of exposures: (1) exposures from equipment failure and (2) exposures from
subversive acts.

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.

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.

1. 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 higherlevel organizational relationships within the IT function. The
interrelationships among systems development, application maintenance, database administration, and computer
operations activities are of particular concern.

Separating Systems Development from Computer Operations

The segregation of systems development (both new systems development and maintenance) and operations activities is
of the greatest importance. The responsibilities of these groups should not be commingled. Systems development and
maintenance professionals acquire (by in-house development and purchase) and maintain systems for users.

Operations staff should run these systems and have no involvement in their design and implementation. Consolidating
these functions invites fraud. With detailed knowledge of an application‘s logic and control parameters along with
access to the computer operations, an individual could make unauthorized changes to application logic during
execution.

Separating the Database Administrator from Other Functions

Another important organizational control is the segregation of the database administrator (DBA) function from other IT
functions. The DBA is responsible for a number of critical tasks pertaining 187 to database security, including creating
the database schema, creating user views (subschemas), assigning access authority to users, monitoring database usage,
and planning for future expansion. Delegating these responsibilities to others who perform incompatible tasks threatens
database integrity.

Separating the DBA from Systems Development: Programmers create applications that access, update, and retrieve
data from the database. To achieve database access, therefore, both the programmer and the DBA need to agree as to
the attributes and tables (the user view) to make available to the application (or user) in question. If done properly, this
permits and requires a formal review of the user data needs and security issues surrounding the request.

Separating New Systems Development from Maintenance

Some companies organize their systems development function into two groups: systems analysis and programming. The
programming group codes the programs according to these design specifications. Under this approach, the programmer
who codes the original programs also maintains them during the maintenance phase of the systems development life
cycle (SDLC).
Inadequate Documentation: Poor-quality systems documentation is a chronic IT problem and a significant challenge for
many organizations seeking SOX compliance. There are at least two explanations for this phenomenon.

First, documenting systems is not as interesting as designing, testing, and implementing them. Systems professionals
much prefer to move on to an exciting new project rather than document one just completed.

The second possible reason for poor documentation is job security. When a system is poorly documented, it is difficult to
interpret, test, and debug. Therefore, the programmer who understands the system (the one who coded it) maintains
bargaining power and becomes relatively indispensable.

Program Fraud: When the original programmer of a system also has maintenance responsibility, the potential for fraud
is increased. Program fraud involves making unauthorized changes to program modules for the purpose of committing
an illegal act. The original programmer may have successfully concealed fraudulent code among the thousands of lines
of legitimate code and the hundreds of modules that constitute a system.

The programmer needs to protect the fraudulent code from accidental detection by another programmer performing
maintenance or by auditors testing application controls. Therefore, having sole responsibility for maintenance is an
important element in the duplicitous programmer‘s scheme.

Disabling fraudulent code during audits and then restoring the code when the coast is clear. Frauds of this sort may
continue for years without detection.

A Superior Structure for Systems Development

The new systems development group is responsible for designing, programming, and implementing new systems
projects. Upon successful implementation, responsibility for the system‘s ongoing maintenance falls to the systems
maintenance group. This structure helps resolve the two control problems described previously.

First, documentation standards are improved because the maintenance group will require adequate documentation to
perform their maintenance duties. Without complete documentation, the formal transfer of system responsibility from
new systems development to systems maintenance cannot occur.

Second, denying the original programmer future access to the application code deters program fraud. Fraudulent code
in an application, which is out of the perpetrator‘s control, increases the risk that the fraud will be discovered.