Previous Table of Contents Next


The entire IT audit plan may be driven by nontechnical issues. External constraints may require that certain audits be performed on a predetermined schedule, and these could consume 100 percent of the available resources. A limited risk assessment model may still be useful for sequencing and refining the required reviews.

It is more likely that the majority of the available IT audit resources can be spent on discretionary reviews. This appears to support having the IT audit manager perform a risk assessment, including additional internal and technical considerations.

Define the Risk Assessment Model. The included model groups the universe of potential risk factors into five categories. The IT audit manager may group or break down these categories as necessary, and also restrict or extend the breadth and depth of the risk factors in each category. The categories are summarized below.

  Criticality: This may be best understood by considering the potential impact of the automated application system or hardware being unavailable. Simply put, the closer an outage comes to stopping the business, the more critical it is.
  Complexity: This should be separated because there is no inherent direct relationship between how complex and how critical an automated application system is. There is a direct relationship between complexity and the risk of failure, and that risk is the focus in this category. The size of a hardware or hardware system is often included in the evaluation of complexity, but it can be included elsewhere. The relationship between size and complexity can be high, but it can also be quite low.
  Technology: This is an important, but equally difficult, category for assessing risk. Technology is important because the right technology should efficiently and effectively support business activities. The wrong technology could easily lead to missed opportunities and wasted resources. The IT auditor trying to assess technology issues is further confounded by having no means to objectively determine the “right” technology for each company and related nuances.
  Control environment: This is where any prior IT reviews are included. The IT auditor, whether experienced director or first-year staff, is likely to be most comfortable and confident working in this category. The IT auditor should be careful not to over-emphasize the control environment due to that comfort factor.
  Integration: The more tightly integrated the systems are with the business activity, the greater the business risk if there is a problem. The irony is that weakly integrated systems represent an almost automatic IT audit recommendation.

Develop Risk Factor Weighting. The IT audit manager creates a weighting methodology to complement and support the risk factor categories defined for the risk assessment model. There are numerous alternatives available, but the text utilizes a basic automatic approach on a 100-point scale.

The 100 point system is one of a wide range of alternative implementations of the arithmetic model. There are also at least three different ways to implement the 100 point system. The first method illustrated in Exhibit 5-1, assumes that each group of categories or subcategories must total 100 points. The total score achieved in a subcategory group is reduced when the score moves up to the next level.

The second method is built on the assumption that there are only 100 points, and they are allocated across the full range of categories and subcategories. The method illustrated in Exhibit 5-2. The third method is based on the idea that each individual category, a subcategory, is scored on the same scale, such as 1 to 100, or 1 to 10. The actual score is multiplied by a weighting factor. This method is illustrated in Exhibit 5-3.

All three exhibits include sample data as if each of the methods were used to evaluate a single automated application system. The IT auditor should notice that all three methods lead to the same final risk score. The method selected may be more closely linked to the experience and personal preference of the auditor than anything else.

Proponents of the first method, which combines the other two methods, believe that it allows the IT auditors performing the risk assessment see the complete situation without over complicating the risk scoring process.

Proponents of the second method believe it to be the most realistic because there are no secondary in automatic calculations. There are only 100 points to be had, and each category’s contribution to the total is clearly visible.

Proponents of the third method believe that its advantage is based on the fact that the IT auditor performing the review evaluates each category or subcategory on the same scale, and that repetition and consistency will lead to better results.

The first method, the 100-point must system, is portrayed in Workpaper 5-1. This workpaper is structured with one automated application system or general controls review per column, and the categories and subcategories down the left side. This structure is probably better suited to those situations where there are a limited number of automated application systems and general controls reviews. This workpaper is designed with the categories as columns, and the list of potential automated application systems and general controls review reviews appear down the left side of the risk assessment model.

There is no single set of risk factors that encompass every situation the IT auditor may encounter. The following lists illustrate some of the risk factors that might be included in each category. Criticality (defined as the impact of a system outage on):

  The company’s mission
  The well-being, safety, or interest of third parties
  The company’s competitive advantage
  The public’s confidence in the company or product
  The ability to provide privacy, confidentiality, or security
  The interfaces with internal or external third parties

Complexity:

  Number of users
  Number of interfaces
  Network complexity
  Number of input items
  Number of physical files
  Number of logical files
  Number of simultaneous interactive queries
  Complexity of core programming language
  Number of time zones supported
  Number of devices
  Transaction volumes
  Complexity of individual transactions

Technology:

  Number of technology platforms:
—Mainframe
—Midrange
—Client/server
  Number of hardware vendors
  Number of software providers

General controls, including:

  IT administrations
  Physical access controls
  Logical access controls
  SDLC methodology
  Backup and recovery

Step 4. The risk assessment model can be used in both developing and production automated application systems. The results are comparable because the potential risk can be assessed for systems being developed. The difference between the two really only relates to evaluation, there controls as the systems in development cannot be evaluated.


Exhibit 5-2.  Risk Assessment Model (Weighted System)


Previous Table of Contents Next