Risk Assessment for IT audit within Banks and Financial Institutions

Risk Assessment Process

Risk assessment is a common first step in a risk management process. Risk assessment is the determination of quantitative or qualitative value of risk related to a concrete situation and a recognized threat. In other words, it is a process for risk identification, evaluation, and prioritization of the organization’s key business risks.

?To determine an acceptable level of risk, an organization must first understand its risk appetite — the degree to which the organization elects to accept risks without spending resources to mitigate them, or is willing to take on risks that will potentially create new value to the organization (e.g., mergers and acquisitions [M&A] transactions). The risk appetite is subjective in nature and varies from one organization to another. However, it is critical because an understanding will drive the organization’s strategic alternatives in the risk assessment process.

?A formal risk assessment process identifies threats and vulnerabilities and is sufficiently broad-based to encompass key internal and external factors. Risk assessment enables the organization to identify assets as well as the risks to those assets, estimate the likelihood of technology failures, and identify appropriate controls for protecting assets and resources. Management evaluates the results of the risk assessment process to prioritize solutions for potential problems, taking into account the severity of likely ramifications and the expense of implementing cost-effective and reasonable safeguards or controls.

?IT risk assessment is not a stand-alone process, but an integral part of an organization’s overall risk assessment process. While it is often convenient and necessary to identify and assess risks unique to the IT environment, the impact of those IT-specific risks must be evaluated in the context of overall business risks as well.

?An important factor to keep in mind is that the risk assessment process (as well as most audits) is itself subject to risk. For example, sampling risk can affect the outcome of the risk assessment process. Sampling risk is the risk that the items or areas being measured do not fully or accurately represent the universe of items to be evaluated. If some, but not all, employees are asked to respond to a survey as part of a risk assessment, the act of selecting a subset of the employee population results in exposure to sampling risk.

?There are two components of sampling risk: alpha risk and beta risk. Alpha risk (also known as a Type I error or false positive) is the risk that a significant error or exception does not exist but is identified due to characteristics of the sample selected. A large number of security risks might be identified in a risk survey, but if only the IT security department is surveyed, items that are not truly a significant risk to the business could be falsely included. Beta risk (also known as a Type II error or false negative) is the risk that a significant error or exception is missed or not considered, typically because it was not contained in the sample selected. If no risks to HR are identified, but no one from the HR department participates in the survey, there is an increased risk that areas relevant to the HR department will be overlooked in the risk assessment process.

Objectives of IT Risk Assessment

The objectives of IT risk assessment include aligning with an organization’s objectives, risks, and controls. An IT risk assessment enables the organization to better strategically manage risk and (among other benefits):

• ?Increase system and data reliability.
• Deliver high-quality information quickly and reliably.
• Increase satisfaction of internal and external customers.
• Reduce system complexity and the efforts of maintenance.
• Increase productivity.
• Reduce regulatory costs while remaining compliant.
• Initiate sustainable process improvements across the enterprise.

?As per ISACA’s IT Audit and Assurance Guideline G13 “Use of Risk Assessment in Audit Planning” section 2.2.2, “The IS auditor should consider each of the following types of risk to determine their overall level:

• Inherent risk.
• Control risk.
• Detection risk.

?

Inherent Risk

?Inherent risk is the susceptibility of an audit area to err in a way that could be material, individually or in combination with other errors, assuming that there were no related internal controls. For example, the inherent risk associated with operating system security is ordinarily high because changes to, or even disclosure of, data or programs through operating system security weaknesses could result in false management information or competitive disadvantage. By contrast, the inherent risk associated with security for a stand-alone PC, when an appropriate analysis demonstrates it is not used for business-critical purposes, is ordinarily low.

?Inherent risk for most IT audit areas is ordinarily high because the potential effects of errors usually span several business systems and many users. In assessing the inherent risk, the IT auditor should consider both pervasive and detailed IT controls.

?

Control Risk

?Control risk is the risk that an error that could occur in an audit area and could be material, individually or in combination with other errors, will not be prevented or detected and corrected on a timely basis by the internal control system. For example, the control risk associated with manual reviews of computer logs can be high because activities requiring investigation are often missed, owing to the volume of logged information. The control risk associated with computerized data validation procedures is ordinarily low because the processes are consistently applied.

?

The IS auditor should assess the control risk as high unless relevant internal controls are:

• Identified.
• Evaluated as effective.
• Tested and proved to be operating appropriately.

?

Detection Risk

?Detection risk is the risk that the IS auditor’s substantive procedures will???not detect an error that could be material, individually or in combination?with other errors. For example, the detection risk associated with identifying breaches of security in an application system is ordinarily high when logs for the whole period of the audit are not available at the time of the audit. The detection risk associated with identifying a lack of disaster recovery plans is ordinarily low because existence is verified easily.

