Annual Audit Manual
COPYRIGHT NOTICE — This document is intended for internal use. It cannot be distributed to or reproduced by third parties without prior written permission from the Copyright Coordinator for the Office of the Auditor General of Canada. This includes email, fax, mail and hand delivery, or use of any other method of distribution or reproduction. CPA Canada Handbook sections and excerpts are reproduced herein for your non-commercial use with the permission of The Chartered Professional Accountants of Canada (“CPA Canada”). These may not be modified, copied or distributed in any form as this would infringe CPA Canada’s copyright. Reproduced, with permission, from the CPA Canada Handbook, The Chartered Professional Accountants of Canada, Toronto, Canada.
5035.4 Information processing objectives
Sep-2022
In This Section
CAS Guidance
Risks to the integrity of information arise from susceptibility to ineffective implementation of the entity’s information policies, which are policies that define the information flows, records and reporting processes in the entity’s information system. Information processing controls are procedures that support effective implementation of the entity’s information policies. Information processing controls may be automated (i.e., embedded in IT applications) or manual (e.g., input or output controls) and may rely on other controls, including other information processing controls or general IT controls (CAS 315.A6).
OAG Guidance
Information processing objectives (IPOs) provide a useful framework to help evaluate the design effectiveness of information processing controls within a business process or sub‑process to understand the input, processing, and recording of data. Within each business process and related transaction flows, it is of fundamental importance that controls are designed and implemented to verify that authorized transactions are recorded in a complete and accurate manner, and to prevent, or detect, unauthorized amendments. The four information processing objectives are summarized below:
|
Completeness (C) |
All transactions that occur are entered and accepted for processing once and only once and in the proper period. For example, duplicate entries are identified and rejected; all exceptions/rejections are addressed and resolved. |
|
Accuracy (A) |
Transactions are recorded at the correct amount in the appropriate account and proper period (the date input was correct). This includes accuracy of key data elements and standing data used in transaction processing. |
|
Validity (V) |
Only authorized transactions that actually occurred and are related to the organization are recorded. |
|
Restricted Access (R) |
Data is protected against unauthorized amendments and access to confidential data and physical assets is appropriately restricted to authorized personnel. It can be difficult to achieve the other three information processing objectives (Completeness, Accuracy, and Validity), when the restricted access objective is not met. |
Our understanding of IPOs/CAVR (Completeness, Accuracy, Validity and Restricted Access) supports our judgments about the design effectiveness of information processing controls within a business process or sub‑process. Our documentation of the business process and related sub‑processes underlying significant FSLIs (i.e., obtained and/or updated during planning) typically includes this information across all CAVR components (see table below), but explicit documentation of these considerations is not required.
The table below sets out the applicability of information processing objectives to the different types of controls:
|
Control type |
Guidance |
|
ITGCs |
ITGCs are not information processing controls, they operate at a level higher than business process controls. However, the design of ITGCs can support information processing objectives and controls. As explained in CAS 315.A150 the standard requires the auditor to identify and evaluate general IT controls for IT applications and other aspects of the IT environment that the auditor has determined to be subject to risks arising from the use of IT, because general IT controls support the continued effective functioning of information processing controls. A general IT control alone is typically not sufficient to address a risk of material misstatement at the assertion level. We apply professional judgement when identifying risks arising from the use of IT because not all IT‑dependencies in our audit will require us to conclude that they are “subject to risks arising from the use of IT”. See OAG Audit 5035.2—Identify entity’s ITGCs that address risks arising from the use of IT, for further guidance, including a flowchart to assist in making this judgement. |
|
Information processing |
A single information processing control may address multiple information processing objectives. If controls that address information processing objectives are effective, we then determine for which financial statement assertions those controls provide audit evidence. If an information processing objective at a particular stage of processing is not achieved, the data generated at that and subsequent stages of processing, as well as information derived from the data, may not be reliable. It may reflect events and transactions that did not occur, it may be incomplete, it may be mathematically inaccurate, or it may reflect assets or liabilities that do not exist. We need to consider the validity of the transaction; the completeness and accuracy of input wherever data is entered into the system; and whether the absence of controls designed to address the information processing objectives relating to the maintenance of files (integrity of standing data, completeness and accuracy of update, and completeness and accuracy of accumulated data) at each stage of processing could result in a material financial statement misstatement. In addition, we need to consider whether assets are protected against loss from errors and fraud (particularly misappropriation) in the processing of transactions and handling of related assets. Once we have concluded that the design of controls is appropriate to address the risk and that the controls are implemented, we may select the information processing controls we intend to test for operating effectiveness and determine for which financial statement assertions those controls provide audit evidence. Where missing or ineffective controls relating to the recording and processing of data could result in a material financial statement misstatement, consider how to respond to the resulting control deficiency and the resulting impact on the nature, timing and extent of our audit procedures. Also consider documentation and communication, including creation of a Control deficiencies/ weaknesses (Issue) (see OAG Audit 6057), reporting this deficiency to management, and, when appropriate, those charged with governance. |
| Direct ELCs |
Since Direct ELCs operate at a level higher than the information processing level, information processing objectives may not be directly relevant in relation to Direct ELCs. In relying on Direct ELCs, as described in OAG Audit 5035.1 we need to assess the reliability of the information upon which the control is executed in one of three ways:
|
|
Indirect ELCs |
Information processing objectives are not generally relevant in relation to Indirect ELCs. Indirect ELCs set the “tone at the top” and operate at a higher level of the organization and therefore do not contribute directly to a specific FSLI, assertion or process objective. |
OAG Guidance
When evaluating controls to achieve the completeness information processing objective we seek to establish that
- all transactions that occur are entered and accepted once and only once for processing, and in the proper period,
- duplicate items are identified and rejected by the system, and
- all exceptions are addressed and resolved.
The following are examples of controls used to achieve the completeness information processing objective:
|
Batch totalling |
Transactions are grouped (“batched”) and counted. After input and processing, the total number of transactions processed is compared to the initial batch total. Exceptions are reported to management for resolution. For example, a company has 2,500 employees paid monthly. Each month the salaries and deductions are calculated and reviewed by management. All 2,500 are batched and uploaded to enable the payroll BACS (Bankers’ Automated Clearing System) run. After the upload, the batch control compares the expected number of employees to be paid against the number salary payment transactions uploaded. |
|
Sequence checking |
Transactions are expected to be input and/or processed in sequential order. Missing or duplicate sequence numbers are reported to management for resolution. For example, the entity’s purchases and payables business process includes an analysis of all invoices posted in the period matching them to their respective purchase orders (“PO”) and goods receipt notes (“GRN”). The entity’s “three way match control” identifies any duplications or missing unique sequential identifiers and reports these to management for investigation. Where the three way match control is automated, ITGCs can provide supporting evidence for the completeness IPO. |
|
One‑for‑one checking |
Manual one‑for‑one checking of source documents to a report of transactions to check that every transaction was processed once and only once is costly and time‑consuming. Computer matching is used to automate this process particularly when an entity has a high volume of transactions subject to the matching procedure. |
Completeness controls could be undertaken manually or may be automated.
Each one of these completeness controls requires active review and resolution of exceptions for the control to operate effectively.
Related guidance
See OAG Audit 6054 for guidance on testing automated controls.
OAG Guidance
The accuracy information processing objective is about whether the individual data elements are input and recorded correctly. Accuracy is also of particular importance when making changes to standing data.
Programmed edit checks are often used to achieve the accuracy information processing objective. Certain completeness control techniques may also help to achieve the accuracy IPO, depending on how the control is designed, for example one‑for‑one sequence checks can support the accuracy objective.
Programmed edit checks are procedures the system performs to check data in an online entry screen or during processing. Programmed edit checks are critical in real‑time processing environments as transactions are recorded as entered. Most real‑time systems do not accept a transaction for processing until all edit checks have been passed. Many programmed edit checks are set up via “configurable settings” in the application. These configurable settings are known as automated controls. How the settings within the application are configured may have a very important impact on the effectiveness of accuracy controls.
To understand and evaluate programmed edit checks and other automated controls, work with an IT Audit specialist to design an appropriate approach to evaluation, including consideration of ITGCs to determine continuity of their operation.
While generally edit checks are important in an online environment, they are also an important aspect of control in a batch processing environment.
The following are examples of accuracy controls. These could be undertaken as a manual process, or via programmed edit checks:
|
Reasonableness check |
Verifies that data falls within predetermined limits. For example, a system rejects a transaction with a quantity of 1001 when a quantity between 1 and 1000 is expected. |
|
Dependency check |
Verifies that the relationship among data elements is logical. For example, if an address is entered in the state or region, then the postal/zip code entered must be a valid zip code for that state or region. |
|
Existence check |
Data is compared to a file of data for that field. For example, checking customer number against an approved list of customer numbers. |
|
Format check |
Verifies that the data entered follows the expected alphanumeric patterns. For example, the system rejects a numeric data element when it is expecting only alphabetic characters. |
|
Mathematical accuracy check |
Verifies the accuracy of mathematical calculations performed on entered data. For example, a system requires a user to enter a unit price, quantity, and extended price. The system then recalculates the extended price and rejects the transaction if the result does not match the entered extended price. |
|
Check digit Verification |
The last digit of a reference number has a mathematical relationship to the preceding digits. If this relationship does not hold true, the transaction is rejected. For example, the eighth digit in an eight‑digit reference number is the check digit created from the other seven numbers: The first, third, fifth and seventh numbers are each multiplied by three, and then added together. If the eighth digit does not follow this mathematical relationship, the reference number will be rejected. |
|
Prior Data Matching |
Comparison to existing data is used to verify that the correct data element is being updated. For example, when updating a password, the user is requested to first confirm their existing user ID and password. This helps enable a check that the password is updated for the correct user’s account. |
|
Prerecorded Input |
The correct data element is chosen from data already recorded on the system. For example, pre‑defined drop‑down boxes in client‑server applications are used to avoid incorrect data being input. |
|
Key Verification |
Data is re‑keyed by an independent party to ensure that the initial input was accurate. For example, when initiating adding a new supplier and adding the bank account details, a second person manually types the bank account number and any differences are resolved before the information is accepted. |
Related guidance:
See OAG Audit 6054 on guidance on testing automated controls
OAG Guidance
Validity means that the transactions recorded in financial systems relate to actual authorized events/transactions and transactions entered and processed are valid. The following control techniques can be used for validity:
|
Authorization |
The validity of each transaction is reviewed and approved by an appropriate member of management. Approval may be evidenced through manual authorization, or as part of an automated workflow (see below). For example, an accounts payable team member updates payment details in the payments system. The accounts payable team leader manually authorizes the payment details before payment can be made. |
|
Application security authorization |
The validity of each transaction is established based on the fact that it is entered or approved in the application by an authorized individual. The application is designed to verify that transactions can only be entered in accordance with the application security controls. Note that the effectiveness of application security controls may rely on the effectiveness of the security administration controls considered during the evaluation of ITGCs. For example, the payments module automatically highlights updates made by the accounts payable team for the relevant level of management to review before they authorize the weekly payment run. |
|
Programmed validity checks |
An application may be programmed to check the validity of a transaction. For example, an automated three‑way match control in the payment module will reject a payment transaction as invalid unless the payment can be matched to goods received and an outstanding purchase order. |
|
Checking to source |
Comparing transaction data against source documentation provides evidence over the validity, completeness and/or accuracy information processing objectives. For example, comparing payment details to the original invoice to confirm that the amount outstanding has been allocated to the appropriate aging category. |
Similar to accuracy, for validity information processing objectives that are automated controls work with an IT Audit specialist to develop an appropriate approach.
See OAG Audit 6054 on guidance on testing automated controls
OAG Guidance
Restricted access focuses on the protection of data from unauthorized amendment. In other words, once valid data is recorded completely and accurately, there are controls in place to verify that the data remains complete, accurate, and valid until amended through subsequent authorized means.
While the definition of restricted access includes the concepts of confidentiality and the protection of physical assets, we are not ordinarily concerned with those aspects of the definition from an information processing perspective as they are less related to the achievement of financial statement assertions. Refer to Relationship between information processing objectives and financial statement assertions for further information.
The following are examples of controls that management can implement to either prevent or detect unauthorized changes to recorded data. Note that it is unlikely that the restricted access information processing objective could be achieved in a complex system environment without the existence of effective preventative data security controls, which are evaluated through our work on ITGCs.
|
Data security |
Most data is stored in some type of data environment (e.g., a data file or database). While data security controls are typically considered as part of the assessment of ITGCs, it is important to draw the appropriate linkage from that work to where that evidence helps achieve the restricted access information processing objectives for specific business processes. Data security controls can contribute to accomplishing objectives related to segregation of duties. |
|
File reconciliations |
File totals are regularly reconciled with an independently maintained control total to verify that unauthorized changes have not occurred. This control total might be maintained manually, it might be maintained as part of the data file, or it might be maintained as part of an independent data file. For example, the A/R balance per the general ledger is reconciled to the outstanding receivables detail in the A/R system). |
|
Exception reporting |
This technique can be used to identify potential problems with the integrity of data that required management review and resolution. For example, a report of all standing data elements changed from one period to the next may be reviewed to ensure that no unauthorized changes were made to a master file. Note: A similar technique can be used for completeness, accuracy, and validity information processing objectives. |
|
Detailed checking of data on file |
Certain data elements, especially significant data elements used in key calculations, are so important that it may be determined that periodic reviews of those data elements are necessary to achieve information processing objectives. For example, the loan amortization table used to calculate customer payments in a loan system is critical to loan payment amounts being accurate. A periodic review may be instituted over the data in this table to check for unauthorized changes. |
Related guidance:
See OAG Audit 5035.2 for guidance on how the Access to Programs and Data domain of ITGCs contributes to the restricted access information processing objective.
See OAG Audit 6054 for guidance on testing automated controls.
See OAG Audit 5035.2 for guidance on cybersecurity considerations.
OAG Guidance
If an information processing objective at a particular stage of the business process or sub‑process is not achieved, the data generated at that and subsequent stages of processing, as well as information derived from the data, may not be reliable. This may be because transactional data
- is processed incompletely (Completeness),
- is recorded or processed inaccurately (Accuracy),
- reflects transactions or events that did not occur or were not authorized (Validity),
- is not protected against unauthorized amendments throughout the process (Restricted access).
Where missing or ineffective controls relating to the recording and processing of data could result in a material financial statement misstatement, we document the control deficiency or weakness to consider how to respond to the resulting deficiency in internal control, including the resulting impact on the nature, timing and extent of our audit procedures. See OAG Audit 5037 for additional guidance related to the impact of control deficiencies identified in the entity`s system of internal control.
OAG Guidance
Although the information processing objectives appear similar to the financial statement assertions, there is not a one‑for‑one relationship, and the two are used for different purposes as highlighted below:
|
Information Processing Objectives |
Financial Statement Assertions |
|
Used to evaluate the design effectiveness of controls, particularly information processing controls, within a business process or sub‑process |
Representations made by management as to the fair presentation of financial statements and account balances |
While information processing objectives and financial statement assertions serve different purposes, they are not completely unrelated. For certain FSLIs, it would be difficult for management to implicitly make any of the financial statement assertions if the information processing objectives were not met. For example, it may be difficult for management to assert that all revenue transactions are accurately recorded if one or more of the information processing objectives is not met (e.g., there exists unauthorized access to the order processing system (restricted access), or the system does not properly calculate invoices (accuracy). On the other hand, meeting the information processing objectives does not ensure all assertions have been met. For example, the complete and accurate processing of bad debts and loss allowances for expected credit losses do not alone satisfy the valuation assertion for accounts receivable, though it helps to establish the reliability of historical data that might be used by management in estimating the loss allowance.
The table below may be useful in understanding how the information processing objectives support the financial statement assertions, assuming that the business process/sub‑process to which the controls relate is designed and operating effectively.
|
Information Processing Objective |
Financial Statement Assertion |
|
Completeness |
Completeness, Cutoff, Existence/Occurrence, Rights and Obligations |
|
Accuracy |
Accuracy, Valuation |
|
Validity |
Existence/Occurrence, Rights and Obligations |
|
Restricted Access |
Most, except for Rights and Obligations |
Our understanding of how the entity’s information system and related business processes achieve the information processing objectives helps us to (1) identify and assess the risks of material misstatement at the assertion level and (2) select controls implemented by management to test operating effectiveness.
When summarizing evidence related to a financial statement line item (FSLI), determine the evidence obtained from testing controls for each relevant assertion. This may include considering controls related to that FSLI to evaluate whether the information processing objectives have been achieved through controls including, the input, processing, and recording of data. Evidence of appropriate design, implementation and operating effectiveness for controls supporting information processing objectives provide assurance at the assertion level.
As data flows through the entity’s information system, there are risks to data integrity. Risks can occur across all processes and sub‑processes. Therefore, we consider IPOs across all sub‑processes, as part of our understanding of the entire end‑to‑end flow of data in the information system. This helps to identify if there is a risk that one control could be ineffective as a result of a control deficiency in a control designed to address another IPO in the same business process. For example, management may have implemented a control over completeness, such as a one‑for‑one check relating to customer invoicing, that could be rendered ineffective by ineffective restricted access controls over sales order data.
We understand how the information processing objectives are achieved in the relevant sub‑process, and the impact of ITGCs on these controls over information processing objectives before we select controls over a financial statement assertion we plan to test. Deficiencies identified in the information processing controls may affect our risk assessment and related audit responses.
Why restricted access is linked to most assertions
Restricted access to assets and records means that data is protected against unauthorized amendments, its confidentiality is verified, and physical assets are protected. This is similar to the control environment or tone at the top in that it links to many of our assertions. If we know that the physical assets are protected, then we have contributed to our “existence/occurrence” assertion. If we know that access to the system is restricted, then we may have contributed to our “existence/occurrence”, “completeness” “accuracy” and “valuation” assertions.
OAG Guidance
Automated information processing controls serve the same information processing objectives of completeness, accuracy, validity and restricted access as manual information processing controls. However, they are influenced to a greater degree by the effectiveness of ITGCs and require manual follow up for resolution. All automated information processing controls have a corresponding manual control. (i.e., batch totals for completeness and accuracy of data transfer could require manual follow‑up for records in suspense). They are ordinarily tested in conjunction with their associated manual‑based controls to determine whether there is a proper balance of control (e.g., a transaction is rejected or flagged and there is a manual research and follow up process with a documented resolution).
Some examples of automated information processing control methods in each of the information processing objectives are as follows:
Completeness:
-
Sequential numbering of transactions: Every transaction can be uniquely identified in the information system and the information system will not accept duplicate numbers, or numbers outside the set range. Missing numbers reported for investigation and followed up as needed.
-
Balancing and reconciling controls: Comparing the total(s) in the information system to the total(s) expected to be input. Differences identified as reconciling items would be followed up and corrected. The following are some examples of balancing and reconciling controls:
-
Hash totals: The numerical sum of one or more fields entered into the information system, including data not normally used in calculations, such as account number. The hash total is compared between the information system and the total expected to be input. If data points are lost or changed, a mismatch occurs which indicates a potential issue to be understood and corrected
-
Batch totals: The number of items in a batch entered into the information system. The total is compared between the information system and the total expected to be input. If part of the batch was lost, a mismatch occurs which indicates a potential issue over completeness of data transfer to be understood and corrected
-
-
Edit checks: Sometimes called “constraints” or “validation checks”, edit checks automatically compare data against pre‑defined criteria. The information system only allows data to be input that meets these criteria. The criteria may include:
-
A set of numerical limits. For example a control designed to identify and report transactions that exceed specified credit limits
-
Expected data format. For example a control that only accepts a date in the format “dd/mm/yy”
-
A set of logical conditions. For example to identify potential duplicate transactions based on invoice value
-
Accuracy:
-
Edit checks which could include reasonableness checks, existence checks, format checks.
-
Matching of customers, vendors, part numbers, invoices, and purchase orders to existing data
-
Control total balancing of data within transactions are input into the system.
-
Validity:
-
Transactions routed along a workflow approval process for processing by employees with appropriate authority.
-
Matching customer data against an existing data file (historical data, standing data, data from another organization/system, prior data matching).
Restricted Access:
-
Formal authorization by application owner is required for access to specific accounting records. Management reviews access rights periodically to ensure only authorized individuals have access and for segregation of duties. Exceptions noted are investigated and resolved.
-
Access controls include a proper segregation of duties (access only the information needed to perform my job function, i.e., responsibilities for approving, processing, handling assets should be divided among employees).
-
Access controls such as user IDs and passwords are utilized and specific to each application. Passwords are changed periodically and not replaced by previously used passwords. Multiple failures to log on invalidate the user ID and is reported via an exception report. Management investigates and resolves all items.
Related guidance
OAG Audit 5035.3—Identify entity’s ITGCs that address risks arising from the use of IT
OAG Guidance
Interface controls are considered information processing controls and we consider them when they are supporting information processing objectives. Interface controls are critical in helping to verify the completeness and accuracy of data transfer, as well as the validity of the data received. Interface controls can be manual or automated as the data transfer may be manually initiated and the value/record count may be reconciled manually or through application batch totals. If reconciled through application batch totals, there needs to be a report stating the result as the system will not self‑correct. The following are examples of the automated information processing controls employed to check data transmission is transferred from the source system, and received by the destination system in a complete and accurate manner:
-
Edit checks used by destination systems to restrict receipt of interface data from only certain, predefined, source systems. This is generally done by the use of system recognition codes (e.g., IP addresses and database pointers). This would also be considered a validity control as it verifies the validity of the data received.
-
Edit checks built into the destination system to disallow the acceptance of files that are not for the correct date, i.e., the system won’t accept yesterday’s file again if today’s is not ready.
-
Edit checks built into data transmission. For example, the destination system can calculate control totals and record counts of data received from valid sources. The destination system compares the totals and counts back to the source system. The source system compares the control totals against its own calculated information. If the totals are the same, the source system will send a confirmation back to the destination system. If the totals are not the same, the destination system will not process the data. This will verify that transmission was complete and accurate. For this area, also consider resubmission controls.
-
Edit checks using file headers/footers. File headers can summarize the information that is included in the files sent from source systems. The information can include, for example, number of records, total amount fields, total debits, total credits, file sizes. The destination system imports the file on a record for record basis individually computing edit check calculations. When the calculated information matches the header or footer, the information will go to the next stage of the validation process. If the data does not match refer to the resubmission controls.
Resubmission Controls. A very important follow‑up control that exists to verify that when the above controls detect failures in communications, the destination system will let the source system know to resubmit the original data transmission. In this scenario, the source system ignores the original message, as this could lead to duplicate processing of transaction data.
Data Validation Controls. All data received by source systems goes through data validation controls or edit checks. These edit checks could include, for example, numeric fields that check for other characters, date fields that check whether the data is in the correct format. Company numbering formats are also checked against the business rules. There are business rules that will apply on all data fields received by the source system. For example, a customer number must be between 1000001 and 1099999. These same controls are also applied for resubmission activities.
Related guidance
OAG Audit 5035.2—Identify entity’s ITGCs that address risks arising from the use of IT