COBIT FAQs 

 

Frequently Asked Questions

  1. What is the purpose of COBIT?
  2. Who is using COBIT?
  3. Who are the process owners?
  4. Why was the orientation of COBIT focused on the process rather than functions or applications?
  5. How robust are the business requirements?
  6. What is the overall quality of COBIT, and were any process owners/executives part of the expert review?
  7. What is the future direction of COBIT?
  8. How did ISACA/ITGI decide on the list of primary references?
  9. Can I use COBIT as a statement of criteria for specific audit conclusions?
  10. Are the control objectives meant to be a minimum level of control or best practice?
  11. What about the absence of platform-specific controls?
  12. Where are the application controls?
  13. Why is there overlap within the control objectives?
  14. Are the control objectives linked to the IT Assurance Guide and to what degree?
  15. Why are there no risk statements with the control objectives?
  16. What training is available for the use of COBIT?
  17. Who in my organization should go to the training?
  18. What is the level of training required?
  19. In what way can I suggest to IT management that it use COBIT?
  20. Is the COBIT framework superior to the other accepted control models?
  21. What is the quickest and best way to sell COBIT to IT managers?
  22. Since COBIT currently does not address associated business risks, but rather the more proactive control statements to be achieved, is there any consideration being given to address the perceived need of risk identification?
  23. Has the COBIT framework been accepted by CIOs?
  24. How are the management guidelines integrated into the COBIT framework?
  25. The COBIT framework states that the COBIT maturity models are derived from the SEI Capability Maturity Model (CMM). What is the actual relationship between COBIT and CMM?
  26. Do I need to meet an exact level when assessing a process using COBIT's maturity models, and does this differ from the original CMM approach?
  27. COBIT has three dimensions of maturity. What do they mean?
  28. How do you perform a COBIT-based maturity assessment?
  29. How prescriptive are the COBIT maturity models and supporting guidance, and how does this compare to the CMM/CMMI approach?
  30. The CMMI maturity levels appear to be different to the COBIT maturity levels. Is this true?
  31. Is it really possible to benchmark my maturity levels with other organizations if the maturity assessments are not very precisely measured?
  32. Are COBIT's maturity models useful to organizations that have already adopted CMMI?
  33. Since the four COBIT resource types (applications, information, infrastructure and people) apply to each of the COBIT processes, why are some indicated and others not in the Process Descriptions?

 

1. What is the purpose of COBIT?

The purpose of COBIT is to provide management and business process owners with an information technology (IT) governance model that helps in delivering value from IT and understanding and managing the risks associated with IT. COBIT helps bridge the gaps amongst business requirements, control needs and technical issues. It is a control model to meet the needs of IT governance and ensure the integrity of information and information systems.

2. Who is using COBIT?

COBIT is used globally by those who have the primary responsibilities for business processes and technology, those who depend on technology for relevant and reliable information, and those providing quality, reliability and control of information technology.

3. Who are the process owners?

COBIT is IT process-oriented and, therefore, addresses itself in the first place to the owners of these processes. Referring to Porter's Generic Business Model, core processes (e.g., procurement, operations, marketing, sales) are discussed, as well as support processes (e.g., human resources, administration, information technology). As a consequence, COBIT is not only to be applied by the IT department, but by the business as a whole.

This approach stems from the fact that in today's enterprises, the process owners are responsible for the performance of their processes, of which IT has become an integral part. In other words, they are empowered but also accountable. As a consequence, business process owners bear the final responsibility for the information technology as deployed within the confines of their business process. Of course, they will make use of services provided by specialized parties such as the traditional IT department or the third-party service provider.

COBIT provides business process owners with a framework, which should enable them to control all the different activities underlying IT deployment. As a result, on this basis they can gain reasonable assurance that IT will contribute to the achievement of their business objectives. Moreover, COBIT provides business process owners with a generic communication framework to facilitate understanding and clarity amongst the different parties involved in the delivery of IT services.

Furthermore, the management guidelines provide management with a set of tools that allow self-assessment to help make choices for control implementation and improvements over IT, and measure the achievement of goals and the proper performance of IT processes. The management guidelines include maturity models; key goals and metrics; and responsible, accountable, consulted and/or informed (RACI) charts to clarify roles and responsibilities to support managerial decision making.

