In Part I of our SAS 145 series, we explored the increased focus on risk assessment as the foundation for risk-based audits. In Part II, we’re expanding on the concept of risk assessment and specifically focusing on the risks relating to information technology.
For anyone doing a PCAOB integrated audit, incorporating information technology (IT) considerations, such as general IT controls, into the audit plan might seem like old news, but for everyone else, this is a paradigm shift. We’ve been writing about this for many years now, but the ever-increasing role of technology in business and as a result, in audits, has now made its way into auditing standards applicable to all audits.
Let’s explore some of this new guidance and considerations for teams in applying SAS 145.
Definitions
The new SAS 145 guidance includes 13 definitions. In Part I, we discussed how the AICPA revised the definition of a significant risk, to be more focused on the inherent risk factors and less dependent upon the nature of the procedures to address the risks. Of the 12 remaining definitions, four relate to information technology, including the following:
The standard goes on to further define IT applications (programs used in initiation, processing, recording and/or reporting of transactions or information), IT infrastructure (network, operating systems, and databases), and IT processes (processes to manage access and changes to the IT environment). Though one could argue that “processes” used generically could/would incorporate IT naturally, it’s interesting to note that the AICPA made sure to explicitly call out IT.
Understanding Controls
Risk assessment has always been predicated on understanding the processes in place at an entity, which naturally involves understanding the internal controls built into a process. However, historically, many audit engagement teams simply obtained a process narrative from the client, incorporated that narrative into the planning documentation and then moved on to assess risk. If teams weren’t relying on controls, they didn’t feel the need to delve into the control process and thoroughly document the design and implementation of controls. This was generally true for any non-integrated audit, public or private, regardless of the requirements within the auditing standards.
Now, with SAS 145, planning and risk assessment requires engagement teams, regardless of controls reliance, to document their understanding of the design and implementation of controls for the following areas:
We’ve yet to see how stringently this last bullet will be enforced through the peer review process, but it is essentially a “catch-all” since, inherently, we need to understand processes (which are made up of various controls) to fully understand potential risks and appropriately design an audit approach. That’s just auditing 101, but perhaps we’re a little biased.
Understanding IT Controls
IT in the modern business world is becoming pervasive as companies automate processes and continue to invest in technology solutions. It should go without saying that understanding the design and implementation of controls fundamentally includes understanding the IT controls. However, because this is such a shift, the AICPA made a point of explicitly calling out requirements related to IT. Beyond just identifying automated controls, this incorporates understanding how IT plays into IT-dependent manual controls and how IT produces information and data. Given data is the foundation of most audit procedures, it is crucial that we understand how information is completely and accurately processed, where data is stored (databases and data warehouses), and how it is produced / reported.
For all audit areas covered by one of the four bullets above, the engagement team must understand “how information flows through the entity’s information system, including how transactions are initiated, and how information about them is recorded, processed, corrected as necessary, incorporated into the general ledger, and reported in the financial statements…[1]” This means understanding what systems and applications are being used and what risks arising from the use of IT (RAFITs) exist. The engagement team must then also identify and evaluate the design and implementation of the general IT controls (GITCs) that address each of the RAFITs. That means understanding controls addressing concerns around logical access and change management, to name a few of the GITCs.
But what if a company doesn’t have any controls in place? Through various audit quality advisory services, we’ve heard many teams tell us that their clients don’t have formalized processes and controls. In these circumstances, we expect the engagement team to understand what controls (manual and/or IT related are in place and to evaluate whether there is a broad-scale material weakness that should be communicated to those charged with governance, such as the audit committee or board of directors. In addition, the audit should then be designed incorporating this material weakness, which should increase overall risk. If the client refuses to accept a material weakness, then audit teams will have no choice but to dig into the controls and understand the entire process, including IT considerations.
Incorporating IT into Audits
While we can all recognize the importance and prevalence of IT in our own lives, many firms are resistant to invest in the resources needed to incorporate an understanding of IT into the planning and risk assessment process. Firms should consider the following:
Resources: Given the fact that many firms in the private company space only perform substantive audits, we have seen a dearth of IT knowledge and experience amongst engagement teams. Firms will need to consider hiring IT professionals, either as direct hires, such as creating an IT assurance group, or as contractors. Either way, firms should begin to expect that every audit engagement will incorporate some time from IT professionals. For clients that have little to no formalized controls, the IT auditor may only need a couple hours, but for larger clients with more structured internal control environments, audits should be budgeting time for IT auditors to assist with the planning and risk assessment process. Remember, it’s not just understanding the process, but its also evaluating the design effectiveness and implementation of controls; this generally means walkthroughs. While a non-IT auditor might be able to assess whether controls are implemented, understanding the design effectiveness requires an understanding of the relevant risks, including risks arising from the use of IT. In addition to engaging IT professionals, it is also important to ensure firms are hiring the right kind of professionals. There are plenty of IT professionals in the marketplace, but most IT professionals come from a consulting background and IT within the context of an audit is a very different mindset. IT auditors need to understand more than just GITCs; they need to understand the business processes and the flow of transactions in the entity’s information systems. This means that IT auditors need to work in tandem with financial statement auditors to ensure both auditors fully understand the flow of information and with that knowledge, holistically evaluate the risks of material misstatement. Nothing in an audit should be done in isolation as everything is interconnected.
Training: Historically, we have seen many firms offer IT training, but limit the attendees to only IT auditors. We encourage firms to being building out IT trainings for both IT and financial statement auditors. Because IT is so pervasive now, financial statement auditors need to be able to speak the language of IT and hold a conversation. When an IT auditor says there is a change management concern, the financial statement auditor needs to understand the potential gravity of the issue. For instance, a change management deficiency could render an entire system unreliable which could have significant repercussions for relying on any data from that system. While it is incumbent upon IT auditors to speak up and ensure they adequately communicate the risks, it is also critical that financial statement auditors learn the language to engage in that conversation. Integrating IT training so that IT and financial statement auditors are both present will also allow for IT auditors to better understand financial statement audit risks. Ideally, these trainings will allow for cross-line information sharing; we all have something to learn from the other.
In addition, while a financial statement auditor may attend an IT training, it’s important that firms understand that a one-off training over IT does not mean a financial statement auditor can perform full testing over IT controls (including GITCs). Knowledge and competence take time to develop; that’s why the CPA and CISA licenses, amongst other certifications, have both education and experience requirements.
Templates: To build upon the knowledge being taught in trainings, firms should also consider building out templates that help guide auditors in understanding relevant IT considerations, such as templates for performing walkthroughs of IT-automated and/or IT-dependent manual controls. In addition, firms could consider building out templates to help facilitate the aggregation of IT applications, programs, reports and spreadsheets inventories. From this listing, there could then be separate templates to assist with identifying the relevant risks related to each item in the inventory as well as evaluating the design effectiveness and implementation of relevant controls identified to address the RAFITs.
We also encourage firms to embrace the use of flowcharts; while we may understand the general process conceptually, flowcharts really help to map out systems and where/how information is stored and processed; data flow diagrams can be especially useful for entities with a number of systems and interfaces. Visually seeing information flow between systems on a flowchart helps to understand the risks (i.e. “what could go wrongs”) within the process.
Integration: Finally, we recommend firms consider the concept of integration. This concept has two senses:
1. Integration of the audit team: Engagement teams work best when IT auditors are integrated into the financial statement audit and not viewed as “separate.” In other words, IT auditors should be a part of the planning and risk assessment process and should be incorporated into process walkthroughs. Testing approaches should be clearly discussed to understand how all elements of a control are being tested so as to ensure all automated AND manual components of a control are evaluated. This again emphasizes the importance of training engagement teams so that financial statement auditors can dialogue around IT testing and so that IT auditors understand financial statement audit objectives.
2. Integration of the audit: If teams are already performing procedures to evaluate the design and implementation of IT controls, including GITCs, why not go ahead and perform an integrated audit? We’ve written about the inevitability of integrated audits, but certainly now with the new SAS 145 requirements, it seems like an obvious next step to leverage the work performed and plan on a controls reliance approach. The bulk of controls testing work is performed in identifying and evaluating the design and implementation of controls. Testing the operating effectiveness is the easy part once the design has been understood. This will become increasingly important, if for no other reason than testing the completeness and accuracy of information produced by IT systems. The completeness and accuracy of data is paramount for any audit procedure, but especially as data analytics gain traction.
Key Takeaways
Johnson Global Advisory
1717 K Street NW, Suite 902
Washington, D.C. 20006
USA
+1 (702) 848-7084