COBIT Focus Volume 1: January 2014 

COBIT Focus Newsletter

Come join the discussionCome join the discussion! Abbas K will respond to questions in the discussion area of the COBIT 5—Use It Effectively topic beginning 24 January 2014.


Middle East Bank Improves Information Security
By Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO, PRINCE2

As a result of its initiative to improve information security with the help of COBIT, a Middle East bank realized several benefits, including:

  • Improved integration of information security within the organization
  • Informed risk decisions and risk awareness
  • Improved prevention, detection and recovery
  • Reduced (impact of) information security incidents
  • Enhanced support for innovation and competitiveness
  • Improved management of costs related to the information security function
  • Better understanding of information security

Obtaining buy-in from senior management is a common complaint among information security professionals. However, at one Middle East bank in Kuwait, the information security manager did not have that problem when implementing COBIT to define the enterprise’s information security principles because senior management at the bank was already well aware of the industry-accepted framework. As a result, his assessment report was quickly completed, quickly accepted and greatly appreciated.

The organization uses many standards and frameworks, including ISO 27001, the Payment Card Industry Data Security Standard (PCI DSS) and the IT Infrastructure Library (ITIL), and wanted to align its department processes and principles with a common framework that is highly flexible and adaptable, and has controls and processes in common with other industry frameworks. The organization found this in COBIT, which in its latest edition—COBIT 5—offers detailed mapping with other frameworks including International Organization for Standardization (ISO) standards, The Open Group Architecture Framework (TOGAF) and the Project Management Body of Knowledge (PMBOK).

No other framework provides such detailed mapping with various, industry-accepted standards. The bank has used COBIT 5 and COBIT 5 for Information Security for a number of projects:

  • COBIT 5 Tool Kit was used to identify the statement of applicability (SOA) for each domain, along with the corresponding 37 processes and 210 practice statements.
  • The COBIT 5 principles have been mapped to the information security department’s current processes with an objective to identify any potential gaps. (See the Supporting Evidence column in figure 1 for results of the mapping.)
  • All gaps identified in the assessment were addressed based on recommended guidelines for each of the practice statements.

Information Security Principles

As outlined in COBIT 5 for Information Security, information security principles communicate the rules of the enterprise in support of the governance objectives and enterprise values, as defined by the board and executive management. These principles need to be:

  • Limited in number
  • Expressed in simple language and state, as clearly as possible, the core values of the enterprise

These principles (figure 1) are generic and applicable to all enterprises and can be used as a basis for developing information security principles unique to the enterprise.

Figure 1

Benefits of COBIT 5 Implementation

The bank achieved its goals in a short time—just three months—improving a number of processes, including:

  • Ensure governance framework setting and maintenance
  • Ensure benefits delivery
  • Ensure risk optimization
  • Ensure resource optimization
  • Ensure stakeholder transparency
  • Manage the IT management framework
  • Manage strategy
  • Manage enterprise architecture
  • Manage innovation
  • Manage requirements definition
  • Manage assets
  • Manage continuity


The bank plans to continue using this assessment framework on an annual basis and as other projects warrant it. The latest version of COBIT is easy to understand and implement, particularly the tool kit, which provides all the required information needed to use COBIT within the organization.

Abbas K, CISA, CISM, CGEIT, COBIT 5 (Foundation), CEH, C|CISO, PRINCE2
Has more than 14 years of experience with cross-functional sectors of information security and information risk. He is the manager of information security at a leading regional bank in the Middle East. Previously, he has worked with Ernst & Young and KPMG. He is well versed in IT standards and frameworks, such as COBIT, ISO 27001, PCI DSS, TOGAF and ITIL.


Come join the discussionCome join the discussion! Vishal Salvi and Avinash Kadam will respond to questions in the discussion area of the COBIT 5—Use It Effectively topic beginning 24 January 2014.


Information Security Management at HDFC Bank: Contribution of Seven Enablers
By Vishal Salvi, CISM, and Avinash W. Kadam, CISA, CISM, CGEIT, CRISC, CBCP, CISSP, CSSLP

HDFC Bank was incorporated in August 1994 and has a nationwide network of 3,062 branches and 10,743 automated teller machines (ATMs) in 1,568 Indian towns and cities.

HDFC Bank operates in a highly automated environment in terms of IT and communication systems. All of the bank’s branches have online connectivity, which enables the bank to offer speedy funds transfer facilities to its customers. Multi-branch access is also provided to retail customers through the branch network and ATMs.

