COBIT Case Study: IT Risk Management in a Bank 

 

This case study is a real-life example of using COBIT® for IT risk management within a global bank. COBIT was used effectively for managing risk within the technology teams to ensure that appropriate IT governance and IT assurance processes were utilised throughout the bank.

Background

The bank in the given case is a global conglomerate with operations in more than 50 countries and with more than 125,000 employees across the globe. The bank’s technology teams are located throughout the world to support global lines of business. The IT teams include development centres that are part of the bank and others that are outsourced to vendors, as well as technology back offices that support IT infrastructure and services. The bank had a history of multiple governance and assurance templates and processes followed by different teams, regions and locations. Hence, the key challenge was to create a common governance and assurance process across technology teams.

The technology governance and assurance programme was designed through a risk management framework to ensure effective risk and control management.

The framework was defined to address existing risk and control management weaknesses, such as:

  • Immature processes for assessing and testing compliance
  • Lack of a single control repository, resulting in control duplication
  • Lack of a clear, repeatable process for completing risk assessments
The new framework was expected to enable technology teams to understand the significant operational risks and their impact on the wider organisation by:
  • Addressing areas in which risks were not effectively controlled
  • Allowing technology executives to demonstrate regulatory responsibilities efficiently
  • Using a common platform for reporting all regulatory requirements across regions and countries
  • Effectively reporting technology risk and control weaknesses that may impact the business
  • Implementing a standard process across regions and offices to ensure consistency and avoid duplication of reporting

Use of COBIT

The governance team decided to use COBIT as a standard framework. A team of professionals—including risk, IT security and US Sarbanes-Oxley Act process experts—was set up to define the processes and templates. The team primarily worked on three areas:

  1. Defining a framework to use—Control objective framework (COF)
  2. Identifying a standard definition of ‘entities’ against which risks and controls were to be evaluated—Key entity management model
  3. Identifying a risk management process—Risk and control assessment (RCA)

Key steps in the process of developing a new risk management framework are described in the following sections.

Step 1—Defining COF

The COF was defined to link risks affecting technology offices and industry standard best practice controls as defined by COBIT. Three objectives were set whilst defining the COF:

  1. It should act as a tool to facilitate the effective assessment of risks and controls within technology.
  2. It should act as a reporting framework to demonstrate how technology satisfies reporting regulatory requirements, including those of Sarbanes-Oxley.
  3. It should act as an aid to drive management assurance.
The steps in implementing COF using COBIT included:
  • Identify principal risks—The principal risks of level I were defined and frozen based on earlier information. Those identified included risks related to technology, operations, people, legal and regulatory, financial reporting, financial crime, brand, and change.
  • Identify level II risks—The principal risk was further broken down into level II risks. As an example, the ‘technology principal risk’ was further drilled down to:
    - Inadequate design/testing of IT systems
    - Unavailability of IT systems
    - Lack of IT security
  • Identify control objectives—For each of the level II risks, control objectives were identified using COBIT. Figure 1 indicates the mapping of the level II risks with the control objectives identified against each of the technology risks.

Figure 1—Mapping Level II Risks

Benefit of Step 1

Prior to implementing this framework, each entity, organisation and location had its own set of controls. COBIT helped in developing and managing a single list of controls for each type of risk through the mapping of needed controls to COBIT. In turn, this assisted with the attestation of each type of risk, which provided confidence to senior executives on the reporting and attestation process. Subsequently, a risk assessment process was developed to define risks and controls. This helped in ensuring that adequate controls were deployed to cover the principal risks and level II risks.

Step 2—Identifying Entities for Managing Risks and Controls

The key entity management model was defined to include IT building blocks, against which risk and control assessments were to be performed. The IT building blocks are logically linked together for reporting purposes to provide a risk and control assessment for all supporting services within the purview of the technology office.

