CCSP Outsourcing and Cloud Contract Design: SLA, MSA, SOW, Escrow and ISO/IEC 27036

A cloud or outsourcing contract is usually a stack of documents, each with one job. The master service agreement (MSA) holds the standing legal terms for the whole relationship; each statement of work (SOW) defines one engagement; the service-level agreement (SLA) states measurable service commitments and the remedies when they are missed. Together they turn the business's requirements into terms the provider is bound by.

A memorandum of understanding, by contrast, records an intention to cooperate and is usually not a binding definition of paid deliverables.

Order of precedence

Documents drafted by different teams conflict: a SOW might make data-loss liability uncapped while the MSA caps all liability. Do not rely on the general interpretive idea that specific terms beat general ones; a court may not apply it, and the MSA may say its caps override everything. An order-of-precedence clause, normally in the MSA, ranks the documents (and can allow a SOW to override a named MSA term expressly), so both parties know which term wins before a dispute arises.

Documents incorporated by reference

Providers often incorporate their online SLA, acceptable use policy or security policy by linking to a web page. If the contract incorporates the document "as updated from time to time", the provider can lower its commitments unilaterally mid-term. A commitment is only as stable as the text it points to, so protective drafting freezes the referenced document as it stood when the contract was executed for the life of the term, or permits later edits only where they leave the customer's protection intact.

Definitions decide what the provider actually owes. Any obligation that turns on an undefined term, such as "security incident", "availability", "response" or "scheduled maintenance", lets the provider interpret it in its own favour. When the parties disagree about what an obligation covers, settle the definition first: any timing commitment or penalty built on an undefined term is only as strong as the provider's reading of that term.

• Security incident: state whether suspected as well as confirmed events count, and which systems and data are in scope.
• Response: an automated acknowledgement can satisfy a "15-minute response" while no engineer looks at the problem for hours. If what matters is human engagement, tie the definition to that event, for example the moment a competent person begins diagnosing the fault, rather than to any message being sent.
• Availability: define what counts as down, how it is measured and what is excluded (planned maintenance windows, customer-caused outages). The availability calculation itself is covered with SLA design in Domain 1 and operations in Domain 5.

Metrics should measure the outcome you care about

A metric is only useful if it tracks the business outcome the service exists for. For an outsourced backup service, "backup jobs completed" says little about whether the business can recover; a metric such as successful test restores within the agreed recovery time measures the outcome the service exists for. Apply the same test to any outsourced function: start from the harm the business wants to avoid and measure the service against that. Every metric needs a stated measurement method, a data source, a reporting frequency and a consequence when it is missed. Activity counts (staff assigned, tickets closed) measure effort, not results.

Vendor assessment is due diligence on a provider's security, compliance and resilience, done before the contract is signed and repeated through the relationship. Its depth should be proportionate to the data and the business process the vendor will touch. The order matters: contract terms, risk decisions and remedies are all written from what the assessment finds, so understanding the risk a provider brings comes before negotiating how to manage it, even when a service has been picked informally.

Common inputs

• Security questionnaires (for example, built on the CSA Cloud Controls Matrix and its CAIQ questionnaire).
• Independent attestations and certifications: SOC 2 Type II reports, ISO/IEC 27001 certificates (and their statement of applicability and scope), CSA STAR entries, PCI DSS Attestations of Compliance.
• Financial and ownership information (see vendor viability), subcontractor lists and data locations.
• For AI service providers, how customer data is used for training and what security and ethical controls apply to the models.

Read the report, not just its name

A SOC 2 Type I report describes control design at a point in time; a Type II report also tests whether controls operated effectively over a period. Either way, its value depends on its opinion and scope. A qualified opinion means that, in some area, controls were not suitably designed or did not operate effectively, or the auditor could not obtain enough evidence, so obtain the provider's response and remediation plan. Under the carve-out method, a subservice organisation's controls (such as the infrastructure provider hosting a SaaS platform) are excluded from the report, so assurance over that organisation must come from its own report. A SOC 3 report has the same scope as the SOC 2 it summarises, and an ISO/IEC 27001 certificate does not answer either issue. A bridge (gap) letter covers the months since a report's period ended, but it is a statement by the provider's own management, not independent evidence.

Tier vendors by risk

Applying the same depth of review to every supplier either wastes effort on low-impact vendors or under-assesses critical ones. Risk-based tiering sets assessment depth by impact criteria, the sensitivity of the data the vendor handles and the criticality of the service, because those decide how much harm a failure could do: detailed review and evidence for the top tier, lighter review for the rest, and reassessment when a vendor's access or role changes.

