LIST OF APPLICATION CONTROLS

Note: The following is a general outline of application controls (source: “IT Assurance Guide Using COBIT”). In the case of robust IT applications, the auditor should identify
other application controls in accordance with the financial regulatory framework after evaluating the complexity of the application and the related IT risks.

A. SOURCE DATA PREPARATION AND AUTHORISATION

Control Objectives Application control requirements

Control Objective: Ensure that source 1. Design source documents in a way that they increase accuracy with which data can be recorded, control the
documents are prepared by authorised workflow and facilitate subsequent reference checking. Where appropriate, include completeness controls in
and qualified personnel following the design of the source documents.
established procedures, taking into
2. Create and document procedures for preparing source data entry, and ensure that they are effectively and
account adequate segregation of duties
properly communicated to appropriate and qualified personnel. These procedures should establish and
regarding the origination and approval
communicate required authorisation levels (input, editing, authorising, accepting and rejecting source
of these documents.
documents). The procedures should also identify the acceptable source media for each type of transaction.
Errors and omissions can be minimised
3. Ensure that the function responsible for data entry maintains a list of authorised personnel, including their
through good input form design.
signatures.
Detect errors and irregularities so they
4. Ensure that all source documents include standard components, contain proper documentation (e.g.,
can be reported and corrected.
timeliness, predetermined input codes, default values) and are authorised by management.
References to regulatory framework:
5. Automatically assign a unique and sequential identifier (e.g., index, date and time) to every transaction.
IR Art. 22a(1)(d), 48 (f) and 107; ICS7,
ICS12 and ICS13. 6. Return documents that are not properly authorised or are incomplete to the submitting originators for
correction, and log the fact that they have been returned. Review logs periodically to verify that corrected
Related information criteria: Integrity
documents are returned by originators in a timely fashion, and to enable pattern analysis and root cause
and efficiency.
review.
B. SOURCE DATA COLLECTION AND ENTRY
Control Objectives Application control requirements

Control Objective: Ensure that data 1. Define and communicate criteria for timeliness, completeness and accuracy of source documents.
input is performed in a timely manner Establish mechanisms to ensure that data input is performed in accordance with the timeliness, accuracy
by authorised and qualified staff. and completeness criteria.

Correction and resubmission of data 2. Use only pre-numbered source documents for critical transactions. If proper sequence is a transaction
that were erroneously input should be requirement, identify and correct out-of-sequence source documents. If completeness is an application
performed without compromising requirement, identify and account for missing source documents.
original transaction authorisation
3. Define and communicate who can input, edit, authorise, accept and reject transactions, and override
levels.
errors. Implement access controls and record supporting evidence to establish accountability in line with
Where appropriate for reconstruction, role and responsibility definitions.
retain original source documents for the
4. Define procedures to correct errors, override errors and handle out-of-balance conditions, as well as to
appropriate amount of time.
follow up, correct, approve and resubmit source documents and transactions in a timely manner. These
procedures should consider things such as error message descriptions, override mechanisms and
escalation levels.
References to regulatory framework:
IR Art. 22a(1)(d), 48 (f,g), and 107; ICS7 5. Generate error messages in a timely manner as close to the point of origin as possible. The transactions
and ICS13. should not be processed unless errors are corrected or appropriately overridden or bypassed. Errors that
cannot be corrected immediately should be logged in an automated suspense log, and valid transaction
Related information criteria: Integrity
processing should continue. Error logs should be reviewed and acted upon within a specified and
reasonable period of time.

6. Ensure that errors and out-of-balance reports are reviewed by appropriate personnel, followed up and
Control Objectives Application control requirements

corrected within a reasonable period of time, and, where necessary, incidents are raised for more senior-
level attention. Automated monitoring tools should be used to identify, monitor and manage errors.

7. Ensure that source documents are safe-stored (either by the business or by IT) for a sufficient period of
time in line with legal, regulatory or business requirements.

C. ACCURACY, COMPLETENESS AND AUTHENTICITY CHECKS

Control Objectives Application control requirements

Control Objective: Ensure that 1. Ensure that transaction data are verified as close to the data entry point as possible and interactively
transactions are accurate, complete during online sessions. Ensure that transaction data, whether people-generated, system-generated or
and valid. interfaced inputs, are subject to a variety of controls to check for accuracy, completeness and validity.
Wherever possible, do not stop transaction validation after the first error is found. Provide
Validate data that were input, and edit
understandable error messages immediately to enable efficient remediation.
or send back for correction as close to
the point of origination as possible. 2. Implement controls to ensure accuracy, completeness, validity and compliance to regulatory
requirements of data input. Controls may include sequence, limit, range, validity, reasonableness, table
look-ups, existence, key verification, check digit, completeness (e.g., total monetary amount, total items,

References to regulatory framework: total documents, hash totals), duplicate and logical relationship checks, and time edits. Validation criteria

FR Art. 28a (2)(b,c) and 61(e); IR Art. and parameters should be subject to periodic reviews and confirmation.

22a(1)(a,d), 48 (c,f),and 107; ICS7,

3. Establish access control and role and responsibility mechanisms so that only authorised persons input,
ICS12 and ICS13.
modify and authorise data.

Related information criteria: Integrity

4. Define requirements for segregation of duties for entry, modification and authorisation of transaction
and efficiency.
data as well as for validation rules. Implement automated controls and role and responsibility
requirements.

