Vendor Management Using COBIT

VENDOR
MANAGEMENT
Using COBIT® 5
Personal Copy of: Mr. Cosmin Ionascu

2 Vendor Management: Using COBIT® 5
ISACA®
With more than 110,000 constituents in 180 countries, ISACA (www.isaca.org) helps business and
IT leaders maximize value and manage risk related to information and technology. Founded in 1969,
the nonprofit, independent ISACA is an advocate for professionals involved in information security,
assurance, risk management and governance. These professionals rely on ISACA as the trusted source
for information and technology knowledge, community, standards and certification. The association,
which has 200 chapters worldwide, advances and validates business-critical skills and knowledge through
the globally respected Certified Information Systems Auditor® (CISA®), Certified Information Security
Manager® (CISM®), Certified in the Governance of Enterprise IT® (CGEIT®) and Certified in Risk and
Information Systems ControlTM (CRISCTM) credentials. ISACA also developed and continually updates
COBIT®, a business framework that helps enterprises in all industries and geographies govern and manage
their information and technology.
Disclaimer
ISACA has designed and created Vendor Management: Using COBIT® 5 (the “Work”) primarily as an
educational resource for security, governance and assurance professionals. ISACA makes no claim
that use of any of the Work will assure a successful outcome. The Work should not be considered
inclusive of all proper information, procedures and tests or exclusive of other information, procedures
and tests that are reasonably directed to obtaining the same results. In determining the propriety of
any specific information, procedure or test, security governance and assurance professionals should
apply their own professional judgment to the specific circumstances presented by the particular
systems or information technology environment.
Reservation of Rights
© 2014 ISACA. All rights reserved. No part of this publication may be used, copied, reproduced,
modified, distributed, displayed, stored in a retrieval system or transmitted in any form by any
means (electronic, mechanical, photocopying, recording or otherwise) without the prior written
authorization of ISACA. Reproduction and use of all or portions of this publication are permitted
solely for academic, internal and noncommercial use and for consulting/advisory engagements, and
must include full attribution of the material’s source. No other right or permission is granted with
respect to this work.
ISACA
3701 Algonquin Road, Suite 1010
Rolling Meadows, IL 60008 USA
Phone: +1.847.253.1545
Fax: +1.847.253.1443
Email: info@isaca.org
Web site: www.isaca.org
Provide Feedback: www.isaca.org/vendor-management

Participate in the ISACA Knowledge Center: www.isaca.org/knowledge-center
Follow ISACA on Twitter: https://twitter.com/ISACANews
Join ISACA on LinkedIn: ISACA (Official), http://linkd.in/ISACAOfficial
Like ISACA on Facebook: www.facebook.com/ISACAHQ
ISBN: 978-1-60420-344-8
Vendor Management: Using COBIT® 5
3

Acknowledgments 3
Acknowledgments
ISACA Wishes to Recognize:
Development Team
Serge Cauberghs, PwC, Belgium
Maxim Deweerdt, PwC, Belgium
Stefanie Grijp, PwC, Belgium
Bart Peeters, CISA, PwC, Belgium
Sven Van Hoorebeeck, CISA, PwC, Belgium
Work Group
Stephen Buraczynski, CCBSO, CCBTO, NVE Bank, USA
Sami Kaukinen, CISM, CISSP, Finland
Sujatha Nambisan, CISA, NeST Information Technologies Pvt., Ltd., India
Anne Maria Yrjana, CISA, CRISC, Tieto Finland, Finland
Nikolaos Zacharopoulos, CISA, CRISC, CISSP, DeutschePost-DHL, Germany
Expert Reviewers
Jennifer Bayuk, CISA, CISM, CGEIT, CISSP, Jennifer Bayuk LLC., USA
Russell K. Fairchild, CISA, CRISC, CISSP, PMP, SecureIsle, USA
Kenneth H. Newman, CISM, CRISC, PMP, ITIL/ITSM, Central Pacific Bank, USA
Yogendra Rajput, Gujarat Gas Company Ltd., India
Anantha Sayana, CISA, CISM, CIA, Larsen & Toubro, Ltd., India
Claudio Schicht, CISA, CGEIT, ITIL, PMP, Independent Consultant, Argentina
Joanne De Vito De Palma, MBA, BCMM, The Ardent Group LLC., USA
ISACA Board of Directors

Tony Hayes, CGEIT, AFCHSE, CHE, FACS, FCPA, FIIA, Queensland Government, Australia,
International President
Allan Boardman, CISA, CISM, CGEIT, CRISC, ACA, CA (SA), CISSP, Morgan Stanley, UK,
Vice President
Juan Luis Carselle, CISA, CGEIT, CRISC, Radio Shack, Mexico, Vice President
Ramses Gallego, CISM, CGEIT, CCSK, CISSP, SCPM, Six Sigma Black Belt, Dell, Spain,
Vice President
Theresa Grafenstine, CISA, CGEIT, CRISC, CGAP, CGMA, CIA, CPA, US House of
Representatives, USA, Vice President
Vittal Raj, CISA, CISM, CGEIT, CFE. CIA, CISSP, FCA, Kumar & Raj, India, Vice President
Jeff Spivey, CRISC, CPP, PSP, Security Risk Management Inc., USA, Vice President
Marc Vael, Ph.D., CISA, CISM, CGEIT, CRISC, CISSP, Valuendo, Belgium, Vice President
Gregory T. Grocholski, CISA, The Dow Chemical Co., USA, Past International President
Kenneth L. Vander Wal, CISA, CPA, Ernst & Young LLP (retired), USA, Past International President
Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Director
Krysten McCabe, CISA, The Home Depot, USA, Director
Jo Stewart-Rattray, CISA, CISM, CGEIT, CRISC, CSEPS, BRM Holdich , Australia, Director
Knowledge Board
Christos K. Dimitriadis, Ph.D., CISA, CISM, CRISC, INTRALOT S.A., Greece, Chairman
Rosemary M. Amato, CISA, CMA, CPA, Deloitte Touche Tohmatsu Ltd., The Netherlands
Steven A. Babb, CGEIT, CRISC, Vodafone, UK
Thomas E. Borton, CISA, CISM, CRISC, CISSP, Cost Plus, USA
Phil J. Lageschulte, CGEIT, CPA, KPMG LLP, USA
Anthony P. Noble, CISA, Viacom, USA
Jamie Pasfield, CGEIT, ITIL V3, MSP, PRINCE2, Pfizer, UK

Acknowledgments (cont.)
Guidance and Practices Committee
Phil J. Lageschulte, CGEIT, CPA, KPMG LLP, USA, Chairman
John Jasinski, CISA, CGEIT, ISO20K, ITIL Exp, SSBB, ITSMBP, USA
Yves Marcel Le Roux, CISM, CISSP, CA Technologies, France
Aureo Monteiro Tavares Da Silva, CISM, CGEIT, Brazil
Jotham Nyamari, CISA, CISSP, Deloitte, USA
James Seaman, CISM, CRISC, A. Inst. IISP, CCP, QSA, RandomStorm Ltd., UK
Gurvinder Singh, CISA, CISM, CRISC, Australia
Siang Jun Julia Yeo, CISA, CRISC, CPA (Australia), MasterCard Asia/Pacific Pte. Ltd., Singapore
Nikolaos Zacharopoulos, CISA, CRISC, CISSP, DeutschePost–DHL, Germany

Table of Contents 5
Table of Contents
Chapter 1. Introduction..............................................................................................9
Background............................................................................................................9
Purpose of This Publication..................................................................................9
Who Should Use This Guide?...............................................................................9
Scope and Approach............................................................................................10
Chapter 2. Vendor Management..............................................................................11

Vendor Management Defined..............................................................................11
Life Cycle of the Contractual Relationship.........................................................12
Setup...............................................................................................................13
Contract...........................................................................................................14
Operations.......................................................................................................14
Transition-out..................................................................................................15
Stakeholder Responsibilities and Viewpoints......................................................15
C-level Executives...........................................................................................16
Business Process Owners...............................................................................16
Procurement....................................................................................................17
Legal...............................................................................................................17
Risk Function..................................................................................................17
Compliance and Audit....................................................................................18
IT.....................................................................................................................18
Security...........................................................................................................18
Human Resources...........................................................................................19
Chapter 3. Threats and Risk Related to Vendor Management.............................21

Common Threats in Vendor Management...........................................................21
Financial Impact of Inadequate Vendor Management
(Over the Relationship Life Cycle).....................................................................23
Chapter 4. Vendor Management Risk Mitigation Actions....................................27

COBIT 5 Guidance on Mitigation Actions.........................................................27
Case Study Illustrating Threats, Risk and Mitigating Actions............................40
Background.....................................................................................................40
Initial Solution................................................................................................40
What Happened?.............................................................................................41
Lessons Learned.............................................................................................42

Chapter 5. Binding Documents...............................................................................45

Call for Tender.....................................................................................................45
Vendor Contract...................................................................................................46
Service Level Agreements...................................................................................47
SLAs Defined.................................................................................................48
How to Create Successful SLAs.....................................................................48
SLA Common Pitfalls....................................................................................50
Benefits of Effective Service Level Management..........................................52
OLAs and Underpinning Contracts.....................................................................52
Chapter 6. Managing a Cloud Service Provider....................................................53

Excerpt From Security Considerations for Cloud Computing............................53
Appendix A. Vendor Selection Dashboard..............................................................87
Appendix B. Call for Tender Template...................................................................91
Appendix C. Call for Tender Checklist...................................................................95
Appendix D. D
rafting the Contract: High-level Legal Checklist
for Non-legal Stakeholders................................................................97
Appendix E. Example Contract Template............................................................103
Appendix F. SLA Template....................................................................................125
Appendix G. Service Level Agreement (SLA) Checklist.....................................129
Appendix H. Example SLA Template...................................................................131
Appendix I. Example Generic SLA.......................................................................137
Appendix J. Example SLA Deployment and Maintenance of Digital Copiers.......149
Appendix K. E
xample SLA Back Office Services...............................................157
Appendix L. H
igh-level Mapping of COBIT 5 and
ITIL V3 for Vendor Management...................................................171
Acronyms ................................................................................................................173
Glossary...................................................................................................................175

List of Figures 7
List of Figures
Figure 1—Life Cycle of the Contractual Relationship..............................................12
Figure 2—Bidding Document Comparison................................................................14
Figure 3—Vendor Management RACI Chart.............................................................16
Figure 4—Financial Impact of Inadequate Vendor Management...............................24
Figure 5—Financial Impact of Adequate Vendor Management.................................25
Figure 6—Initial Case Solution..................................................................................41
Figure 7—Three-tier Framework................................................................................43
Figure 8—Information Items in the Vendor Relationship Life Cycle........................45
Figure 9—SLA Issues.................................................................................................49
Figure 10—SLA Common Pitfalls.............................................................................50
Figure 1—Cloud Service Models (in Security Considerations for
Cloud Computing).....................................................................................55
Figure 9—Cloud Threats and Mitigating Actions Mapped to COBIT® 5
for Information Security (in Security Considerations for
Cloud Computing).....................................................................................74
Figure 11—Vendor Selection Dashboard Example....................................................87
Figure 12—Vendor Score Example............................................................................88
Figure 13—Graphic Representation of Vendor Score Example.................................89
Figure 14—Call for Tender Checklist.........................................................................95
Figure 15—Service Level Agreement (SLA) Spider Diagram Example ................125
Figure 16—SLA Checklist.......................................................................................129

Page intentionally left blank

Chapter 1. Introduction 9
Chapter 1. Introduction
Background
Vendors constitute an important part of an enterprise’s external environment. The

increased use of outsourcing and cloud computing implies that vendors are taking
on an increasingly fundamental role in the operations of an enterprise. In addition,
a trend in the market is toward fewer, but more significant, vendor relationships,
in part because many enterprises prefer to have a single point of contact (SPoC),
which represents a consortium of vendors to simplify the management process. As
the scope, scale and complexity of vendor relationships and services increase, the
risk related to them and the importance of effective vendor management increase
proportionately. Managing external vendors should be a key competency for every
enterprise and can lead to optimally mitigated risk and significant benefits.
Purpose of This Publication
Vendor management includes the process of managing third parties that deliver
IT services and products to the enterprise to maximize benefits and reduce
associated risk. This process requires significant effort from both the enterprise
and the vendor; therefore, IT vendor management often focuses on strategic
client-vendor relationships that play a vital role in the enterprise’s daily operations.
These relationships can have significant impact on the success of strategic projects
and may generate substantive financial implications.
Strategic client-vendor relationships can encompass significant risk to the enterprise and
should be managed rigorously. Although guidance on third-party management is available
in process APO10 Manage suppliers in COBIT® 5: Enabling Processes1, this publication
on vendor management provides additional and more detailed practical guidance and
facilitates the vendor management process for IT and business professionals. Vendor
Management: Using COBIT® 5 complements COBIT® 5: Enabling Processes.
Who Should Use This Guide?
Establishing and managing vendor relations is not solely the responsibility of IT