?In determining the level of substantive testing required, IS auditors should consider:

• The assessment of inherent risk.
• The conclusion reached on control risk following compliance testing.

?The higher the assessment of inherent and control risk, the more audit evidence IT auditors should normally obtain from the performance of substantive audit procedures.

Risk Assessment and Measurement

There are various risk assessment and measurement techniques available to an IT auditor. They range from simple classification of high, medium, and low to more complex and scientific calculations. An IT auditor should consider the level of complexity and details commensurate with the nature and size of the organization being audited before deciding upon any specific methodology.

?Irrespective of the methodology being selected and used, an IT auditor should include an analysis of the risks to the enterprise resulting from the loss of controls supporting system availability, data integrity, and business information confidentiality. All risk assessment methodologies rely on subjective judgments at some point in the process (e.g., classification of risks into high, medium, and low or determining the severity of the impact as minor, moderate, or catastrophic). It is important that the IT auditor identify the subjective decisions required to be used in a particular methodology and consider whether these judgments can be made and validated with an adequate level of accuracy.

?According to Section 2.1.4 of ISACA’s G13, when deciding upon the most appropriate risk assessment methodology, IT auditors should consider:

• ?The nature of information required to be collected. Some systems use financial effects as the only measure, which may not be appropriate for IT audits.
• The cost of application and other licenses required to use the methodology.
• The extent to which the information is readily available.
• The cost of obtaining additional information before reliable output can be obtained, including the time required to be invested in the collection of this information.
• ?The opinions of others using this methodology and their views of how well it has assisted them in improving the efficiency and/or effectiveness of their audits.
• The willingness of management to accept the methodology as the means of determining the type and level of audit work carried out.

?

?

Risk Assessment Overview

?A typical risk assessment process involves:

• ?Understanding an organization’s business, including strategies and objectives.
• ?Developing a preliminary understanding of key businesses risks and processes, and aligning them to the organization’s strategies and objectives.
• ?Creating a customized risk universe containing risks faced by the organization.
• ?Determination of current monitoring activities outside of internal auditing.
• ?Understanding the effectiveness of entity-level controls.
• ?Scoping the risk assessment by obtaining input from all stakeholders.
• ?Assessing, prioritizing, and validating key business risks with the key stakeholders.
• ?Reporting the results of risk assessment and using those results to develop the audit plan.

?

Plotting risk factors: Upon assessment of risks, the results can be visually represented by scatter plotting them on a chart. One chart (MARCI) used for plotting the risk factors has four quadrants to categorize risk response actions: Mitigate (M), Assurance (A), Redeploy (R), and Cumulative Impact (CI). A MARCI chart depicts impact, vulnerability, and relative mitigated value rankings of the plotted risks. These can be ranked as high, medium, or low. The chart provides management with a point-in-time assessment of the impact of the significant risks on the organization’s value and its vulnerability to these risks. This map assists the organization in the development of the audit plan and should be periodically updated to accurately depict the organization’s exposure toward any untoward incident.

???

MARCI Chart Axis Definition

?The MARCI chart format can be used to show relative relationships between a variety of factors, and is frequently used for multiple purposes. It is important to understand what is being shown and the meanings of the categories for each axis. Many of the terms used have similar or overlapping meanings and can cause confusion if not clearly defined. Two commonly used factors are Impact and Vulnerability, though Impact versus Likelihood, Likelihood versus Vulnerability, and Inherent Risk versus Residual Risk are also commonly seen. Users should agree on what is being defined on each axis for their organization and when the values are calculated.

?For example, if risk is measured before mitigating controls are considered, then Vulnerability more likely would be used to refer to the exposure surface of the organization to the risk being measured; while if a risk is measured after mitigating controls are considered, then Vulnerability can be taken to mean the amount of risk to which the organization remains exposed or vulnerable, also sometimes called Residual Risk. To clearly communicate the meaning and implications presented by a MARCI chart, the auditor should clearly define the axes as part of the risk assessment process. For example, the following definitions for Impact and Vulnerability, if included in a risk assessment report containing a MARCI chart, would greatly help a reader to identify what the chart is attempting to show.

?Impact: Impact (also called Gross or Inherent Risk) is an estimate of the severity of adverse effects, the magnitude of a loss, or the potential opportunity cost should a risk be realized. Impact is measured for all the relevant risk factors such as Financial Impact, Reputation Impact, Regulatory Impact, etc.

?

• High: Scenarios where an organization’s cash flows are seriously affected, serious diminution in market share and reputation with adverse publicity, or happening of the risk event will significantly deter the achievement of the organization’s key business objectives.
• ?Medium: Scenarios where an organization’s cash flows may be affected, market share and/or reputation will be affected in the short term, or happening of the risk event will have some adverse effect on the achievement of the organization’s business objectives.
• ?Low: Scenarios where a negative impact on an organization’s cash flows will be absorbed under normal operating conditions or happening of the risk event will have very little or no impact on the achievement of the organization’s business objectives and minimal impact on the organization’s reputation and/or goodwill.