5. Report transactions failing validation and post them to a suspense file. Report all errors in a timely
fashion and do not delay processing of valid transactions.

6. Ensure that transactions failing edit and validation routines are subject to appropriate follow-up until
errors are remediated. Ensure that information on processing failures is maintained to allow for root
cause analysis and help adjust procedures and automated controls.
D. PROCESSING INTEGRITY AND VALIDITY
Control Objectives Application control requirements

Control Objective: Maintain the 1. Establish and implement mechanisms to authorise the initiation of transaction processing and to ensure
integrity and validity of data that only appropriate and authorised applications and tools are used.
throughout the processing cycle.
2. Routinely verify that processing is completely and accurately performed with automated controls,
Detection of erroneous transactions where appropriate. Controls may include checking for sequence and duplication errors,
does not disrupt the processing of valid transaction/record counts, referential integrity checks, control and hash totals, range checks and buffer
transactions. overflow.

3. Ensure that transactions failing validation routines are reported and posted to a suspense file. Where a
file contains valid and invalid transactions, ensure that the processing of valid transactions is not delayed
References to regulatory framework:
and all errors are reported in a timely fashion. Ensure that information on processing failures is kept to
FR Art. 28a (2) (b,c) and 61(e); IR Art.
allow for root cause analysis and help adjust procedures and automated controls, to ensure early
22a(1) (a,d), 48 (c,f),and 107; ICS7,
detection or prevent errors.
ICS12 and ICS13.
4. Ensure that transactions failing validation routines are subject to appropriate follow-up until errors are
Related information criteria: Integrity,
remediated or the transaction is cancelled.
confidentiality, and availability.
5. Ensure that the correct sequence of jobs has been documented and communicated to IT operations. Job
output should include sufficient information regarding subsequent jobs to ensure that data are not
inappropriately added, changed or lost during processing.

6. Verify the unique and sequential identifier to every transaction (e.g., index, date and time).

7. Maintain the audit trail of transactions processed. Include date and time of input and user identification
Control Objectives Application control requirements

for each online or batch transaction. For sensitive data, the listing should contain before and after
images and should be checked by the business owner for accuracy and authorisation of changes made.

8. Maintain the integrity of data during unexpected interruptions in data processing with system and
database utilities. Ensure that controls are in place to confirm data integrity after processing failures or
after use of system or database utilities to resolve operational problems. Any changes made should be
reported and approved by the business owner before they are processed.

9. Ensure that adjustments, overrides and high-value transactions are reviewed promptly in detail for
appropriateness by a supervisor who does not perform data entry.

10. Reconcile file totals. For example, a parallel control file that records transaction counts or monetary
value as data should be processed and then compared to master file data once transactions are posted.
Identify,, report and act upon out-of-balance conditions.
E. OUTPUT REVIEW, RECONCILIATION AND ERROR HANDLING
Control Objectives Application control requirements

Control Objective: Establish procedures 1. When handling and retaining output from IT applications, follow defined procedures and consider
and associated responsibilities to privacy and security requirements. Define, communicate and follow procedures for the distribution of
ensure that output is handled in an output.
authorised manner, delivered to the
2. At appropriate intervals, take a physical inventory of all sensitive output, such as negotiable instruments,
appropriate recipient and protected
and compare it with inventory records. Create procedures with audit trails to account for all exceptions
during transmission; verification,
and rejections of sensitive output documents.
detection and correction of the
accuracy of output occur; and 3. Match control totals in the header and/or trailer records of the output to balance with the control totals
information provided in the output is produced by the system at data entry to ensure completeness and accuracy of processing. If out-of-
used. balance control totals exist, report them to the appropriate level of management.

4. Validate completeness and accuracy of processing before other operations are performed. If electronic
output is reused, ensure that validation has occurred prior to subsequent uses.
References to regulatory framework:
FR Art. 28a 2(b,c), Art. 61(e); IR Art. 48 5. Define and implement procedures to ensure that the business owners review the final output for
(f) and 108; ICS7, ICS12 and ICS13. reasonableness, accuracy and completeness, and output is handled in line with the applicable
confidentiality classification. Report potential errors; log them in an automated, centralised logging
facility; and address errors in a timely manner.
Related information criteria: Integrity,
6. If the application produces sensitive output, define who can receive it, label the output so it is
confidentiality, availability and
recognisable by people and machines, and implement distribution accordingly. Where necessary, send it
effectiveness.
to special access-controlled output devices.
 F. TRANSACTION AUTHENTICATION AND INTEGRITY

Control Objectives Application control requirements

Control Objective: Before passing 1. Where transactions are exchanged electronically, establish an agreed-upon standard of communication
transaction data between internal and mechanisms necessary for mutual authentication, including how transactions will be represented,
applications and business/ operational the responsibilities of both parties and how exception conditions will be handled.
functions (within or outside the
2. Tag output from transaction processing applications in accordance with industry standards to facilitate
enterprise), check the data for proper
counterparty authentication, provide evidence of non-repudiation and allow for content integrity
addressing, authenticity of origin and
verification upon receipt by the downstream application.
integrity of content.

3. Analyse input received from other transaction processing applications to determine authenticity of origin
Maintain authenticity and integrity
and the maintenance of the integrity of content during transmission.
during transmission or transport.

References to regulatory framework:

FR Art. 28a 2(c) and 48 (f); ICS7, ICS12
and ICS13.

Related information criteria: Integrity

and confidentiality.