Legal, Risk and Compliance
Obligations and their sources
These questions ask you to map obligations to controls. Know the shape of major regimes: GDPR (controller/processor roles, lawful basis, data subject rights, breach notification, transfer mechanisms), HIPAA (covered entity/business associate, BAA), PCI DSS (cardholder data scope, shared responsibility with the provider), SOX (financial-reporting controls), and sector privacy laws. Data residency and sovereignty rules may forbid storage or even access from certain jurisdictions.
Assurance evidence
Distinguish SOC reports: SOC 1 covers financial-reporting controls; SOC 2 covers security, availability, confidentiality, processing integrity, and privacy (Type I = point in time, Type II = a period); SOC 3 is a public seal with no detailed control description. ISO/IEC 27001 certifies a management system; CSA STAR layers cloud-specific criteria. The 'right to audit' is usually satisfied by accepting these reports - providers rarely grant on-site audit rights, and demanding it is often the wrong answer.
Risk management
Identify assets and threats, assess likelihood and impact (qualitative or quantitative), treat (mitigate, transfer, avoid, accept), then monitor. Contracts carry risk too: SLAs, data ownership, exit and portability, subcontractor chains, and notification timelines.
Worked example
A customer wants to store EU personal data in a US region. GDPR does not ban it, but the transfer needs a valid mechanism (adequacy decision, SCCs, or BCRs) plus a transfer impact assessment, and the provider's data-processing addendum must name subprocessors and breach notification windows.
Trap: treating the provider's certification as your own compliance. Certification is evidence about the provider's controls, not a transfer of your obligations. The customer remains accountable to regulators and data subjects.