COBIT. Focus. Leveraging COBIT to Tighten Controls in Using Third-party Software. The newsletter dedicated to the COBIT user community

Transcription

1 COBIT Focus April 2009, Volume 2 The newsletter dedicated to the COBIT user community Leveraging COBIT to Tighten Controls in Using Third-party Software By Chong Ee, CGEIT In a recent panel presentation on IT considerations in riskbased audits, a number of audience members voiced concerns over their increasing reliance on application software maintained and operated by third parties to obtain numbers for financial reporting. Specific questions included: How can management ensure that the transactions processed by third-party software are performed in a complete, accurate, valid and secure manner? How can management obtain assurance on the continued operation of third-party software? In This Issue Leveraging COBIT to Tighten Controls in Using Third-party Software By Chong Ee...page 1 COBIT Guidance for Service Managers By Gary Hardy...page 3 Banking Industry Regulatory Challenges: Moving From Regulation-based to Process-based Compliance By Buck Kulkarni...page 4 The Need for COBIT Mappings By Jimmy Heschl...page 9 COBIT as a Supporting Tool for IT Supervision of Pension Funds Administration Companies By Guillermo Perez...page 10 IT Governance and Process Maturity: A Research Study By Roger Debreceny and Glen L. Gray...page 14 Control Objectives for Information and related Technology (COBIT ) provides a comprehensive framework for identifying, reviewing and tightening controls in the use of third-party software. Figure 1 illustrates specific COBIT processses and areas of application. Although COBIT focuses on IT general controls, it also outlines a set of related application control objectives (AC1 through AC6) that cover source data preparation and entry, edit checks and processing, and output validation and data transmission integrity. In mitigating transaction-level risks arising from the use of thirdparty software, management needs to revisit key classes of business transactions and perform an end-to-end process walkthrough of each key transaction class. Application controls provided by third-party software encompass transaction-level controls configurable or inherent in an application addressing one or multiple control objectives of data completeness, accuracy, validity and authorisation. In reviewing the business process(es) supported by a third-party application, management examines existing application controls and, where gaps exist, identifies compensating manual transaction-level controls. As an example, the lack of a preventive application control tying posted invoices to actual shipments upstream may be compensated by a detective manual control on weekly invoiced-to-shipped reconciliations downstream. In reviewing the transaction life cycle, management may need to review interfaces between third-party software and Continued on page 2

2 Figure 1 COBIT Processes and Application to Third-party Controls COBIT Process AI2 Area Acquisition and maintenance of thirdparty application software Areas of Application Review of automated functionality in line with control design requirements and vis-à-vis compensating controls maintained by the enterprise AI5 Procurement of IT resources Review of policies and procedures around supplier sourcing and whether transaction processing requirements are addressed through a request for proposal (RFP) or other processes DS1 Management of service levels Periodic review of actual vs. expected third-party service levels and overall user satisfaction DS2 Management of third-party services Review of policies and procedures governing the management of external providers that maintain and operate third-party software DS4 Continuous availability of IT services Review of unplanned outages and third-party service levels specific to application availability DS5 Management of systems security Periodic review of software access controls and history of security incidents ME2 Monitoring and evaluation of internal control Periodic review of internal control reports, such as SAS 70s, from third parties and how they integrate with an enterprise s internal controls over financial reporting internal sofware, as well as interfaces amongst two or more third-party softwares. For example, if output from a third-party subledger application is downloaded into a spreadsheet for upload to an internal general ledger application, there is a risk that the downloaded data may be manipulated in an inappropriate manner prior to the upload. In this situation, management may choose to tighten end-user computing controls surrounding the downloaded spreadsheets. It is important to differentiate application controls provided by third-party software from IT general controls maintained by a third-party provider in operating the software. For management to rely on the former, it needs to obtain assurance about the latter. IT general controls maintained by a thirdparty provider encompass pervasive-level IT controls governing the access administration, change management and operation of the provided software. These may be documented extensively in periodic Statement on Auditing Standards (SAS) 70 reports. In handling a thirdparty deficiency in access management, management may opt to augment existing procedures on third-party reporting and review and tighten internal entity controls around security administration and month-end close procedures. In piecing and assembling the population of internal controls related to the use of third-party software, specific controls may be deemed key in mitigating identified risks in a sustainable manner. These, in turn, provide the substance for reporting and monitoring individuals responsible for managing the service provider relationship, i.e., relationship owners. Ultimately, mangement is responsible for the achievement of related control objectives. In its increasing use of third-party software for transaction processing, it is imperative that an enterprise embrace and maintain an effective set of third-party controls that support overall data integrity, confidentiality and availability. References IT Governance Institute, COBIT 4.1, USA, 2007 Knowledge Synergized, IT Considerations in Risk-based Financial Statement Audits, 22 January 2009, Chong Ee, CGEIT is the director of compliance and accounting process at ZipRealty Inc. Having held a variety of compliance, audit, analyst and consultant roles with UPEK, XOMA, PricewaterhouseCoopers, Deutsche Bank and KPMG Consulting, Ee s focus is on bridging compliance with process improvement. page 2

