COBIT Focus Volume 3: July 2012 

COBIT Focus Newsletter

Come join the discussion!Come join the discussion! Marc Vael will be responding to questions in the discussion area of the COBIT (4.1 and earlier)—Use It Effectively topic beginning 23 July 2012.


Why Using Visual Maturity Scoring Is an Added Value for Any Auditor

When one needs to execute a lot of IT audit missions without any proper work programs or guidance available, using COBIT is, at the same time, a gift and a necessity. But in order to send a strong message to the audit committee and executive management, one needs to work with figures instead of words.

COBIT is a universal framework that can be used as a source of inspiration for building a proper IT audit work program. In fact, the process of starting with an audit scope (and out of scope) is key to triggering the COBIT flow; the scope will determine the topic and thus can be linked to one of the four domains of COBIT 4.1 (Plan and Organize [PO], Acquire and Implement [AI], Deliver and Support [DS], and Monitor and Evaluate [ME]) and then to one of the 17 business goals. Then, COBIT kicks in with multiple IT goals (28 in total), each of which is linked to a number of COBIT IT processes. For example, auditing innovation would start by selecting business goal 16 (in the learning and growth perspective) “manage product and business innovation,” which provides three suggested IT goals according to COBIT:

  • 5: Create IT agility.
  • 25: Deliver projects on time and on budget, meeting quality standards.
  • 28: Ensure that IT demonstrates cost-efficient service quality, continuous improvement and readiness for future change.

All three suggested IT goals lead to the following 10 COBIT 4.1 IT processes: PO2, PO4, PO5, PO7, PO8, PO10, AI3, DS6, ME1 and ME4.

At this point the fascinating filtering/consolidation/summarization process starts to get to a practical, homogeneous work program. If one follows and chooses all 10 indicated IT processes with all of their control objectives, the work program would be very large—so large it would consume too much time and resources to execute.

Now, what type of filtering approach can one use to keep the audit project within scope, timing and budget? This is where the funnel logic is relevant to use as a model. When reviewing the 10 selected COBIT 4.1 IT processes, the first step is to note that all four COBIT 4.1 domains are represented in the life cycle of the process1 so that the audit represents all steps in the process. This is the case for this innovation audit, and it is important because the life cycle guarantees the timing dimension in combination with the process maturity at each of the four stages: PO, AI, DS and ME.

Then, one looks at each of the 10 COBIT IT processes with their control objectives and puts them together in a first raw draft work program. At this point, the auditor can add or delete relevant COBIT IT processes with the goal to bring the best value for the available resources; the auditor can then select the main COBIT IT process as the kernel for the audit. If this selection has taken place, the summary document leads to a good first work program. But, as stated, time and budget also play an important role in this process, thus the auditor might need to limit the number of topics to the essentials. The IT Assurance Guide: Using COBIT, which also contains value drivers and risk drivers for each control objective, can help with this. Now the auditor has pared the original list of control objectives to a manageable list for the audit.

This is not the end of using COBIT during the audit process. In fact, during the audit, it becomes obvious that some tests are not relevant or are just missing based on the discussions and information retrieved from the auditees. Thus, the number of topics might increase again in order to have a high-quality audit report that is in line with the expectations from the audit committee. Such added elements impact the list of value and risk drivers, as well as the results. A specific reference must be made to appendix III in COBIT 4.1 so that one does not get confused with the individual process maturity models in COBIT 4.1’s main process materials, which are not directly related to control maturity. And, here again, COBIT provides a maturity process, which can be applied not only to the complete process, but also at the control level. This implies that the score is recalculated to the scale (between 0 and 5), thus creating a maturity-control-level score (and color) for each control.

Not all COBIT controls are equal, and this is especially true by industry and by organization; it may be that one control within an organization is more important than another (or that there is a mitigating control that needs to be factored in). Thus, auditor/management judgment may affect the simple process of adding all scores together for one type and dividing by the relevant number to get an average maturity model score; this might give incorrect results if proper judgment is not used.

In addition to the COBIT maturity model description, figure 1 includes the author’s interpretation of the control maturity enterprise conclusion. This is intended and is useful to make it clear to management and the auditee what these scores actually mean/imply for their organization.

Figure 1

By adding all scores together for one type and dividing by the relevant number, one gets back an average COBIT maturity model score for that particular control objective. And, by adding all control objectives, one gets an average score. By adding all scores together and dividing by the total number, one gets the overall maturity score for that process. This can be easily achieved using Microsoft Excel.

