Cloud Governance, Risk, and Compliance
Domain 1: Cloud Governance, Risk, and Compliance
This domain tests how you convert legal, regulatory, and contractual obligations into cloud controls, then prove them with evidence. Expect questions on control frameworks, shared-responsibility evidence, risk treatment, data residency, and third-party risk.
Core rules
- Governance starts with a control catalog mapped to frameworks such as ISO/IEC 27001, NIST SP 800-53, PCI DSS, and SOC 2. Map once, reuse across audits; avoid duplicate controls.
- A provider's certification does not certify your workload. AWS, Azure, and GCP attestations cover the provider's side of the shared responsibility model; you still own IAM, data classification, encryption choices, and logging.
- Compliance is continuous: use cloud-native evidence (AWS Config, Azure Policy, GCP Asset Inventory) plus manual artifacts for process controls.
- Risk treatment options are accept, mitigate, transfer, avoid. Document residual risk with an owner and review date.
- Data residency and sovereignty constrain region choice, replication, support access, and subprocessors.
Worked example
A payment processor runs on IaaS and must meet PCI DSS. The provider's PCI attestation covers physical security and hypervisor isolation. The customer must still scope the cardholder data environment, restrict IAM, encrypt card data, retain logs, and test segmentation. The correct answer maps each PCI requirement to provider evidence or customer evidence; it does not claim the provider's certificate covers the application.
Traps
- Treating SOC 2 as a certification; it is an attestation report with a scope and period.
- Assuming all provider services inherit the same compliance status.
- Ignoring scope creep from snapshots, backups, and logs that contain card data.
- Presenting a one-time audit as continuous compliance.