3 COBIT Guidance for Service Managers By Gary Hardy, CGEIT The IT Governance Institute (ITGI ) has recently released a new COBIT publication aimed at IT service managers, available at This is the first of a series of guides aimed at specific positions who use COBIT to enhance IT governance within their specific scope of activities. It also helps explain how to use COBIT together with other standards and best practices relevant to the role in this case, the IT Infrastructure Library (ITIL) V3 and ISO Users of COBIT and ITIL may find it difficult to navigate and identify guidance that is relevant to their particular service manager role. Furthermore, it may also be difficult to know how COBIT and ITIL can be applied together. COBIT User Guide for Service Managers helps overcome these issues and provides a focused view of how those involved in key service management roles can use COBIT and ITIL to meet the challenges of service management. It will help them ensure that properly governed and managed services are provided to businesslevel customers and users of the services. The objective of the guide is to help those responsible for managing the end-to-end life cycle of IT services to understand how to best use COBIT and ITIL to enhance IT governance. For the purposes of the guide, this role is called service manager. It is accepted that a wide range of job titles hold the service manager role in enterprises today and, furthermore, that there are many kinds of enterprises involved in IT service delivery, including in-house IT functions. It is not the intent of the guide to prescribe a specific role. For governance of IT services to be effective, the roles and responsibilities for management activities need to be clearly defined. This guide s intention is to help any manager involved in managing IT services to consider his/her role and make sure that responsibility and accountability have been clearly allocated for all key service management activities. The guide s intention is also to help service managers better understand the need for IT governance and how to apply good practices in their specific roles and responsibilities. Its aim is also to facilitate easier use and adoption of the COBIT and ITIL concepts and approaches, and to encourage integration of COBIT with ITIL. While the primary audience is those fulfilling a service manager role, other managers will find it useful to understand the service manager s role and how their specific roles can interact to achieve business objectives. It is also important for senior business and IT management to have an appreciation and understanding of service management to ensure that there is an understanding of the service manager s role. Senior management sponsorship will enable higher IT governance and service management maturity levels, which in turn will contribute to increased value to the enterprise and reduced risks. The guide s structure is based on COBIT s components key controls, goals and metrics, roles and responsibilities (RACI) charts, and maturity models. It also leverages ITGI s COBIT mapping research and the latest mappings between COBIT 4.1 and ITIL V3.3. The guide is structured as follows: Chapter two explains the need for service management good practice. Chapter three provides an overview of a service manager s role and why it is important, and defines the most important activities of a service manager and how they relate to IT governance. Chapter four explains how COBIT and ITIL support governance of IT services. Chapter five explains how to get started and combine COBIT and ITIL for successful service management. Chapter six contains the core guidance in the form of a table showing: The key activities of a service manager, organised by ITIL V3 processes The corresponding COBIT 4.1 control objectives The corresponding ISO/IEC :2005 references A generic range of roles and responsibilities, expressed as a Responsible, Accountable, Consulted and/or Informed (RACI) chart Continued on page 4 page 3

4 The content of the table in an expanded worksheet form, including copies of the relevant COBIT control objectives and control practices, is available to ISACA members separately as a downloadable Microsoft Excel workbook. Appendix 1 contains a maturity model for the service manager role. Appendix 2 contains example case studies. Appendix 3 contains an overview of COBIT and ITIL. Gary Hardy, CGEIT is director of IT Winners, an independent consultancy based in South Africa. He has been involved in the IT industry for more than 30 years and is a longstanding member of ISACA. He has worked in a variety of IT roles, initially as a systems developer and project manager, then as computer audit manager for a major oil company and group manager at Deloitte & Touche in London. He has been director of consultancy for a major IT security company and a director of risk consulting at Arthur Andersen. He is currently an advisor to the ITGI and Deloitte, a thought leader on IT governance, and an author of many publications on related topics. Banking Industry Regulatory Challenges: Moving From Regulation-based to Process-based Compliance By Buck Kulkarni, CISA, CGEIT, PgMP The banking industry faces a plethora of regulations. As the current crisis has shown, some aspects fall under multiple regulations while others are unregulated. For example, the US has multiple regulators, such as the Securities and Exchange Commission (SEC), the Office of Thrift Supervision (OTS), the Office of the Comptroller of Currency (OCC) and the National Credit Union Administration (NCUA), to regulate national banks, regional banks, banks that are public corporations, fair lending practices, consumer protection, identity protection, capital adequacy requirements, antimoney-laundering (AML) activities, nefarious use of the banking system and so forth. US banks also need to comply with international regulations and self-regulatory frameworks. Explosive growth in new product categories and the possibility of surviving banks becoming universal banks provide a glimpse into what lies in store for the US banking industry. As each regulation emerges in response to a specific crisis, it imposes its own rules. The regulations do not have forward, backward or sideways compatibility. In other words, the effort an enterprise makes to meet the know-yourcustomer (KYC) regulation, for example, does not help it meet US Sarbanes-Oxley Act requirements and its efforts toward Sarbanes- Oxley compliance do not help in Payment Card Industry (PCI) Data Security Standards (DSS) compliance. Information technology is the catchall layer that has to remediate the noncompliant pieces, but it is usually too rushed and too understaffed to formulate a unified, costeffective framework. Clearly, the banking industry has paid a heavy price for this, and there is an evident drive among banks to beef up their security and regulatory compliance capabilities. Should the administration of US President Barack Obama bring about enhanced regulatory focus (as it has promised to do), it will likely galvanize banks into action at an accelerated pace. Herein lies the danger. New regulations will again address new areas (e.g., swaps, synthetics, derivatives, exchanges) and, again, they will operate independently of present regulations. KYC, AML, the Sarbanes-Oxley Act, the US Patriot Act, SB 1386 (and its equivalents in other states), the Gramm-Leach-Bliley Act (GLBA), PCI DSS and Basel II are some of the regulations that impact US banks. Every transaction banks conduct can break one or more of these laws. Neither the regulations nor the regulatory authorities have a coordinated approach, so the banks have to comply with one regulation at a time. The finance function drives Sarbanes-Oxley compliance, the card business drives PCI DSS compliance, the retail business drives OTS compliance and so forth. This has created compliance silos that are inefficient, redundant and expensive. Continued on page 5 page 4