?

Vulnerability: Vulnerability (also called Residual Risk) is the extent to which the functional area may be exposed or unprotected in relation to various risk factors after existing controls have been taken into account.

• ?High: Controls minimally reduce the functional area’s exposure to an adverse impact. Controls are primarily either detective or nonexistent.
• ?Medium: Controls moderately reduce the functional area’s exposure to an adverse impact. Controls are primarily detective.
• ?Low: Controls currently produce the desired result to significantly reduce the functional area’s exposure to an adverse impact. Controls are primarily preventative and believed by management to be operating effectively.

?

Technology Audit Initiatives by Quadrant

• ?Mitigate — Management strategies to reduce or minimize the impact of, or the vulnerability to, a risk, or both.
• Assure — Increase the level of confidence that risk exposures are within the organization’s risk appetite.
• ?Redeploy Resources — Determine whether risk management resources are better deployed elsewhere.
• ?Cumulative Impact — Investigate further to determine the aggregate impact of a number of small impacting risks.

?Risks that have both high impact on the value and high vulnerability, which fall in the (M) quadrant, should be given a high priority and the remediation actions tracked at the executive and program level. For risks that are deemed to be of high impact but low vulnerability due to existing controls or mitigation measures, the organization should confirm that the measurement of vulnerability is realistic and the confidence in preparedness is justified. These risks fall in the (A) quadrant. Risks that have low impact and low vulnerability should be tested and monitored under the normal controls environment and efficiencies identified so that resources dedicated to low-impact, low-vulnerability risk can be redeployed. These risks fall in the (R) quadrant. Risks that have low impact but high vulnerability should be examined independently, but also measured for their frequency and cumulative impact on the organization’s objectives; the likelihood that multiple low-impact, high-vulnerability risks occur simultaneously also should be determined. These risks fall in the (CI) quadrant.

?

OCTAVE

With the growth of information systems, the confidentiality, integrity, and availability of information plays a vital role in an organization’s mission. Organizations should not form protection strategies for their information systems by focusing solely on infrastructure weaknesses and fail to establish or overlook the effects of risk on their most important information assets. When the IT function is solely responsible for an IT risk assessment, it can lead to a gap between the organization’s operational requirements and information technology requirements. Often, the IT staff members alone do not have the necessary understanding of the organization’s mission or business related needs. It is not clear whether important information is being adequately protected or significant resources are protecting relatively unimportant information. This is a situation that arises when the operational or business units of?the organization and the IT department are not communicating effectively, and the organization might be unknowingly assuming a high level of risk with respect to protecting its information assets.

?The Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) approach, developed by the Software Engineering Institute (SEI) and available from the Computer Emergency Response Team (CERT), defines the essential components of a comprehensive, systematic, context-driven, and self-directed information security risk evaluation. There are also several alternative approaches that are similar to or based on the OCTAVE methodology. Under the OCTAVE method, the operational or business units and the IT department work together to address the information security needs of the organization. An organization can make information-protection decisions based on risks to the confidentiality, integrity, and availability of critical information technology assets by following the OCTAVE method or a similar approach. The OCTAVE approach is embodied in a set of criteria that define the essential elements of an asset-driven information security risk evaluation.

?There are multiple methods consistent with the OCTAVE criteria. For example, the approach would be implemented differently in a very large organization as opposed to a very small one. Presently, the following three methods have been developed, consistent with the OCTAVE criteria:

• ?OCTAVE method, which forms the basis for the OCTAVE body of knowledge.
• OCTAVE-S, for smaller organizations.
• OCTAVE-Allegro, a streamlined approach for information security assessment and assurance.

?The OCTAVE method developed by SEI uses a three-phase approach to examine organizational and technological issues to assemble a comprehensive picture of the information security needs of an organization. The phases are described as:

• ?Phase 1: Build Asset-based Threat Profiles — This is an organizational evaluation. Key areas of expertise within the organization are examined to elicit the knowledge about critical information assets, the threats to those assets, the security requirements of the assets, what the organization is currently doing to protect these information assets (current protection strategy practices), and weaknesses in organizational policies and practice (organizational vulnerabilities).
• ?Phase 2: Identify Infrastructure Vulnerabilities — This is an evaluation of the information infrastructure. The key operational components of the IT infrastructure are examined for weaknesses (technology vulnerabilities) that can lead to unauthorized action.
• ?Phase 3: Develop Security Strategy and Plans — Risks are analyzed in this phase. The information generated from the organizational and information infrastructure evaluations (Phases 1 and 2) is analyzed to identify risks to the organization and evaluate the risks based on their impact to the organization’s mission. In addition, an organization protection strategy and risk mitigation plans for the highest priority risks are developed.

