Previous Table of Contents Next


Section 23
Identify Application Risks

Auditors of every discipline often rely on their experience and instincts to determine which audit areas to emphasize or exclude. Automated applications often include an increased level of risk and complexity. This increase makes it much more risky, if not impossible, for the IT auditor to rely strictly on judgment for final audit planning. This section presents a risk-based approach for the initial evaluation.

General Risk Assessment. IT auditors evaluate application risks to determine the level of resources to commit to the review and then to determine how to allocate the assigned resources.

Time Requirements. IT auditors preparing a risk/control matrix should plan to spend 20 to 80 hours preparing a matrix for all applications never before reviewed, and 8 to 24 hours to update an existing matrix.

Specific Procedures. The IT auditor will need to prepare a list of controls related to a particular application, along with a comparable list of potential risk exposures. The overall goal is to determine whether existing risk exposures are adequately addressed by existing controls. Application risks can be grouped into one or more of the following three areas:

1.  Inherent risk is always part of a particular application.
2.  Technological risk may be based on the use of unknown technology, the use of new technology by untrained personnel, or the risk that someone will use powerful new software against the company’s interest.
3.  Situational risk is based on the idea that additional risks may be created by the facts and circumstances surrounding a particular transaction.
4.  Volume risk is founded on the idea that transaction volumes, average transaction value, and other similar items may reflect a higher level of risk.

THE MEANING OF RISK

IT auditors should adopt one of the possible meanings of risk and use it consistently within the enterprise. The two primary alternative definitions are differentiated by the consideration of controls. Risk can be defined as the potential for problems, errors, or unauthorized activity. Alternatively, risk can be defined as the residual potential after consideration of the existence and effectiveness of controls.

There is no single definition in use within the profession, and this author will not advocate one over the other. The former definition is used for the purposes of this publication.

The specific risks included in each risk area above are not meant to be all-inclusive. IT auditors should note that the author has assigned a risk level to each risk area as well as to each specific risk. This was done to reduce the chance that one area could inappropriately overshadow the others.

The IT auditor is expected to assign a numeric risk level to each specific risk item based on his or her review procedures for gathering background data and evaluating that data. The risk level (1-3) is multiplied by the estimated risk to get a weighted score, and the weighted scores are totaled to determine total risk.

IT auditors completing the initial risk assessment procedures will need to consider application risk in two contexts. First is stand-alone risk, while the second is relative risk.

STAND-ALONE RISK

IT auditors focusing on stand-alone risk will need to compare the risk between application elements to determine how audit resources should be allocated. This approach is most significant in situations where a more complex application is being reviewed, and there is a need to select which components will receive the most attention.

RELATIVE RISK

IT auditors focusing on relative risk are most likely to estimate the total risk per application so that comparison can be made. The simplest comparison is to take all of the application totals, sort them in descending order, and start by auditing the applications from the ones with the highest scores to the lowest.

IT auditors can use the risk score in two ways. They can evaluate a single application by comparing its risk score to the maximum possible score. They can also compare the scores of two or more applications in total or in detail. The auditors should be careful not to read too much into scores that are similar. They probably can make preliminary assessments based on significant differences of 15% or more.

ENSURING SUCCESS

IT auditors can increase the likelihood that these tasks will be completed successfully. They can consult external sources for traditional applications, provide the planning time and resources required to produce reliable results, and draw their opinions carefully from the data collected, among others. IT auditors should consider using a risk assessment work plan.

The IT auditor is likely to recognize that there are going to be situations where a new type of application requires a different approach. This enhanced approach is based on the work of a single, experienced individual who can take the application information and perform the same analysis that would otherwise be performed by the group. This individual would perform essentially the same activities as demonstrated below for the regular risk assessment process.

1.  Form risk assessment team. The auditor in charge should probably be the risk assessment team coordinator. The coordinator’s responsibilities include identifying the team members, outlining the proposed process, keeping the meeting(s) on track, and handling necessary administrative requirements.
IT auditors should not need to include the entire audit team unless the team is limited to one or two individuals, or the risk assessment is so complex that it will be necessary to break into subteams. The IT auditor includes the entire audit team to ensure that every team has at least one audit representative. The auditor will have to see that the appropriate personnel from other business areas are included. The possible organizational participants were described in detail in Part VII, and included end-user management, end users, security personnel, and other IT personnel.
2.  The risk assessment approach. The IT auditor in charge should work with select client personnel to determine whether a group meeting or one-on-one interviews would be more effective. The IT auditor then schedules the meeting or meetings as deemed necessary. The IT auditor should make theses arrangements to take place as quickly as possible as the results are needed to continue the overall review.
3.  Final meeting preparation. The auditor in charge should ensure that the appropriate materials have been organized and copied well before the meeting. He or she is also responsible for ensuring that the meeting facilities are suitable to their intended purpose.
4.  Conduct the meeting or meetings. The IT auditor has probably realized that these meetings probably need less structure than many other meetings. The meeting format needs to encourage creativity and brainstorming—an open exchange of ideas with no immediate recrimination, ridicule, or retort. The following techniques often help ensure the meeting has a successful overtone.
a.  Team members should state their understanding of the meeting’s objective(s). This can keep the meeting focused and provide a basis for subsequent brainstorming.
b.  Someone should record brainstorming sessions in some fashion from the team. The team leader might need to structure this activity, at least during the first time around to ensure that every participant has a chance to present his or her ideas and thoughts. There should also be at least one chance to comment on other’s ideas.
c.  The IT auditor in charge should strongly encourage a requirement that the team(s) develop one or more specific solutions to the problem the team(s) is(are) addressing. A team may choose to record its version as an update of an existing diagram or narrative. Unless this existing item can be enlarged, IT auditors are strongly encouraged to provide flip charts or whiteboards so the entire group can see the same solution. This should help prevent confusion and inconsistency when a final draft is prepared.
5.  Completing the risk assessment. IT auditors should ensure that the final opinions regarding potential and existing risks, along with existing or proposed solutions, are fully documented in an effective manner.


Previous Table of Contents Next