The bank has prioritised its engagement in technology and the Internet as one of its key goals and has made significant progress in web-enabling its core businesses. In each of its businesses, the bank has succeeded in leveraging its market position, expertise and technology to create a competitive advantage and to build market share.

Use of COBIT

As an early adopter of COBIT 4.1, HDFC Bank’s IT governance journey started almost six years ago, when COBIT 4.1 was just introduced. Almost all of the 34 IT processes defined in COBIT 4.1 were adopted by the bank.

Following COBIT 5’s introduction in April 2012, HDFC Bank took some time to consider a migration. Because the bank has successfully implemented COBIT 4.1 to great benefit, it will not immediately migrate to COBIT 5. However, the seven enablers introduced by COBIT 5 were intuitively adopted by HDFC Bank even before these were popularised in COBIT 5.

COBIT 5 describes seven enablers, which are factors that, individually and collectively, influence whether something will work—in this case, governance and management of enterprise IT (GEIT):

  1. Principles, policies and frameworks are the vehicles to translate a desired behaviour into practical guidance for day-to-day management.
  2. Processes describe an organised set of practices and activities to achieve certain objectives and produce a set of outputs in support of achieving overall IT-related goals.
  3. Organisational structures are the key decision-making entities in an enterprise.
  4. Culture, ethics and behaviour of individuals and the enterprise are often underestimated as a success factor in governance and management activities.
  5. Information is pervasive throughout any organisation and includes all information produced and used by the enterprise. Information is required for keeping the organisation running and well governed, but at the operational level, information is often the key product of the enterprise.
  6. Services, infrastructure and applications include the infrastructure, technology and applications that provide the enterprise with IT processing and services.
  7. People, skills and competencies are linked to people and are required for successful completion of all activities and for making correct decisions and taking corrective actions.

Organisational Structures

Organisational structures are the key decision-making entities in an enterprise.

Information security at HDFC Bank is driven by its information security group (ISG). The group is headed by the chief information security officer (CISO), who reports to the executive director of the bank. The ISG is primarily responsible for identifying, assessing and proposing mitigation for every information-security-related risk. This responsibility is carried out by interacting with various committees and stakeholders and preparing plans, proposals, policies, procedures and guidelines.

The implementation of these is assigned to the implementation teams across the bank.

The governance framework at HDFC Bank is driven by a number of top-level committees (figure 1). The importance given to information security is evident from the number of top-level committees that have information security on their agenda.

Figure 1

Roles and responsibilities for the ISG have been well defined through a RACI chart (figure 2). One of the main points to be noted is that, although the responsibility for information security management is with the ISG, the accountability is squarely with the function heads. Similarly, although the ISG is accountable for the risk assessment definition, function heads are accountable for risk assessment execution. This segregation of responsibility and accountability creates ownership of risk mitigation and information security management with the function heads.

Figure 2

The overall framework for governance to implementation is provided in figure 3.

Figure 3

The 21 components are constantly monitored for maturity level. The assignment of work to the ISG team members is based on these controls.

Principles, Policies and Frameworks

Principles, policies and frameworks are the vehicles to translate the desired behaviour into practical guidance for day-to-day management.

HDFC Bank has created a comprehensive policy document of around 100 pages. The current version is 3.x, and it is being revised to version 4.0. This document covers the 11 information security domains as specified in ISO 27001 in a platform- and technology-agnostic manner. It is modeled on Information Security Forum (ISF)’s Standard of Good Practices.

Because the bank uses 30 to 40 different technologies, there are more detailed policies created for each technology. These are fine-grained technology-specific policies for reference by the technical team responsible for implementing these technologies.

These policies are further subdivided into records for mapping against various authoritative standards/frameworks, such as ISO 27001, COBIT and Reserve Bank of India (RBI) guidelines. These records are input into a governance, risk and compliance (GRC) tool that provides the bank’s internal unified control framework (UCF). This helps to identify, in an automated fashion, the compliance level achieved. The tool provides almost 40 authoritative sources that are already mapped through the UCF. Thus, compliance with any source can be easily found.

The ISG team uses the Factored Analysis of Information Risk (FAIR) methodology for computing probable risk by capturing threat event frequency and loss event frequency, giving appropriate weight to each factor, and deriving the risk rankings for prioritising and decision making. The ISG team also reviewed ISO 27005 and created a sound approach to risk management with the help of these standards.

A short version of the policy document has been created as a 20-page user guide supported by a list of top 10 rules for information security.

There are a number of vendors providing services to HDFC Bank. The supply chain security is assured by regular third-party reviews of vendors, which are performed by external audit firms.

