At Tandem, we occasionally receive questions from our clients on the topic of an "IT audit risk assessment," most often in reference to an examination request list item. Where did this concept come from, what exactly is it, and how would you begin to conduct one? Let's find out.
The concept of an IT audit risk assessment was first mentioned in the Interagency Guidelines Establishing Information Security Standards (circa 2001), which are the regulatory implementation of GLBA. The standards say:
"Regularly test the key controls, systems and procedures of the information security program. The frequency and nature of such tests should be determined by the institution's risk assessment."
One thing to note here, the regulation doesn't use the words "an IT audit risk assessment." Even though this may be the origins of the idea in financial institution regulatory circles, the exact term would not appear until later.
While regulations are often prescriptive (i.e., it prescribes what must be done), in contrast, guidance is often more descriptive (i.e., it describes how to do something). So, to find out more about an IT audit risk assessment, let's see what the guidance says.
The earliest guidance on audit risk assessments seems to originate from the FFIEC's 2003 Audit Booklet. The booklet states that each financial institution's audit program should include "a risk assessment process to describe and analyze the risks inherent in a given line of business" (page 11). The booklet later indicates that the risk assessment should be used to guide decisions about "the frequency and depth of each area's audit" (page 15). These concepts are quoted verbatim in the 2012 version of the booklet. Nevertheless, the phrase "audit risk assessment" does not appear in either version of the booklet.
The first documented use of the phrase "audit risk assessment" in FFIEC examination procedures did not appear until the release of the FFIEC's 2015 Management Booklet. While the phrase "audit risk assessment" does not exist in the booklet's contents, Objective 6.3 states that examiners should:
"Determine whether the board, or its committee, has appropriate oversight of audit through the following: (a) Audit risk assessment and audit plan."
Following this use, the phrase has been used in several additional examination procedures, guidance, and resources, including the:
Based on what we can see in the guidance and examination procedures, an IT audit risk assessment is a component of a risk-based audit program, designed to help auditors facilitate effective resource allocation. The original intent was not necessarily to exist as a standalone document, but rather as a process, using the financial institution's existing risk assessments to make decisions about frequency and scope of audits.
As the phrase "audit risk assessment" began to appear in examination procedures, an idea emerged that this must be an isolated process with a standalone, independent deliverable. This caused confusion, as the process and result often looked like the results of information security risk assessments: a list of assets, prioritized by risk or importance, with a list of controls used to mitigate risks.
When it comes to the difference between an IT audit risk assessment and the organization's existing information security risk assessments, the difference lies in how the assessment results are used:
Historically, financial institution IT systems were relatively standardized. This means it was obvious which areas needed to be audited (e.g., the core, Active Directory, wire transfer, and ACH systems, the network, etc.) and there were fewer technologies which needed to be audited. In many cases, the most efficient and effective auditing method was to audit everything once a year.
As financial institutions diversify their technology solutions, a formalized plan can inform auditors with limited resources which systems need auditing and at what frequency. If systems are audited too frequently, it can result in misallocated valuable resources (e.g., money, time, expertise, etc.). If systems are not audited frequently enough (or even at all), it can result in significant vulnerabilities and security concerns.
While the driving force behind an IT audit risk assessment may currently be an examination request list item, an IT audit risk assessment is a valuable process, designed to improve an organization's security and bottom line.
Since an IT audit risk assessment is a process, there are numerous ways to conduct one. While the steps taken can be important, it is most important that the process enables you to justify your reasoning about what and how frequently areas are audited. If you are not sure where to begin, here are some recommended steps.
Consider and answer the following questions. Do your risk assessments:
These questions come from a list of considerations on pages 11 and 12 of the FFIEC's Audit Booklet. They describe what should be included as part of a risk-based auditing process. If it sounds familiar, that's a good thing because these are things you should already be doing as part of your information security risk assessment process. In other words, if you answered "yes" to each of the above questions, then your existing risk assessments should be satisfactory for the purposes of conducting an IT audit risk assessment.
As a "scoring system" is one of the primary components, the asset management, and risk assessment process should typically result in comparable ratings, which can be associated with an audit frequency to determine a suggested audit cycle. For example, some common ratings you could use from Tandem Risk Assessment in the IT audit risk assessment process include:
Whichever categorization you choose to use, it is important to connect the rating scale with an audit frequency. For a simplified example, assets with a:
By doing so, you can determine an audit cycle and justify your decisions, based on the asset value.
Once you have determined the audit cycle, the next step is to develop a schedule. Determine when each area would be audited or document an exception to detail why it would not be audited according to the cycle.
As we have established, an IT audit risk assessment is a process, but it remains important to show your work, so your Board of Directors, senior management, and examiners can understand your processes. An ideal place to document the details of this process would be in the organization's testing policy or in a standalone audit plan. Elements to consider include the:
Additional elements to consider are listed on page 8 of the FFIEC's Audit Booklet.
Yes, the Tandem suite of products includes several features which can help with the IT audit risk assessment process.
Current Tandem users can refer to the Tandem Knowledge Base for additional details regarding how to manage the IT audit risk assessment process in Tandem.
Risk-based auditing is a process of thoughtfulness and intentionality. It is less about having a specific document with the words "IT audit risk assessment" printed across the front and more about the organization being able to justify the decisions behind what, why, and how frequently you are auditing certain areas. This ensures the organization can most effectively use its resources, while also ensuring a high level of security.
To get started or to take your processes to the next level, check out how Tandem Risk Assessment, Audit Management, and Policies can help you put your best foot forward as you take your IT audit risk assessment processes into the future.
Update: This blog was updated on 01/16/2023 to include additional regulatory requirements for IT audit risk assessments.