5 The last six years have shown that a more effective approach would be achieving reasonable assurance at a business process level and translating this assurance to the regulatory compliance layer. and/or groups, and there is no common thread to monitor a transaction from end to end. Figure 1 illustrates how a customer triggers a transaction. The process-based approach to compliance has four essential steps: 1. Identify business processes. 2. Assess risks to prioritize remediation. 3. Identify controls necessary to provide reasonable assurance. 4. Implement and monitor controls. Step 1 Identify Business Processes A documented process map is vital to an enterprise s efficiency. A detailed process map shows how each trigger (e.g., a customer depositing a check) activates the business process and what subprocesses are performed, until the trigger is fully processed and an end-oftransaction can be declared. In many banks, due to legacy and other issues, this process chain is performed by different technology platforms A sample transaction will elucidate figure 1. For example, a customer requests to remit British sterling to a foreign destination. The customer, who has a US dollar-denominated account, executes a withdrawal transaction from his/her savings account. This initiates a transaction for a foreign exchange system, which may process through a separate software application and may not be integrated with the savings account application. The system has to check for standing instructions and probably work via a foreign exchange dealer. Additionally, there are multiple initiation points for this transaction. Different parts of this process may be subject to different regulations (including KYC, Foreign Figure 1 Retail Banking Transaction Process Continued on page 6 page 5

6 Assets Control and AML regulations), but the process is one. Thus, making the whole process compliant with best practices (that go beyond all regulations) is a more efficient approach. Step 2 Risk Assessment to Prioritize Remediation Defining and documenting the risk profile of each business process is vital to remediation. Using COBIT principles, the IT risk can be seen as the likelihood and impact of the following attributes of data being compromised: 1. Effectiveness 2. Efficiency 3. Integrity 4. Confidentiality 5. Availability 6. Compliance 7. Reliability To assess these criteria, the enterprise must look at all networks, hardware, operating systems, databases, applications and web layers that participate in the chain of actions performed from initiation to completion of transactions Thus, the enterprise can assign a clear risk rating to each process in the context of the seven criteria. Any action it takes on the basis of these steps has a universal applicability and is not based on regulations, geography (i.e., country-specific regulations) or any other subjective considerations. If it can provide assurance that it provides confidentiality to a data store based on industry standard principles and practices, it automatically complies with regulations that demand confidentiality of data. Some regulations are prescriptive in nature and call for additional actions, but such actions will only be incremental and not call for new initiatives. Step 3 Using COBIT to Identify Relevant Controls for Each Process Applying COBIT is the third stage of processbased compliance. An enterprise does not have to implement all 34 COBIT processes, as all may not be relevant. The enterprise can identify (and document for its auditors) the process domains that are important to the business process under Continued on page 7 Figure 2 Relevant COBIT Processes for Identified Business Process page 6