HDFC Bank is certified for ISO 27001 and BS 25999, is planning to achieve the ISO 22301 certificate, and has achieved 92 percent compliance with the RBI guidelines.

The ISG team is currently focused on creating a sound incident management system; providing adequate data protection; ensuring appropriate implementation of bring your own device (BYOD); and detecting, containing and removing advanced persistent threats in a timely fashion.


Figure 4Processes describe an organised set of practices and activities to achieve certain objectives and produce a set of outputs in support of achieving overall IT-related goals. The ISG follows an information security process model based on 21 components:

  1. Application security
  2. Cryptography
  3. Monitoring
  4. Incident management
  5. Online banking security
  6. Malware management
  7. Data protection
  8. Secure software development life cycle
  9. Vendor (third-party) management
  10. Business continuity planning
  11. Privacy
  12. Identity and access management
  13. Risk management
  14. Physical security
  15. Awareness
  16. Governance
  17. Policy
  18. Asset life cycle management
  19. Accountability and ownership
  20. System configuration
  21. Network security

The information security planning, designing, deployment and monitoring is done for these individual components. This approach keeps the teams focused. The policies, procedure, guidelines, standards, technologies and tools are built for these components. This approach provides granularity in managing each focus area and also leads to defense-in-depth architecture.

Each of the components contributes to building the control standards and control procedures that satisfy high-level policy requirements. This is a bottom-up approach that serves to mitigate the top-level security concerns for business processes by providing adequate security for the assets used by these processes.

The work of mapping all business processes with assets is currently being carried out. The business processes are being ranked based on the criticality and impact they may have on the business. If one asset, e.g., a server, is hosting multiple IT processes supporting multiple business processes, it gets the ranking attributed to the most critical business process.

The approach followed by the HDFC Bank ISG is closely aligned with COBIT 5’s goals cascade (figure 4).

Stakeholder drivers identified by HDFC Bank are shown in figure 5.

Figure 5

Information Security Maturity Levels

ISG has developed an information security maturity model. The model has defined five levels of maturity as shown in figure 6.

Figure 6

ISG has defined eight desirable attributes for information security components. These are listed in column 1. Requirements for achieving each level for an attribute have been defined in the subsequent columns. For example, the policy attribute is at level 1 if there is no policy defined for a particular component, and it is at level 5, i.e., optimised, if there is continuous review and improvement of the policy.

Tracking of each of the 21 components is based on this model. The maturity model has been successfully used by HDFC Bank to build a sense of benchmarking within the organisation. It helps in finding areas for improvement. These evaluation exercises are done in a workshop mode. There is a healthy two-way communication leading to a sense of participation and clarity about the strategy and vision of the enterprise. The model is strictly used for internal gap analysis and for identifying areas for improvement. It is not meant for use to provide assurance to a third party.

The above maturity model was created by the ISG to meet its unique needs for defining specific improvement plans. This maturity model is loosely based on the maturity model defined in COBIT 4.1. One of the criticisms of the COBIT 4.1 maturity model was that the criteria for levels are subjective. HDFC Bank is now considering mapping the current processes with the COBIT 5 Process Assessment Model (PAM), which is based on ISO 15504.

Services, Infrastructure and Applications

Services, infrastructure and applications include the infrastructure, technology and applications that provide the enterprise with IT processing and services.

HDFC Bank uses almost 40 different technologies. Various services, infrastructure and applications are built around these technologies. As described under the processes enabler, each of these services is mapped to the information security maturity level. A continuous updating of the maturity level against attributes such as automation, effectiveness, incident management and measurement ensures that these services are monitored very closely. All projects for improvement of the services are based on the maturity level aimed at the particular service.


Information is pervasive throughout any organisation and includes all information produced and used by the enterprise. Information is required for keeping the organisation running and well governed, but at the operational level, information is often the key product of the enterprise.

Reliable information for security management is a key factor. Information in terms of strategy, budget, plan and policies is regularly presented through board papers. Information security requirements are captured through a risk acceptance form (RAF) and are reviewed at the information security risk management committee (ISRMC). The ISG also prepares various information security review reports, including audit findings, maturity reports, threat analyses, vulnerability assessment reports, information risk registers, breaches and loss reports, and information security incident and problem reports.

The maturity model provides additional inputs for good quality information. Various information security metrics and measurements have been created based on the ISO 27004 framework and are presented as a dashboard. Currently, work is in progress to implement an IT GRC tool to capture all the information at the source and demonstrate compliance against numerous requirements, including RBI guidelines, PCI DSS and Basel II. The tool also provides mapping of various controls from COBIT 4.1.