This practical use of maturity scoring also allows for visualization by management and members of the audit committee. At the same time, it provides the auditees with a clear vision of what their control profile looks like (by preference and benchmarked against the expected maturity score of executive management). If the difference is less than one, the perception of control maturity from management corresponds with the reality as verified by internal audit. If the difference is more than one, then one can conclude that the perception from management on the control maturity does not correspond with the reality as audited by internal audit and, thus, needs actions to improve the maturity of controls.

One might argue that this approach is too mathematical or too visual, and that may be correct, but at the same time, it provides for proper discussion about the visualization of a process maturity control.

Is chief audit executive at Smals, a Belgian not-for-profit IT organization with more than 1,800 employees working exclusively for the Belgian Federal Social Security Institutions. Vael has more than 20 years of experience in risk and security management, business continuity management, privacy, outsourcing, and IT audit in private and public enterprises. He is an international vice president of ISACA, and chairman of ISACA’s Knowledge Board and president of the ISACA Belgium Chapter.

Editor’s Note

ISACA suggests the COBIT Assessment Programme developed by ISACA as an alternative approach that readers could consider if process capability assessment is a key objective of an assignment. More mature organizations may wish to consider this alternative approach which is based on ISO/IEC 15504-2 as applied in the new COBIT Process Assessment Model (PAM): Using COBIT 4.1.


1 Under the assumption that an audit needs to cover the full life cycle of the process (plan [PO], build [AI], run [DS] and monitor [ME])


New Publication Extends Information Security Coverage of COBIT 5
By Christos K. Dimitriadis, CISA, CISM, CRISC

Following the launch of COBIT 5 in April 2012, development continued on the creation of the COBIT product family, which includes, in addition to COBIT 5, enabler guides and professional guides to expand the value of COBIT 5 to critical business areas.

ISACA announced the release of the first of the professional guides in June at ISACA’s World Congress: INSIGHTS 2012. Developed by an international team of information security experts, COBIT® 5 for Information Security provides additional value for those who are either responsible for, or interested in, information security. COBIT 5 for Information Security is designed for security professionals and places a security lens over COBIT 5.

On its own, COBIT 5 specifically addresses information security by focusing on an information security management system (ISMS) in the Align, Plan and Organize (APO) management domain (APO13 Manage security), and establishes the prominence of information security within the COBIT 5 process framework. This process highlights the need for enterprise management to plan and establish an appropriate ISMS to support the information security governance principles and security-impacted business objectives resulting from the Evaluate, Direct and Monitor (EDM) governance domain.

COBIT 5 for Information Security extends these views of COBIT 5, further explaining each component of COBIT 5 from an information security perspective. Additional value for information security constituents is created through security-specific explanations, activities, processes and recommendations.

The COBIT 5 for Information Security publication provides detailed guidance on COBIT 5 that information security professionals can use when establishing, implementing and maintaining information security in an enterprise’s business policies, processes and structures. It offers readers guidance and information regarding the enterprise business drivers and benefits related to information security, how to view and apply COBIT 5 principles from an information security professional’s perspective, how to use COBIT 5 enablers to support enterprise governance and management of information security arrangements, and how COBIT 5 for Information Security aligns with other information security standards.

COBIT 5 for Information Security enables those who are already using COBIT 5 to utilize the COBIT 5 content to improve security within their enterprise.

Christos K. Dimitriadis, CISA, CISM, CRISC
Is the head of information security for INTRALOT GROUP, a multinational supplier of integrated gaming and transaction processing systems based in Greece, managing information security in more than 50 countries on all continents. He also is international vice president of ISACA and chair of the COBIT Security Task Force.


Come join the discussion!Come join the discussion! Andrew Stekhoven will be responding to questions in the discussion area of the COBIT 5—Use It Effectively topic beginning 23 July 2012.


Active Software Escrow’s Usefulness for Companies Embracing COBIT 5
By Andrew Stekhoven

IT governance is integral to the success of overall enterprise governance because it integrates and institutionalises optimal ways of planning and organising, acquiring and implementing, delivering and supporting, and monitoring and evaluating the IT function and its performance.

The latest edition of ISACA’s globally accepted framework, COBIT 5, provides an end-to-end business view of governance and management of enterprise IT (GEIT) that reflects the central role of information and technology in creating value for enterprises. The principles, practices, analytical tools and models found in COBIT 5 embody thought leadership and guidance from business, IT and governance experts around the world.