or the business process owners. The vendor management process involves many
stakeholder functions within the enterprise, for example:
• The legal function validates contracts.
• The compliance, legal and audit functions are consulted during the review of
service agreements.
• The enterprise risk function analyzes vendor-related risk.
• The board approves budgets.
• The procurement function ensures that vendor management activities are
integrated into the overall selection and management process.
1
ISACA, COBIT® 5: Enabling Processes, USA, 2012
This publication provides practical guidance for all stakeholders involved in the
vendor management process, from the board and C-level executives (e.g., chief
executive officer [CEO], chief financial officer [CFO], to business professionals,
supporting functions (e.g., compliance, legal, risk, procurement) and IT.
Scope and Approach

The practical guidance in this publication is specifically for IT-related services and
products and focuses mainly on outsourcing of services because this type of vendor
relationship may be the most complex. The processes, challenges, mitigations and
benefits described in this publication can also be applied to an enterprise context
that includes other types of vendor relationships, including business and IT.
This publication describes the vendor management process and its activities and
then presents the most common threats, risk and mitigation actions. A detailed case
study is provided to show the potential consequences of faulty vendor management.
Practical sample templates and checklists are also provided to help during
implementation of the concepts presented in this publication.
The information is organized as follows:

• Chapter 2—Vendor management definition, life-cycle stages and stakeholders
• Chapter 3—Threats and risk related to vendor management
• Chapter 4—Good practices to mitigate risk related to vendor management
• Chapter 5—Binding documents that should be considered during the vendor
management life cycle
• Chapter 6—Cloud vendor management
• Appendices—Practical templates, checklists and examples

Chapter 2. Vendor Management 11
Chapter 2. Vendor Management

This chapter defines vendor management, explains the process life-cycle phases and
identifies the process stakeholders.
Vendor Management Defined
A vendor is a third party that supplies products or services to an enterprise.

These products or services may be outsourcing, hardware, software, services,
commodities, etc. Vendor management is a strategic process that is dedicated to
the sourcing and management of vendor relationships so that value creation is
maximized and risk to the enterprise is minimized. This process requires dedicated
effort from the enterprise and the vendor. The approach and level of effort vary
based on the vendor relationship and the scope of services and products. Each type
of relationship may require a different set of steps and documents, depending on
the relationship and the enterprise strategy. Enterprises should focus their vendor
management efforts on third-party relationships that:
• Play a vital role in the enterprise’s daily operations
• Have a critical impact on the success of the enterprise’s strategic projects
• Require long-term contracts
• Have potential for significant financial implications
• Are difficult to change overnight
• Require frequent interaction and collaboration for disputes or have complex
problem-resolution mechanisms
• Access or manage substantial critical or sensitive data
Most enterprises seek external vendor support for assistance with operations for one
of the following reasons:
• Vendor expertise—The enterprise needs expert knowledge or a broader
perspective and experience with similar enterprises to effectively and efficiently
handle certain activities.
• Vendor capacity—The enterprise does not have the resources to handle the work
related to a specific product or service. The vendor can supply the resources to
support the entire operation or to supplement in-house resources.
• Vendor assuming risk—The enterprise outsources activities to leverage a
vendor’s experience with operational risk and corresponding risk mitigation
services. However, the accountability for the adequate performance of those
activities can never be delegated and stays with the enterprise.
• Vendor leveraging scale—Vendors can offer services at a lower cost because
working for multiple customers allows vendors to leverage scale.
Engaging third parties to provide strategic products or services comes with specific
threats and risk. These are further discussed in chapter 3. Threats and Risk Related
to Vendor Management. The first action to mitigate vendor-related risk is to

establish an effective vendor management process with goals and objectives that
ensure the following:
• Vendor management strategy is consistent with enterprise goals.
• Effective cooperation and governance models are in place.
• Service, quality, cost and business goals are clear.
• All parties perform as agreed.
• Vendor risk is assessed and properly addressed.
• Vendor relationships are working effectively, as measured according to
service objectives.
Commonly accepted vendor management processes, good practices and other

mitigation actions that can reduce exposure of identified risk are further discussed
in chapter 4. Vendor Management Risk Mitigation Actions.
Life Cycle of the Contractual Relationship
The life cycle of the contractual vendor relationship can be divided into four phases,
as shown in figure 1. Each phase typically consists of a number of activities.
Figure 1—Life Cycle of the Contractual Relationship
• Requirements Contract Transition-out

• Call for tender Transition-in
• Evaluation • Understanding • Operations
• Shortlist • Deliverables Management phase out
• Negotiation • Service levels of Operations • Transition of
• Metrics knowledge and
• Costs operations to
Setup • Legal new vendor
Operations
Contract Change
Management
The first step in implementing a robust vendor management process is to define

and document a sourcing strategy that aligns with enterprise strategy, i.e., determine
the IT capabilities for which the enterprise wants to involve third parties, define the
objectives for collaboration, and identify the vendors that will be strategic partners
or suppliers. The risk and expected benefits of the outsourced capabilities need to
be determined to provide a way to measure success. A number of factors need to be
considered when deciding if outsourcing is a good option. Following are factors that
are commonly considered when comparing internal sourcing vs. external sourcing:
• Employee wages (fringe benefits, overtime compensation, holidays, etc.)
• Operational cost (overhead, infrastructure, tools, etc.)

• Ability to meet availability requirements

• Degree of control by company (flexible, static, etc.)
• Overhead and follow-up
• Availability of tools and methodology
• Availability of skills and expertise
• Ability to meet confidentiality and security requirements
• Focus on core competencies
• Short-term and long-term needs
Defining the outsourcing strategy is an important first step in the process,

but is considered out of scope for the remainder of this publication. More
detailed guidance on how to define the enterprise outsourcing strategy as part
of the IT strategy can be found in process APO02 Manage strategy in
COBIT® 5: Enabling Processes.
Setup
During the first phase of the contractual vendor relationship life cycle, setup of
the contractual relationship, the enterprise focuses on gathering product or service
requirements from different stakeholders, e.g., business units, legal, compliance
and IT. The main challenge in the first phase of the process is to organize the
requirements into a clearly understandable document on which all parties agree.
The requirements document serves as the basis for the call for tender, which is sent
to the market. A call for tender may include one step or many, depending on the
guidelines established in the sourcing strategy, the size of the sourcing organization,
and the complexity of the product or service being sought. Some enterprises prefer
to send out a request for information (RFI) before the call for tender to identify
candidates and competencies in the market. The outcome of the RFI serves to better
scope the request for proposal (RFP) in terms of potential candidates, technologies,
delivery models, etc. When the enterprise has a clear understanding of the product
or service needed and market options, a request for quote (RFQ) can be sent out to
invite vendors to present their options. Some enterprises send an RFP directly to
vendors, explaining the required products or services and requesting formal offers
from available candidates. Figure 2 illustrates the main differences among the three
bidding documents.
After receiving responses from candidates, the enterprise evaluates them based on
predetermined evaluation criteria and weighting factors and composes a short list of
qualified vendors with which to start negotiations. Vendor selection is based on the
extent to which the vendor meets defined requirements (i.e., service time delivery,
price ranges, communication system, geographic location, training aids, etc.), a
demonstrated ability to deliver high-quality products and services, and interest in
developing long-term relationships. After the short list is finalized, negotiations
with the best-qualified vendors begin. It is recommended to short-list at least two
vendors to have a contingency solution if negotiations with a particular vendor fail.

Figure 2—Bidding Document Comparison

Request for Information Request for Quotation Request for Proposal
(RFI) (RFQ) (RFP)
• Educational tool • Price comparison tool • Formal evaluation tool
• Used to gather information • Used when customer • Used when customer
when product, services or understands products, understands products or
requirements are not fully services, requirements and services and has well-defined
understood market conditions requirements
• Low complexity (easier to • Medium complexity (easier to • High complexity (requires
prepare, requires less effort prepare, requires less effort significant time invested in
than RFP) than RFP, requires clear documenting requirements
• Less formal than RFP understanding of requirements) and evaluation criteria)
• Can be used as input for RFP • Semiformal • Can be used before
• Simplifies vendor comparison sending RFQ
by focusing on price
Contract
In the second phase of the contractual vendor relationship life cycle, the enterprise
and the vendor develop a contract that specifies the details of their business
relationship. This contract accomplishes the following:
• Forms a common understanding of what needs to be achieved
• Defines all deliverables, relevant service levels and metrics
• Defines responsibilities and obligations
• Defines the terms and conditions
• Specifies how risk will be allocated between parties
• Defines legal counsel and jurisdiction stipulations
Good practices dictate that the enterprise have contract templates that can be used
during this phase to ensure that final contracts are in compliance with enterprise
policies and objectives. Using a vendor-provided contract is not recommended
because it may favor the vendor and put the enterprise at a disadvantage.
Often, the contract phase is not executed properly, mainly due to time constraints
and eagerness to get to the operations phase. An example is when an enterprise is
changing vendors and proceeds through the process as fast as possible. This haste
could increase the risk of incumbent demotivation or problems with phasing out
buildings and equipment. However, as explained in chapters 3 and 4, it is critical
to invest the appropriate time and resources to negotiate and document the contract
because this can have substantial business (financial) and legal impact in a later
phase of the relationship cycle.
Operations
The third phase of the contractual vendor relationship life cycle, operations, begins
with a transition-in period, in which the vendor starts delivering new products
or services to the enterprise or takes over operations from another vendor or IT
group. After delivery responsibility is fully assumed by the new vendor, operational
collaboration is initiated and management activities commence to guide the
relationship toward the goals set in the second phase.

Contract Change Management

Contracts are living documents that require modification when conditions in
the business relationship change, e.g., when the service model, pricing, risk or
legislative requirements that must be incorporated into the contract change. The
enterprise and the vendor must agree on the resulting financial and risk implications
and document these in the new contract. The need for changes and procedures
to address them should be disclosed and documented in the original contract to
prevent misunderstandings and/or business disruptions.
When the contract with a current vendor is near expiration or marked for
termination, the vendor selection process starts. Before moving to the
transition-out phase, the enterprise should select a replacement. Once the setup and
contract phases for the new vendor are completed and a new vendor is engaged, the
old vendor starts the transition-out phase, which includes transfer of knowledge and
resources, as needed.
Transition-out
At some point in time, there will most likely be a transition-out phase in the
contractual vendor relationship life cycle. When the vendor is no longer needed
or willing to deliver contracted products or services, arrangements are made to
facilitate the phaseout, preferably in combination with a transfer of knowledge,
data, systems and operations to a new vendor or back in-house. Often, during
contract negotiations, little effort is invested in describing and planning an exit
strategy because of the difficulty in foreseeing how business, people and technology
might evolve. The business case that is explained in chapter 3 demonstrates the
importance of having a defined and documented exit strategy that describes
activities and conditions to ensure business continuation.
Stakeholder Responsibilities and Viewpoints
Many stakeholders are involved in the vendor management process. As explained in

chapter 1. Introduction, establishing and managing good vendor relations does not
involve IT or the business process owners solely, but also many other stakeholders
within the enterprise. The participation of the legal function is crucial in helping
to define requirements and writing contracts. Compliance and audit should be
consulted when reviewing service agreements and vendor compliance assessments.
Risk management and business continuity should analyze vendor-related risk, etc.
The RACI (responsible, accountable, consulted and informed) chart in figure 3 is a

high-level representation of the various stakeholders in vendor management.

Figure 3—Vendor Management RACI Chart

Contractual Relationship Life Cycle
Stakeholder Setup Contract Operations Transition-out
C-level executives A A A A
Business process owners R R I R
Procurement R R I R
Legal R R C C
Risk function C C R R
Compliance and audit C C C C
IT R R R R
Security R C R C
Human resources (HR) C C C C
C-level Executives
The C-level executive who is accountable for the vendor management process
depends on the scale of outsourcing. When the scope and impact of products and
services are limited to IT, the chief information officer (CIO) is often accountable
for the execution of the contractual vendor relationship life-cycle phases. When the
scope also includes the business, the CIO provides oversight and coordination of
all responsible parties and supports other C-level executives in the decision-making
processes. The CIO provides oversight to ensure that:
• Contract objectives do not conflict among vendors, products and services.
• Contracts comply with internal policies.
• Contracts are managed properly.
• Service level agreements (SLAs) are met.
For involvement of large-scale vendor services covering or impacting the entire

enterprise, however, the CEO and CFO are more closely involved and take on the
accountability for the activities described previously for the CIO.
The CFO is responsible for the enterprise budget, after it is approved by the board;
therefore, the CFO should approve the budget that is available for IT vendors. The
CFO should be at least consulted for the following responsibilities:
• Drafting the call for tender to validate budget specifications
• Negotiating with multiple vendors
• Agreeing on the final vendor contract
The CEO and CFO should be informed of vendor performance during the
operations phase.
Business Process Owners

The goal of contracting IT products or services is to enable the enterprise to
achieve its goals. Therefore, business process owners should be actively involved

in the vendor management life cycle in addition to IT and procurement. Some key
responsibilities of business process owners include:
• Providing business requirements
• Consolidating stakeholder requirements and making sure they are validated and
approved by all parties
• Evaluating potential vendors using specific business knowledge and expertise
• Providing input for contract specifications (e.g., service levels and
transition-out specifications)
Procurement
Many responsibilities within the vendor management life cycle belong to the
procurement function. Involving sourcing professionals from the beginning of
the process enables them to support business units, IT and compliance during
the selection and contract management processes. Following are some key
responsibilities of procurement:
• Help business process owners consolidate business requirements from
various stakeholders.
• Help IT consolidate IT-related requirements.
• Prepare and send out the call for tender.
• Gather vendor offers.
• Facilitate the vendor evaluation process.
• Facilitate vendor negotiations.
• Facilitate contract management activities.
Legal
To effectively mitigate vendor-related risk, the legal function should be involved
throughout the entire vendor management life cycle. Assigning ownership of certain
tasks creates commitment and a close collaboration with the other stakeholders. Key
responsibilities of the legal function include:
• Provide input regarding service requirements, from a legal point of view.
• Consolidate legal requirements and make sure that they are validated and approved
by the other stakeholders.
• Provide boilerplate standard contract language for important legal and
compliance provisions.
• Evaluate potential vendors using specific legal knowledge and expertise.
• Draft the contract, taking into account and reviewing the specifications provided
by other stakeholders.
Risk Function
The risk function should be consulted throughout the vendor management life
cycle to obtain a complete view on risk that is related to the relationship, services
or products. During the setup and contract phases, the risk function provides
requirements to mitigate potential risk. Potential risk during the operations phase is
addressed within the enterprise risk framework, based on information provided by
the business units and the enterprise risk appetite.

If the vendor environment, business model, products or services change, the risk
function initiates an assessment to identify and address new risk. After the risk
assessment is completed, the enterprise identifies controls that are required to
minimize newly identified risk and updates related documentation (e.g., business
impact analyses, business continuity plans [BCPs], disaster recovery plans [DRPs],
insurance policies and the risk framework).
Compliance and Audit

The compliance and audit functions should be consulted throughout the vendor
management life cycle to ensure compliance with internal and external laws,
regulations and policies. Compliance and audit participate in the vendor
management life cycle by:
• Ensuring compliance of vendor candidates during the selection process
• Providing compliance requirements to be included in the contract
• Ensuring compliance of the selected vendor during operations
IT
All stakeholders share the responsibility of the vendor management process to
ensure that products and services received from the vendor support enterprise goals
within risk tolerances. However, the IT role is significant because its members may
be more familiar with the products and services and their market availability. Key
responsibilities of IT include the following:
• Identifying potential vendors, products and services
• Providing input regarding requirements for products and services from an IT
point of view
• Providing input associated with baseline standard requirements and
architectural limitations
• Providing expectations associated with good practices and defined
architectural boundaries
• Providing information practices, such as information ownership and co-location
requirements, partnership arrangements and employee checking
• Consolidating the previous inputs and ensuring that they are validated and
approved by all stakeholders
• Evaluating potential vendors using specific IT knowledge and expertise
• Providing input for contract specifications (e.g., transition-in specifications,
transition-out specifications and service metrics)
• Monitoring, reporting and managing vendor performance during operations
Security
Although security is often associated with the IT stakeholder, security is regarded
as a separate stakeholder because it does not always reside within the IT function
and can be involved with other functions as well as IT. Security is responsible for
the following:
• Providing input regarding security requirements for products and services
• Providing input associated with baseline security standard requirements

• Providing information practices, such as information accessibility and required

assurances of information protection
• Verifying compliance of the vendor with product, service and information
security requirements
Human Resources
The HR stakeholder should be consulted throughout the vendor management life
cycle to ensure compliance with the enterprise’s worker statutes, local regulations,
code of conduct and labor law.


Chapter 3. Threats and Risk Related to Vendor Management 21
Chapter 3. Threats and Risk Related to

Vendor Management
Creating awareness within the enterprise about the risk and threats posed by
third parties that provide IT products or services is the first step toward effective
IT vendor management. This chapter identifies common threats that can impact
vendor management and provides a demonstration of the financial impact that poor
management practices can have throughout the enterprise.
Common Threats in Vendor Management
Recent research2 reveals that approximately one out of five enterprises (19 percent)
does not invest sufficient effort to manage vendors and vendor-provided services
effectively. This means, e.g., that enterprise requirements and standards are not
properly incorporated into vendor contracts, ownership of information being
handled by vendors remains undefined and, if these vendors go out of business,
access to retrieve this information is not guaranteed.
This research finds that almost 70 percent of enterprises have some awareness about
vendor management and incorporate some requirements into IT vendor contracts,
but do little to nothing to determine whether their vendors comply with terms
specified in the contracts and even less to determine if they are at risk because of
their vendors, often until it is too late.
Approximately 12 percent of enterprises devote great effort to gather information

from vendors, assesses vendor compliance and risk, employs red flags and triggers
to identify when additional information from vendors is needed, and takes action to
manage the compliance profiles and risk posed by their vendors.
Following are the most common vendor management threats and related risk
components (financial, operational, legal/compliance and reputational):
T1 Vendor selection:
– Description—The threat of inadequate vendor selection may result during
the operations phase in the nonfulfillment of core vendor contractual
obligations. Proper due diligence before closing the contract can help
mitigate this risk and provide the enterprise with a better view on the long-
term delivery capabilities and sustainability of the vendor.
– Risk—Failure to conduct adequate vendor selection exposes the enterprise to
a financial risk in the form of the considerable costs associated with replacing
the vendor, potential revenue loss and ineffectiveness of financial penalties.
Operational risk includes the inability to operate a certain part of the delivered
service to meet the enterprise goals and the inability to obtain adequate skilled
2
I T Policy Compliance Group, “Vendor Risk Management for IT,” May 2012, Wellington Research Ltd,
www.itpolicycompliance.com/wp-content/uploads/2012/05/Vendor-Risk-Management-May-2012.pdf
resources. Image and market share loss are considerable reputational risk
elements. Legal risk is situated around labor issues and lawsuits.
Risk affected—Financial, operational, reputational and legal/compliance
T2 Contract development:
– Description—An incomplete contract, not covering all the aspects of
the relationship that need to be managed up front, is a major threat to the
sustainability of the contractual relationship.
– Risk—Neglecting to detail payment terms and price-setting mechanisms is a
major financial risk associated with this threat. Related to the financial risk,
but also operational in nature, is requiring unrealistic or inadequate service
levels from the vendor, which results in overengineered solutions and high
prices or underutilization of resources and lost business opportunities. Other
operational risk includes missing end-of-life management stipulations (exit
strategies) in the contract or inappropriately communicating requirements
(not clear and measurable) to the vendor. Legal/compliance risk could
arise when the contract fails to detail liabilities or does not stipulate any
intellectual property rights or specifications on the use, disposal, and
distribution of software and data.
Risk affected—Financial, operational and legal/compliance
T3 Requirements
– Description—The threat of inadequately setting up and detailing the
requirements can have a huge impact on the proper execution of the service
by the vendor.
– Risk—Enterprises tend to focus on solutions instead of defining the
requirements and giving freedom to the vendor to propose the optimal
solution. This could lead to operational (e.g., failing service), financial
(e.g., revenue loss due to failing service), legal (e.g., disputes with vendor
due to not meeting the requirements) and reputational (e.g., unwanted
rumors, image and/or market share loss due to the inability to provide a
service to clients) issues in the long run. Insufficiently detailing reporting
requirements and the right to audit may also expose the enterprise to
an operational risk (e.g., unawareness of the performance of the service
delivery).
Risk affected—Financial, operational, reputational and legal/compliance
T4 Governance
– Description—A lack of governance during the contractual vendor
relationship life cycle can be considered a major threat to proper
vendor management.
– Risk—Failure to define an adequate governance model between the
enterprise and the vendor increases operational and compliance risk. Also
related to a lack of governance is ineffective contract change management
procedures during the contract life cycle, which increases operational risk
(e.g., ineffective execution of the service due to misaligned incentives) and
financial risk (e.g., paying a price that is too high for the desired level of
service provisioning).

T5 Strategy
– Description—The enterprise vendor management strategy has considerable
impact on the enterprise’s business activities.
– Risk—Over reliance on a specific vendor, especially for business-critical
tasks, increases operational risk (e.g., lack of in-house knowledge and
demotivation of employees) and, consequently, financial risk (e.g., vendor
can over price its service due to the enterprise’s dependence on the vendor).
Considerable attention must be paid to the applicable law in the vendor’s
physical location, especially with offshore vendors and contracted cloud
computing services, because these regulations can expose the enterprise to
increased legal risk.
Financial Impact of Inadequate Vendor Management

(Over the Relationship Life Cycle)
The financial impact on the enterprise of inadequate vendor management during the
life cycle of the contractual vendor relationship varies depending on the phase (see
chapter 2). During the setup phase, most activities related to vendor management
are internal. This means that minimal financial impact is experienced when an issue
occurs. It is important to note that, during this stage, enterprises are likely to cut
corners to speed up the process, which may result in significant financial impact
during subsequent phases.
In the contract phase, more internal and external stakeholders are involved and
negotiations need to be more formal. Therefore, rectifying issues or correcting
mistakes may require more effort and resources than during the setup phase. If,
during the contract phase, it is discovered that requirements were not properly
defined during setup, certain steps may need to be repeated. Even if no immediate
financial impact is expected due to duplication of efforts, it is recommended that
additional effort be spent during setup to finalize requirements and develop a robust
contract agreement.
The amount of effort and resources required to correct issues or mistakes during
the transition-in period and the operations phase is significantly higher. Problems
in the contract or deficiencies in products and services due to poor requirements
definition should be addressed immediately to prevent additional impact on
operations. These emergency changes may come with a high price for the enterprise
and the additional risk of disrupting processes, depending on the products or
services impacted. Figure 4 is a graphic representation of financial impact over the
contractual vendor relationship life cycle.

Figure 4—Financial Impact of Inadequate Vendor Management
Money
Time
Operations
Setup
Out
In
Contract
Investing more time up front, before signing the contract and during contract
negotiations, is clearly worth the effort. Figure 5 is a graphic representation of
the financial impact of adequate vendor management. The red area in the figure
represents the additional financial input that the enterprise needs to spend in the
setup and contract phases to make sure all identified risk and requirements are
addressed and included in the contract. This can reduce effort and cost during
the transition-in period and the operations and transition-out phases, as shown by
the green area in figure 5. Comparing the green area (the money saved in later
phases) with the red area (the money spent in earlier phases) shows clearly that
the green area outweighs the red area, and significant savings can be realized
by investing sufficient time and resources in the preparation phases. Moreover,
smooth operations increase the perception of good vendor performance within the
enterprise, thereby improving the image of the IT organization.
Simply put, spending time and effort during the beginning of the life cycle and
having qualified resources to manage the third party properly will pay off during
the operational phases of the relationship.

Figure 5—Financial Impact of Adequate Vendor Management
Money
Time
Operations
Setup
Out
In
Contract


Chapter 4. Vendor Managemnt Risk Mitigation Actions 27
Chapter 4. Vendor Management

Risk Mitigation Actions
Awareness about the importance of proper vendor management constitutes the first
step to implementing an effective process. Mitigating actions, good practices and
recommendations to overcome the threats provided in chapter 3 are described in
this chapter.
Enterprises have different approaches to managing vendor-related risk. On one

side of the spectrum, there are enterprises that treat vendor management as a
simple sourcing and contract-signing issue, while, on the opposite side, there are
enterprises that consider vendor management part of the enterprise long-term
strategy to reduce risk, optimize cost and create value for stakeholders.
Managing vendors has many benefits. Some of the benefits reported by enterprises
that have mature processes include the following:
• Data loss reduction
• Decrease in audit findings
• Cost optimization
• Increased availability
• Liability reduction
• Increased end-user satisfaction
• Value creation
COBIT 5 Guidance on Mitigation Actions
This section describes the major mitigation actions related to the previously described
threats and risk. With the implementation of these mitigation actions, the impact and
probability of a risk event can be greatly reduced. However, residual risk may still
exist, and periodic evaluation of vendor management actions is always advised.
The following are 22 mitigation actions:

1. Diversify sourcing strategy to avoid overreliance or vendor lockin:
• Related threat—T5
• Mitigation—Overreliance on a particular vendor may expose the enterprise
to the risk of being unable to transfer to alternative vendors. When too many
critical tasks in a process are being performed by the same vendor, there is a
high probability that the enterprise will have no resources in-house who are
capable of taking over the process if needed (even just to train a new vendor).
This risk needs to be managed when making strategic decisions and deciding
which tasks or processes to outsource and which ones to keep in-house.
• Related guidance in COBIT 5:
– Processes: APO02 Manage strategy, APO10 Manage suppliers
– Enabler: Organisational Structures

2. Establish policies and procedures for vendor management:

• Mitigation—Standardized procedures and guidelines help to build sustainable
vendor relationships in which risk is managed and decisions are made on an
objective basis. Policies and procedures are the tools to establish this working
environment and can support all vendor-related activities, e.g., vendor selection,
management and evaluation.
– Process: APO11 Manage quality
– Enablers: Principles, Policies and Frameworks; Information
3. Establish a vendor management governance model:
• Mitigation—It is important to have a formal governance structure in place
to manage the contract life cycle. The governance model should define
stakeholders and responsibilities, escalation procedures, reporting requirements
and frequency, governance bodies, etc. With this structure, the enterprise can
manage the contract on the different levels of the relationship, i.e., operational,
tactical and strategic levels. Vendor management should involve all levels of the
enterprise to generate the right cooperation and involvement.
– Processes: APO09 Manage service agreements, APO10 Manage suppliers
4. Set up a vendor management organization within the enterprise:
• Mitigation—Establish a vendor management office (VMO). VMOs are
particularly beneficial to large enterprises that deal with a large number of
vendors, enterprises that maintain highly complex contractual relationships and
enterprises that have few, but highly strategic, sourcing relationships. If having a
dedicated VMO is not an option, the creation of a vendor relationship manager
(VRM) role is recommended. It is an SPoC for each vendor (e.g., for managing
complaints from both sides). The same person may be responsible for more than
one vendor. It is also a good practice to have a person in the IT organization
responsible for contractual and financial relationships with each vendor.
VRMs are beneficial for smaller enterprises or those that have only a limited
number of strategic sourcing relationships. Establishing either one of these
organizational structures (VMO or VRM) allows the enterprise to consolidate
several responsibilities and activities for the oversight and management of
strategic vendors. These organizational structures can be set up as part of IT,
procurement or strategic management. However, accountability for adequate
vendor management remains at the enterprise’s C level.
Effective vendor management requires a wide breadth of skills and

competencies from the people (VMOs and VRMs) involved, including
the following:
– Knowledge and experience with business operations to understand the
activities and context of the enterprise

– Relationship-building and alignment-building skills to facilitate cooperation

among all parties involved
– Detail orientation to measure vendor performance and follow up on processes
– Big-picture thinkers with strategic viewpoints to understand the high-level
importance of certain relationships
– Analytical thinking to solve problems and find root cause
– Basic legal understanding of contract terms and conditions
– Negotiation skills
– Knowledge of vendor management practices
– Enablers: Organisational Structures; People, Skills and Competencies
5. Foresee requirements regarding the skills and competencies of the
vendor employees:
• Mitigation—The enterprise should stipulate certain levels of experience
(expressed in relevant education or years of experience) and certifications
that vendor employees should possess. For example, if the vendor provides IT
security services, the enterprise will want to ensure that the vendor’s employees
are fully skilled and certified in that domain. Certifications3 can easily be
required, complementary to experience levels. A good practice is to establish a
key performance indicator (KPI) on the average number of years of experience
of the team; achievement of the KPI requires that the average not fall below a
certain number of years.
Sustainability and success of the relationship are also greatly influenced by the
vendor employees’ ability to adapt to the culture and behavior of the enterprise,
especially for situations where they are required to work on enterprise
premises. Disputes can arise if these employees are not sensitive to specific
behaviors within the enterprise, which may result in high turnover and customer
dissatisfaction.
– Process: APO10 Manage suppliers
– Enabler: People, Skills and Competencies
6. Use standard documents and templates:
• Mitigation—Good practice dictates that an enterprise have standard documents
and templates that can be used during the life cycle to ensure that they comply
with enterprise policies and objectives. Using vendor-provided documents
and templates is not recommended because they may favor the vendor and put
the enterprise at a disadvantage. An example of a call for tender template is
available in appendix B, and an SLA template is available in appendix F.
– Process: APO09 Manage service agreements
– Enabler: Information
3
xamples include Certified Information Systems Auditor (CISA) and Certified Information Security
E
Manager (CISM) from ISACA, and Certified Information Systems Security Professional (CISSP)
from (ISC)2.
7. Formulate clear requirements:

• Mitigation—The requirements definition forms the basis for the call for tender
and is used in the contract phase to establish clear enterprise expectations
about vendor performance, deliverables, quality of service, cost, etc. Poorly
defined requirements used during the negotiations and contract phase may
cause confusion and disputes later in the relationship regarding roles and
responsibilities, liabilities, factors used to determine cost, etc. Moreover, this
may have a substantial financial impact on either party during the operations
phase. Therefore, it is important for business process owners, IT, legal and other
stakeholders to reach a common understanding before proceeding to the next step
in the process. When preparing a call for tender, it is important to ensure that:
– Context and enterprise activities are clear. Defining boundaries of scope and
explaining enterprise objectives may be helpful for vendors to be able to
understand the environment in which the enterprise operates.
– Requirements are clearly defined, validated and approved by stakeholders.
– A procedure is included to clarify requirements if needed, e.g., through
question-and-answer sessions.
– Vendors are allowed sufficient time to prepare their proposals.
– The award criteria and decision process are clearly defined. These criteria are
communicated to participating vendors, but are limited to the highlights of the
evaluation process. Communicating detailed evaluation criteria may influence
vendor proposals and is, therefore, not recommended.
• The following types of requirements may be included:
– B usiness requirements defined by the business, specifying the type of product
or service the business needs to execute its activities
– L egal and regulatory requirements, defined by legal
– HR requirements defined by HR, specifying requirements related to the status
of workers, code of conduct and local regulations
– IT requirements defined by IT—Defining IT requirements in a proper
manner requires the enterprise to avoid focusing on solutions. Stakeholders
should define requirements based on enterprise goals and objectives, and
refrain from selecting specific technologies, applications or infrastructures.
As mentioned previously, a potential reason to choose to work with vendors
is to leverage their expertise, capacity and scalability. Restricting the request
for services by preselecting technologies, applications or infrastructures can
potentially endanger the realization of these benefits, due to the enterprise’s
limited knowledge of all potential market solutions. Focusing on enterprise
needs will provide the vendor with a certain degree of freedom to propose the
optimal solution to meet the enterprise’s objectives.
However, this does not mean that technical boundaries can never be defined.
On the contrary, existing technical architectures should be considered to
define limitations and help vendors to better define solutions. In specific
cases, the request can be linked to specific technologies, such as operating

system platforms and databases, or to certain skills, such as information

security and software development language. In any case, the enterprise
should focus on defining the requirements (including any limitations), rather
than on the solution.
– Security requirements defined by the stakeholder responsible for physical and
information security, specifying the security policy with which the vendor
should comply
• Other considerations relative to requirements include:
– The enterprise must have a clear understanding of third parties before starting
any contractual relationship. This is definitely a concern when offshoring or
contracting cloud computing services. Enterprises looking for cost-efficient
alternatives may contract anybody in the world to host data processing or
storage systems, but they must be aware of laws applicable in countries where
the vendor has facilities. Ignorance of applicable laws may expose the enterprise
to potential undesirable consequences. For instance, some countries have laws
that allow the government to access, decrypt and confiscate any data repository
residing in their country. Enterprises contracting with a provider from such a
country are exposing the confidentiality and privacy of their data or, worse, they
may incur economic penalties due to noncompliance with local regulations.
– From a vendor perspective, it is also important to consider what laws are
applicable in the country where the enterprise resides. For example, two vendors
were short-listed when trying to close an outsourcing deal for a help desk. One of
them lost the contract, however, because the vendor was going to control desktops
remotely from another country and, thus, gain access to information from abroad,
which was strictly prohibited by law in the country where the enterprise was
located. The vendor could have avoided the cost of bidding for the job if the
vendor had first learned about compliance requirements with applicable laws.
– When specifying requirements for a product or service, it is important to
leave the decision about how the vendor will provide this service or product
to the vendor’s judgment. Good practice is to describe the business goals and
let the vendor propose how to best achieve them. After all, one of the main
reasons for outsourcing is that vendors have better experience and resources
with solutions and technologies.
– The effort does not end when the requirements are defined. To ensure that
vendor performance will meet enterprise expectations, these requirements
must be properly documented and communicated to the vendor so that:
. The vendor clearly understands what the enterprise needs to accomplish.
. Goals and objectives are clear and measureable.
. All parties know where to find these requirements.
. A formal process to change requirements is defined.
– The enterprise can have clearly defined requirements, but if they are not
communicated in the right way to the vendor, the outcome may be the same
as if the requirements were inappropriately defined.
– Processes: BAI02 Manage requirements definition, BAI03 Manage solutions
identification and build

8. Perform adequate vendor selection:

• Mitigation—A first good practice is to conduct vendor due diligence
activities, which may include vetting customer references, reviewing financial
statements, evaluating market position and longevity, and reviewing control
and compliance reports as applicable (PCI [Payment Card Industry], HIPAA
[Health Information Portability and Accountability Act], SSAE16 [Statements
on Standards for Attestation Engagements], ISO [International Organization for
Standardization], etc.). The financial viability of the vendor should be a major
concern. If the vendor does not have a positive viability outlook, then investing
in a long-term relationship with that vendor may not be the best option for the
enterprise. Moreover, there is no point in imposing financial penalties for not
achieving the required level of service if the vendor does not have the financial
resources to cope with them.
A second good practice in vendor selection is to set up formal evaluation

criteria for vendor selection. Appendix A provides an example of a vendor
selection dashboard to rate the vendor on its contribution to business objectives.
– Processes: APO10 Manage suppliers, APO12 Manage risk
– Enabler: People, Skills and Competencies
9. Cover all relevant life-cycle events during contract drafting:
• Mitigation—The three-tier framework (explained in the following section, Case
Study Illustrating Threats, Risk and Mitigation Actions) can be used to allow
for proper scoping of products and services. This framework gives transparency
to both parties with regard to fee calculation mechanisms and allows for
managing fee adaptations when the parameters of the deliverables change.
Include with this framework a mechanism for (downward) pricing and payment
renegotiation. Because the cost of technology is decreasing quickly, this could
represent a cost-saving factor for the enterprise when included in long-term
contract agreements. Additionally:
– Payment terms should be described in sufficient detail. Vague descriptions
should be avoided and clear agreements on invoicing and payment terms
should be clearly documented in the contract to minimize confusion or
disputes. For example, agreeing to invoice “upon approval of deliverable by
management” could lead to vendor frustration and service disruption if the
approval process is delayed. It is advisable to detail the milestones at which
the enterprise should expect invoices for goods or services and the payment
terms that both parties should follow.
– Contracts should contain specifications for the use and distribution of
software by the vendor. The enterprise may have specific software license
agreements and may be obligated to use specific software. If the vendor
distributes or uses different software, the enterprise may be liable for
noncompliance with license agreements. Furthermore, the use of unlicensed
software may result in legal penalties for the enterprise.

– When problems arise, a properly drafted contract may enable the vendor to
provide fast incident resolution and correction. However, damage may not
be completely avoidable and liability issues may be revealed afterward. That
is why both parties should specify in the contract the liabilities that each
is willing to assume and the insurance available to cover incidents. This
information provides a clear view of the risk that both parties are assuming. It
is good practice to define liability caps to avoid expenditures that could lead
to bankruptcy.
– An indemnification clause should be included in the contract to protect the
enterprise from legal issues related to the vendor performing the contract. An
indemnity clause is very important to ensure that the enterprise is not liable
for another party’s wrongdoing. An indemnification clause is usually referred
to as a “hold harmless” clause where the third party assumes the risk and
offers legal protection from any action arising out of the signed contract.
– A change clause should be included in the contract. During the contract life
cycle, several factors can change or influence the way products or services
are delivered. There may be changes to the service model, pricing, risk or
even legislative requirements. These must be incorporated into contracts
and deliverables. The resulting financial and other implications need to be
approved by both parties before becoming effective. Any significant change
should be negotiated properly before the contract can be modified to reflect
the new agreement.
– When no clause is included in the original contract to guide changes,
negotiations between parties may be difficult and unpleasant. Change clauses
should describe the following:
. How to process changes
. What can be changed
. When changes can be processed
. Who has authority to request and approve changes
. Limits to how much change is allowed
– The best time to negotiate and establish contract change procedures is during
the setup phase. When the vendor is fully integrated with the enterprise and
has developed knowledge and efficiencies, negotiations can be extremely
difficult if there are no formal policies and procedures to follow. This contract
weakness can allow vendors to take advantage of the situation and ask for
premium fees for extra services or for changes to the current contract.
– Processes: APO11 Manage quality, APO12 Manage risk
10. Determine the adequate security and controls needed during the relationship:
• Related threat—T4, T2
• Mitigation—Contracts should contain specifications that are related to
the ownership of the assets that are considered intellectual property of the
enterprise, such as data, information, software programs, manuals and other
written documents. Throughout its life cycle, data ownership should be
specified in the contract to avoid any disputes when contracted services are

terminated. For example, the vendor may provide some proprietary software
to enable the service contracted. This software may require enterprise data to
be stored in the vendor’s database to support operations. What happens to the
ultimate disposition of the data, log files, reports, etc., in the case of contract
termination should be determined by the ownership terms included in the
agreement. If the enterprise fails to include ownership terms in the contract,
the vendor may require additional fees to return data and related assets.
When hiring vendors to provide software, in addition to ownership terms,

the enterprise may include a source code escrow agreement in the contract
to ensure maintenance of the software in case of vendor disruptions. Escrow
agreements are not always related to software; they can pertain to written
documents as well.
During service delivery, the vendor may have access to confidential data
and information. To ensure privacy, security, integrity and confidentiality of
data and information, the enterprise should enforce vendor compliance with
enterprise policies and procedures regarding these matters. The enterprise
should become familiar with the vendor’s policies and procedures, determine
which are more robust, and enforce those. Some vendors may consider
security part of their core services, thus, they may have stronger policies and
procedures. If this is the case, then the enterprise will benefit from enforcing
vendor controls.
The enterprise remains responsible for limiting access to its data. Vendor
access should be extended to data that are needed to deliver the required
services, but no more than that. For example, when working with a database,
the vendor should have access to only the section of the database where
necessary data are stored, not the entire database. In cases where the vendor is
managing data on behalf of the enterprise, security and privacy considerations
must be stipulated in the contract to ensure that the enterprise has a clear
understanding of the following:
– Who will have access to the data
– Where data will be stored
– Backup procedures
– Procedures for destroying data
– Data retention policies
– Capability and willingness to support e-discovery
This information may be particularly critical if the vendor provides services

to competitors.
– Processes: APO11 Manage quality; APO12 Manage risk, MEA01 Monitor,
evaluate and assess performance and conformance
– Enablers: Service, Infrastructure and Applications; Information

11. Set up SLAs:

• Mitigation—For detailed guidance and mitigation strategies regarding SLAs,
see chapter 5. Binding Documents.
12. Set up operating level agreements (OLAs) and underpinning contracts:
• Mitigation—For detailed guidance and mitigation strategies regarding OLAs
and underpinning contracts, see chapter 5 Binding Documents.
13. Set up appropriate vendor performance/service level monitoring
and reporting:
• Mitigation—When defining reporting requirements and service levels, the
enterprise should consider certain reporting specifications, e.g., the party
responsible for defining metrics, collecting information and drafting the
performance reports. Both parties must approve these requirements and
service levels because the information in the reports must be unbiased to
serve as a basis to evaluate the service. Additionally, there should be detailed
descriptions of how the information will be gathered and treated so both
parties feel confident that the report will be based on accurate information.
During the operations phase, vendor performance should be periodically

reviewed to assess the quality of service and adherence to contract conditions.
To facilitate this process, vendors should regularly and transparently report on
the predetermined metrics. Additional self-assessments or independent reviews
of vendor pricing, internal vendor practices and controls may be requested to
ensure reliable and competitive service, compared with alternative suppliers
and market conditions.
Vendor risk should be periodically reviewed to assess whether identified risk

frequencies and impact are still valid and mitigation actions will suffice. If
this is not the case, action plans need to be prepared immediately.
Finally, a periodic evaluation of vendor compliance with enterprise rules and

regulations should be required. To stay current on threats, the chief information
security officer (CISO), IT management and business process owners should
meet periodically with vendors and evaluate their compliance status.

To facilitate and standardize this evaluation process, the enterprise can use
tools such as a strengths, weaknesses, opportunities and threats (SWOT)
analysis; root cause analysis; or any risk assessment framework.
– Processes: APO09 Manage service agreements, APO10 Manage suppliers,
MEA01 Monitor, evaluate and assess performance and conformance
14. Establish a penalties and reward model with the vendor:
• Mitigation—Establish a detailed penalties and reward model, in line with the
risk and rewards that the vendor is facing for the service provisioning. More
guidance on integrating a penalties and reward model SLA can be found in
chapter 5. Binding Documents, in the section on SLAs.
– Processes: APO09 Manage service agreements, APO10 Manage suppliers
15. Conduct adequate vendor relationship management during the life cycle:
• Mitigation—Providing transparency throughout the contract life cycle, from
the first moment of interaction between the vendor and the enterprise until
the termination of the relationship, is a key element to the success of the
collaboration. This mitigation action has been discussed throughout this
publication. The transparency on budget from the vendor side was discussed
in the call for tender section. Creating transparency, on the pricing strategy
from the vendor and the parameters affecting the price, is described in the
case study at the end of this chapter and more precisely by the proposed
three-tier framework. The transparency from the enterprise on the precise
services expected is also included in the case study. The good practice of
providing transparency on performance (vendor side) and performance
evaluation (metrics and evaluation results on the enterprise side) is explained
in the sections about SLAs, in chapter 5.
– Processes: APO08 Manage relationships, APO10 Manage suppliers
– Enabler: Ethics, Culture and Behaviour
16. Review contracts and SLAs on a periodic basis:
•Mitigation—Define a periodic interval for review of contracts and SLAs to
confirm ongoing validity. The interval frequency can depend on the kind of
contract, e.g., duration or value, or the number of parties involved. Validity
needs to be verified because changes to the service model, pricing, risk or
legislative requirements may occur and will have to be incorporated into the
contract or SLA.
Good practice is to include a change clause in the contract. It should provide

guidance on incorporating the changes in the contract or SLA in an easy
way and avoid the need for difficult and unpleasant negotiations between the
parties. For more information, see mitigation action 9 in this section.


– Processes: APO09 Manage service agreements, MEA01 Monitor, evaluate
and assess performance and conformance
17. Conduct vendor risk management:
• Mitigation—Several actions can be taken to conduct vendor risk management.
As discussed in mitigation action 8, “Perform adequate vendor selection,”
due diligence should be the first risk management step to be performed by
the enterprise. Based on that due diligence, a next step for the enterprise is
to develop a detailed risk assessment that identifies all categories of potential
risk that result from outsourcing some activities to a vendor. These categories
can include, but are not limited to, financial, operational, reputational and
compliance/legal risk.
Subsequent to the detailed risk assessment, a risk-based monitoring program

should be set up. Monitoring of vendor performance should include at least
a review and tracking of complaints related to the vendor’s activities because
these form an excellent indicator for vendor performance and related issues.
Finally, the risk assessment should be periodically updated based on the results
of vendor monitoring.
– Processes: APO10 Manage suppliers, APO12 Manage risk
18. Perform an evaluation of compliance with enterprise policies:
• Mitigation—Enterprise rules and policies should be shared with the selected
vendor during the contract phase to create awareness about the internal control
environment and requirements for compliance. Important documents include:
– Enterprise strategy
– Information security policy
– Physical and environmental security policy
– Access control policy
– List of applicable laws and regulations
After the transition-in period, the enterprise should perform periodic

evaluation of the vendor’s compliance with enterprise policies. The frequency
of evaluations depends on the risk to the enterprise if the vendor is not in
compliance with the policy.
– Processes: APO10 Manage suppliers; MEA01 Monitor, evaluate and assess
performance and conformance; MEA03 Monitor, evaluate and assess
compliance with external requirements
– Enablers: Principles, Policies and Frameworks; Information

19. Perform an evaluation of vendor internal controls:

• Mitigation—Discuss the right to audit during contract negotiations to
determine if the enterprise will be allowed to perform compliance audits on
the vendor’s internal controls or if the vendor will provide self-assessment
reports or reports prepared by independent assessors. The option approved
by both parties should be properly documented in the contract to avoid
discussions during the operations phase.
For vendors servicing a large number of clients, a common practice is to

engage a third-party assurance provider. This means that the vendor will
allow an independent provider to conduct audits and prepare a report that can
be used by all of its clients to gain insight into applicable vendor processes.
Customers may use this audit report to support their own internal audits.
An example of such a report is the Service Organization Control (SOC) 2
report, which is used to report on controls at a service organization relevant
to security, availability, processing integrity, confidentiality or privacy. SOC 2
reports address risk of IT-enabled systems and privacy programs beyond the
controls necessary for financial reporting and use predefined standard control
criteria for each of the defined principles, enabling a more direct comparison
of the internal control environment of multiple vendors. More information on
the SOC 2 report is available in the ISACA SOC 2SM User Guide for Report
on Controls at a Service Organization Relevant to Security, Availability,
Processing Integrity, Confidentiality or Privacy, developed by ISACA and the
American Institute of Certified Public Accountants (AICPA).
– Processes: APO10 Manage suppliers; APO12 Manage risk; MEA01
Monitor, evaluate and assess performance and conformance
– Enablers: Organisational Structures; Information
20. Plan and manage the end of the relationship:
• Mitigation–The transition-out phase is a life cycle stage that is likely to be
missing or poorly detailed in the contract. During this stage, the vendor needs
to gradually phase out services, possibly in combination with a transfer of
knowledge and operations to a new vendor. Contracts sometimes cannot
specify when the relationship between the enterprise and the vendor will stop.
Therefore, specific conditions can be added to provide clarity for both parties.
This can be in the form of a time frame or objectives description, e.g., when
certain objectives are met or when the enterprise is mature enough to be able
to provide the service in-house. Good practice is to express objectives in
SMART4 format to eliminate room for misinterpretation.
4
SMART metrics are Specific, Measurable, Attainable, Relevant and Timely.
It is also important to describe how the relationship will come to an end. For
example, a determination should be made as to whether the discontinuation
of services will be gradual (in which the vendor provides support during the
transition-out period) or complete (in which all vendor activities stop at once).
Vendor obligations relative to transfer of knowledge, deliverables or services
to another vendor or to the enterprise should also be defined. These are
important items to discuss and agree on beforehand because, at the end
of the relationship, there is little incentive for the outgoing vendor to do a
proper transfer, unless it is contractually settled and failure to do so may
incur penalties.
Other provisions that should be included in the contract that are related to the
transition-out phase include:
– Buy-back arrangements for equipment and software and a formula for price
determination
– Transfer of relevant subcontractor contracts and leases (e.g., maintenance
and licensing contracts)
– Transfer of data, data structures and methodologies
– Transfer of staff
– Support during the transition
– Processes: APO09 Manage service agreements; APO10 Manage suppliers;
APO12 Manage risk
– Enablers: Services, Infrastructure and Applications; People, Skills and
Competencies; Information
21. Use a vendor management system:
• Related threat—T1, T2, T3, T4
• Mitigation—Depending on the number of vendors, it is good practice to
implement an IT system to store critical information on vendors, such as
order information, contract and SLA information, and billing information.
Most medium-to-high-end vendor management systems also allow for easier
tracking of vendor performance by monitoring KPIs and generating reports
with automatic warning signals.
A cost-benefit analysis should be conducted to identify requirements for a

vendor management system, which may result in using spreadsheets rather
than buying off-the-shelf applications or even implementing fully customized
vendor management systems.
– Processes: APO08 Manage relationships; APO09 Manage service
agreements; APO11 Manage quality; APO12 Manage risk
– Enabler: Services, Infrastructure and Applications

22. Create data and hardware disposal stipulations:

• Mitigation—During the contract life cycle, there could be transfer of data
and/or infrastructure to the vendor. The contract should clearly state how
these data and/or infrastructure will be handed back to the enterprise or
decommissioned at the end of the relationship.
Not all vendor relationships result in transfer of data/infrastructure. Some

vendor relationships are established for a short-term period, e.g., drawings
or sweepstakes, where the vendor is engaged for capturing information and
subsequently is required to dispose of such information. If it is just paper
information, disposal can be performed through burning. If the information is
stored electronically, the contract should clearly stipulate how the vendor will
give assurance to the enterprise that the personally identifiable information is
promptly removed from the vendor’s system.
– Process: APO12 Manage risk
– Enablers: Services, Infrastructure and Applications; Information; Principles,
Policies and Frameworks
Case Study Illustrating Threats, Risk and Mitigating Actions
Background
The IT department of Company ABC has been managing the entire set of business
applications as well as the supporting network infrastructure spread over numerous
European countries.
As a future goal, Company ABC wants to improve the availability and security of
the applications pool and business continuity capabilities. To achieve these targets,
the strategic vision of Company ABC focuses on increasing the maturity of IT
processes to a defined level over a five-year time frame.
As part of Company ABC’s vision, the decision was made to outsource the entire IT
operation and infrastructures.
Initial Solution
After sending out a call for tender, Company ABC received several offers. The
solution that was selected was a large-scale consortium of different companies
that would provide the services in the scope. The agreement was that Company
ABC would be in contact only with an SPoC for all matters related to the contract.
This SPoC would then coordinate with the responsible parties of the consortium,
as shown in figure 6. The consortium’s scope was to take over everything that
Company ABC was doing in-house for IT at that point in time. This included
providing help desk support to all locations, hosting the infrastructure and running
all processes, namely:
• Application life-cycle management
• Testing
• Deployment across several testing and acceptance environments

• Capacity and availability management
• Security management
Figure 6—Initial Case Solution
Client Side Vendor Side
Company SPoC
ABC
Consortium of
different companies
What Happened?
It took only a short period of time to realize that the alignment between Company
ABC’s business objectives and the way the consortium had implemented the
solution was inadequate.
The first indication was the volume of request for change (RFC) requests, and,
more specifically, the way they were executed in the change management process,
which created a large and unexpected workload for the change manager function.
It was determined that this problem was the result of poorly defined workload
expectations and unclear roles and responsibilities. Company ABC was not precise
when defining the commitment that was expected from the consortium to handle
workloads in a timely manner.
Another misalignment between requirements and the solution was discovered

when the consortium analyzed activity reports prepared by the problem manager
function. Legacy elements on top of a highly complex IT environment resulted in
a time-consuming process to properly provide problem resolutions. Specific and
unexpected expertise was also required to advise on root cause analysis. These
problems led to a troubled relationship between Company ABC and the consortium.
In this case, the lack of information caused the consortium to define a delivery
cost model that was misaligned with enterprise expectations. The work-unit cost
per problem charged by the consortium to the enterprise was well below the actual

cost incurred by the consortium. It was evident that the consortium was sustaining
heavy losses when performing problem management. After absorbing the losses
for a while, the consortium stopped focusing on solving problems even when this
behavior incurred penalties. The consortium calculated the cost/charge/penalty
ratios of problem management and decided that ignoring problems was financially
beneficial for them, even if it failed to support Company ABC’s targets.
Dissatisfaction among members of the consortium due to unrealized financial

benefits of the project caused disputes within the group of companies. Furthermore,
consortium members contacted Company ABC directly to start negotiating new terms,
even though Company ABC had clearly requested to deal only with the SPoC.
Some of the frustration with having to interface with companies of the consortium
could have been avoided if Company ABC had clearly stated the interfaces and
communications flows and had a strong consortium agreement that would have
kept discussions internal to the consortium. A solution for the inadequate financial
evaluation is proposed in the following “lessons learned” section, in the form of a
three-tier framework.
Lessons Learned
From the first discussions, both parties need to be clear on the roles and responsibilities
they expect from each other and agree on these together. The enterprise’s requirements
need to be clearly defined and the enterprise must make sure that these requirements
are understood in the same way by the vendor. In addition to making roles and
responsibilities clear, it is pertinent that the process and communication flows also be
clear so that people know when action is expected from them.
To solve the problem of improper financial evaluation of deliverables, a framework

that allows proper scoping of products and services should be used. This framework
gives transparency to both parties with regard to fee calculation mechanisms and
allows for managing fee adaptations when there are changes in the parameters of
the deliverables.
A proposed three-tier framework is shown in figure 7. In the client input section, the
enterprise provides the key parameters that influence the service, e.g., volumes, locations,
service specifications. In the second section of the framework, the vendor defines the
delivery model, which includes any dependencies on the parameters set in the client input
section. By proceeding this way, the vendor creates transparency for the enterprise to
understand which deliverables the vendor will provide, how cost will be calculated, and
what parameters will impact cost. In the cost model section, a price per service or work
unit (defined by the enterprise) can be determined.
Working with the three-tier framework allows for flexibility and scalability. When
parameters change or the values of key parameters change, the vendor has a solid
basis to renegotiate with the enterprise because it is easy to show the impact that the
changes will have on the cost model, via the delivery model. This could help alleviate

frustration and ensures that pricing is no longer an unknown algorithm. The important
consideration here is to include a formal change management process in the original
contract to allow change to the client input and delivery model sections at a later stage
in the relationship (e.g., when key parameters change).
As good practice, the enterprise can provide the vendor with all relevant client
inputs and impose the cost model, i.e., impose a price per deliverable, as part of the
call for tender. This allows the various participating vendors to propose a delivery
model. In doing so, the enterprise will gain insight into the operating model of
each vendor and a better basis of comparison among proposals. For example, for
the setup of a help desk, a vendor from the enterprise’s home country may have a
price per call that is half a foreign vendor’s price per call. However, if the enterprise
includes in the client input a parameter that requires operations in three different
countries, the local vendor’s price per call may be three times more expensive than
the foreign vendor’s price, making the latter a more viable option.
Figure 7—Three-tier Framework
Client Input
• The enterprise defines the key parameters affecting the product or service provisioning.
• The enterprise provides input on the values of the key parameters.
Simplified example—Setting up a help desk:

• The number of locations: five
• The number of countries: three
• The number of languages required to speak by a help desk employee: two
• The number of calls per month: 100,000/month
Delivery Model
• The vendor’s solution architects design a delivery model that takes into account the parameters
from the client input.
• The result of the model is a detailed overview of all the products and services that the vendor will
deliver, the total cost, and transparent detail on the influence that parameters have on cost.

• One help desk person can handle 1,000 calls/month; this means the solution will need 100
employees at a price of Y/employee.
• The help desk will need to be spread out through five locations, increasing the cost/employee
by a factor of 2.3.
• The employees need to speak two languages, increasing the cost/employee by a factor of 1.4.
This results in the following cost model, detailing the full price: (100 × Y ) × 2.3 × 1.4 = Z
Total cost = Z
Cost Model
• In the cost model, a detailed price per service activity or work unit is determined as it will be
delivered and charged to the client.

• For the amount Z, the vendor will handle 100,000 calls/month.
z
• This means that the price per call is 100,000


Chapter 5. Binding Documents 45
Chapter 5. Binding Documents

Throughout the vendor relationship life cycle a number of information items should
be prepared to support and document the steps in the process. Figure 8 shows some
of these information items.
Figure 8—Information Items in the Vendor Relationship Life Cycle
OLA and Vendor

Requirements Call for Vendor Underpinning
Tender SLA Performance
Overview Contract Contracts Reports
The most important binding documents are discussed in the remainder of this chapter.
Templates and sample structures for selected items are provided in the appendices.
Practical guidance on what should be included in a call for tender is available in
appendix B. A high-level legal checklist for nonlegal stakeholders is included in
appendix D, which provides an overview of what legal elements should be taken into
account when drafting a vendor contract. A sample SLA is provided in appendix H.
It is not always clear which documents are binding. In addition to the information
items shown in figure 8, other documents may be binding and have an impact on
the relationship, such as the following:
• Answers from question-and-answer sessions
• Further clarifications document
• Initial proposal
• Presentations
• Best and final offer (BaFO)
Good practice is to stipulate clearly in each document whether or not it is a binding

document and to mention the validity period of the document. It is also advisable to
mention clearly in the contract if there are any other documents that are considered
binding and, therefore, part of the contract agreement.
Call for Tender
A call for tender is the process in which the enterprise requests from potential
vendors a proposal to provide specific services. A call for tender may include one
step or several, depending on the guidelines established in the sourcing strategy,

size of the sourcing organization, or complexity of the product or service needed.

Some enterprises prefer to send out an RFI before the call for tender to identify
candidates and competencies in the market. The outcome of the RFI serves to better
scope the RFP in terms of potential candidates, technologies, delivery models, etc.
When the enterprise has a clear understanding of the product or service needed and
market options, an RFQ can be sent out to invite vendors to present their options.
Some enterprises send an RFP directly, which explains the required products or
services and requests formal offers from available candidates. Figure 2 in chapter 2
illustrates the main differences among these three bidding documents.
Regardless of the number of steps, the call for tender should always make three
elements clear to the vendor:
1. The enterprise context and more specific information on the enterprise IT
governance and management
2. The requested services that the enterprise wants to acquire. It is vital to detail
these service requirements as precisely as possible to enable the vendor to
prepare an adequate offer.
3. The expected roles and responsibilities for the service requirements. Setting
clear expectations in the call for tender phase provides a basis for negotiations,
guarantees that a topic is not overlooked, and may help to avoid confusion or
discussions in a later stage of the collaboration.
General requirements could be added as a conclusion. For further guidance, see

appendices B and C, which include, respectively, a call for tender template and a
checklist on what to include when drafting a call for tender.
Vendor Contract
The enterprise should detail in the vendor contract, among other factors, the
following items:
• Fees
• Roles and responsibilities
• Deliverables
• Workflows
• Fallback procedures
• Penalty and reward mechanisms
• Confidentiality of information
• Intellectual property
• Transition-out procedures
Furthermore, the contract must conform to enterprise standards and legal and
regulatory requirements. Given the differences among local regulations, positive
opportunities as well as negative consequences of the local context should be
considered. A high-level legal checklist for non-legal stakeholders is included in
appendix D.

Another portion of the contract should include the SLA, with specific service levels
and metrics that have been accepted by the vendor. For more information, see the
Service Level Agreements section in this chapter.
The most important inputs for the contract are detailed requirements (business,
IT, compliance, HR, security and legal), the vendor proposal, and the vendor
risk assessment. The vendor risk assessment needs to be completed during the
selection process and should include potential tangible and intangible impacts
that the enterprise could experience. Potential risk related to the products or
services required should also be evaluated and addressed by defining service level
requirements and contingency procedures to mitigate possible vendor failure.
Enterprise rules and policies should be shared with the selected vendor to create
awareness about the internal control environment and requirements for compliance.
Important documents include the following:
• Enterprise strategy
• Information security policy
• Physical and environmental security policy
• Access control policy
• List of applicable laws and regulations
The vendor should provide assurance of compliance prior to initiating the operations
phase. Sometimes, it is recommended to include some of these requirements in
the call for tender to ensure that the vendor will have the capabilities necessary to
comply, before starting negotiations.
Different kinds of contracts exist regarding price structure. All vendor contracts can
be classified into one of the following types:
• Time and means (T&M) contracts—The vendor provides resources per
specifications, and payment is based on the performed work hours and used means.
• Fixed-price contracts (FPC)—The completion or performance of certain tasks
per specifications is expected for payment of a fixed price.
• Hybrid contracts—These contracts are a blend of FPC and T&M contracts.
The type of contract also determines partially where the risk center of gravity is
shifted. An FPC shifts more of the financial risk to the vendor as the vendor needs
to complete a task within a fixed fee. A T&M contract shifts more of the financial
risk to the enterprise and is more difficult for the enterprise to manage.
Service Level Agreements
This section discusses the purpose, structure, pitfalls and benefits of SLAs. Sample
SLAs are provided in appendices F and H. Appendix G contains a checklist of items
to include when drafting an SLA.

SLAs Defined
An SLA is an agreement, preferably documented, between a product or service
provider and the enterprise that defines minimum performance targets for a
deliverable and how they will be measured and reported.
SLAs should:
• Contain precise definitions of services and service terms.
• Include performance levels, performance measures, quality levels and error rates,
service constraints, recharging prices and service charge adjustments.
• Be included in an appendix to the contract and referenced in the master agreement.
• Specify the period of time for which the SLA is valid, the circumstances under
which it can be terminated and how changes can be made.
• Match what the enterprise needs and is prepared to pay for. Setting unreasonably
high SLAs may lead to excessive service costs. Exceeding SLAs is an indication
of potentially paying for more than requested.
The SLA enables customer and vendor accountabilities and expectations to be

clearly understood. Performance against the SLAs can have the following financial
implications:
• Where the vendor exceeds the service level, the vendor may be rewarded by
the enterprise.
• Where the vendor fails to achieve the agreed service level, the vendor may have to
pay a penalty to the enterprise.
• The penalty/reward structure will influence the behavior and performance of
the vendor.
SLA levels are often categorized into bronze, silver and gold classes:
• Bronze—Modest service level targets to guarantee basic availability and support
for noncritical systems
• Silver—Standard service levels in the industry and recommended for initial
discussions with the business
• Gold—Aggressive service levels to prevent any unscheduled downtime of critical
systems that could impact customer operations or end users
How to Create Successful SLAs

Creating appropriate SLAs is not easy. Figure 9 shows some of the issues that may
impact the creation of a robust SLA.

Figure 9—SLA Issues
The enterprise has business

objectives, but does not know • SLA creators often become so focused on details
that the linkage to the business objectives is lost.
how to link them to SLAs.
The enterprise wants to • Turning every operational metric into an SLA can result
in excessive bureaucracy, additional management cost
measure too much. and increased risk of incentivizing undesirable behavior.
The enterprise has no • Some SLAs clearly describe the service to be measured,
experience with how to use but they neglect to include how and when the actual
a particular SLA. calculations should occur.
• Some enterprises focus on defining service obligations

The enterprise did it right, but do not use the governance activities and control
but it still does not work. systems defined in the contract.
When drafting an SLA, two critical parts should be included. The first part
includes the identification of services and performance metrics, as outlined in the
following steps:
1. Scope services and identify the service users.
2. Identify service descriptions and constraints:
• Be certain to define service deliverables because these are what the
enterprise buys.
• Clearly define service boundaries.
3. Collect and analyze service element data:
• Determine what can be measured.
4. Initiate performance definition:
• Design service measures that reflect the enterprise requirements.
• Define achievable delivery standards.
5. Review data, quality and performance:
• Determine current and required service levels.
• Continue to evaluate SLAs as services and requirements change.
Each metric should comply with the following key characteristics:

• The metric is objectively measurable.
• The metric includes a clear statement of the expected end result.
• The metric supports enterprise requirements, including compliance issues.
• The metric focuses on the effectiveness or efficiency of the process that is
being measured.
• The metric allows for meaningful trend or statistical analysis.
• Appropriate industry standards or external standards are applied.
• Enterprise and the vendor accept the metric.

In addition to incentives for incremental improvements, incentives may be awarded

for reengineering processes and improving efficiency (in this case, an appropriate
incentive may be to share with the vendor the resulting economic benefits).
Incentives are a significant tool for an enterprise to use to ensure continuous
improvement efforts from the vendor on both a small and a large scale. For
example, the vendor may want to update equipment for a variety of reasons, such
as it is newer, better, easier to manage or cheaper (bulk purchase externally or
internally), but is constrained in doing so due to missing incentives in the contract.
Implementing gain sharing could remove the actual or perceived imbalance in
benefits and risk and ensure implementation of measures that are beneficial for
both parties.
The second part of the SLA discusses processes related to SLA governance and
change management. It describes how service effectiveness will be tracked, e.g.,
through monthly meetings; how information will be reported and addressed,
e.g., through SLA scorecards; and how penalties will be structured. Furthermore,
this second part explains how changes to the SLA are to be managed. SLA reviews
should follow if the environment changes, expectations or key parameters change,
better metrics or measurement tools are available, wrong behavior is detected, etc.
Changing an SLA involves contractual changes and can potentially have significant
financial impacts; therefore, vendor pricing may also need to be revisited.
SLA Common Pitfalls

There are many common pitfalls in developing an SLA. Figure 10 lists proposed
mitigating actions for each identified pitfall.
Figure 10—SLA Common Pitfalls

Pitfall Mitigation
Focusing on the wrong objectives Map specific services to desired business results when
defining and managing service levels.
Choosing simplistic metrics Select metrics based on the value they provide rather
than ease of measurement.
Using inappropriate terminology and Do not use words that can be interpreted in different
confusing words ways by different people.
Leaving too much room for interpretation •C learly define important performance expectations.
• S hare common means for reporting and interpreting
performance results.
• P rovide a mechanism to manage the SLA throughout
its life cycle to ensure that terms stay current with
the relationship.
Implementing labor-intensive analysis and Automate as many aspects of service level
reporting processes management as possible to reduce resource
requirements and improve the quality and timeliness
of reporting.

The enterprise should not try to impose unrealistic or unreasonable service levels
that result in excessive penalties when the vendor fails to meet them. Unrealistic
expectations and excessive penalties may cause the relationship to deteriorate,
leaving both parties with a bitter feeling about the situation and sometimes leading
to a complete cessation of service. Moreover, requiring very high service levels may
lead to overengineered solutions and high prices.
The opposite of defining unrealistic service levels is defining service levels that are
below the levels required to meet business goals. Defining realistic expectations
may require some up-front work; however, it is critical for the enterprise to define
the service levels that will enable the enterprise to succeed. Inadequate service
levels may lead to underutilization of resources and missed business opportunities
when the full potential of the service is not realized.
Effective vendor management also requires using appropriate terminology and

avoids using confusing words. Using appropriate terminology means that words are
understood by both parties in the same way. For example, “problem” and “incident”
may have the same meaning for non-IT staff; however, when talking to IT-minded
people, those two terms have completely different meanings. If necessary, a glossary
of terms should be included in all binding documents to establish a common ground
for communication between parties. This glossary should include industry terms
and enterprise-specific terminology.
Confusing words are those that can be interpreted in different ways by different
people. Words such as “around,” “approximately,” “no more,” “less than,” “normal”
and “best effort” are words or expressions that are open for interpretation. These
words and others like them are not appropriate and should be avoided, especially
when setting goals and defining metrics. Good practice is to always use SMART
terminology, as follows:
• Specific—Describe the purpose in a clear and concrete way. It should be an
observable action, behavior or outcome to which a number, amount, percentage or
other quantitative data can be connected.
• Measurable—There must be a system, method or procedure for determining the
extent to which the target at any given time has been reached. A SMART goal is
always normative: It is a measure of the quality of the effort.
• Attainable—Targets should be attainable, otherwise the risk exists that motivation
to reach the target is lost and the target is not pursued. Setting attainable goals can
be done by actively involving people in choosing and formulating the objectives.
It is important to empower them during the process.
• Realistic—An easy target may not be interesting because it does not challenge
people nor provide satisfaction. Good practice is to set goals that are just above
the level of ability of the people or enterprise involved. When individuals feel they
have something extra to do to achieve the goal, they feel proud to display their
best work, and this may work as an incentive to achieve the goal. A goal may be
not relevant if set at a level below what is standard.
• Timely—SMART goals have clear start and end dates. This is always true for
short-term goals, but may not be possible for long-term goals.
Benefits of Effective Service Level Management

Well-designed SLAs and mature service level management maximize the
effectiveness of the services they target and manage. This improves business
performance and fosters a better relationship between the enterprise and the
vendor through:
• Better alignment with business objectives
• Ability to manage services proactively
• Greater transparency of service delivery
• Lower service level management overhead
• Better relationships between the enterprise and vendor
OLAs and Underpinning Contracts
As defined in the previous section, an SLA is an agreement between the enterprise

and a product or service provider. This service provider may be an external party;
an internal department, e.g., the IT department for IT services; or a combination of
both. When two or more (internal or external) groups collaborate for the delivery
of these services, they usually define an OLA that applies to all parties involved.
The purpose of an OLA is to stipulate clearly and measurably the service provider’s
internal interdependent support relationships. In this way, the internal services are
properly aligned to provide the intended SLA.
Although OLAs are not as comprehensive and detailed as SLAs, the same two main
sections that are in the SLA should be included in an OLA. The first section identifies
services and performance metrics. The second section in the OLA discusses processes
related to OLA governance and change management. The same pitfalls as discussed
in the SLA section are applicable here. The OLA should be tested and changed only
when necessary, it is not static, and contains start and end dates.
An underpinning contract is an agreement between the vendor and a third party or

subcontractor, whereby the third party provides services or goods to the vendor to
support the vendor’s delivery of the service to the enterprise. Thus the underpinning
contract is a supporting document for the SLA and contains stipulations that are
required to meet the agreed-on SLA targets.
The underpinning contract also contains sections about the identification of services
and performance metrics and about governance and change management, like
the SLA. The same pitfalls can also be taken into account. It is important for the
enterprise to verify whether any stipulations exist in the original contract between
the enterprise and the vendor that state that the vendor is (or is not) permitted, to
outsource part of its activities to a third party. Some enterprises consider it to be too
high a risk for the vendor to outsource part of its activities and, therefore, prohibit
the vendor from outsourcing by so stating explicity in the contract.

Chapter 6. Managing a Cloud Service Provider 53
Chapter 6. Managing a
Cloud Service Provider
In recent years, cloud computing has become more than just another IT buzzword.
It refers to a business trend that is expected to have—and for some enterprises
already has—a significant impact on the way enterprises operate. It is likely that
cloud computing will gain even more importance as both the cloud and cloud
service provider markets mature. Because cloud service providers (CSPs) are, in
many cases, strategic vendors to the enterprise, the concept of cloud computing
constitutes an important part of the vendor management scope.
These vendors, however, have very specific cloud-related risk and challenges.
ISACA’s publication Security Considerations for Cloud Computing provides
practical guidance regarding cloud computing and security considerations of
operating in the cloud. Taking into account the substantial impact that faulty
vendor management of the CSP relationship may have on enterprise operations,
this chapter repeats information on the most important risk as discussed in the
aforementioned publication.
The remainder of this chapter is an excerpt from Security Considerations for

Cloud Computing.
The Key Element of Trust
Security and data privacy concerns are typically seen as critical barriers to the
adoption of cloud services. To mitigate identified risk, cloud users can opt to set
in place service level agreements (SLAs) or they can ask cloud service providers
to meet certain control objectives. In the end, however, the discussion comes down
to the key element of trust, which is a major component in the cloud computing
business model. There can never be sufficient controls and agreements to mitigate
all concerns if trust is a missing factor in the client-supplier relationship.
Therefore, in considering cloud adoption, it is important to know all the parties

involved and their physical locations. The parties involved are not limited to the
CSP and its employees, but also include all vendors that are in close contact
with the cloud service provider and that may come in contact with user data. It
is important to ensure that they are trustworthy (e.g., they are not involved in
fraudulent activities, they are economically solvent). A good rule of thumb is to
select CSPs that have significant history in the cloud services industry and can
provide solid business references.

The answer to the question “How can I rely on a CSP to protect my data?” will be
influenced by a number of aspects:
• The possibility for auditing and the verification of controls. Does the cloud user
have a view of the CSP’s mitigating controls to handle risk—controls related to
security, availability, processing integrity, confidentiality and privacy? In this
context, several standards or good practices are available for CSPs to report on
their security status. The American Institute of Certified Public Accountants
(AICPA) SOC 2 report or any security certification (International Organization for
Standardization [ISO 2700x]) can be used to evaluate the security practices of a
possible CSP. Guidance on how to fully understand and use AICPA SOC 2 reports
can be found in ISACA’s SOC 2SM User Guide, scheduled to be available by the end
of September 2012. The enterprise must identify compliance requirements or select
a recognized security framework (e.g., ISO, Statements on Standards for Attestation
Agreements [SSAE] 16, Payment Card Industry Data Security Standard [PCI
DSS], Health Insurance Portability and Accountability Act [HIPAA], US Sarbanes-
OxleyAct [SOX]) and request proof of compliance from the CSP.
• The CSP financial position and market recognition
• Is the CSP certified or recognized by one or more security standards authorities
(e.g., the National Information Assurance Partnership [NIAP], which is a
US government body operated by the National Security Agency [NSA], and NIST)?
• The availability of business continuity plans (BCPs), disaster recovery plans
(DRPs) and robust backup procedures, taking into account multifacility,
multicountry CSPs
• The quality of the user’s own data and data classification; policies, principles and
frameworks; processes; organizational structures; culture, ethics and behaviour;
services, infrastructure and applications; people, skills and competencies; and risk
appetite (see chapter 4)
• General negotiations and relationship with the service provider: contracts, SLAs,
communication processes, roles and responsibilities matrices, etc.
3. Overview of Security Risk and Threats

Related to Operating in the Cloud
Recent publications and media coverage have discussed the extensive benefits of
migrating to the cloud: better management and allocation of IT physical resources,
flexibility, high scalability, elasticity and cost savings. However, changing from one
environment to another entails some disadvantages as well, e.g., in the form of new
risk or new threats. Enterprises that are considering moving to the cloud must be
aware of the risk and threats involved to decide whether the cloud is an appropriate
solution and which service and deployment models entail a degree of risk that they
can manage and are willing to accept.
Once the enterprise is aware of the risk and threats, it can implement a series of
mitigating actions and controls to reduce or eliminate the threats related to the
service and delivery model it has chosen and to ensure that the benefits of moving
to the cloud are realized as expected.
Visibility as a Critical Factor
The decision to move to the cloud implies that the information assets of the
enterprise will be “managed” by the CSP. However, the enterprise—the owner of the
assets—is likely to have little knowledge or “visibility” into the people, processes
and technology supporting its information assets. The lack of visibility is also
known as “abstraction;” to counter the effects the CSP should provide to customers
full details on how its assets are managed.
The level of abstraction or visibility provided by the CSP becomes extremely

important when evaluating risk. In fact, each service model corresponds to an
abstraction level based on the number of layers in the Internet Protocol (IP) stack
being replaced by the cloud. For this reason, IaaS represents the lowest abstraction
level (infrastructure only) and SaaS the highest (application + middleware +
infrastructure).
The higher the abstraction level, the higher the risk or the number of threats to take
into account because risk is cumulative (figure 1). However, CSPs often offer only
visibility into the cloud stack corresponding to the service model chosen. Security
professionals must be aware of this factor when evaluating a move to the cloud. A
common mistake is to assume that SaaS will not also be subject to risk related to
infrastructure; however, risk and threats are there. They are on a layer that is less
visible because it is no longer under the operational responsibility of the enterprise,
but is under that of the CSP.
Figure 1—Cloud Service Models

Data and Application
Security Risk
Per SLA
SaaS
Software as a Service
Client Assumes Presentation Presentation
Modality Platform
All Data and Application
APIs
Security Risk
Applications
PaaS
Data Metadata Content
Platform as a Service
IaaS
Infrastructure as a Service Integration and Middleware Integration and Middleware
APIs APIs APIs

Infrastructure as a Service (IaaS)
Software as a Service (SaaS)

Platform as a Service (PaaS)
Platform as a Service (PaaS)
Core Connectivity Core Connectivity Core Connectivity

and Delivery and Delivery and Delivery
Abstraction Abstraction Abstraction
Hardware Hardware Hardware
Facilities Facilities Facilities
Source: Universal Model, © Cloud Security Alliance. Used with permission.

Risk Factors by Service Model
S1. IaaS
With IaaS, the CSP provides the enterprise with fundamental computing
resources/equipment (storage, hardware, servers and network components) while the
enterprise remains in control of the operating system (OS) and applications installed.
Risk-decreasing factors:
S1.A Scalability and elasticity—Lack of physical resources is no longer an
issue. Due to the scalable nature of cloud technologies, the CSP can
provide capacity on demand at low cost to support peak loads (expected or
unexpected). Elasticity eliminates overprovisioning and underprovisioning
of IT resources, allowing better cost optimization. This becomes a great
advantage for resilience when defensive measures or resources need to be
expanded quickly (e.g., during DDoS attacks).
Risk affected—Unavailability
S1.B DRP and backup—CSPs should already have in place, as common practice,
disaster recovery and backup procedures. However, recovery point objective
(RPO), recovery time objective (RTO), and backup testing frequency and
procedures provided by the CSP should be consistent with the enterprise
security policy.
Risk affected—Unavailability, loss
S1.C Patch management—Cloud infrastructures are commonly based on
hypervisors and are controlled through a central hypervisor manager or
client. The hypervisor manager allows the necessary patches to be applied
across the infrastructure in a short time, reducing the time available for a new
vulnerability to be exploited.
Risk affected—Unavailability, loss, theft, disclosure
Risk-increasing factors:
S1.D Legal transborder requirements—CSPs are often transborder, and different
countries have different legal requirements, especially concerning personal
private information. The enterprise might be committing a violation of
regulations in other countries when storing, processing or transmitting data
within the CSP’s infrastructure without the necessary compliance controls.
Furthermore, government entities in the hosting country may require access
to the enterprise’s information with or without proper notification.
Risk affected—Disclosure
S1.E Multitenancy and isolation failure—One of the primary benefits of the
cloud is the ability to perform dynamic allocation of physical resources when
required. The most common approach is a multi-tenant environment (public
cloud), where different entities share a pool of resources, including storage,
hardware and network components. All resources allocated to a particular
tenant should be “isolated” and protected to avoid disclosure of information
to other tenants. For example, when allocated storage is no longer needed

by a client it can be freely reallocated to another enterprise. In that case,

sensitive data could be disclosed if the storage has not been scrubbed
thoroughly (e.g., using forensic software).
Risk affected—Theft, disclosure
S1.F Lack of visibility surrounding technical security measures in place—For any
infrastructure, intrusion detection systems (IDS)/intrusion prevention systems
(IPS) and security incident and event management (SIEM) capabilities must
be in place. It is the responsibility of the CSP to provide these capabilities to
its customers. To ensure that there are no security gaps, the security policy and
governance of the CSP should match those of the enterprise.
S1.G Absence of DRP and backup—The absence of a proper DRP or backup
procedures implies a high risk for any enterprise. CSPs should provide such
basic preventive measures aligned with the enterprise’s business needs (in
terms of RTO/RPO).
S1.H Physical security—In an IaaS model, physical computer resources are shared
with other entities in the cloud. If physical access to the CSP’s infrastructure
is granted to one entity, that entity could potentially access information
assets of other entities. The CSP is responsible for applying physical security
measures to protect assets against destruction or unauthorized access.
S1.I Data disposal—Proper disposal of data is imperative to prevent unauthorized
disclosure. If appropriate measures are not taken by the CSP, information
assets could be sent (without approval) to countries where the data can be
legally disclosed due to different regulations concerning sensitive data. Disks
could be replaced, recycled or upgraded without proper cleaning so that the
information still remains within storage and can later be retrieved. When a
contract expires, CSPs should ensure the safe disposal or destruction of any
previous backups.
Risk affected—Disclosure
S1.J Offshoring infrastructure—Offshoring of key infrastructure expands the
attack surface area considerably. In practice this means that the information
assets in the cloud need to integrate back to other noncloud-based assets
within the boundaries of the enterprise. These communications (normally
done through border gateway devices) could be insecure, exposing both the
cloud and internal infrastructures.
S1.K Virtual machine (VM) security maintenance—IaaS providers allow
consumers to create VMs in various states (e.g., active, running, suspended
and off). Although the CSP could be involved, the maintenance of security
updates is generally the responsibility of the customer only. An inactive
VM could be easily overlooked and important security patches could be left
unapplied. This out-of-date VM could become compromised when activated.

Cloud provider authenticity—Although communications between the

S1.L
enterprise and the cloud provider can be secured with technical means
(encryption, virtual private network [VPN], mutual authentication, etc.) it is
the consumer’s responsibility to check the identity of the cloud provider to
ensure that it is not an imposter.
S2. PaaS
PaaS adds a layer to IaaS by providing the capability to deploy applications in
a cloud infrastructure. The applications are developed using the programming
languages and tools supported by the CSP. Thus, physical support, OS and
programming tools are the responsibility of the CSP, while the applications and the
data remain under the control of the enterprise. This service model entails the same
impacts on risk as IaaS, plus the following factors.
Risk-decreasing factor:
S2.A Short development time—Using the service oriented architecture (SOA)
library provided by the CSP, applications can be developed and tested within
a reduced time frame because SOA provides a common framework for
application development.
S2.B Application mapping—If current applications are not perfectly aligned with
the capabilities provided by the CSP, additional undesirable features (and
vulnerabilities) could be introduced.
S2.C SOA-related vulnerabilities—Security for SOA presents new challenges
because vulnerabilities arise not only from the individual elements, but
also from their mutual interaction. Because the SOA libraries are under the
responsibility of the CSP and are not completely visible to the enterprise,
there may exist unnoticed application vulnerabilities.
S2.D Application disposal—When applications are developed in a PaaS
environment, originals and backups should always be available. In the event
of a contract termination, the details of the application could be disclosed
and used to create more selective attacks on applications.

S3. SaaS
In a SaaS model, the CSP provides to the enterprise the capability to use
applications running on the cloud infrastructure. The enterprise, in turn, provides to
the CSP the data necessary to run the application. The physical infrastructure, OS,
applications and data are the responsibility of the CSP. The enterprise has only the
role of client/user. This service model entails the same impacts on risk as PaaS, plus
the following factors.
S3.A Improved security—CSPs depend on the good reputation of their software
capabilities to maintain their SaaS offering. Consequently, they introduce
additional features to improve the resilience of their software (e.g., security
testing or strict versioning) or to inform users about the exact state of their
business application (e.g., specific software logging and monitoring).
S3.B Application patch management—Due to the fact that the SaaS application
service is managed globally and only by the CSPs, application patch
management is more effective, allowing patches to be deployed in little time
with limited impact.
S3.C Data ownership—The CSP provides the applications and the customer
provides the data. If data ownership is not clearly defined, the CSP could
refuse access to data when required or even demand fees to return the data
once the service contracts are terminated.
Risk affected—Unavailability, loss, disclosure
S3.D Data disposal—In the event of a contract termination, the data fed into the
CSP’s application must be erased immediately using the necessary tools to
avoid disclosures and confidentiality breaches (forensic cleaning may be
required for sensitive data).
S3.E Lack of visibility into software systems development life cycle (SDLC)—
Enterprises that use cloud applications have little visibility into the software
SDLC. Customers do not know in detail how the applications were developed
and what security considerations were taken into account during the SDLC.
This could lead to an imbalance between the security provided by the
application and the security required by customers/users.
S3.F Identity and access management (IAM)—To maximize their revenues,
CSPs offer their services and applications to several customers concurrently.
Those customers share servers, applications and, eventually, data. If data
access is not properly managed by the CSP application, one customer could
obtain access to another customer’s data.
Risk affected—Loss, theft, disclosure

S3.G Exit strategy—Currently, there is very little available in terms of tools,

procedures or other offerings to facilitate data or service portability from
CSP to CSP. This can make it very difficult for the enterprise to migrate
from one CSP to another or to bring services back in-house. It can also result
in serious business disruption or failure should the CSP go bankrupt, face
legal action, or be the potential target for an acquisition (with the likelihood
of sudden changes in CSP policies and any agreements in place). If the
customer-CSP relationship goes sour and the enterprise wants to bring the
data back in-house, the question of how to securely render the data becomes
critical because the in-house applications may have been decommissioned or
“sunsetted” and there is no application available to render the data.
S3.H Broad exposure of applications—In a cloud environment, the applications
offered by the CSP have broader exposure which increases the attack space.
Additionally, it is quite common that those applications still need to integrate
back to other noncloud applications within the boundaries of the enterprise.
Standard network firewalls and access controls are sometimes insufficient to
protect the applications and their external interactions. Additional security
measures may be required.
Risk affected—Unavailability, loss, disclosure
S3.I Ease to contract SaaS—Business organizations may contract cloud
applications without proper procurement and approval oversight, thus
bypassing compliance with internal enterprise policies.
S3.J Lack of control of the release management process—As described before,
CSPs are able to introduce patches in their applications quickly. These
deployments are often done without the approval (or even the knowledge)
of the application users for practical reasons: if an application is used by
hundreds of different enterprises, it would take an extremely long time for
a CSP to look for the formal approval of every customer. In this case, the
enterprise could have no control (or no view) of the release management
process and could be subject to unexpected side effects.
S3.K Browser vulnerabilities—As a common practice, applications offered
by SaaS providers are accessible to customers via secure communication
through a web browser. Web browsers are a common target for malware
and attacks. If the customer’s browser becomes infected, the access to the
application can be compromised as well.
Risk Factors by Deployment Model
Cloud deployment models do not have the same abstraction as cloud service
models. That is, risk is not cumulative, but particular to each model. However,
“trust” among the different entities (CSP, customers, CSP’s third-party service
providers, etc.) is an important factor—not just trust between the CSP and the
customer, but enough trust in the other tenants sharing computing resources
hosting the enterprise’s information assets. If a user abuses the infrastructure and
services of the public cloud, the entire infrastructure might be at risk of failure,
theft or seizure (for forensics), including the services used by other enterprises. It
is important as part of the decision process to carefully consider which assets can
securely be hosted in a public cloud and which cannot.
D1. Public Cloud

In a public cloud, the CSP shares infrastructure and resources among various
unrelated enterprises and individuals.
D1.A Public reputation—Providers of public cloud services are aware that they are
generally perceived as more “risky.” It is critical for them to ensure a good
reputation as a secure provider or customers will simply move elsewhere.
D1.B Full sharing of the cloud (data pooling)—The cloud infrastructure is
shared by multiple tenants of the cloud service provider. These tenants have
no relation to the enterprise or other tenants in the same space, therefore no
common interest and concerns for security.
D1.C Collateral damage—If one tenant of a public cloud is attacked, there could
be an impact to the other tenants of the same CSP, even if they are not
the intended target (e.g., DDoS). Another possible scenario of collateral
damage could be a public cloud IaaS that is affected by an attack exploiting
vulnerabilities of software installed by one of the tenants.
D2. Community Cloud

In the community cloud, cloud services are deployed for the use of a group of
entities who share an inherent level of “trust.” In some cases, all the entities are
subject to a common security policy (thus making the trust factor stronger). In other
cases, there is no common security strategy or policy. As described previously, there
are on-site and off-site community clouds.
D2.A Same group of entities—The component of “trust” among the entities in
a community cloud makes the level of risk lower than in a public cloud.
(However, it remains higher than in a private cloud.)
D2.B Dedicated access for the community—Dedicated access can be configured
for authorized community users only.

Risk-increasing factor:
D2.C Sharing of the cloud—Different entities may have different security
measures or security requirements in place, even if they belong to the
same enterprise. This could render an entity at risk because of the faulty
procedures or SLAs of another entity, or simply because of differing security
levels for the same type of data.
Risk affected—Loss, theft, disclosure
D3. Private Cloud

In a private cloud, cloud services are deployed for the exclusive use of one
enterprise. No interaction with other entities is allowed within the cloud. As
described previously, there are on-site and off-site private clouds.
D3.A Can be built on-premises—Physical or location-related considerations can
be more closely controlled by the enterprise because the cloud infrastructure
can be located on the enterprise’s premises. Global enterprise security
policies would apply.
D3.B Performance—Affects on-site private clouds. Because the private cloud is
deployed inside the firewall on the enterprise’s intranet, transfer rates are
dramatically increased (fewer nodes to cross). Storage capacity can also be
higher; private clouds usually start with a few terabytes and can be increased
by adding disks.
D3.C Application compatibility—While applications that have already been confirmed
to be virtualization-friendly are likely to run well in a private cloud environment,
problems can occur with older and/or customized software that assumes direct
access to resources. Larger applications that currently run on dedicated specialized
clusters with hardwiring into proprietary runtime and management environments
may also be questionable candidates for migration, at least until standards settle
and vendors take steps to make their solutions private-cloud-compatible. In the
meantime, compatibility testing and remediation are critical.
D3.D Investments required—Making a business case for shared infrastructure
and the necessary training or recruitment to acquire associated skills is
notoriously hard at the best of times. Although the word “cloud” has a high
profile, messages from vendors and service providers are often confusing
and contradictory, making seeking support from senior stakeholders even
more of an issue. If the head of finance thinks cloud is all about getting rid
of infrastructure, it can be difficult to explain that investments are needed in
new equipment, software and tools. The enterprise must conduct a cost-benefit
analysis and prepare a business case to determine whether the cloud is a viable
solution to meet specific business requirements, and justify any expenses.
Risk affected—Cost
Cloud IT skills required—Affects on-site private clouds. Building a private

D3.E
cloud within the enterprise infrastructure seems the best option in terms of
security. However, the maintenance of cloud infrastructures requires specific
cloud IT skills in addition to the traditional IT skills, thus increasing the
required initial investment and maintenance costs.
Risk affected—Cost
D4. Hybrid Cloud

Hybrid cloud is a model that allows enterprises to create a mix of public,
community and private clouds, depending on the level of “trust” required for their
information assets. For example, an enterprise could decide that its web portals can
be migrated to a public cloud, but its main business application should be migrated
to a private cloud, this combination will create a hybrid cloud model.
Because hybrid clouds are a mix of the other three models, their risk-increasing or
risk-decreasing factors are the same as those models. There is, however, one
risk-increasing factor related mainly to this model:
D4.A Cloud-interdependency—If the enterprise mixes two or more different
types of clouds, strict identity controls and strong credentials will be needed
to allow one cloud to have access to another. This is similar to a common
network infrastructure problem: how to allow access from a low-level
security zone to a high-level security zone?
Overview of Threats and Mitigating Actions
When considering these implementation strategies, service models and related risk,
it is noteworthy that most of the risk-increasing factors affect theft and disclosure
while most of the risk-decreasing factors affect unavailability and loss. This could
be interpreted as a trade-off.
Risk-decreasing factors are exploited through the implementation of controls to

ensure that the enterprise receives the full benefits of the cloud. Control objectives
for cloud operations are covered extensively in ISACA’s publication IT Control
Objectives for Cloud Computing: Controls and Assurance in the Cloud.
This section addresses the possible threats that could exploit any of the risk-increasing
factors previously described. It also maps the threats to mitigating actions found in
COBIT 5 for Information Security, which explains in more detail selected terminology
and how to implement certain actions within the enterprise. (A table mapping threats
and mitigating actions can be found in the appendices section.)
With the implementation of these mitigation actions, the impact and probability of
a risk event are greatly reduced, depending on the level of severity of the controls
involved. But risk and threats still exist, although reduced. Specific risk assessments
must be conducted periodically to evaluate the risk situation of the assets specific to
the enterprise and identify improvement opportunities.
Technical 3
A. Vulnerable access management (infrastructure and application, public cloud):
• Related risk factors: S1.D, S3.F, D1.B, D2.C
• Description: Information assets could be accessed by unauthorized entities due
to faulty or vulnerable access management measures or processes. This could
result from a forgery/theft of legitimate credentials or a common technical
practice (e.g., administrator permissions override).
• Mitigation:
– A contractual agreement is necessary to officially clarify who is allowed to
access the enterprise’s information, naming specific roles for CSP employees
and external partners.
– Request that the CSP provide detailed technical specifications of its IAM
system for the enterprise’s CISO (or equivalent authority) to review and
approve. If necessary, include additional controls to ensure robustness of the
CSP’s IAM system. Most CSPs will not provide such details due to internal
security policies, but the enterprise can request controls and benchmarks as
an alternative (e.g., result of penetration testing on the CSP’s IAM systems).
– Use corporate IAM systems instead of CSP’s IAM systems. The IAM remains
the responsibility of the enterprise, so no access to assets can be granted
without the knowledge of the enterprise. It requires the approval of the CSP
and the establishment of a secure channel between the CSP infrastructure and
the corporate IAM system.
• Related guidance in COBIT 5 for Information Security:
– Appendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler
. A.2 Information Security Policy
– Appendix F. Detailed Guidance: Services, Infrastructure and Applications
Enabler
. F.6 User Access and Access Rights in Line With Business Requirements
. F.10 Monitoring and Alert Services for Security-related Events
B. Data visible to other tenants when resources are allocated dynamically
• Related risk factor: S1.E
• Description: This refers to data that have been stored in memory space or
disk space that can be recovered by other entities sharing the cloud by using
forensics techniques.
• Mitigation:
and external partners. All controls protecting the enterprise’s information
assets must be clearly documented in the contract agreement or SLA.
– Encrypt all sensitive assets that are being migrated to the CSP, and ensure
that proper key management processes are in place. This will consume part
of the allocated resources due to the encrypt/decrypt process and global
performance can be affected.
– Request the CSP’s technical specifications and controls to ensure that the data
are properly wiped when requested.
– Use a private cloud deployment model (no multitenancy).
3
elated guidance on technical threats and mitigating actions can also be found in COBIT 5, DSS05
R
Manage security services.

– Appendix G. Detailed Guidance: People, Skills and Competencies Enabler:
. G.3 Information Risk Management
. G.6 Information Assessment and Testing and Compliance
Enabler:
. F.5 Adequately Secured and Configured Systems in Line With Security
Requirements and Security Architecture
. F.9 Security Testing
C. Multitenancy visibility:
• Related risk factors: S1.E, D1.B, D2.C
• Description: Due to the nature of multitenancy, some assets (e.g., routing
tables, media access controls [MAC] addresses, internal IP addresses, local
area network [LAN] traffic) can be visible to other entities in the same cloud.
Malicious entities in the cloud could take advantage of the information; for
example, by utilizing shared routing tables to map the internal network topology
of an enterprise, preparing the way for an internal attack.
• Mitigation:
– R equest the CSP’s technical details for CISO (or equivalent authority) approval
and require additional controls to ensure data privacy, when necessary.
and external partners. All controls protecting the enterprise’s information
assets must be clearly documented in the contract agreement or SLA.
– Appendix E. Detailed Guidance: Information Enabler:
. E.8 Information Security Review Reports
– Appendix C. Detailed Guidance: Organizational Structures Enabler:
. C.1 Chief Information Security Officer (CISO)
Enabler:
D. Hypervisor attacks:
• Description: Hypervisors are vital for server virtualization. They provide the
link between virtual machines and the underlying physical resources required to
run the machines by using hypercalls (similar to system calls, but for virtualized
systems). An attacker using a virtual machine in the same cloud could fake
hypercalls to inject malicious code or trigger bugs in the hypervisor. This could
potentially be used to violate confidentiality or integrity of other virtual machines
or crash the hypervisor (similar to a DDoS attack).
• Mitigation:
– Request CSP’s internal SLA for hypervisor vulnerability management, patch
management and release management when new hypervisor vulnerabilities are
discovered. The SLA must contain detailed specifications about vulnerability
classification and actions taken according to the severity level.

– Appendix B. Detailed Guidance: Processes Enabler:
. B.2 Align, Plan and Organize: APO09 Manage Service Agreements
– Appendix A. Detailed Guidance: Principles, Policies and Framework Enabler:
E. Application attacks:
• Related risk factor: S3.H
• Description: Due to the nature of SaaS, the applications offered by a CSP are
more broadly exposed. Because they can be the target of massive and elaborate
application attacks, additional security measures (besides standard network
firewalls) are required to protect them.
• Mitigation:
– Request that the CSP implements application firewalls, antivirus and anti-
malware tools.
– The SLA must contain detailed specifications about vulnerability
classification and actions taken according to the severity level, which must
align with corporate policies and procedures for similar events.
. G.5 Information Security Operations
Enabler:
F. Application compatibility
• Related risk factor: D3.C
• Description: In a virtualized environment, direct access to resources is no
longer possible (the hypervisor stays in the middle). This could generate issues
with older and/or customized software that could go unnoticed until it is too
late to fall back.
• Mitigation:
– Evaluate extensively the design and requirements of application candidates
to move to the cloud and/or request the CSP a test period to identify possible
issues.
– Require continuous communication and notification of major changes to
ensure that compatibility testing is included in the change plans.
. B.3 Build, Acquire and Implement: BAI02 Manage Requirements
Definition
. E.6 Information Security Requirements
Enabler:
. F.3 Secure Development
G. Collateral damage
• Description: The enterprise can be affected by issues involving other entities
sharing the cloud. For example, DDoS attacks affecting another entity in the
cloud can leave the enterprise without access to business applications (for SaaS
models) or extra computing resources to handle peak loads (for IaaS models).
• Mitigation:
– Ask the CSP to include the enterprise in its incident management process that
deals with notification of collateral events.
– Include contract clauses and controls to ensure that the enterprise’s contracted
capacity is always available and cannot be directed to other tenants without
approval.
Enabler:
. F.8 Adequate Incident Response
H. SaaS access security
• Related risk factor: S3.K
• Description: Access to SaaS applications (either via browser or specific
end-user clients) must be secure in order to control the exposure to attacks and
protect the enterprise and his assets.
• Mitigation:
– Use hardened web browsers and/or specific end-user client applications
which include appropriate security measures (anti-malware, encryption,
sandboxes, etc.).
– Use secure virtual desktops or specific browser clients when connecting to
cloud applications.
– Educate corporate users about the risk of running SaaS applications using
insecure devices.
Enabler:
. F.6 User Access and Access Rights in Line With Business Requirements
. G.5 Information Security Operations
I. Outdated VM security
• Related risk factor: S1.K
• Description: An inactive VM could be easily overlooked and important
security patches could be left unapplied. This out-of-date VM could become
compromised when activated and expose other VM connected to the cloud.

• Mitigation:
– Introduce procedures within the enterprise to verify the state of software
security updates prior to the activation of any VMs.
– Contractually request the CSP to apply security patches on inactive VMs.
– Appendix A. Detailed Guidance: Principles, Policies and Framework
Enabler:
Enabler:
. F.5 Adequately Secured and Configured Systems, Aligned With Security
Regulatory 4
A. Asset ownership
• Related risk factors: S2.D, S3.C
• Description: Any asset (data, application or process) migrated to a CSP could be
legally owned by the CSP based on contract terms. Thus, the enterprise can lose
sensitive data or have data disclosed because the enterprise is no longer the sole
legal owner of the asset. In the event of contract termination, the enterprise could
even be subject (by contract) to pay fees to retrieve its own assets.
• Mitigation:
– Include terms in the contract with the CSP that ensure that the enterprise
remains the sole legal owner of any asset migrated to the CSP.
– Encrypt all sensitive assets being migrated to the CSP prior to the migration
to prevent disclosure and ensure proper key management is in place. This can
affect the performance of the system.
– Appendix C. Detailed Guidance: Organizational Structures Enabler:
. C.5 Information Custodians/Business Owners
B. Asset disposal
• Related risk factors: S1.I, S2.E, S3.D
• Description: In the event of contract termination, to prevent disclosure of
the enterprise’s assets, those assets should be removed from the cloud using
tools and processes commensurate to data classification; forensic tools
may be necessary to remove sensitive data (or other tools that ensure a
complete wipeout).
• Mitigation:
– Request CSP’s technical specifications and controls that ensure that data are
properly wiped and backup media are destroyed when requested.
– Include terms in the contract that require, upon contract expiration or any
event ending the contract, a mandatory data wipe carried out under the
enterprise’s review.
4
elated guidance on regulatory threats and mitigating actions can be found in COBIT 5, MEA03
R
Monitor, evaluate and assess compliance with external requirements.
C. Asset location
• Related risk factor: S1.D
• Description: Technical information assets (data, logs, etc.) are subject to the
regulations of the country where they are stored or processed. In the cloud, an
enterprise may, without notification, migrate information assets to countries
where regulations are less restrictive or their transmission is prohibited
(personal information in particular). Unauthorized entities that cannot have
access to assets in one country may be able to obtain legal access in another
country. Conversely, if assets are moved to countries with stricter regulations,
the enterprise can be subject to legal actions and fines for noncompliance.
• Mitigation:
– Request the CSP’s list of infrastructure locations and verify that regulation in
those locations is aligned with the enterprise’s requirements.
– Include terms in the service contract to restrict the moving of enterprise
assets to only those areas known to be compliant with the enterprise’s own
regulation.
– To prevent disclosure, encrypt any asset prior to migration to the CSP, and
ensure proper key management is in place.
. G.4 Information Security Architecture Development
Enabler:
. F.2 Security Awareness
Information Security Governance5

A. Physical security on all premises where data/applications are stored
• Related risk factor: S1.H
• Description: Physical security is required in any infrastructure. When the
enterprise migrates assets to a cloud infrastructure, those assets are still subject
to the corporate security policy, but they can also be physically accessed by the
CSP’s staff, which is subject to the CSP’s security policy. There could be a gap
between the security measures provided by the CSP and the requirements of the
enterprise.
• Mitigation:
– Request the CSP’s physical security policy and ensure that it is aligned with
the enterprise’s security policy.
– Request that the CSP provide proof of independent security reviews or
certification reports that meet the enterprise’s compliance requirements (e.g.,
AICPA SSAE 16 SOC 2 report, SOX, PCI DSS, HIPAA, ISO certification).
– Include in the contract language that requires the CSP to be aligned with the
enterprise’s security policy and to implement necessary controls to ensure it.
– Request the CSP’s disaster recovery plans and ensure that they contain the
necessary countermeasures to protect physical assets during and after a disaster.
5
elated guidance on information security governance threats and mitigating actions can be found in
R
COBIT 5, EDM01 through EDM05 processes.

– Appendix E. Detailed Guidance: Information Enabler
– Appendix A. Detailed Guidance: Principles, Policies and Frameworks Enabler
B. Visibility of the security measures put in place by the CSP:
• Related risk factor: S1.F
• Description: The cloud is similar to any infrastructure in that security measures
(technology and processes) should be in place to prevent security attacks. The
security measures provided by the CSP should be aligned with the requirements
of the enterprise, including management of security incidents.
• Mitigation:
– Request the CSP’s detailed schemes of the technical security measures in
place and determine whether they meet the requirements of the enterprise.
– Include in the contract language that requires the CSP to provide the
enterprise regular reporting on security (incident reports, intrusion detection
system [IDS]/intrusion prevention system [IPS] logs, etc.).
– Request the CSP’s security incident management process to be applied to
the enterprise’s assets and ensure that it is aligned with the enterprise’s own
security policy.
– Appendix E. Detailed Guidance: Information Enabler
. E.8 Information Security Review Reports
. E.9 Information Security Dashboard
Enabler:
C. Media management:
• Related risk factor: S1.I
• Description: Data media must be disposed in a secure way to avoid data
leakage and disclosure. Data wipeout procedures must ensure data cannot be
reproduced when data media is designated for recycle or disposal. Controls
should be in place during transportation (encryption and physical security).
This should be specified in the CSP security policy and contract SLA.
• Mitigation:
– R equest the CSP’s process and techniques in place for data media disposal
and evaluate whether they meet the requirements of the enterprise.
– Include in the contract language that requires the CSP to comply with the
enterprise’s security policy.
– Appendix B. Detailed Guidance: Processes Enabler
. B. 3 Build, Acquire and Implement: BAI08 Manage Knowledge

D. Secure software SDLC:

• Description: When using SaaS services, the enterprise must be sure that the
applications will meet its security requirements. This will reduce the risk of
theft, disclosure and unavailability.
• Mitigation:
– Request the CSP’s details about the software SDLC policy and procedures
in place and ensure that the security measures introduced into the design are
compliant with the requirements of the enterprise.
. B . 3 Build, Acquire and Implement: BAI03 Manage Solutions
Identification and Build
Enabler:
. F.3 Secure Development
E. Common security policy for community clouds:
• Description: Community clouds share resources among different entities that
belong to the same group (or community) and thereby possess a certain level
of mutual “trust.” This trust must be regulated by a common security policy.
Otherwise, an attack on the “weakest link” of the group could place all the
group’s entities in danger.
• Mitigation:
– Ensure that a global security policy specifying minimum requirements is
applied to all entities sharing a community cloud.
– Appendix 5. Detailed Guidance: Principles, Policies and Framework Enabler:
. E.2 Information Security Strategy
F. Service termination issues
• Related risk factor: S3.G
• Description: Currently, there is very little available in terms of tools,
procedures or other offerings to facilitate data or service portability from CSP
to CSP. This can make it very difficult for the enterprise to migrate from one
CSP to another or to bring services back in-house. It can also result in serious

business disruption or failure should the CSP go bankrupt, face legal action, or
be the potential target for an acquisition (with the likelihood of sudden changes
in CSP policies and any agreements in place). Another possibility is the “run
on the banks” scenario, in which there is a crisis of confidence in the CSP’s
financial position resulting in a mass exit and withdrawal on first-come,
first-served basis. If there are limits to the amount of content that can be
withdrawn in a given time frame, then the enterprise might not be able to retrieve
all its data in the time specified. Another possibility may occur if the enterprise
decides, for any reason, to end the relationship with the CSP. The complexity of
the business logic and data models could make it impossible for the enterprise to
extract its data, reconstruct the business logic and rebuild the applications.
• Mitigation:
– Ensure by contract or SLA with the CSP an exit strategy that specifies the
terms that should trigger the retrieval of the enterprise’s assets in the time
frame required by the enterprise.
– Implement a DRP, taking into account the possibility of complete CSP
disruption.
. B.2 Align, Plan and Organize: APO09 Manage Service Agreements
. B.4 Deliver, Service and Support: DSS04 Manage Continuity
G. Solid enterprise governance:
• Related risk factor: S3.I
• Description: Enterprises turn to CSPs in search of solutions that can be
implemented easily and at low cost. This ease can be tempting, especially when
the enterprise is facing urgent deadlines that require an urgent solution (e.g.,
the expiration of application licenses or the need of more computing capacity).
This can become an issue because enterprises may contract cloud applications
without proper procurement and approval oversight, thus bypassing compliance
with internal policies.
• Mitigation:
– Ensure that internal governance controls are in place within the enterprise to
involve the necessary governance organization (legal, compliance, finance,
etc.) during the decision process of migrating to cloud services.
. B.1 Evaluate, Direct and Monitor: EDM01 Ensure Governance Framework
Setting and Maintenance.
. B.5 Monitor, Evaluate and Assess: MEA02 Monitor, Evaluate and Assess
the System of Internal Control

H. Support for audit and forensic investigations.

• Related risk factor: S1.F, S1.L
• Description: Security audits and forensic investigations are vital to the enterprise
to evaluate the security measures of the CSP (preventive and corrective), and
in some cases the CSP itself (for example, to authenticate the CSP). This raises
several issues because performing these actions requires extensive access to the
CSP’s infrastructure and monitoring capabilities, which are often shared with
other CSP’s customers. The enterprise should have the permission of the CSP to
perform regular audits and to have access to forensic data without violating the
contractual obligations of the CSP to other customers.
• Mitigation:
– Request the CSP the right to audit as part of the contract or SLA. If this is
not possible, request security audit reports by trusted third parties.
– Request that the CSP provide appropriate and timely support (logs, traces,
hard disk images, etc.) for forensic analysis as part of the contract or SLA.
If this is not possible, request to authorize trusted third parties to perform
forensic analysis when necessary.
. B.1 Align, Plan and Organise: APO10 Manage Suppliers.
. B.5 Monitor, Evaluate and Assess: MEA02 Monitor, Evaluate and Assess
the System of Internal Control.

74
Appendix C. Mapping Threats and Mitigating Actions to

COBIT ® 5 for Information Security
Figure 9 maps cloud threats and mitigating actions to COBIT 5 for Information Security.
Figure 9—Cloud Threats and Mitigating Actions Mapped to COBIT ® 5 for Information Security
Risk Mapping to
Threat Description Factors Mitigation COBIT 5 for Information Security
Technical Threats
A. Vulnerable Information assets could be accessed S1.D • A contractual agreement is necessary to • A ppendix A. Detailed Guidance:
access by unauthorized entities due to faulty or S3.F officially clarify who is allowed to access Principles, Policies and Frameworks
management vulnerable access management measures D1.B the enterprise’s information, naming Enabler
(infrastructure or processes. This could result from a D2.C specific roles for CSP employees and – A.2 Information Security Policy
and application, forgery/theft of legitimate credentials external partners. • Appendix F. Detailed Guidance: Services,
public cloud) or a common technical practice (e.g., • Request that the CSP provide detailed Infrastructure and Applications Enabler
administrator permissions override) technical specifications of its IAM system – F .6 User Access and Access Rights in
for the enterprise’s CISO to review and Line With Business Requirements
approve. Include additional controls to – F .10 Monitoring and Alert Services for
ensure robustness of the CSP’s IAM Security-related Events
system. Most CSPs will not provide such
details due to internal security policies,

but the enterprise can request controls
and benchmarks as an alternative (e.g.,
result of penetration testing on the CSP’s
IAM systems).
Figure 9—Cloud Threats and Mitigating Actions Mapped to COBIT ® 5 for Information Security (cont.)
Risk Mapping to
Technical Threats (cont.)
A. Vulnerable •U
se corporate IAM systems instead of
access CSP IAM systems. The IAM remains
management the responsibility of the enterprise, so
(infrastructure no access to assets can be granted
and application, without the knowledge of the enterprise.
public cloud) It requires the approval of the CSP and
(cont.) the establishment of a secure channel
between the CSP infrastructure and the
corporate IAM system.
B. D
ata visible to This refers to data that have been stored S1.E • A contractual agreement is necessary to • Appendix G. Detailed Guidance: People,
other tenants in memory space or disk space that can officially clarify who is allowed to access Skills and Competencies Enabler
when resources be recovered by other entities sharing the the enterprise’s information, naming – G.3 Information Risk Management
are allocated cloud by using forensics techniques. specific roles for CSP employees and – G.6 Information Assessment and
dynamically external partners. All controls protecting Testing and Compliance
the enterprise’s information assets must • Appendix F. Detailed Guidance: Services,
be clearly documented in the contract Infrastructure and Applications Enabler
agreement or SLA. – F.5 Adequately Secured and Configured
• Encrypt all sensitive assets that are Systems, in Line With Security

being migrated to the CSP, and ensure Requirements and Security Architecture
that proper key management processes – F.9 Security Testing
are in place. This will consume part of
the
allocated resources due to the
encrypt/decrypt process so global
performance could be affected.
• Request the CSP’s technical
specifications and controls to ensure
Chapter 6. Managing a Cloud Service Provider
that the data are properly wiped when

requested.
• Use a private cloud deployment model
75
(no multitenancy).
76
Risk Mapping to
C. Multitenancy Due to the nature of multitenancy, some S1.E •R equest the CSP’s technical details for • Appendix E. Detailed Guidance:
visibility assets (e.g., routing tables, MAC addresses, D1.B CISO approval and require additional Information Enabler
internal IP addresses, LAN traffic) could D2.C controls to ensure data privacy. – E.8 Information Security Review
be visible to other entities in the same • A contractual agreement is necessary to Reports
cloud. Malicious entities in the cloud could officially clarify who is allowed to access • Appendix C. Detailed Guidance:
take advantage of the information, e.g., by the enterprise’s information, naming Organizational Structures Enabler
utilizing shared routing tables to map the specific roles for CSP employees and – C.1 Chief Information Security Officer
internal network topology of an enterprise, external partners. All controls protecting (CISO)
preparing the way for an internal attack. the enterprise’s information assets must • Appendix F. Detailed Guidance: Services,
be clearly documented in the contract Infrastructure and Applications Enabler
agreement or SLA. – F.10 Monitoring and Alert Services for
•U se a private cloud deployment model Security-related Events

(no multitenancy).
D. Hypervisor Hypervisors are vital for cloud virtualization. S1.E • Request the CSP’s internal SLA for • Appendix B. Detailed Guidance:
attacks They provide the link between virtual hypervisor vulnerability management, Processes Enabler
machines and the underlying physical patch management and release – B.2 Align, Plan and Organize (APO)
resources required to run the machines by management when new hypervisor . APO09 Manage Service Agreements.
using hypercalls (similar to system calls, vulnerabilities are discovered. The SLA • Appendix G. Detailed Guidance: People,

but for virtualized systems). An attacker must contain detailed specifications Skills and Competencies Enabler
using a VM in the same cloud could fake about vulnerability classification and –G .3 Information Risk Management
hypercalls to inject malicious code or actions taken according to the severity • Appendix A. Detailed Guidance:
trigger bugs in the hypervisor. This could level. Principles, Policies and Framework
potentially be used to violate confidentiality • Use a private cloud deployment model Enabler
or integrity of other VMs or crash the (no multitenancy). – A.2 Information Security Policy
hypervisor (similar to a DDoS attack).
Risk Mapping to
E. Application Due to the nature of SaaS, the applications S3.H •R equest that the CSP implements • Appendix G. Detailed Guidance: People,
attacks offered by a CSP are more broadly application firewalls, antivirus, and Skills and Competencies Enabler
exposed. Because they can be the target of anti-malware tools. – G.5 Information Security Operations
massive and elaborate application attacks, • The SLA must contain detailed – G.6 Information Assessment and
additional security measures (besides specifications about vulnerability Testing and Compliance
standard network firewalls) are required to classification and actions taken • Appendix F. Detailed Guidance: Services,
protect them. according to the severity level, which Infrastructure and Applications Enabler
must align with corporate policies and – F.10 Monitoring and Alert Services for
procedures for similar events. Security-related Events
F. Application In a virtualized environment, direct access D3.C • Evaluate extensively the design and • Appendix B. Detailed Guidance:
compatibility to resources is no longer possible (the requirements of application candidates Processes Enabler
hypervisor stays in the middle). This to move to the cloud and/or request of – B.3 Build, Acquire and Implement (BAI)
could generate issues with older and/ the CSP a test period to identify possible . BAI02 Manage Requirements
or customized software that could go issues. Definition.
unnoticed until it is too late to fall back. • Require continuous communication and • Appendix E. Detailed Guidance:
notification of major changes to ensure Information Enabler
that compatibility testing is included in – E .6 Information Security Requirements

the change plans. • Appendix F. Detailed Guidance: Services,
Infrastructure and Applications Enabler
– F .3 Secure Development
77
78
Risk Mapping to
G. Collateral The enterprise can be affected by issues D1.C • Ask the CSP to include the enterprise • Appendix E. Detailed Guidance:
damage involving other entities sharing the cloud. in its incident management process Information Enabler
For example, DDoS attacks affecting that deals with notification of collateral – E.6 Information Security Requirements
another entity in the cloud can leave the events. • Appendix F. Detailed Guidance: Services,
enterprise without access to business • Include contract clauses and controls to Infrastructure and Applications Enabler
applications (for SaaS models) or extra ensure that the enterprise’s contracted – F.8 Adequate Incident Response
computing resources to handle peak loads capacity is always available and cannot • Appendix G. Detailed Guidance: People,
(for IaaS models). be directed to other tenants without Skills and Competencies Enabler
approval. – G.3 Information Risk Management
•U se a private cloud deployment model
(no multitenancy).
H. S aaS access Access to SaaS applications (either via S3.K •U se hardened web browsers and/or • Appendix F. Detailed Guidance: Services,
security browser or specific end-user clients) must specific end-user client applications Infrastructure and Applications Enabler
be secure in order to control the exposure which include appropriate security – F.6 User Access and Access Rights in
to attacks and protect the enterprise and measures (anti-malware, encryption, Line With Business Requirements
assets. sandboxes, etc.). – F.10 Monitoring and Alert Services for
•Use secure virtual desktops or specific Security-related Events
browser clients when connecting to cloud • Appendix G. Detailed Guidance: People,

applications. Skills and Competencies Enabler
– G.5 Information Security Operations
Risk Mapping to
I. Outdated VM An inactive VM could be easily overlooked S1.K • Introduce procedures within the • Appendix A. Detailed Guidance:
security and important security patches could be enterprise to verify the state of software Principles, Policies and Framework
left unapplied. This out-of-date VM could security updates prior to the activation of Enabler
become compromised when activated. any VMs. – A.2 Information Security Policy
• E mpower the CSP to apply security • Appendix F. Detailed Guidance: Services,
patches on inactive VMs. Infrastructure and Applications Enabler
– F.5 Adequately Secured and Configured
Systems, Aligned With Security
Regulatory Threats
A. Asset ownership Any asset (data, application or process) S2.D • Include terms in the contract with • Appendix C. Detailed Guidance:
migrated to a CSP could be legally owned S3.C the CSP to ensure that the enterprise Organizational Structures Enabler
by the CSP based on contract terms. remains the sole legal owner of any – C.5 Information Custodians/Business
Thus, the enterprise can lose sensitive asset migrated to the CSP. Owners
data or have them disclosed because • Encrypt all sensitive assets being
the enterprise is no longer the sole legal migrated to the CSP prior to the

owner of the asset. In the event of contract migration to prevent disclosure and
termination, the enterprise could even be ensure proper key management is in
subject (by contract) to pay fees to retrieve place. This could affect the performance
its own assets. of the system.
B. Asset disposal In the event of contract termination, to S1.I • Request CSP’s technical specifications • Appendix G. Detailed Guidance: People,
prevent disclosure of the enterprise’s S2.E and controls that ensure that data are Skills and Competencies Enabler:
assets, those assets should be removed S3.D properly wiped and backup media is – G.3 Information Risk Management
from the cloud using forensic tools destroyed when requested.
(or other tools that ensure a complete • Include terms in the contract that require,
wipeout). upon contract expiration or any event
ending the contract, a mandatory data
wipe carried out under the enterprise’s
79
review.
80
Risk Mapping to
Regulatory Threats (cont.)
C. Asset location Technical information assets (data, logs, S1.D •R equest the CSP’s list of infrastructure • Appendix G. Detailed Guidance: People,
etc.) are subject to the regulations of the locations and verify that regulation Skills and Competencies Enabler
country where they are stored. In the cloud, in those locations is aligned with the – G.4 Information Security Architecture
an enterprise may, without notification, enterprise’s requirements. Development
migrate information assets to countries • Include terms in the service contract – G.6 Information Assessment and
where regulations are less restrictive or to restrict the moving of enterprise Testing and Compliance
their transmission is prohibited (personal assets to only those areas known to • Appendix F. Detailed Guidance: Services,
information in particular). Unauthorized be compliant with the enterprise’s own Infrastructure and Applications Enabler
entities that cannot have access to assets regulation. – F.2 Security Awareness
in one country may be able to obtain legal • To prevent disclosure, encrypt any asset
access in another country. Conversely, prior to migration to the CSP, and ensure
if assets are moved to countries with proper key management is in place.

stricter regulations, the enterprise can
be subject to legal actions and fines for
noncompliance.

Risk Mapping to
Information Security Governance Threats
A. P hysical security Physical security is required in any S1.H •R equest the CSP’s physical security • Appendix E. Detailed Guidance:
on all premises infrastructure. When the enterprise policy and ensure that it is aligned with Information Enabler
where migrates assets to a cloud infrastructure, the enterprise’s security policy. – E .6 Information Security Requirements
data/applications those assets are still subject to the •R equest that the CSP provide proof • Appendix A. Detailed Guidance:
are stored corporate security policy, but they can of independent security reviews or Principles, Policies and Frameworks
also be physically accessed by the CSP’s certification reports (e.g., AICPA SSAE 16 Enabler
staff, which is subject to the CSP’s security SOC 2 report or ISO certification). – A.2 Information Security Policy
policy. There could be a gap between the • Include in the contract language that
security measures provided by the CSP requires the CSP to be aligned with
and the requirements of the enterprise. the enterprise’s security policy and to
implement necessary controls to
ensure it.
•R equest the CSP’s DRP and ensure
that they contain the necessary
countermeasures to protect physical
assets during and after a disaster.

81
82
Risk Mapping to
Information Security Governance Threats (cont.)
B. Visibility of The cloud is similar to any infrastructure S1.F •R equest the CSP’s detailed schemes of • Appendix E. Detailed Guidance:
the security in that security measures (technology and the technical security measures in place Information Enabler
measures put in processes) should be in place to prevent and determine whether they meet the – E.6 Information Security Requirements
place by the CSP security attacks. The security measures requirements of the enterprise. – E .8 Information Security Review
provided by the CSP should be aligned •R equest that the CSP provide proof Reports
with the requirements of the enterprise, of independent security reviews or – E.9 Information Security Dashboard
including management of security certification reports (e.g., AICPA SSAE 16 • Appendix F. Detailed Guidance: Services,
incidents. SOC 2 report or ISO certification). Infrastructure and Applications Enabler
• Include in the contract language – F .10 Monitoring and Alert Services for
that requires the CSP to provide the Security-related Events
enterprise with regular reporting on
security (incident reports, IDS/IPS

logs, etc.).
•R equest the CSP’s security incident
management process be applied to
the enterprise’s assets and ensure that
it is aligned with the enterprise’s own
security policy.

C. Media Data media must be disposed in a secure S1.I •R equest the CSP’s process and • Appendix B. Detailed Guidance:
management way to avoid data leakage and disclosure. techniques in place for data media Processes Enabler
Data wipeout procedures must ensure disposal and evaluate whether they meet –B .3 Build, Acquire and Implement (BAI)
that data cannot be reproduced when data the requirements of the enterprise. . BAI08 Manage Knowledge.
media support is designated for recycle or • Include in the contract language that
disposal. Controls should be in place during requires the CSP to comply with the
transportation (encryption and physical enterprise’s security policy
security). This should be specified in the
CSP security policy.
Risk Mapping to
D. S ecure software When using SaaS services, the enterprise S3.E •R
equest the CSP’s details about the • Appendix B. Detailed Guidance:
SDLC must be sure that the applications will software SDLC in place and ensure Processes Enabler
meet its security requirements. This will that the security measures introduced – B.3 Build, Acquire and Implement (BAI)
reduce the risk of disclosure. into the design are compliant with the . BAI03 Manage Solutions Identification
requirements of the enterprise. and Build.
•R
equest the CSP to provide proof • Appendix E. Detailed Guidance:
of independent security reviews or Information Enabler
certification reports (e.g., AICPA SSAE 16 – E.6 Information Security Requirements
SOC 2 report or ISO certification). • Appendix F. Detailed Guidance: Services,
Infrastructure and Applications Enabler
– F.3 Secure Development
E. Common Community clouds share resources among D2.C • E nsure that a global security policy • Appendix E. Detailed Guidance:
security policy different entities that belong to the same specifying minimum requirements Information Enabler:
for community group (or community) and thereby possess is applied to all entities sharing a – E.6 Information Security Requirements
clouds a certain level of mutual “trust.” This community cloud. • Appendix A. Detailed Guidance:
trust must be regulated by a common •R equest that the CSP provide proof Principles, Policies and Framework
security policy. Otherwise, an attack on the of independent security reviews or Enabler

“weakest link” of the group could place all certification reports (e.g., AICPA SSAE 16 – E.2 Information Security Strategy
the group’s entities in danger. SOC 2 report or ISO certification).
83
84
Risk Mapping to
F. Service Currently, there is very little available in S3.G • Ensure by contract or SLA with the CSP • Appendix B. Detailed Guidance:
termination terms of tools, procedures or other offerings an exit strategy that specifies the terms Processes Enabler
issues to facilitate data or service portability that should trigger the retrieval of the – B.2 Align, Plan and Organize (APO)
from CSP to CSP. This can make it very enterprise’s assets in the timeframe . APO09 Manage Service Agreements.
difficult for the enterprise to migrate from required by the enterprise. • Appendix B. Detailed Guidance:
one CSP to another or to bring services • Implement a DRP, taking into account Processes Enabler
back in-house. It can also result in serious the possibility of complete disruption of –B.4 Deliver, Service and Support
business disruption or failure should the the CSP. . DSS04 Manage Continuity.
CSP go bankrupt, face legal action, or be • Appendix G. Detailed Guidance: People,
the potential target for an acquisition (with Skills and Competencies Enabler
the likelihood of sudden changes in CSP – G.3 Information Risk Management
policies and any agreements in place).

Another possibility is the “run on the banks”
scenario, in which there is a crisis of
confidence in the CSP’s financial position,
resulting in a mass exit and withdrawal on
first-come, first-served basis. If there are
limits to the amount of content that can
be withdrawn in a given timeframe, then

the enterprise might not be able to retrieve
all its data in the time specified. Another
possibility may occur if the enterprise
decides, for any reason, to end the
relationship with the CSP. The complexity of
the business logic and data models could
make it literally impossible for the enterprise
to extract its data, reconstruct the business
logic and rebuild the applications.
Risk Mapping to
G. S olid enterprise Enterprises turn to CSPs in search of S3.I • E nsure that internal governance controls • Appendix B. Detailed Guidance:
governance solutions that can be implemented easily are in place within the enterprise Processes Enabler
and at a low cost. This ease can be to involve the necessary control – B.1 Evaluate, Direct and Monitor (EDM)
tempting, especially when the enterprise organizations (legal, compliance, finance, . EDM01 Ensure Governance
is facing urgent deadlines that require etc.) during the decision process of Framework Setting and Maintenance.
an urgent solution (like the expiration of migrating to cloud services. – B.5 Monitor, Evaluate and Assess (MEA)
application licenses, or the need of more . MEA02 Monitor, Evaluate and Assess
computing capacity). This can become the System of Internal Control.
an issue because organizations may
contract cloud applications without proper
procurement and approval oversight,
thus bypassing compliance with internal
policies.
H. S upport for audit Security audits and forensic investigations S1.F • Request of the CSP the right to audit as • Appendix B. Detailed Guidance:
and forensic are vital to the enterprise to evaluate the S1.L part of the contract or SLA. If this is not Processes Enabler
investigations security measures of the CSP (preventive possible, request security audit reports – B.2 Align, Plan and Organise (APO)
and corrective), and in some cases the CSP by trusted third parties. . APO10 Manage Suppliers.

itself (e.g., to authenticate the CSP). This • Request that the CSP provide appropriate – B.5 Monitor, Evaluate and Assess (MEA)
raises several issues because performing and timely support (logs, traces, hard . MEA02 Monitor, Evaluate and Assess
these actions requires having extensive disk images) for forensic analysis as the System of Internal Control.
access to the CSP’s infrastructure and part of the contract or SLA. If this is not
monitoring capabilities, which are often possible, request of the CSP to authorize
shared with other CSP’s customers. The trusted third parties to perform forensic
enterprise should have the permission analysis when necessary.
of the CSP to perform regular audits and
to have access to forensic data without

violating the contractual obligations of the
CSP to other customers.
85

Appendix A. Vendor Selection Dashboard 87
Appendix A. Vendor Selection Dashboard

The real-life example dashboard in figure 11 can be used to evaluate vendors
during vendor selection. The first column contains the business objectives (selection
criteria) on which the vendor will be evaluated. These can vary depending on the
enterprise as well as the specific goals of the to-be-outsourced activity. The weight
column represents the weight that a certain factor has in the total evaluation, which
can also depend on the to-be-outsourced activity. Here, weight is represented as
four increasing bars, each representing 25 percent—the weight of a particular factor
adds to 25 percent, 50 percent, 75 percent or 100 percent. The next four columns
represent the rating of each of the vendors (X, Y, Z, W) per business objective.
These ratings vary from 0 (black) to 1 (red) to 2 (yellow) to 3 (green). Finally, the
last four columns contain merely an indication of the category of the criteria. This
information can be used to verify if the selection criteria cover all the relevant
aspects of the future collaboration.
Figure 11—Vendor Selection Dashboard Example
Partnership
Customer Name: ______________ Weight Rating
Approach
Technical
Managed
Services
%
(25-50- Vendor Vendor Vendor Vendor
Business Objective 75-100) X Y Z W
Business understanding ● ● ● ● x
Unified data/voice/video ● ● ● ● x
Results as opposed to means ● ● ● ● x
Scalability
• Europe ● ● ● ● x
• World ● ● ● ● x
Security ● ● ● ● x
Long-term vision ● ● ● ● x
Design of the solution ● ● ● ● x
Resilience
• Production ● ● ● ● x
• Backup ● ● ● ● x
Capacity
• Production ● ● ● ● x
• Backup ● ● ● ● x
Bandwidth optimization ● ● ● ● x
SLA (end-to-end) ● ● ● ● x
KPIs (reporting-trend-capacity ● ● ● ● x
planning)
Transition IN (no big bang) ● ● ● ● x
Courts of justice ● ● ● ● x
Languages for support ● ● ● ● x
(incident management)
Black = 0, red = 1, yellow = 2, green = 3

Figure 11—Vendor Selection Dashboard Example (cont.)
Customer Name: ______________ Weight Rating
Partnership
Approach
Technical
Managed
Services
%
(25-50- Vendor Vendor Vendor Vendor
Business Objective 75-100) X Y Z W
Key processes (change management- ● ● ● ● x
planned/unplanned maintenance)
Supplier internal processes (others) ● ● ● ● x
Partnership relation ● ● ● ● x
Negotiation time duration and ● ● ● ● x
complexity
Company internal workload at ● ● ● ● x
minimum
Black = 0, red = 1, yellow = 2, green = 3
Weights and ratings should be multiplied and summarized per vendor to determine
a final score as shown in figures 12 and 13. It is advisable to select the two highest
rating vendors and start negotiations with them.
Figure 12—Vendor Score Example

Budget Vendor X Vendor Y Vendor Z Vendor W
One-time charge $215,989 $335,000 $333,613 $123,209
Contract term proposed (years) 5 5 5 3
Monthy recurrent $74,190 $112,607 $64,841 $97,370
Total over 3 years $2,886,829 $4,363,752 $2,667,889 $3,628,529
Total over 5 years $4,667,389 $6,870,638 $4,224,073 $5,965,409
Ranking Vendor X Vendor Y Vendor Z Vendor W

Business objectives (minimum = 1, maximum = 4) 3.66 2.95 3.44 2.99
Financials (5 year contract-smallest = 100%) 110% 163% 100% 141%

Appendix A. Vendor Selection Dashboard 89
Figure 13—Graphic Representation of Vendor Score Example
0 1 2 3 4 5
0%
Ranking weighted
according to company
25%
business requirements Vendor Ranking Pricing
Vendor X 3.66 110%
Vendor Y 2.95 163%
50% Vendor Z 3.44 10%
Vendor W 2.99 141%
75%
Best pricing
100% Z
X
125%
W
150%
Y
175%
Fit for purpose

200%


Appendix B. Call for Tender Template 91
Appendix B. Call for Tender Template

It is advisable to pay careful attention to the information shared in a call for tender
because there is not yet a nondisclosure agreement between the enterprise and the
potential vendors.
Chapter 1. Enterprise Context
The purpose of the first chapter in the call for tender is to provide insight into
the enterprise strategy and the business context in which the enterprise operates.
This information is important for potential vendors to understand the enterprise
environment and activities, key parameters for service delivery and potential
opportunities or threats. The information in this chapter forms the basis for the
vendor to develop a tailored approach for the enterprise and adequately respond to
the call for tender. The following sections could be included:
• Enterprise profile:
– Enterprise strategy
– Enterprise goals
– Enterprise services
– Organizational structure
• Enterprise IT mission and vision
Chapter 2. IT Governance and Management
In the second chapter, more specific information is provided regarding the enterprise
IT governance and management. The following sections should be included:
• IT goals and strategic orientations
• High-level insight into the enterprise architecture
• Overview of the IT organization and services
• Roles and responsibilities
• IT process management frameworks or standards
• Applicable policies and regulations
Chapter 3. Requested Services
Once the potential vendor is informed about the enterprise context and the
enterprise IT governance and management, the key purpose of the call for tender
should be communicated by detailing the services that the enterprise is requesting
from the market. It is important to detail the service requested as precisely as
possible to enable the vendor to prepare an adequate offer. The enterprise should
focus on the needs rather than defining solutions. The challenge for potential
vendors is to provide the enterprise with the best solution to meet the requirements.
However, limitation to use specific applications or infrastructure can be added to
comply with architectural boundaries. The following sections could be included:
• High-level description of the service requested
• Current situation

• Objectives of the service requested

• Critical success factors
• Scope
• Detailed requirements overview
• Locations in scope
• Volumes of services
• Specific resource requirements
• Certification requirements
• Budget (time and means vs. results driven)
• Compliancy requirements (e.g., laws, regulations and internal policies)
Chapter 4. Roles and Responsibilities
This chapter clarifies a suggested division of roles and responsibilities in the

contractual relationship. Setting clear expectations in the call for tender provides a
basis for negotiations, guarantees that the topic is not overlooked and might help to
avoid confusion or discussions in a later stage of the collaboration. The following
sections could be included:
• Overview of activities and stakeholders involved
• High-level RACI (responsible, accountable, consulted and informed) matrix
Chapter 5. General Requirements
As a conclusion, this chapter should provide some general rules and guidelines.
These could be either fixed rules, which are not negotiable, e.g., security
requirements, or suggested guidelines that the vendor should take into account when
drafting the offer, e.g., vendor capabilities. It is recommended to indicate whether
the enterprise considers an item to be a fixed rule or a guideline. The following
sections should be included:
• Relationship governance structure
• Escalation procedures
• System and service management tools
– Objectives
– Requirements
– Reference documents
• Performance evaluation
– Procedure
– Metrics
• Vendor capabilities
– Security management capabilities
– Project management capabilities
– Service continuity capabilities
–S ervice reporting capabilities
– Continuous improvement capabilities
– Asset and innovation management capabilities

Appendix B. Call for Tender Template 93
Appendix
Appendices provide additional information that is important input to a vendor for

describing services or determining price. The following appendices could be included:
• Key parameters, e.g., volumes and enterprise locations
• Service level requirements
• Enterprise policies, e.g., information security policy and personnel management policy
• Glossary of terms
Opting for an RFI/RFP Procedure
When making a distinction between a request for information (RFI) and a request
for proposal (RFP) in the call for tender process, the elements described previously
should be split between the two information documents. When sending out an RFI,
it is important to begin with a description of the enterprise context, as explained
in the first chapter of the call for tender template. As a general guideline, the RFI
document is not as specific as the RFP document. The RFI provides an insight into
the enterprise context and the objectives of a potential vendor relationship, without
specifying too much detail. The RFI purpose is to find out who the interested
parties in the market are, what possible solutions might be interesting to investigate
further and potentially phase out vendor candidates that do not fit the requirements
at an early stage, for reasons such as global spread or potential to serve large
enterprises.
An RFP that was preceded by an RFI should not necessarily repeat this information,
unless new vendor candidates are included in the RFP process.


Appendix C. Call for Tender Checklist 95
Appendix C. Call for Tender Checklist

Figure 14—Call for Tender Checklist
Chapter 1. Enterprise Context Relevant? Applied?
Enterprise profile:
• Enterprise strategy
• Enterprise goals
• Enterprise services
• Organizational structure
Enterprise IT mission and vision
Chapter 2. IT Governance and Management Relevant? Applied?
IT goals and strategic orientations
High-level insight in enterprise architecture
Overview of the IT organization and services
Roles and responsibilities
IT process management frameworks or standards
Applicable policies and regulations
Chapter 3. Requested Services Relevant? Applied?
High-level description of the requested service
Current situation
Objectives of the requested service
Critical success factors
Scope
Detailed requirements overview
Location in scope
Volumes of services
Specific resource requirements
Certification requirements
Budget (time and means vs. results driven)
Compliancy requirements (laws, regulations and internal policies)
Chapter 4. Roles and Responsibilities Relevant? Applied?
Overview of activities and stakeholders involved
High-level RACI (responsible, accountable, consulted and
informed) matrix

Figure 14—Call for Tender Checklist (cont.)

Chapter 5. General Requirements Relevant? Applied?
Relationship governance structure
Escalation procedures
System and service management tools:
• Objectives
• Requirements
• Reference documents
Performance evaluation:
• Procedure
• Metrics
Vendor capabilities:
• Security management capabilities
• Project management capabilities
• Service continuity capabilities
• Service reporting capabilities
• Continuous improvement capabilities
• Asset and innovation management capabilities
Appendix Relevant? Applied?
Key parameters, e.g., volumes, enterprise locations
Service level requirements
Enterprise policies, e.g., information security policy, personnel
management policy
Glossary of terms

Appendix D. Drafting the Contract: 97
High-level Legal Checklist for Non-legal Stakeholders
Appendix D. Drafting the Contract:

High-level Legal Checklist
for Non-legal Stakeholders
This appendix provides an overview of the main points of attention when
negotiating an IT vendor contract. Most contract elements were discussed
previously in the Vendor Management: Using COBIT 5 guide. The elements
presented in this overview are, however, not exhaustive, because every enterprise
has specific elements that it requires to be included in its contracts.
1. S
cope of Services
The IT contract must clearly define the services that will be performed, to
avoid any dispute among the parties regarding scope of services. For a time and
materials (T&M) contract, it is especially important to clearly describe the scope
of the services to be provided, the scheduling of the services and the number of
services to be delivered. Alternatively, when the IT contract is for a well-defined
deliverable (e.g., specific software that will be developed), establishing the scope
becomes less important as long as the deliverable specifications and requirements
are clearly defined in the contract.
As mentioned in chapter 4. Vendor Management Risk Mitigation Actions,

special attention should be paid to defining the terminology used throughout the
agreement, particularly terms that are commonly used in one field or location,
but may not be known or may have another meaning in other fields or locations
(e.g., best effort, commercially reasonable effort and force majeure).
IT projects may have a dynamic nature, so the contract may be subject to frequent
changes, especially in the case of long-term agreements. For this type of project,
establish a method to modify the scope, i.e., a change management procedure,
or include a consultation clause in the agreement. This allows the parties to
distinguish the “must have” and the “nice to have,” assess risk associated with
proposed changes while the project progresses and jointly approve changes.
2. C
ore Obligations of Parties
After the scope of services has been clearly defined, parties should agree on the
performance standards regarding the delivery of services.
IT contracts usually contain a description of mutual rights and obligations for the
parties. Most often, these obligations consist of general responsibilities, such as
information obligation, cooperation obligation and obligation to comply with the
applicable legislation.

The parties should set sufficient interim delivery milestones to enable the
project to be completed successfully and in due time. Such milestones allow the
enterprise to monitor the project progress and to maintain control of the various
interim deliverables. Each milestone and the corresponding interim deliverables
should be clearly defined by the parties in the contract.
3. O
wnership of Intellectual Property and Data
During the implementation of an IT project, the parties may have to manage
different forms of intellectual property rights. The contract should clarify
the distinction between intellectual property that existed before the start of
the contract, the intellectual property developed during the project and the
intellectual property of third parties.
It is important that clear provisions are included in the IT contract regarding

the ownership right and the right to use all intellectual property involved in the
project. If no provisions regarding the intellectual property developed during
the project are included in the contract, the service provider could be considered
to be the owner of this intellectual property. This may be problematic for the
continuity of the business when the contract expires.
If the enterprise does not obtain full ownership rights of the relevant intellectual
property upon termination of the agreement, the contract should explicitly allow
the use of intellectual property, for example, with a license agreement. The
range of such rights should be defined (e.g., only for internal purposes, only in
a specific country, for a limited or unlimited period, limited number of users
and exclusive or nonexclusive), and the contract should stipulate whether the
intellectual property can also be used by parties related to the enterprise (e.g.,
subsidiaries and external service providers) or can be sublicensed and transferred.
If the enterprise obtains the intellectual property rights at the end of the
agreement, it should be determined whether a license should be given to the
service provider for future projects.
4. E
nd of Contract
The way in which a contract is terminated depends on the term for which it has
been concluded (definite or indefinite) and on the termination possibilities for
the parties included in the contract. Including specific exit arrangements in the IT
contract is important. A smooth transfer to another service provider or in-house
prevents endangering the continuity of business operations. Ownership rights
and the right to use intellectual property after the end of the contract, discussed
previously, are part of the end of contract arrangements.
Due to the technical complexity of IT projects, some IT contracts consist

of several independent contracts and appendices. As a consequence, the
termination of one contract may entail the termination of another contract (e.g., a
maintenance contract). IT contracts need to be properly monitored to ensure that
all dependencies are properly addressed during termination procedures.
5. P
rivacy, Security and Confidentiality of Data and Information
To sufficiently protect the confidential data and information that are exchanged
between parties during an IT project, certain safeguards must be included in the
contract. First, the data and information that should be considered as confidential
should be identified, and then the scope of the obligations toward this confidential
information (e.g., secrecy) and the permitted use of it should be defined.
During IT projects, personal data are often processed and transferred. When this
is the case, both the client and the service provider must follow the applicable
private data legislation. Because each country has its own privacy regulations,
the compliance of the IT contract with the applicable national legislation should
be checked. Private data legislation can differ substantially between different
jurisdictions. Some jurisdictions have extensive privacy legislation, while
other jurisdictions have only limited legislation or a total lack of protection of
private data. The latter situation may cause serious problems if private data are
transferred to such jurisdictions. All European companies have similar private
data regulations because these regulations were the result of a European directive.
However, certain differences between European countries are possible because
of the differences in implementation of the directive. In those countries where
extensive private data protection is in place, the national private data regulations
generally provide for the obligation to include a guarantee in the IT contract that
the service provider will process any personal data in line with the applicable
legislation. The service provider must ensure that private data that are transferred
to a country that is not considered to be a safe harbor are sufficiently protected.
The contract must include a clear assignment of roles regarding the processing of
personal data. The contract must clarify the following:
• Who will process the data?
• During which period the data will be processed and kept?
• Who will have access to the data?
• Which data will be kept?
• Where will the data be kept and during which period?
The deliverables (e.g., an IT tool or software) should also be compliant with

the applicable private data regulations. The contract should provide sufficient
testing of the deliverable to ensure that the deliverable meets the required data
protection standards.
6. F
ees and Payment Terms and Modalities
The contract should be explicit about the method to calculate price. It should
be clearly specified whether the project will be executed for a fixed price, on
the basis of actual time spent (e.g., an hourly rate or a man per day rate) or a
combination of both.
It is equally important for the payment terms and modalities to be included in

the contract (e.g., send an invoice, the term of payment and the consequences of
late payment). For long-term contracts, it is advisable to include an adjustment
clause, which allows parties to modify certain conditions (e.g., the price) of
the agreement at specific stages of the project. Depending on the applicable
legislation, an indexation clause could be inserted into the contract. This clause
should contain, at a minimum, the index, the indexation formula and the
frequency of the indexation. Other price revision methods can also be included
(e.g., consultation clause).
7. Performance
A service level agreement (SLA) is very common in IT contracts and can be
an effective tool to create a common understanding between contracting parties
regarding services, priorities and/or responsibilities in the framework of
an agreement.
As discussed previously, only measurable and realistic SLAs are defined in the
contract. Unrealistic SLAs might cause disputes between parties. SLAs should be
measurable to allow meaningful reporting among the parties. The reports can be
used during consultations between parties about the achievement of the SLA.
It is important to address the consequences of noncompliance in the SLA. The

contract could provide a set of actions to deal with the cause of noncompliance.
The parties could define penalties in case of non-achievement of the levels
established. However, incentives for the achievement of the SLA (or a
combination of penalties and incentives) often appear to be more efficient.
If the parties decide to provide a price correction, it is important to stipulate that

the price correction is not the only compensation that can be claimed in a case
of non-achievement of the SLA, so that the right to the payment of full damage
is not jeopardized. For continuity of the enterprise, it is recommended to provide
a special clause that states that the enterprise can appoint a third-party service
provider to deliver the necessary services in case of non-achievement of the SLA
by the service provider.
If required, an audit clause can be included in the contract that allows the
enterprise to obtain the right to access relevant financial data, accounting
information, operational and technical data, safety standards, etc., of the other
party. It is strongly recommended to insert this audit clause into a contract
because it allows the enterprise to check, among others, the co-contracting party’s
performances, compliance and achievements.
8. T
erm and Termination Possibilities
Contracts can be established for a definite or indefinite term. A contract for an
indefinite term can be terminated at any moment in time, subject to due notice.

A contract for a definite term ends automatically upon expiration of its term.
Nevertheless, parties could agree to renew the contract automatically (tacit
agreement). It is important to define in the contract the consequences of the
automatic renewal (e.g., will the same terms and conditions apply, what will be
the duration of the renewed contract and will the same SLAs be in place).
If the parties foresee the possibility of interim termination due to specific

circumstances, they could include a clause that allows early termination of the
contract for specific reasons, without any court intervention, and thus avoid
long judicial procedures. For example, the parties could include a material
adverse change clause (MAC clause), which allows a contracting party to
terminate or renegotiate the contract in case of a substantial (material) change
in the circumstances (e.g., in case of a change to the current legislation). MAC
clauses are especially useful in long-term agreements. The clause should
identify in a concrete and objective manner the different circumstances that can
lead to an early termination or renegotiation of the agreement and the possible
consequences in the case of the specified material adverse change (e.g., price
adjustments, termination of the contract or renegotiation of the contract delivery
terms, and product specification).
The parties can define which circumstances or events of default will lead to an
early dissolution of the agreement with entitlement to compensation. As indicated
previously, proper exit arrangements should be negotiated to ensure a smooth
transfer to another provider in case of termination under any circumstances.
9. Liabilities
Dependent on the jurisdictions involved, the legal rules regarding liability are
quite stringent. However, contracting parties might be able to negotiate different
arrangements regarding liabilities. The service provider, in particular, will benefit
from a limitation of liability because the service provider bears the biggest
responsibilities. The limitation of the liability of the service provider regarding
the security, protection and loss of data is a common liability clause in contracts.
In most cases, the service provider will try to limit its liability to the minimum
extent possible.
Contractual clauses regarding the limitation of liability can take several forms,
for example, the liability can be capped to a maximum amount or certain
damages can be excluded from any compensation. It is common practice for
a service provider to try to limit its liability as much as possible. However,
the service provider should bear some liability, especially regarding its core
obligations. Furthermore, such limitation of liability should be evaluated in view
of the enterprise’s liability toward its own customers as well as the liabilities
covered by insurance policies.

Parties can also define how third-party claims will be addressed (e.g., in case
of an infringement on intellectual property rights). Include indemnity clauses in
the contract that define how these claims will be handled. When a contracting
party of the enterprise bears damages because of a fault of the service provider,
the enterprise will be held responsible by the contracting party. Because of the
indemnity clause, the enterprise can seek to have the service provider reimburse
it for monies that the enterprise had to pay to the damaged party.
Certain jurisdictions have special liability laws for online providers (e.g., laws
of the member states of the European Union [EU] and the Digital Millennium
Copyright Act of the USA).
10. D
ispute Resolution and Applicable Law
The IT services contract may involve different countries and, therefore, cover
different jurisdictions, for example, the service provider and the enterprise are
located in different countries. The contract must determine the governing law
and the competent jurisdiction in case a dispute arises related to the agreement.
The choice of the applicable law has an impact on the validity and enforceability
of the clauses of the agreement. A legal procedure under foreign law or in
front of a foreign court may involve additional costs (e.g., the intervention of a
foreign lawyer) and risk.

Appendix E. Example Contract Template 103
Appendix E. Example Contract Template

Disclaimer: Nothing contained in this publication is to be considered as legal advice.
Readers are responsible for obtaining legal advice from their own legal counsel. This
publication and any forms or agreements within it are intended solely for educational
and informative purposes only.
Provision of contract services:
<date>
Enterprise identification code:
This Agreement is concluded between:
<Vendor>, entered in the Register of Legal Persons under number xxxx.xxx.xxx.
Hereinafter referred to as “Supplier,”
and
<Enterprise> with registered office at xxxxxx, entered in the Register of Legal

Persons under number xxxxxx;
Hereinafter referred to as “Enterprise.”

I. The Agreement
1. Purpose and Structure of the Agreement

This Agreement has been concluded with a view to create a formal framework
agreement between ENTERPRISE and the SUPPLIER, along with the
relevant Subagreements and any annexes, appendices and SOW’s, duly
approved and signed by ENTERPRISE and the SUPPLIER, which covers
all contractual aspects of business transactions related to the provision
of Contract Services. Section I contains the meta-information about the
Agreement. Section II contains the general terms and conditions that govern
the ICT Assignment. Section III contains a sample Subagreement.
2. Drafting and Signature

This Agreement was drawn up in xxx on [ ] in two originals; each Party
certifies that it has received a copy.
For ENTERPRISE
NAME
Function
For the SUPPLIER
NAME
Function
3. Notifications
All correspondence concerning this Agreement, is to be sent to the following
address. Any changes to the above particulars will be notified in writing.
For Supplier
<Address>
For Enterprise
<Address>
II. General Terms and Conditions

1. Definitions
• Acceptance—The juridical act of Enterprise, through which Enterprise
formally confirms that the Deliverables of an Assignment are in
conformance with the Acceptance Criteria
• Agreement—A formal framework agreement between Enterprise and
the Supplier, along with the relevant Subagreements and any annexes,
appendices, duly approved and signed by Enterprise and the Supplier, which
covers all contractual aspects of business transactions related to the provision
of Contract Services
• Assignment—All Contract Services to be delivered by the Supplier under a

specific Subagreement
• Contract Price—The price to be paid by Enterprise for the Assignment, as
set out in the relevant Subagreement
• Contractor—Any individual whom the Supplier calls upon to perform the
Contract Services
• Contractor Profile—A combination of technical skills, Profiles and
experience that describe an individual Contractor and that contributes to the
determination of the Contract Price through the Ratecard
• Contract Services—All services to be delivered by the Supplier under the
Agreement and under the terms and conditions laid down in the Agreement
and described in a Subagreement. It is explicitly agreed that only the
services mentioned in Appendix A fall within the scope of the Frame
Agreement.
• Deliverables—All deliverables that result from the Contract Services
• Effective Date—Date of signature of the Agreement by the Parties
• Enterprise—Enterprise, with registered office at xxxxxxxxx, entered in the
Register of Legal Persons under number xxxxxxx
• Enterprise Affiliated Companies—xxxxxxxxxx
• Enterprise Project Coordinator—The individual appointed by Enterprise
in the Subagreement, to act as liaison between Enterprise and the Supplier,
regarding an Assignment.
• Intellectual Property Rights—All patents (including models and designs),
trade secrets, copyrights, software rights, database rights and trademarks
• Party/Parties—Enterprise and/or the Supplier
• Progress Meeting—The progress meeting, installed by both parties for a
Project-based Assignment, and through which all communication between
the Parties pursuant to such Assignment will take place
• Project-based—Contractors working in assignments/projects that are
clearly defined in scope, specifications and objectives and, therefore, in
time (deadline) and price. Payment of Supplier is subject to actual delivery.
Supplier is responsible for allocating the resources it deems appropriate to
deliver the service.
• Project Manager—The individual appointed by the Supplier in the
Subagreement, who is responsible for the actual management and
supervision of the Contractors and who will also act as liaison between the
Supplier and Enterprise (or the Enterprise Project Coordinator), regarding an
Assignment
• Ratecard—One or more tables, included in the Agreement, which outline
the financial conditions applicable to the provision of Contract Services for
each main Contractor Profile
• Statement of Work (SOW)—The precise and detailed description of an
Assignment, including its Deliverables and, if applicable, the technical and
functional specifications. The SOW will always be an integral part of a
Subagreement.

• Subagreement—The document that Enterprise and Supplier execute

pursuant to the terms of this Agreement to contract for the provision of
Contract Services
• Supplier—The Tenderer whose proposal, tender or bid is accepted by
Enterprise and with whom the Agreement is concluded
• Third Party—Any natural or legal person, public authority, agency or any
other body other than the Parties or their Affiliated Companies.
• Third-party Claim—Any claim made by any Third Party against any of the
Parties or their Affiliated Companies.
• Time-based—An assignment for a fixed, predefined period and amount of
time for predefined tasks.
2. Subject Matter, Subagreements and Duration of the Agreement

2.1 This Frame Agreement establishes the standard terms and conditions
pursuant to which Enterprise may, from time to time, obtain from
Supplier, such professional IT services as described in Appendix A,
as may be agreed upon from time to time in a Subagreement. Such
Subagreement shall state clearly that it is executed pursuant to the terms
of this Frame Agreement and shall contain a description of the precise
nature of each Assignment. No services will be provided by Supplier
unless parties have agreed upon a Subagreement concerning those
services.
2.2 Supplier shall have no obligation to agree to provide services
requested by Enterprise or to enter into a Subagreement with respect to
such services.
2.3 Contract Services are to be performed by the Supplier, onsite or offsite.
In no case shall Enterprise be deemed to be the legal or actual employer
of the Contractors.
2.4 A Subagreement executed hereunder shall be deemed to incorporate by
reference the terms and conditions contained in this Frame Agreement.
A Subagreement may amend any term contained in this Agreement or
list special terms and conditions applicable to the Contract Services to be
provided there under.
2.5 The Frame Agreement shall enter into force for a term of x years from
the date of its signature by the Parties (the Effective Date). Upon the
expiration if this term, the Agreement shall automatically be extended for
successive periods of one year, save in the event of service of notice of
termination by either of the Parties by registered letter and subject to a
notice period of 90 days.
2.6 Notwithstanding any such termination of this Frame Agreement and
except to the extent an Subagreement is terminated pursuant to the
provisions with this Frame Agreement, each Subagreement signed
between Enterprise and Supplier prior to the effective date of the
termination of this Frame Agreement shall remain in full force and
effect in accordance with its terms, including the terms and conditions
of this Frame Agreement which are incorporated by reference into such
Subagreement.
2.7 Enterprise reserves the right to monitor supplier performance during the
term of any Subagreement, in accordance with clause 9.
3. Project-based Assignments—Delivery, Acceptance and Delays

3.1 Delivery and Acceptance
The Subagreement can subdivide an Assignment in milestones. Supplier
will use reasonable efforts to deliver all Deliverables specified for a
specific milestone before or at the latest on the milestone date. They will
be submitted to Enterprise for Acceptance. Enterprise and Supplier may
define acceptance tests and acceptance criteria in the Subagreement,
which will serve as a basis for Acceptance, and may set out in
greater detail the mutual rights, obligations and responsibilities in the
Acceptance process.
The Parties will jointly determine how many working days Enterprise
will have to accept the Deliverables or reject them in writing. If
Enterprise does not accept or reject the Deliverables within this period
or, in any case, when Enterprise makes any productive or live use of
the Deliverables, whichever occurs first, they will be incontrovertibly
deemed to have been Accepted.
In the event of rejection, Enterprise will communicate the reasons in

writing, following which Supplier will make the necessary changes
and resubmit the Deliverables to Enterprise. Once again, the Parties
will jointly agree a period within which Enterprise may accept the
Deliverables or reject them in writing. Any difference of opinion in this
matter will be submitted to the Progress Meeting.
If no Acceptance took place three months after delivery, and if the non-
Acceptance is attributable to the Supplier, Enterprise has the right to terminate
the relevant Subagreement with immediate effect in whole or in part, by
means of a registered letter and without prior judicial intervention.
When parties to a Subagreement have omitted to specify acceptance criteria in

the Subagreement, the Deliverables will be accepted, if the general acceptance
criteria for such Deliverables, as they can be reasonably understood by
professionals, knowledgeable persons, have been met.
3.2 Delays in Delivery

If expressly agreed in a Subagreement, the Supplier commits to respect
the agreed milestones, and shall notify Enterprise promptly in case of a
likely delay.
In such case, when delays in delivery of a Subagreement are, attributable

to the Supplier will be compensated by means of a fixed-rate discount on
the price stated in the relevant Subagreement. This discount will amount

to two percent of the Contract Price for the Assignment for each week's
delay, up to a maximum of 10 percent of the Contract Price.
It is the Supplier’s responsibility to prove that the delays are attributable to

force majeure, to Enterprise or to a Third Party appointed by Enterprise.
4. Contract Price
4.1. Time-based Contract Services
Time-based Contract Services will be provided on a Time and Materials
fee basis. Save as otherwise expressly provided, a fixed per diem rate
shall be laid down according to the Ratecard, a normal working day
consisting of eight (8) hours of work between 07:45 and 18:00, excluding
lunch time and breaks.
All rates must include any accommodation and travel expenses incurred
by the Contractors. They should not include taxes.
If for the project, Enterprise requires the supplier to travel, the Enterprise
travel policy will be applied if this policy has been communicated to
Supplier (bookings made by xxxx + 50 EUR per diem/day).
An invoicing plan shall be determined in each Subagreement

individually. In the absence of an invoicing plan, invoicing shall be
effected monthly in proportion to the progress of the work.
4.2 Project-based Contract Services

Unless otherwise agreed upon in the relevant Subagreement, Project-
based Contract Services will be provided on a fixed price fee, to be
agreed by the Parties prior to the commencement of the Assignment,
which should not include taxes.
However, the Contract Price shall be determined by reference to, among

other things, the relevant Ratecard, i.e., the Supplier shall provide details
of the resources he will allocate to the Assignment (number of man-days
by Contractor Profile), as well as any discounts, if any, with respect
to the Ratecard that may be granted to Enterprise for the particular
Assignment. Ratecard prices are agreed maximum prices for the duration
of the agreement.
The Contract Price shall include any accommodation and travel expenses
incurred by the Contractors. They should not include taxes.
The Contract Price indicated in the Subagreement shall be valid for the
entire duration of the Assignment.

4.3 Price Indexation

Every year, and only on the anniversary of the Effective Date of the
Agreement, on the written request of the Supplier at least one month in
advance, Ratecard rates and prices may be adjusted. Such adjustments
shall not give cause to any individual rate or price increment higher than:
P1 = P0 × (0.80 × S2/S1 + 0.20)
Where:
P1 = the revised price
P0 = the price in the year n-1
S1 = “Agoria” index for the current month preceding year n - 1
S2 = “Agoria” index for the current month preceding year n
year n = the contract year for which the revised price will apply
year n - 1 = the contract year preceding year n
Price indexation is applicable to all ongoing Subagreement, Including

Project based.
If for any reason whatsoever the aforementioned indexation system

should cease to exist, or if local regulations do not permit the Parties to
use the aforementioned indexation system for adjusting the prices, the
parties will revise this clause by mutual agreement and will adjust the
price on the basis of a comparable formula or other suitable method of
calculation.
5. Payments
The Supplier shall invoice within twelve (12) months after delivery of
the relevant Contract Services. Each claim of the Supplier with respect to
outstanding amounts that are not invoiced becomes prescribed after this period
of twelve (12) months.
Invoices are to be addressed to:

Enterprise
VAT: xxxxxxx
Attn. xxxxxxx
xxxxxxxxxxxx
xxxxxxxxxxxx
Bxxxxxxxxx
Invoices are payable within the 30 days of invoice date. Interest for late
payments are computed on the legal rate.
Any invoice not disputed by means of a registered letter received by Supplier

within a delay of 20 working days after the invoice date, explaining the
possible reason for disputing it, will be deemed to be accepted by Enterprise.

6. Intellectual Property
6.1 The Supplier acknowledges that all proprietary software of Enterprise, or
software which has been licensed to Enterprise by a Third Party, is and
will remain the property of Enterprise or of the Third Party. Enterprise
will grant, free of charge, a temporary, nontransferable and nonexclusive
license to use or modify all Enterprise software, tools, methods and
know-how in such a way as agreed on in each Subagreement. The
Supplier will not infringe any existing property right in respect of this
software or these tools, methods and know-how, and will comply strictly
with all obligations Enterprise has towards the Third Parties concerned.
6.2 The intellectual, nonmoral property rights to all Deliverables identified in
the Subagreements as client materials will be automatically transferred to
Enterprise as the development thereof progresses. Therefore, the Supplier
guarantees that he has the explicit authorization of the Contractors to
transfer such intellectual, nonmoral property rights, within the meaning
of the European Directive of 14 May 1991 on the legal protection of
computer programs. Enterprise grants Supplier a nonexclusive,
royalty-free, worldwide, perpetual right to use, reproduce, copy, adapt,
modify, multiply, sublicense and market the Client Materials.
6.3 The copyright and all other intellectual property rights in any materials
or software (whether written or machine-readable) created by or licensed
to Supplier prior to this Frame Agreement or outside a Subagreement and
any subsequent modifications to the same (“Pre-existing Works”) will
remain vested in Supplier (or our licensor). To the extent that these are
part of any of the Deliverables, Supplier will grant Enterprise a license to
use them in accordance with Clause 6.4. below.
6.4 Supplier is the sole owner of the copyright and all other intellectual
property rights in any materials in all Deliverables that are not identified
as Client Materials and in all other materials or software created
under a Subagreement. Supplier grants Enterprise a nonexclusive,
nontransferable license to use these Deliverables, which are not identified
as Client Materials (and any Pre-existing Works to the extent that these
form part of the Client Materials) for their own internal use and only for
the purposes for which they were delivered. Enterprise will refrain from
copying, reproducing, modifying, multiplying, adapting, sublicensing
these Deliverables (or any Pre-existing Works to the extent that these
form part of the Client Materials) to any Third Party.
6.5 Each party will at the request and reasonable expense of the other
execute all such documents and do all such acts as may be reasonably
necessary in order to vest in the other the rights granted to the other
under this Clause 6.
6.6 Without prejudice to the above, the Supplier will retain the right to
use ideas, methods or concepts developed in the performance of the
Assignment, regardless of whether they are patentable or not, in other
situations or for other clients.

7. Indemnity Against Third-party Claims

Each Party will hold the other Party harmless against any and all Third-party
Claims on the grounds of an alleged infringement of their intellectual property
rights as a result of the use of software, tools, methodologies and know
how to which the proprietary rights or rights of use were granted under the
Agreement.
If such infringement of the intellectual property rights of Third Parties by the

indemnifying Party is established in law, or if the indemnifying Party should
effect a settlement on this matter with Third Parties, the indemnifying Party, in
mutual agreement with the indemnified Party, will either acquire the right for
the indemnified Party to continue using the product in question, or will offer a
substitute or appropriate product of equivalent quality, or will take the product
back, subject to payment of the price paid by the indemnified Party for the
product in question. This without prejudice to the indemnified Party’s right to
prove that it has sustained a greater loss.
The indemnified Party must notify the indemnifying Party in writing of

the Third-party Claim within ten (10) working days after receipt thereof.
Thereafter, the indemnified Party will deliver to the indemnifying Party,
within five (5) working days of receipt thereof, copies of all notices and
documents (including court papers) received by the indemnified Party relating
to the Third-party Claim.
The parties will cooperate in mounting a defense against any and all
Third-party Claims. Such cooperation shall include providing records and
all information, which can reasonably be considered relevant and making
employees available to provide additional information and explanation.
The indemnifying Party is entitled to assume responsibility for the defense

against a Third-party Claim via legal counsel of its choice. If the indemnifying
Party chooses to handle the defense, the indemnified Party will have the right
to participate in the defense and to employ its own counsel at its own expense,
it being understood that the indemnifying Party will at all times be in charge
of the defense. The indemnifying Party will compensate the indemnified Party
for all reasonable fees and expenses of counsel employed by the indemnified
Party as long as the indemnifying Party, once notified by the indemnified
Party, does not itself assume responsibility for the defense against the
Third-party Claim notified.
The indemnifying Party will not be entitled to assume responsibility for the
defense against a Third-party Claim if there is a conflict of interest, in which
case the indemnified Party will be entitled to be compensated for the expenses
it reasonably incurs in defending itself against any such claim.

8. Contractors and Subcontractors

As a general rule, the Supplier is not permitted to employ any subcontractors,
freelance personnel or interim personnel for the execution of the Agreement.
Notwithstanding the aforementioned, for the performance of Contract
Services, Supplier may draw upon the resources of other member firms or
divisions within its own network of separate and independent legal entities,
who will act as subcontractors. Any references herein or in a Subagreement to
Supplier’s staff, employees, partners or members include subcontractors and
their staff. Supplier shall remain liable to the Enterprise for the fulfillment of
its obligations under a Subagreement.
The Supplier guarantees for the purposes hereof that any Contractor under
this first paragraph will be bound to the Supplier by means of a contract of
employment, that it will withhold and transfer the payroll taxes and social
security contributions due and that it will not act in contravention of labor
laws and social security regulations in force.
Enterprise is permitted, within the limits of Art. 31§1 of the Law of 24 July
1987 on Temporary Work, Temporary-Employment Business Work and
Provision of Labor for Users, to give the Contractors instructions, in executing
the Agreement, with regard to both working and rest times and the execution
of the work agreed upon with Supplier. However, the Supplier will be
responsible for the actual management and supervision of the Contractors.
In no case shall Enterprise be deemed to be the legal or actual employer
of the Contractors.
However, without prejudice to the first paragraph of this clause, the Supplier
may be allowed to employ any subcontractors, freelance personnel or
interim personnel for the execution of the Agreement after explicit and prior
written agreement by Enterprise, which shall be confirmed in any relevant
Subagreement.
Should Enterprise accept the use of subcontractors, freelance personnel or

interim personnel for the execution of the Agreement, the Supplier will be
required to:
• Maintain a permanently updated list of all Contractors, including at least the
following information: name, employment situation (employee,
self-employed, subcontractor or others), to the extent the subcontractors are
not Supplier entities.
• Explicitly accept any and all liabilities for the payment of payroll taxes and
social security contributions due by the Contractors.
• Explicitly confirm that the Contractors have not acted in contravention
of applicable labour laws and social security regulations, by providing a
certificate from Social Security Services confirming there are no
arrears outstanding.

The Supplier will take all steps necessary to ensure that the Contractors have
the required experience and competence to perform the Assignment properly
with respect to the Contractor Profile required by Enterprise.
The Supplier will ensure that the Contractors, present on Enterprise

premises, comply with Enterprise’ s safety regulations and any obligations
they are subject to in respect of safety and health at work, to the extent these
regulations and obligations have been communicated to supplier.
9. Progress Monitoring
The Supplier shall appoint a Project Manager for each Assignment in the
Subagreement, who shall act as point of contact. The Project Manager
appointed by the Supplier shall undertake the actual direction and exercise
the supervision of the Contractors of said Assignment.
Enterprise shall appoint an Enterprise Project Coordinator for each

Assignment in the Subagreement, who shall provide the Supplier with the
necessary information and take the necessary decisions, or ensure that other
persons take such decisions, in a timely manner.
The Project Manager and the Enterprise Project Coordinator shall meet at
regular intervals for discussions on the progress of the work. The Project
Manager shall prepare the minutes of the discussions on the progress of the
work. These minutes shall be submitted to the Enterprise Project Coordinator
for approval and shall not be binding upon Enterprise unless signed by the
Enterprise Project Coordinator.
The constitution and frequency of the Progress Meeting will be described in

the Subagreement.
The Project Manager will inform the Enterprise Project Coordinator of each
Progress Meeting and its agenda at least two business days beforehand.
The Project Manager will send minutes of the Progress Meetings to the
Enterprise Project Coordinator within two business days of the meeting.
If the Enterprise Project Coordinator protests the minutes of the Progress

Meetings, Parties will have ten (10) business days to agree on the minutes,
in despite whereof a new Progress Meeting will be held.
10. Change Procedure

The Parties acknowledge that, during the term of the Assignment, it may be
necessary to make changes to the Contract Services. Enterprise may give
instructions to change the Contract Services and may authorize, in writing,
any change proposed by the Supplier, which was not the result
of an instruction.

Because any such change might have an impact on the quality, duration and
the price of the Assignment and its Deliverables, strict mutual agreement
regarding the implementation of the change and the impact on the price and
duration is required. Any and all changes must be handled via the change
procedure outlined below.
Each party may submit a change request to the other party.
The other party, on receipt will register the change request. The Supplier
will handle the administrative follow-up of the change request.
If the Supplier believes a feasibility study or an analysis is required to

evaluate a change request, it must inform Enterprise of this in writing and
detail the additional cost to Enterprise, if any. Only if Enterprise formally
approves this request in writing, the Supplier may carry out the feasibility
study or analysis, as approved, and charge Enterprise for this.
The Supplier must submit an implementation change proposal to Enterprise,

whether after a feasibility study or analysis or otherwise. This proposal must
specify what the potential impact of the requested change will be on the
Deliverables (quality, duration and cost). The impact must be noted on or
attached to the change request.
The implementation proposal will either be approved or rejected at the

Progress Meeting, or if no Progress Meeting is installed, by the Enterprise
Project Coordinator and the Project Manager. The decision will subsequently
be set out in writing as an addendum to the relevant Subagreement and
signed by both Parties. Until parties have agreed upon a change request,
the relevant Subagreement shall be performed in accordance with the latest
agreed version of that Subagreement.
11. Training
No in-house training will be provided except by mutual consent of the Parties.
If the Contractors attend training courses organized or funded by Enterprise,

the following rules will apply (if the training is necessary for executing
the project):
• Enterprise will be invoiced for the hours spent attending a training course.
• The training costs by an in-house Enterprise instructor will be charged to
the Supplier at a rate of 275 EUR/day.
• In the case of training provided by a third-party instructor, the actual
cost will be shared proportionally between the Enterprise and external
participants (pro rata allocation) and charged accordingly to the Supplier
whose Contractors participated in the training course.

The Supplier acknowledges that only a member of Enterprise’s Senior

Management can authorize exceptions to this arrangement.
If the Supplier attends external ad hoc training courses, an agreement will

be made directly between the Supplier and the third-party training provider.
Enterprise will not be involved in this.
12. Resources Provided by Enterprise

Enterprise will provide the Supplier with the necessary documentation and
information, including the Enterprise health and safety regulations, as well
as the materials, space and machine time and all other facilities, which the
Supplier reasonably requires for the fulfilment of its obligations under the
Agreement. Enterprise will not, however, provide the Supplier with
parking facilities.
The Supplier guarantees that the Contractors shall use the resources provided
by Enterprise simply and solely for the performance of and in relation to
the Agreement.
Supplier will not be liable for any loss or damage arising from reliance on
any information or materials supplied by Enterprise or any third party, or for
any inaccuracy or other defect in any information or materials supplied by
Enterprise or any third party.
In addition, the Supplier will comply with any and all safety regulations
and codes of conduct required by Enterprise with respect of the use of these
resources, to the extent these regulations and codes are communicated
to Supplier.
13. Confidentiality
Parties acknowledge that the existence and content of the relationship with
between Enterprise and Supplier, as well as the information and knowledge
concerning one of the parties obtained or received in the performance of the
Assignment (such as technical, financial, statistical, personal and
customer-related information of Enterprise-affiliated Companies,
transactional data, information on the management of a business, etc.) which
is marked confidential or manifestly confidential is confidential information.
This, however, is not the case for:

• Information in the public domain or information which has legitimately
been made public without contravening the present Agreement
• Information legitimately received from Third Parties, insofar as these Third
Parties are not themselves subject to a duty to observe secrecy
• Information that has been developed or discovered completely
independently of Enterprise

For the purposes of this article, the Enterprise-affiliated Companies will not
be considered Third Parties. Likewise, member firms of the Supplier’s global
network will not be considered Third Parties.
Parties will use best efforts to ensure that in no way, either directly or
indirectly, verbally or in writing or by any other means, divulge this
confidential information to Third Parties unless the other party has given
its prior written consent or unless this is necessary for legal, accounting or
regulatory reasons.
With regard to all confidential information which, regardless of the form in

or the data carrier on which it exists, is in the possession of the Supplier or
Enterprise or which has been provided to the Supplier or to Enterprise, the
parties undertake:
• To take the same precautions as it would to prevent the unauthorized use,
dissemination or publication of its own, similar confidential information
• To ensure an adequate level of security in the saving, storage and dispatch
of the information to preclude its loss, theft, unauthorized modification
and/or disclosure
• Not to use the information for any purpose other than that agreed
• Not to keep the information longer than reasonably necessary to allow the
Assignment to be carried out, and to return this information, including any
copies made, to the disclosing party immediately after all its obligations
have been met, or else destroy it after having been authorized to do so by
the disclosing party. However parties expressly agree that each party has at
all times the right to keep one copy of all (confidential) information solely
for archiving and defence purposes.
• To have the obligations agreed upon carried out exclusively by Contractors
the Supplier may reasonably assume to be reliable
The parties must also ensure that any person to whom Confidential
Information is disclosed is aware of the above obligations and are
contractually bound to comply with them.
This article will remain in effect both during the Frame Agreement and after
it has come to an end.
14. Premature Termination of the Agreement

Each Party has the right by operation of law to terminate the Agreement in
whole or in part, without prior intervention of the courts, with immediate
effect, from the moment that:
• The other Party is declared bankrupt.
• The other Party is subject to a sequestration.
• The property of the other Party becomes subject to an attachment, in
so far as this attachment brings to light a material adverse influence on
its solvency, or hinders or renders impossible the performance of its
commitments under the Agreement.
• The other Party is forced to embark on a closing-down sale as a trading

organization.
• The other Party is voluntarily or compulsorily wound up as a result of a
merger, split or similar procedure, with the exception of the procedures
forming part of a restructuring of the group of which this Party is part.
In the event of repeated or substantial failure by either of the Parties to

perform any of its obligations or tasks in pursuance of a Subagreement
and if this failure is not fundamentally remedied within thirty (30) days of
having been notified in writing by means of registered letter, the other Party
may by means of written notification sent by registered letter terminate the
Subagreement in whole or in part, as from the date stated in the notice
of termination.
In the event of repeated or substantial failure by either of the Parties to

perform any of its obligations or tasks in pursuance of the Agreement and if
this failure is not fundamentally remedied within thirty (30) days of having
been notified in writing by means of registered letter, the other Party may
by means of written notification sent by registered letter terminate the
Agreement in whole or in part, as from the date stated in the notice
of termination.
If a Subagreement is terminated prematurely in accordance with this Article

because of a serious shortcoming on the part of the Supplier, the total
liability of the Supplier will be set at 100 percent of the invoiced portion of
the Contract Price.
15. Resolution of Disputes

If any dispute should arise relating to the Contract Services, that dispute will
be submitted to the relevant Progress Meeting, or if no Progress Meeting is
installed, by the Enterprise Project Coordinator and the Supplier’s Project
Manager, which has/who have the task of deliberating in order to resolve the
dispute or of negotiating any amendment to the Agreement. This deliberation
will convene as often as the Parties consider reasonably necessary in order to
further the resolution of the dispute.
During the deliberation any information reasonably requested by each Party

will be supplied to ensure that each Party is fully informed.
If the dispute is not resolved within 30 days through such negotiations, each
party shall have the right to submit the unresolved issue to the <city> courts,
which shall have exclusive jurisdiction to settle any such dispute, controversy
or claim which may arise in connection with the legal relationships
established by the present Agreement.

16. Liability for Defects and Noncompliance/Use of Deliverables

The liability of the Supplier for defects or noncompliant Deliverables is in
the first instance limited to repairing, restoring or replacing the work which
is defective or noncompliant. If these solutions are not possible, the Supplier
will make good the loss suffered by Enterprise within the limits
defined hereunder.
The total liability of the Supplier for the Assignment is limited to

reimbursement for the direct loss, up to a maximum amount equal to the
amount paid or payable by Enterprise to Supplier.
Any extra-contractual liability of Supplier is subject to the same limitation.
The Supplier will take out insurance for this with a reputable insurance
company. Evidence of such insurance shall be presented to Enterprise, on
Enterprise’s simple request.
Neither Party will be liable under the Agreement for indirect loss in any
form whatsoever, such as a loss of earnings, business interruption or
stagnation, losses resulting from a loss of data, personnel costs and costs of
personnel depletion. For the purpose of the Agreement, indirect loss does not
include damage to hardware and other movable and immovable items, such
as software, nor the costs of repairing the hardware and data files, the costs
of fallback to another system or the necessary intervention by Third Parties.
This liability limitation will not apply in case of intentional fault by Supplier.
The Services and the Deliverables are provided solely for Enterprise’s benefit
and use and only for the purpose stated in the Subagreement. As such
Services and Deliverables may not be appropriate for any other purpose,
any use Enterprise makes of Services and Deliverables for such another
purpose is at its sole risk and responsibility. Enterprise may not disclose
the Deliverables, provide copies of the Deliverables or make the benefit
of the Services available to any third party without Supplier’s prior written
consent which Supplier may, at its sole and absolute discretion, refuse or
grant, subject to the third party agreeing to appropriate terms stipulated by
Supplier. Supplier accepts no liability or responsibility to any third party who
benefits from or uses the Services or gains access to the Deliverables, without
its aforementioned written consent. Enterprise agrees to hold harmless and
indemnify Supplier against any liabilities, losses, expenses or other costs
Supplier reasonably incurs in connection with any claims against Supplier or
any other Supplier Entity by third parties in connection with or arising out of
the Frame Agreement or any Subagreement.

17. Liability for Material Damage and Physical Injury

The Parties are liable for material damage and physical injury which is
caused by fault on their part.
In the event of material damage, the total liability of each Party will be
limited to 125.000 euro per event, with a series of related events being
counted as a single event.
This liability limitation will not apply in case of intentional fault by Supplier.
The total liability of each Party in the event of death or physical injury will
be determined in accordance with the applicable law.
The Parties will take out insurance for this with a reputable insurance
company. Evidence of such insurance shall be presented to the other Party,
on that Party’s simple request.
18. Force Majeure

Neither Party will be liable either in whole or in part vis-à-vis the other Party
for delays or deficiencies in performance if those delays or deficiencies are
attributable to causes which are beyond its reasonable control.
In the event of force majeure as described above, the Party which invokes
force majeure will notify the other Party thereof in writing within seven (7)
days, stating the nature of the force majeure and of the underlying
circumstances. In the event of force majeure which continues for longer
than three (3) months, the Party against which the force majeure has been
invoked will be entitled to terminate the Agreement with immediate effect by
registered letter.
For the purpose of the Agreement, force majeure does not include a failure
to comply or a failure to comply on time by a subcontractor, with the
obligations which that party has assumed vis-à-vis one of the Parties, unless
the Party in question demonstrates that the failure to comply or comply on
time with that obligation is attributable to force majeure.
19. Independent Contractor

The Supplier will carry out the Agreement as an independent contractor, and
will have neither the right nor the authority to enter into obligations, expressly
or tacitly, for the account of Enterprise, and will not be authorized to represent
Enterprise as its intermediary except by express written mandate.
20. Predatory Hiring

Both Parties undertake not to seek work from or offer work to, nor to make
use of other services of an employee of the other Party or an employee of
the Affiliated Companies thereof or an employee, director or partner of a

member firm of the Supplier’s global network, involved in the execution of

this Agreement for the duration of the Agreement and for a period of twelve
(12) months from the end date of the Agreement.
If a Party employs an employee of the other Party in contravention of the

foregoing provision, compensation will be payable equivalent to 12 months
of gross salary of said employee.
This clause will not apply on hiring as a result of general advertising

campaigns.
21. Service Continuity

The Supplier shall maintain to a considerable extent the stability in the team
of Contractors and shall document the Contract Services in a structured way.
The Supplier warrants that the Contractors possess the requisite experience
and competence to perform the Contract Services in an adequate manner
and, in particular, that:
• The Project Manager is an experienced and qualified employee of the Supplier.
• The other Contractors have the required competence and are sufficiently
initiated into the Assignment prior to the commencement of the Assignment.
Although the Supplier undertakes to use best efforts to ensure continuity

within the team of Contractors, where any changes in named Supplier staff
are necessary or when such individuals need to attend training programmes
to develop their professional skill and knowledge, Supplier will give
Enterprise reasonable notice of the changes and will provide Enterprise with
details of replacement staff.
If Enterprise forms the opinion that, for pressing reasons that could seriously
jeopardize the success of the Assignment, all cooperation with a Contractor
has become impossible, Enterprise must notify the Supplier thereof by
registered letter, requesting the replacement of that Contractor. The Supplier
must then, within one month of receiving the registered letter, appoint a
replacement that is capable of working on the Assignment.
22. Press Releases

No press releases, public announcements or public disclosures relating to the
Agreement, including but not limited to promotional or sales material, will
be issued by either of the Parties without the express prior written consent of
the other Party.
23. Binding Force and Assignments

The Agreement binds the Parties and their respective successors and
assignees. Unless otherwise agreed, each Party undertakes not to transfer
the rights and obligations arising from the Agreement to Third Parties either
in whole or in part without the prior written consent of the other Party. This
clause is not applicable in all cases of legal succession.
24. Waiver of Rights

The fact that one of the Parties fails to exercise or enforce its rights under
the Agreement vis-à-vis the other Party will in no way constitute a waiver of
its rights by that Party.
25. Severability
If any provision in the Agreement is deemed to be invalid, unlawful or
unenforceable, both Parties will be relieved of all rights and obligations
arising from that provision, but only in so far as that provision is invalid,
unlawful or unenforceable. The provision in question will be amended in
so far as this is necessary in order to make it valid, lawful or enforceable,
without affecting the spirit of the Agreement.
Subject to evidence to the contrary, all other provisions in the Agreement

will be regarded as valid, lawful and enforceable.
26. Full Agreement and Precedence

The Agreement:
(i) Constitutes the full agreement between the Parties
(ii) Supersedes every agreement, communication, offer, proposal or
correspondence, verbal or written, exchanged or entered into between the
Parties prior to the date of the Agreement and relating to the same topic
(iii) May only be amended in writing and by duly authorized representatives
of the Parties
In the event of any inconsistency between the terms and conditions
contained in the Frame Agreement and the provisions of the Subagreement,
the provisions that shall prevail are the provisions of the Subagreement. In
the event of any inconsistency between the provisions of the Subagreement
and the Statement of Work or any attachment or appendix, the Subagreement
will prevail.
27. Electronic communications

Parties may wish to communicate electronically with each other. However,
the electronic transmission of information cannot be guaranteed to be secure
or virus or error free and such information could be intercepted, corrupted,
lost, destroyed, arrive late or incomplete, or otherwise be adversely affected
or unsafe to use. Parties recognize that systems and procedures cannot be a
guarantee that transmissions will be unaffected by such hazards.
Parties confirm that they each accept the risks of, and authorize, electronic
communications between them. They each agree to use commercially
reasonable procedures to check for the then most commonly known viruses
before sending information electronically. They will each be responsible
for protecting their own systems and interests in relation to electronic
communications and neither Enterprise nor Supplier (in each case including

our respective partners, employees or agents) shall have any liability to

each other on any basis, whether in contract, tort (including negligence) or
otherwise, in respect of any error, damage, loss or omission arising from or
in connection with the electronic communication of information between
parties and their reliance on such information.
The exclusion of liability in this clause shall not apply to the extent such
liability cannot by law be excluded.
28. Governing Law and Competent Jurisdiction

The Agreement will be subject to the laws of <country>. Any disputes
relating to the formation, performance or interpretation of the Agreement
will be submitted to the courts of <city>.
III. Sample Subagreement
Subagreement No. C…
This Agreement is concluded between ……………....., with registered office
at ....................., ..............................................., entered in the
Register of Legal Persons under No. .................. and hereinafter referred to as
the Supplier,
and
………………, with registered office at ………………, entered in the

Register of Legal Persons under No. ……………… and hereinafter referred
to as Enterprise.
General Terms and Conditions

Save as may otherwise be expressly stipulated, this Subagreement is governed
in its entirety by the general terms and conditions of the “Agreement relating
to Contract Services”, C....…...
Subject Matter
[Description of the Assignment]
Acceptance
[Procedure, Criteria]
Contract Price
Performance of this Assignment shall be effected at … euro < a day, in total,
etc. >, VAT excluded.
Invoicing shall be effected monthly, on the basis of …..

Time Line
Start of the Assignment: ../../….
Termination of the Assignment: ../../….
with an option for extension.
Coordination
Project Manager: ......................…..
Enterprise Project Coordinator: ......................…..
Location: ......................…..
Done at ……………… on ……………… in duplicate, each Party

acknowledging having received a copy hereof.
IV. Ratecards
1. Time-based Contract Services
2. Project-Based Contract Services
3. Discounts


Appendix F. SLA Template 125
Appendix F. SLA Template

Overview of the Approach
This section gives an overview of all the elements taken into account in the mission
of the vendor, which can be represented visually by means of a spider diagram,
as shown in figure 15. Other elements in this chapter can contain the precise
definitions of the RACI (responsible, accountable, consulted and informed) matrix
and the roles and stakeholders described throughout this publication:
• RACI formalism
• Definition of roles
• Definition of stakeholders
Figure 15—Service Level Agreement (SLA) Spider Diagram Example

Architecture
References Plan
SLA Document Implementation
Roles Information Project Implement
RACI Control/Monitor
Penalties
Technical Framework
Appendices Quality Plan
Contacts
SLA Configuration
Management
Incident
Management
KPIs
Problem
Service Level Management
Reporting Management Recurring
Activities Release
Management
Quality
Availability
Management
Control/Monitor
Penalties
Description of Services
This section begins with a description of the scope of the services that are being
delivered to the enterprise. In a subsequent section, the exclusion and applicability
conditions can be documented. The general principle here is that any element not
listed in the scope of services is considered to be out of scope of the service level
agreement (SLA). In the force majeure section, any event or circumstance that is
beyond the control of the vendor can be described. The penalties that are set in the
SLA are not applicable to the events and circumstances that are in the force majeure
section. In the last part of this section, the services provided are detailed, including

a description of service deliverables, the time frame in which the SLA is valid and
the fees related to the delivered services:
• Scope of the services
• Exclusion and applicability conditions:
– General principle
– Force majeure
• Services provided in the context of this SLA:
– Description of deliverables
– Validity period
– Fees
Levels of Service
The first part of this section should detail a number of key performance indicators
(KPIs) measuring the level of services and define a claim or bonus for each KPI
to motivate the client and the vendor to deliver on time and with the required
quality. The next part details the penalties and bonuses related to the KPIs. Good
practice defines different penalties for different ranges of the KPI outcome.
It is also possible to add a repetition factor to address the event of continuous
underperformance. When a certain unwanted value for a KPI is reached multiple
periods in a row, for a specified number of months per year, the repetition factor
guides how to proceed. Good practice is also to include bonuses when KPI outcome
is better than required ranges. This section is in line with the COBIT 5 enabling
process APO09.04 Monitor and report service levels.
Key performance indicators can be presented in a table with the following headers:
• ID
• KPI
• Description
• Specification (calculation method)
• Client justification
• Unit
• Target
• Limit
• Bonus
• Computations for penalties or bonus
Other Quality Expectations
This section provides an overview of all the other quality expectations. Specific
topics will vary depending on each enterprise’s needs. The following example topics
show the content for this section:
• Complaint management
• Escalation procedure
• Periodic service review report:
– Contents
– Frequency
Appendix F. SLA Template 127
– Distribution list
• Service review report meetings:
– Goals
– Frequency
– Attendees
• Change management procedure
• Process of dissolution
• Level of access provided to the vendor
• Guarantees of nondisclosure
• Agreements with potential subcontractors
Complaint management describes the process that will be used to address

complaints, who will audit a complaint and what information a complaint must
contain. If difficulties continue between the two parties, the escalation procedure
can be activated. This is an exceptional action that is to be taken only as a last
resort, when one of the two parties is not satisfied. This section details the different
levels of complaints and the related roles of the client and vendor.
An SLA requires regular monitoring to allow for corrections to achieve its defined
goals, gauge any variations and register penalties or bonuses. It is important to
detail the content, frequency and distribution list of performance reports. Periodic
meetings with the vendor to review meeting performance reports should be properly
defined. These periodic meetings will contribute to the transparency of both parties
to specify the goals, frequency and attendees of these meetings.
Another important element in this chapter is the change management procedure.

It describes the process of how to treat changes to the scope, fees and KPIs and
details the change management process as described in COBIT 5 enabling process
APO09.05 Review service agreements and contracts.
This section is a good place to document the termination conditions of the SLA
(process of dissolution), level of access provided to the vendor at client premises,
guarantees of nondisclosure and agreements with potential subcontractors.
RACI Matrix
The last section details, for each service or activity, the stakeholders (identified
in the overview of the approach) that are accountable, responsible, consulted
or informed.
Appendix
The appendix can provide additional important information for a vendor that
describes services or calculates KPIs. A contact information list of key stakeholders
or responsible parties for the SLA can be helpful for the client and the vendor.


Appendix G. Service Level Agreeement (SLA) Checklist 129
Appendix G. Service Level Agreement

(SLA) Checklist
Figure 16—SLA Checklist
Overview of the Approach Relevant? Applied?
RACI formalism
Definition of roles
Definition of stakeholders
Description of Services Relevant? Applied?
Scope of the services
Exclusion and applicability conditions:
• General principles
• Force majeure
Services provided in the context of this SLA:
• Description of service deliverables
• Time frame
• Fees
Levels of Service Relevant? Applied?
Key performance indicators (KPIs)
Computations of penalties/bonus
Other Quality Expectations Relevant? Applied?
Complaint management
Escalation procedure
Periodic service review report:
• Contents
• Frequency
• Distribution list
Service review report meetings:
• Goals
• Frequency
• Attendees
Change management procedure
Process of dissolution
Level of access provided to the vendor
Guarantees of nondisclosure
Agreements with potential subcontractors
RACI Matrix Relevant? Applied?
RACI Matrix
Appendix Relevant? Applied?
Extra details for services to be performed
Calculation details for KPIs
Contact information list of key stakeholders


Appendix H. Example SLA Template 131
Appendix H. Example SLA Template

Service Level Agreement
Template
This file is based on the template “Sample Service Level Agreement” file name
egsla.doc from the website http://helpdeskclientsupport.wikispaces.com Lesson 9.
Full link to document is: http://helpdeskclientsupport.wikispaces.com
/file/detail/egsla.doc
Table of Contents
1. Service Level Agreement

1.1 Goal
1.2 Objectives
1.3 Period of Agreement
1.4 SLA Review Process
1.5 References
1.6 Service Level Monitoring
1.7 Complaints
2. <VENDOR> Responsibilities
2.1 Functional Overview
2.2 Hours of Operation
2.3 Response Times
2.4 Priority Level Response Times
2.5 Support Available
3. <CLIENT> Responsibilities
3.3 Response Times
3.4 Service Level Targets
4. Supported Products/Applications/Systems
4.1 Hardware Support Services
4.2 Software Support Services
4.3 Training Services


for
Supply of Support Services
between
<VENDOR>
and
<CLIENT>
1.1 Goal
The goal of this agreement is to provide a basis for cooperation between
<VENDOR> and <CLIENT> for support services. <VENDOR> commits itself
to ensuring timely and efficient support. This agreement will contribute to the
environment of achievement and maintenance of targeted service levels.
1.2 Objectives
• Enhance the business relationship between <CLIENT> and <VENDOR> to
guarantee effective support.
• Document the responsibilities of all parties.
• Guarantee that <VENDOR> delivers the agreed-on quality with adequate support
for <CLIENT>.
• Define in detail the service to be delivered by <CLIENT> and the level of service
that can be expected by <VENDOR> to meet both <CLIENT> and <VENDOR>
expectations.
• Provide a system of monitoring to have objective measurement.
• Provide a mutual understanding of the service level requirements.
1.3 Period of Agreement

This agreement will commence on the date specified in the signed contract
following the acceptance by both parties and will continue until terminated.
1.4 SLA Review Process

This agreement will be reviewed within one year after the official start date, or
at a mutually agreed-on date, by <VENDOR> and <CLIENT>. The review will
cover technology services provided, service levels and procedures. Changes to this
agreement must be approved by both parties.
1.5 References
The following documents will serve as a basis for the policies and procedures
of <VENDOR> operation. They also will define the support levels required and
prioritization of computer faults by <VENDOR>.

Copies of these documents will be made available to <CLIENT> as they become

available to ensure compliance with <CLIENT> standards:
• Supported infrastructure
• Supported applications
• Security and retention procedure
• User development guide
• Acceptable network procedures
1.6 Service Level Monitoring

The success of SLAs depends firmly on the ability to accurately measure
performance. In that way, reliable information can be provided to <CLIENT>.
The constant monitoring of service factors is a must, considering that they are
meaningful and measureable. Measured levels must be compared with agreed-on
levels on a regular basis by both parties.
Service level monitoring will be performed by <VENDOR>. Reports will be

produced as and when required and forwarded to <CLIENT>.
Service level monitoring and reporting is performed on response times for faults, as
specified in Section 3.4 of this agreement.
1.7 Complaints
All complaints relating to the operation of the help service, including:
• Expected level of support
• Actual support offered and delivered
• Personnel responsible for providing or administering support
• Any other issue relating to this document or the relationship between <VENDOR>
and <CLIENT>
2. <VENDOR> Responsibilities

Provide a service for the registration and resolution of all computer-related
problems submitted by end users of <VENDOR>. This includes the following
specific responsibilities:
• Provision of a help desk or similar facility
• Extracting information from end users according to <CLIENT>
• Timely referral of faults to <CLIENT>
• Monitoring of problem resolution
• Delivering SLA reporting

<VENDOR> help/support service will operate daily from 09:00 to 17:00, except on
public holidays when alternative arrangements will be made and publicized.

2.3 Response Times

The table in section 2.3 illustrates the priority assigned to problems according to the
importance of the reported situation. This importance is to be assessed during the
initial telephone response to <CLIENT>.
Non- Non- Request

Support Business- Business- business- business- for
Level critical critical critical critical Service
Fatal Impaired Fatal Impaired
High 1 2 2 3 5
Medium 1 2 3 3 5
Low 2 or 3 3 or 4 3 or 4 5 5
Legend:
• Fatal—Total system inoperability
• Impaired—Partial system inoperability
• Business-critical—Unable to perform core business functions
• Non-business-critical—Able to perform limited core business functions
2.4 Priority Level Response Times

The table in section 2.4 shows the required initial telephone response times for
the individual priority levels. All times indicated represent telephone response
time during specified working hours of 09:00 to 17:00, Monday to Friday, unless
otherwise indicated in this document or otherwise agreed on by <VENDOR>
and <CLIENT>.
Response Time
Priority Level (Minutes)
1 12
2 25
3 40
4 50
5 90
Telephone Response Time

The indicated telephone response time represents the maximum delay between a
request being reported to <CLIENT> and <CLIENT> representative contacting
<VENDOR> by telephone.
Notification Path
The purpose of this telephone contact with <CLIENT> is to notify <CLIENT> of
the receipt of the fault/request from <VENDOR> and provide <CLIENT> with
details of the proposed action to be taken in response to the particular fault/request.

<CLIENT> representative must notify <VENDOR> immediately when escalating

a request. If so requested by <CLIENT>, <VENDOR> will facilitate the actual
escalation of the request. Escalated requests will require telephone response to
<VENDOR> by <CLIENT>, with the same conformities as default requests.
2.5 Support Available

The table in section 2.5 shows the support available for each support level, as
defined by the infrastructure list. The recommended infrastructure list is produced
by <VENDOR> as the standard for information management usage within
<VENDOR>.
Internally External
Support Level Internal Support Conducted Training Priority Support/Training
Advised Full Available High Yes
Supported Full Not available Medium Yes
Acknowledged Limited Not available Low Yes
Not recommended None Not available None Yes
The sourcing of external support services for infrastructure at the “acknowledged”

and “not recommended” levels will be at the expense of <CLIENT>. <VENDOR>
will not be responsible for any costs for the support of infrastructure under
these levels.
Support services provided by <VENDOR> for products not contained in the

infrastructure list document or those listed at the “not recommended” level will be
limited subject to available <VENDOR> resources.
External training courses will always be provided at the expense of <CLIENT>.

Internally conducted training courses may also be at the expense of <CLIENT>.
3. <CLIENT> Responsibilities

<VENDOR> is a provider of in-house server infrastructure and monitoring
platforms and support to <CLIENT>.

<VENDOR> representative will be available to provide support functions between
the hours of 09:00 to 17:00, Monday through Friday (public holidays excluded),
unless alternative arrangements have been agreed on by <CLIENT>.
3.3 Response Times

<VENDOR> will accept the priority assigned to a problem by <CLIENT>,
according to the matrix in section 2.3, and provide a response to <CLIENT>,
as detailed in the table in section 2.4.

3.4 Service Level Targets

<VENDOR> will respond within the time specified by the priority allocation.
<VENDOR> will issue reports as and when required to the <CLIENT> unit
manager for the purpose of gauging <CLIENT> performance.
4. Supported Products/Applications/Systems
4.1 Hardware Support Services

Hardware products supported:
• <VENDOR> type XYZ router
• <VENDOR> type XYZ switch
• <VENDOR> type XYZ UPS
• Generic firewall
• Other vendor remote connection concentrator
4.2 Software Support Services

Software products supported:
• <VENDOR> specific remote control software
• Generic monitoring software
• Open source operating system
• <VENDOR> operating system
• <VENDOR> client ticketing system portal
4.3 Training Services

Available courses:
• Basic usage of <VENDOR> ticketing service
• Advanced usage of <VENDOR> ticketing service
• Basic commands of generic routers
• Advanced commands of generic routers

Appendix I. Example Generic SLA 137
Appendix I. Example Generic SLA

Generic
Table of Contents
1. Introduction
1.1 Goals and Objectives
1.2 Service Catalog
1.3 Roles and Responsibilities
2. Services in Scope
2.1 E-procurement Modules and Platforms
2.1.1 Description
2.1.2 Responsibilities
2.2 IT Operations Activities
2.2.1 Description
2.3 Standard Changes
2.4 Incident Management
2.4.1 Description
2.4.2 Classification of Incidents
2.5 Release Management
2.5.1 Description
2.6 Change Management
2.6.1 Description
3. Service Level Management
3.1 KPIs
3.1.1 Modules and Platforms
3.1.2 Incident Management
3.1.3 Change Management
3.1.4 Release Management
3.2 Reports
3.3 Governance Structure
3.3.1 Escalation Procedure
3.3.2 Service Level Reviews
4. Glossary


for
E-procurement
between
<VENDOR>
and
<CLIENT>
1. Introduction
1.1 Goals and Objectives

<CLIENT> and <VENDOR> have agreed on the services that are included in the
supply of an e-procurement platform by <VENDOR>. This document contains the
descriptions of these services and the definition of the agreed-on target levels.
1.2 Service Catalog

The services included in the agreement concern:
• E-procurement modules and platforms
• Request fulfillment
• Incident management
• Change management
• Release management
• IT operations management
1.3 Roles and Responsibilities
Role Responsibility
Service manager • Accountable for the services and service levels delivered
• Coordinates meetings with <CLIENT> to provide status reports
• Provides service metrics to <CLIENT>
• Coordinates service requests
• Escalates issues to necessary parties for resolution
Incident manager • Manages incidents and solutions
• Reports incidents to <CLIENT> within agreed-on times
Change manager • Manages all change requests from <CLIENT>
• Manages all internal change requests
• Keeps <CLIENT> informed about all changes that are approved, and
provides release plans
• Collaborates with release manager to move changes to production
• Helps document changes to services and supporting technology

Role Responsibility
Release manager • Collaborates with change manager to process change requests and move
changes to production
• Makes sure that training and support material is created and delivered
before a major release
• Keeps <CLIENT> informed about the status of the release and confirms the
release date before the implementation
• Helps document changes to services and supporting technology
IT manager • Takes care of all IT operations activities and is responsible for the
availability of the service
2. Services in Scope
In this section, the services covered by this SLA are detailed. It contains a description of
each service and the responsibilities on both supplier and customer sides.
2.1 E-procurement Modules and Platforms

2.1.1 Description
The e-procurement system that <CLIENT> will use consists of three modules, two
platforms and two interfaces.
The modules are:

• E-request
• E-ordering
• E-invoicing
The platforms are:

• Supplier portal
• Customer portal
The interfaces are between:

• The e-invoicing module and the supplier back end
• The e-invoicing module and strategic and process back office
The supporting services that are detailed in the remainder of this document apply to
all items listed previously.
<VENDOR> IT manager ensures 98 percent availability of the modules and the
platforms, maintenance time excluded.

2.2 IT Operations Activities

2.2.1 Description
IT operations activities are sets of specialized technical activities ensuring that the
technology required to deliver and support the e-procurement solution and related
services is operating effectively and efficiently.
Specifically, the activities are shown in the following table.
E-procurement Project Activities

Maintenance of the technical Hosting of the infrastructure Maintenance of interfaces
environments (application,
servers, databases, backups)
Within the scope, three kinds of technical maintenance, which affect the availability
of the system, are distinguished as shown in the following table.
Normal Maintenance Major Maintenance Infrastructure Maintenance

• Outside business hrs • Outside business hrs •M aintenance of electricity
• Maximum four • Maximum 12 hrs and cooling
hrs unavailability unavailability • As much as possible outside
• User notification: five days • User notification: 10 days of business hrs
•M aximum six days
unavailability
•U ser notification: one month
If for any reason the proposed time slot is in conflict with other maintenance job
schedules, <CLIENT> should contact the service manager.
<VENDOR> IT manager takes care of all IT operations activities. All
communication about maintenance and infrastructure are handled between
<CLIENT> and service manager. Service manager will make sure that <CLIENT>
is informed about maintenance within the previously determined notice period, and
any conflicts for <CLIENT> will be handled by service manager.
2.3 Standard Changes

Standard changes are requests by <CLIENT> that have been defined as:
• New supplier activation
• New/change users on the portals
• Customer entity changes

2.4 Incident Management

2.4.1 Description
An incident is defined as an unplanned interruption of the IT service
(e.g., unavailability of the service) or a reduction in the quality of the IT service
(e.g., data corruption). Fast restoration of the service is the main goal of
incident management.
Incidents can be detected by anyone. In case of an incident, a ticket will be created

and assigned to the help desk.
Closure of a ticket is only possible with a final fix. In the event that a final fix is
not feasible, a workaround shall be proposed and a problem ticket will be created to
allow further investigation. Cross-referencing of problem and incident shall allow
proper follow-up.
2.4.2 Classification of Incidents

Incidents are classified according to their business priority. The determination of
business priority is as follows. Impact and urgency of the incident are evaluated:
• Impact—The measure of the effect of an incident
• Urgency—The measure of the time it takes until an incident has a significant impact
ased on their business priority, three levels of classification will be used:

B
• Low
• Medium
• High
he priority of the incident will determine the resolution time or mean time to
T
repair (MTTR):
• Low: MTTR 120 hrs
• Medium: MTTR 24 hrs
• High: MTTR 4 hrs
<VENDOR> incident manager is responsible for solving the reported incidents
within the agreed-on time frame.
<CLIENT> must ensure reasonable availability of staff to answer questions or test

something when <VENDOR> is resolving an incident or request.
2.5 Release Management

2.5.1 Description
A release is a set of changes that will be implemented simultaneously. Release
management defines the schedule for implementing releases and makes sure to
minimize the impact of changes and provide stability of services for the users through
careful planning and strategy.

Three types of release are distinguished:

• Major releases—Has a significant impact on the system and contains new
features. User acceptance testing (UAT) will be set up and users will be requested
to be involved.
• Minor releases—Has no significant impact on the system and contains smaller
incremental improvements or fixes and technology upgrades. For this kind of
release, no UAT is required.
• Emergency releases—This type of release consists of quick fixes to repair
incidents and problems. There is usually no UAT required or planned, but UAT
is scheduled on an ad hoc basis. For emergency releases, the process will be
applied retroactively.
Service manager guarantees that a new release remains backward compatible with
documents created with older versions. A minimum notice period of four months will be
respected in the event of a release that contains changes that are not backward compatible
with <CLIENT> systems. <CLIENT> has to make sure that the interface changes on its
side and on the supplier side happen within these four months.
<CLIENT> ensures availability of the people involved in UAT. The period of UAT is
planned in advance of the release planning and communicated by release manager.
Release manager shall provide training and support material a minimum of two
weeks before a release goes live.
Release manager also keeps <CLIENT> informed about the status of the release
and confirms the release date two weeks before implementation.
2.6 Change Management
2.6.1 Description
A change is the addition, modification or removal of anything that could have an
effect on IT services. Change management is a process comprised of identification,
prioritization, initiation, evaluation and controlling changes to the application. The
change advisory board (CAB) will analyze and discuss the collected changes.
The change requests (CRs) coming from <CLIENT> are discussed first in the
business CAB, consisting of <VENDOR> service manager and representatives
of <CLIENT>. In this CAB, the CRs are approved for further analysis by the
technical CAB. The outcome of the business CAB is a prioritized short list of CRs.
The business CAB convenes on ad hoc basis when service manager has collected
enough CRs to organize the meeting. However, <CLIENT> is entitled to request a
business CAB twice per quarter.
The technical CAB convenes every week regarding the CRs approved by the business
CAB and the CRs coming from <VENDOR>. The purpose of this CAB is to approve
or reject CRs on technical grounds, and to assign approved CRs for release.
<VENDOR> service manager tracks all CRs received from <CLIENT> on a
tracking page. Once the tracking page has been updated with a new CR, service
manager informs the requestor via email. This happens within two working days
after the request has been made.
The business CAB is organized by the service manager. The service manager also
is the main person responsible for logging approved CRs, resulting in adding those
CRs to the agenda of the technical CAB. In the event of rejection of a CR from the
technical CAB, the service manager will provide feedback to <CLIENT>.
<VENDOR> change manager keeps <CLIENT> informed within one week after
the technical CAB about all changes that are approved and the release to which they
are assigned.
3. Service Level Management
This section describes how the agreed-on service levels will be managed. It defines
the KPIs for the services:
• What will be measured
• How these measurements will be performed
• The agreed-on service level targets
3.1 KPIs
3.1.1 Modules and Platforms
Availability of the Systems

Objective End users should have access to the system at all times. Availability of the system is
the main measurement for this KPI.
Calculation Specialized tools are used to check availability. These tools check the system via a
method simple access-check. If the system is not accessible for a continuous 60 seconds, the
system is considered unavailable.
All of these metrics produce a result, being either available or unavailable.
Calculation:
∑ [(Actual Uptime + Excusable Downtime)/Scheduled Hours]
= (100)
∑ All metrics
Planned maintenance should be excluded from the calculation.

Frequency Monthly
Source of Specialized monitoring tools
information
Target 98 percent

3.1.2 Incident Management
Incident Prevention
Objective System stability is important to maintain availability. The following calculation
measures the number of incidents addressed within a given time.
Calculation = ∑ High incidents
method = ∑ Medium incidents
= ∑ Low incidents
Frequency Every two weeks
Source of Monitor reporting
information
Target High incidents: <1
Medium incidents: <5
Low incidents: <20
Incident Resolution Time

Objective System stability is important to maintain availability. The following calculation
measures the time needed to address incidents within a given time.
Calculation ∑ High incidents restored within two hours
= (100)
method ∑ High incidents
∑ Medium incidents restored within 24 hours

= (100)
∑ Medium incidents
∑ Low incidents restored within 240 hours

= (100)
∑ Low incidents
Frequency Every two months
Source of Reports from ticketing software, including the time stamps from opening to closing a
information ticket.
Target High incidents: 95 percent
Medium incidents: 97 percent
Low incidents: 99 percent
3.1.3 Change Management
Response Time to Change Requests

Objective This KPI measures how responsive the business is when new changes are requested.
Calculation ∑ Confirmation of logging CR on WIKI page within two days after receipt
= (100)
method ∑ CRs requested by PO
Frequency Every two weeks
Source of Automatic mail generation
information
Target 98 percent

Change Advisory Board Reporting

Objective <CLIENT> should be aware of changes requested and approved to plan how to
minimize the impact of changes moving to production. This metric measures the
quality of the change/communication process.
Calculation ∑ Technical CAB reports delivered to <CLIENT> within five days after approval
= (100)
method ∑ Technical CAB meetings
Frequency Quarterly
Source of Mail when client receives technical report
information
Target 100 percent
3.1.4 Release Management
User Preparation for Release

Objective User awareness about upcoming changes is essential to any business. This KPI
measures the quality of the change/communication process to notify users about
changes before they are implemented.
Calculation ∑ Documentation and training provided at least Z weeks before release
= (100)
method ∑ Releases
Frequency Quarterly
Source of Updated WIKI
information
Target 100 percent
Release Communication
Objective The business shall always be adequately and timely informed about the planning
and implementation of changes. This KPI measures how well the business is being
informed.
Calculation ∑ Release date confirmations at least three weeks before release
= (100)
method ∑ Releases
Frequency Every three months
Source of Formal communications to the <CLIENT> to notify that a release will be implemented
information
Target 100 percent

3.2 Reports
<VENDOR> provides an electronic monthly report on the KPI performance. This

way, <CLIENT> has the opportunity to review and verify the fulfillment of the KPIs.
Content of the KPI report will be comprised of:

1. KPI performance, as described in section 3.1
2. Description of the remedial actions taken or planned on missed KPIs
3. Remediation actions to avoid reoccurrence of user impact
4. All escalations taken and a clear overview of the current status of these escalations
very quarter a steering dashboard is delivered by <VENDOR> that shows the

E
performance levels of the last 12 months.
3.3 Governance Structure
3.3.1 Escalation Procedure
Customer Customer Problem logged

discovers contacts Help and ownership
problem. Desk. assigned.
Level one Problem owner

technician Resolution at Yes verifies customer
attenpts to solve level one? satisfaction.
problem.
Problem record
marked closed.

If no resolution has been found at level one, the following procedure applies.
Level two technician

Provide customer Problem passed to level
attempts to solve
with tracking number. two technician.
the problem.
Change management/ Update record/notify

Resolution at recording of new
Yes problem owner of
level two? solution in database. solution.
Problem owner
Problem record
verifies customer
marked closed.
satisfaction.
If no resolution has been found at level two, the following procedure applies.
Level three technician

Problem passed to level Resolution at
attempts to solve
three technician. level three?
the problem.
Yes
Change management/ Update record/notify Problem owner

recording of new problem owner of verifies customer
solution in database. solution. satisfaction.
Problem record
marked closed.

3.3.2 Service Level Reviews
Operational service • Monthly report presented by service manager

level review • “On-target” service with a red-amber-green scheme
• Green results are not discussed.
• Log of action points plus follow-up
• Minutes prepared by <VENDOR> and circulated within
one week after meeting
Steering review • Quarterly
• Steering dashboard discussed between leadership of
<VENDOR> and project owner
• Long action plans are formulated based on trends in the
dashboard.
• Minutes of the meeting prepared by <VENDOR> and
circulated within one week after meeting
4. Glossary
Term Description
Change The addition, modification or removal of anything that could have an
effect on IT services
Change request (CR) A request to change something on the application (e.g., new features)
Incident An unplanned interruption of the IT service or a reduction in the
quality of an IT service
Key performance A quantifiable measure to compare the actual performance against
indicator (KPI) the agreed-on levels
Mean time to repair The average time to fix an incident or problem
(MTTR)
Problem The underlying cause of incidents
Release A set of changes that will be implemented simultaneously
Service level The formal definition of the services offered
agreement (SLA)
User acceptance Test conducted by end users of the system to determine whether the
training (UAT) requirements are met.
Working hours From Monday to Friday, between 09:00 and 17:00, except on
official holidays

Appendix J. SLA Deployment and Maintenance of Digital Copiers 149
Appendix J. SLA Deployment and

Maintenance of Digital Copiers

for
Deployment and Maintenance of Digital Copiers
between
<VENDOR>
and
<CLIENT>
Table of Contents

1.1 Purpose
1.2 Scope
1.2.1 Services and Requests Covered Under This Agreement
1.2.2 Changes to SLA
1.2.3 Processes and Procedures
1.2.4 Metrics
1.2.5 General Terms and Conditions
Appendix 1. Definitions
Appendix 2. Roles and Responsibilities

1.1 Purpose
The purpose of this service level agreement (SLA) is to formalize an arrangement
between <CLIENT> and <VENDOR> to deliver equipment and support services, at
specific levels of support, and at an agreed-on cost.
This SLA contains a description of how delivery of the services will be

measured, including:
• KPIs that will be measured
• When they will be measured
• Who is responsible for measuring the KPIs
• Any exceptions to the normal service level requirements
• Any dependencies which may compromise the delivery of the service
This SLA will evolve over time, with additional knowledge of the client requirements
as well as the introduction of new devices and services into the support portfolio
provided by <VENDOR>.
1.2 Scope
The following states the equipment and services provisioned by <VENDOR>
to <CLIENT>.
1.2.1 Services and Requests Covered Under This Agreement

The following services are provided by <VENDOR> to <CLIENT>:
• Deployment and maintenance of digital copiers—This includes equipment,
maintenance, parts, travel, toner, and all consumable supplies except paper
and staples. Prices for the devices will be set according to the average monthly
printing volumes per device.
Preventive maintenance shall be performed as prescribed by the manufacturer of

the devices. This also includes a greater frequency if, due to large usage of the
devices, this is deemed necessary.
The guaranteed in-person service response time for detective maintenance,

following any service call, shall be four business hours or less, normal business
hours (09:00 to 17:00, Monday through Friday). The response time:
– Begins when the request is logged with <VENDOR> problem-ticketing system
– Stops when the request is logged as solved by the technician
• Service availability—The guaranteed in-person response time following any
service call is four business hours or less. If <VENDOR> is unable to respond to
any service call within four hours from the time the call was placed, <VENDOR>
shall provide copies, on that device, at no charge for the following month, and all
penalties related to replacement and further meter cost reductions apply to any
device that falls below 98 percent uptime for any twenty-day work period.

The minimum acceptable level of uptime for any device shall be 98 percent as
determined by the following formula: Uptime = [(Total Time – Lost Time)/Total
Time] (100).1, 2
The following table shall be applied in case of exceptions noted.
Uptime
Level Response
During any 20-day work period:
98-90% Charge to <CLIENT> shall be reduced or credited by 20% on that device.
89-80% Charge to <CLIENT> shall be reduced or credited by 30% on that device.
<79% No monthly payment shall be charged to <CLIENT> on that device.
During 3 consecutive 20-work day periods:
<98% <VENDOR> will replace the device with an equivalent device for the remaining term of
the contract at no additional cost to <CLIENT>.
Furthermore, responses are also expected as shown in the following table.
Exception Response
Technician cannot repair <VENDOR> shall provide or loan a multifunctional printer equal to the
a machine fault within existing model. <VENDOR> shall ensure that the loaned device connects
one business day to the network and prints with existing drivers and controllers. This loaned
device shall be provided at no additional cost to <CLIENT>, including no
additional meter costs and no additional delivery costs, until the existing
device is fully operational and functioning in the intended manner.
More than four service A service manager shall evaluate the performance of the device and fully
calls for the same fault correct all problems with the device. If that device then requires a further
in any quarter period service call for the same fault within the next 90 days, <VENDOR>
will remove the device and loan the department a similar or equivalent
model until the problem device is repaired and tested at <VENDOR>
service facility.
• Equipment moves—All equipment moves/relocations shall be at no charge. This

includes off-site storage if required, removal, reinstallation, testing and training.
• “Extra support” hours—All requests for support during non-business hours shall
be considered to be extra support. Extra support will be provided free-of-charge if
<VENDOR> is notified 24 hours in advance of the request for extra support.
1
Total Time = Available time for 09:00 to 17:00 hrs for 10 days (8 hrs × 10 days = 180)
2
Lost Time = Lost time in hours. The total elapsed time, within an eight-hour day, between 09:00 and
17:00, Monday through Friday (excluding public holidays), that the equipment is unable to produce
copies or other primary functions in accordance with the specification for reasons attributable to
equipment failure or withdrawal of equipment for remedial maintenance repair or testing. Lost Time
shall commence upon notification by the <CLIENT> to < VENDOR>-specified service dispatch of a
fault condition which prevents full utilization of the equipment and shall end when the equipment is
powered up and ready to execute <CLIENT> work, and the fault call has been logged as complete by
the service technician.
• Accessory support—<VENDOR> support staff shall be available after

<MANUFACTURER> support of networking devices to assist <CLIENT> staff.
This includes conducting site surveys and proposing devices or deployment
strategies.
• Training—On-site training shall be provided to applicable users for each piece of
equipment. The selected users shall be trained for each device and shall include
functionality and usage, features and a “how-to” initiate service calls.
• Install base management—All removal, addition or modification of devices shall
be at the same cost rates. Removal of devices may not exceed five percent of the
installed base per year.
• Change management—New or changed processes, practices or policies that
affect <CLIENT> support and that have an impact on the fleet shall be presented
to <CLIENT> to understand, learn and follow up. All changes shall be coordinated
with <CLIENT>.
• Upgrades—Upgrades include operating system upgrades, device upgrades,
software upgrades, and manufacturer-required upgrades. The upgrades shall be
coordinated with the preventive maintenance service calls or coordinated with
<CLIENT> to reduce downtime.
• Status reports—Full status reports will be presented every two months to
encompass all service activity per device. Reporting content shall be responsive to
<CLIENT> requirements.
• Credits—Unusable copies shall be credited back to <CLIENT> at the rate of
$00.011 USD per copy/print. Unusable copies are the result of a malfunctioning
device that requires a service call and not user error.
• Replacement policy—Whenever it is not possible to repair a device on site, a
replacement device of equal capability shall be introduced to decrease downtime.
If a device is unrepairable, an equal replacement or a device with bigger
capacity will be provided for the remaining term of the agreement. A temporary
replacement will be provided if a device is down for more than two business days.
1.2.2 Changes to SLA

• Termination of agreement—<CLIENT> may terminate this agreement without
penalty if <VENDOR> repeatedly violates the terms of this agreement. In such an
event, < CLIENT> shall give <VENDOR> 30 days written notice of intent
to terminate.
• Non-appropriation—<CLIENT> will make every effort to ensure a continuation
of funding for the period of this contract. Should insufficient funds be
appropriated and budgeted in any fiscal year for payments due under this contract,
<CLIENT> is obligated to immediately notify <VENDOR>. This shall create
no further financial obligation of <CLIENT>. If and when these kinds of events
occur, the contractual service will be terminated without penalty or expense to
<CLIENT> of any kind whatsoever.

• Amendment to agreement—Any amendment to the terms and conditions of this

agreement requires the approval of <VENDOR> and < CLIENT>. Amendment
of the agreement takes place through an addendum to this agreement and the
recording of that addendum in an Appendix to this agreement.
There will be an opportunity on a quarterly basis to make adjustments to this

SLA. <VENDOR> and <CLIENT> should work together to make changes at
that time.
• New applications or devices—New applications and versions implemented
during the term of this agreement will move into <VENDOR> support model
through <VENDOR> process. <VENDOR> will be responsible for initiating
and ensuring completion of the appropriate process. Changes to the inventory
of applications supported will be reviewed on a regular basis, and if need be,
changes to the SLA will follow the process described in the previous section on
Amendment to Agreement.
1.2.3 Processes and Procedures

• Problem-ticket system—<VENDOR> problem-ticket system will be used by
all support team levels to record and track all problem reports, inquiries or other
types of calls received by support. This provides <VENDOR> with the ability to
provide metrics with regard to this SLA.
• Billing of services—Direct billing to <CLIENT> under the terms and conditions
of the appropriate purchase order will be the standard for the billing of services. A
detailed invoice, including all average costs per device, will be provided prior or at
the same time of billing.
1.2.4 Metrics
• Metrics reporting—Regular reporting will be provided monthly by <VENDOR>
to <CLIENT> on available metrics as related to target performance. These reports
are expected to be produced by <VENDOR> problem-ticket system, which will
detail ticket management performance against SLA targets in <VENDOR> case
management process. Two categories of metrics are of the utmost importance:
(1) the availability of the device, and (2) the availability of the system.

Availability of the Devices

Objective End users must be able to use the devices at all times during operations
hours.
Calculation method Availability is checked using specialized tools that access the systems to verify
availability. If the system is not reachable for a continuous 240 seconds, the
All of these measurements produce a result, being either available or

unavailable.
Calculation:
= (100)
∑ All metrics
For the calculation, measurements during announced maintenance are

excluded.
Frequency Hourly
Source of End-to-end monitoring tools
information
Target 98 percent
Unscheduled Must not exceed one percent of the time
outages
Scheduled Every three months
maintenance
Availability of the Systems

Objective For the services to be used, the end users should be able to access the
system all of the time. This KPI measures the availability of the system.
Calculation method Availability is checked using special tools that access the systems to verify
availability. If the system is not reachable for a continuous 120 seconds, the
All of these measurements produce a result, being either available or

unavailable.
Calculation:
= (100)
∑ All metrics
Announced maintenance activities are excluded in calculation.

Frequency Every three hours
Source of End-to-end monitoring tools
information
Target 98 percent

1.2.5 General Terms and Conditions

• Term of agreement—This agreement is in effect on the date of acceptance of this
agreement and ends on the latest date specified in any terms of the work statement
submitted by <VENDOR> and agreed to by <CLIENT>.
• Organizations—This agreement is between <CLIENT> and <VENDOR>,
as named on the cover of this agreement.
• Approvals—To make these agreement operational, approvals according to
Appendix 2 of the work statement must be in place.
• Key contacts—Key contacts are shown in the work statement.
Appendix 1. Definitions
Levels of support—Two levels of support are included in this SLA. These levels
are integrated with <VENDOR> support processes and are defined as standard
coverage and extra coverage.
These support levels represent generalist support. If the Help Desk is unable to
solve the issue, the ticket is escalated to <VENDOR> Level 2 support.
The Help Desk will take care of support requests as shown in the following table.
Telephone
Help Desk Hours Contact
Standard coverage 09:00 to 17:00, Monday through Friday TBD
Extra coverage 17:00 to 09:00, seven days a week TBD
During critical processing periods, support is extended to extra support. This must
be requested by <CLIENT> contacting <VENDOR>. <CLIENT> shall notify
<VENDOR> 24 hours in advance by phone or email.
Support request—Any request regarding the fixing of a defect or problems with

the functionality of the stated devices
Work order—Any request that involves changing or adding functionality on an

existing system. These kinds of requests are only covered in this agreement if they
are less than four days of effort.

Appendix 2. Roles and Responsibilities
Role Responsibilities
<VENDOR> • <VENDOR> will conduct business in a courteous and professional manner
with <CLIENT>.
• <VENDOR> will use its own appropriate Help Desk to provide Level 1 support,
including creating problem tickets and work orders and assigning responsibility to the
appropriate Level 2 resource.
• <VENDOR> will use its own appropriate internal group to provide Level 2 server,
network and infrastructure support services.
• <VENDOR> will obtain <CLIENT> approval before ticket closure.
• Once a support request has been submitted, <CLIENT> will make itself available to
work with <VENDOR> support resource assigned to the support request.
• <VENDOR> will attempt to resolve problems over the telephone on first call.
• <VENDOR> will log all information from <CLIENT> required to establish contact
information, document the nature of the problem and <CLIENT>
hardware/network environment (as applicable).
<CLIENT> • <CLIENT> will conduct business in a courteous and professional manner with
<VENDOR>.
• <CLIENT> will provide all information required to open a support request.
• <CLIENT> end users will not contact <VENDOR> support resources directly to report
a problem. All problem calls must be logged through the appropriate Help Desk.
Program • Liaise between <CLIENT> and <VENDOR> team and project managers.
manager • Liaise with <CLIENT> user departments.
<CLIENT> • Ensure that all required documentation, information and knowledge items have been
prepared according to the transition checklist and turned over prior to the start of
support for a new application.
• Identify resource requirements.
• Identify all access requirements.
• Meet with <VENDOR> team to set up timeline and develop
transition/deployment plans.
• Ensure that SLA targets are met (coordinating all activities to ensure that all tasks are
performed in a consistent manner and on schedule).
• Ensure that all work is performed according to the agreed-on work methods and
standards that are in effect within <CLIENT> and <VENDOR>.
• Act as point of escalation for issues beyond usual scope.
Infrastructure • Liaise with other organization groups.
support • A ssess the workload for each support request and assign work to the team member
manager having the appropriate technical knowledge.
<VENDOR> • Assist in conducting all root-cause analysis and bug-fix isolation and resolution
activities, and associated documentation for the individual tasks, as assigned by
<CLIENT> program manager.
• Act as a point of contact for all issues for <CLIENT> infrastructure.
• Determine (for enhancements) the potential high-level effort for all changes.
• Identify all tasks associated with each support request and derive estimates for the
completion of each task for organization staff and resources.
• Conduct and participate in testing as needed.
• Provide knowledge transfer to key organization support specialists on a regular basis.

Appendix K. Example SLA for Back Office and LAN Services 157
Appendix K. Example SLA Back Office

Services

for
Back Office Services
between
<VENDOR>
and
<CLIENT>
Table of Contents
1. Introduction
2. Metrics and Validation of Service Levels
3. Reporting
4. Service Level Review
5. Service Levels for New Service or Additional Services
6. Method of Measurement
6.1 Classification of Values
6.2 Excusable Downtime
7. Attachment 1: Service Level Measurements

1. Introduction
This agreement describes <VENDOR> duties, obligations and responsibilities

related to the service levels for defined back office services and certain <CLIENT>
responsibilities. An additional document is provided to describe specific service
level metrics (SLM) that <VENDOR>will provide to <CLIENT> as part of
this agreement.
2. Metrics and Validation of Service Levels
<VENDOR> service performance is to be measured as follows:

• <CLIENT> and <VENDOR> have concluded that historical data are insufficient
to set the service level target on that basis.
• <CLIENT> and <VENDOR> agree on using a specific target as specified in
Attachment 1 of this schedule.
After the transition period end date, the measurement period follows. The
measurement period takes three calendar months, during which time
<VENDOR> will:
• Use standard measurement tools to monitor and report the performance levels
for the services. If during the measurement period the parties detect a particular
service level that cannot reach the target specified in this schedule, <VENDOR>
and <CLIENT> will agree to review the required conditions and time frames for
achieving this particular SLM expected value1.
• Submit to <CLIENT> a standard report by country or set of standard reports
assessing <VENDOR> performance during the previous calendar month against
the levels of service specified in the tables set forth in Attachment 1 to
this schedule.
• Define and communicate the method of measurement for the service levels.
Upon completion of the measurement period:

• <VENDOR> will update the tables set forth in Attachment 1 of this schedule
to reflect the mutually agreed-on service levels and service level measurement
criteria, and will provide an amended copy of this schedule to <CLIENT>.
• <VENDOR> will meet or exceed the service levels, as set forth in this schedule.
• If applicable, to validate that the service levels accurately reflect <CLIENT> business
operations seasonality, <CLIENT> and <VENDOR> agree to track the performance
attainment for each of the defined services for the six months following the
measurement period and adjust the service levels for each of the defined services based
on the combined performance attainment for both periods.
1
he SLM expected value is the value that <CLIENT> and <VENDOR> agree should be achieved by
T
<VENDOR> during the execution of the service.

3. Reporting
By the tenth day after the first full calendar month following the establishment of
the service levels pursuant to section 2 (measurement and validation of service
levels) and monthly thereafter, <VENDOR>will submit to <CLIENT> a standard
report or set of standard reports assessing <VENDOR> performance during the
previous calendar month against the service levels.
<VENDOR> also will be responsible for promptly investigating failures to meet the
service levels by:
• Initiating problem investigations to identify root causes of failures related to not
achieving the service levels
• Promptly reporting problems related to the services, as identified, to <CLIENT>
that reasonably could be expected to have a material adverse effect on
<CLIENT> operations
• Making written recommendations to <CLIENT> for improvement in procedures
related to the services
<VENDOR> will identify root causes, correct problems and make reasonable
technical efforts to minimize recurrences of missed service levels for which the
<VENDOR> or its suppliers are the only responsible parties. <CLIENT> agrees
to correct problems and attempt to minimize the recurrence of problems for
which <CLIENT> or its suppliers are the only responsible parties and that prevent
<VENDOR> from meeting the service levels.
<VENDOR> will notify <CLIENT> of problems caused by the actions or inactions

of <CLIENT> or its affiliates, third-party suppliers, clients or <CLIENT>
prioritization of available resources. In such cases, if <CLIENT> agrees on the
problem causes, <VENDOR> will be relieved of responsibility for meeting affected
service levels for the period affected and until the problem has been solved.
4. Service Level Review
<CLIENT> and <VENDOR> will review the service levels at least once per year
and mutually agree whether to:
• Add to, delete or change the services to be measured, the corresponding service
levels and their measurement methodology to reflect changes in <CLIENT>
business operations.
• Improve the existing service levels, where warranted, to reflect operational or
technical improvements.

5. Service Levels for New Service or Additional Services
With respect to new services or additional services, <VENDOR> and <CLIENT>

will establish initial service levels following full implementation of such services
which will apply during the initial 90-day period of <VENDOR> providing such
new services or additional services.
During these 90 days, <VENDOR> and <CLIENT> will conduct the process set
forth in section 2 of this schedule (measurement and validation of service levels) to
validate the initial service levels and agree on the actual service levels, if applicable,
for such new services or additional services.
6. Method of Measurement
The service level agreement (SLA) will be composed of a series of SLMs. The
parties agree that the result of the SLMs will constitute the only way to measure the
quality of the services being given by <VENDOR> to <CLIENT>.
<CLIENT> and <VENDOR> agree that although this agreement refers to numerous
specific services which <VENDOR> is required to provide, only the SLA and SLM,
defined as follows, will be used to reflect the overall and complete quality evaluation of
<VENDOR> execution and performance of its responsibilities.
Term Definition
SLM alarm trigger A value that, if achieved by an SLM, indicates a reduction in the quality of the
(SLMAT) services that <VENDOR> is providing to <CLIENT>
SLM expected value The value that <CLIENT> and <VENDOR> agree should be achieved by
(SLMEV) <VENDOR> during the execution of the service
SLM measurement The period of time that will be used to collect and aggregate the data and
period report the SLM
SLM method of The mathematic or algorithmic transformation to be performed on the data
calculation collected to produce the SLM
SLM method of The method or mechanism that will be used to collect the data to be used to
measurement calculate the SLM
SLM metric A literal name for the SLM
SLM number An identifier that will be used to uniquely identify each SLM
SLM objective A description of the objective of the measurement
SLM tolerance range The percentage of the SLM expected value indicating the variation or error that
(SLMTR) a particular SLM measurement can have with respect to the SLM expected
value, without affecting the quality of the services that <VENDOR> is providing
to <CLIENT>.
SLM unit of measure The unit of the SLM expected value and SLM alarm trigger. If the expected
value is dimensionless, for example a percentage, it will be indicated as not
available (N/A).
SLM value (SLMV) The value that results from collecting data using the SLM method of
measurement during the SLM measurement period, and applying the SLM
method of calculation. SLMV will be calculated monthly.

<VENDOR> will take the measurements or perform the data collection activities
that are required to calculate the SLM, based on tools such as the call management
database of the Help Desk and the availability of the services to end users. Further,
<VENDOR> will produce the SLM value as defined by the SLM measurement
period, and using the SLM method of calculation defined for each SLM. This
calculation is the one that will be reported to <CLIENT>.
6.1 Classification of Values

Once an SLM value has been calculated for a measurement period, it will be
classified as follows.
For SLMs where a value toward positive infinity represents a better service:
BLUE GREEN
SLA exceeded SLA accomplished
SLMV ≥ (SLMEV + SLMTR) (SLMEV − SLMTR) ≥ SLMV <
The SLM value is greater than or equal to (SLMEV + SLMTR)
the SLM expected value plus the SLM The SLM value is greater than or equal to
tolerance range. the SLM expected value minus the SLM
tolerance range, and less than the SLM
expected value plus the SLM tolerance range.
YELLOW RED
SLA almost accomplished SLA not accomplished
(SLMEV − SLMAT) ≥ SLMV < SLMV < (SLMEV − SLMAT)
(SLMEV − SLMTR) The SLM value is less than the SLM
The SLM value is greater than or equal to expected value minus the SLM
the SLM expected value minus the SLM alarm trigger.
alarm trigger, and less than the SLM
expected value minus the tolerance.
For SLMs where a value toward zero or negative infinity represents a better service:
BLUE GREEN
SLA exceeded SLA accomplished
SLMV ≤ (SLMEV + SLMTR) (SLMEV − SLMTR) ≤ SLMV <
The SLM value is less than or equal to the (SLMEV + SLMTR)
SLM expected value plus the SLM The SLM value is greater than or equal to
tolerance range. the SLM expected value minus the SLM
tolerance range, and less than the SLM
expected value plus the SLM tolerance range.
YELLOW RED
SLA almost accomplished SLA not accomplished
(SLMEV + SLMTR) < SLMV ≤ SLMV > (SLMEV + SLMAT)
(SLMEV − SLMV) The SLM value is greater than the SLM
The SLM value is greater than the SLM expected value plus the SLM alarm trigger.
expected value plus the SLM tolerance range,
and less than or equal to the SLM expected
value minus the SLM value.
During the week following the monthly review meeting, <VENDOR> will present a
detailed action plan for any SLM whose value has fallen within the YELLOW or RED
area to restore the SLM to the GREEN or BLUE area.
6.2 Excusable Downtime

Excusable downtime is defined as the period when the following situations occur,
from detection to resolution:
• <VENDOR> shall be relieved of any service level measure not compliant to the
extent that <VENDOR> failure is due to the <CLIENT> failure to perform any
obligation under this agreement.
• <VENDOR> shall be relieved of any service level measure not compliant if
the <VENDOR> or third parties performing work for <VENDOR> fail to
perform any obligation under this agreement, including responsibilities for
retained hardware and software, considering that the situation is informed by the
<VENDOR> in a timely manner and approved by <CLIENT>.
• <VENDOR> shall be relieved of any service level measure not compliant if
the <CLIENT> or third parties performing work for the <CLIENT> spend
excessive time on approvals (SLM measuring will be paused until <CLIENT>
communicates approval to <VENDOR>).
• Problems identified by <CLIENT> or <VENDOR>, and that cannot be solved by
<VENDOR>, due to <CLIENT> retained software and hardware in back-level
version and/or unsupported by its provider
• Problems with <CLIENT> retained software and hardware in performing
their function
• Jointly agreed and previously scheduled technical maintenance windows
• Changes in the environment caused by <CLIENT> or third parties under
<CLIENT> responsibility and not communicated to the <VENDOR>
• Problems caused by malicious software not attributed to <VENDOR> negligence
in performing the services
Calculated SLMs will be reported to <CLIENT> as set forth in section 3.0

on Reporting.
During the transition period, the <VENDOR>, with the assistance of the
<CLIENT>, will make reasonable technical efforts to minimize impact to current
service levels, even if no measurement methodology has been established yet.

7. Attachment 1: Service Level Measurements
IT Outsourcing (ITO) Services

Scheduled Server SLMEV SLMTR SLMAT
Category Facilities Hrs ID† (%) (%) (%)
Critical server availability Campus 24/7 TBD 97.5 0.1 1.0
(RISC servers) Non-campus* Business TBD 97.0 0.2 2.0
Non-campus* Non-business TBD 96.0 0.2 2.0
Proxy servers Campus 24/7 TBD 97.0 0.1 0.5
Non-campus* Business TBD 97.0 0.2 2.0
Critical services Campus 24/7 TBD 98.0 0.1 0.5
availability: Non-campus* Business TBD 97.0 0.2 2.0
– Domain Name System
(DNS) running on Non-campus* Non-business TBD 96.0 0.2 2.0
RISC machines
– Dynamic Host
Configuration
Protocol (DHCP)
– Relational Database
Management
System (RDBMS)
– VS Gateways
(remote access)
– Hypertext Transfer
Protocol (HTTP) server
Email availability Campus 24/7 TBD 98.0 0.1 0.5
Other server availability Campus 24/7 TBD 98.5 0.1 1.0
Remote access Campus 24/7 TBD 98.5 0.1 0.5
availability Non-campus* Business TBD 98.0 0.2 0.5
Managed firewall Campus 24/7 TBD 98.0 0.1 1.0
availability§
TBD = To be determined
* Subject to IT infrastructure as set forth in Master Agreement
† The server ID is an identification associated with each server included in this agreement and will be completed during
wall-to-wall inventory and site survey in the transition period and will be updated as required during the term.
§ This SLMEV only applies to <CLIENT> site.
Business hrs: as established in Master Agreement
Server availability SLA calculations (for critical servers, notes servers and other servers):
[(Actual Uptime + Excusable Downtime)/Scheduled Hours] (100)
Managed firewall availability service level calculations:
Managed Firewall Availability = [(Actual Uptime + Excusable Downtime)/Scheduled Hours] (100)
Note: Excusable downtime will be subtracted from SLMV.

ITO Services for Restoring Files

SLMEV SLMTR SLMAT
Category (hrs) (%) (%)
File restore last version <2 GB 8 3.0 4.0
File restore last version >2 GB 20 3.0 4.0
Central notes recovery time (notes hub at <VENDOR> 20 0.5 2.0
data center)
File restore SLA calculations: File Restore = [(restore end time – restore start time) × file size]/file size
Central notes recovery time SLA calculations: Recovery time = max (uptime – downtime)
ITO Service Requests

SLMTR SLMAT
Category SLMEV (%) (%)
User administration Normal: 2.0 4.0
(creation/deletion) 96.0% within 12 business hrs
— file/print 99.0% within 24 business hrs*
servers, notes†
Urgent (business reasons; less than 8% of 2.0 4.0
total requests):
96.0% within 12 business hrs
99.0% within 24 business hrs*
Critical (security issues; less than 2% of 2.0 4.0
total yearly requests):
Notes: database Normal: 2.0 4.0
deployment† 96.0% within 12 business hrs
total requests):