?Each phase of the OCTAVE method contains two or more processes. Each process is made up of activities. The following list highlights the phases and processes of OCTAVE:

??Phase 1: Build Asset-based Threat Profiles

-Process 1: Identify Senior Management Knowledge

-Process 2: Identify Operational Area Management Knowledge

-Process 3: Identify Staff Knowledge

-Process 4: Create Threat Profiles

?Phase 2: Identify Infrastructure Vulnerabilities

-Process 5: Identify Key Components

-Process 6: Evaluate Selected Components

?Phase 3: Develop Security Strategy and Plans

-Process 7: Conduct Risk Analysis

-Process 8: Develop Protection Strategy

?

Following are some of the important aspects of the OCTAVE method:

?Self-direction

?The OCTAVE method is self-directed. A small, interdisciplinary team?of the organization’s personnel (called the analysis team) manages the process and analyzes all information. Thus, the organization’s personnel are actively involved in the decision-making process.

?Analysis Team

?The OCTAVE method requires an analysis team to conduct the evaluation and analyze the information. The analysis team is an interdisciplinary team comprising representatives from both the mission-related and information technology areas of the organization. Typically, the analysis team contains a core membership of about three to five people, depending on the size of the overall organization and the scope of the evaluation.

Workshop-based Approach

?The OCTAVE method uses a workshop-based approach for gathering information and making decisions. In Phase 1, key areas of expertise within the organization are examined in facilitated workshops (also called knowledge elicitation workshops). The analysis team facilitates these workshops. Participants in the workshops are from multiple organizational levels. The knowledge elicitation workshops are important for identifying what is really happening in the organization with respect to information security. The outputs for Phase I through the workshops include: list of critical assets, security requirements for critical assets, threats to critical assets, current security practices, and current organizational vulnerabilities.

?

Catalogs of Information

?The OCTAVE method relies upon the following major catalogs of information:

• ?Catalog of practices — a collection of good strategic and operational security practices.
• Threat profile — the range of major sources of threats that an organization must consider.
• Catalog of vulnerabilities — a collection of vulnerabilities based on platform and application.

?An organization that is conducting the OCTAVE method evaluates itself against the above catalogs of information. During Phase 1, the organization uses the catalog of practices as a measure of what it is currently doing well with respect to security (its current protection strategy practices) as well as what it is not doing well (its organizational vulnerabilities). The analysis team also uses the catalog of practices when it creates the protection strategy for the organization during Phase 3.

?The OCTAVE method allows an organization to make information protection decisions based on risks to the confidentiality, integrity, and availability of critical IT assets. It also enables business units and IT departments to work together to address the information security needs of the organization.

The Role of Management Sponsorship in the Risk Assessment Process

Management’s role in developing an internal risk model that drives subsequent audit planning and testing activities should never be underestimated. Management’s commitment and ongoing support is critical to help ensure participation by all necessary participants in internal risk modeling through the risk assessment process. To secure their commitment, the team entrusted with the responsibility of risk assessment and modeling holds an initial meeting with the executives and management to describe the process and its benefit to the organization. Keeping management posted with updates helps in sustaining their interest levels.

?

Use of Risk Assessment in Audit Planning

Risk assessment in audit planning helps an organization identify risks that can prevent it from obtaining its objective and develop a risk-based audit plan focused on high-risk areas. As per ISACA’s IS auditing guidelines G13, “Use of Risk Assessment in Audit Planning,” IS auditors should use the selected risk assessment techniques when developing the overall audit plan and planning specific audits. Risk assessment, in combination with other audit techniques, should be considered when making planning decisions such as:

• ?The nature, extent, and timing of audit procedures.
• The areas or business functions to be audited.
• The amount of time and resources to be allocated to an audit.

A comprehensive risk assessment provides a basis for the development of an IT audit plan that is risk-focused and flexible enough to meet the organization’s ever-changing business environment. A year-long IT audit plan may not be an effective way to manage the dynamic needs of the organization. On the contrary, it should be viewed as a living document that is aligned with the business activities and supports management efforts to implement organizational strategies successfully. An audit plan that fails to keep pace with the changes renders the organization vulnerable to significant business risks. Key steps in developing a risk-focused internal audit plan include:

• ?Mapping the key business risks to auditable units.
• ?Developing an audit plan that addresses auditable entities with highest risk, disregarding the skill-sets availability.
• ?Assigning resources with the skill sets necessary to participate in the audits.
• Validating the audit plan with management and the audit committee.
• ?Revisiting the audit plan as well as updating the risk assessment, as a result of a change to the organization’s business environment.