As in previous editions of COBIT, COBIT 5 contains several references to software escrow. Software escrow (specifically, active software escrow) has been described by Gartner as a smart and effective way for software licensees—that is, all businesses and organisations utilising IT—to protect their mission-critical applications in an ever-changing environment.

‘[Software escrow] is an insurance policy to make sure you have access to that source code should that vendor no longer maintain that software for your organization, so [it] gives you an alternative.’1

This article defines active escrow, highlights its benefits for user organisations as well as software developers, and explains where and how active software escrow underpins COBIT 5 objectives using three examples.

Defining Active Software Escrow

IT systems and software products are never bug-free, complete or static in their development cycle. For there to be any form of maintenance and/or development of the software (that is, business continuity in respect to the vital business process or function that it supports), there has to be access to the source code of that mission-critical software.

Active software escrow is a legally binding agreement signed between the user of the IT system, the supplier of the IT system and an independent escrow service provider to ensure that the software source code and technical documentation related to the services provided are not only kept safe, but are also professionally verified and updated on a routine basis. If certain conditions mentioned in the agreement come to pass, the escrow agent releases the source code and any other technology or documentation mentioned in the agreement to the user company.

In an active software escrow agreement:

  • The supplier deposits its intellectual property with the escrow agent (the neutral and independent trusted third party) for the future, conditional benefit of the user company in the event of a trigger condition as defined in the escrow agreement
  • The escrow agent verifies and holds the deposited material in escrow
  • Under specific conditions as set out in the escrow agreement, the escrow agent is authorised to release the material to the user company, specifically for the purposes of the user company’s business continuity

The Benefits of Active Software Escrow

For many medium-sized and large user companies, the business case for active software escrow is excellent, considering:

  • The value of their business processes and revenue streams that are dependent upon the software platforms concerned
  • The value of the investments they have made in, for example, the software product, the implementation project, training, support and maintenance
  • The magnitude of reputational, consequential and other damage in the event of business disruption due to mission-critical IT system failure
For the larger software or IT system developer, active software escrow:
  • Reinforces ownership rights in the source code, which typically are the most valuable asset, by providing the developer company with documentation when securing a patent claim, significant assistance in an infringement suit and robust proof to support an intellectual property copyright claim
  • Mitigates the permanent loss of critical source code and related technical documentation, as having the most valued asset in escrow with a neutral third party provides an alternative to disaster in the event of an emergency
  • Reduces dependency on key employees who may hoard instead of share information
For the small and medium-sized enterprise (SME) or software developer, software escrow:
  • Could open new markets by providing potential customers with security (smaller information and communications technology [ICT] suppliers are often precluded from tendering for major projects despite their expertise and intellectual property because the contracting organisation believes it is less risky to deal with large, established firms)
  • Ensures business continuity should those with whom the intellectual property resides leave the company or are unable to fulfil their work obligations because of illness or death

Active Software Escrow Can Support Effective Implementation of COBIT 5 Guidance

Current protocols such as COBIT and King III recognise that IT has become an integral part of doing business today—it is fundamental to the support, sustainability and growth of organisations.

Developing an understanding of COBIT 5 and how it can be leveraged to lead IT organisations and mitigate IT-related risk is an advantage that any chief information officer (CIO) can acquire. Doing so will establish credibility with external auditors, the audit committee, shareholders and executive management. And, knowing where to utilise active software escrow can assist the CIO in implementing COBIT 5 guidance effectively.

The following are three instances where active software escrow underpins COBIT 5.

Instance 1: APO10.04 Manage Supplier Risk
APO10.04 Manage supplier risk in the COBIT 5 process reference guide states that the organisation must ‘identify, monitor and, where appropriate, manage risk relating to the supplier’s ability to deliver service efficiently, effectively, securely, reliably and continually.’

Partnering with a professional active software escrow service provider can assist the organisation in meeting these requirements. Based on industry best practice, it can:

  • Define the contract to provide for potential service risk by clearly defining service requirements
  • Consider alternative suppliers or standby agreements to mitigate possible supplier failure
  • Address the security and protection of intellectual property (IP)
  • Take into account any legal or regulatory requirements within the country in which the organisation and the supplier company are trading

