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

Transcription

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

2 Table of Contents Proprietary Notice And Other Notifications... 5 Legal Notice... 6 Acknowledgments... 6 Terminology And Provenance Executive Summary Framing The Problem Scope Value Of The Commercial Framework... 9 Table 4.1 Value of the Commercial Framework Taxonomy...10 Table 5.1 Terms and Definitions Commercial Framework - Disclaimer Describing The Commercial Framework The ODCA Master Services Agreement (Generic): Introduction...12 Figure Construction of the ODCA Master Services Agreement (Generic) ODCA Master Services Agreement (Generic): Key Drivers...13 Table Commercial Framework Drivers Influence...13 Figure Master Service Agreement Generic Key Drivers Usage Scenarios: Using The Commercial Framework Usage Scenario: Creating An Organization/Context Specific Master Services Agreement...14 Figure How Organization-Specific Context Agreements are Constructed Usage Scenario: Creating A Project-Specific Master Services/Local Agreement...16 Figure How Project-Specific Local Agreements are Constructed Usage Scenario: Using The Commercial Framework Within Cloud Services Lifecycle...17 Figure Cloud Services Lifecycle Usage Scenario: Using The Commercial Framework To Discover Services Usage Scenario: Negotiation Usage Scenario: Provision, Instantiate, And Use Service Usage Scenario: Terminate Service ODCA Generic Master Services Agreement (MSA) Driver: Governing Law

3 9.2 Driver: Variations To Terms Of Service Driver: Multiple Parties And Sub Contracting Driver: Assignment And Divestiture Driver: Priority Of Documents Driver: Intellectual Property Driver: Liability Driver: Indemnification Driver: Auditability Driver: Description Of Services And Service Level Agreements Driver: Availability Driver: Cost Management Driver: Multi-Tenancy Driver: Privacy Driver: Information Security Driver: Data Ownership Driver: Data Location And Cross Border Data Flow Driver: Monitoring By Cloud Provider Driver: Incident Management Driver: Security Breach Management Driver: Electronic Discovery Driver: Data Sanitization Driver: Record Retention Driver: Portability (Dealing With Cloud Termination) Driver: Software Entitlement Management Relevance To Users Cloud Subscribers, Decision Makers, Procurement Staff and Risk Managers Cloud Providers Technology And Solutions Providers Regulators Cloud Auditors Cloud Brokers And Integrators Other Actors Cloud Standards Bodies

4 11.0 Good Practices For Managing Commercial Agreements Well Formed Business Case And Requirements Business Case Inclusions Well Defined Roles And Responsibilities Across Cloud Subscriber And Cloud Provider Review And Update Commercial Arrangement Knowledge Base of Contracts Summary of Industry Actions Required References

5 PROPRIETARY NOTICE AND OTHER NOTIFICATIONS This ODCA Master Usage Model: Commercial Framework is proprietary to the Open Data Center Alliance, Inc. OPEN DATA CENTER ALLIANCE SM, 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 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 Use of this document by ODCA Participants is also subject to the ODCA s bylaws and its other policies and procedures. 5

6 Legal Notice This Open Data Center Alliance SM 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 ALLIANCE SM, 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 NIST, ENISA (European Network and Information Security Agency) and the Queen Mary University of London School of Law. 6

7 OPEN DATA CENTER ALLIANCE Sm Master USAGE MODEL: Commercial framework REV 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-fromstock 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). 7

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; influence further standardization of services and quality attributes. 8

9 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. Table 4.1: Value of the Commercial Framework Value Proposition Drive efficiency and value, shorten the time to setup commercial relationships Maximize reuse Enforce compliance Influence regulatory and industry change Influence standardization of services and quality attributes Evolution of an enterprise-ready, open cloud marketplace Achieved 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 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. Through the analysis and inclusion of regulatory compliance requirements, as an integral part of the contract, including terms and conditions for monitoring regulatory compliance. Through the articulation of the challenges associated with the complex and diverse regulatory environment Through the definition of levels of service, quality metrics, and assurance terms. Through the cloud providers defining standard compliant solutions and service definitions meeting the commercial framework requirements 9