4. Why was the orientation of COBIT focused on the process rather than functions or applications?

The COBIT framework has been structured into 34 IT processes clustering interrelated life cycle activities or interrelated discrete tasks. The process model was preferred for several reasons. First, a process by its nature is results-oriented in the way that it focuses on the final outcome while optimizing the use of resources. The way these resources are physically structured, e.g., people/skills in departments, is less relevant in this perspective. Second, a process, especially its objectives, is more permanent in nature and does not risk change as often as an organizational entity. Third, the deployment of IT cannot be confined to a particular department and involves users and management as well as IT specialists. In this context, the IT process remains, nevertheless, the common denominator.

As far as applications are concerned, they are treated within the COBIT framework as one of the four resource categories. Hence they are to be managed and controlled in such a way as to bring about the required information at the business process level. This way, application systems are an integral part of the COBIT framework and can be addressed specifically through the resource vantage point. In other words, focusing strictly on the resources only, one would automatically get an application view of the COBIT objectives.

5. How robust are the business requirements?

During the review process of COBIT, senior managers and CIOs liked the definition of the business requirements for information, and supported the choices about which requirements were most important in what process. Choices were difficult and entailed considerable debate among the experts during the project. The guiding principle has always been: What really is fundamental for this control objective in this process? Which resource needs special control? Which information requirement needs special attention?

With the development of COBIT 4.1, the understanding of business requirements has been strengthened by the addition of generic business goals and a business-goal-to-IT-goal-to-IT-process cascade. These generic goals, based on extensive industry research, help COBIT users align their business requirements with specific critical processes.

6. What is the overall quality of COBIT, and were any process owners/executives part of the expert review?

To assure the high level of quality of COBIT, several measures have been taken. The most important are:

  • The whole research process has been overseen by the IT Governance Committee (ITGC), which is responsible for all ITGI research, and directed by the COBIT Steering Committee (CSC). Besides preconceiving the deliverables, the CSC has also been responsible for the final quality of these deliverables.
  • A CIO panel provides insights and suggestions for further developments.
  • The detailed research results have been quality-controlled throughout.
  • The preliminary research involved several COBIT development groups based around the world.
  • Before being issued, the final texts were distributed to more than 100 specialists, including process owners, business managers and analysts, such as Gartner, to obtain their comments.
  • Overall, experience shows that the COBIT model appeals to members of business management as a whole; they appreciate the added value of it in view of improving their control over IT. In this regard, ITGI is confident that the required quality level, beyond customer satisfaction, has been achieved, although feedback is always welcomed and considered. Because COBIT development is a continuous improvement process based on real experience by users, there will always be potential improvements to quality and usefulness.

7. What is the future direction of COBIT?

As with any comprehensive and groundbreaking research, COBIT will be updated to a new version approximately every three years, with minor enhancements in between. This will ensure that the model and the framework remain comprehensive and valid. The validation will also entail ensuring that the primary reference materials have not changed, or, if they have, those changes are reflected in the document. The next version will be COBIT 5 and a design document is posted on the COBIT home page www.isaca.org/cobit under the heading COBIT Update Project.

8. How did ISACA/ITGI decide on the list of primary references?

The list of primary references was developed as a collective consensus based on the experience of the professionals who participated in the CSC's research, expert review and quality assurance efforts.

9. Can I use COBIT as a statement of criteria for specific audit conclusions?

Yes, basing the IT Assurance Guide firmly on the control objectives takes the auditor's opinion out of the audit conclusion, replacing it with authoritative criteria. COBIT is based on more than 40 standards and best practices documents for information technology from standards-setting bodies (public and private) worldwide. These include documents from Europe, Canada, Australia, Japan and the United States. Because COBIT contains all pertinent worldwide standards identifiable at the time of publication, it is all-inclusive with respect to IT controls standards. As a result, COBIT can be used as an authoritative source reference document, providing IT controls criteria on audits.

10. Are the control objectives meant to be a minimum level of control or best practice?

