General vs Application Controls

Download Report

Transcript General vs Application Controls

Today’s Lecture

• application controls • audit methodology

• • • • • •

General vs Application Controls

general implemented consist. across all appl.

application are built into specific programs distinction often arbitrary - general are usually reviewed once for audit as a whole application must be considered for each significant application if general are uniformly strong and operate effectively obtain such assur. wrt each app.

if not, does not mean each appl. affected... need to consider app by app.

Application Controls

• hardware – parity checks, character checks • input and output controls – at source dep’t and data control • programmed controls (software)

Effective Design

• • • • • designed with regard to business requirements designed with regard to business risk analysis only rely upon after taking general controls into consideration use structured programming techniques use training

Types of Transactions • • • • each have different sensitivity and risk of errors master file changes - updated only periodically normal business applications error correction transactions

Master File Changes • • • • completeness, accuracy, currency and data authorization error would occur every time make sure using current masters important to guard against fraud

Normal Transactions • • • second largest concern necessary to control effectively need to include controls over regular transactions and reports

Error Correction Transactions • • • • watch bypass potential errors often put aside and ignored all should be logged with clear responsibility for correction ideally put back through regular processing

Preventive Controls over Processing • • • • • data entry as close to source of transact as possible to ensure familiarity structure operating procedures so that business activity not complete until transaction processing eliminate human component as much as possible authorize transactions before data entry use access control software

Preventive Controls over Processing (cont’d) • • • • • use 3 levels of access • physical access to terminal, access control over use of terminal and authorization in software scrutinize manually prepared input use computer to edit transactions • use edit progs to check for missing data, format, self checking digit, limits & logical relation checks use key verification & interactive systems use formatted input screens

Preventive Controls over Processing (cont’d) • • • • • use appropriately designed input forms single source transaction data - input once document application control procedures manuals, etc.

training and supervision adequate working conditions

Detective Controls • • • • • • use suspense records for impending transactions monitor & investigate lack of regular activity (see if transactions omitted) verify records by examining assets etc.

prepare budgets/investigate variances number transactions - check sequence group and count source documents and count # transactions processed

Detective Controls (cont’d) • • • • • • use control totals to check completeness reconcile changes in recorded assets and liabilities to transactions processed If practical, establish procedures for verification by users design programmed reasonableness tests match processing results to source documents in detail check computations

Detective Controls (cont’d) • • • • • use summary and exception reports use double entry recording to balance transactions agree summary records to detailed records require user approval of results require error tracking and analysis - develop stats

Master File Controls • • authorize all changes before input record changes to semi-permanent listings, reconcile changes • • • print out for review by knowledgeable users for errors use control totals application progs should internally label master files

Errors and Exception Controls • • • use error and exception reports - ensure follow- up user error logs and define correction procedures and responsibilities resubmit errors into NORMAL processing cycle - do not bypass

Management & Audit Trails • • • • • file each record in planned sequence to facilitate retrieval provide unique id for each record retain source copy for transactions provide methods of tracing data backwards and forwards through IS document retention procedures

Management & Audit Trails (cont’d) • • • use logs periodically copy and save permanent records that are overwritten by changes provide software capability to scrutinize & analyse data

Advanced System Characteristics • • • • • • • absence independent evidence no visible audit trails lack of auth evidence heavy I/C reliance need to understand transaction flow test controls to be relied upon audit hardware/software