ITO Service Requests (cont.)

SLMTR SLMAT
Notes: ACL Normal: 2.0 4.0
configuration† 96.0% within 12 business hrs
total requests):
*For those ITO requests not completed in time, <VENDOR> will provide to <CLIENT> an action plan to complete them in a
timely manner. This procedure will be defined in the procedure manual.
†This SLMEV will be measured from the trouble ticket registration at <VENDOR> Help Desk at <VENDOR> data center.

Help Desk Services

SLMTR SLMAT
Speed to answer 80% answered in <30 seconds 0 2.0
Abandon rate <8%* 0 2.0
First call resolution 75% 1.0 2.0
Availability of service support 99.5% 0 0.1
* Abandon calls with a user time frame lower than 30 seconds from an option menu was selected; will not apply for
this SLMEV.
Speed to answer SLA calculation:
(number of calls answered in <30 seconds/number of calls received) (100)
Abandon rate SLA calculation:
(number of calls in which user abandons call after entry into agent queue/number of calls for which end user enters the
queue for access to an agent) (100)
First call resolution SLA calculation:
(number of in-criteria tickets closed during the first call, for each country/number of tickets received, from end users of each
country, in-criteria of possible resolution) (100)
Availability of service support calculation:
[(Actual Uptime + Excusable Downtime)/Scheduled Hours] (100)
<VENDOR> has assumed that the average quantity of minutes of call service time for each call will be six minutes. In case
the average call received at Help Desk is greater than the call service time assumption for a period of three consecutive
months, <VENDOR> will review jointly with <CLIENT> the Help Desk services.
PDS Deskside Software Support and Software Installations Services

