Cloud Security Governance and Risk Management
What this domain tests
Cloud Security Governance and Risk Management tests how you set direction, assign accountability, and treat risk when infrastructure is outsourced. Expect questions on policy hierarchy, risk appetite, third-party risk, control inheritance, CSA CCM, ISO/IEC 27017, and NIST RMF/CSF concepts.
Core rules and concepts
- Governance is not the same as security operations: it defines who decides, what is required, and how exceptions are approved and reviewed.
- Maintain a cloud risk register with asset, threat, likelihood, impact, existing controls, treatment, owner, and due date. Risk can be mitigated, avoided, transferred, or accepted; outsourcing operations does not transfer reputational or regulatory accountability.
- Use provider assurance artifacts (SOC 2 Type II, ISO/IEC 27001/27017 reports, pen-test summaries) as evidence, not as proof that your configuration is secure.
- Control inheritance must be mapped: provider controls may cover physical security and hypervisor patching, while customer controls cover IAM, data classification, and workload configuration.
- Define KRIs such as public-storage findings, privileged accounts without MFA, and unresolved critical vulnerabilities; report them to a risk committee.
Worked example
A team stores customer records in object storage and a scanner finds a bucket allowing public read. Likelihood is high because the endpoint is internet-accessible; impact is high because records are personal data. Existing controls include default encryption but no preventive policy. Treat by blocking public ACLs at the organization level, remediating the bucket, and adding a detective alert. The risk owner is the data owner, not the cloud provider. Residual risk is accepted only after evidence and a review date.
Traps that cost marks
- Saying risk is transferred to the provider because a contract exists.
- Treating a provider certificate as covering the customer's workloads.
- Confusing compliance with security; a compliant system can still be compromised.
- Writing policies without owners, exceptions, or review cadence.
- Forgetting subprocessors and fourth parties in vendor risk.