5035.2 Identify the risks arising from the use of IT and the related ITGCs

Sep-2022

OAG Guidance

As part of understanding and evaluating the entity’s system of internal control, we obtain or update our understanding of how the entity uses information technology (IT) relevant to the preparation of the financial statements and how the entity responds to risks arising from the use of IT. Refer to OAG Audit 5034 for further guidance on understanding the IT environment relevant to the information system.

It is only after understanding how the IT environment is relevant to the preparation of the financial statements that we fully understand the entity’s processes, data flows and risks, including risks arising from the use of IT. The following are examples of some factors that can influence an entity’s need to use IT:

• The type of business (e.g., entity that develops digital property which requires sophisticated IT infrastructure to protect)
• Business model (e.g., online sales, subscription business) 
• Compliance with laws or regulations (e.g., data protection laws or electronic filing requirements of regulators)
• Financial reporting risks identified by the entity as part of its operations that can be mitigated with the use of technology (e.g., automated calculations to minimize manual errors)

Why is this important?

It is through the identification of IT applications and other aspects of the IT environment (e.g., databases, operating system, network) relevant to the preparation of the financial statements that engagement teams are able to identify the risks arising from the use of IT and related information technology general controls (ITGCs) that address these risks. This provides the basis for the engagement team to understand the entity, identify and assess risks of material misstatements, assess the control risk as documented by our determination of expected controls reliance (i.e., none, partial or high), and develop effective and efficient audit responses to address the risks of material misstatement.

