OPEN DATA CENTER ALLIANCE Sm Master Usage Model: Commercial framework REV 1.0

(1)

(2)

PROPRIETARY NOTICE AND OTHER NOTIFICATIONS

Copyright © 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.

This “ODCA Master Usage Model: Commercial Framework” is proprietary to the Open Data Center Alliance, Inc.

OPEN DATA CENTER ALLIANCESM_,_ODCASM_{, and the}_{OPEN DATA CENTER ALLIANCE}_{logo® are trade names trademarks, service marks}

and logotypes (collectively “Marks”) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited. This document does not grant any user of this document any rights to use any of the ODCA’s Marks.

All other service marks, trademarks and trade names referenced herein are those of their respective owners. This document and its contents are provided “AS IS” and are subject to all of the limitations set forth herein.

The delivery of this document to you (“user”), and the inclusion of any proposals or recommendations in this document (including, without limitation, the scope and content of any proposed methodology, metric, requirements, or other criteria) does not mean the ODCA will necessarily be required at any time in the future to finalize this document or release this document to any party outside the ODCA.

NOTICE TO NON-ODCA PARTICIPANTS

Non-ODCA Participant may only review this document and provide feedback only to ODCA regarding this document. Without limiting the generality of the foregoing, Non-ODCA Participants:

• Are not permitted to copy or distribute this document to any other party;

• Acknowledge that this document is a DRAFT and, as such, non-ODCA Participants are not permitted to reference or incorporate any part of this document (in whole or in part) in any other document without obtaining a separate prior written consent from the ODCA;

• Are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way without ODCA’s prior consent; and

• Agree that if user provides any feedback regarding this document, the user hereby automatically grants to ODCA a perpetual, irrevocable, non-exclusive, royalty-free, sub-licensable, assignable, worldwide copyright license in and to said feedback, with the right (directly and through sublicensing) to copy, publish, modify, distribute, and create derivates of said feedback in any way, including (without limitation) incorporating the user’s feedback into this document.

NOTICE TO ODCA PARTICIPANTS

(6)

Legal Notice

Copyright © 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.

This “Open Data Center AllianceSM_{Master Usage Model: Commercial Framework” is proprietary to the Open Data Center Alliance, Inc.}

NOTICE TO USERS WHO ARE NOT OPEN DATA CENTER ALLIANCE PARTICIPANTS: Non-Open Data Center Alliance Participants only have the right to review, and make reference or cite this document. Any such references or citations to this document must give the Open Data Center Alliance, Inc. full attribution and must acknowledge the Open Data Center Alliance, Inc.’s copyright in this document. Such users are not permitted to revise, alter, modify, make any derivatives of, or otherwise amend this document in any way.

NOTICE TO USERS WHO ARE OPEN DATA CENTER ALLIANCE PARTICIPANTS: Use of this document by Open Data Center Alliance Participants is subject to the Open Data Center Alliance’s bylaws and its other policies and procedures.

OPEN DATA CENTER ALLIANCESM_{, ODCA}SM_{, and the OPEN DATA CENTER ALLIANCE logo® are trade names, trademarks, service marks and}

logotypes (collectively “Marks”) owned by Open Data Center Alliance, Inc. and all rights are reserved therein. Unauthorized use is strictly prohibited.

This document and its contents are provided “AS IS” and are to be used subject to all of the limitation set forth herein.

Users of this document should not reference any initial or recommended methodology, metric, requirements, or other criteria that may be contained in this document or in any other document distributed by the Alliance (“Initial Models”) in any way that implies the user and/or its products or services are in compliance with, or have undergone any testing or certification to demonstrate compliance with, any of these Initial Models.

Any proposals or recommendations contained in this document including, without limitation, the scope and content of any proposed methodology, metric, requirements, or other criteria does not mean they will be required by the Alliance in the future to develop any certification or compliance or testing programs to verify any future implementation or compliance with such proposals or recommendations. This document does not grant any user of this document any rights to use any of the Alliance’s Marks.

All other service marks, trademarks and trade names referenced herein are those of their respective owners. Published November, 2012

Acknowledgements

ODCA would like to acknowledge the references to prior content and research material developed by

(7)

Commercial framework REV 1.0

1.0 Executive Summary

The purpose of this master usage model is to drive efficiency and value through the standardization of commercial dynamics involved in the cloud lifecycle. The goal is to have a cloud eco-system that uses standard commercial services from a variety of cloud providers and can be delivered to multiple subscribers. This Usage Model specifies requirements and definitions required to create a set of standard commercial documents for cloud services providers that fit the needs of larger enterprises. The necessary standard framework for delivering such services and standard service definitions are established in this document.

One of the major barriers to adoption of cloud services is the difficulty in establishing a Master Service Agreement (MSA) between the supplier and the consumer. Such documents can take several months to negotiate, and result in high legal costs on both sides.

In recent years we have seen a move within IT to provision away from build-to-order systems and towards standardized, assembled-from-stock components. A customer no longer waits weeks for a system to be built and delivered. Instead, IT expects to run on “industry standard” components they can assign or commission and de-commission in an agile manner as their business needs change.

Cloud standards and best practices should be pre-assembled into a structure to simplify and shorten the contractual process. The structure should be, contributed by and agreed upon by both enterprises and service providers.

The goal of this Commercial Framework usage model is to:

• Simplify and standardize the process to create and negotiate cloud contracts to achieve business outcomes. • Highlight the need for the cloud industry to adopt consistent ways to negotiate commercial contracts and MSA. • Encourage the evolution of a dynamic global marketplace based on open discovery and free market principles.

This master usage model will allow the industry to write a clear set of requirements with common legal and commercial master documents that will allow cloud subscribers to execute and scale with confidence and lower their overhead to adoption. This process is applicable to Infrastructure as a Service (IaaS), Platform as a Service (PaaS), Software as a Service (SaaS), and other less common types of services such as Virtual Private Data Center as a Service (VPDCaaS).

(8)

2.0 Framing the Problem

Many issues still exist that prevent the rapid adoption of cloud computing, including:

• Proprietary implementations with little commonality between clouds (which creates the potential for lock-in and lack of price transparency).

• Regulatory concerns over the suitability of cloud computing to meet requirements.

• Lack of cloud security to the level of consistency and transparency required for high-end enterprise implementations. • Lack of clear service definitions that allow comparison of offerings across different suppliers.

• Right of audit.