IT control objectives are statements of managerial actions to achieve necessary outcomes or purposes to control risk and add value within a particular IT process. They are written as short, action-oriented management practices and expressed wherever possible in a life cycle sequence. Control objectives are complemented by COBIT Control Practices, Guidance to Achieve Control Objectives for Successful IT Governance, 2nd Edition, which describe a set of management actions designed to attain the outcomes described in the control objective.

Management makes choices relative to control objectives:

  • Selecting those that are applicable in the enterprise's setting
  • Determining the cost-benefit ratio of adopting the control objective, including acceptance of the risk of not implementing a control objective
  • Deciding on the actual control practices and implementing them or choosing alternative management actions to achieve the similar outcomes
  • Choosing how to implement (frequency, span, resourcing, automation, etc.)

11. What about the absence of platform-specific controls?

The COBIT control objectives are generic in nature and address activities or tasks within IT processes. This way they are platform-independent. However, they are the overall structure wherein more specific platform-related controls are to be defined. In fact, the general control objectives should remain valid regardless of whether one is controlling, for example, a mainframe platform or an office automation platform. It is obvious that certain aspects will require more emphasis in a given environment.

12. Where are the application controls?

The application controls were originally fully integrated in the COBIT model. This option had been taken considering that COBIT is business-process-oriented and that at this level application controls are merely part of the overall controls to be exercised over information systems and related technology. In most cases, however, this part cannot be outsourced. Hence, the question is of prime importance.

Before the publication of COBIT 4.0, there was one process, Manage data, where the traditional transactions and file controls could be found. In COBIT 4.0 the application controls were taken out of DS10 and made part of the COBIT framework using the ACn prefix, because it was decided that they had become accepted as being owned by business process owners and not part of an IT process. With COBIT 4.1, they have been simplified to six key application control objectives, AC1 to 6.

13. Why is there overlap within the control objectives?

Overlap in the control objectives, although not occurring often, was intentional. Some control objectives transcend domains and processes and, therefore, must be repeated to ensure that they exist in each domain or process. Some control objectives are meant to be cross-checks of one another and, therefore, must be repeated to ensure consistent application in more than one domain or process. Thus, although potentially perceived as overlapping, COBIT intentionally repeats some control objectives to ensure appropriate coverage of these IT controls.

14. Are the control objectives linked to the IT Assurance Guide and to what degree?

Objectives have been developed from a process orientation because management is looking for proactive advice on how to address the issue of keeping IT under control. Balancing cost and risk is the next issue to address (i.e., making a conscious choice of how and whether to implement each control objective). The link is the process. The control objectives help management establish control over the process. The IT Assurance Guide testing steps assist the auditor or assessor by providing assurance that the process is actually under control, such that the information requirements necessary to achieve business objectives will be satisfied. In reference to the control framework represented by the waterfall model, the testing steps can be seen as providing the feedback from the control processes back to the business objectives. The control objectives are the guide going down the waterfall to get the IT process under control. The IT Assurance Guide testing steps are the guide for going back up the waterfall with the question: ‘Is there assurance that the business objective will be achieved?'; The 2007 IT Assurance Guide provides specific tests at the process and control objective level, whereas the previous Audit Guidelines provided tests at only the process level.

15. Why are there no risk statements with the control objectives?

The provision of risk statements was seriously considered and investigated during the research and review phase of the initial COBIT project, but not retained because management preferred the proactive approach (objects are to be achieved) over the reactive approach (risks are to be mitigated). The risk approach comes in at the end of the IT Assurance Guide when the risk of not implementing the controls is substantiated. In the application of COBIT, the risk approach is certainly useful when management decides which controls to implement or when auditors decide which control objectives to review. Both of these decisions depend entirely on the risk environment. In the management guidelines the goals and metrics can be used as risk indicators by considering their absence or lack of positive outcomes. Also, the control practices provide risk and value statements at the control objective level, indicating the risks of not implementing a control objective and the value of improving the control.

16. What training is available for the use of COBIT?

ISACA has developed and is continually enhancing it education and training portfolio supporting COBIT.