These are three distinct vendor-management risks and controls. Vendor lock-in is dependence on a provider's proprietary services, data formats or interfaces that makes moving elsewhere impractical or very expensive. Vendor viability is the risk that the provider fails, is acquired or stops supporting the service. Escrow places material with a neutral agent to be released on defined events.

Data portability is not the same as no lock-in

Portability terms, a right to extract everything in a non-proprietary, well-specified form, address the data side of lock-in. But data export solves only the data. If the workload depends on proprietary serverless functions, workflow engines or managed machine-learning APIs, the application logic must still be rebuilt on another platform. Judge any proposed lock-in control by one test: does it lower what it would cost to move?

Viability: plan for failure and for change of control

For a critical service from a small or private provider, assess financial stability (audited accounts, funding, customer base) and agree an exit plan. Insolvency is not the only risk: ownership can pass to a party the customer does not want to depend on, such as a rival or an owner subject to an unwelcome jurisdiction. A change-of-control clause gives a right to terminate and recover data when ownership changes. The remedy should fit the event: after an unwelcome takeover the customer's need is a clean, timely exit with its data.

Escrow: what it holds and when it helps

Software (source code) escrow is a three-party agreement in which an independent agent holds the vendor's source code and releases it to the customer on defined triggers, typically insolvency, cessation of business or end of support. It is not cryptographic key escrow (third-party custody of keys) and not a perpetual licence. For SaaS, code alone is rarely enough: a useful deposit also includes build scripts, deployment and configuration material, documentation and sometimes the customer's data. Two properties make escrow work:

• Current deposits: the deposit is updated regularly as the product changes, not made once at signing.
• Verification: the agent or an independent tester builds the deposit to confirm it produces the working product. Verification is not a vulnerability review and does not test the legal enforceability of triggers.

Escrow only helps a customer able to build and run the software. An organisation that cannot operate software itself is better served by continuity planning built around current, portable copies of its data and a rehearsed switch to another provider.

A right to audit lets the customer (or its regulator) inspect a provider's controls; in public cloud it is usually replaced or narrowed by independent assurance. Large multitenant providers refuse individual on-site inspections because thousands of customer audits would disrupt shared facilities and expose other tenants. The usual compromise is a contractual right to receive current attestation reports and certifications (SOC 2 Type II, ISO/IEC 27001, CSA STAR) and to ask follow-up questions. The aim is evidence that controls work, obtained in a form the provider's operating model can support.

Regulated customers

Financial-services and other regulators often require that both the firm and the regulator can access and audit providers of critical outsourced services. Published reports alone do not meet that requirement. Firms negotiate a regulatory addendum granting access and audit rights for the customer and its regulator, and exercise them efficiently through pooled audits, where several customers jointly appoint auditors, respecting the provider's multitenant constraints.

Assurance when you need it, not just annually

Attestation reports look backwards over a fixed period, and an annual audit on long notice cannot respond to an incident. A triggered audit right (on a security incident, a regulator request or a material control failure) produces timely, independent evidence. Typical triggers are worth listing explicitly so neither party argues later about whether one has occurred. How audits are planned and performed is covered in sub-domain 6.3; here the question is what the contract must secure.

Termination terms decide when each party may end the contract and what happens to the customer's service and data when it does. The main types differ in whether a reason is needed:

Suspension and access to data during disputes

Provider terms often allow immediate suspension or termination for any unpaid invoice. The customer's main risk is being locked out of its data during a billing dispute. Protective drafting requires advance warning and an opportunity to put things right before any suspension, and keeps the service and data available while a charge is contested in good faith.

Exit: transition, return and deletion

• Transition assistance: where the provider's standard retention after termination is shorter than a realistic migration, the contract needs continued service and data access for a defined transition period, plus help with export.
• Data return: format, completeness and timing of the final export.
• Deletion: deletion of all copies, including backups and replicas, by a set date, with a certificate of deletion. How the data is actually sanitised is covered with data security in Domain 2.

The customer should own its content and anything derived from it, and the contract should limit the provider's use of that data to providing the service. Draft SaaS terms often allow the provider to use "customer content and usage data" to improve its services, including training machine-learning models or building commercial products from it. The question is what the provider is permitted to do with the data, and only a data ownership and use clause answers it.

The definition decides what is protected

