Cloud Compliance, Risk and Vendor Management
This domain tests how you consume a vendor's assurance evidence, translate it into your own risk position, and keep it current.
Evidence types are not interchangeable
A certification is issued by an accredited body (ISO/IEC 27001, 27017, 27018). An attestation is an independent auditor's report on controls: SOC 1 for financial reporting, SOC 2 for security, availability, confidentiality, SOC 3 as a public summary. A self-assessment is a questionnaire the vendor completes, such as the CSA CAIQ against the Cloud Controls Matrix. Regulated programs - FedRAMP, PCI DSS, HIPAA - impose obligations a generic SOC 2 does not satisfy. The exam rewards knowing the difference.
Vendor risk lifecycle
Scope the service, classify the data, tier the vendor by criticality, request evidence, review it, record residual risk, contract the controls evidence cannot supply (breach notification timelines, subprocessor approval, data return and deletion, audit rights), then monitor continuously - a SOC 2 Type II covers a past period, not today.
Worked example
A SaaS vendor supplies a SOC 2 Type II. The analyst checks whether the scope covers the exact service and region being purchased, whether the period covers the last twelve months, whether there are qualifications or exceptions, which complementary user entity controls (CUECs) are listed, and whether subservice organizations were carved out. Reasoning: the report describes the vendor's controls, not your compliance, and the CUEC list is effectively your to-do list - for example, enforcing MFA on your own tenant.
Traps
Treating SOC 2 as a certification. Skipping the CUECs. Assuming a FedRAMP authorization covers your agency's specific requirements. Accepting "right to audit" language that is never exercised. Missing subprocessor chains and unverified data deletion.