Online offerings at www.isaca.org/elearning:

  • COBIT Foundation Course™ (to be launched mid April 2010)
  • COBIT Foundation Examination™

Classroom offerings:

  • COBIT Foundation Course™ with associated COBIT Foundation Examination™ at www.isaca.org/cobittraining
  • Implementing IT Governance using COBIT™ and Val IT (previously titled “COBIT Implementation Course”) at www.isaca.org/cobittraining
  • COBIT training is also available through the ISACA On-site Training program at www.isaca.org/onsitetraining
  • ISACA’s Training Week program includes the COBIT Strategies for Implementing IT Governance course. For more information go to www.isaca.org/trainingweek

17. Who in my organization should go to the training?

COBIT training should be attended by management, IS and audit managers, IT professionals, business process managers, and quality assurance and audit professionals.

18. What is the level of training required?

The amount and level of training necessary is a function of how comfortable one feels with the product; however, practical experience has shown that successful implementation is directly related to the amount of COBIT knowledge acquired. Therefore, training is considered to be very important but the training also has to be properly and correctly provided, which is why ISACA developed a portfolio of courses. The IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition, and the IT Assurance Guide provide valuable support following attendance at training courses.

19. In what way can I suggest to IT management that it use COBIT?

Because COBIT is business-oriented, using it to understand IT control objectives to deliver IT value and manage IT-related business risks is straightforward:

  • Start with business objectives in the framework.
  • Select the IT processes and control objectives appropriate to the enterprise from the control objectives.
  • Operate from the business plan.
  • Assess the status of the organization, identify critical activities leading to success and measure performance in reaching enterprise goals with the management guidelines.
  • Assess procedures and results with the IT Assurance Guide.

20. Is the COBIT framework superior to the other accepted control models?

Most senior managers are aware of the importance of the general control frameworks with respect to their fiduciary responsibility, such as COSO, Cadbury, CoCo or King II; however, they may not necessarily be aware of the details of each. In addition, management is increasingly aware of the more technical security guidance such as ISO 17799, and service delivery guidance such as ITIL. Although the aforementioned models emphasize business control and IT security and service issues, only COBIT attempts to deal with IT-specific control issues from a business perspective. It should be noted that COSO was used as source material for the business model and ISO 17799 and ITIL, amongst many others, were used to develop the control objectives. COBIT is not meant to replace any of these control models. It is intended to emphasize what control is required in the IT environment while working with and building on the strengths of these other control models.

21. What is the quickest and best way to sell COBIT to IT managers?

As we all know, there is no cavalry to come to the rescue. As the rest of the implementation tools point out, the organizational culture is vitally important. A proactive culture will be more receptive than one that is not. However, consider emphasizing the business aspects and the fact that COBIT does not get lost in technical terminology. Furthermore, point out that COBIT was designed the way an IT manager thinks, and one of its greatest benefits is that everything is documented in one place.

With the addition of the management guidelines, COBIT provides management with new capabilities to support self-assessment of organizational status, comparison with industry good practices, alignment with enterprise objectives, implementation decision making and performance monitoring. The maturity models, key goal indicators and key performance indicators provided in these guidelines can assist management in better aligning IT with the overall enterprise strategy by ensuring that IT is an enabler of the enterprise goals.

22. Since COBIT currently does not address associated business risks, but rather the more proactive control statements to be achieved, is there any consideration being given to address the perceived need of risk identification?

Risk is addressed in a pervasive manner throughout COBIT and even more so with the advent of the management guidelines. A major driver of the control and assurance processes is the IT governance model that is now covered extensively in COBIT and the management guidelines framework.

IT governance refers to the generic enterprise objectives of measuring benefits and managing risk. The same idea, risk management as an enterprise objective, was nevertheless already captured by COBIT earlier, because COBIT states that IT needs to provide information to the enterprise that must have the required characteristics to enable the achievement of enterprise objectives. While the security-related criteria of availability, integrity and confidentiality may be more readily associated with risk, not achieving enterprise objectives or not providing the required criteria is a risk that the enterprise needs to control.