Therefore, even though we may later decide not to test the operating effectiveness of ITGCs or other controls, the risks which these controls are designed to address will need to be understood as part of our risk assessment and considered when developing our responses to risks of material misstatement. For example, the entity may manage its customer accounts receivable using an IT application (the “accounts receivable subledger” which automatically interfaces with the revenue collection application used to match revenue against invoice) because there is a large volume of revenue and collection transactions and management concluded it is more effective than managing it manually using a spreadsheet application such as Microsoft Excel. Management implements ITGCs and other information processing controls aimed at ensuring accurate processing and to maintain the integrity of the information reflected in the accounts receivable subledger. Regardless of any plan to test the operating effectiveness of controls addressing relevant assertions of the accounts receivable FSLI, there are risks arising from the use of this IT application, such as the risk that unauthorized or untested changes, or the failure to make necessary changes to application configuration when generating a system‑generated report such as an accounts receivable aging report, could result in transaction records not being processed completely and accurately. We consider this risk as part of our risk assessment process even if we only intend to make use of the report for substantive testing purpose. If we plan to use the report as part of a test of controls or for our substantive procedures, we still need to address the completeness and accuracy of the source data, (which in this example is the data received via the interface with the revenue collection application, therefore we may need to consider the interface as an IT dependency and the report logic.

Within the block below Identify risks arising from the use of IT, we address, in more detail, the identification of IT risks and in the block below Identify entity’s ITGCs that address risks arising from the use of IT we cover identifying ITGCs to address those risks, which together comprise the “Identify IT risks and ITGCs” element of the OAG Risk Assessment Process illustrated below.

Identifying risks arising from the entity’s use of IT and the entity’s ITGCs that address such risks

The following chart shows how we utilize the understanding of the various elements of an entity’s system of internal control to identify risks arising from the entity’s use of IT and the entity’s ITGCs implemented to address those risks:

Mapping CAS 315 terminology to OAG Audit

General Information Technology Controls

CAS 315 refers to General Information Technology Controls. This is equivalent to the term Information Technology General Controls (ITGCs) used in OAG Audit.

ITGC Domains

CAS 315 provides relevant requirements addressing the need to understand the entity’s internal controls and emphasizes the importance of obtaining an appropriate understanding of the IT environment. Although the ITGC domain names used in OAG Audit have not been updated to align to the revised ITGC domain names used in CAS 315 (Revised), the meaning of the terms are the same and related procedures designed to assess the design and test the operation of ITGCs relevant to the network, operating system or database layers, fully align with the requirements and guidance of the revised standard. These domain names used in OAG Audit may be updated in the future to eliminate the narrowing terms such as “program” or “program and data”. For now, the following table provides a mapping of the ITGC domain names used in OAG Audit to those used in CAS 315:

*CAS 315 references three IT Processes—Manage Access, Manage Change and Manage IT Operations. OAG Audit guidance includes a fourth domain “Program Development” to enable us to more easily identify and focus on development related activities at the entity and the related audit work. Equally, if the entity does not undertake development in the period, this ITGC domain would not need to be evaluated, which helps facilitate effective and efficient working practices.

OAG Guidance

CAS 315.26(b) requires us to identify IT applications and other aspects of the IT environment related to controls within the control activities component of the entity’s system of internal control that are subject to risks arising from the use of IT (e.g., IT applications the entity is relying upon to accurately process and maintain the integrity of information in the entity’s information system).

The starting point is the controls that address the risks of material misstatement that we have identified within the control activities component of the entity’s system of internal control. Refer to OAG Audit 5035.1 for further guidance related to these controls. We consider if these controls rely upon one of more IT dependencies.

Where we identify IT dependencies, we identify the IT application or other aspects of the IT environment that relate to these IT dependencies and consider if they are subject to risks arising from the use of IT. When risks arising from the use of IT are identified, we understand the IT general controls (ITGCs) that address the risks arising from the use of IT and evaluate the design and implementation of these ITGCs.

Where a manual control relies on a system‑generated report, the report is the only IT dependency type, and we conclude that we are able to substantively test the reliability of the system‑generated report for each instance of the control we plan to test, we do not consider this control to be “subject to risks arising from the use of IT” and therefore are not required to evaluate the design and implementation of ITGCs relevant to this system‑generated report. While we are not required to evaluate the design and implementation of ITGCs relevant to system‑generated reports when our testing strategy is to substantively test the reliability of each instance of the report, we consider whether it would be a more effective and efficient strategy to test the ITGC and if so, we would evaluate the design and implementation of the relevant ITGCs.

Similar to assessing the complexity of the IT environment (OAG Audit 5034) we may consider involving IT Audit when identifying IT applications and other aspects of the IT environment that may be subject to risks arising from the use of IT. IT Audit involvement could range from consulting, to coaching or completing parts of this work to support the engagement team in making these judgements.

Supporting notes to the flowchart:

IT Dependencies: We identify IT dependencies when obtaining our understanding of the entity’s system of internal control, and through our end‑to‑end understanding of the data flows, processes and controls. This understanding provides a good source of information for identifying IT applications and other aspects of the IT environment related to the entity’s information processing controls.

As explained further in OAG Audit 5034, IT dependencies relate to automated or manual controls or planned substantive procedures that are dependent on IT such as system generated reports, automated calculations within applications, security that facilitates the segregation of duties or restricts direct data changes in the database and automated interfaces between IT applications.

Manual Controls: Where identified controls have no IT dependencies (i.e., the controls are entirely manual, with no reliance upon IT) we are not required to evaluate the design and implementation of ITGCs.

IT Environment: When considering IT dependencies related to controls, CAS 315 requires us to consider the entire IT environment which comprises IT applications, data and other aspects of the IT environment, including: The supporting infrastructure, specifically the network and operating systems on which applications operate The underlying databases that hold data used by applications in the information system The interfaces between IT applications

System Generated Reports: Where the only identified IT dependencies associated with a control we intend to rely upon are system generated reports for which we plan to substantively test the reliability (i.e., completeness and accuracy) of the information included in such reports, we are not required to evaluate the design and implementation of ITGCs relevant to the system‑generated reports.

For IT dependencies that do not relate to a control but are relevant to our planned substantive testing (i.e., a system‑generated report), we document IT dependencies and related aspects of the IT environment, but we do not need to identify the IT applications, or other aspects of the IT environment as being “subject to risks arising from the use of IT”. We may, nevertheless, need to evaluate the design and implementation and test the operating effectiveness of ITGCs if necessary to address the reliability of a system‑generated report (see OAG Audit 4028.4 for guidance on testing reliability of system‑generated information)

Risks arising from the use of IT: Where there are risks for which substantive procedures alone do not provide sufficient appropriate audit evidence (i.e., we will rely on ITGCs), or if there are any IT dependencies, other than system generated reports which we plan to test substantively, then risks arising from the use of IT will be identified. For the IT related risks we would identify ITGCs and evaluate their design and implementation.

CAS 315 Appendix 5.15 provides examples of characteristics to be considered when identifying whether IT applications and other aspects of IT would be subject to risks arising from IT. These characteristics include:

• Nature of the application (e.g., standalone, interfaced)
• Volume of data Complexity of the application
• Whether management is relying upon the IT application to accurately process and maintain the integrity of information in the entity’s information system
• Whether management uses system‑generated reports in their controls and whether we plan to directly test the inputs and outputs of such reports (rather to rely on controls) to cover the risk
• The information produced could be tested substantively only

In addition to IT applications that are subject to risks arising from the use of IT (e.g., IT applications the entity is relying upon to accurately process and maintain the integrity of information in the entity’s information system), we understand the other aspects of the IT environment to consider how they may impact our risk assessment. The following examples illustrate other aspects of an entity’s IT environment that could give rise to risks from the use of IT:

• We identify an automated control performed in an IT application that calculates a translation of sales invoiced in a foreign currency. The control uses a database reflecting currency exchange rates for the translation and recognition of the revenue transaction in the functional currency of the entity. In this case, we would identify both the application performing the automated currency translation calculation and the database of foreign currency translation rates as both could give rise to risks from the use of IT. This is because they are both used in this IT dependent automated control.
• During the year the entity changes from a manual process to an automated interface between application A and application B. As part of understanding this change process we identify that the client uses an IT “ticketing” tool to document and manage development of this change request and a software code management tool to enable management and review of the code changes made. We identify applications A and B relating to the interface IT dependency, and the ticketing and code management tools (i.e., applications that support change management for applications A and B). Applications A and B, the IT ticketing tool and the code management tool could give rise to risks arising from the use of IT.
• The entity uses cloud management consoles and back‑up services. These cloud based services free the entity from maintaining their own software to monitor infrastructure performance, error logging and back‑up management. The entity’s supplier portal is hosted on the cloud, and the majority of the entity’s supplier invoices, which feed into their accounts payable sub‑ledger are received through the supplier self‑service function in the portal. A system performance issue or downtime could result in invoices submitted by the suppliers not being recorded in the entity’s accounts payable sub‑ledger timely or completely and accurately, leading to a potential understatement of the entity’s recorded liabilities. The entity relies on performance reports and error logs from their cloud service provider to identify potential issues with the cloud infrastructure. These cloud services could give rise to risks arising from the use of IT.

Understand the nature and use of technology solutions

Entities are adopting technology solutions to automate processes, increase efficiencies, analyze data, increase speed of issue identification, and enhance quality. In many cases, these technology solutions have the potential to impact financial reporting. These technologies may increase the risk of material misstatement as some of these technologies are in continuous development, and may require expert skills to be developed, implemented, tested and operated. It is important for us to identify these technologies, applications or other related aspects of the IT environment, and consider the related risks arising from the use of IT. Although technology solutions may be evolving, the need to identify and understand ITGCs addressing the identified risks remains unchanged.

The following are examples of technology solutions that may be used by the entity:

• Data analysis—Technology solutions, such as Alteryx and Power Query, can be used to prepare and blend data for analysis (e.g., calculation/report used in the performance of controls or substantive procedures) by gathering, cleansing, and joining data from multiple sources. The output from data analysis technology solutions (such as an Alteryx workflow) can be an Excel spreadsheet, which may look exactly like the spreadsheet that was previously created manually.
• Visualization (reporting)—Technology solutions, such as Tableau, Power BI or Qlikview, can provide visualizations to analyze and/or present data. They are used to present raw data in a more understandable format by providing users with the ability to easily present data from various sources into one output.
• Robotic Process Automation (RPA)—RPA platforms, such as UiPath, Blue Prism or Automation Anywhere, are technology solutions that can be programmed to automate repetitive tasks. For instance, RPA may be employed to extract key metrics from customer’s financial statements or generate credit models and make preliminary decisions on credit limits. RPA may also be employed to automate the termination of user access for those identified during the periodic user access review.
• Artificial intelligence (AI)—AI represents computer systems able to perform tasks that normally require human intelligence, such as visual perception, speech recognition, decision‑making, and translation between languages. An example of AI might be the automation of reconciliations to enhance the speed of resolution of reconciling items. Through learning how individuals manually match unreconciled items, AI can be trained to execute the matching process, enabling users to limit their review to the remaining exceptions.

Blockchain—Blockchain is a type of distributed ledger technology where data is stored in blocks that are cryptographically linked together. Blocks of data are connected to the block before and after, with every additional block strengthening the verification of the previous block. Blockchains can be permissionless (open to the public) or permissioned (only available to those given access) and can be used to store a wide range of data, some examples are cryptocurrencies (e.g., Bitcoin, Ethereum), non‑fungible tokens (e.g., digital art), or supply chain (e.g., food traceability). Not all blockchains are created equally and it is important to understand the key elements of a blockchain, including but not limited to, the distributed ledger, network of participants, consensus mechanism and cryptography.

OAG Guidance

The nature of risks arising from the use of IT depends on the nature and characteristics of the identified IT applications or other aspects of the IT environment subject to risks arising from the use of IT (e.g., IT application the entity is relying upon to accurately process and maintain the integrity of information in the entity’s information system). For example, when revenue transactions are processed online and the entity uses an IT application to initiate and record these transactions the IT application is subject to risks such as inaccurate data processing and recognition of invalid transactions if unauthorized access to the application occurred.

Other aspects of the IT environment could lead to risks arising from the use of IT. For example, direct changes could be made to the data in the database used by an application which could circumvent application level controls. Another example would be a network and operating system that an application runs on which does not have controls to prevent unauthorized users from gaining inappropriate access or may not have appropriate intrusion detection controls to identify if there is unauthorized copying of data.

For each IT application or other aspect of the IT environment, we identify the risks arising from the use of IT. Risks arising from the use of IT are defined by CAS 315 12(i) as:

Susceptibility of information processing controls to ineffective design or operation, or risks to the integrity of information (i.e., the completeness, accuracy and validity of transactions and other information) in the entity’s information system, due to ineffective design or operation of controls in the entity’s IT processes.

When identifying risks we consider how the IT application or other aspects of IT are used to initiate, record, process, correct and incorporate in the general ledger and report transactions in the entity’s financial statements. See OAG Audit 5034 for further guidance of this understanding, and what are the risks involved in these transactions.

As part of understanding of the control activities component, we need to consider IT risks that occur at the entity level that are not associated with underlying IT dependencies and are not application specific. These are broader entity‑wide considerations of the IT environment—the “IT process‑wide considerations”, and therefore we need to consider whether these entity‑level risks may be pervasive and give rise to a risk of material misstatement at the financial statement level, see OAG Audit 5043.2 for further guidance. The two most common IT process‑wide consideration risks are:

• Duties are not appropriately segregated: When deficiencies in indirect controls (e.g., policies) affect the entity’s overall IT environment
• Governance of IT processes are not established: When deficiencies in the entity’s overall IT controls affect the entity’s overall IT environment

Some examples of risks arising from the use of IT for each aspect of the IT environment:

See the block below Identify entity’s ITGCs that address risks arising from the use of IT for further guidance on identifying an entity’s ITGCs and their impact on the audit.

Risk considerations on the use of technology solutions

The following table provides some examples of risk considerations that may be relevant when the entity is using technology solutions:

OAG Guidance

Information technology general controls (ITGCs) over the entity’s IT processes support the continued proper operation of the IT environment, including the continued effective functioning of information processing controls and the integrity of information (i.e., the completeness, accuracy and validity of information) in the entity’s information system (CAS 315.12(d)). For example, access rights and restrictions intended in the design of the entity’s system of internal control.

ITGCs typically include granting and removing user access rights, administering security, enforcing authentication (e.g., password) controls, segregation of duties, and monitoring direct access and security change activities within, and across the IT environment. Deficiencies in ITGCs could compromise the effectiveness of management’s segregation of duties controls or other related control objectives by permitting inappropriate access rights. Such access could allow inappropriate changes to information maintained in the entity’s information system. Risks arising from the use of IT lead to consideration of the ITGCs that address such risks. Well designed, implemented and maintained ITGCs create the foundation upon which other controls can operate to address these risks.

Example:

The following risk has been identified in relation to an entity’s accounts receivable balances “Method (including any model), significant assumptions and data used to estimate the allowance for doubtful accounts are not appropriate/reasonable” and the following control responding to the risk has been identified:

Detective, IT Dependent manual control: The system generated A/R aging report (which is configured to allocate invoices into aging categories) is reviewed by the finance manager for significantly aged customer balances and known issues in the accounts receivable sub‑ledger and the corresponding allowance for doubtful accounts to ensure account balances are adequately reserved. Differences are investigated and resolved on a timely basis. We apply the illustrative flowchart in the block above Identify IT applications and other aspects of the IT environment to identify IT dependencies, related aspects of the IT environment subject to risks arising from the use of IT, and the related ITGCs that address these risks:

This example demonstrates a risk may be addressed by an entity’s ITGCs but is not intended to address all potential risks arising from the use of IT.

There may be other considerations and controls to be tested to enable reliance on this report, depending on the determined testing approach. For example, information processing controls over the preparation and maintenance of the report (see OAG Audit 4028.4 for guidance on testing reliability of information generated by an IT application).

As noted in OAG Audit 5031, entity level controls (ELCs) operate at the entity level. IT process‑wide considerations are IT controls that have impact across more than one business process and are considered when evaluating the effectiveness of information processing or direct entity‑level controls at the transaction level within a business process. We also consider if these IT process‑wide considerations could relate to pervasive risks, see the block above Identify risks arising from the use of IT.

ITGCs help determine the continued reliability of information generated by applications. ITGCs are typically categorized in four domains, as described below.

*The ITGC domains cover the IT environment as a whole and relate to the IT processes in CAS 315, as per the mapping in the block above Overview.

For risks arising from an entity’s use of IT we consider which of the four ITGC domains may be relevant. For example, for an entity that relies on a number of applications, the Program development domain may only be relevant when significant development, implementation, or conversion projects impact the risk of material misstatement. Refer to the block below ITGC Domains for guidance on each ITGC domain.

The following table provides some examples of ITGCs commonly implemented to address risks arising from the use of IT, categorized by IT domain.

Please see the block below Cybersecurity risk assessment considerations for further consideration of the risks and controls relating to cybersecurity that could affect one or more of the ITGC domains.

OAG Guidance

Access to Programs and Data*—Domain objective:

To ensure that only authorized access is granted to the IT applications and other aspects of the IT environment upon authentication of a user’s identity. Controls over access to the IT environment include the processes used by the entity to add, delete, and change users (both business users and IT personnel) and their related access rights according to the control objectives established in the design of the control (that is, to achieve the entity’s objectives for appropriately restricted access and segregation of duties).

*Access to Programs and Data covers access to the IT environment as a whole and relates to the “Manage Access” domain in CAS 315, as per the mapping in the block above Overview.

When understanding controls over access to the IT environment, we typically understand the entity’s IT security risks, its approach to IT security, and the relevant aspects of its specific IT security architecture (e.g., “single sign‑on” to the network versus application‑level security), before deciding which layer(s) of security and access controls are important to address the identified risks arising from the use of IT (i.e., IT risks relevant to the preparation of the financial statements).

The sub‑components of Access to Programs and Data domain typically include:

•  Management of security activities
• Security administration
• Direct access to data (databases or data files)
• Operating system security
• Utilities (e.g., job schedulers, reporting tools)
• Network security
• Physical security

Examples of ITGCs that may exist to manage access to the IT environment typically include the following (CAS 315 Appendix 6.2(a)):

•  Authentication
• Authorization
• Provisioning
• Deprovisioning
• Privileged access
• User access reviews

When understanding the above, not all sub‑components and ITGCs may be applicable to every entity, and other risk factors may exist that may need to be considered. The manner in which access is requested, authorized and controlled varies among entities, depending on the size and complexity of the environment and volume and types of access processed.

Consider using applicable territory technical platform practice aids and work programs to assist in our evaluation of controls over access in the Access to Programs and Data domain.

We obtain this understanding of the sub‑components and ITGCs to help determine which layer(s) of security controls are relevant to the preparation of the financial statements and obtain evidence about whether the more important elements exist and are implemented. For instance, perimeter or network security and anti‑hacking controls, such as firewalls and intrusion detection systems, may be relevant to the preparation of the financial statements if there are material financial reporting risks that are not adequately addressed by application‑level security alone. Additionally, if utility applications such as job schedulers or reporting tools are used to support key reports or interfaces, these utilities may be relevant to the preparation of the financial statements. The following graphic illustrates the different layers of security in the IT environment:

Direct access to databases or data files

Access to data is a routine and essential aspect of operating most computerized accounting systems. However, management needs to implement an appropriate balance of controls to mitigate the risk of a material misstatement from unauthorized or erroneous changes to accounting data via direct data access. We generally focus our direct data access risk assessment at the database or application layers. There is generally a lower risk of direct data access at the operating system level, as data is not expected to be held, nor directly accessed at the operating system level. As illustrated in the figure above, these are all within the internal network. The perimeter network and security are where the cross‑over into the external, web‑facing IT environment (e.g., the internet) occurs. As noted above, the perimeter network is where intrusion prevention/detection and monitoring controls are set up to prevent attacks (e.g., ransomware) which may prevent the entity from accessing its critical infrastructure or data. Other cybersecurity risks and controls may relate to access to programs and data, and/or other ITGC domains. See the block below Cybersecurity risk assessment considerations for additional guidance on cybersecurity risks and controls.

When access to data is restricted to authorized users in the IT department, operational risks such as accidental system shutdown or the incorrect restore of data/ interfaces or programs tend to be greater than the risks of intentional misstatement or other types of fraud. If personnel responsible for financial reporting (e.g., finance controller) have direct access to change data, we may need to consider if this may be an indicator of potential fraud risks. Consider likelihood, not just magnitude when evaluating the risks associated with privileged access.

The following considerations may be helpful for identifying ITGCs in the Access to Programs and Data domain that address the risks arising from an entity’s use of IT. See the block above Identify risks arising from the use of IT for further guidance on identifying risks arising from the use of IT. Note: Not all points of focus are relevant to every entity, and other risk factors may exist that will need to be considered.The table below provides examples of risks and considerations for the audit split by sub‑component and referencing these ITGCs.

*Please see the block below Cybersecurity risk assessment considerations for further consideration of the risks and controls relating to cybersecurity that could affect one or more of the ITGC domains.

OAG Guidance

The entity is to demonstrate, with reasonable assurance, that sufficient change controls are applied consistently to all aspects of the IT environment—including IT applications, network, databases or operating system(s) that are subject to risks arising from the use of IT. The sub‑components of the Program Change domain typically include:

• Management of maintenance activities
• Specification, authorization and tracking of change requests
• Construction
• Testing and quality assurance
• Program implementation
• Documentation and training
• Data changes
• Segregation of duties

Examples of ITGCs that may exist to manage changes to the IT environment typically include the following (CAS 315 Appendix 6.2(b)):

• Change management process
• Segregation of duties over change migration

When understanding the above, not all sub‑components and ITGCs may be applicable to every entity, and other risk factors may exist that may need to be considered. The manner in which changes are identified, tracked, and controlled varies among entities, depending on the size and complexity of the environment and volume and types of changes processed. When determining our approach to addressing the risk associated with program changes, we obtain an understanding of the nature of changes made during the period under audit (e.g., changes to source code, configuration of database or operating systems, data changes, etc.).

When considering the risks arising from the use of IT associated with IT changes, we first obtain an understanding of the nature of changes made during the period under audit (i.e., changes to source code, configuration of database or operating systems, etc.) for identified applications and other aspects of the IT environment. Where changes impact on identified IT dependencies, we may choose to rely on change controls to address the risks arising from the use of IT. An important aspect of effective change controls is the ability of the entity to understand if, and when, a key automated information processing control or IT‑dependent manual control has changed, whether they have been considered for testing in the change process, and whether change controls are applied consistently. This will usually entail some degree of linkage between the change activities in IT and overall ownership and monitoring. This is also a necessary criteria, not only to support a benchmarking strategy (as described in OAG Audit 6054), but also to use our testing of ITGCs as the basis for relying on the ongoing operating effectiveness of information processing controls and IT dependent manual controls in the current audit period. We can possibly eliminate or significantly limit our testing of change controls when the risk of significant changes to a key application is low. For example, during the risk identification process where client’s use off‑the‑shelf software with no customization, or when other reliable evidence demonstrates that a relevant automated or IT‑dependent manual control hasn’t been changed since it was last tested (e.g., a system report or evidence showing last date modified).

Determining the full population of changes

Monitoring and testing that all relevant changes have been subjected to the entity’s change controls can be made easier when the entity’s IT environment can produce reliable evidence (i.e., an “audit trail”) of the full population of changes. For example, if a reliable report of all compilation dates of all changes placed in production is available, management can more readily demonstrate that every change went through its controlled process.

However, not all IT environments are designed to produce reliable, automated information about the population of changes. Some will log only the date of last modification. Others may be able to log all changes, but perhaps those logs can be circumvented or overwritten by those with direct access to the production environment. A lack of IT generated change data does not in itself preclude management from being able to demonstrate, with reasonable assurance, that the entity’s change controls are applied consistently to relevant changes. Some factors to consider in evaluating whether there can be reasonable assurance that all such changes have been dealt with appropriately typically include:

• The types of applications used, whether the entity has access to the source code, and the nature and volume of routine changes
• Whether changes are rigorously tracked, electronically or manually, by parties who are independent from those requesting or making the changes, using data that cannot be altered by those requesting or making the changes
• Whether separate environments are maintained for development, testing and production, and only the appropriate individuals have access to each of those environments
• Whether responsibilities are segregated appropriately such that the person responsible for identifying, tracking, and reporting on the status of change requests does not have accounting or finance responsibilities
• Whether there is an automated “audit trail” record enabled for the IT environment

The guidance below can be considered when assessing the risks arising from the use of IT, see the block Identify risks arising from the use of IT for further guidance on identifying risks arising from the use of IT. The following considerations may be helpful for identifying ITGCs in this domain that address the risks arising from the use of IT identified at the entity. Note: Not all points of focus are relevant to every entity, and other risk factors may exist that will need to be considered. For example, cybersecurity risks and controls may relate to program change, and/or other ITGC domains. Please see the block Cybersecurity risk assessment considerations for additional guidance on cybersecurity risks and controls.

The table below provides examples of risks and considerations for the audit split by sub‑component and referencing these ITGCs.

*Please see the block Cybersecurity risk assessment considerations for further consideration of the risks and controls relating to cybersecurity incidents that could affect one or more of the ITGC domains.

OAG Guidance

Program Development*—Domain objective:

To ensure that IT applications and other aspects of the IT environment are developed, configured, and implemented to achieve management’s control objectives. This includes development or acquisition or implementation controls and data conversion controls.

*Program Development covers development of the IT environment as a whole and relates to the “Manage Change” domain in CAS 315, as per the mapping in the block Overview.

This domain is relevant only where significant development, implementation, or conversion projects exist or are anticipated that will impact the risk of material misstatement to the current year’s financial statements. ITGCs related to the Program Development domain will be identified to address risks arising from the use of IT related to new IT applications or other aspects of IT developed, configured and implemented in the period. For example, when there is a new IT application used in an identified control, we may have identified a risk related to incompletely or inaccurately processed data in this application. Therefore, in order to address the risk, management implemented ITGCs to test and approve the IT application.

CAS 315 includes development in the “Manage Change” IT process. As above, the Program Development domain is only relevant where the entity has significant development, implementation or conversion projects in the period. Development may not occur every year. Separating Program Development from Program Change assists us in a more granular evaluation of how change occurs in the entity’s IT environment. It also helps us to identify and assess the risks arising from the use of IT at the domain level:

• Where the entity undertakes no development in the period, no Program Development domain risks arise from the use of IT
• Where the entity undertakes development in the period, the Program Development domain is where development risks arising from the use of IT are documented

ITGCs related to development will vary from entity to entity and project to project, depending on the risks identified. The most important development controls tend to operate close to the implementation date. We also monitor and assess new risks that may arise from development activities (i.e., temporary super user access among key financial personnel), as well as controls that the entity might put in place temporarily during the conversion period.

For example, the entity plans to implement a new financial application this year. This new system will impact the entity’s financial statements for that audit year. It is often more effective and efficient to understand newly implemented or changed information processing controls and data conversions by reviewing the entity’s controls in the development cycles than it is to test the controls solely in the live, post‑implementation environment.

Professional judgment is needed to determine whether we understand development controls in the current year, particularly for implementation that will not directly impact financial reporting risk until a subsequent year. Refer to the table below for considerations when assessing the risks arising from the use of IT within the Program Development domain. ITGCs related to development are important to many audits, but their overall relevance is more client specific.

We review significant developments and assess the financial impact associated with the entity’s development where the development relates to a control identified within the control Activities component. For example, if an entity implements a new IT application during the period under audit that includes controls and IT dependencies relating to a risk of material misstatement, we obtain an understanding of the implementation process and identify the risks arising from the use of IT to determine whether the development controls address these risks. This understanding is helpful when considering if it is efficient and effective to test controls to obtain evidence over the new system, implementation process and conversion of data. In circumstances where the development relates to a risk arising from the use of IT, we obtain the supporting documentation.

The sub‑components of the Program Development domain typically include:

• Management of development and implementation activities
• Project initiation, analysis, and design
• Construction/package selection
• Testing and quality assurance
• Data conversion
• Program implementation
• Documentation and training
• Segregation of duties

Example of ITGCs that may exist to manage development of the IT environment typically include the following (CAS 315 Appendix 6.2(b)):

• Change management process
• Segregation of duties over change migration
• Systems development or acquisition or implementation
• Data conversion

We determine the activities that are relevant and the controls based on the entity’s unique IT environment. The following considerations may be helpful for identifying ITGCs in this domain that address the identified risks arising from the use of IT at the entity. See the block Identify risks arising from the use of IT for further guidance on identify risks arising from the use of IT. Note: Not all considerations are relevant to every entity, and other risk factors may exist that will need to be considered. For example, cybersecurity risks and controls may relate to program development, and/or other ITGC domains. Please see the block Cybersecurity risk assessment considerations for additional guidance on cybersecurity risks and controls.

When understanding the above, not all sub‑components and ITGCs may be applicable to every entity, and other risk factors may exist that may need to be considered. The table below provides examples of risks and considerations for the audit split by sub‑component and referencing these ITGCs.

*Please see in the block Cybersecurity risk assessment considerations for further consideration of the risks and controls relating to cybersecurity incidents that could impact across one or more of the ITGC domains.

Auditing Enterprise Resource Planning Systems Implementation and Upgrades

Implementation and significant upgrades/changes to our client’s Enterprise Resource Planning (ERP) systems often result in business process changes. The results of such changes may mean transactions are not processed the way they used to be, reports may be redesigned and changes in controls are implemented. For example, some upgrades/changes result in moving the ERP to be hosted in a cloud environment which means that the supporting infrastructure may change. Sometimes when an entity upgrades/changes its ERP there is a movement away from traditional preventative controls, and a movement of some controls to those that have both preventive and detective characteristics:

• Real time controls designed to avoid creating a ‘hard stop’ that interrupts business operations, while enabling controls that support the business, or
• Hybrid controls that have both preventive and detective characteristics.

When understanding and evaluating the design of those controls we consider both preventive and detective characteristics of the control to the extent they are responsive to the identified risk of material misstatement.

See OAG Audit 5034 for guidance and examples of different types of Controls.

The audit of the financial statements needs to consider the impact of these ERP implementations and/or upgrades as part of risks arising from the use of IT. There is a presumption that any client with systems of sufficient complexity and scope to warrant the expenditures to implement an ERP system would have an impact on our audit strategy. It is also necessary to recognize that a large‑scale ERP implementation may create an environment in which it is unlikely that an effective audit can be conducted without adopting, to a significant degree, a controls‑oriented approach.

Each ERP implementation is unique (e.g., no two SAP implementations are the same), thus consider the impact of the implementation on internal control and make a determination about how to audit effectively in the individual client circumstances. The points that need to be considered during such changes are:

• IT Audit involvement to understand the impact of the ERP to the control environment. Additionally, it is normally expected that Information technology general controls (ITGCs) are tested.
• How the ERP implementation will impact the inherent risk factors and the overall risk assessment process necessary to understand and audit the implementation. During the initial year of an ERP implementation or significant upgrade, early planning is conducted to:
  • Identify which controls that address the risks of material misstatement at the assertion level are impacted by new or changed ERP modules
  • Identify the other aspects of the IT environment that could be subject to risks arising from the use of IT, e.g.
    • Interfaces (ERPs are often linked to other systems that in turn need controls to ensure that all inputs are received for processing and all outputs are distributed appropriately)
    • Network, database and application level security, and
    • Other risks and related ITGCs (i.e., in this instance the Program development ITGC domain is likely to be important)
  • Obtain the entity’s implementation timetable to determine when and where the ERP implementation will impact the audit
• Impact to controls—has a baseline understanding and assessment of internal control been established by:
  • Internal audit reviews (pre‑implementation or post‑implementation controls assessment)?
  • OAG’s evaluation of the design and implementation of controls undertaken as part of the audit?
  • Assessments by other reputable firms?
  • Documentation of business processes and controls for the new ERP processing environment?
• What are the entity’s and the Audit Committee’s expectations of the audit?
  • Does the entity expect the OAG team to understand how to access information using its ERP system?
  • Do they expect the OAG team to place reliance on the new processing and internal control environment?
• What is the impact on the OAG team’s prior audit knowledge?
  • Has the ERP system changed the process or methods for performing significant or a majority of the business processes? Have the entity’s business processes moved from manual to automated processes?
  • Has the ERP implementation changed the entity’s internal control from manual detective‑based controls to automated preventive‑based controls or some combination of both?
  • Has the ERP system completely changed the ITGCs? Has the ERP system replaced all the legacy systems that the PwC team’s knowledge and internal control understanding was based on?
  • Is the mapping of the entity’s significant business processes and systems still accurate?

Related Guidance

See OAG Audit 3102 for guidance on the use of IT Audit.

OAG Guidance

Computer Operations—Domain objective:

To ensure that the IT applications and other aspects of the IT environment are processed completely and accurately in accordance with management’s control objectives, and that processing problems are identified and resolved completely and accurately to maintain the integrity of financial data.

*Computer Operations covers IT operations across the IT environment as a whole and relates to the “Manage IT Operations” domain in CAS 315, as per the mapping in the block Overview.

Activities in IT operations often present operational risk, not a risk of material misstatement, depending on the entity’s specific circumstances. Some elements of IT operations may be relevant to the preparation of the financial statements, particularly when they serve not only as ITGCs, but also as information processing controls that directly support relevant financial statement assertions. For example, job scheduling is an IT activity that could directly impact the completeness and accuracy of financial data if it were to break down. Similarly, backup and recovery procedures may be important to the risk of financial misstatement if data recoveries are frequent, such as when systems are unstable, or if there is a cyber incident that restricts access to the live environment. ITGCs related to IT operations are important to many audits, but their overall relevance is more entity level specific. We may identify activities in IT operations that serve as information processing controls as part of the control activities component. The sub‑components of the Computer Operations domain typically include:

• Management of computer operations activities
• Batch scheduling and processing
• Real‑time processing
• Backup and problem management
• Disaster recovery

Example of ITGCs that may exist to manage computer operations typically include the following (CAS 315 Appendix 6.2(c)):

• Job scheduling
• Job monitoring
• Backup and recovery
• Intrusion detection

The following considerations may be helpful for identifying ITGCs in this domain that address the risks arising from the use of IT identified at the entity. See the block Identify risks arising from the use of IT for further guidance on identifying risks arising from the use of IT. Note: Not all considerations are relevant to every entity, and other risk factors may exist that will need to be considered. For example, cybersecurity risks and controls may relate to computer operations, and/or other ITGC domains. Please see the block cybersecurity risk assessment considerations for additional guidance on cybersecurity risks and controls.

When understanding the above, not all sub‑components and ITGCs may be applicable to every entity, and other risk factors may exist that may need to be considered. The manner in which computer operations are set up, authorized and controlled varies among entities, depending on the size and complexity of the environment and volume and types of operations undertaken. The tables below provide examples of risks and considerations for the audit split by sub‑component and referencing these ITGCs.

*Please see the block Cybersecurity risk assessment considerations for further consideration of the risks and controls relating to cybersecurity that could affect one or more of the ITGC domains.