By ensuring that business-critical assets are held in escrow, the user company is protected in the event that a key supplier cannot meet its contractual obligations. Upon failure, materials can be released to the user organisation safely, minimising disruption, time and cost. Ultimately, escrow is a smart, simple way of managing risk and demonstrating holistic corporate governance.

For example, Fedict, the Belgian Federal State Service for Information and Communication Technology, elected to utilise active software escrow to secure, in all circumstances, the use of the software it utilises to deliver e-government services.

Fedict’s software applications, as well as those developed by Fedict for other federal government services, are ultimately essential applications, the use of which must be guaranteed in all circumstances. Escrow service is just one of the measures taken within a global framework to ensure continuity of these IT services.

In terms of the Fedict agreement, the escrow agent acts as a neutral, independent third party that, in certain circumstances, would release the latest version of licensed software held in escrow to Fedict so that its continued use of the software is guaranteed.

Currently, all software suppliers to the Belgian federal government are subject to this escrow arrangement—they cannot do business with Fedict unless a complete set of source code, with the relevant technical documentation, has been lodged in escrow nominating Fedict as the legally entitled escrow beneficiary.

In this way, Fedict is able to guarantee the continuity of its technology dependent services to its stakeholders: the taxpaying public.

Instance 2: DSS04.07 Manage Backup Arrangements
DSS04.07 Manage backup arrangements in the COBIT 5 process reference guide requires that the organisation to ensure availability of business-critical information—that systems, applications, data and documentation maintained or processed by third parties are adequately backed up or otherwise secured. COBIT 5 states: ‘Consider escrow or deposit arrangements.’

Once again, active software escrow is a simple solution for companies seeking to comply with COBIT 5, as opposed to passive escrow or untested escrow deposits. The latter are often useless when called upon to deliver business continuity in the face of the supplier’s inability to continue supporting its technology.

The passive approach to escrow or intellectual property custodianship involves passive custodians (such as banks, notaries and legal firms) physically holding a copy of the software, source code and documentation, but these custodians do not warrant that they are the correct or up-to-date versions.

With active software escrow, the escrow agent verifies the property held at least once a year to warrant that the deposit contains what the supplier has committed to lodge. This provides proper reassurance that the material on deposit is up to date and usable.

Research has highlighted that as many as nine out of 10 unverified source code deposits held in escrow are useless and, therefore, unable to provide for a business’s continuity should its software partner no longer be in a position to continue supporting the systems it has provided.2

For example, one professional escrow agent offers three levels of technical verification and reporting depending on how mission-critical the client considers the business application to be:

  1. Basic technical integrity test—Ensures that the deposited media are readable and contain those elements agreed upon in the escrow agreement
  2. Detailed technical integrity test—Includes level 1 plus an analysis of the user environment to ensure that deposited media contain source code of the software used in the operational software environment
  3. Full technical integrity test—Includes level 1 and 2 plus full compilation of software, including representative testing of compiled object code in a comparable hardware environment, to fully ensure that the media contain every element required within the operational environment

The following example highlights why COBIT 5’s insistence on verification is so important. A few years ago, the Lorenzo patient record system at the heart of Britain’s £10 billion (US $25 billion) National Health Service IT upgrade was exposed as foilware. According to an article in The Australian, the Lorenzo system was initially scheduled for release in March 2004, but there had been a series of delays and no British hospital trust was using the new software being developed by iSoft in Europe.

iSoft Australia was at the time supplying the same product for various state health projects, including Victoria’s Aus $323 million HealthSmart. There the latest delivery date was 2008, but a review found the date to be far too optimistic.

David More, an independent consultant and e-health blogger, wrote, ‘New South Wales Health should not rely on its passive escrow arrangements with iSoft to protect the rollout of patient administration systems. There is no point holding obsolete software code in escrow. All that does is provide a false sense of security.’3

Instance 3: APO10.02 Select Suppliers
APO10.02 Select suppliers in the COBIT 5 process reference guide requires the user company to select suppliers according to a fair and formal practice to ensure a viable best fit based on specified requirements. Requirements should be optimised with input from potential suppliers. In the specific case of software acquisition, the rights and obligations of all parties should be included and enforced in the contract terms.

Active software escrow ensures the rights of all parties are enforced, as required by COBIT 5.

In one example, a South African fund manager (‘Manco’) with more than R200 billion funds under management demonstrated the value of active software escrow when aligning its risk strategies to COBIT. Manco selected SoftwareX as its preferred IT system based on best features and total cost of ownership considerations. SoftwareX was also the IP of a small and financially challenged company, which was in negotiations to sell.

