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.

Where did the phrase "IT audit risk assessment" originate?

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:

What is an IT audit risk assessment?

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.

What is the difference between IT audit risk assessment and information security risk assessment?

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:

  • Apply Controls: Information security personnel use the assessment results to identify high-risk areas and ensure controls are applied to mitigate the risks.
  • Validate Controls: Auditors use the assessment results to determine how frequently and at what level each area's controls need to be validated to ensure they are mitigating risks, as expected.

Why are examiners asking for an IT audit risk assessment?

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.

How should you conduct an IT audit risk assessment?

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.

Step 1: Review your organization's existing risk assessments.

Consider and answer the following questions. Do your risk assessments:

  • Describe and analyze the risks to your business?
  • Cover all the organization's assets, systems, applications, processes, etc.?
  • Consider factors, like control adequacy, the operating environment, sensitivity of data, previous audit results, etc.?
  • Use a "scoring system," to rank importance and prioritize risks?
  • Get reviewed, updated, and approved at least annually?

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.

Step 2: Use the risk assessments to determine an audit cycle.

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:

  • CIA Rating: A rating of an asset's confidentiality, integrity, and availability scores, determined by the types of data associated with the asset. This can be beneficial because it demonstrates each asset's inherent value.
  • Overall Risk Rating: A rating which conflates the asset's CIA rating with the residual risk of threats to the asset and data. This can be beneficial because it considers not only the value of the asset but also how much risk remains once key controls have been applied.

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:

  • "High" rating could need audited every "12 months."
  • "Medium" rating could need audited every "24 months."
  • "Low" rating could need audited every "36 months."

By doing so, you can determine an audit cycle and justify your decisions, based on the asset value.

Step 3: Schedule audits according to the frequency.

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.

Step 4: Ensure the process is documented and reported.

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:

  • Organization's list of assets, prioritized by rating.
  • Audit cycle frequency definitions.
  • Official audit schedule (and any exceptions) for at least the next 12 months.
  • Budget, goals, staffing needs, reporting structures, etc.

Additional elements to consider are listed on page 8 of the FFIEC's Audit Booklet.

Are there any tools for making an IT audit risk assessment?

Yes, the Tandem suite of products includes several features which can help with the IT audit risk assessment process.

  • Tandem Risk Assessment is designed to help you create a list of assets, associate the assets with other Tandem elements (e.g., third-party services, software, systems, business processes, etc.), perform risk assessments over each asset, and obtain helpful reporting. This product can provide the foundational details you need to begin performing your IT audit risk assessment.
  • Tandem Audit Management takes things to the next level by allowing you to create an audit schedule in advance, assign responsibility, document each audit's scope, and associate controls from your risk assessments to prove their effectiveness.
  • Tandem Policies offers a set of cybersecurity policies, including a Security Testing policy to help the organization document and define the components of the audit plan.

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.

Conclusion

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.