7 review and focus its efforts on providing controls and documentation on those areas. This will reduce the effort and cost of COBIT mapping, without compromising governance, risk and compliance (GRC) goals. The following section takes the transaction process from figure 1 and identifies the COBIT process domains that are relevant to it in figure 2 (shown in bold italics). The following 14 COBIT processes help the identified business process in the described ways: 1. PO2 Define the information architecture A single transaction triggers multiple actions. The information architecture identifies where an action belongs (the owner), the IT application(s) that perform(s) the action and the processes that interface with the action (to provide input, validation or business rules or to accept output), and provides a technical description of this application. This information enables the organization to trace a business process through its constituents and maintain control over the process. 2. PO4 Define the IT process, organization and relationships One business process can (and usually will) be performed by many IT processes. Each IT process will have an owner, custodian, approver and auditor. The knowledge of these elements and their interdependencies is crucial to maintain the integrity of the process. 3. PO9 Assess and manage IT risks This section describes the identified risks; their rating; and the avoid, transfer, mitigate and accept (ATMA) determination. Without this knowledge, every action may create risks unknown to the performer. 4. AI2 Acquire and maintain application software The stakeholders of the business process need to know how the applications that execute the business process are acquired and maintained. The diligence, methodology and validation provide information on how secure and dependable the performance of the process is. 5. AI3 Acquire and maintain technology infrastructure The underlying infrastructure of networks, servers, databases, and security and access control devices is as important as the application that executes the business process. Assurance on the infrastructure goes a long way toward providing the assurance of the business process. 6. AI6 Manage changes If changes to the information architecture, applications and infrastructure are not managed in a reliable manner, they will lose integrity over time, and the execution of the business process will become unstable and unreliable. 7. ME2 Monitor and evaluate internal control This section describes the internal controls that are at work while the business process is performed (e.g., how segregation of duties is achieved, how access is denied or permitted, how maker-and-checker is implemented.) This description assures the business user and the auditor of the dependability of the process results. 8. ME3 Ensure compliance with external requirements This section describes the data, audit trails, logs and other information captured and processed to report on the regulatory compliance of actions performed in the business process (e.g., how credit card data are identified, segregated, encrypted and stored will determine compliance with PCI DSS). 9. DS5 Ensure systems security This section is universal, as there is no business process that will survive without it. The security measures in operation on the infrastructure, applications, data stores, user access and all other factors in the business process demonstrate the assurance on the seven criteria discussed earlier. 10. DS8 Manage service desk and incidents Incidents occur frequently during execution of business processes. Some may be user-committed and some may be due to system failures. Study of service requests and incidents provides insight on the assurance level available in the business process and needs careful analysis to maintain reasonable assurance. 11. DS 9 Manage the configuration This section describes how the configuration (the preset parametric values in devices and software) options are chosen, applied and changed for all participating devices, software and operating procedures. Any uncontrolled configuration change can create potential for errors and fraudulent actions. 12. DS10 Manage problems The day-to-day performance of business processes poses problems to stakeholders, from users to administrators to business managers to Continued on page 8 page 7

8 auditors. This section describes how these problems are captured, processed, resolved and communicated to stakeholders. 13. DS11 Manage data For most stakeholders, it is ultimately the accuracy of the data that provides the proof of reliability. The data management processes are described in this section from creation to destruction, and stakeholders need to understand these before they can feel assured about data integrity. 14. DS13 Manage operations A business process has to be operational to impact the business, and this section describes how the process operates in real life. The persons authorized to operate this process, their rights and obligations, the audit reviews of operations, and monitoring of resources provide assurance on the reliability of the business process. Step 4 Implement and Monitor Controls The 14 processes noted previously are relevant to a business process that handles customer transactions. It is important to keep in mind that other processes may become relevant to this process as circumstances change. For example, when introducing web-based banking, DS7 Educate and train users may be treated as a primary process for a period of time. Similarly, if this business process is outsourced to a vendor, DS13 Manage operations may be replaced by DS2 Manage third-party services. Conclusion As these processes are employed for multiple business processes, they can be visualized as multiple circles. As the number of circles increases, they start overlapping and these overlapping parts are the benefits reaped from the process-driven approach to compliance, e.g., an enterprise may implement a data encryption system in one business process. Once proven and audited, it can be replicated to other processes at marginal cost and effort. This one effort will meet the internal control and governance of data security, be it under Sarbanes-Oxley, PCI DSS, GLBA or any other regulation. Buck Kulkarni, CISA, CGEIT, PgMP is an IT GRC consultant based in Rutherford, New Jersey, USA. He builds GRC frameworks to assist organizations in meeting their governance, risk management, audit and regulatory compliance challenges in a unified and cost-effective way. He has executed Sarbanes-Oxley, PCI DSS and data privacy compliance projects for banking, financial services and retail industries and makes extensive use of the COBIT framework in his work. He can be reached at bkul@live.com. page 8