10 5.0 Taxonomy The standard terms and definitions used in this document are listed below in Table 4.1 Terms Definitions. Table 5.1 Terms and Definitions Actor/Term Cloud Provider Cloud Standards Body Cloud Subscriber Cloud Broker Cloud Federation Cloud-Aware Application Traditional Application Workload Description 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. An entity responsible for setting and maintaining the cloud orchestration standards contemplated in this usage model. A person or organization that has been authenticated to a cloud and maintains a business relationship with a cloud. 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) 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 Applications designed and built with the sole intent of running in a cloud environment. A program or system that has not been specifically designed (or remediated) to transparently leverage the unique capabilities of cloud computing. 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. 10

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 attorneyclient 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. 11

12 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). Figure Construction of the OCDA Master Services Agreement (Generic) Inputs ODCA Master Services Agreement (Generic) Regulatory Obligations [Local, National, International] Industry Standards Business Requirements [primarily non functional requirements] Policy Requirements Generic External Drivers Generic Customer Requirements Generic Supplier Capabilities ODCA Master Services Agreement (Generic) Business and Regulatory Drivers Motivation Risks Mitigated Pre Contractual Considerations Contractual Requirements Monitoring Considerations Sample Clauses 12

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 The Commercial Framework Drivers Influence The Following Types Of Considerations Consideration Cost and Service Trust and Sustainability Data Dealing with issues Baseline details in a contract Description of the Solution Managing service levels and economics of the commercial arrangement. 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 interoperability. Ensuring effective ownership, flow, storage, retention, and return of data. Key considerations to prevent, detect, and respond to issues through the lifecycle of the contract. Defining the governing law, managing the governance and change control, and executing the contract, for all parties involved. 13

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 Master Services Agreement Generic Key Drivers Cost and Service Cost Management Service Levels Availability Multi Tenancy Trust and Sustainability Privacy Intellectual Property Information Security Portability Data Ownership Trans Border Flow Sanitization Record Retention Dealing with Issues Incident Managment Indemnity Breach Management Monitoring Electronic Discovery Auditability Liability Licensing Baseline Details within a Contract Governing Law Assignment Sub Contracting Divestiture Variations to Terms Priority of Documents 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 ODCA Master 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 ODCAsupplied 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 location, sector, and so on. 14

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 providerspecific 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 How Organization-Specific Context Agreements are Constructed Inputs Organization-specific Master Services Agreement (context-specific) ODCA Master Services Agreement (Generic) Customer-specific Business Requirements [functional, non functional, policy, etc.] Customer and Industry-specific Regulatory Requirements Decision Process Organization-specific Master Services Agreement (context-specific) Supplier-specific Capabilities Contract-specific Terms and Conditions 15

16 8.2 Usage Scenario: Creating a Project-Specific Master Services/Local Agreement Once an organization-specific master services/local agreement has been setup, service agreements can be derived from the organizationspecific MSA for service delivery arrangements. Delivery arrangements can also be called project services or statement of work for 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 How Project-Specific Local Agreements are Constructed Inputs Project-specific agreements defined under the umbrella of context-specific MSA Local Agreement 1 Organization-specific Master Services Agreement (context-specific) Local Agreement 2 Local Agreement 3 Local Agreement.. 16

17 8.3 Usage Scenario: Using the Commercial Framework Within Cloud Services Lifecycle The following picture illustrates the cloud services lifecycle. Figure 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 Framework 3 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. Corporate governance requirements for the new or transformed service. 17

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 Privacy 18

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. 19

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 Motivation 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. 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. 20

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. 21

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 This driver is primarily driven by business requirements. 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. 22

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 sub-contractors, the cloud provider should be responsible for identifying the subcontractors. The provider is also responsible for notifying the cloud subscriber prior to changing the agreed 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 Monitor the level of sub-contracting. 23