Cloud Security, Risk and Compliance
The Cloud Security, Risk and Compliance domain tests whether you can place controls correctly across the shared responsibility model and evidence compliance. Questions typically describe a service and ask who owns a control, or which standard or legal obligation applies.
Shared responsibility
The provider is responsible for security of the cloud; the consumer for security in the cloud. The boundary moves with the service model. In IaaS the consumer patches the OS and secures the workload; in PaaS it secures code, configuration and identities; in SaaS it secures users, access rights, data classification and the settings it chooses.
Core control areas
- Identity and access management: least privilege, federation, multi-factor authentication, joiner-mover-leaver processes.
- Data protection: classification, encryption in transit and at rest, and control of keys. Customer-managed keys can change key control and access policy, but do not by themselves prove that a provider or workload can never decrypt data.
- Residency and jurisdiction: where data and metadata are stored, and which laws reach them.
- Assurance: ISO/IEC 27001 for an information security management system, ISO/IEC 27017 for cloud-specific controls, ISO/IEC 27018 for protecting PII in public clouds acting as PII processors, SOC 2 reports and the CSA STAR registry.
Legal position
Identify the applicable legal roles, contracts and data requirements for the actual service. Outsourcing processing does not by itself discharge the customer’s own obligations. Provider certifications describe a defined scope and period; inspect what services and controls they cover and what remains for the customer. No particular national contract clause, breach deadline or transfer permission is invented here.
Worked example
A company buys a SaaS HR system holding EU employee data. Who secures what? Reasoning: the provider secures the application, the underlying infrastructure and its own personnel. The company decides which data may be entered, configures roles so managers see only their team, reviews access quarterly, sets retention and answers employee requests. Encryption responsibilities depend on the actual service: some protections are enabled by default, while customers still choose relevant configuration, key policy, permissions and data classification. Inspect the documented boundary rather than assuming every encryption feature is optional.
Traps that cost marks
- Assuming the provider is responsible for everything once data is in the cloud.
- Believing encryption removes accountability - key ownership decides who is really protected.
- Treating a provider's ISO/IEC 27001 certificate as proof that your own use of the service is compliant.
- Confusing ISO/IEC 27017 with ISO/IEC 27018.
- Forgetting audit rights, breach notification timelines and data deletion at exit.