9 The Need for COBIT Mappings By Jimmy Heschl, CISA, CISM, CGEIT Whatever framework an organization uses for managing its IT department and for governing enterprise IT, there are numerous other standards, good and best practices, frameworks, and reports available. IT professionals must ask whether the framework the organization uses is appropriate, complete and stable. How can this be demonstrated? What if the organization uses the IT Infrastructure Library (ITIL) for its operational IT processes, COSO s Enterprise Risk Management Framework for enterprise risk management (ERM), and gets ISO/IEC certified as specifically required for one of its customers? Many organizations need to start from scratch for each and every standard with which they need to comply, not just because the implementation or compliance process is not repeatable, but because the former implementers have built up their own silo in which they currently operate and they are experienced in defending their universe. Have you ever talked with a security manager [usually highly experienced in ISO and National Institute of Standards and Technology (NIST) standards] about service management (ITIL)? Or have you discussed portfolio, program and project management with an ITIL-experienced service manager? They immediately try to broaden their standard (or it could be called their universe ) to the new domain, and they try to broaden the scope of what they know. There s no clear link in ISO to service management, application development, project management, program management or portfolio management. To make such a link, one either has to invent the link or adopt a broader standard. Linking such subject matters and breaking down the silos is surprisingly simple. Suddenly the experts realize that, outside of their own silo, IT professionals and business departments try to approach similar objectives with comparable methodologies. They define processes, implement and improve controls, measure the achievement of their goals, and create a report on the efficiency and effectiveness of the process. A board member receives one report on the status of service management, structured according to ITIL and using ITIL terms; one report on portfolio, program and project management from a staff member with the Project Management Body of Knowledge (PMBOK) certification who also has knowledge and understanding of Val IT ; a risk management report including some IT risks from the risk manager; security management reports from the International Organization for Standardization (ISO)-experienced security manager; and the latest budget figures on IT spending from the controlling department. It is a difficult job first to understand those different reports and approaches (and what should actually be done with them) and then to make the right decisions. Therefore, there is a definite need for a common, unifying framework to ensure that IT processes are complete and managed adequately to ensure that the organization s objectives are achieved. This framework is COBIT. History of COBIT Mappings In 2002, this article s author started his first mapping initiative to help a customer adopt COBIT, British Standard (BS) 7799 (which became ISO 27001), ITIL and other standards. COBIT Research Update Recently released COBIT initiatives include: ITGI Enables ISO/IEC 38500:2008 Adoption COBIT User Guide for Service Managers The above publications can be found at or COBIT initiatives scheduled for availability in second quarter of 2009: COBIT and Application Controls: A Management Guide COBIT Mapping: Mapping of FFIEC With COBIT 4.1 COBIT Mapping: Mapping of ISO With COBIT 4.1 COBIT Mapping: Overview of International IT Guidance, 3 rd Edition Continued on page 10 page 9

10 The methodology used is quite simple: 1. Tear the standards into small, digestible pieces of information (sometimes a paragraph, sometimes a sentence, sometimes a single word). 2. Map those chunks to one (or sometimes more) COBIT control objective. The possibility exists that there may be some portions that cannot be mapped to any control objective, in which case the need for a new control objective is identified. In the author s BS 7799 mapping, such a case occurred on only one occasion. In 2003, ITGI, as the result of great interest from COBIT users, set up a program to manage future mappings. The first deliverable was the Overview of International IT Guidance to give the intended reader a quick overview. The first detailed mapping (ISO 17799, with more than 1,000 interrelationships) was published in Since then, ITGI has published mappings of COBIT with PMBOK, PRINCE2, Capability Maturity Model Integration (CMMI) 1.1, The Open Group Architecture Framework (TOGAF) 8.1, ITIL V2, ISO 27002, CMMI 1.2 and ITIL V3. ITGI is currently finalizing mappings to ISO and Federal Financial Institutions Examination Council (FFIEC), and is developing mappings of Val IT to Managing Successful Programmes (MSP), ITIL V3 and PRINCE2. Additionally, ITGI is planning to interlink COBIT with Val IT and the soon-to-be-published IT risk framework. Summary The mapping documents can help identify the interdependencies and overlaps of these standards. This is helpful in implementing the standards and avoiding gaps, as described previously: the gap of productivity/efficiency that resides within and between the silos and the gap in information for effective decision making at the board and business management levels. By using COBIT as the umbrella framework, IT practices and standards can be integrated to achieve a complete overview of IT. Proven methodologies can be reused to define, manage and improve objectives, processes and controls, and the mapping documents can be a useful tool in getting there. The mapping documents can be downloaded from the ISACA web site at Jimmy Heschl, CISA, CISM, CGEIT is senior manager of IT advisory at KPMG Austria. He is also a board member of the ISACA Austria Chapter, a member of the COBIT Steering Committee and program manager of ITGI s COBIT Mapping series. He was highly involved in the development of COBIT 4.0 and 4.1. He is highly experienced in implementing COBIT in numerous organizations and is an accredited COBIT trainer. COBIT as a Supporting Tool for IT Supervision of Pension Funds Administration Companies By Guillermo Perez The main role of the regulator/supervisor of pension funds administration companies is the protection of the affiliate s rights, as well as those of the retirees and their beneficiaries. This implies, among other things: Protecting the affiliate s right over the monies that have been deposited in his/her name Ensuring access to information Proposing a framework to regulate the activities of these entities with regard to operational, legal, fiscal, financial, investment and accounting areas Ensuring appropriate working of operational processes Evaluating companies risks and proposing measures to mitigate them Applying corrective mechanisms over the entities operations to improve their efficiency and avoid unwanted practices To accomplish this role, the regulator and supervisor must have enough legal backing to authorize, regulate, inspect, investigate, punish, suspend and terminate operating authorization for a given entity. Specifically, to perform the referred tasks, it is essential for the IT supervisor to have available an adequate tool set and a supporting framework, particularly related to accessing information belonging to the controlled entities, irrespective of where that information might reside. Continued on page 11 page 10