People, Skills and Competencies

People, skills and competencies are linked to people and are required for successful completion of all activities, for making correct decisions and taking corrective actions.

HDFC Bank has deployed a number of techniques to create awareness about security and to build appropriate skills and competencies. Following is a list of some of the initiatives:

  • Information security movie—A 20-minute movie was created and presented with all the trappings of a real movie theatre experience (e.g., tickets, popcorn). The movie has proven extremely popular, and so far 40,000 employees have seen it. Every training programme begins with this movie.
  • Information security cartoon strip—A cartoon strip was created with two characters, one named Sloppy and the other Sly. Their exploits entertain the readers and also carry a very powerful security message. This cartoon strip is now planned to be printed in a calendar format.
  • Security net—The security net (an intranet) houses all relevant material, such as policies, standards, guidelines, contact lists, business continuity plans and approach notes.
  • Email and picture campaign—Regular emails are sent cautioning everyone about being alert, e.g., a reminder about avoiding phishing emails is sent after any successful phishing attempt.
  • Ten security commandments—The user policy document has been summarised into key information security rules that are easy to read and remember (figure 7).
    Figure 7
  • Security First course—All employees have to undertake this one-hour course every two years. Taking the examination and obtaining passing marks is mandatory. A certificate is issued to all successful candidates. The certificate acts as an official recognition. Apart from the certificate, the star performers are also recognized through global mailers sent to all the bank’s employees as well as monetary rewards.
  • One-day workshop—A one-day workshop is conducted periodically for senior management at which the CISO explains the importance of information security for the bank and the specific measures deployed for its implementation.

Culture, Ethics and Behaviour

Culture, ethics and behaviour of individuals and the enterprise are often underestimated as a success factor in governance and management activities. Nonetheless, they are important contributors to the success of an enterprise.

COBIT 5 has identified eight types of behaviours that contribute to building security culture in an organisation. Various initiatives taken by HDFC Bank have led to creating the right type of security behaviours. HDFC Bank has used multiple channels of communication, enforcement, clear policies, rules and norms. Secure behaviour is also encouraged through recognition, e.g., a security certificate, and strong messages to defaulters. Secure behaviour is strongly influenced through raising awareness.

The eight types of behaviour are reproduced here for reference along with the specific measures adopted by HDFC Bank to embed these behaviours into the daily practice of bank employees:

  • Information security is practiced in daily operations. HDFC Bank management has conveyed its expectations of employees by stressing the principle of zero tolerance for unacceptable behaviour relating to information security, rewarding good behaviour, recognising and rewarding people for good work towards risk management, and constantly reminding everyone through the tagline “Security is incomplete without U.” This has ensured that information security is practiced in daily operation.
  • People respect the importance of information security policies and principles. The security culture has been built over time through constant efforts in creating awareness. Employees now understand the importance of information security and take security initiatives seriously. Audit has also played an important role in enforcing various security policies and principles.
  • People are provided with sufficient and detailed information security guidance and are encouraged to participate in and challenge the current information security situation. HDFC Bank believes in engaging all stakeholders in the security effort. Introduction of any new process involves ensuring open interaction with all the affected parties. The issues are discussed in workshops and buy-in is achieved through two-way dialogue—allowing everyone to clarify any doubts they may have. Extensive training is provided for every new information security initiative, not only to the information security group but to all stakeholders.
  • Everyone is accountable for the protection of information within the enterprise. The information security group is responsible for identifying and managing the risk whereas the business heads are held ultimately accountable. This has been clearly documented in the RACI chart discussed earlier. This makes all the stakeholders feel responsible as well as accountable for protection of information within the enterprise.
  • Stakeholders are aware of how to identify and respond to threats to the enterprise. Threat identification is part of the training provided to stakeholders. Stakeholders are encouraged to report incidents, e.g., send an email to the ISG about any spam or phishing email received. The response received by the ISG on a day-to-day basis shows the keen awareness of everyone to identify and report incidences.
  • Management proactively supports and anticipates new information security innovations and communicates this to the enterprise. The enterprise is receptive to account for and deal with new information security challenges. ISG is constantly engaged in introducing innovations to deal with information security challenges. There is full management support to interact with industry and share knowledge and experience with a larger audience as well as learn from others. This case study is an example of this openness.
  • Business management engages in continuous cross-functional collaboration to allow efficient and effective information security programmes. The structure of various committees is an example of continuous cross-functional collaboration. Making information security independent of the IT function has provided a much broader reach and direct access to various business groups across the organisation.
  • Executive management recognises the business value of information security. The CISO works at a strategic level, reporting to a senior person in the bank. This has empowered the CISO to drive various information security initiatives with a great amount of freedom. This is a good indication of management’s recognition of the business value of information security.