Specific examples have been provided in the 'substantiating'; section of the IT Assurance Guide. The objective of that section is to document for management what can or has happened as a result of not having effective control in place. More practically, one entire process was defined to cover the assessment of risk. (See PO9 Assess and manage IT risks.)

Risk is addressed in the framework in a proactive manner, i.e., by focusing on objectives, because the primary risk that needs to be managed is that of not achieving the objectives. The section on documenting the impact of control weaknesses of the IT Assurance Guide provides examples of these risks for each process. This provides for the risk information for which the control and assurance professional is looking. A whole IT process is dedicated to the assessment of risk in the overall set of IT objectives.

23. Has the COBIT framework been accepted by CIOs?

Yes, it has been accepted in many organizations globally, and new cases continue to be documented. However, it should not surprise anyone that in those entities where the CIO has embraced COBIT as a usable IT framework, this has come as a direct consequence of one or more COBIT champions within the audit and/or IT department(s). Even more important than acceptance by the CIO is acceptance by the board and executive management. Successful implementation of IT governance using COBIT depends greatly on the commitment of top management.

The addition of the management guidelines should also increase the acceptance of COBIT by enterprise and IT management. The emphasis on alignment of IT with enterprise goals, self-assessment and performance measurement will ensure that COBIT is seen not only as a control framework, but also as providing a set of tools for improving the effectiveness of information and IT resources. The integration of the management guidelines with the COBIT framework and control objectives provide additional emphasis for management to use COBIT as the authoritative, up-to-date and established model for IT control and governance.

24. How are the management guidelines integrated into the COBIT framework?

Starting with the COBIT framework, the application of international standards and guidelines and research into good practices led to the development of the control objectives. Management needed a similar application of the framework to allow self-assessment and choices to be made for control implementation and improvements over its information and related technology.

The management guidelines provide the tools to accomplish this. They were developed for each of the 34 IT processes, with a management and performance measurement perspective. Maturity models, goals and metrics, and roles and responsibilities (RACI) charts are provided by the guidelines to support management decision-making processes.

With COBIT 4.0 the management guidelines were integrated and positioned together with the control objectives in one complete publication, to give users a single complete source.

25. The COBIT framework states that the COBIT maturity models are derived from the SEI Capability Maturity Model (CMM). What is the actual relationship between COBIT and CMM?

The maturity models (MMs) in COBIT were first created in 2000 and at that time were designed based on the original CMM scale with the addition of an extra level (0) as shown below:

  • Level 0: Non-existent
  • Level 1: Initial/ad hoc
  • Level 2: Repeatable but Intuitive
  • Level 3: Defined Process
  • Level 4: Managed and Measurable
  • Level 5: Optimized

The use of this scale is the only relationship to CMM, as it was felt that the CMM approach, designed for rigorous software development environments, was not appropriate for COBIT where the approach is at a strategic level and focused on high-level IT management processes.

The purpose of the COBIT MMs is to provide a management tool enabling benchmarking and targeting of desired process maturity levels and to encourage process improvement via gap analysis. Although concepts of the CMM approach were followed, the COBIT implementation differs considerably from the original CMM, which was oriented toward software product engineering principles, organizations striving for excellence in these areas and formal appraisal of maturity levels so that software developers could be ‘certified';.

A generic definition was created for the COBIT MM scale, which is similar to CMM but interpreted for the nature of COBIT's processes. A specific model was then developed from this generic scale for each of COBIT's 34 processes. A maturity attribute generic scale was also developed, using six attributes. This scale was not based on any CMM concepts but was created by the COBIT expert development team.

Since 2000, the COBIT MMs and maturity attributes have been refined and adjusted based on experience and feedback. The SEI discontinued the original CMM and replaced it with a new model called CMMI. CMMI has not been used in the development of the COBIT MMs.

26. Do I need to meet an exact level when assessing a process using COBIT's maturity models, and does this differ from the original CMM approach?

The main purpose of the COBIT maturity models is to give management a tool to help them better understand the current capability of IT management processes, do benchmarking, gap analysis and improvement planning.