11 In risk-based supervision, the supervisor focuses his/her efforts on ensuring that the supervised entities utilize appropriate processes to identify, measure, monitor, mitigate and publish their risk exposure. COBIT offers the supervisor a tool set to use as a guide or to build an environment-adapted audit framework. Supervision and Outsourced Services In an ever-increasing way, organizations seek more efficiency and efficacy in their business processes, in addition to lowering their operating costs. This tendency is notorious in key areas such as: Software development and maintenance Application hosting Contingency sites and backup storage Communications Hardware maintenance As a consequence, the IT supervisor must lend special attention to verifying the responsibilities for each link of the outsourcing contracts chain assumed by the organization. Activities may be delegated, while responsibilities for their correct development may not. Some basic questions may be identified that arise when risk-based supervision is undertaken, particularly when supervised organizations outsource key business services: Are the IT processes those required by the business? Are process execution responsibilities clearly delimited? Are process owners clearly assigned? Are adequate internal controls in place? Are risks adequately understood and managed? Is there adequate information protection in regard to confidentiality, integrity and availability? Is assigned personnel adequate to use the IT systems in a safe and productive manner? COBIT provides a framework that allows the supervisor to order his/her work, enabling the use of a tool set that simplifies the search of answers to the questions. Activities that should be verified as to adequate risk management include: Access to information of the pension funds administration companies affiliates (clients) by the outsourcing companies in the course of performing their activities Pension fund administration companies key Continued on page 12 Figure 1 Example Survey Question Excellent Very Good To what degree are all third-party services identified and categorized according to third-party type, importance and criticality? To what degree is a formal documentation procedure kept to keep record of technical and organizational relationships, objectives, expected deliverables and credentials of the third party s representatives? To what degree is the relationship management process formalized for each third party? Good Sufficient Poor Observations Figure 2 Questionnaire by COBIT Process, Applied to DS2 DS2 Manage Third-party Services Excellent Very Good To what degree is an owner assigned to the process to ensure that responsibilities are clearly defined? To what degree are roles, activities and responsibilities defined for an efficient process execution? To what degree are objectives clearly established for this process? To what degree is process performance measured to enable comparison with established objectives? Good Sufficient Poor Observations page 11

12 business process execution, especially when outsourced Data management and backup safe storage Job assignments to predefined roles in outsourcing contracts Information recovery in the event of contract noncompliance by contracted third parties Business continuity planning Get to Know Supervised Reality One way to become familiar with the condition of the supervised universe is to implement selfassessment surveys based on COBIT processes. The results of this task tend to direct controls and audits more efficiently toward weaker aspects of technology processes in the organizations, but, as the result comes from applications of the interested party itself, it cannot be the only tool to that effect. This technique can be complemented with interviews, where the IT supervisor can use preformatted forms, to clarify answers to the surveys and incompatibilities among answers, amplify results, and document affirmations from the audited parties. Process Questionnaire Surveys based on COBIT processes provide insight into the reality of the companies internal Continued on page 13 Figure 3 Fragment From the Maturity Model for DS2 Maturity Level Description 0 Nonexistent There is no recognition of the need for internal control. Control is not part of the organization s culture or mission. There is a high risk of control deficiencies and incidents 1 Initial/ad hoc There is some recognition of the need for internal control. The approach to risk and control requirements is ad hoc and disorganized, without communication and monitoring 2 Repeatable but intuitive Controls are in place but are not documented. Their operation is dependent on knowledge and motivation of individuals. Effectiveness is not adequately evaluated. Many control weaknesses exist 3 Defined Controls are in place and are adequately documented. Operating effectiveness is evaluated on a periodic basis and there are an average number of issues. However, the evaluation process 4 Managed and measurable There is an effective internal control and risk management environment. A formal, documented evaluation of controls occurs frequently. Many controls are automated and regularly reviewed. Management 5 Optimized An enterprisewide risk and control program provides continuous and effective control and risk issues resolution. Internal control and risk management are integrated with enterprise practices, supported IT-enabled Business Activities Pure IT Activities Legend: R: Responsible A: Accountable S: Supported C: Consulted I: Informed Activities Collection Account closure Affiliation recording Intercompany affiliate migration Pension funds investment Application development and maintenance Application change management Access control Data administration Backups Figure 4 Example RASCI Chart CEO CFO Business executives CIO Role Business process developer COO SW development manager DBA page 12