Leadership as an Influencing Factor

In addition, the leadership in HDFC Bank plays a prominent role in building the security culture. Active participation by executive management and business unit management in the various top-level committees where information security is an important agenda item demonstrates the commitment at the top. Participation by leadership in business continuity planning exercises to discuss various disaster scenarios also shows deep involvement.

Vishal Salvi, CISM
Has more than 20 years of industry experience, having worked at Crompton Greaves, Development Credit Bank, Global Trust Bank and Standard Chartered Bank before taking on his current role as chief information security officer and senior vice president at HDFC Bank. At HDFC Bank, he heads the information security group and is responsible to provide leadership to the development and implementation of the information security program across the bank.

Is a leading authority on information security. He has four decades of experience in IT management, information systems audit, and information security consulting and training. He is currently advisor to ISACA’s India Task Force. Previously, Kadam served as an ISACA international vice president from 2006 to 2008 and president of the ISACA Mumbai Chapter from 1998-2000. He is the recipient of ISACA’s 2005 Harold Weiss Award.


Come join the discussionCome join the discussion! Stefan Beissel will respond to questions in the discussion area of the COBIT 5—Use It Effectively topic beginning 24 January 2014.


Supporting PCI DSS 3.0 Compliance With COBIT 5
By Stefan Beissel, Ph.D., CISA, CISSP

The Payment Card Industry Data Security Standard (PCI DSS) aims to improve the security of cardholder data and is required when cardholder data or authentication data are stored, processed or transmitted. The implementation of enabling processes from COBIT 5 can support compliance to PCI DSS1. COBIT 5 assists enterprises in governance and management of enterprise IT (GEIT) in general and, at the same time, supports the need to meet security requirements with enabling processes and management activities. The mapping of COBIT 5 enabling processes to PCI DSS 3.0 security requirements facilitates the simultaneous application of COBIT 5 and PCI DSS 3.0 and helps create synergies within the enterprise.


PCI DSS was released by the PCI Security Standards Council (PCI SSC), a panel of five global payment brands—American Express, Discover Financial Services, JCB International, MasterCard Worldwide and Visa Inc. PCI DSS also includes requirements for data security and related audit methods. In particular, the primary account number (PAN) is the defining factor in the applicability of PCI DSS requirements.

The goal of PCI DSS is primarily to protect the confidentiality of cardholder data. Confidentiality, as part of the information security triad that includes integrity and availability, is one of the main objectives of information security and protection. Confidentiality is the assurance that data cannot be viewed by or disclosed to unauthorized persons and, thus, be compromised. Measures that are used to protect confidentiality often also protect integrity. For example, if data are compromised by an attacker or malicious software, integrity will often be affected, too. Integrity is the assurance that data remain accurate and complete and cannot be tampered with or altered by unauthorized means. Availability means that authorized users or systems can access data at any required time. The availability is guaranteed by the systems and infrastructure, which are ready for use and have sufficient capacity to process all requests as quickly as necessary. Attackers can compromise the information availability by flooding a system with service requests and, thus, cause a denial-of-service attack, preventing access to critical information or data.

For credit card processing companies, the setup of a PCI-DSS-compliant environment is necessary because without it a significant part of their business model would not be achievable and significant losses would be incurred. In addition, loss of reputation and possible fines by credit card companies can be expected. Credit card processing companies are classified into four merchant compliance levels (levels/tiers one to four) relating to the number of transactions affected over a 12-month period.2 Each level has specific PCI DSS compliance requirements. Companies that are classified in levels two to four must perform an annual self-assessment questionnaire (SAQ) and complete a quarterly network scan by an approved scanning vendor (ASV). Companies with an annual number of transactions of six million or more are classified as level one and must create an annual report on compliance (ROC) and be audited by a Qualified Security Assessor (QSA). The result of the audit is documented with an attestation of compliance (AOC).3

The PCI DSS addresses 12 major requirements (figure 1) for control measures that are divided into topics, including network (requirements 1 and 2), protection of cardholder data (requirements 3 and 4), vulnerability management program (requirements 5 and 6), access control measures (requirements 7, 8 and 9), monitoring and testing of networks (requirements 10 and 11), and information security policy (requirement 12). Each requirement is further divided into subrequirements and testing procedures.

