Evaluating the Design and Implementation of Programmed and Manual Controls

Chapter 6, "Business Application System Development, Acquisition, Implementation, and Maintenance," discussed the review of general controls, which include the controls over project and change management, systems development, operations and maintenance, and network operations. This section discusses application controls, which relate directly to the functions (input, processing, and output) performed by applications. Application controls are used to ensure that only accurate, complete, and authorized data is entered into a system. These controls can be either manual or automated and ensure the following:

• Valid, accurate, and complete data is entered into the system.

• Processing of data is accurate and performs the function(s) it was created for.

• The processing of data and results meet expectations.

• The data is maintained to ensure validity, accuracy, and completeness.

Manual controls include checks performed by IT staff and IS auditors such as the review of error logs, reconciliations, and exception reports. Automated controls include programming logic, validation and edit checks, and programmed control functions.

ISACA recommends that the testing of automated controls include the use of manual procedures to ensure proper investigation of exceptions and that the IS auditor's tasks include the following:

• Identifying application components and transaction flow through those components, and gaining an understanding of the system by reviewing system documentation and performing interviews

• Applying the appropriate audit procedures to test control strengths and weaknesses, and evaluate the impact of control weaknesses

• Analyzing test results and audit evidence to determine whether the control objectives were achieved within the control environment

• Ensuring the application's operational effectiveness and efficiency by comparing the application with efficient programming standards, and comparing systems functionality to management objectives for the system

Business Process Controls

The IS auditor should use a combination of manual review (system documentation and logs), observations, integrated test facilities, and embedded audit modules. The IS auditor must review application controls, data integrity controls, and controls associated with business systems and components. These components might include electronic data interchange (EDI) and electronic funds transfers (EFT).

In reviewing application controls, the IS auditor should review the following areas:

• Input/output controls

  • Input authorization

  • Batch controls

• Processing control procedures

  • Processing

  • Validation

  • Editing

• Output controls

  • Critical forms logging and security

  • Negotiable instruments logging and security (signatures)

  • Report distribution

  • Balancing and reconciliation

  • Output error handling

  • Output report retention

An IS auditor must first understand relative business processes before performing an application audit. This can be accomplished by reviewing the business plan, the IT strategic plan (long and short term), and organizational goals.

Input/Output Controls

In auditing input and output controls, the auditor must ensure that all transactions have been received, processed, and recorded accurately, and that the transactions are valid and authorized. The auditor should review access controls and validation and edit checks. It is important to remember that in an integrated environment, the output of one system could be the input to another system. Input/output controls should be implemented for both the sending and receiving applications.

Input Authorization

Input can be either automated or manual, and it ensures that only authorized transactions are entered into the system for processing. Manual controls can include reports generated by the system that list transactions requiring manual authorization or source documents containing signatures. Some systems employ an automated control to provide authorization for data exceptions. An example is a sales transaction in which the price of the product is being reduced. The salesperson might not be authorized to reduce the price, but an automated request could be sent to a supervisor. The supervisor would then log in with a second-level password to authorize the price change.

A second-level password is an automated process to facilitate the approval of transaction data exceptions.

When using manual controls, the organization must ensure that all documents are controlled and that procedures exist to ensure that they have been accounted for. Automated access controls include the following:

• Online controls Authorized individuals or systems are authenticated before performing sensitive functions

• Client identification Specific workstations and individuals are authenticated before performing sensitive functions

Batch Controls

A batch control transaction summarizes totals of transactions within a batch. This transaction can be based on monetary amount, total items, total documents, or hash totals. These totals can be compared to the source documents to ensure that all items have accurate input. In addition, control totals ensure that the data input is complete and should be implemented as early as data preparation to support data integrity. Hash totals are generated by selecting specific fields in a series of transactions or records. If a later summation does not produce the number, this indicates that records have been lost, entered or transmitted incorrectly, or duplicated.

Hash totals are used as a control to detect loss, corruption, or duplication of data.

Processing, Validation, and Editing

Data validation is used to identify errors in data regarding completeness, inconsistencies, duplicates, and reasonableness. Edit controls perform the same function as data-validation controls but are generally used after data has been entered but before it is processed. Table 7.2, created by ISACA, describes edit checks.

Table 7.2. Data-Validation Edits and Controls

Validation Edits	Description
Sequence check	A sequence check ensures that data falls within a range sequence and that no values are missing or outside the sequence range. The sequence check uses the last known valid number as the first number and the last number in the sequence, and ensures that data falls sequentially within that range. An example would be to ensure that all check numbers in a system fall within an acceptable range (such as 1100) and that all checks fall within that range, with no missing checks.
Limit check	A limit check verifies that the data in the transaction does not exceed a predetermined limit.
Range check	A range check verifies that data is within a predetermined range of values. An example would be a check to ensure that the data falls between two dates (such as 1/1/2005 and 6/1/2005).
Validity check	A validity check uses predetermined criteria to check data validity.
Reasonableness check	A reasonableness check is a data-validation edit control that matches input data to an occurrence rate. In other words, the data is within reasonable limits.
Table look-ups	This check ensures that data entered complies with predetermined values in a corresponding table.
Existence check	An existence check ensures that required data is entered correctly according to predetermined criteria.
Key verification	Key verification is an edit check ensuring input integrity by having initial input re-entered by a second employee before the transaction can occur.
Check digit	A check digit is an effective edit check to detect data transposition and transcription errors. A check digit is a sum of the numeric value of the data and is appended to the data to ensure that the original data has not been altered or is not incorrect.
Completeness check	A completeness check is an edit check to determine whether a field contains valid data and is not null or filled with zeros or blanks.
Duplicate check	A duplicate check ensures that the new data being input does not already exist as a prior transaction.
Logical relationship check	A logical relationship utilizes logic, in that if a particular condition is true, one or more additional conditions or data-input relationships might be required to be true. Performing a check for logical relationships is useful for detecting errors such as incorrect birth dates or marriage dates.