The IT building blocks were defined as:
  • Process entities—These represent the processes used to support, control and manage the IT environment. Any control issues in a process entity would affect many IT services, e.g., change control is pervasive across most IT services.
  • Supporting services entities—Linking with process and technology entities allows for a complete end-to-end risk and control assessment for that supporting service, e.g., interfacing risks amongst technology entities, service-level risks for end-to-end IT service, and integration risks (the management of handoffs between departments).
  • Technology entities—These represent the ‘traditional’ IT components, e.g., servers, applications, networks and firewalls. The service maps and the RCA process were used to facilitate the identification of the key technology entities that make up each supporting service.
  • Project entities—Whilst project entities have no effect on the top 20 services, it is very important to capture any control and risk information ahead of go-live. This will allow the target state controls for a new development/project change to be assessed, reported and communicated prior to go-live. Some examples of the top 20 services include ATM connectivity and core banking application support services.

The bank’s method for defining IT services is through an IT service catalogue. As part of its IT service catalogue, each of the top 20 services was identified for the supporting services that underpin it. A service map was created for each supporting service. The service maps illustrate the technology components that are linked together to support the end-to-end services.

Each process entity and technology entity is distinct and can be linked to multiple supporting services. As a result, the key entity management model is flexible and can support expansion to additional IT services as required. The linkage amongst entities allows risk assessments to be aggregated to provide an end-to-end service risk profile, which is meaningful to management and the different clusters managing the entities in the overall service.

Benefit of Step 2

Prior to implementing the new risk management process, each region, country, etc., of the bank had its own risk and control matrices. The risk and controls evaluation was based on the understanding of each team working on risk management within the region, and there was no focus on the ‘end result’, i.e., the impact of risk on customer service. COBIT helped in identifying key services that had an impact on business and customers and kept the focus on controls. Once such risks were identified, the controls were frozen based on the COBIT framework and were evaluated for control effectiveness—with the clear objective of determining the impact on customer service. This resulted in reducing the total number of incidents and reducing the impact of incidents on customers and\or customer services.

Step 3—Defining and Implementing the RCA Process

The process overview in figure 2 highlights the five steps to performing a risk assessment. Within each of the steps, the key tasks were identified. A series of tools/process aides was defined to assist with the scoping, scheduling and delivery of the risk assessment, and is outlined in figure 2.

Figure 2—RCA Process Steps

The objective in developing the common RCA process was to ensure that the analyses of risks and controls were consistent across the teams globally.

One of the tools was a simple Excel template defined to capture risk and control information. The template then was frozen for use by all of the entities. The template was defined to capture the following key information:

  • Principal and level II risks
  • Control objectives with reference to the COBIT controls process
  • Reference to Sarbanes-Oxley control requirements
  • Control owner
  • Control assessment—effective, ineffective
  • Actions to make the control effective
  • Action closure details—action owner, target date

The templates were filled by the risk and control owner and were sent to the central risk team for review. They were then entered into the risk management tool to track actions for closure and reporting on open risks. Each was tagged with:

  • Entity owners—Typically the owners of the RCA
  • Risk owners—The owners responsible for the risk
  • Control owners—The owners responsible for maintaining control effectiveness
  • Action owners—The owners of actions defined due to ineffective controls

Benefit of Step 3

Through training programs, the terms ‘entity/RCA owners’, ‘risk owners’, ‘control owners’ and ‘action owners’ were explained using a Responsible, Accountable, Consulted and Informed (RACI) chart (see figure 3 for an example). The responsibilities were also mapped in the job descriptions and in performance evaluation criteria of the staff.

Figure 3—Example RACI Chart

The example in figure 3 clarifies that, although the head of facilities was held accountable for providing physical security on an ongoing basis, the chief operations officer (COO) was accountable for ensuring reporting of incidents and follow-up thereof. For any actions of employees and vendor staff working out of the office, human resources (HR) was consulted and informed.

Step 4—Training Key Stakeholders

