14.2 Outsourcing & Cloud Contract Design (Domain 6.5)
Key Takeaways
- Domain 6.5 covers outsourcing and cloud contract design: business requirements (SLA, MSA, SOW), vendor management (assessments, lock-in, viability, escrow), detailed contract management clauses, and supply-chain security (including ISO/IEC 27036 concepts).
- MSA sets master legal terms; SOW defines specific work; SLA defines measurable service levels—security and risk requirements must be explicit across these artifacts, not assumed.
- Vendor management addresses continuous assessment, lock-in and exit, financial/operational viability, and escrow where source or critical dependencies require protection.
- High-value contract clauses include right to audit, metrics and definitions, termination, litigation venue, assurance, compliance, access to cloud/data, cyber insurance, data ownership, and security requirements.
- On CCSP items, choose contract and vendor controls that preserve customer rights (audit, exit, data return) and supply-chain assurance—not handshake deals or pure trust in marketing.
Outsourcing and Cloud Contract Design
Domain 6.5 requires the CCSP to understand outsourcing and cloud contract design. Technical architecture without enforceable agreements leaves security as a hope. Contracts allocate duties, define measurable performance, create audit and exit rights, and set the rules for incident cooperation, data ownership, and liability—within what law allows.
This section tracks the outline: business requirements (SLA, MSA, SOW); vendor management (assessments, lock-in, viability, escrow); contract management (right to audit, metrics, definitions, termination, litigation, assurance, compliance, access to cloud/data, cyber risk insurance, data ownership, security requirements); and supply-chain management (ISO/IEC 27036).
Why Contracts Are Security Controls
In cloud, many “controls” are operated by someone else. Your residual control is often governance + contract + verification.
| Without strong contracts | With intentional contract design |
|---|---|
| Vague “industry standard security” | Specific control requirements, certifications, and encryption expectations |
| No timely breach notice | Processor notice windows that protect legal clocks |
| No audit path | Right to audit / rights to receive SOC reports and penetration summaries |
| Sticky exit | Documented return formats, transition assistance, deletion attestation |
| Unclear ownership | Explicit data ownership and license-to-process language |
| Mystery subprocessors | Flow-down security and notification of subprocessor changes |
Exam principle: When a stem asks how to ensure a CSP will support forensics, deletion, or audit, look for contractual rights negotiated before onboarding, not heroic post-incident improvisation alone.
Business Requirements: SLA, MSA, and SOW
Outsourcing documents come in layers. Know what each is for so security requirements land in the right place.
| Artifact | Purpose | Typical security/risk content |
|---|---|---|
| Master Service Agreement (MSA) | Umbrella legal terms governing the relationship | Liability, indemnities, confidentiality, IP, data protection framework, insurance, dispute resolution, termination framework, audit rights at a high level |
| Statement of Work (SOW) | Specific project or service scope, deliverables, timelines, acceptance | Implementation hardening tasks, migration security gates, professional services access rules, deliverable security criteria |
| Service-Level Agreement (SLA) | Measurable service commitments and remedies | Availability %, support response times, performance metrics, sometimes security operations metrics; service credits |
| Data Processing Agreement / Addendum (DPA) | Privacy-law processing terms (often companion to MSA) | Controller/processor roles, instructions, subprocessors, breach notice, international transfer mechanisms |
| Security exhibit / schedule | Detailed security requirements | Control baselines, encryption, logging, IR cooperation, employee screening, secure development |
SLA Realities for Security Professionals
SLAs historically emphasize availability and support, not confidentiality. A 99.9% uptime SLA does not mean “breach-proof.” Still, SLAs matter for risk:
- Definitions determine whether partial degradation counts as downtime.
- Measurement windows and exclusions (scheduled maintenance, customer-caused outages) change real-world protection.
- Remedies are often service credits—not full consequential damages. Credits rarely equal business loss; treat SLA credits as partial transfer, not complete risk transfer.
- Security SLOs (when negotiated) may include time-to-notify for incidents, vulnerability fix timelines for provider-managed layers, or log delivery latency.
MSA and SOW Interaction
| Pattern | Risk if mishandled |
|---|---|
| Security only in a slide deck, not MSA/exhibits | Unenforceable expectations |
| SOW grants consultants standing prod admin without MSA access controls | Privilege and custody gaps |
| Marketing SLA web page conflicts with signed MSA | Ambiguity; signed terms usually control if drafted that way—verify |
| Order forms silently downgrade security tier | Critical workloads on economy plans without IR or logging features |
Practice: Security architecture decisions (region, tier, support plan, key management option) should be reflected in purchased SKUs and written exhibits, not only in a design workshop.
Vendor Management
Vendor management is the ongoing discipline of selecting, onboarding, monitoring, and exiting cloud and IT suppliers. The outline highlights vendor assessments, vendor lock-in risks, vendor viability, and escrow.
Vendor Assessments
| Assessment type | When used | Outputs |
|---|---|---|
| Inherent risk tiering | Before deep diligence | High/medium/low vendor risk → depth of review |
| Security questionnaire | Onboarding / periodic | Control self-attestation (prefer mapped to CCM or similar) |
| Assurance review | Critical vendors | SOC 2 / ISO certs / pen test summaries / SIG or CAIQ responses |
| Architecture review | High-sensitivity integrations | Data flows, identity model, encryption, admin paths |
| Privacy review | Personal data processing | DPA fitness, transfer tools, retention |
| Financial / operational due diligence | Strategic dependency | Going concern, support capacity |
| Continuous monitoring | Always for critical vendors | Alerts on incidents, cert expiry, material news |
Assessment quality tips: Prefer evidence over unchecked “yes” boxes; validate scope periods; reassess on mergers and product changes; include fourth parties (IdP, payments, CDN) when they are material.
Vendor Lock-In Risks
Lock-in is the difficulty and cost of switching providers or bringing services back in-house.
| Lock-in source | Example | Mitigation themes |
|---|---|---|
| Data format | Proprietary exports, incomplete APIs | Portable formats, regular export tests |
| Identity & integration | Deep custom connectors | Abstraction layers, standards-based federation |
| Skills & ops | Team only knows one platform | Cross-training; multi-cloud patterns where justified |
| Contract term | Auto-renew, punitive exit fees | Negotiate exit assistance and reasonable terms |
| Architecture | Provider-unique services everywhere | Consciously accept lock-in or design portable cores |
| Legal | Data stuck due to dispute | Clear return/deletion and transition clauses |
Lock-in is not always wrong—sometimes unique services create value—but it must be a conscious risk acceptance with an exit sketch, not an accident.
Vendor Viability
Viability asks whether the vendor will remain able to deliver securely over the relationship horizon.
| Signal | Why it matters |
|---|---|
| Financial distress | Cuts to security staff, rushed sales of customer data assets, sudden shutdown |
| Chronic outages / breach pattern | Culture and capacity problems |
| Key-person dependency (small SaaS) | Bus factor on security and ops |
| Geopolitical / sanctions exposure | Sudden service illegality or network isolation |
| Roadmap abandonment | Feature rot on security capabilities you depend on |
Critical workloads need contingency: exportable data, alternative providers identified, or in-house fallback for essential functions.
Escrow
Escrow deposits critical materials (commonly source code, and sometimes keys, build instructions, or configuration) with a trusted third party for release under defined conditions (bankruptcy, material breach, failure to maintain).
| Escrow use case | Cloud relevance |
|---|---|
| Custom software from a vendor | Classic source-code escrow |
| Critical SaaS niche provider | Harder—you may escrow data export packages, IaC, or API specs more than full multi-tenant platform code |
| Key/material custody arrangements | Split knowledge for break-glass scenarios (carefully designed) |
| Documentation & runbooks | Ensure operability if vendor collapses |
Exam note: Escrow is a viability and continuity control, not a substitute for day-to-day access controls. Release conditions and verification that escrow deposits are current matter as much as the idea of escrow itself.
Contract Management: Clauses That Carry Risk
Domain 6.5 lists a dense set of contract management topics. Treat each as a negotiable (or at least reviewable) control point.
Right to Audit
| Approach | Notes |
|---|---|
| On-site / customer audit rights | Often limited in hyperscale contracts; may be replaced by third-party reports |
| Right to receive assurance reports | SOC, ISO certificates, bridge letters |
| Cause-triggered audits | After material incidents or control failures |
| Regulator / customer flow-down | Ability to support your customers’ audit demands if you are a SaaS provider using a CSP |
| Cost and notice | Who pays; how much notice; frequency caps |
If direct audit is impossible, demand transparent assurance and contractual commitments to remediate material findings affecting your environment.
Metrics and Definitions
Ambiguous words destroy enforceability.
| Term needing definition | Why |
|---|---|
| Availability / downtime | Partial outage, login failures, API error rates |
| Security incident / breach | Triggers notice and IR duties |
| Personal data / customer data | Scope of DPA and ownership clauses |
| Business day / response time | Support and notice clocks |
| Force majeure | Whether cyber events are excluded or included |
| Confidential information | What must be protected and returned |
Termination
| Termination theme | Security relevance |
|---|---|
| For cause | Material security breach as trigger |
| For convenience | Exit flexibility vs price |
| Transition assistance | Months of dual-run help, knowledge transfer |
| Data return format & timeline | Machine-readable export, completeness |
| Secure deletion & certification | Crypto-erase / wipe attestation after exit |
| Survival clauses | Confidentiality, liability, audit rights that outlive the term |
Litigation and Dispute
Venue, governing law, arbitration vs courts, and injunctive relief for IP/data misuse affect how quickly you can compel action. Cross-border cloud contracts may pick a governing law that is unfamiliar—legal counsel leads, but security leaders must flag practical enforceability of security promises.
Assurance and Compliance
| Clause theme | Example expectations |
|---|---|
| Maintain certifications | Keep named ISO/SOC scopes current during term |
| Notify of material control changes | Loss of certification, subprocessor swaps |
| Compliance with laws | Privacy, export, sector rules applicable to the service |
| Customer compliance support | Provide artifacts needed for your audits and regulators |
| Prohibited uses | AUP constraints you must operationalize |
Access to Cloud and Data
Ensure the contract supports:
- Administrative access models compatible with least privilege and your IAM federation.
- Data access during disputes (you must not be locked out of your data).
- Assistance for eDiscovery and lawful access processes.
- Clear rules for provider support personnel access (break-glass, logging, customer approval for highly sensitive environments).
Cyber Risk Insurance
| Topic | Practice |
|---|---|
| Vendor insurance requirements | Minimum cyber/liability limits; rated insurers; certificates on request |
| Customer cyber policy | Align with cloud use; notify carriers of material outsourcing |
| Interface of liabilities | Caps, exclusions for unpaid invoices, consequential damage waivers—model residual financial risk |
| Incident cooperation | Insurers may require specific forensics vendors or notice periods |
Insurance transfers financial risk; it does not fix technical debt. Pair with mitigation.
Data Ownership
State clearly that customer data remains customer-owned (or controller-owned as applicable), that the provider receives a limited license to process only to deliver the service, and that provider may not mine customer data for unrelated purposes without lawful basis and agreement. Address derived data, telemetry, and anonymization carefully—marketing claims of “we train AI on your content” can be a risk acceptance decision.
Security Requirements
Security schedules should be specific enough to verify:
| Area | Example requirements |
|---|---|
| Encryption | In transit TLS versions; at rest algorithms; key management options |
| Access control | MFA for privileged provider staff; customer IAM features |
| Logging & monitoring | Log types available; retention; export |
| Vulnerability management | Scanning cadence; severity SLAs for provider-managed layers |
| IR & breach notice | Contact paths; initial notice timelines; cooperation duties |
| BCDR | RTO/RPO targets; test frequency; customer responsibilities |
| Secure development | SDL practices for provider software |
| Personnel | Screening, training, confidentiality |
| Subprocessors | Flow-down; objection rights where feasible |
Negotiation reality: Hyperscale providers offer less custom paper than boutique SaaS. Response strategies include selecting higher security tiers, using customer-managed keys, architectural mitigations, and risk acceptance with monitoring—not inventing impossible “we rewrite their global MSA by Friday” plans.
Supply-Chain Management and ISO/IEC 27036
Cloud services are supply chains of supply chains: hardware, firmware, open-source libraries, colocation, identity providers, payment processors, AI model vendors, and managed security partners. Domain 6.5 points to supply-chain management, with ISO/IEC 27036 as the referenced family for ICT supply-chain security guidance.
Why Supply-Chain Risk Dominates Cloud
| Chain link | Failure example | Downstream impact |
|---|---|---|
| CSP platform | Control-plane defect | Wide customer impact |
| Managed open-source | Compromised package in build image | Malware in many deploys |
| SaaS integration | OAuth app abuse | Data exfiltration without “breaking” encryption at rest |
| Hardware/firmware | Trusted component implant (rare, severe) | Hard-to-detect persistence |
| Professional services | Over-privileged contractor | Insider-path breach |
| Subprocessor | Secondary breach | Your data exposed via party you never assessed directly |
ISO/IEC 27036 (Conceptual Exam View)
ISO/IEC 27036 is a multi-part standard family providing guidance on information security for supplier relationships in ICT. You are not expected to recite every part number on the exam, but you should grasp the intent:
- Security is embedded throughout the supplier lifecycle: planning, selection, agreement, delivery continuity, and termination/transition.
- Both acquirer and supplier have responsibilities; security is mutual, not one-sided.
- Supply-chain security includes product/service integrity, not only traditional “vendor questionnaire” confidentiality.
- Relationships should address risks introduced by suppliers and risks suppliers face that cascade to you.
| Lifecycle stage | Acquirer practices (examples) |
|---|---|
| Plan | Define security requirements, risk tiering, multi-sourcing strategy |
| Select | Due diligence, assurance review, proof-of-concept security tests |
| Agree | MSA/SLA/DPA/security schedule; audit and incident clauses |
| Deliver / operate | Continuous monitoring, access reviews, periodic reassessment |
| Transition / exit | Data return, key revocation, access removal, lessons learned |
Practical Supply-Chain Controls for Cloud Customers
- Inventory dependencies — CSPs, SaaS, libraries, build systems, DNS, certificate authorities, MSSPs.
- Tier by criticality — Depth of assessment follows blast radius.
- Flow-down requirements — Your critical suppliers must manage their suppliers to an agreed bar.
- Technical integrity — Signed images, SBOMs where available, dependency pinning/scanning, provenance in CI/CD.
- Least privilege integrations — OAuth scopes, workload identities, network egress controls to third parties.
- Monitor and respond — Subscribe to advisories; have playbooks for vendor compromise (rotate keys, revoke apps, rebuild).
- Contract for transparency — Subprocessor lists, breach notice, and cooperation clauses.
- Test exit — Periodic restore/export drills prove the chain can be cut if needed.
Integrating 6.4 and 6.5
Enterprise risk management (6.4) identifies scenarios and treatments; outsourcing and contracts (6.5) encode treatments into enforceable relationships. Example chain:
- Risk: SaaS breach exposing customer PII.
- Treatments: mitigate (SSO/MFA, DLP, minimization), transfer (insurance, liability clauses), share (clear controller/processor duties), accept residual with monitoring.
- Contracts: DPA notice timelines, security schedule, audit/assurance rights, deletion on exit, subprocessor controls, cyber insurance minimums.
- Supply chain: assess the SaaS vendor and its critical subprocessors; monitor continuously.
Exam Approach for Domain 6.5
- Map the stem to MSA vs SOW vs SLA (legal umbrella vs project scope vs measurable service levels).
- For vendor risk, consider assessment depth, lock-in, viability, and escrow—not price alone.
- Prefer clauses that preserve audit/assurance, data ownership, IR cooperation, and exit.
- Treat insurance and credits as partial financial tools, not proof of security.
- Extend diligence to the supply chain; ISO/IEC 27036 signals lifecycle supplier security, not a one-time checkbox.
Domain 6.5 rewards professionals who can sit with legal and procurement and turn security architecture into written, testable commitments—the difference between a trusted cloud program and an ungoverned sprawl of click-through terms.
Which statement best distinguishes MSA, SOW, and SLA in cloud outsourcing?
A niche SaaS tool is critical to operations, but the provider is a small company with uncertain long-term viability. Which vendor management approach best addresses this Domain 6.5 concern?
Negotiating a cloud contract for a regulated workload, which package of clauses most directly supports customer security governance?
How should a CCSP apply ISO/IEC 27036 concepts to cloud supply-chain management?
You've completed this section
Continue exploring other exams