13 controls on an individual basis and, therefore, an understanding of the status of the whole pension funds administration system. Such information is of great use to the supervisor. While such questions can be answered from different criteria by different organizations, the varying results would then have to be assessed by the supervisor in the results review and comparison stage, comparing actual information received against minimum expectations. This would be inefficient. A survey form based on COBIT s control objectives (figure 1) allows for an efficient comparison of control management by the supervised entity against the minimal requisites for an effective IT process control. It is interesting to complement the knowledge obtained from the process of implementing a questionnaire for each situation with the generic COBIT process (figure 2), particularly when supervision is undertaken in initial control stages. Maturity-level Questionnaire Questionnaires based on the COBIT maturity models benefit from the precision of level descriptions, which means that differences among criteria-based answers are more detailed than in process surveys (figure 3). Application of this model also helps to establish the gap among current and desired maturity levels. RACI Charts Responsible, Accountable, Consulted and Informed (RACI) charts define which activities should be delegated and to whom (figure 4). They also provide the supervisor with a risk identifier, based on the deviations from preestablished roles recorded in service contracts. To ensure that they are supported by evidence, it is convenient for these charts to be filled by the supervisor through interviews with the supervised. The charts clearly show which roles perform which activities. Additionally, the chart being used for the pension funds administration companies in Uruguay has an additional attribute, S, supported ( RASCI chart). 1 Other Benefits Pension funds administration companies are generally required to hire external audit services. It is also common that when the supervising entity adopts a recognized better-practice-supported audit framework, audit firms will align with this framework. This brings the additional benefit that the supervisor and audit firms speak the same language, and generating such a continuity line in external audit reports allows for follow-up on previous findings. COBIT greatly facilitates the communication between the external auditor and supervising entity, which becomes essential to the supervisor. Conclusion The IT supervisor must incorporate new tools that help control the organization and thus contribute in mitigating risks inherent to controlled processes. COBIT is essential in this environment. COBIT s contributions in this respect are essential for supervision s life cycle, providing the supervisor with widely tested tools for IT control management and leaving to the supervisor s judgment and market needs the the opportunity and depth at which to apply and implement them. Guillermo Perez was an IT internal control systems analyst with the Central Bank of Uruguay (BCU) and is now an IT inspector for the division of market values and control at AFAP BCU. Author s Note All opinions are purely those of the author and do not represent an official or institutional stand or position by the Central Bank of Uruguay. Endnote 1 This organization uses the S attribute to reflect those organizational positions which do not have a direct relationship to the other attributes, but nonetheless are required to support the mentioned activity. During the COBIT 4.0/4.1 developments, this aspect was considered but it was determined that this was not tangible and people, therefore, cannot be held accountable for such support. The decision was made that such support did not need to be mentioned in the COBIT RACI chart, but should be part of enterprises basic HR policies and evaluated regularly during performance reviews. page 13

14 IT Governance and Process Maturity: A Research Study By Roger Debreceny, Ph.D., and Glen L. Gray, Ph.D., CPA An important attribute of IT governance is the development and maintenance of the capability to perform key IT processes. The IT function, working with the rest of the organization, must build a variety of capabilities to meet organizational and strategic objectives. Formalized methods for the identification and development of process maturity have been in existence for many years through the work of the Software Engineering Institute s (SEI) Capability Maturity Model (CMM) and Capability Maturity Model Integration (CMMI). Achievement of process maturity is also a core element of COBIT, with a somewhat modified version of CMM playing a key role. Process maturity in COBIT has five levels (plus zero) to measure the maturity of IT processes (zero being nonexistent, one being initial and ad hoc, two being repeatable but intuitive, three being defined, four being managed and measurable, and five being optimized). At level one, the COBIT framework notes that there is evidence that the enterprise has recognized that the issues exist and need to be addressed. There are, however, no standardized processes; instead, there are ad hoc approaches that tend to be applied on an individual or case-bycase basis. At the other end of the continuum, at level five, COBIT notes that processes have been refined to a level of good practice, based on the results of continuous improvement and maturity modeling with other enterprises. Chief information officers (CIOs) and other executives know that it does not make economic sense to be at a level five maturity for every IT process, because the benefits of being at level five for every process could not justify the costs of achieving and maintaining that level of maturity. One would expect process maturity levels to vary for different IT processes, IT infrastructure and industry characteristics. For example, level two may be adequate for one IT process, but inappropriate for another, more critical IT process. Differences in maturity come from factors such as the risks facing the organization and the contribution of processes to value generation Continued on page 15 page 14