SLMTR SLMAT
Category SLMEV* (%) (%)
Deskside software support services 95.0% within 12 business hrs 1.0% 2.5%
completion—campus site
Deskside software support services 90% within 24 business hrs 1.0% 3%
Completion—non-campus site
On site software installations— 90% within 32 business hrs 1.0% 2.5%
campus site 99.5% within 64 business hrs†
On site software installations— 90% within 40 business hrs 1.0%
non-campus site 99.5% within 80 business hrs†
(i) *Excusable downtime will be subtracted from SLMV.
(ii) †For these PDS deskside software support and software installations services not completed in time, <VENDOR> will
provide to <CLIENT> an action plan to complete them in a timely manner. This procedure will be defined in the
procedure manual.
Deskside software support services calculations:
(number of times service completed within allotted time/number of in-criteria requests for service) (100)
Onsite software installations services calculations:

PDS Hardware Maintenance Services

(for machines provided by <VENDOR> refresh program)
SLMTR SLMAT
Hardware maintenance services 95.0% within 12 business hrs 0.5 3
completion—campus site
Hardware maintenance services 90% within 24 business hrs 1.0 4
completion—non-campus site
Refresh new machine (on scheduled 95% new machine deployment on 1.0 3
time) scheduled time
99.5% new machine deployment

