ITAG RESEARCH INSTITUTE Cobit s management guidelines revisited: the s / s cascade 1 Wim Van Grembergen, University of Antwerp (UA) Steven De Haes University Antwerp Management School (UAMS) IT Alignment and Governance (ITAG) Research Institute Introduction In his concern to respond to management s need for control and measurability of information technology (IT), the Information Technology Governance Institute (ITGI) further built on its COBIT framework by providing in 2000 the Management Guidelines. The Management Guidelines identify for the 34 COBIT IT processes two types of metrics: Key Performance Indicators (s) and Key Goal Indicators (s). In this article the meaning of these metrics will be clarified, a waterfall of s and s will be proposed and their relationship with IT and business goals will be explained. The enhanced metrics and goal concepts as explained in this article will become important knowledge components of the new edition of COBIT, of which the exposure draft will be released this year. 1 Research funded by ISACA/ITGI 1/6
Cobit s management guidelines revisited: the s / s cascade 2/6 The foundation: the balanced scorecard The balanced scorecard (BSC) is a performance management system that enables businesses, business units and functional business areas to drive strategies based on goal definitions, measurement and follow-up. The balanced scorecard can be applied to IT resulting in four specific domains: the business contribution perspective capturing the business value created from IT investments, the user perspective representing the user evaluation of IT, the operational excellence perspective evaluating the IT (COBIT) processes employed to develop and deliver applications, and the future perspective representing the human and technology resources needed by IT to deliver its services over time [Van Grembergen (2000), Van Grembergen and De Haes (2003)]. In order to turn the BSC approach into a management tool, cause-and-effect relationships between metrics need to be established. These relationships are articulated by two key types of measures: performance drivers and outcome measures. A well developed IT BSC contains a good mix of these two types of measures. Outcome measures such as programmers productivity (e.g. number of function points per person per month) without performance drivers such as IT staff education (e.g. number of educational days per person per year) do not communicate how the outcomes are to be achieved. And performance drivers without outcome measures may lead to significant investment without a measurement indicating whether the chosen strategy is effective. Management Guidelines s and s In ITGI s Management Guidelines [ITGI, 2000] a Key Goal Indicator is defined as a measure of what has to be accomplished and by comparison a Key Performance Indicator a measure of how well the process is performing. It is also indicated that their relationship looks for measures of outcome of the goal and for measures of performance relative to the enablers that will make it possible for the goal to be achieved. As explained in the Management Guidelines this is the same as the aforementioned relationship between the outcome measures and performance drivers of the BSC approach. Key Goal Indicators and Key Performance Indicators are exactly the same as Outcome Measures and Performance Drivers. It is important to stress that they are synonyms because in practice there is a lot of confusing about s and s. It has to be clear that also s are metrics representing goals and that always a distinction has to be made between s and s making it possible to express the cause-and-effect relationships. / cascade The Management Guidelines provides a limited list of possible s and s for each of the 34 COBIT IT processes, but not their relationship. In analysing those proposed s specifically, it appears that these goal metrics are in many times defined at different levels: IT process level, IT level and business level. This insight enables us to define a cascade of metrics with causal relationships between process s, process s, IT s and business s as visualised in Figure 1. 2/6
Cobit s management guidelines revisited: the s / s cascade 3/6 Figure 1: causal relationships at process, IT and business level IT / COBIT Process DS5: Ensure System Security Security expertise Process level number of incidents because of unauthorised access Number of security breaches IT level Business level Number of incidents causing public embarrassment The example cascade in Figure 1 is applied to the DS5 COBIT process Ensure System Security. In the top left rectangle the / relationship is illustrated for the security process itself. Security expertise (process ) can be a strategy to decrease the Number of incidents because of unauthorized access (process ). In the middle rectangle a typical for the IT level is displayed, Number of security breaches, with as corresponding IT the previously mentioned process, Number of incidents because of unauthorized access. This suggests that the of the lower IT process level is now the of the higher IT level. In the same logic, the IT becomes a at the business level, driving the business of Number of incidents causing public embarrassment. Important to note is that this example is of course over-simplified. In practice, multiple s will affect the business s as is illustrated in Figure 2. Figure 2: multiple s driving business IT / COBIT Process DS5: Ensure System Security Process level IT level Business level 3/6
Cobit s management guidelines revisited: the s / s cascade 4/6 s for IT process goals, IT goals and business goals Previous section introduced s at three levels: process, IT and business levels. These s are metrics representing specific goals on each of those three levels. For example, the business Number of incidents causing public embarrassment can be one of the metrics referring to a business goal such as Manage business risks. Similar examples of goals can be given for IT s and IT process s. In the reviewed COBIT that will be released in 2005, detailed guidance on those IT and IT process goals and metrics will be provided as shown in Figure 3. More specifically, for each COBIT process, a list will be provided of process goals, with corresponding process goal s. In the Figure below, an example process goal for the COBIT process Ensure Systems Security is Minimise the impact of security vulnerabilities and incidents which can be measured by number and type of expected and actual access violations. By extension, these process goals are linked to the IT goals which they enable, such as Maintain the integrity of information and processing infrastructure, also with corresponding IT goal s such as number of systems where security requirements are not met. Finally, key management practices are listed as enablers for the process goals, such as managing user identities and authorizations in a standardized manner, and supplemented with corresponding process s such as Number of access rights authorized, revoked, reset or changed.. This entire picture offers a complete cascade from key management practices enabling process goals, which in turn enable IT goals, each time with corresponding metrics. Figure 3: Goals and metrics of COBIT process DS5 Ensure Systems Security IT GOALS Ensure critical and confidential information is withheld from those who should not have access to it Ensure automated business transactions and information exchanges can be trusted Maintain the integrity of information and processing infrastructure Account for and protect all IT assets Ensure IT services can resist and recover from failures due to error, deliberate attack, or disaster are measured by IT KEY GOAL INDICATORS Time to grant, change and remove access privileges Nr of systems where security requirements are not met. D r i v e PROCESS GOALS Permit access to critical and sensitive data to only authorised users Identify, monitor and report security vulnerabilities and incidents Detect and resolve unauthorised access to information, applications and infrastructure Minimize the impact of security vulnerabilities and incidents. are measured by PROCESS KEY GOAL INDICATORS Nr and type of suspected and actual access violations Nr of violations in segregation of duties % of users that do not comply with password standards Nr and type of malicious code prevented D r i v e KEY MANAGEMENT PRACTICES Understanding of security requirements, vulnerabilities and threats Managing user identities and authorisations in a standardised manner Defining security incidents Testing security regularly are measured by PROCESS KEY PERFORMANCE INDICATORS Nr and type of security incidents Nr and type of obsolete accounts Nr of unauthorised IP addresses, ports and traffic types denied. % of cryptographic keys compromised and revoked Nr of access rights authorised, revoked, reset or changed 4/6
Cobit s management guidelines revisited: the s / s cascade 5/6 As mentioned before, similar tables have been developed for all COBIT processes. The development of these tables was preceded by detailed research into the existing s and s of COBIT, including defining causal relationships between them, and into business goals and IT goals in eight different industries [(see Van Grembergen et al. (2005)]. The tables themselves were composed by a group of 40 practitioners and academics during a COBIT Development Workshop. These tables provide a very rich foundation to build up a measurement and management system, in the format of scorecards, for IT and its processes. References Van Grembergen, W., De Haes, S. and Moons, J. (2005), Linking business goals to IT goals and Cobit processes, Information Systems Control Journal. Van Grembergen, W. Saull, R. and De Haes, S. (2003), Linking the IT balanced scorecard to the business objectives at a major Canadian financial group, Journal of Information Technology Cases and Applications. Van Grembergen, W. (2000), The balanced scorecard and IT governance, Information Systems Control Journal. ITGI (2000), Management guidelines. Cobit. Governance, control and audit for information and related technology 5/6
Cobit s management guidelines revisited: the s / s cascade 6/6 About UAMS UAMS (University Antwerp Management School) has the ambition to be a learning partner in management, by offering a broad range of training programmes for future and current managers in the business world, in public services and social-profit organizations. The priorities cover optimal quality control, interactive teaching methods, an emphasis on research-based knowledge and best practice, an international orientation and a continuous adaptation of our programmes to the needs of the market. About ITAG The Information Technology Alignment and Governance (ITAG) Research Institute, was established in within UAMS to host applied research in the domains of IT Governance and business/it alignment. The research centre is an initiative of Prof. dr. Wim Van Grembergen and dr. Steven De Haes. Both have research and practical experience in the IT Governance and Strategic Alignment domains. Recently, this team was reinforced by senior researcher Hilde Van Brempt. Contact UAMS - ITAG Research Institute Sint-Jacobsmarkt 9-13 B-2000 Antwerpen Belgium Wim Van Grembergen, Ph.D. is a professor at the Information Systems Management Department of the University of Antwerp and an executive professor at the University of Antwerp Management School. He is academic director of the Information Technology and Alignment (ITAG) Research Institute and has conducted research in the areas of IT governance, value management and performance management. Over the past years, he has been involved in research and development activities of several COBIT products. He can be contacted at Wim.VanGrembergen@ua.ac.be. Steven De Haes, Ph.D. is responsible for the information systems management executive programs and research at the University of Antwerp Management School. He is managing director of the Information Technology and Alignment (ITAG) Research Institute and recently finalised a Ph.D. on IT governance and business/it alignment. He has been involved in research and development activities of several COBIT products. He can be contacted at Steven.DeHaes@ua.ac.be. 6/6