Figure 1

In November 2013, version 3.0 of PCI DSS was published. By 2015, compliance to this new version will be binding for all card-processing companies. In comparison to version 2.0, version 3.0 contains changes in the form of additional clarifications, guidance and advanced requirements.4 The 20 advanced requirements are aimed at achieving improvements in the areas of awareness, flexibility and security responsibility.


Figure 2COBIT 5 provides a comprehensive framework that assists enterprises in achieving their objectives for GEIT. It helps enterprises create optimal value from IT by maintaining a balance between realizing benefits and optimizing risk levels and resource use.5 The COBIT 5 product family also includes enabler guides, professional guides and a collaborative online environment. The most significant change in comparison to COBIT 4.1 is the reorganization of the framework from an IT process model into an IT governance framework.

The following chapter maps the PCI DSS 3.0 security requirements to the key, associated COBIT 5 enabling processes. The COBIT 5 process reference model includes processes for GEIT (figure 2).6

COBIT Enabling Processes by PCI DSS Topics

All sensitive systems must be protected against unauthorized access from untrusted networks. Firewalls are used for securely separating networks. They control the network traffic and block unwanted access between networks. They can be used locally on workstations or they can be dedicated systems within the network infrastructure.

Use of restrictive configurations can minimize the risk of unauthorized access from outside of the company network. System defaults that are present upon delivery of systems and components represent a security risk. Passwords and other settings that were specified by the manufacturer of the systems are usually widely available and can be exploited by unauthorized persons. Also, a variety of unneeded services are usually activated after the initial installation of operating systems. These services can also be exploited by unauthorized persons. Key enabling processes in COBIT 5 that can help mitigate risk are listed in figure 3.

Figure 3

Protection of Cardholder Data
Cardholder data must be stored and displayed only under certain conditions. Relevant requirements address data storage, deletion, encryption and masking (figure 4).

Figure 4

PCI DSS addresses encryption as well as specifics such as handling electronic keys. Where cardholder data are transmitted over open public networks, their encryption is required. If data are transmitted (e.g., via the Internet, wireless networks, Global System for Mobile Communications [GSM], General Packet Radio Service [GPRS]), there is an increased risk that an attacker can eavesdrop and manipulate cardholder data. The application of encryption, as specified, is one of many suggested methods to minimize this risk.

Vulnerability Management
The use of antivirus software is required to protect systems against malicious software. It can include pattern-based and behavior-based detection techniques. Pattern-based detection techniques detect viruses only after new virus patterns are updated to the antivirus software. Behavior-based detection techniques can identify malware on the basis of nonconventional behavior patterns, but these detection techniques may be inaccurate and may produce false positives and false negatives.

Development and maintenance of systems and applications must be secure, too. This includes the prevention or elimination of vulnerabilities that can be exploited by attackers to compromise or manipulate cardholder data. Regular installation of patches for operating systems and applications must be done, and secure programming of developments is required. Careful testing ensures that vulnerabilities are found. (See figure 5.)

Figure 5

Access Control Measures
The access to cardholder data must be restricted depending on appropriate roles as defined by the business need. According to least-privilege and need-to-know principles, only those persons authorized to access cardholder data for business purposes should be permitted access. This requires the implementation of control and authorization management, where each person can be assigned to a role with appropriate permissions (role-based access control [RBAC]) (figure 6).

Figure 6

For each person with system access, the assignment of unique identification (ID) is required. This is usually implemented via personal accounts. Only a person who can be successfully authenticated using a password, token or other authentication method will be allowed to access a computer or system.

Physical access to cardholder data must also be restricted. Trespassers who gain entry to offices or data centers could steal, damage or manipulate media or computer components. Media can include electronic media (such as diskettes, CDs and hard disks) as well as paper. With physical access control and the visible wearing of badges, unauthorized persons can be distinguished from authorized users.

Monitoring and Testing of Networks
All access to network resources and cardholder data must be tracked, monitored and logged (figure 7). With protocols, unauthorized access can be identified and traced. In addition, they are helpful for technical failure analysis. The PCI DSS requires logging of every access to cardholder data.

Figure 7

Security systems and processes need to be regularly tested. This includes regular scanning for security vulnerabilities and attack vectors. These threats must be identified and removed before they can be exploited by a would-be attacker.

Information Security Policy
An information security policy must be created and maintained by each company and communicated to, and followed by, all employees (figure 8). It contains requirements for information security to which all employees are bound. Topics in an information security policy include the communication of the PCI DSS requirements, the training for security awareness, the establishment of an incident response plan and the monitoring of the security posture of service providers.

