GEIT Framework at Work, Part 2: Plan the Solution

This article is the second in a 6-part series that looks at the practical application of a governance of enterprise IT (GEIT) framework. This article focuses on planning the resolution of the issue identified in part 1. In part 1, the issue identified was a reliance on controls identified and designed by management without involving anyone responsible for looking at the control portfolio from the enterprise perspective. This lack of control portfolio oversight introduced the risk that the enterprise may not be in regulatory compliance. This article explains how to design a GEIT solution to address the lack of oversight, which shall be referred to as governance; who needs to work on it; and what their work products, or outputs, will look like.

In the words of the people performing the governance implementation, the underlying issue uncovered by the internal audit (IA) team is that there is a lack of proper oversight. This suggests there is an insufficient understanding of stakeholder needs; no mapping of those needs to enterprise, IT-related and enabler goals; and a lack of data or metrics that prove the internal control environment is, in fact, designed and operating in such a manner as to provide assurance that compliance with enterprise requirements will occur.

What is needed now is a formal design and structure around governance such that stakeholder requirements align with enterprise and IT goals. When properly aligned, stakeholders can be assured that they are covering all identified requirements (external and internal) and that any resource shortfalls can be identified. Creating this formal structure will provide a comprehensive view of the internal control environment that is currently lacking. Recall that in COBIT, stakeholders refers primarily to those internally, such as the board of directors and executive leadership team.

Resources are finite, and there are always competing projects or priorities. That means stakeholders need to define how resources are allocated to goals. The guardrails for designing a governance structure and assigning resources anticipate that it must create and deliver value to stakeholders while assuring compliance with all requirements.

Design a GEIT Structure

COBIT 5 is used as the framework for the governance structure design. COBIT 5 shows how to lay out a governance structure and define the roles that are needed to support it. That design process starts with gaining an understanding of the stakeholder requirements. COBIT 5 has a sample of common stakeholder requirements, which are shown in figure 1.

Figure 1—Mapping COBIT 5 Enterprise Goals to Governance and Management Questions

Source: ISACA, COBIT 5, USA 2012. Reprinted with permission.

The first task is to determine which requirements pertain to the enterprise and which to prioritize. To simplify this process, the focus is placed on one particular need. This one particular issue will be traced through the governance structure design.

In understanding an audit finding and creating tasks within a governance implementation effort, it is helpful to use figure 1, Mapping COBIT 5 Enterprise Goals to Governance and Management Questions, from the COBIT 5 framework. A lack of transparency in IT-enabled investments can lead to the observation that there is a lack of oversight. The goals-to-questions table assists in determining which enterprise goals to pursue. Looking at figure 1, there is a stakeholder need that seems to fit: “Are the total IT effort and investments transparent?” In the table, this need is mapped to enterprise goal 5, “Financial transparency.”

The enterprise goal will be mapped to an IT-related goal, and then the appropriate resources will be defined to support the accomplishment of that goal. Enterprise goals are mapped to IT-related goals in figure 2, which can be found in the COBIT 5 framework. In this figure, financial transparency is mapped to IT-related goal 06, “Transparency of IT costs, benefits and risk.”

Figure 2—Mapping COBIT 5 Enterprise Goals to IT-Related Goals

Source: ISACA, COBIT 5, USA 2012. Reprinted with permission.

The final mapping that needs to be done is to determine which resources will support the IT-related goal. Figure 3 provides a mapping from IT-related goals to processes, which are the main determinant of resources in the GEIT structure.

Figure 3—Mapping COBIT 5 IT-Related Goals to Processes

Source: ISACA, COBIT 5, USA 2012. Reprinted with permission.

In figure 3, IT-related goal 06 is supported primarily by 8 different processes in the process reference model. The place to start is with process APO13 Manage Security as that is where the organization in this case study has made significant investment in the past year. APO13 is primarily focused on the information security management system (ISMS).

Define the Roles

The detail of process APO13 is found in COBIT 5: Enabling Processes . Processes are broken down into practices. This is the level where work is actually performed in most cases. Each practice tells what resources are needed (inputs), what to do (description and activities), and what will be produced (outputs).

The first concern is to understand what roles will participate in the practices of this process in the enterprise. Each process has an associated responsible, accountable, consulted and informed (RACI) chart that tells who is responsible, accountable, consulted and informed by practice. The primary focus in determining roles will be on accountability and responsibility.

The RACI chart for the APO013 process shows that the chief information security officer (CISO) is the accountable party in every practice. Note that only 1 role can be assigned accountability. This ensures consistent direction and development of performance metrics, which will be very important later. There are 2 roles that share responsibility in each of the 3 practices in APO13, the chief information officer (CIO) and the information security manager (IS manager).

What the End Products Look Like

Define the planned work products each role will produce.

Process APO13 Manage security has 3 related practices. These are:

• APO13.01 Establish and maintain an ISMS
• APO13.02 Define and manage an information security risk treatment plan
• APO13.03 Monitor and review the ISMS

Work products need to be defined for each practice to understand overall resource requirements. COBIT 5: Enabling Processes gives common outputs created by these practices ( figure 4).

Figure 4—Management Practices and Related Outputs

Source: ISACA, COBIT 5: Enabling Processes , USA, 2012. Reprinted with permission.

Each work product should be further described to facilitate identification and creation of the work products ( figure 5). The description of the work products created in the process reference model can be referenced from appendix B.2 Level 1 Output Work Products, figure 19 in COBIT Process Assessment Model (PAM): Using COBIT 5 . The APO13 work products are reproduced in figure 5.

Figure 5—Output Work Products

Source: ISACA, COBIT Process Assessment Model (PAM): Using COBIT 5 , USA, 2013. Reprinted with permission.

Project Planning—Next Time

The next article in this series will discuss creating a project plan with templates, as appropriate, and demonstrate what work and time will be needed to solve the issue.

Peter C. Tessin, CISA, CRISC, CISM, CGEIT

Is a senior manager at Discover Financial Services. He leads the governance group within business technology (BT) risk. In this role, he is responsible for ensuring that policy, standards and procedures align with corporate objectives. He serves as the internal party responsible for regulatory exam management and is the internal liaison to corporate risk management. Prior to this role, Tessin was a technical research manager at ISACA® where he was the project manager for COBIT 5 and led the development of other COBIT 5-related publications, white papers and articles. Tessin also played a central role in the design of COBIT Online, ISACA’s website that offers convenient access to the COBIT 5 product family and includes interactive digital tools to assist in the use of COBIT. Prior to joining ISACA, Tessin was a senior manager at an internal audit firm, where he led client engagements and was responsible for IT and financial audit teams. Previously, he worked in various industry roles including staff accountant, application developer, accounting systems consultant and trainer, business analyst, project manager, and auditor. He has worked in many countries outside of his native United States, including Australia, Canada, France, Germany, Italy, Jordan, Mexico and the United Kingdom.