Legal, Risk & Compliance
You outsourced the operation, never the accountability
A bank moves its loan system to a public cloud and assumes the provider now owns the legal and regulatory risk. It does not. Across every cloud responsibility model the customer stays the data owner answerable to regulators, courts, and its own customers, even when someone else runs the metal. That single asymmetry is the organizing idea of this 13% domain (the smallest of the six; Cloud Data Security at 20% is the largest): operation moves out, accountability stays in, so the job becomes winning back through law, contract, and evidence the control you physically gave up. The classic exam trap is the answer that says the provider's certification or SLA discharges your obligation. It never does; it only gives you something to rely on while you remain on the hook. Treat the provider's SOC 2 (Service and Organization Controls, a CPA attestation under AICPA SSAE 18) as evidence you can cite, not as a transfer of your duty.
The domain answers five governance questions in order
Read the subtopics as one chain, each answering the next question a cloud engagement raises. Cloud Legal Requirements & Risks asks what law binds the data: it covers conflicting jurisdictions, the US CLOUD Act versus GDPR Article 48, data sovereignty and localization, and why eDiscovery (the legal collection of electronically stored information) is harder when you do not own the disk. Privacy Issues asks whose data it is: it separates personally identifiable information (PII) from the regulated ceilings of PHI and from contractual versus statutory data, and fixes the cloud customer as GDPR controller and the provider as processor. Cloud Audit Process asks how you prove control without walking the floor: you rely on third-party attestations, so know the SOC 1/2/3 family and Type I versus Type II cold. Enterprise Risk Management asks how much risk you keep: name the four data-handling roles, pick exactly one of five treatments (avoid, mitigate, transfer, share, accept) per risk, inside a declared appetite, using a recognized framework. Outsourcing & Cloud Contracts asks how the deal locks all of it in: MSA, SOW, and SLA, plus right-to-audit, data-ownership, return-and-destruction, and supply-chain clauses under ISO/IEC 27036.
When in doubt, the defensible, documented, law-aligned answer wins
The instinct this domain rewards is governance over improvisation. A risk decision backed by a recognized framework (ISO 31000, the NIST Risk Management Framework, COSO) beats the same decision made on personal judgment, because it is repeatable and auditable. A control you can evidence through a published attestation beats one you merely assert. A contractual right you reserved in writing (to audit, to portability, to data return and certified destruction) beats an assurance given over a call. When an exam answer is technically fine but undocumented, unframeworked, or contract-silent, prefer the option that produces a record a regulator or court would accept.
The five governance questions and the subtopic that answers each
| Governance question | What it decides | Anchor standard or term | Drill into |
|---|---|---|---|
| What law binds this data? | Jurisdiction, sovereignty, localization, eDiscovery exposure | CLOUD Act vs GDPR Art. 48; ISO/IEC 27050 | Cloud Legal Requirements & Risks |
| Whose data is it? | PII vs PHI, contractual vs regulated, controller vs processor | GDPR controller/processor; ISO/IEC 27018 | Privacy Issues |
| How do we prove control? | Reliance on third-party attestations, scope, gap analysis | SOC 1/2/3, Type I vs Type II (SSAE 18) | Cloud Audit Process |
| How much risk do we keep? | Roles, the five treatments, appetite and tolerance | ISO 31000; NIST SP 800-37 RMF | Enterprise Risk Management |
| How does the deal lock it in? | MSA/SOW/SLA, right-to-audit, data return, supply chain | ISO/IEC 27036; SLA per NIST SP 800-47 | Outsourcing & Cloud Contracts |