With COBIT's maturity models, unlike the original SEI CMM approach, there is no intention to measure levels precisely or try to certify that a level has exactly been met. It is also not strictly true in COBIT that a lower level must be fully complied with before higher levels of maturity can be reached, as in CMM. A COBIT maturity assessment is likely to result in a profile where conditions relevant to several maturity levels will be met, as shown in figure 1.

This is because when assessing maturity is often the case that some implementation is in place at different levels even if it is not complete or sufficient. These strengths can be built on to further improve maturity. For example, some parts of the process can be well defined and, even if the process is incomplete, it would be misleading to say the process is not defined at all.

Furthermore, if the six generic maturity attributes defined in COBIT are also assessed to give a more detailed analysis, it is quite likely that each attribute may be at a different level, too (e.g., policies, standards and procedures may be defined, but goal setting and measurement may be ad hoc).

It is, therefore, best to choose a level based on the "closest fit," while appreciating and understanding the positive things that have been implemented as well as the gaps that need to be improved. In the example, the process would be said to be at level 3. It would also be misleading and imply an unreal level of precision to describe the process as being at, say, level 2.9.

In COBIT the important objective is to understand what level is appropriate for a given process, based on business requirements, and to understand the nature of any gaps, so that any significant weaknesses in the process can be identified and improved. Guidance on this approach is provided in the IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition.

27. COBIT has three dimensions of maturity. What do they mean?

The three dimensions, as explained in the COBIT framework, are capability, performance and control. They can be used to be more precise when assessing maturity for a given IT process in a specific situation. The application of these dimensions is left to the COBIT user to decide depending on how detailed and precise the maturity assessment needs to be and the scope of the assessment target area.

Capability is the level of maturity required in the process to meet business requirements (ideally driven by clearly defined business and IT goals). The COBIT maturity models focus on capability and help an enterprise recognize the capability that best fits specific process requirements.

Coverage is a measure of performance, i.e., how and where the capability needs to be deployed based on business need, and investment decisions based on costs and benefits. For example, a high level of security may have to be focused upon only for the most critical enterprise systems.

Control is a measure of actual control and execution of the process, in managing risks and delivering the value expected in line with business requirements and risk appetite. A process may appear to be at the right capability level with the right management characteristics, but still fail because of an inadequate control design. This is an assessment against the COBIT control objectives considered necessary for the process. COBIT provides a generic maturity model for internal control, and processes PO6 and ME2 help institutionalize the need for good controls.

Given the above, it is possible to use all of these dimensions to carry out a detailed assessment of maturity for a specific critical area, for example, security of a banking application, or the overall change management process. At a high level they can also be used to provide an overall and thorough assessment of the maturity of a process by considering all three dimensions in the context of the overall business requirement.

28. How do you perform a COBIT-based maturity assessment?

The reality is that probably no two COBIT maturity assessments are performed in exactly the same manner. COBIT provides some tools and techniques, and the COBIT user will follow an approach based on specific enterprise needs. The assessments can be high-level, often in a workshop discussion, or detailed with careful gap analysis.

Generically, the following common principles usually apply:

  • The maturity requirements should be driven by business requirements ideally expressed as business and IT goals.
  • The requirements depend on the scope being considered and can be very specific for a particular scope or high-level if the scope is for the enterprise as a whole.
  • The maturity models help assess capability (defined in COBIT to mean how well the process is being managed in comparison to the COBIT maturity models and attributes).
  • The maturity attributes can be used to analyze current maturity levels in detail and are required to do a proper gap analysis.
  • COBIT's control objectives provide a way to measure how well the process addresses key controls needed to minimize risk and deliver value.
  • COBIT's control practices can be used to help design improved processes and to increase process maturity, together with other industry standards and best practices.
  • It is recommended that that the maturity attributes be used to assess at a detailed level and to carry out a gap analysis, so that the root causes of immaturity can be identified and business decisions can be taken on where to invest to improve maturity for least cost and maximum benefit. IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition, provides a road map that includes guidance on the above steps.

29. How prescriptive are the COBIT maturity models and supporting guidance, and how does this compare to the CMM/CMMI approach?