Manco concluded its agreement and implemented SoftwareX. At the same time, its developer was acquired by the listed company with which it had been negotiating. Within nine months, the listed entity decided to discontinue providing support and maintenance of SoftwareX. Manco cried foul and insisted the listed entity was in breach of contract. The listed entity disagreed.

Fortunately, Manco had insisted on an escrow agreement as part of the selection criteria process and exercised its right to maintain and support SoftwareX solely for purposes of business continuity. The escrow service provider was, therefore, required to release the source code and all supporting documents to Manco.

As a result of the escrow agreement, Manco satisfied its operational risk management and good governance imperatives, achieved the return on investment it was looking for when it implemented SoftwareX, and was able to switch to a new system on its own terms and within its own time frame.


Active software escrow can meet many of the concerns about business continuity addressed in COBIT 5, including:

  • Disaster recovery—Permanent loss of critical information is not an option. Having the organisation’s most valued asset in escrow with a neutral third party provides the organisation with an alternative to disaster in the event of an emergency. The active escrow agent maintains a copy of the intellectual property stored off-site in a professional vaulting facility and available for restoration.
  • Reduced dependency on key employees—30-day escrow deposit cycles can ensure proper delivery according to functional specification and agreed-upon deliverables (including documentation) when independent technical verification is performed on each deposit as a matter of course.
  • Quality deposits—Verification services provide assurance to an organisation’s clients that all source-code deposits meet a superior technical standard.
  • Verification—On request, most escrow agents can provide extended verification services. Compilation is included in the analysis and testing of the deposit; it verifies that the deposit is readable, correct and complete in all respects. This testing warrants that the escrow deposit will be useable if released.

Andrew Stekhoven
Is managing director of Escrow Europe (Pty) Ltd. During the last 25 years, he has been engaged in a broad cross-section of executive roles within the ICT industry. Stekhoven has been a member of the Institute of Directors in South Africa (IoD) for 15 years. Since its inception in 2004, Stekhoven has established Escrow Europe as the leading active escrow company in South Africa and is closely involved in the promotion of ICT good governance practices and the convergence of international protocols, such as COBIT, with the local King recommendations for corporate governance. Escrow Europe has also been featured by Microsoft Inc. as one of only seven internationally recognised escrow service providers for their CfMD (Certified for Microsoft Dynamics) Partner Programme (the only one on the African continent) and is the only escrow service provider in Africa to be ISO 9001:2008 certified.


1 Bona, Alexa and Younker, Edward, ‘Management Update: How to Protect Yourself If Your Software Vendor is Acquired,’ Gartner Inc. Research Products G00123815, September 8, 2004. And Disbrow, J. and Park, A., ‘Be Aware of Contract Issues When Negotiating Software Escrows,’ Gartner Inc. Research Note G00125669, February 7, 2005 as part of Iron Mountain white paper, Best Practices: Technology Escrow—Who’s Using It and Why?,
2 Escrow Europe, Review of Verification: 2003. For a copy of the full report, contact Escrow Europe on
3 More, David; Australian Health Information Technology,,


ISACA’s CCC Provides Valuable COBIT 4.1 Implementation Support for Users
By Robert Payne, CGEIT

The COBIT Controls Collaboration (CCC) environment is a platform that supports COBIT 4.1 practitioners in their practical application of the various control objectives and control practices. In CCC, users can interact by exchanging thoughts, queries and solutions based on their practical experiences in applying COBIT’s control objectives and control practices. The community environment is structured around the COBIT 4.1 processes, control objectives and control practices.

CCC Development

ISACA constituents had long been asking for increased practical guidance on best practices for the implementation and ongoing use of COBIT. COBIT 4.1 users in particular indicated that they needed more practical, control-related guidance once having digested the framework. Implementing the control objectives and practices in real life has been a struggle for many COBIT users, and CCC provides the much-needed support and platform for them to fully realize the value of COBIT. In the CCC platform, COBIT users can collaborate to support each other.

This platform is intended to address the needs of COBIT users who seek information related to using COBIT in either a very specific or targeted way. For example, a user might want to discuss managing security (DS5 in COBIT 4.1), but wants to restrict the conversation to environments in which the underlying system is an AS/400 used in the insurance industry. To use CCC for this purpose, the practitioner must log in to the CCC and navigate to DS5, where he/she can start a new discussion describing the specific AS/400 issue in the insurance industry. Users with knowledge and familiarity with this topic will then respond to the initiated discussion.