with no more than three business
day of delay†
* Excusable downtime will be subtracted from SLMV.
† F or these PDS hardware maintenance services not completed in time, <VENDOR> will provide to <CLIENT> an action plan
to complete them in a timely manner. This procedure will be defined in the procedure manual.
Hardware maintenance services completion SLA calculations (for campus and non-campus):
Refresh new machine SLA calculation:
(number of times service completed within allotted time/number scheduled requests) (100)
PDS IMAC Services

SLMTR SLMAT
IMAC management services 90% by end of 16 business hrs 0.5 3.0
completion time 99.5% by end of 32 business hrs†
IMAC performance services 90% by end of 32 business hrs 0.5 2.5
completion time—campus 99.5% by end of 64 business hrs†
IMAC performance services 90% by end of 40 business hrs 0.5 3.0
completion time non-campus 99.5% by end of 80 business hrs†
* Excusable downtime will be subtracted from SLMV.
†For these PDS IMAC services not completed in time, <VENDOR> will provide to <CLIENT> an action plan to complete them
in a timely manner. This procedure will be defined in the procedure manual.
IMAC management services completion time calculation:
(time to schedule requested IMAC as measured from time ticket is opened until IMAC is scheduled)
(number of IMAC management services performed within two business days/number of IMAC management services requests
received) (100)
IMAC performance services completion time calculations:
(number of IMAC performance services completed within applicable time period/number of IMAC performance services
requests received) (100)
Notes:
1. S LA attainment for IMAC performance services will be measured from the time all required IMAC components are
available at the facility where the IMAC will be performed and all IMAC prerequisites and site modifications (including
telecommunications) are complete.
2. The following will not be counted when calculating <VENDOR> SLA attainment for IMAC services:
(a) An IMAC that is delayed at <CLIENT> request
(b) IMAC activity that is performed outside of the established IMAC process (i.e., unauthorized and undocumented)
(c) IMACs performed as a project