The MMs in COBIT , like all the COBIT guidance, are intended to be tailored and developed to suit the specific needs of the enterprise. The guidance is also at a high level with the intention that it provides generic guidance, not specific, detailed criteria. In particular, the maturity attributes are very generic and high-level, intended to be a simple guide for any process. When performing a COBIT maturity assessment, specific attribute details will need to be identified for the process under review, and compared to COBIT's control objectives, control practices, and goals and metrics to the desired level of detail. COBIT does not prescribe the assessment approach, which is a management decision, ranging from a high-level workshop discussion to an in-depth analysis, as appropriate, driven by business needs.

In CMM/CMMI, although the guidance would always need to be tailored for a given appraisal situation, the standard guidance is much more specific and detailed, due to its much narrower focus on software product delivery and more formal appraisal/assessment procedure.

30. The CMMI maturity levels appear to be different to the COBIT maturity levels. Is this true?

Yes, CMMI uses the following scale:

  • Level 0: Incomplete
  • Level 1: Performed
  • Level 2: Managed
  • Level 3: Defined
  • Level 4: Quantitatively Managed
  • Level 5: Optimizing

COBIT's scale differs:

    Level 0: Non-existent
  • Level 1: Initial/ad hoc
  • Level 2: Repeatable but Intuitive
  • Level 3: Defined Process
  • Level 4: Managed and Measurable
  • Level 5: Optimized

There is no direct relationship between these two scales. The COBIT scale was based on the original CMM scale and has remained the same since the first version of the COBIT maturity models were released in 2000. There was never any intention to align the models exactly with CMM or CMMI when it was introduced, or to try to maintain any such alignment, as COBIT's maturity modeling approach is based on different objectives to the Software Engineering Institute's (SEI's) objectives.

COBIT's models provide management with a self-assessment tool for positioning IT process capability in comparison to business requirements, and as a tool for gap analysis and improvement planning, taking into account the required capability driven by business requirements (business and IT goals), control requirements (control objectives) and performance (how much and where to implement, driven by costs and benefits).

CMMI provides a rigorous, objective and repeatable assessment, and fulfils the needs of organizations requiring certifications to meet contractual needs, or needing to demonstrate development engineering capabilities of a high maturity for customers where software development is critical.

31. Is it really possible to benchmark my maturity levels with other organizations if the maturity assessments are not very precisely measured?

Yes, even though COBIT's maturity levels are not intended to be measured precisely, the levels give a good guide to management. Even when an approximate assessment is carried out, for example, in a management workshop, the level selected is usually a sound reflection of the actual level. Benchmark comparisons provided in COBIT Online from user input and from surveys are helpful to managers for comparing their organization to others. The data collected have also empirically validated the broad nature of the actual measures—there are few "unusual" scores, IT processes even in large and significant enterprises are generally not well developed in most IT functions, and most organizations have COBIT-defined process maturity that is relatively low, i.e., between levels 2 and 3.

32. Are COBIT's maturity models useful to organizations that have already adopted CMMI?

Yes, even though the approaches are different, an enterprise that has already adopted and applied CMMI can use COBIT to cover areas not addressed by CMMI, and will be able to use the CMMI experience to apply COBIT's models to whatever formal level they require, in areas not covered by the scope that was defined for the CMMI assessment. For example, an advanced software development shop could broaden its maturity assessment to apply it to their entire IT function, including other important COBIT IT processes. The mapping publication, available from the ITGI, showing how COBIT compares to CMMI, would be a very helpful resource, but the enterprise would need to devise its own CMMI-like assessment approach using COBIT's generic guidance as a starting point, or follow the suggested approach in the ITGI publication—IT Governance Implementation Guide: Using COBIT and Val IT, 2nd Edition. In time, it is expected that the CMMI guidance will broaden into other areas such as service management, which would be equivalent to the ITIL processes and principally the COBIT DS domain.

33. Since the four COBIT resource types (applications, information, infrastructure and people) apply to each of the COBIT processes, why are some indicated and others not in the Process Descriptions?

COBIT identifies the most important resources the process owner should focus on in terms of control, management and governance. Of course somewhere every process relates to all resources but then we would have to mark every resource for every process, and then we would not add value.