One of the main challenges was to explain the entire process to all of the stakeholders with different backgrounds and understanding of risks and controls and at various locations. The challenge was managed by creating additional training programs at various levels. This involved:

  • Creating risk experts (typically with background experience and certifications such as Certified Information Systems Auditor™ [CISA®] and Chartered Accountant [CA]) across the regions and offices who were trained under a train-the-trainer program. Such resources were used to train the stakeholders.
  • Tailoring the training delivered by the risk experts to the audience. For entity owners, a simple process overview was provided through mandatory computer-based training. For risk and control owners, training was detailed and included examples and tests, and it was delivered through classrooms at different locations or through web-based training sessions.
  • Offering, as part of the mandatory training program, an awareness training session that explained the process and provided links and contacts for local risk experts within the organisation for further information and guidance.
  • Arranging a workshop to disseminate the relevant information to stakeholders; this should begin any risk assessment process. The training resources were used to facilitate the control self-assessment (CSA) at different locations.
  • Modifying the role description and performance evaluation process to include specific tasks for risks and controls

Benefit of Step 4

Due to this top-down approach, the importance of risk management was well accepted and it was effective at all levels of the organisation.

Step 5—Using a Reporting Tool

A simple spreadsheet was used for maintaining a risk and control repository for each entity. Within the entity, the risk team member used an Excel spreadsheet for tracking risks, actions, etc. However, there was a requirement to have a single, common database repository for maintaining organisationwide risks and controls. Hence, a tool was developed to gather information for all entities. This helped in:

  • Tracking all risks related to a ‘service’
  • Centralising a repository for all risks and control information
  • Tracking all actions defined and agreed to in the RCA process
  • Tracking closure of actions
  • Reporting to senior executives on risks based on the specific requirements and levels of risk
  • Basing regulatory requirements reporting on a common, single database of risks and controls

Benefit of Step 5

A single repository of all risks, controls and actions was used by assurance teams in their reporting to the chief information officer (CIO) and for tracking compliance at a high level.

Conclusion

The entire development and implementation of the new process took almost two years. While the central team was responsible for developing the process, the location-based risk resources were instrumental in implementation, training, etc. Since the implementers at the different locations were part of the team, their feedback was used in making suitable changes and corrections that helped improve the maturity of the process.

Other tangible benefits of this initiative included:
  • Prior to this implementation, there were more than 500 entities for which risks and controls were tracked. The number was optimised to around 100 entities. This was possible due to the implementation of the key entity management model.
  • Earlier, there were more than 1,000 controls defined. The number was reduced as each control was mapped to the COBIT framework. At the global level, the number of controls was reduced to almost 350. However, within a particular entity, region, country, etc., further drilling down of a control was allowed for tracking locally. For example, globally, in the RCA, a single control was identified for local compliances:  local regulatory compliance control. However, this control was further drilled down to various compliances based on country-specific requirements. In India, for example, this was managed through a separate spreadsheet that covered all of the Indian regulations, such as employee/labor laws and taxation regulations.
  • The exercise helped the bank in managing risk and control process for Sarbanes-Oxley and other regulatory processes. The RCA spreadsheet provided a separate filter for Sarbanes-Oxley compliance applicability.
  • The process repository in the tool helped in maintaining consistency. This was done by creating a separate sub-unit within the risk team to check the quality of each RCA before it was entered in the RCA tool.
  • A common training pack was seen as an important and valuable deliverable by the risk team and was defined based on the audience. For example, a training pack of 15 minutes for all entity owners (typically centre heads in each country or region) was developed and implemented using the e-learning portal, whereas a detailed process training pack was developed for risk and control owners.

Jitendra Barve, CISA, FCA
is a certified accountant with more than 18 years of experience in accounting, finance, audit and consulting. He has spent more than 10 years in information security audits and consulting and has worked on various assignments on risk management, risk-based internal audits, and information security reviews and audits. Barve is a board member of the ISACA Pune Chapter (India). He is associated with a mid-sized CA firm from Pune, G.D. Apte and Co.

Editor’s Note

Readers may wish to note that ISACA’s Risk IT framework expands on the areas covered in this article and supports enterprises in identifying, governing and managing IT-related business risks, complementing the control (risk mitigation) guidance provided in COBIT. Click here for more information on Risk IT.