Users may initiate and participate in discussions related to specific COBIT topics and can further define them by geography, system or industry as appropriate.

Benefits of the CCC Environment

Intended for IT practitioners, the CCC environment provides a structure for users to collaborate, learn and share their experiences on various thread topics specific to COBIT 4.1 control objectives and practices. Participants also have the ability to:

  • Create more specific threads as their needs dictate
  • Exchange knowledge about specific control objectives and good practices
  • Learn how COBIT 4.1 control objectives and related practices apply to specific situations across different industries, geographies or technologies
  • Enhance the benefits gained from using COBIT 4.1

The CCC environment, part of the ISACA Knowledge Center, is available to all COBIT users to browse and view discussions related to COBIT 4.1 control objectives and practices. It is also available to ISACA members who use COBIT and want to gain value by collaborating with fellow professionals on the use of COBIT content in practical situations.

To get started, visit the COBIT 4.1 Controls Collaboration page of the ISACA web site.

Robert Payne, CGEIT
Is the principal consultant at Lode Star Strategy Consulting, a consulting entity specialising in corporate and IT strategy, IT governance, strategic IT management and performance management. Immediately prior, he was the chief information officer at Trencor Services (Pty) Ltd. He was a founding member of the South African COBIT Development Group and participated with ISACA in the development of COBIT 4.0, COBIT 4.1 and COBIT 5.


Come join the discussion!Come join the discussion! Francisco Herrera Hernandez and Manuel Vargas Roldan will be responding to questions in the discussion area of the COBIT (4.1 and earlier)—Use It Effectively topic beginning 23 July 2012.


Read this article in SpanishImplementation of COBIT 4.0 in Scotiabank, Costa Rica
By Francisco Herrera Hernandez and Manuel Vargas Roldan

Scotiabank, known as BNS (Bank of Nova Scotia), is one of the five largest banks in Canada. In existence for more than 178 years and with a presence in more than 50 countries, it has an international network of branches and offices in Latin America, Canada, the US, the Caribbean, Europe, Asia and the Pacific.

At BNS, the COBIT 4.0 implementation project began with an international survey of the bank’s IT department directors to find out whether any of them apply a standard that involves having processes based on COBIT, in any of its versions, on a mandatory basis. As a result, a large number of "Scotiabankers" were found to have ISACA certifications, but no other branches had regulations similar to those in Costa Rica, such as the legislation SUGEF 14-091 approved by the National Counsel to Supervise the Financial System of Costa Rica (SUGEF, in Spanish), nor are any other branches subject to similar guidelines or directives such as those established for banks in Costa Rica in the IT management regulation included in SUGEF 14-09.


SUGEF approved the IT management regulation applicable to all banking and financial entities in the country starting in 2009 and establishing as mandatory implementing the 34 COBIT 4.0 processes and reaching the third level of maturity for each identified COBIT process within three years.

Compliance with these regulations is met through the execution of independent external audits, led by a CISA-certified professional, and framed in the external audit guidelines2 and professional and ethical criteria3 provided by ISACA, applying on a mandatory basis the S7 IT Audit and Assurance Standard4 and the G20 IT Audit and Assurance Guideline.5

Corporate Decision

As the culture of control is one of BNS’s principles, IT is supported by existing channels to disburse the controls implemented based on the use of web services and those in the compliance unit (the unit responsible for verification of compliance with external regulations) for IT regulatory issues. One of the critical success factors in the implementation of good IT governance was to use the current organizational structure to plan, organize, direct, coordinate, monitor, and make appropriate and timely decisions to gain from the advantages, benefits and opportunities derived from its use. This allowed the compliance unit to become the only authorized channel to receive and deliver requirements from auditors, whether internal or external.

Although the full responsibility for good IT governance falls by definition on the board of directors, duties are delegated to the different units of the bank—the control, evaluation and account performance of which follow the outline of authority and responsibility that is current within the bank.

Facing the Challenge

To face the challenge of implementing mandatory processes following the terms and conditions established by the local regulator, in this case SUGEF, BNS designed a route plan (a plan designed to achieve compliance as quickly as possible with the COBIT 4.0 control objectives) for the prioritization of measures to follow to successfully meet the requirements. The plan considered, first, the involvement of the IT committee with the active participation of upper management and the main bank executives.