• Lack of a consistent framework to support the rapid development of commercial contracts and master service agreements that meet the specific needs of cloud subscribers. (Contracting and procurement processes are typically lengthy and arduous. Therefore, the contract generation and management processes could be easily outpaced by the technology innovation cycle. For an increased uptake of cloud computing, it is essential that trust be increased between cloud providers and cloud subscribers. More transparency in the offerings, legal aspects, and contractual arrangements is necessary, and should be driven by standards and requirements across business and regulatory obligations.

For these reasons, the ODCA members are focusing on internal private clouds as a natural first step. Internal private clouds have the potential to dramatically improve business response, and improve efficiency over more traditional IT delivery models. Transitioning in this manner enables the enterprise to realize cloud benefits while deferring immediate resolution of these significant concerns. It also allows the selective deployment of newer, cloud-friendly, scale-out applications that allow quick expansion of services on standard computers, while retaining the older, more static applications where necessary.

3.0 Scope

The ODCA Master Usage Model: Commercial Framework is focused on shortening the time required to set up commercial working

relationships between cloud subscribers and cloud providers. It is driven by a synthesis of most significant regulatory compliance obligations and cloud-centric business requirements that drive commercial negotiations within the ecosystem. The framework strengthens the ability of cloud subscribers and cloud providers to address regulatory concerns within the context of meeting and surpassing business expectations for cloud implementations.

The Open Data Center Alliance believes the formal definition of standard commercial agreements is important for the evolution of an enterprise-ready, open cloud marketplace.

A standard and common data model for commercial contracts will facilitate widespread adoption by cloud providers, and will enable cloud subscribers to access compliant and commercially viable services.

By providing a clear set of requirements at a variety of service levels that are carefully underpinned with a set of common legal and commercial master documents, cloud subscribers will be able to execute at scale with more confidence and with much lower overhead to adoption.

This is an ambitious project, requiring a number of iterations to deliver the needed detail. Please review Section 7.0 Describing the Commercial Framework in this document to appreciate the scope of this usage model.

Future iterations of this initiative will:

• add further clarity on the terms and conditions;

• provide further guidance on the applicability of the drivers across common business problems; • automate the selection of key requirements to suit a specific business problem;

(9)

Value Proposition Achieved

Drive efficiency and value, shorten the

time to setup commercial relationships Through standardization of the commercial dynamics to shorten in the cloud lifecycle and the time taken to negotiate compliant and effective contracts Through the provision of standards driven by an analysis and scan of the business requirements, regulatory requirements, and commercial dimensions specific to cloud computing

Maximize reuse Through reuse of the umbrella MSA, and inherit the MSA to create local agreements or specific project based agreements for a cloud provider / cloud subscriber pair.

Enforce compliance Through the analysis and inclusion of regulatory compliance requirements, as an integral part of the contract, including terms and conditions for monitoring regulatory compliance.

Influence regulatory and industry

change Through the articulation of the challenges associated with the complex and diverse regulatory environment

Influence standardization of services

and quality attributes Through the definition of levels of service, quality metrics, and assurance terms. Evolution of an enterprise-ready, open

cloud marketplace Through the cloud providers defining standard compliant solutions and service definitions meeting the commercial framework requirements

4.0 Value of the Commercial Framework

The ODCA Commercial Framework provides value across the cloud lifecycle through the specification, definition and guidance that supports several elements contributing to the value proposition.

(10)

Actor/Term Description

Cloud Provider An organization providing network services and charging cloud subscribers. A (public) cloud provider provides services over the Internet. A cloud subscriber could be its own cloud provider; such is the case for private clouds.

Cloud Standards Body An entity responsible for setting and maintaining the cloud orchestration standards contemplated in this usage model.

Cloud Subscriber A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud.

Cloud Broker An entity that manages the use, performance, and delivery of cloud services and negotiates relationships between cloud providers and cloud consumers. In general, a cloud broker can provide services in three categories: Service Intermediation, Service Aggregation, and Service Arbitrage.1

(Definition from NIST Cloud Specific Terms and Definitions)

Cloud Federation A concept of service aggregation characterized by interoperability features that address the economic problems of vendor lock-in and provider integration.2

(Definition from Cloud Federation http://www.aifb.kit.edu/images/0/02/Cloud_Federation.pdf)

Cloud-Aware Application Applications designed and built with the sole intent of running in a cloud environment.

Traditional Application A program or system that has not been specifically designed (or remediated) to transparently leverage the unique capabilities of cloud computing.

Workload A machine image or virtual machine instance and information on the technical layout (e.g., number of cores, RAM, etc.), network configuration, and the data store directly associated with the VM. The VM is the abstraction of all the workload’s constituent elements.

5.0 Taxonomy

The standard terms and definitions used in this document are listed below in Table 4.1 Terms Definitions.

(11)

6.0 Commercial Framework - Disclaimer

Open Data Center Alliance, Inc. is NOT a law firm.

The terms and conditions set forth in this Commercial Framework Usage Model are intended to be used as templates only and are not intended as legal advice. Our publishing of this document and your use hereof is NOT intended to create nor does it create an attorney-client relationship between Open Data Center Alliance, Inc. and you. We encourage you to seek proper, independent legal advice from an appropriate advisor before making use of any terms, conditions or other materials found herein.

No template can possibly contemplate every contingency, and the particular facts and circumstances of your situation may make an

otherwise relevant document undesirable or incomplete. Further, laws and the application of laws by courts and government agencies change frequently. If you use a document, you do so at your own risk and you are totally and solely responsible for the consequences of your actions. The terms, conditions and other materials set forth in this document are provided to you on an “as is” and “as available” basis. We expressly disclaim all warranties with respect to the content hereof, express and implied, including but not limited to the implied warranties of

merchantability, fitness for a particular purpose, title, and non-infringement. We expressly disclaim any warranty that any terms, conditions or other materials contained herein are legally enforceable. Finally, we reserve the right to change this document at any time in our sole discretion.

(12)

Figure 7.1.1 Construction of the OCDA Master Services Agreement (Generic)

ODCA Master Services Agreement (Generic)

Inputs

Generic External Drivers Generic Customer Requirements Generic Supplier Capabilities Sample Clauses Monitoring Considerations Contractual Requirements Pre Contractual Considerations Risks Mitigated Motivation Business and Regulatory Drivers ODCA Master Services Agreement (Generic) Regulatory Obligations [Local, National, International] Industry Standards Business Requirements [primarily non functional requirements] Policy Requirements

7.0 Describing the Commercial Framework

The ODCA Master Usage Model: Commercial Framework supports the definition, negotiation, and generation of a commercial contract to meet key business requirements (functional and non-functional) and regulatory obligations governing cloud subscribers and providers.

7.1 The ODCA Master Services Agreement (Generic): Introduction

To support this objective, the ODCA has specified a generic MSA. The MSA (or contract guidance) has been created using: • Generic external drivers: International quality standards, regulatory requirements, obligations, etc.

• General customer requirements: Items and details that all customers require, such as improved quality of service (QoS) and lower costs

• General supplier capabilities: Quality certification and service reporting as well as the standard text blocks derived by the ODCA that can be selected and used as components within any such agreement.

• Based on discussions and consensus between knowledgeable practitioners, a standard set of material that could form a sound basis for an agreement between any cloud subscriber and any cloud provider has been specified within the ODCA MSA (Generic).

(13)

7.2 ODCA Master Services Agreement (Generic): Key Drivers

The ODCA MSA (Generic) is indexed by key regulatory and business drivers that drive the obligations, compliance, and commercial analysis within service-based cloud arrangements.

• The regulatory influences and business requirements are chosen from a universe of concerns, as a representative set of “common concerns” that may apply in a generic sense across multiple situations.

• Regulatory drivers are external influences and obligations to comply with laws, regulations, industry standards, and insurers who may influence the terms of a contract.

• Business drivers are internal influences within an organization (cloud subscriber or cloud provider) that provide commercial considerations, business specific requirements (functional and non-functional), risk management, and policy compliance considerations.

An overlap between regulatory drivers and business drivers can exist. Each driver section contains one or more of the following:

• Description of the driver and why it is relevant to a cloud agreement.

• Motivation of the driver based on specific questions, risks and considerations, such as industry type, regulation type, business need, or the resolution of an existing business problem.

• Risks that are potentially mitigated by the effective implementation of the commercial framework driver.

• Key considerations before negotiating a commercial contract, including cloud subscriber responsibilities. Note: These considerations not normally specified within a contract.

• Key considerations for inclusion within a cloud contract are requirements-based and define the roles and responsibilities of the key actors for implementing and managing the cloud services.

• A monitoring methodology for assuring adherence to the contract.

In a future version of the document, standard terms and conditions to support the key contractual requirements will be specified in further detail (there is initial guidance in this document). It is important that these terms and conditions are compliant, valid, enforceable in the defined jurisdictions, and balance the needs of the cloud subscriber and cloud provider.

Table 7.2.1 The Commercial Framework Drivers Influence The Following Types Of Considerations

Consideration Description of the Solution

Cost and Service Managing service levels and economics of the commercial arrangement.

Trust and Sustainability Ensuring trust, privacy, and security within the relationship, and taking actions to support sustainability of the business or technology processes when a cloud arrangement is terminated or requires inter-operability.

Data Ensuring effective ownership, flow, storage, retention, and return of data.

Dealing with issues Key considerations to prevent, detect, and respond to issues through the lifecycle of the contract.

Baseline details in a contract Defining the governing law, managing the governance and change control, and executing the contract, for all parties involved.

(14)

A schematic of the current list of regulatory and business drivers elaborated within the ODCA Master Usage Model: Commercial Framework is provided below:

Table 7.2.2 Master Services Agreement Generic Key Drivers

Cost and Service Cost_Management Service Levels Availability

Portability Multi Tenancy Liability Licensing Record Retention Sanitization Information Security Privacy Intellectual_Property

Trans Border Flow Ownership Sub Contracting Divestiture Governing Law Assignment Incident Managment Indemnity Monitoring Breach Management Variations

to Terms Priority ofDocuments Auditability Electronic Discovery Trust and Sustainability Data Dealing with Issues Baseline Details within a Contract

8.0 Usage Scenarios: Using the Commercial Framework

8.1 Usage Scenario: Creating an Organization/Context Specific Master Services Agreement

As described in the Disclaimers section of this document, the ODCAMaster Services Agreement (Generic), while providing guidance on inclusions within a contract, is not sufficient to generate commercial contracts and should not be considered legal advice. The creation of an organization/context specific Master Services Agreement to deliver cloud services is a multi-stage process. This process is intended to be invoked frequently: at least once for every combination of cloud subscriber and cloud provider. The process includes:

• As suitable foundation material, the ODCA Master Usage Model: Commercial Framework has created a set of generic MSA material (requirements, motivation, terms and conditions, and controls).

• When a cloud subscriber and cloud provider agree that they will do business together, they will set up a MSA that encompasses any specific engagements.

• For any one pairing of cloud consumers and cloud providers, a selection process is followed to determine which of the ODCA-supplied material is to be used to set up an organization/context specific MSA between them.

• The organization then customizes the ODCA MSA (Generic) to include their specific requirements. These can include: º Specific customer technical, external regulatory, regional, or business requirements that may vary per country, business

(15)

º Any specific terms and conditions which the customer wishes to apply. Caution should be exercised as deviation from the standard terms may also lead to inapplicability of the standard benefits. Note: All cloud subscriber-specific arrangements are likely to be costlier in the long term.

º Any specific capabilities or offerings provided by the cloud provider. Note: Caution is required as the use of cloud provider-specific facilities may inhibit the possibility of portability or interconnectivity in the future.

A decision process ensures that varying inputs are matched to produce the organization specific MSA for delivery of services between that cloud subscriber and cloud provider. Multiple MSA documents may be required. For example, there could be a common service MSA, and specific MSA documents for different countries based on local requirements and regulations.

The organization-specific MSA provides an umbrella or all-encompassing contract that will contain common obligations, terms and conditions, and methodology to govern the commercial arrangement. The ODCA envisions that the time taken to setup an organization specific MSA will be greatly reduced by leveraging the framework outlined in this document.

Figure 8.1.1 How Organization-Specific Context Agreements are Constructed

Organization-specific Master

Services Agreement (context-specific) Inputs Organization-specific Master Services Agreement (context-specific) Decision Process ODCA Master Services Agreement (Generic) Customer-specific Business Requirements [functional, non functional, policy, etc.] Customer and Industry-specific Regulatory Requirements Supplier-specific Capabilities Contract-specific Terms and Conditions

(16)

8.2 Usage Scenario: Creating a Project-Specific Master Services/Local Agreement

Once an specific master services/local agreement has been setup, service agreements can be derived from the organization-specific MSA for service delivery arrangements. Delivery arrangements can also be called project services or statement of work for organization-specific services.

The organization-specific MSA can be reused across future statements of work or contracts for specific services that fall under a detailed engagement for a specific purpose – the value proposition is to ensure that common terms and conditions are negotiated primarily once only, and reused across detailed engagements for the same customer and supplier pair.

This methodology ensures that the time taken to set up additional contracts is reduced and the requirements for cost management, compliance, governance, service provision, and quality attributes can be reused once they have been negotiated.

Figure 8.2.1 How Project-Specific Local Agreements are Constructed

Local Agreement 2 Local Agreement.. Local Agreement 3

Organization-specific

Master Services

Agreement

(context-specific)

Inputs

Project-specific agreements defined under

the umbrella of context-specific MSA

Local Agreement 1

(17)

8.3 Usage Scenario: Using the Commercial Framework Within Cloud Services Lifecycle

The following picture illustrates the cloud services lifecycle.

Figure 8.3.1 Cloud Services Lifecycle

Discovery Negotiation Provision Instantiate Use Terminate

The ODCA Master Usage Model: Commercial Framework can be applied across these lifecycle stages, and the application is described in the usage scenarios.

8.4 Usage Scenario: Using the Commercial Framework to Discover Services

Pre-conditions

Definition of the business problem: The cloud subscriber should have identified and defined the specific business problem to be solved, or opportunity to be gained by using cloud services and cloud computing arrangement.

Define requirements: The cloud subscriber should have defined the requirements for the service about to be acquired or transformed. Business requirements are influenced by a combination of factors, and should include:

• Functional and non-functional business requirements and the context specific needs of the business.

• Identify the scope of the applicable regulatory landscape: The cloud subscriber should have defined regulatory and compliance drivers and obligations, enabling the specification of clear mandates and regulatory obligations that must be met by providers of cloud services. Since cloud services generally cross jurisdictional boundaries, services are typically influenced and governed by regulatory obligations at local, federal, international, and industry levels. Regulatory obligations and compliance cover a lot of ground. They include government regulations, such as Sarbanes-Oxley and the European Union Data Protection Act, and industry regulations, such as PCI DSS for payment cards and HIPAA for health data.

• Refer to the ODCA Usage Model: Regulatory Framework3_{for a sample list of regulators, industry standards organizations, and}

regulations.This usage model provides a reference to a sample of local, federal, and international regulatory bodies, regulations, laws, and standards spanning industry domains such as government, banking brokerage and financial services, health/

pharmaceuticals, and telecommunications.

• Refer to the ODCA Master Usage Model: Commercial Framework (this document) to create and refine the set of commercial requirements within a cloud services arrangement including business drivers, and regulatory drivers.

(18)

Scenario steps

1. Access service catalog: The cloud subscriber accesses the service catalogs of one or more cloud providers to obtain a list of available services. This supports an improved understanding of the services offered by the cloud providers, and also enables the application of a first-level filter based upon corporate policy. For example, a provider may offer a service to remove companies from an enterprise’s roster that do not meet minimum standards for corporate governance, financial disclosure, credit worthiness, or service.

2. Due diligence: The cloud subscriber conducts due diligence of the cloud provider and the subcontracted parties. Due diligence includes commercial standing, reputation, track record, capacity to meet cloud subscriber expectations, and requirements.

3. Risk assessment: The cloud subscriber conducts a risk assessment of the concentration of services being supported by each cloud provider. If a significant proportion of critical functions and/or material business functions are supported by a single provider, the risks in the event of cloud provider failure is greater than if the services are spread over multiple providers.

4. Assess and select services: The cloud subscriber reviews the service catalog of the filtered cloud providers to select the subset of cloud providers that meet the required service assurance parameters for the amount of units of service desired as well as the regulatory and business requirements specified by the ODCA Master Usage Model: Commercial Framework. The constraints, obligations, standardized service quality attributes, and terms and conditions specified by the ODCA Master Usage Model: Commercial Framework should be used to assess solution and service offerings from cloud providers and brokers.

8.5 Usage Scenario: Negotiation

Once the cloud subscriber identifies the vendors and service offerings that best meet their needs (based on consumer experience bias or limitations, such as in-place contracts, past service experience, etc.), the cloud subscriber negotiates with the cloud provider to establish a contract for the cloud services. The output of this phase is a signed contract in which the cloud subscriber agrees to consume services at a certain price while the cloud provider agrees to meet that demand and all other contractual obligations.

The ODCA Commercial Framework specifies standards and guidance for the creation of standard contracts and terms and conditions driven by business context, regulatory context, and the business problem being solved.

The standard set of documented requirements and clauses are appropriate for use by both the demand and the supply side, increasing the potential reuse of agreements and contracts across different provider/customer pairs.

8.6 Usage Scenario: Provision, Instantiate, and Use Service

During the provision service phase, the cloud subscriber submits the final requirements that have been negotiated and agreed with in the commercial contract to the cloud provider for the service they wish to acquire. The cloud service provider then fulfils the service request. Instantiation is an optional phase. Instantiation allows for any manual work the cloud subscriber needs to be completed to enable their consumption of the cloud service. This might include setting custom configuration parameters beyond the standard set of requirements, establishing security, and so on.

Environments and resources are established based upon the requests made above by the consumers.

The ODCA Master Usage Model: Commercial Framework specifies contractual requirements to be implemented during service provisioning and use, within the areas of:

• Service and performance levels • Availability

• Cost management

• Portability and interoperability • Information security

(19)

• Data ownership

• Location of data and cross-border data flow • Incident management

• Breach management • E-discovery

• Sustainability and business continuity • Data sanitization

• Record retention

• Intellectual property management.

Monitoring and governance: The ODCA Master Usage Model: Commercial Framework provides governance and monitoring requirements in the contract for:

• Service and performance levels • Availability

• Cost management

• Location of data and cross border data flow • Privacy

• Information security • Data ownership

Measurement: It is envisioned that service attributes and performance levels offered by providers will be measured by applying ODCA

Usage Model: Standard Units of Measure,4_{and consistent quality levels within a service such as bronze, silver, gold, platinum. This phase}

requires monitoring and reporting on services at levels necessary to ensure SLAs are maintained and achieved.These measurements allow cloud providers to display their ability to meet service levels for prospective customers. Customers can use the metrics to compare service performance between providers. Metrics also support increased interoperability.

Compliance program: Cloud subscribers and cloud providers should develop an on-going corporate compliance and risk management program to ensure regular review of regulatory requirements and changes, industry standards, internal processes, and cloud provider operations. Refer to the ODCA Usage Model: Regulatory Framework 3_{for guidance on developing a corporate compliance and risk}

management program.

8.7 Usage Scenario: Terminate Service

The ODCA Master Usage Model: Commercial Framework provides requirements, key considerations and clauses to support orderly termination of a contract, while maintain portability of the service and managing data.

Within the terminate service phase, the cloud consumer or the cloud provider chooses to terminate the service as bound by the contract that was signed in the negotiation phase.

Termination can occur as a normal course of business operations or as a result of abnormal events, such as contract violation and security incidents or breaches that could involve penalties or recourse options

The cloud services may be transitioned back in-house, terminated as the business opportunity has ceased to exist, or moved to another cloud service provider. Portability of the service is a key consideration.

The ODCA Master Usage Model: Commercial Framework has defined several regulatory and business drivers relating to termination of a cloud service. The objective is to maintain the sustainability, portability, and interoperability of the services.

(20)

The cloud subscriber should use the ODCA Master Usage Model: Commercial Framework to determine data management, information management, and service management required by the scope of the cloud arrangement.

The specific sections and drivers within ODCA Master Services Agreement (Generic) that pertain to cloud termination are: • Privacy • Data Ownership • Electronic Discovery • Intellectual Property • Data Sanitization • Record Retention

• Portability (as related to cloud termination)

9.0 ODCA Generic Master Services Agreement (MSA)

The following sections describe the prospective sections of a contract. The sections are indexed as Drivers. Refer to the ODCA Master

Services Agreement (Generic): Key Drivers section of this document for details on the drivers and the contents of the generic master services

agreement.

Cloud services are designed to fulfil a need for flexible use so that a user-company can cope with unplanned requirements in either facilities or volumes. For example, after installing a new system a few months may pass before the customer realizes the cloud can and should be interconnected to another system. For this reason, ODCA suggests all components of an MSA should be discussed and agreed upon, even if some are not in the initial scope. These components can be invoked at a later date, when they are needed.

9.1 DRIVER: Governing Law

Type

This driver is primarily driven by business requirements and regulatory requirements.

Description

• This section describes the considerations around which law governs the execution, implementation, and fulfilment of the contract. This section also provides information on which laws may be relevant in court cases.

• Choices of law and jurisdiction clauses are frequently included in contractual agreements. It is likely that more than one legal jurisdiction will be involved within a cloud service. The choice of law and jurisdiction will determine which country’s law applies to compliance obligations, dispute resolution, arbitration, etc.

• Cloud subscribers usually avoid enforcing contractual terms in overseas jurisdictions under foreign law. Similarly subscribers avoid defending an action in an overseas jurisdiction under foreign law.

• The cost of legal considerations should be assessed and compared with the benefits of the particular cloud service in a foreign jurisdiction.

Motivation

• Conflicting legislation and regulations: Different countries or regions have differing and at times conflicting information on legislations and regulations that affect such issues as legal protection and the commercial regulatory climate.

• In a cloud environment, the region and jurisdiction of the cloud subscriber and the cloud provider may be different.

• Location of data being hosted in the cloud, as well as location from which data is administered may also be different from the cloud subscriber’s location.

(21)

• Unless specified, it would be unclear which jurisdiction should apply. It is important to determine which governing law or laws apply when a contract is documented and executed.

Assessment and Pre-Contractual Considerations

The cloud subscriber should consider the legal aspects before entering into a contract and review the criteria used to determine the governing law. Choices for governance include:

• Governing the contract by the law of the state, country or region in which the cloud subscriber is established. • Governing the contract by the law of the location where the cloud provider has its main office or strong presence in a

jurisdiction.

• Governing the contract by the law of the location where the transaction is performed when a cloud provider has strong multinational presence.

Contractual Considerations

The contract should specify clear guidance on governing law and law used for dispute resolution. Sample clause (this is not legal advice, it is provided as guidance only)

a. Subject to mandatory Applicable Law which may not be excluded by contract, this Master Agreement and any Local Agreements are governed by the laws of <insert applicable jurisdiction here>

b. Subject to clause (a), the Parties irrevocably submit to the exclusive jurisdiction of the < insert applicable jurisdiction here > Courts over any action, claim or matter arising under or in connection with this Master Agreement

Relevance to Cloud Models

IaaS, PaaS, SaaS

9.2 DRIVER: Variations to Terms of Service

Type

This driver is primarily driven by business requirements.

Description

This section describes the considerations to guide how terms and conditions within a contract can be changed, who can make changes and when the changes can be made.

Motivation

• Different classes of change in a contract can be handled differently. It may be appropriate to require notice and possibly an option to terminate the contract in the case of a material change in the service that negatively impacts the cloud subscriber. • With SaaS services, cloud subscribers may have to accept the providers’ rights to change features. It is important that this does

not adversely impact the contracted service.

• Changes to IaaS or PaaS implementations may result in significant impact to cloud subscribers too.

• Updates made to the cloud-computing infrastructure, platforms, or applications could result in functional changes or impacts to the service received by the cloud subscribers.

• Therefore it is important that critical changes to the implementation are carefully managed and governed within a contract.

Assessment and Pre-Contractual Considerations

• The cloud subscriber and cloud provider should agree on which changes can be made without prior consent, which class of changes require prior consent, and the notice period required.

(22)

• In some instances, the cloud provider may have discretion to unilaterally amend specific terms of the contract. This allows the provider to accommodate development in technology and to react to updated regulatory mandates. This should be clearly assessed and considered.

• Contracting on terms that can be amended without notice involves an element of trust. The parties to the contract should agree which terms belong to this category.

Contractual Considerations

The cloud subscriber and cloud provider should determine which changes can be legitimately made by which party (with or without notice or prior consent). For example:

• It may be appropriate to allow the cloud provider to make changes without notice to avoid intellectual property infringement or service changes that do not impact functionality.

• It may be appropriate for the cloud service provider to make changes when the changes either improve or at least do not have a detrimental impact on the cloud subscriber rights or service requirements.

• The cloud provider and the cloud subscribers should agree on which types and instances of changes will require a written agreement or amendment to the terms and conditions of the contract.

• The contract should specify a change control procedure for changes to the contract, including changes to service levels, quality attributes, costs, controls, processes, etc.

• No modification, amendment, or waiver of any provision in the agreement shall be effective unless it is in writing and either signed or accepted electronically by the party against whom the modifications, amendment, or waiver is to be asserted.

• The cloud service provider cannot change core services without consent. Minor changes (agreed prior) can be permitted without notification.

• The cloud service provider is permitted to make improvements to services, if the provider can ensure the changes are not detrimental to the cloud subscribers’ service levels.

• The cloud subscriber is permitted to terminate the contract or reject changes to the contract when the current contract period expires if the changes made by the provider are detrimental to the service levels.

• The cloud provider should provide notice prior to discontinuing a feature or functionality. The notification period should be in line with the time that it would take the cloud subscriber to manage the impacts of the changes.

Relevance to Cloud Models

IaaS, PaaS, SaaS

9.3 DRIVER: Multiple Parties and Sub Contracting

Type

Description

This section describes the considerations of managing contracting of services with multiple parties, and sub-contracting issues.

Motivation

• Cloud services may be provided by multiple parties (in the form of sub-contracting, cloud brokers, or cloud integrators). This affects cloud contracts, and the enforceability of the contract between parties.

• The presence of multiple parties in a contract could lead to inappropriate management of service levels, reduce clarity around liability for under performance, diffuse the responsibility for information security or privacy breaches, and complicate who can access data and systems.

(23)

Risks If Sub Contracting and Multiple Parties Are Not Considered

Risks posed by poorly defined contract management and handling processes include:

• Not being able to assign accountability and responsibility for the obligations of the contract. • Privacy breaches.

• Inability to determine recourse actions when there is contractual under performance. • Ineffective management of liability considerations.

Assessment and Pre-Contractual Considerations

• The cloud subscriber should assess the impact of handling multiple parties and sub-contractors from an information security perspective, and then devise an appropriate contract.

• The cloud subscriber should assess if sub-contracting will involve data processing in a non-approved region or a region that presents challenges in implementing controls that are required to meet regulatory and business obligations.

• The cloud subscriber should ensure that personal data processing in the cloud is adequately secured regardless of whether one party (cloud provider), or multiple parties (sub processors, or sub-contractors) process the data.

• The contract between a cloud provider and a cloud subscriber should consider if sub-contracting is permitted and how it should be implemented. Sub-contracting should only be invoked for specifically agreed functions.

• The third party liability of sub-contractors should be assessed and clearly specified. This is also relevant to claims arising from privacy or security breaches when personal or confidential information is involved.

• Integrators can be contracted independently from cloud providers or they can act as an intermediary between the cloud provider and subscriber. The cloud subscriber must consider how using an integrator will affect their continued use of a cloud provider environment when integrator’s contract ends.

Contractual Considerations

The following aspects require consideration within a cloud contract:

• The cloud provider should not sub contract the services to a third party, without consultation with and agreement from the cloud subscriber.

• When a cloud subscriber agrees to use of contractors, the cloud provider should be responsible for identifying the sub-contractors. The provider is also responsible for notifying the cloud subscriber prior to changing the agreed sub-sub-contractors. • The contract should specify and consider the implications of liability and how the liability is transfer (or not) between multiple

parties.

• This agreement shall be binding on the parties and their successors through mergers, acquisitions, or other processes. • Neither party may assign, delegate or otherwise transfer its obligations or rights under this Agreement to a Third Party without

the prior written consent of the other party.

• The cloud subscriber should have vetting and veto powers over the sub-contractors.

• In limited instances, the cloud subscriber may contract directly with the sub-contractors for significant obligations.

• The cloud provider should remain directly responsible for all aspects of complying with the terms of their contract irrespective of the use of sub-contractors.

• The contract should clarify and specify the chain of responsibility and recourse actions for breaches, incidents, and service level performance when multiple parties are contracted.

Contract Monitoring Considerations

(24)

• Review service performance for contractors and sub-contractors. • Review liability considerations.

• Monitor the control environment with sub-contractors.

IaaS, PaaS, SaaS

9.4 DRIVER: Assignment and Divestiture

Type

Description

This section describes the considerations to manage the continuity or otherwise of a commercial contract resulting from either parties to the contract changing their business model, or organizational structure due to mergers, acquisitions, and divestiture of business interests.

Motivation

• It is important to think through the implications of mergers, acquisitions, or divestiture of the cloud providers business on the continuity (or otherwise) of the commercial contract or master services agreement, as well as similar implications due to mergers, acquisitions, or divestitures of the cloud subscriber’s business.

• Negotiation of appropriate assignment or novation clauses can reduce the financial fees and negotiation costs arising from contract changes to deal with business structure changes.

Risks If Assignment of Contract Is Not Considered

Potential risks of not defining and managing the handling of contract assignment are:

• Loss of business continuity due to the contracted services not being provided by the cloud provider. • Increased costs to manage changes to contract terms and conditions.

• Customer impact due to impacts on continuity of service.

• Reputation damage arising from the inability to enforce the contract.

Assessment and Pre-Contractual Considerations

• The cloud subscriber should analyze the types of assignment scenarios that are of strong concern to the cloud subscriber, but may not be problematic for the cloud provider, and include reasonable considerations within the contract. The transfer of the agreement to an affiliate of the cloud subscriber has generally been acceptable to cloud providers.

• The cloud subscriber should assess the management strategy in the event their business is sold to another entity, either as by a transfer of shares or as a sale of assets. A key consideration could be to allow assignment to anyone who acquires the business that uses the technology and business services supported by the cloud arrangement.

• From a cloud provider perspective, it is important to assess the pre-requisites of “full novation” of the contract to ensure that the contract is novated to a cloud subscriber (assignee) that has an equivalent or acceptable credit rating as the assignor itself. • The cloud subscriber should analyze the implications of business changes to the cloud provider’s business, with due

consideration to when the supplier is able to assign the agreement to an entity (usually acceptable to the cloud subscriber when the cloud provider’s entire business has been acquired, by an entity that is acceptable to deal with). The flexibility of contract assignment should take into account the interests of both parties in the arrangement.

(25)

Contractual considerations

The cloud contract should specify the following considerations:

• If a cloud provider assigns portions of their revenue stream as part of a financing plan for their business, the cloud subscriber should be able to continually deal with the cloud provider directly for the matters within the arrangement (and not have to deal with the assignee of the revenue stream).

• Conditions when the cloud subscriber can assign or novate the contract. • Conditions when the cloud provider can assign or novate the contract.

IaaS, PaaS, SaaS

9.5 DRIVER: Priority of Documents

Type

Description

This section will govern which parts of the agreement override other parts of the agreement if there is a conflict between the constituent parts. Such conflicts could occur within a contract or master services agreement when it has been drafted by multiple stakeholders, when there are many schedules or agreements (master agreement, local agreement, project agreement, schedules, appendices etc.), or when certain terms and conditions contradict each other.

Motivation

• Different requirements within the contracts could create inconsistencies or contradict each other. Different parts of a contract could also be drafted at different stages and timelines. It is therefore important to specify the management of contract documents to deal with multiple documents, and agree on a hierarchy of precedence to govern the required actions and implications.

• An agreement on the priority of documents can resolve several potential issues with contract execution and fulfilment of requirements, compliance, and governance obligations.

Risks If Priority of Contract Documents Is Not Considered

Potential risks of not defining and managing the handling of priority of contract documents are: • Inconsistent understanding and execution of contract terms and conditions.

• The cloud subscriber should analyze the types of assignment scenarios that are of strong concern to the cloud subscriber, but may not be problematic for the cloud provider, and include reasonable considerations within the contract. The transfer of the agreement to an affiliate of the cloud subscriber has generally been acceptable to cloud providers.

The cloud contract should agree on the following:

• For Prioritization of contract documents: In the event of and to the extent of any inconsistency between two or more documents which form part of the contract, the documents should be interpreted in an agreed order of priority.

Sample clause (this is not legal advice, it is provided as guidance only). In the event and to the extent of any inconsistency between two or more documents which form part of this Contract, those documents will be interpreted in the following order of priority:

(26)

º The Contract Details and any attachments to the Contract Details; º these terms and conditions;

º documents incorporated by reference in these terms and conditions; and º the remaining appendices to these terms and conditions

Prioritization of Contract Details and Attachments

º In the event and to the extent of any inconsistency between the Contract Details and any attachment to the Contract Details, the Contract Details will take priority

Prioritization of Documents in Appendix

º In the event that any of the following documents are incorporated into this Contract (whether by attachment to or by reference in Appendix), they will be interpreted in the following order of priority

º priority document type 1 º priority document type 2 º priority document type n

º and any further incorporated documents will be prioritized consistently with the foregoing

Relevance to Cloud Models

IaaS, PaaS, SaaS

9.6 DRIVER: Intellectual Property

Type

Description

This section describes the considerations to manage Intellectual Property (IP) within cloud arrangements. Intellectual property protection is applicable for both the cloud subscriber, as well as the cloud provider. Certain IP rights belong to the cloud subscriber, usually based on the data owned by them. Certain IP rights belong to the cloud provider, usually algorithms, patents, design and such.

Motivation

• Handling of intellectual property in the cloud is an important consideration because confidential or commercially sensitive data may be stored or processed by cloud arrangements.

• Storing original works, illegal content, or offensive content on the cloud infrastructure could impact reputation, and breach intellectual property.

• It is important to assert who owns the rights to the dataand information hosted and used within the cloud service.

Risks If Intellectual Property Is Not Considered

Potential risks of not defining and managing how intellectual property is handled are: • Intellectual property breaches.

• Liability arising from IP breaches. • Reputation damage.

• Regulatory fines or compliance breaches. • Loss of competitive advantage.

(27)

• The cloud subscriber should analyse and understand what constitutes intellectual property.

• The cloud subscriber and the cloud provider should understand the legal landscape influencing the management, protection and governance of intellectual property in all locations where the cloud contract is executed and where the provider operates to supply the service.

Contractual Considerations

The cloud contract should specify the following considerations:

• Clarify the ownership of data and intellectual property produced by the data. This IP is usually owned by the cloud subscriber. • Clarify what Intellectual property is owned by the cloud provider. The IP of services being provided usually belongs to the cloud

provider.

• Clarify the ownership of IP rights to the applications and executables developed on Platform as a Service (PaaS). While the IP of the applications developed usually belongs to the cloud subscriber, the IP of Platform and integration tools usually belong to the cloud provider.

• Intellectual property must be protected when the data is moved, retained, or disposed of. The roles and responsibilities for protecting the IP should be clarified between the cloud subscriber and the cloud provider.

• Clarity the ownership of IP resulting from enhancements to SaaS applications suggested by the cloud subscribers. • The cloud subscriber owns the right to review logs and manage intellectual property infringement issues.

• The IP implications of using software licenses in the cloud must be assessed from the perspectives of capacity and virtualization.

Contract Monitoring Considerations

• Monitor the breach of intellectual property rights. • Monitor the controls to protect intellectual property.

IaaS, PaaS, SaaS

9.7 DRIVER: Liability

Type

Description

This section describes the considerations required to manage cloud provider and cloud subscriber liability.

Motivation

In the event of an incident, breach of contract, or contractual under performance, it is important to determine the extent of liability and ownership of liability to handle recourse actions. Incidents could be triggered by the cloud subscriber, cloud provider, or the end user of the service (the end customer).

Risks If Liability Is Not Considered

Potential risks of not defining and managing how liability is handled are: • Reputation damage.

(28)

• Loss of competitive advantage. • Financial loss.

Assessment and Pre-Contractual Considerations

The liability considerations impact both the cloud subscriber and the cloud provider. Both parties should consider the implications of liability in terms of quantifying the liability, assessing the type of liability being agreed upon, liability payments or compensation, and definitions of what constitutes breaches, direct losses, indirect losses, consequential losses and other parameters that drive liability management.

The contract should clarify and define the following liability related considerations: • The liability of the cloud provider

• The liability of the cloud subscriber

• The circumstances when liability clauses will come into effect (i.e. What is the liability for). Examples of liability conditions are direct losses, indirect losses, loss of revenue, loss of profit or goodwill, reputational damage, security breaches, incidental, special, consequential or exemplary damages.

• Define the amount of liability including no liability, limited liability, tiered approach to limiting liability, unlimited liability, capped liability etc.

• A provider can decline liability for any direct, indirect, losses. This can include damages for loss of profits, goodwill, and loss of data. This agreement can be upheld even if the other parties have been advised of the possibility of such damages.

• The contract can limit the liability loss to the fees to be paid during a specific period, specify a capped monetary amount, tied to resupplying services lost or paying the cost of resupplying services lost, or a combination of these considerations

• A contract can place an overall cap on the extent of any damages for which the cloud provider will be liable, or for which a cloud subscriber will be liable.

• Specific warranties with liability in relation to data loss or corruption may be implemented.

• Damage or loss can be caused by an act of nature or other force that cannot be controlled by the parties involved (i.e., force majeure). A contract should consider how liability would be handled in such a case.

Relevance to Cloud Models

IaaS, PaaS, SaaS

9.8 DRIVER: Indemnification

Type

Description

This section describes the considerations required to manage indemnity clauses in a contract. An indemnity commits that one party undertakes to accept the risk of loss or damage the other party may suffer as a result of events, behavior, incidents, breaches etc. The indemnity is a legally binding commitment.

Motivation

Indemnification clauses impact both the cloud provider and the cloud subscriber, and are key considerations within a contract.

Risks If Indemnification Is Not Considered

Potential risks of not defining and managing how indemnification is handled are: • Reputation damage.

(29)

• Financial loss.

Assessment, Pre-Contractual and Contractual Considerations

• The cloud provider may require the cloud subscriber to indemnify the cloud provider against any claim arising from the cloud subscriber’s use of the service. This indemnification requirement needs careful consideration on part of the cloud subscriber. • The cloud subscriber may require the cloud provider to indemnify the cloud subscriber against any liability arising from a third

party claim that the cloud provider has infringed intellectual property rights of the third party.

• Cloud subscribers should assess the impact of any claim from an individual, also known as a data subject, as a result of unlawful processing or security breach by the cloud provider.

• The cloud subscriber may also obligate their “end users” to indemnify the cloud subscriber for their actions, and specify when services will be terminated for breaches or misconduct.

Relevance to Cloud Models

IaaS, PaaS, SaaS

9.9 DRIVER: Auditability

Type

Description

This section describes how right of audit, and certifications of the cloud provider should be handled in a contract.

Motivation

• Many cloud obligations require adherence to legal regulations or industry standards.

• As the cloud subscriber is liable for any breaches that occur, it is important that the cloud subscriber is able to audit the cloud provider’s systems and procedures.

• As audits are disruptive and expensive, the cloud provider will look to minimize the frequency and scale of audits, and most likely place charges on them.

Risks If Audit Is Not Considered

Potential risks of not defining and managing how audit is handled are: • Reputation damage.

• Inability to assure the presence, strength and effectiveness of controls. • Financial loss due to unmanaged incidents or breaches.

The cloud contract should clarify the obligations of the cloud provider, with respect to being audited by the cloud subscriber, an independent body, the regulator, or industry body. Some contractual considerations for audits are:

• The contract should specify who has the right to perform and audit. Supervisory authorities have the right to conduct audits on both the cloud subscriber and the cloud provider.

(30)

• The contract may allow the cloud provider to conduct an audit on their information security program. The provider will usually give the audit findings to the cloud subscriber upon receipt of a formal written request.

• The contract should specify the terms and conditions under which the cloud provider will share their own audit reports with a cloud subscriber or regulator.

• The cloud provider will implement any required controls or mitigants identified by the cloud subscriber or information security program audits.

• Where audits are disallowed and no independent third-party audits are conducted or shared with cloud subscribers, cloud subscribers must rely on undertakings by cloud providers regarding security.

• The cloud provider should provide federated reports across the environment and generate adequate auditing information for any likely investigation of the cloud environment.

• The provider should ensure that audit logs are preserved with the standards that are required by regulating bodies.

• The contract should specify which cloud provider personnel have access to audit logs. This must be decided prior to placing cloud subscriber data in the cloud provider environment.

• The provider should ensure all personnel who have access to the audit logs have proper clearances as required by the subscriber.

• Audit transaction records should never be modified or deleted, and only authorized users may be allowed to access audit transaction files.

• Audit and transaction records should be backed up and stored safely off site.

Relevance to Cloud Models

IaaS, PaaS, SaaS

9.10 DRIVER: Description of Services and Service Level Agreements

Type

Description

This section specifies the principles and requirements to define quality service descriptions and service level agreements in a contract. The commercial framework and contract for a cloud arrangement should clearly define how the services in scope will be provided. The framework should also define how the service level agreement should be written to ensure effective and efficient provision of the services. The SLA section within a contract forms the fundamental basis for:

• Service definition • Pricing • Delivery • Monitoring • Billing • Governance

• Remediation and rectification upon non-delivery of agreed services or service qualities. A service-offering item is a product or service that can be ordered from and delivered by the cloud provider.

An SLA defines the interaction between a cloud service provider and a cloud service subscriber, and should be formalized within the master service agreement or a contract.

(31)

Further information on defining and monitoring the security service levels in a cloud contract can be sourced from Procure Secure – a guide to monitoring of security service levels in cloud contracts, developed by the European Network and Information Security Agency (ENISA).5

Motivation

• A significant barrier to cloud uptake is the large variation in the maturity and quality of cloud services and the inability to get enterprise grade service level agreements.

• Governing the level of cloud service is a significant business requirement.

• Failure of service can impact business-critical applications as well as data that is accessed and stored via cloud services. • There are direct and indirect regulations and regulatory expectations that oblige the cloud subscriber to govern services provided

to customers or end users. These regulations are placed on the subscriber whether they provided cloud service internally or contract though a cloud provider. Such regulations exist to protect and safeguard the interests of the end consumer and customers within an industry.

Risks If SLAs Are Not Considered

Potential risks of not defining and managing service levels are:

• Not achieving business benefits from the cloud arrangement. • Negative impact on customer satisfaction.

• Breach of regulatory compliance obligations as defined by regulators and legislation for provisioning services for customers and user community.

Applicability

This driver is applicable to: • All cloud services. • All cloud models.

Service characteristics could be described as throughput, av

OPEN DATA CENTER ALLIANCE Sm Master Usage Model: Commercial framework REV 1.0

Table of Contents

PROPRIETARY NOTICE AND OTHER NOTIFICATIONS

Copyright © 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.

NOTICE TO NON-ODCA PARTICIPANTS

NOTICE TO ODCA PARTICIPANTS

Copyright © 2012 Open Data Center Alliance, Inc. ALL RIGHTS RESERVED.

Acknowledgements

2.0 Framing the Problem

3.0 Scope

Value Proposition Achieved

Influence regulatory and industry

4.0 Value of the Commercial Framework

Actor/Term Description

5.0 Taxonomy

Figure 7.1.1 Construction of the OCDA Master Services Agreement (Generic)

7.1 The ODCA Master Services Agreement (Generic): Introduction

7.2 ODCA Master Services Agreement (Generic): Key Drivers

Table 7.2.1 The Commercial Framework Drivers Influence The Following Types Of Considerations

Consideration Description of the Solution

Table 7.2.2 Master Services Agreement Generic Key Drivers

8.0 Usage Scenarios: Using the Commercial Framework

Figure 8.1.1 How Organization-Specific Context Agreements are Constructed

Figure 8.2.1 How Project-Specific Local Agreements are Constructed

8.4 Usage Scenario: Using the Commercial Framework to Discover Services

Pre-conditions

Scenario steps

8.5 Usage Scenario: Negotiation

8.7 Usage Scenario: Terminate Service

9.0 ODCA Generic Master Services Agreement (MSA)

9.1 DRIVER: Governing Law

Description

Motivation

Assessment and Pre-Contractual Considerations

Contractual Considerations

9.2 DRIVER: Variations to Terms of Service

Description

Assessment and Pre-Contractual Considerations

Relevance to Cloud Models

9.3 DRIVER: Multiple Parties and Sub Contracting

Description

Risks If Sub Contracting and Multiple Parties Are Not Considered

Contractual Considerations

Contract Monitoring Considerations

9.4 DRIVER: Assignment and Divestiture

Description

Risks If Assignment of Contract Is Not Considered

Assessment and Pre-Contractual Considerations

Contractual considerations

9.5 DRIVER: Priority of Documents

Description

Risks If Priority of Contract Documents Is Not Considered

Relevance to Cloud Models

9.6 DRIVER: Intellectual Property

Description

Risks If Intellectual Property Is Not Considered

Contractual Considerations

Contract Monitoring Considerations

9.7 DRIVER: Liability

Description

Assessment and Pre-Contractual Considerations

Relevance to Cloud Models

9.8 DRIVER: Indemnification

Description

Assessment, Pre-Contractual and Contractual Considerations

Relevance to Cloud Models

9.9 DRIVER: Auditability

Description

Risks If Audit Is Not Considered

Relevance to Cloud Models

9.10 DRIVER: Description of Services and Service Level Agreements

Description

Motivation

Risks If SLAs Are Not Considered