Communication Services
SLMEV SLMTR SLMAT
Category* (%) (%) (%)
LAN availability—campus sites 97.0 0.2 0.5
LAN availability—non-campus sites; business hrs 97.0 0.2 0.5
LAN availability—non-campus sites; non-business hrs 97.0 0.2 0.5
*Subject to IT infrastructure as set forth in Master Agreement
LAN availability service level calculations, per <CLIENT> facility:

LAN availability = [(actual uptime + excusable downtime)/scheduled hours] (100)
Communication Requests
SLMTR SLMAT
Access list configuration • Normal: 95% within 1.0 3.0
(IP restrictions) 24 business hrs
• Critical (problem resolution):
User administration • Normal: 95% within 1.0 2.0
(creation/deletion)—remote access 32 business hrs
• Urgent (business reasons; less
than 8% of total requests): 96%
within 6 business hrs
• Critical (security issues; less
than 2% of total requests): 97.5%
Proxy: URL filtering • Normal: 95% within 2.5 3.0
24 business hrs
• Critical (business reasons; less
Proxy user insertion or deletion • Normal: 95% within 0.5 3.0
32 business hrs
• Urgent (business reasons; less
than 10% of total requests): 9 6%
• Critical (security issues; less
Proxy: access report • Normal: 95% within 1.5 3
48 business hrs
• Critical (less than 2% of total
requests): 97.5% within
6 business hrs

Communication Requests (cont.)

Proxy additional rule set appliances: • Normal: 97.5% within 0.5 2.0
(a) Provide string-oriented access 32 business hrs
control to Internet: • Urgent (business reasons; less
1. Filter by keyword or key phrase. than 8% of total requests): 97.5%
2. Filter by file extension. within 12 business hrs
3. F ilter by multipurpose Internet • Critical (security issues; less
mail extensions (MIME)-type. than 2% of total requests): 97.5%
4. F ilter by platform for Internet within 6 business hrs
content selection (PICS) rules.
(b) Force user to have filtered Internet
access.
(c) Deny a user access to the Internet.
(d) Suspend Internet access for a
particular user, group of users,
standalone workstation or group of
workstations.
(e) Force a user to only have access to
specified web sites.
(f) Schedule by day and time what
access level users have to the
Internet.
(g) Schedule by day and time which
workstations can have access to
the Internet and with what rights.
(h) Restrict access to web, file transfer
protocol (FTP), Internet relay chat
(IRC), etc., by workstation.
LAN: cabling design • Up to 15 network access points: 0.5 4.0
90% within 5 business days
• From 16 to 50 network access
points: 85% within 12 business days
• More than 50 network access points:
new project
Monthly Report Services

SLMTR SLMAT
Standard reports provided to <CLIENT> • 95.0% by the 15th business day of 0 4
the month following month reported
• 99.0% by the 20th business day
of the month following month
reported*
*For the reports not sent on time, <VENDOR> will provide to <CLIENT> an action plan to send them
in a timely manner. This procedure will be defined in the procedure manual.
Standard report SLA calculation:

(number of standard reports delivered within scheduled time/total standard reports) (100)


Appendix L. High-level Mapping of COBIT 5 171
and ITIL V3 for Vendor Management
Appendix L. High-level Mapping of COBIT 5

and ITIL V3 for Vendor Management
Vendor Management COBIT 5 ITIL V3

• Chapter 2. Vendor • APO10 Manage suppliers. • Service Design. 4.8 Supplier
Management. Life cycle of • MEA01 Monitor, evaluate Management
contractual relationship and assess performance and • Service Strategy. 3.7 Sourcing
• Chapter 2. Vendor conformance. Strategy
Management. Stakeholder • Continual Service
responsibilities and Improvement, 4.1 The 7-Step
viewpoints Improvement Process
• Chapter 3. Threats and
risk related to vendor
management
• Chapter 4. Vendor
management risk mitigating
actions. Mitigating actions
through COBIT 5
• Chapter 5. Binding documents • APO09 Manage service • S ervice Strategy, 4.4 Demand
• Appendix F. SLA template agreements. Management
• MEA01 Monitor, evaluate • S ervice Strategy, 4.2 Service
and assess performance and Portfolio Management
conformance. • S ervice Design, 4.2 Service
Catalogue Management
• S ervice Design, 4.3 Service
Level Management
•C ontinual Service
Improvement, 4.1 The 7-Step
Improvement Process


Acronyms 173
Acronyms
Abbreviation Full Term
BaFO Best and final offer
BCM Business continuity management
CAPEX Capital expenditures—used to acquire or upgrade physical assets such as
buildings, infrastructure and equipment
CFI Call for interest
CFO Chief financial officer
CIO Chief information officer
CISO Chief information security officer
CSP Cloud service provider
DDoS Distributed denial of service
DRP Disaster recovery plan
IaaS Infrastructure as a Service
IAM Identity and access management
IDS/IPS Intrusion detection system/intrusion prevention system
ISM Information security manager
ISO International Organization for Standardization
KPI Key performance indicator
MAC Material adverse change
OLA Operating level agreement
OPEX Operating expenditures—ongoing cost for running a product, business or
organization
OS Operating system
PaaS Platform as a Service
Q&A Questions and answers
QoS Quality of service
RACI Responsible, accountable, consulted, informed
RFI Request of information
RFP Request for proposal
RFQ Request for quote
RPO Recovery point objective
RTO Recovery time objective
SaaS Software as a Service
SDLC Systems development life cycle

Abbreviation Full Term

SIEM Security incident and event manager
SLA Service level agreement
SMART Specific, measurable, attainable, realistic, timely
SPoC Single point of contact
SOA Service oriented architecture
SWOT Strengths, weaknesses, opportunities and threats
TCO Total cost of ownership
UC Underpinning contract
VM Virtual machine
VMO Vendor management office
VRM Vendor management manager

Glossary 175
Glossary
AICPA SOC 2—A report on controls at a service organization, relevant to security,
availability, processing integrity, confidentiality or privacy
Availability—Ensuring timely and reliable access to, and use of, information
Business process owner—The individual responsible for identifying process

requirements, approving process design and managing process performance
Scope note: Must be at an appropriately high level in the enterprise and have
authority to commit resources to process-specific risk management activities
Business professional—Any individual performing business activities. This term

may be used to denote any person working outside IT.
Business requirements—Description of what must be delivered to meet business

objectives and create value
Call for tender—Procedure for generating competing offers from different vendors
COBIT 5—A complete, internationally accepted framework for governing and

managing enterprise information and technology (IT) that supports enterprise
executives and management in their definition and achievement of business goals
and related IT goals. COBIT describes five principles and seven enablers that support
enterprises in the development, implementation, and continuous improvement and
monitoring of good IT-related governance and management practices.
Compliance requirements—Description of what must be delivered or how

it must be delivered to satisfy directives imposed on the enterprise by
regulatory organizations
Consortium—Association of two or more individuals, governments or enterprises

with the objective of participating in a common activity or sharing resources to
obtain a similar goal
Contract—Binding agreement between two or more parties intended to create a

legal obligation among them
Decision matrix—Support tool that allows decision makers to solve a problem by

evaluating, rating and comparing alternatives
Due diligence—The performance of those actions that are generally regarded

as prudent, responsible and necessary to conduct a thorough and objective
investigation, review and/or analysis

Enablers—Factors that, individually and collectively, influence whether something

will work
Force majeure—Clause included in contracts to remove liability for natural and

unavoidable catastrophes that interrupt the expected course of events and restrict
participants from fulfilling obligations
General principle—Contract or SLA element describing exclusion and

applicability conditions
Hold harmless—Clause where the third party assumes the risk and offers legal
protection from any action arising out of the signed contract
Incentivization—Procedure to build incentives into a contract to motivate parties to

deliver high-quality products or services
Intellectual property—Inventions, trademarks, designs, processes or any other

creation for which exclusive rights belong to the enterprise
IT requirements—Description of technical constraints, boundaries and standards

that must be considered when developing products or services
Key performance indicator (KPI)—A measure that determines how well the
process is performing in enabling the goal to be reached
Scope note: A lead indicator of whether a goal will likely be reached and a good
indicator of capabilities, practices and skills. It measures an activity goal, which is
an action that the process owner must take to achieve effective process performance.
Legal requirements—Description of constraints, boundaries and standards that

must be satisfied in order to comply with all applicable laws
Material adverse change clause (MAC clause)—Allows a contracting party to

terminate or renegotiate the contract in case of a substantial (material) change in
the circumstances (e.g., in case of a change to the current legislation). MAC clauses
are especially useful in long-term agreements. The clause should identify in a
concrete and objective manner the different circumstances that can lead to an early
termination or renegotiation of the agreement as well as the possible consequences
of a call on such material adverse change (e.g., price adjustments, termination of the
contract or renegotiation of the contract delivery terms and product specification).
Operating level agreement (OLA)—An internal agreement covering the delivery

of services that support the IT organization in its delivery of services
Out tasking—A formal agreement to turn over a specific operation to another

organization, rather than an entire function

Glossary 177
Outsourcing—A formal agreement with a third party to perform IS or other

business functions for an enterprise
RACI chart—Matrix chart that illustrates who is Responsible, Accountable,

Consulted and Informed within an organizational framework
Request for information (RFI)—A document published with the purpose of

collecting written information about the capabilities of various potential vendors
Request for proposal (RFP)—A document distributed to vendors requesting them

to submit a proposal to supply products or services that meet specific requirements
Request for quote (RFQ)—A document distributed to vendors to request price and
delivery quotations that meet a minimum set of specifications. Generally used when
sourcing commodities
Residual risk—The remaining risk after management has implemented a risk response
Risk—The combination of the probability of an event and its consequence (ISO/IEC 73)
Root cause analysis—A process of diagnosis to establish the origin of an event, which
can be used for learning from consequences—typically from errors and problems
Service level agreement (SLA)—An agreement, preferably documented, between

a service provider and the customer(s)/user(s) that defines minimum performance
targets for a service and how they will be measured
Single point of contact—An individual representing a group of people or enterprises
Source code escrow—A legal arrangement whereby an asset (often money, but
sometimes other property such as art, a deed of title, web site, software source code
or a cryptographic key), is delivered to a third party (called an escrow agent) to be
held in trust or otherwise, pending a contingency or the fulfillment of a condition or
conditions in a contract
Stakeholder—Anyone who has a responsibility for, an expectation from or some

other interest in the enterprise and its goals
SWOT analysis—Process to evaluate strengths, weaknesses, opportunities and

threats involved in a project or business venture
Underpinning contract (UC)—A Contract between an IT Service Provider and

a Third Party. The Third Party provides goods or Services that support delivery
of an IT Service to a Customer. The Underpinning Contract defines targets and
responsibilities that are required to meet agreed Service Level Targets in an SLA
(ITIL V3).

Vendor—Enterprise that sells products or services to other enterprises
Vendor management—Set of policies, processes and procedures used to

strategically source and manage vendors so that investments are maximized and
business risk is minimized
Vendor shortlist—List of vendors who best meet the enterprise objectives

and requirements

Vendor Management Using COBIT

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vendor Management Using COBIT

Uploaded by

Copyright:

Available Formats

VENDOR

Personal Copy of: Mr. Cosmin Ionascu

Provide Feedback: www.isaca.org/vendor-management

Personal Copy of: Mr. Cosmin Ionascu

ISACA Board of Directors

Personal Copy of: Mr. Cosmin Ionascu

Personal Copy of: Mr. Cosmin Ionascu

Chapter 2. Vendor Management..............................................................................11

Chapter 3. Threats and Risk Related to Vendor Management.............................21

Chapter 4. Vendor Management Risk Mitigation Actions....................................27

Personal Copy of: Mr. Cosmin Ionascu

Chapter 5. Binding Documents...............................................................................45

Chapter 6. Managing a Cloud Service Provider....................................................53

Appendix A. Vendor Selection Dashboard..............................................................87

Appendix B. Call for Tender Template...................................................................91

Appendix C. Call for Tender Checklist...................................................................95

Appendix E. Example Contract Template............................................................103

Appendix F. SLA Template....................................................................................125

Appendix G. Service Level Agreement (SLA) Checklist.....................................129

Appendix H. Example SLA Template...................................................................131

Appendix I. Example Generic SLA.......................................................................137

Appendix J. Example SLA Deployment and Maintenance of Digital Copiers.......149

Personal Copy of: Mr. Cosmin Ionascu

Personal Copy of: Mr. Cosmin Ionascu

Page intentionally left blank

Personal Copy of: Mr. Cosmin Ionascu

Vendors constitute an important part of an enterprise’s external environment. The

Purpose of This Publication

Who Should Use This Guide?

Establishing and managing vendor relations is not solely the responsibility of IT

Scope and Approach

The information is organized as follows:

Personal Copy of: Mr. Cosmin Ionascu

Chapter 2. Vendor Management

Vendor Management Defined

A vendor is a third party that supplies products or services to an enterprise.

Personal Copy of: Mr. Cosmin Ionascu

Commonly accepted vendor management processes, good practices and other

Life Cycle of the Contractual Relationship

Figure 1—Life Cycle of the Contractual Relationship

• Requirements Contract Transition-out

The first step in implementing a robust vendor management process is to define

Personal Copy of: Mr. Cosmin Ionascu

• Ability to meet availability requirements

Defining the outsourcing strategy is an important first step in the process,

Personal Copy of: Mr. Cosmin Ionascu

Figure 2—Bidding Document Comparison

Personal Copy of: Mr. Cosmin Ionascu

Contract Change Management

Stakeholder Responsibilities and Viewpoints

Many stakeholders are involved in the vendor management process. As explained in

The RACI (responsible, accountable, consulted and informed) chart in figure 3 is a

Personal Copy of: Mr. Cosmin Ionascu

Figure 3—Vendor Management RACI Chart

For involvement of large-scale vendor services covering or impacting the entire

Business Process Owners

Personal Copy of: Mr. Cosmin Ionascu

Personal Copy of: Mr. Cosmin Ionascu

Compliance and Audit

Personal Copy of: Mr. Cosmin Ionascu

• Providing information practices, such as information accessibility and required

Personal Copy of: Mr. Cosmin Ionascu

Page intentionally left blank

Personal Copy of: Mr. Cosmin Ionascu

– Relationship-building and alignment-building skills to facilitate cooperation

This information may be particularly critical if the vendor provides services

After the transition-in period, the enterprise should perform periodic