Next, adequate implementation of the controls was verified using existing documents and taking on the task of upgrading, referencing and making the necessary standardizations to meet the detailed controls and requirements of the COBIT levels of maturity required by SUGEF for each of the processes. Two employees were assigned on a full-time basis to the project to ensure the continuity and follow-up of the route plan.

Implementation Strategy

The implementation strategy clearly defined the general and specific objectives, which would allow the IT team to meet the objectives effectively, efficiently and economically, and to guarantee the availability of the resources required according to the scheduled tasks, the assignment of personnel committed and capable of executing the tasks assigned with excellence, and the active permanent pursuit of the progress of the project by the IT committee.

In its first phase, the plan analyzed 17 processes that required reaching maturity levels 2 or 3, as appropriate for the selected process.6 The following processes were included: PO1, PO3, PO5, PO9, PO10, AI3, AI5, AI6, DS2, DS3, DS4, DS5, DS9, DS10, DS11, DS12 and ME2. In the second phase of implementation, the remaining 17 processes that should reach maturity level 1 were analyzed to gradually reach maturity level 3 in a maximum of three years, starting in 2010.

Within the process, training in COBIT and good governance of IT, which focused on strengthening the knowledge of personnel participating in implementation, were included.

Results Obtained

The benefits BNS received from using the conceptual framework from COBIT 4.0 include:

  • Stronger alignment among business and IT strategies through the coherence of domains and COBIT processes
  • Creation of defined processes with internationally accepted, auditable and measurable structures that integrate the best practices in the banking industry
  • Identification of key controls that should be strengthened and implemented to ensure adequate internal IT control
  • Better and more reliable processes that strengthen the application of practices related to management of the five elements of control that constitute good IT governance

Lessons Learned

This first experience related to the simultaneous implementation of various high-level processes, many of which are extremely complex and detailed, as well as to the need to create conditions that would yield the expected benefits. It required a significant effort by the institution, but with excellent results.

The effort has been substantial economically as well as in the amount of time dedicated by BNS’s process leaders—the demanding and continuous follow-up, monitoring and control, and the constant involvement of the entire organization, the board of directors, the administration, the managers and the IT department.

Despite the difficulties and the risk involved in the execution of a project of these dimensions, the strategy proposed with anticipation, the follow-up, and the timely and appropriate decisions made to once again follow the course have yielded the expected results, which, while they have just begun to emerge, are sure to create a more competitive, agile bank with strengthened processes, a greater focus on business and an enviable technological culture.

Manuel Vargas Roldan, CISM, CGEIT
With more than 29 years of experience in IT, is the senior manager of information security and IT compliance at BNS. He can be contacted at

Francisco Herrera Hernandez, CGEIT
With more than 35 years of IT experience, is international IT director at BNS. He can be contacted at


1 National Council for Supervision of the Financial System of Costa Rica, SUGEF 14-09, published in La Gaceta, no. 50, San Jose, Costa Rica, 12 March 2009,
2 ISACA, IT Audit and Assurance Standard, Guidelines, Tools and Techniques,
3 ISACA, Code of Professional Ethics,
4 ISACA, S7 Reporting, IT Audit and Assurance Standards,
5 ISACA, G20 Reporting, IT Audit and Assurance Guidelines,
6 Op cit, National Council for Supervision of the Financial System of Costa Rica (SUGEF)


Framework Committee

Steven A. Babb, CGEIT, CRISC, UK, chair
Charles Betz, USA
David Cau, ITIL, MSP, Prince2, France
Sushil Chatterji, CGEIT, Singapore
Frank Cindrich, CGEIT, CIPP, CIPP/G, USA
Jimmy Heschl, CISA, CISM, CGEIT, ITIL, Austria
Anthony P. Noble, CISA, USA
Andre Pitkowski, CGEIT, CRISC, OCTAVE, Brazil
Paras Shah, CISA, CGEIT, CRISC, CA, Australia

Editorial Content

Comments regarding the editorial content may be directed to Jennifer Hajigeorgiou, senior editorial manager, at

COBIT Focus is published by ISACA. Opinions expressed in COBIT Focus represent the views of the authors. They may differ from policies and official statements of ISACA and its 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.

© 2012 ISACA. 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 Julia Fullerton at

COBIT Focus Newsletter