Figure 8


Companies that store, process or transmit cardholder data or authentication data must comply with security requirements of PCI DSS. By using COBIT 5, these companies can cover PCI DSS 3.0 security requirements with COBIT 5 enabling processes. From another point of view, they can use the PCI DSS 3.0 security requirements to facilitate a COBIT 5 implementation and achieve objectives for GEIT. In both ways, these synergies help to optimize risk levels and resource use.

Stefan Beissel, Ph.D., CISA, CISSP
Is an IT security officer, responsible for the management of security-related projects and compliance with PCI DSS, at EVO Payments International.


1 The objective of this article is to provide a broad-brush review of the synergies between COBIT 5: Enabling Processes and PCI DSS 3.0. Cursory knowledge of the PCI DSS, PCI Security Standards Council (PCI SCC), COBIT 5 product family and associated enabling guidance will be helpful.
2 Visa, “Compliance Validation Details for Merchants,” 2012
3 PCI SSC, Payment Card Industry (PCI) Data Security Standard—Requirements and Security Assessment Procedures, Version 3.0, 2013
4 PCI SSC, “Payment Card Industry (PCI) Data Security Standard—Summary of Changes from PCI DSS Version 2.0 to 3.0,” 2013
5 ISACA, COBIT 5, 2012
6 ISACA, COBIT 5: Enabling Processes, 2012


Come join the discussionCome join the discussion! Steve Williamson will respond to questions in the discussion area of the COBIT (4.1 and earlier)—Use It Effectively topic beginning 24 January 2014.


Developing a Governance Framework for the Global Support Organisation at GlaxoSmithKline, Using COBIT
By Steve Williamson

Like most innovation-led organisations, GlaxoSmithKline (GSK) is highly dependent on IT. Its large, centralised IT support group has used COBIT 4.1 as the basis for developing an organisational IT governance framework. GSK is beginning its transition to COBIT 5.

The mission of GSK is ‘to improve the quality of human life by enabling people to do more, feel better and live longer’. In support of this mission, GSK develops and makes pharmaceuticals to treat a range of conditions including respiratory diseases, cancer, heart disease and epilepsy. GSK researches and makes vaccines that protect against infectious diseases, including influenza, rotavirus, cervical cancer, measles, mumps and rubella. It makes innovative consumer health care products, with a portfolio that includes well-known brands such as Horlicks, Panadol and Sensodyne. GSK is a global company operating in more than 115 countries with approximately 100,000 employees.

One of GSK’s strategic priorities is to simplify its operating model by reducing complexity and thereby becoming more efficient. This will free up resources to invest in other, more productive, areas of the business. One of the outcomes of this strategy is a more centralised IT organisation, offering standard IT support services to all business areas.

The application support group was formed by merging a number of autonomous, business-facing IT groups and is responsible for a portfolio of more than 2,000 applications supporting every stage of the value chain (research, development, manufacturing, commercial and corporate functions). This department has several hundred permanent staff, based at different locations worldwide. Additional technical support is provided from two offshore business partners.

The application support department has developed a governance framework for GSK.

Governance for an IT Support Function

Shortly after the formation of the new global support department, the need for an evaluation of governance processes was identified. The aim was to verify that the newly formed organisation has the right structures, processes and controls in place to enable successful execution of its strategy, and to ensure alignment with the enterprise strategy.

Organisational governance is a commonly accepted management term, which most people loosely understand. However, trying to define precisely what IT governance is and how it applies to an IT organisation is in itself a challenge. Thus, reference to commonly accepted industry frameworks is useful. In this case, GSK’s application support department utilized COBIT (version 4.1 was used for this exercise).

ISACA defines IT governance as, ‘The responsibility of executives and the board of directors; consists of the leadership, organizational structures and processes that ensure that the enterprise’s IT sustains and extends the enterprise’s strategies and objectives’.1


One of the advantages of COBIT 4.1 is that it is a framework that is strongly focused on control rather than execution. It covers a broad range of governance areas (e.g., human resources, finance, strategic alignment, risk management, service management) and can be mapped to other industry standards, such as ISO 27001 for security and ITIL for service management, which made it a good fit for GSK.

How GSK Used COBIT 4.1