15 and service delivery. IT managers must ask, where should we be for our key processes? or, at least, how do we compare to our peers? Field Study ITGI provided funding for a large-scale international field study to develop quantifiable IT governance benchmarks. The study used COBIT s business processes and definition of process maturity as the foundation for data collection. Fifty-one IT organizations were visited in Asia, Europe and North America. From these, process maturity data were collected from the owners of each process described in COBIT. Where data were collected from more than one person for a given process, the between-person variation was typically within one level of maturity. These data are, of course, selfreported and subject to bias, and the responses were not able to be validated independently. The number of level zero and one responses received indicates that the respondents were candid in the information provided. The detailed process maturity data were coupled with demographics about the organization and the IT function. COBIT groups IT activities into 34 processes within four logical domains. Based on prior evaluations of process performance, five of the COBIT processes were divided into subprocesses because of the complexity and importance of the individual process (e.g., DS5 Ensure systems security) or because of markedly different concepts embedded within the process (e.g., the data classification and enterprise architecture concepts within PO2 Define the information architecture). As a result, a total of 41 processes were used for the project. In addition to collecting maturity levels, a separate questionnaire was used to interview the CIO to collect IT governance and demographic information for the organization. A wide variety of issues that had previously been identified as relevant to the study of IT governance was investigated. These included: The nature and extent of strategic and tactical alignment between IT and the rest of the organization The structure of the IT function in, for example, centralized, decentralized and socalled federal modes Adoption of IT governance processes and frameworks and demographic data on size, industry, spending, etc. The organizations studied were relatively large because the study wanted organizations that were actively involved in all the various COBIT IT processes. The organizations averaged 172 IT staff and 3,132 clients (or workstations) (with a maximum of 15,000 clients). COBIT and the IT Infrastructure Library (ITIL) were used in the organizations studied. However, only 16 percent and 10 percent, respectively, were intensive users of either COBIT or ITIL. Only three organizations, 6 percent, said that they thoroughly followed both COBIT and ITIL. Results The full 100-page research report, IT Governance and Process Maturity, is available at A few of the findings are described here. As mentioned earlier, COBIT divides process maturation into six different attributes. Reviewing the general maturity levels for the six attributes across processes, the extremes are quite COBIT Education Update COBIT Campus Courses For more information on COBIT classroom and e-learning courses, please visit the COBIT Campus ( ISACA Conference and Education Opportunities Related to COBIT At the 2009 International Conference in Los Angeles, California, USA, on July, ISACA will offer the following COBIT-related workshops and sessions: WS1, Implementing IT Governance Using COBIT and Val IT (preconference, two-day workshop) WS2, Using COBIT in IT Audit and Assurance (preconference, two-day workshop) 121, Update to the IT Governance Implementation Guide 112, COBIT IT Assurance Guide 122, Application Controls and COBIT For more information on these offerings and to register for the International Conference, please visit At the ISACA Training Week in Vienna, Austria, on June, the course COBIT: Strategies for Implementing IT Governance will be offered. To learn more about this opportunity and to register, please visit Continued on page 16 page 15

16 dramatic. The awareness attribute was in the top third for 68 percent of the processes. It was in the lowest third for only five percent of the processes. The goal attribute was in the lowest third for 68 percent of the processes and only in the top third for two percent of the processes. The other relatively high-level attribute was responsibility, which was in the top third for 51 percent of the processes. The other relatively low-level attribute was tools, which was in the bottom third for 56 percent of the processes. The research also explored the consistency in maturity across processes and analyzed the maturity results for different characteristics of the organizations, including country, industry, size of IT operations, IT spending as a percentage of revenue, alignment of business and IT goals, level of outsourcing, and IT governance structure. Conclusion What do the results of the research indicate? For one thing, the research demonstrates that maturity levels of four and five are achievable. On the other hand, because of the low levels for some processes and specific attributes in some processes, the first reaction might be to say that organizations should focus more resources on those processes and attributes to increase their maturity levels. However, one could argue that the levels of any of these processes evolved over time to their sufficient (or adequate or satisfactory) level. This would be called a satisficing strategy where the goal is to achieve an adequate level as opposed to an optimum level. While not promoting this strategy, satisficing does appear to be the dominant strategy for many organizations and should not be rejected out of hand. In the extreme, this strategy is pejoratively called the firefighting strategy. Only with a self-assessment balanced with a careful risk assessment can organizations determine what their target levels should be whether they are adequate (satisficing) levels or optimal levels. The complete report provides detailed maturity model information and explains how to conduct a self-assessment to compare an organization to the 51 organizations included in this study. Roger Debreceny, Ph.D. is the Shidler College distinguished professor of accounting in the Shidler College of Business, University of Hawaii at Manoa (USA). Prior to becoming an academic, he held senior finance positions in Asia. He is a past chair of the COBIT Steering Committee. He can be reached at rogersd@hawaii.edu. Glen L. Gray, Ph.D., CPA is a professor in the accounting and IS department of the College of Business and Economics at California State University in Northridge, California, USA. He has conducted research projects funded by ISACA, The Institute of Internal Auditors, the American Institute of Certified Public Accountants and Big Four accounting firms. He can be reached at glen.gray@csun.edu. COBIT Steering Committee Robert E. Stroud, CGEIT, USA, chair Gary S. Baker, CA, Canada Rafael Eduardo Fabius, CISA, Uruguay Erik Guldentops, CISA, CISM, Belgium Jimmy Heschl, CISA, CISM, CGEIT, Austria Debbie A. Lew, CISA, USA Greet Volders, CGEIT, Belgium Editorial Staff Jane Seago Chief Communications Officer Jennifer Hajigeorgiou Senior Editorial Manager Comments regarding the editorial content may be directed to Jennifer Hajigeorgiou, senior editorial manager, at jhajigeorgiou@isaca.org. COBIT Focus is published by ISACA and the IT Governance Institute. Opinions expressed in COBIT Focus represent the views of the authors. They may differ from policies and official statements of ISACA and/or the IT Governance Institute and their committees, and from opinions endorsed by authors, employers or the editors of COBIT Focus. COBIT Focus does not attest to the originality of authors content ISACA and IT Governance Institute. All rights reserved. Instructors are permitted to photocopy isolated articles for noncommercial classroom use without fee. For other copying, reprint or republication, permission must be obtained in writing from the association. Please contact Joann Skiba at jskiba@isaca.org. page 16