Data edits are implemented before processing and are considered preventative integrity controls.

During the review of input processing, the IS auditor can compare the transaction journal to authorized source documents. The transaction journal records all transaction activity and provides the information necessary for detecting unauthorized input from a terminal and completeness of transactions.

Processing Control Procedures

Processing controls ensure that data is accurate and complete, and is processed only through authorized routines. The processing controls can be programmed controls that detect and initiate corrective action, or edit checks that ensure completeness, accuracy, and validity. Processing controls also include manual controls, such as these:

• Manual recalculation Periodic sample transaction groups can be recalculated to ensure that processing is performing as expected.

• Run-to-run totals These verify data values throughout the various stages of application processing. They are an effective control to detect accidental record deletion in transaction-based applications.

Output Controls

Output controls ensure that information resulting from processing will be delivered in a consistent and secure manner to authorized persons. Per ISACA, output controls include the following:

• Logging and storage of negotiable, sensitive, and critical forms in a secure place. These types of forms should be properly logged and secured to protect against theft or damage.

• Computer generation of negotiable instruments, forms, and signatures. This type of output should be properly controlled. The organization should enable logging to provide a detailed listing of generation, and it should be compared with the forms received.

• Report distribution. Reports can be distributed manually or automatically, but they should follow authorized distribution procedures. All reports should be logged. When automatic reports are distributed either electronically or to print devices, access-control procedures should ensure that only authorized personnel have access to the reports.

• Balancing and reconciling. All output from applications should be logged via transaction logs. The output should be routinely balanced to control totals.

• Output error handling. Procedures should exist for the controlling, logging, and reporting of output errors. The output transaction originators should be notified of errors in a timely manner for review and error correction.

• Output report retention. Policies and procedures regarding record retention should be adhered to. The retention policy should ensure compliance with any legal regulations.

Data Integrity Controls

Data is stored in the form of files and databases. Data integrity testing ensures the completeness, accuracy, consistency, and authorization of data. This differs from application testing because it tests data that is stored within a system after input and processing. The testing of stored data might uncover weaknesses in input/output or processing controls. Two types of tests are associated with data integrity:

• Referential integrity tests Referential integrity works within a relational data model within a database and ensures that the relationships between two or more references are consistent. If the data in one reference is inserted, deleted, or updated, the integrity to the second reference is maintained through the use of primary and foreign keys.

  Disabling referential integrity controls can result in invalid transactions, such as a payment to a vendor that is never recorded to the vendor payment database.

• Relational integrity tests These tests ensure that validation (either application or database) routines check data before entry into the database.

Electronic Data Interchange (EDI)

The purpose of EDI is to promote a more efficient and effective data-exchange process by reducing paper, errors, and delays. In using EDI, organizations with dissimilar computer systems facilitate the exchange and transmittal of information such as product orders, invoices, and business documents. This is accomplished through standardizing the format of data and transmitting the data between systems. Organizations must ensure proper authentication techniques for sending and receiving data between EDI systems, to prevent unauthorized transactions. Transaction authorization is a primary security concern in EDI environments.

Traditionally, EDI systems contain the following components:

• Communications handler A process for transmitting and receiving electronic documents between trading partners via dial-up lines, the Public Switched Telephone Network (PSTN), multiple dedicated lines, or value-added networks.

  

  
  

  A communications handler is an EDI component that transmits and receives documents.

  
  

• EDI interface This manipulates and routes data between the application system and the communications handler.

• EDI translator This translates between data formats.

• Applications interface This moves transactions to or from the application systems and performs data mapping. The EDI interface can ensure the validity of transactions and trading partners by checking information against a trading partner master file. After validation, the EDI interface generates and sends a functional acknowledgment. A functional acknowledgment is a message transmitted from the receiver of an electronic submission to the sender; it notifies the sender that the document was received/processed or was not processed. Functional acknowledgments provide an audit trail for EDI transactions.

Functional acknowledgments can be implemented in the EDI interface to provide efficient data mapping.

• Application system This processes the data sent to or received from a trading partner.

When reviewing an EDI environment, it is important to remember that the EDI environment consists of software that transmits, translates, and stores transactions for processing. Network environments can often add to the complexity of program-to-program communication, making application systems implementation and maintenance more difficult.

Organizations that exchange data via EDI should have a trading partner agreement. The trading partner agreement defines the responsibilities of both organizations with regard to the handling and processing of transactions. The IS auditor should ensure that all transactions are accurately sent and received, translated, processed once, and accessed by authorized parties.

ISACA recommends the following tasks for the IS auditor in reviewing EDI controls:

• Inbound EDI transactions that use public Internet infrastructures should utilize encryption to ensure confidentiality, authenticity, and integrity.

• All inbound EDI transactions should be logged. Edit checks should be used to identify erroneous, unusual, or invalid transactions.

• Inbound and outbound transaction message counts (sent/received) should be logged and periodically reconciled between trading partners.

• Outbound EDI transactions should be compared to the trading partner master file before transmission, to ensure that transactions are being sent to authorized trading partners.

• Authority to initiate, authorize, and transmit transactions should be properly segregated.