COBIT 4.1 is comprehensive, yet simply structured, with each process area sub-divided into process description, control objectives, management guidelines and maturity models. This makes it easy to select the processes that are most applicable to the organisation’s goals and ignore those that are either not relevant or of lesser importance. For example, the COBIT processes PO2 Define the information architecture and PO3 Determine technological direction are the primary responsibility of another department within the enterprise, so these were excluded from the application support department’s framework, and other COBIT 4.1 processes had only partial applicability.

The application support department took the following steps to create its governance framework:

  1. Identify the applicable process areas from COBIT 4.1.
  2. Identify the applicable control objectives within each process area.
  3. Perform the risk assessment, i.e., ascertain the impact to the organisation of control failures in each process.
  4. Identify which existing processes, procedures or working practices address this process area, and evaluate against the control objectives.
  5. Review with subject matter experts and senior management, including those responsible for implementing the controls.
  6. Document any gaps or weak controls, describing the risk and input this information into the relevant process improvement work stream.

When control weaknesses are identified, it normally indicates that a policy is not being implemented effectively. This identifies the need for corrective action, which is the responsibility of management. This type of analysis could reveal a more fundamental problem, such as a previously unrecognised or an inadequately mitigated risk. In such a situation, the corrective action would be changes to the policy framework. Such actions would not be addressed by management, but by the compliance board. This could result in new or amended policies and/or decisions relating to the risk tolerance.

The governance framework is structured by IT governance focus areas (mapped to COBIT process areas) and includes the following:

  • IT organisation and relationship governance
  • The strategic alignment of business and IT objectives
  • Quality, risk and control policies framework
  • Communications, training and knowledge management
  • Investment portfolio, financial management and value delivery governance
  • System development, deployment and maintenance
  • Third-party services/supplier management

For each governance focus area, control objectives, key risk factors and implementation were defined (figure 1).

Figure 1

One may ask, why go to the trouble of creating a separate document rather than using the COBIT material directly? The reason is that having a framework with familiar business context allows it to be more intuitive to those who need to use it. Its purpose is to evaluate GSK’s processes against a commonly accepted standard for governance, not to redefine metrics or introduce new ways of working. This ensured the document is meaningful to a wide range of people, most of whom have little or no experience using COBIT.

Findings and Derived Value

Control objectives can be met by a procedure (e.g., change control process) or through effective organisational structures (e.g., representation on leadership teams), which clearly demonstrated accountability and control. However, during the analysis, the application support department found that some control objectives are being effectively met through nonprocedural methods. Although less formal than a management-approved procedure, most of these methods were documented or implied as part of job descriptions, thus demonstrating accountability.

Determining whether or not a procedure addresses the needs of the control objective is relatively easy. Judging the overall effectiveness of a procedure across a newly consolidated IT department is more difficult without extensive data gathering or audit. As a means of addressing this, newly implemented monitoring activities were used to assess the effectiveness of the mitigation techniques and they were the key source of information, making possible ongoing programme improvement.

In 2013, a department-wide governance audit was performed. This framework document was the basis for audit preparedness. It did not cover everything the auditors assessed, but it helped demonstrate the adequacy of the controls structures in place.

Next Steps

The framework gives a point-in-time evaluation of the application support department’s controls and allows for the identification of threats, vulnerabilities and inefficiencies, risk factors, and issues (which would have otherwise gone unnoticed). It will be maintained in line with organisational changes (e.g., if the organisation starts to offer a broader range of IT services, the framework can easily be expanded).

The next evolution of this governance model will include process capability assessment models for key process areas. The COBIT 5 process assessment model will be the basis for designing and implementing these models. This also marks the transition to COBIT 5. The process areas selected for capability assessments are those that would have the greatest risk impact if they failed to operate effectively. As before, the models will be based on COBIT, but will reference GSK’s metrics and processes. The first step is to perform a baseline assessment to determine current maturity levels, and then long-term improvement objectives will be established to ensure continued process improvement over the next five years.

Steve Williamson
Is the director, IT risk management, at GlaxoSmithKline, responsible for information security, regulatory compliance and quality management. Williamson started his IT career 25 years ago as a software tester in the banking industry. Williamson has been with GSK for the last 16 years in various project management and governance, risk and compliance roles.


1 ISACA, Glossary


Framework Committee

Steven A. Babb, CGEIT, CRISC, ITIL, UK, chair
David Cau, ITIL, MSP, Prince2, France
Sushil Chatterji, CGEIT, Singapore
Frank Cindrich, CGEIT, CIPP, CIPP/G, USA
Joanne De Vito De Palma, USA
Jimmy Heschl, CISA, CISM, CGEIT, ITIL, Austria
Katherine McIntosh, 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.

© 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