This article is the first in a 6-part series that looks at the practical application of a governance of enterprise IT (GEIT) framework. The starting point is discussed in this article—forming an awareness that a problem exists and how to approach it. The subsequent articles will move through planning and executing the solution. More specifically, the second part will plan the resolution, identify the roles needed to work on the problem and describe the end products needed to support the solution. The third installment will cover creating a project plan and demonstrating what work and time will be required to implement the proposed solution. The fourth in the series will outline the work, describing the contributions of each unique role player. The fifth part will describe how to examine results and compare them against initial requirements and how to setup performance measurements. The final entry will detail a post-project review and discuss how continuous improvement can be supported through this project.
Define the Problem
This situation begins with senior management receiving a report from the audit committee of the board that states that oversight
of the internal control environment is weak and could lead to material deficiencies in audits performed by the external
auditor. The report goes on to say that the underlying cause of this must be identified and a solution designed and implemented
as quickly as possible. This series of articles takes the position of senior management in this organization and discusses
what actions will be taken and how the situation will be managed from start to finish.
Senior management meets with the internal audit (IA) team to discuss its findings and learns that the team has identified
numerous issues and believes it has uncovered a trend. IA uses root cause analysis in its reports and states that many
of the issues the organization is facing are caused by a lack of proper oversight. Upon greater scrutiny, senior management
learns that many controls in the internal control environment have grown organically, i.e., management identifies deficiencies
and suggests new or altered controls to respond to these observations, but there is no central authority directing alignment
with enterprise goals other than regulatory compliance.
Natural, organic growth of controls is a common, understandable dynamic that often results in stronger overall control
environments. The strength of this approach is that the need for and design of controls come from those who are closest
to the work and best understand it. The problem that can occur is that management-driven controls can address narrow
interests while simultaneously leaving gaps in overall coverage in the enterprise.
The reliance on management-driven controls explains the IA observation of the lack of oversight in the organization. Management has identified and designed controls without involving anyone responsible for looking at the control portfolio from the enterprise perspective. The lack of control portfolio oversight also introduces the risk that regulatory compliance might not be effectively accomplished.
Restate the Problem in Terms of Governance and COBIT 5
After examination of IA’s reports and analyses, senior management needs to look at how it is managing the internal control
environment from a portfolio perspective and validate the audit findings. Validating the audit findings includes asking
and researching several questions.
Does the organization have a corporate-level risk management function? This is fairly obvious when there is a function
as clearly named as this. But the same purpose could be served under other names and that is what needs to be identified.
The organization might have this function under another name such as “enterprise risk management,” “operational risk
management” or “compliance management.”
How are controls created and implemented? There can be some surprising answers to this question. The higher-level answer
is most likely known and well documented. The problem arises when stakeholders learn that business process owners are
creating controls and following them but have abandoned controls documented in process walkthroughs. That disparity between
what is documented and what is in practice can grow over time and lead to compliance issues with the IA function or,
worse, external regulators. There cannot be an informal internal control environment.
Is there alignment between stakeholder requirements and internal controls and risk management? If this issue is not explicitly
managed, then there can be, and often is, a different picture between what is happening and what the board believes is
happening. Senior management must make certain it knows what stakeholders need from it.
All the issues discussed in validating IA’s reports can be described under one umbrella: governance. Governance is the
understanding of stakeholders’ needs and the alignment of resources to meet those needs. Many tools are used, especially
standards, to assist in making certain that IT practices are well formed and will provide the business results needed
and results meet compliance requirements. Most of those tools are meant to provide technical guidance, such as
Information Technology Infrastructure Library’s (ITIL’s) service transition, which describes in great detail how
change management is best performed. These resources tell how to do something, but do not shed light on whether the right
things are being done, or what should be done. That is the purview of a GEIT framework.
This exercise uses
COBIT 5, the most common GEIT framework in use globally. Looking back at the initial audit findings and IA’s claim
of a lack of oversight, the problem can be restated using COBIT 5. In the words of management performing the GEIT implementation,
the underlying issue uncovered by IA is that there is an insufficient understanding of stakeholder needs; a mapping of
those needs to enterprise, IT-related and enabler goals; and 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. Addressing these issues is precisely what COBIT 5 is meant to do.
Plan the Solution
The next installment of this series will look at how to design a GEIT solution to address the lack of oversight (which this
series refers to as governance), who needs to work on it and what the end product will look like.
Care needs to be taken as stakeholders proceed in defining their needs because there is a natural desire to “boil the
ocean” in these scenarios by taking on too much, too soon. That approach can sabotage the project. Moving forward, the
discussion will include scoping and scaling a solution to act as proof of concept and then rolling that out to broader
audiences. Accomplishing these objectives requires involving stakeholders at various stages of roll-out and executing
on a carefully planned, well-timed and highly transparent communications plan.
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.