PECB Lead Cloud Sec common mistakes
PECB Lead Cloud Sec · Understand the traps and how to avoid them.
Treating the cloud shared responsibility model as a single fixed split, and answering scenario questions by assigning all infrastructure controls to the provider and all data controls to the customer regardless of service model (IaaS vs PaaS vs SaaS).
Candidates memorize one diagram of the shared responsibility model and reuse it verbatim. In reality the split moves with the service model and with specific control areas such as host and guest OS patching, network controls, and identity management, so a memorized split produces wrong answers on scenario items.
What to do instead
Build a matrix of IaaS, PaaS, and SaaS against control areas (physical, hypervisor, guest OS, runtime, application, data, identity, network) and rehearse where the boundary shifts for each. For every scenario question, first identify the service and deployment model, then derive the split rather than recalling one.
Confusing cloud deployment models with service models, for example calling a private cloud a service model or describing a community cloud as a type of IaaS.
The terms are often used loosely in vendor material, and candidates learn them from marketing pages rather than from the definitions in ISO/IEC 17788 and ISO/IEC 17789, where deployment model and service model are separate dimensions.
What to do instead
Study the ISO/IEC 17788 vocabulary deliberately: service models (IaaS, PaaS, SaaS) and deployment models (public, private, community, hybrid) are orthogonal. Practice classifying short scenarios on both axes simultaneously and note the essential characteristics (on-demand self-service, broad network access, multi-tenancy, rapid elasticity, measured service) that distinguish cloud from traditional hosting.
Writing a cloud security policy that restates the existing on-premises policy with the word 'cloud' inserted, without addressing cloud-specific commitments such as provider due diligence, data location, sub-processor notification, exit and portability, or the division of controls with the provider.
Candidates under time pressure reuse familiar policy structures and treat cloud as a delivery detail. They also underestimate that a cloud policy must anchor the provider relationship, because many controls are delegated and cannot be verified directly.
What to do instead
Draft a policy skeleton with mandatory cloud-specific clauses: scope and definitions, provider selection and due diligence, shared responsibility and control allocation, data classification and location, sub-processor management, access and identity, logging and monitoring obligations, incident notification timelines, exit strategy and data return, and review cycle. For exam questions, check whether a proposed policy clause is verifiable and enforceable against a provider.
Treating documented information as a one-off deliverable, so answers assume that producing a policy, a risk assessment, or a statement of applicability once satisfies the requirement, ignoring version control, approval, distribution, retention, and review triggers.
Candidates focus on content and forget that ISO management system standards require control of documented information: identification, format, review and approval, availability, and protection. Cloud adds version churn because provider terms and service features change frequently.
What to do instead
Learn the control-of-documented-information requirements as a checklist (identification, format and media, review and approval for suitability and adequacy, availability and protection, retention and disposition, change control, access). Apply it to cloud artifacts specifically: provider contracts, security annexes, risk registers, control matrices, and evidence of monitoring. In questions, prefer answers that include review triggers tied to provider changes.
Performing a cloud risk assessment that lists only technical threats and omits provider-related and contractual risk, such as provider insolvency, service termination, sub-processor concentration, jurisdiction and legal access, loss of control over data, and lock-in.
Candidates carry over an on-premises threat list and do not extend the asset and threat model to include the provider as a dependency. They also forget that likelihood and impact change in multi-tenant environments, for example through shared-fate and concentration risk.
What to do instead
Extend the risk methodology with a cloud-specific risk taxonomy covering availability and exit, confidentiality and multi-tenancy, integrity and change management, compliance and jurisdiction, supply chain and sub-processors, and lock-in and portability. For each scenario, ask what the organization no longer controls directly and whether a compensating control or contractual commitment exists.
Applying a risk treatment as if the organization owns the control, for example accepting 'the provider patches the hypervisor' as a treatment without recording who verifies it, how it is evidenced, and what the residual risk is when the provider's assurance is weak.
The shared responsibility model makes it tempting to treat delegated controls as closed. Candidates forget that delegation does not transfer accountability, and that residual risk must still be assessed against the organization's own risk criteria.
What to do instead
For every treatment, record control ownership, the evidence source (provider attestation report, contractual commitment, independent audit), the verification frequency, and the residual risk. Practice distinguishing controls the organization operates, controls the provider operates with customer evidence obligations, and controls that are shared.
Mixing up the focus of ISO/IEC 27017 and ISO/IEC 27018, for example citing ISO/IEC 27018 as the source for multi-tenancy and virtual machine hardening, or ISO/IEC 27017 as the source for personally identifiable information processor obligations.
Both are cloud extensions of ISO/IEC 27002 and share a clause structure, so candidates learn them as a pair and blur their scopes. The titles are similar and the additional guidance clauses are easy to conflate.
What to do instead
Anchor each standard with one sentence: ISO/IEC 27017 gives cloud-specific guidance on information security controls for cloud service providers and customers, including shared roles, multi-tenancy, virtual environment hardening, and service monitoring; ISO/IEC 27018 focuses on protecting personally identifiable information in public clouds acting as PII processors. Then map each control you study to the correct standard and note whether it is customer-side, provider-side, or both.
Answering ISO/IEC 27017 questions by naming controls without stating the role split, so the answer does not say whether the cloud service customer or the cloud service provider is responsible for the control and what the other party must do.
Candidates learn control names and forget that the distinguishing feature of the cloud controls guidance is the explicit allocation of responsibilities between customer and provider, plus the need for documented agreements covering that allocation.
What to do instead
For each cloud-specific control, memorize three elements: the control objective, the customer responsibility, and the provider responsibility, plus the agreement mechanism that records the split. When answering, explicitly state the allocation and the evidence or contractual clause that supports it.
Designing cloud security awareness and training as a single generic module for all staff, without role-specific content for cloud administrators, developers, and procurement or legal staff who negotiate provider contracts.
Candidates reuse a standard security awareness program and treat cloud as a topic rather than a set of distinct roles. The result misses the highest-risk behaviors, such as developers misconfiguring storage permissions or procurement staff accepting default provider terms.
What to do instead
Define a role matrix: all staff, cloud service consumers, cloud administrators and engineers, developers and DevOps, procurement and legal, and management. Assign each role the cloud-specific behaviors and decisions it owns, and specify how competence is evidenced (training records, certification, practical assessment). In exam scenarios, match the training intervention to the role and the specific risky behavior.
Describing cloud incident management as a purely internal process, omitting provider notification obligations, joint investigation, evidence acquisition across provider boundaries, and the contractual timelines that govern them.
Candidates apply the familiar internal incident process and forget that in cloud the organization may not have direct access to logs, hypervisor telemetry, or physical evidence, and that the provider is a necessary party to detection, containment, and forensics.
What to do instead
Extend the incident process with cloud-specific elements: provider contact and escalation paths, notification timelines and content requirements in both directions, log and evidence access arrangements agreed in advance, jurisdiction and law enforcement considerations, and communication with affected customers where the organization is itself a processor. Practice scenarios where the provider detects first and where the customer detects first.
Treating cloud security testing and monitoring as a provider responsibility only, and answering questions about assurance without mentioning customer-side monitoring of configuration, identity and access, logging, and provider attestation review.
Delegation of infrastructure controls leads candidates to conclude that assurance is also delegated. They overlook customer-operated controls such as identity and access management, configuration baselines, and the use of provider-native monitoring and audit logs.
What to do instead
Separate assurance into provider-side evidence (attestation reports, certifications, penetration test summaries, service level reporting) and customer-side activities (configuration and posture monitoring, log collection and review, access reviews, vulnerability management for customer-managed components, and periodic review of provider assurance). For each monitoring question, state which party produces the data and which party must review it.
Describing continual improvement as an annual management review alone, without linking nonconformities, monitoring results, provider changes, and incident lessons to corrective action and measurable improvement objectives.
Candidates reduce continual improvement to a single review meeting and miss the cycle of measurement, analysis, corrective action, and verification. In cloud, frequent provider service changes and new features create a steady stream of improvement triggers that a yearly review cannot capture.
What to do instead
Map the improvement cycle explicitly: what is measured (control effectiveness, incident metrics, provider performance, audit findings), how often, who analyzes it, how corrective actions are tracked to closure, and how effectiveness is verified. Include triggers such as provider feature changes, new sub-processors, audit findings, and incident post-mortems, and show how each feeds the risk assessment and the documented information.