This article presents an effective methodological approach to implement and sustain the COBIT PO9 Assess and manage IT risks process. This process belongs to the Plan and Organize domain of the COBIT framework and is key for any organization concerned with managing and controlling its risks. It is a core process for any internal control framework that must comply with laws and regulations such as the US Sarbanes-Oxley Act or Basel II. Although this strategy was applied to this process only, in a large international financial group (€100 billion), this approach may be applicable to other processes of the COBIT framework, with significant advantages in terms of rightsizing the implementation project.
Giving Sustainability to PO9
Obtaining a high level of maturity for the PO9 process is apparently a trivial task. The experience in this case1 shows that a management system can be put in place in three to four months. But, because PO9 requires a context to be fully operational, a methodology is required to identify a manageable set of assets and activities in which risk management can be applied, producing visible results in a reasonable time frame and with a justifiable amount of resources.
The approach described in this article is based on COBIT 4.1 and is independent from the context in which risk management occurs.
Description of the Context
Operational risk management has become mandatory for many institutions because there are external drivers such as Basel II and other international and country-specific regulatory requirements. Valorization of risk, as a decision tool for the choice of controls that protect the organization’s assets, is sufficient justification for operational risk to encompass IT practices and IT operations. IT organizations now believe that addressing risk is no longer a matter of choice; it is a requirement from both a financial and compliance point of view.
This is not the only motivation. Project management standards and best practices have risk management requirements in common. Another strong motivation is the need to keep the costs of controls at a reasonable level. Risk assessment and evaluation provide the necessary inputs to reduce the risks to acceptable levels while investing the “right” amount of money. Stakeholders also fear for their investments and require reasonable assurance that risks are managed in a proficient manner by management.
The case described in this article occurred in a company that is the only supplier of IT services to a large international financial institution. The boards of both companies were fully aligned with the need to have a systematic approach to risk management, and the initiative took place with their full sponsorship.
The objective of the project was to implement the recommendations of ISO 31000, Risk management, ensuring at the end a maturity level of at least three for PO9. The set of deliverables included a risk management policy; risk management processes; a description of functions; a context manual; a list of threats, vulnerabilities and risks; a baseline of key performance indicators (KPIs) and key risk indicators (KRIs); a risk assessment tool; and training materials. These deliverables are just the foundation for what an organization needs to do. Additional actions are required to achieve a continual and sustainable attitude toward risk.
The Challenge
Basel II and other local regulations issued by the Bank of Portugal are now in effect, and as a result, it is in the best interest of financial institutions to implement a sound operational risk management system in the shortest period of time without compromising compliance with the various requirements. The obvious place to start was to define the policies and processes required by the organization. This approach, although sound, is a lengthy one and has a prerequisite: a careful choice of processes. Another very lengthy path, while absolutely and formally correct, is to make an inventory of the organization’s assets and perform a thorough risk assessment cycle.
The challenge in this project was to choose a strategy that could provide quick wins, that was supported by a good rationale and fully coherent with the recently adopted risk management methodology, and that was sound enough to be accepted by internal audit and the regulator.
The Methodology
The internal control system of the IT organization was being built using COBIT as the main source of good control practices. Consequently, the design of the rationale and the strategy had to be supported by COBIT also.
COBIT 4.1’s framework, control objectives, management guidelines and maturity models indicate, for each process, the required input and output processes. It can be established that every process needs to be implemented in an enabling and supporting environment, with the objective to increase process maturity levels and, thus, control effectiveness. To achieve its goals, a process needs activities and information provided by external sources. Each goal can be better achieved when each activity is executed properly and when data are available and reliable.
As such, there was a need to ensure that the PO9 process was receiving the required inputs from other processes, even if those processes were not yet in place or, because of reduced maturity or lack of implementation scope, they were not delivering the expected outputs.
PO9 Assess and manage IT risks is framed by processes as shown in figure 1.
Figure 2 shows the minimum requirements to set up the PO9 process. COBIT’s management guidelines provide a fairly comprehensive description of the required inputs. Following these guidelines throughout the design phase of the risk management processes provided a foundation for a reliable and comprehensive strategy to ensure a consistent, “clean and lean” approach to PO9’s design, implementation and sustainability and, thus, to ensure a management-optimized methodological approach.
Having identified the processes, the second step was to look again at COBIT and clearly identify which inputs PO9 was expecting from the processes included in the relationship diagram. Each of the mentioned processes produced a specific output that had to be fed into the PO9 stream of operational processes (those that the organization recognizes and executes on a daily basis). Many other assets had to be run through risk management. The management guidelines (figure 2) contain the minimum requirements for any organization. In fact, the main goal of implementing PO9 is to ensure that the organization’s assets have an adequate level of protection against threats that explore the existing vulnerabilities.
Analyzing the list of inputs, it became obvious that COBIT suggests that an organization should look first to the following assets:
- The services provided by the IT organization to the business
- The components of the infrastructure that support the services
- The projects
- The suppliers’ services
- The continuity plans
Then, the organization should build the list of threats and vulnerabilities that are applicable to its assets.
Risk analysis is more efficient when supported by historical data. This is referred to as historical risk trends and events. In the absence of historical data, a qualitative approach should be developed based on personal experience, technical expertise and the data provided by manufacturers and suppliers.
Having identified the inputs for PO9, the next challenge was to identify where and how they were produced. Fully documented operational processes and management are normally the first sources of information. When this is not the case, the task is more efficient when supported by a typical map of functions that are normally responsible for producing such inputs.
Again, COBIT is a reliable source of planning information. The Responsible, Accountable, Consulted and Informed (RACI) charts indicate who in the organization is responsible for the production of each input. The results of using the RACI tables for PO1, PO10, DS2, DS4, DS5, ME1 and ME4; selecting the proper activities; and then choosing just the responsible functions are shown in figure 3.
Using the information in figure 2, gathered using the management guidelines, a solid reference was built and can be used to understand where the relevant functions are located in the organization chart and whether their responsibilities involve the production of the required inputs.
Collecting the Evidence
The next objective was to understand how many inputs exist, how effective and how mature the production process is, if there are any threats associated with the process, which controls are in place to ensure that risks are being managed, and also which process controls exist.
The evidence that is collected has to be recorded exactly as when a self-assessment is being performed. It is not relevant at this point to analyze the content of the inputs in great detail. That is the job of the PO9 process.
Processing the Results
A self-assessment or an independent audit reveals if the inputs exist and, if they exist, what their maturity level is. It is at this point that usage of PO9 becomes operationally relevant.
PO9 control objectives are clear. The organization needs a framework, a clear context, and processes designed and in operation regarding the event identification, the assessment of risk and the response to risk.
The first question to ask: Is there any way in which the inputs are related to the organization’s risk assessment context? In short, the risk assessment context is a document that describes, among other things, the assets that are relevant to the organization, the risk assessment criteria and the threat baseline.
The information collected, or the lack of it, should drive a KRI evaluation. COBIT control practices provide information to create a list of KRIs. They can be derived from the risk drivers and complemented by the risk appetite defined by management. The values obtained provide direction to the amount of remediation required to lower the level of risk to which the organization is exposed.
The Risk IT Framework
The previously mentioned risk management project took place during 2008. The Risk IT framework had not been published yet. All the project work was based on a working draft of ISO 31000 and, of course, the PO9 control objectives and control practices.
Published in 2009, Risk IT has a comprehensive process model2 that could be useful to achieve the objectives described in this article.
Process goals RG1, RG2 and RG3, all three linked to Risk Governance (RG), supply the necessary guidance to define the context in which risk management occurs in a particular institution.
Define IT risk analysis scope, a key activity of process goal RE3, helps to identify the relevant assets for analysis. RE3 brings attention to collecting historical data that are later needed for the estimation of IT risk (RE2.2).
Conclusions
COBIT can be used beyond control objectives. This simple example shows one of the benefits that COBIT’s management guidelines can bring when a decision has to be made about the scope of applicability of a particular process—in this case, PO9.
This example could become more complex just by adding additional input processes to the set of processes that have been mentioned. The increase in complexity is due to the amount of information that has to be treated, but not to the methodology itself. ISACA provides a good source for financial institutions to identify the additional projects: IT Control Objectives for Basel II. This book provides a sound rationale for the list of COBIT processes in scope.
While COBIT sets good practices for the means of risk management by providing a set of controls to mitigate IT risk, Risk IT sets good practices for the ends by providing a framework for enterprises to identify, govern and manage IT risk.
Endnotes
1 This is based on the authors’ recent experiences with COBIT and PO9 in particular.
2 ISACA, The Risk IT Framework, USA, 2009, https://www.isaca.org/resources/it-risk
Vítor Prisca, CISM, CGEIT
is an executive director at Novabase and the principal of the IT management practice. He assisted in the expert review of COBIT 4.0 and is a certified consultant for International Organization for Standardization (ISO) 20000 and 27001. Prisca also delivers training in IT best practices, compliance (US Sarbanes-Oxley Act and Basel II), business continuity and information security management.
Manuel Moreira, CISA, IPMA Level C: Certified Project Manager
is a manager at Novabase. He has vast experience with customer projects in the areas of compliance, internal control, process design and implementation, security, and audit.