Use restrictions apply only to what the contract defines as customer data. If "customer data" means only files users upload, the provider can still use event records, telemetry and metadata, which may reveal user behaviour. Negotiate the definition first, so it covers logs, metadata, configuration and derived data, and then the use limits and deletion terms that depend on it. Anonymisation requirements and deletion at exit come after the scope is right. With AI services in particular, check whether prompts, outputs and fine-tuning data are within the definition and excluded from model training.

These clauses decide who pays when something goes wrong and where disputes are settled.

Disputes: law, forum and arbitration

• Governing law (choice of law) decides which country's law interprets the contract; it does not decide where the dispute is heard.
• Jurisdiction (forum) names the courts that hear disputes; a national court judgment can be hard to enforce in another country.
• Binding arbitration under named international rules is private, decided by arbitrators chosen for their expertise, and its awards are enforceable in most countries under the 1958 New York Convention. It suits a cross-border relationship wanting confidentiality and enforceability.
• Mediation uses a neutral third party to help the parties agree; it does not impose a binding decision.

Limitation of liability and indemnification

Providers cap liability (often at twelve months of fees) and exclude indirect and consequential loss. The likely costs of a provider-caused data breach, regulatory fines, notification costs and client claims, could be classed as indirect and fall outside the cap entirely. The protective term is a separate, higher super-cap for data breaches that names those costs as recoverable direct losses. Because the problem is how the losses are classified as well as how much is recoverable, the fix has to address both. An indemnification clause requires one party to pay the costs of specified third-party claims against the other, the classic example being intellectual-property infringement claims over the provider's software; it is not the same as a liability cap or a warranty disclaimer.

Cyber risk insurance

Insurance transfers part of the financial risk, but only if the policy responds to the loss in question.

Before a customer relies on its own policy for provider failures, confirm first that the policy covers incidents at third-party providers at all. A short outage can cause real losses yet fall entirely inside the waiting period, so the claim pays nothing. When the customer requires the provider to be insured, what matters is the provider's ability to pay claims the customer brings, so the useful requirement is liability cover sized to the customer's potential loss, with ongoing evidence that it remains in place (periodic certificates, advance notice of cancellation) and, often, additional-insured status for the customer.

Outsourcing transfers the work, not the customer's accountability, so the contract must pass the customer's legal, regulatory and security obligations on to the provider in specific, testable terms. "Industry-standard security" commits the provider to almost nothing.

• Breach notification: when the customer must report breaches to a regulator within a fixed deadline and the provider will usually detect them first, the provider must notify the customer well inside that deadline. The customer, as the regulated party or controller, makes the regulatory report; a provider reporting directly to the regulator does not meet the customer's duty.
• Data location: a localisation requirement covers primary data, backups, replicas and remote access by support staff. Copies and access paths multiply inside a provider's operations, so the binding commitment has to be contractual and cover every copy and every route by which staff can reach the data, with advance notice before anything moves.
• Regulatory cooperation: provider support for regulator inquiries, audits and eDiscovery requests.
• Security control obligations: named controls or frameworks, vulnerability management, encryption and key management responsibilities, personnel screening and incident response commitments.

PCI DSS and third-party service providers

PCI DSS requires an entity using third-party service providers (TPSPs) to keep a list of them (Requirement 12.8.1) and written agreements in which each TPSP acknowledges its responsibility for the security of the account data it handles (Requirement 12.8.2), to know which requirements each TPSP manages and which the entity keeps (12.8.5), and to monitor each TPSP's compliance status at least annually (12.8.4). A provider's Attestation of Compliance is evidence for that monitoring; it does not allocate responsibilities in the contract. TPSPs, in turn, must give their customers that written acknowledgment (12.9.1).

ISO/IEC 27036 is the multi-part international standard on information security for supplier relationships. It helps acquirers and suppliers manage the security risks that arise when one organisation depends on another's products or services, including the chain of suppliers behind a direct provider.

Keep it distinct from neighbours: ISO/IEC 27017 gives cloud-specific information security controls, ISO/IEC 27018 protects PII in public clouds acting as processors, and ISO/IEC 20000-1 is IT service management.

Subcontractors and fourth parties

A SaaS provider typically relies on a hosting provider, data centre operators and support firms, some of whom can reach customer data, while the customer's contract binds only the SaaS provider. The supplier-relationship approach is flow-down: the provider must impose equivalent security duties on each subcontractor, disclose who they are (and notify changes), and remain responsible for them. The customer's leverage runs through its direct provider, so the obligations must too, and the provider's reporting should show how it oversees each link.