ISC2 Certified Cloud Security Professional (CCSP): The Security Cert That Proves You Can Govern, Architect, and Protect the Cloud

Domain 1 — Cloud Concepts, Architecture and Design (17%)

The foundational domain. Know the NIST SP 800-145 service model taxonomy: IaaS (physical resources abstracted, customer controls OS and above), PaaS (OS and middleware managed, customer controls application and data), SaaS (entire stack managed, customer controls configuration and data access). Know the four NIST deployment models: public (multi-tenant, provider-owned), private (single-tenant, organisation-controlled), community (shared by organisations with common concerns — regulated industries, government), and hybrid (two or more deployment models interconnected for data and application portability).

The Shared Responsibility Model shifts control upward with each service tier. In IaaS, the provider secures physical infrastructure and the hypervisor — the customer owns everything above. In SaaS, the provider handles nearly the full stack. The exam tests whether you can draw this boundary correctly for a given scenario, and identify which party is liable when a control gap exists on one side of that boundary.

Virtualisation security: hypervisor types (Type 1 bare-metal — VMware ESXi, Microsoft Hyper-V; Type 2 hosted — VirtualBox, Parallels), VM escape (an attack where a VM process breaks out to the hypervisor layer — the primary hypervisor threat vector), VM sprawl (uncontrolled VM proliferation that evades change management and patch cycles), and snapshot security (snapshots include memory state and may contain credentials or decryption keys — careless retention creates compliance and data exposure risk). Containers share the host kernel — lighter but with a larger shared attack surface. VM isolation is stronger; container density is higher. The exam expects you to weigh this trade-off by workload sensitivity.

Domain 2 — Cloud Data Security (20%)

The heaviest domain and the most distinctive CCSP content. The cloud data lifecycle has six phases: Create, Store, Use, Share, Archive, Destroy. The exam maps security controls to each phase — for example, DLP and encryption at Store, access control and activity monitoring at Use, and cryptographic erasure or certificate destruction at Destroy. Know data classification levels (Public, Internal, Confidential, Restricted) and how classification drives control requirements and data handling obligations.

Encryption in transit and at rest: TLS 1.2/1.3 for data in transit (TLS 1.0 and 1.1 are deprecated; mutual TLS (mTLS) requires both parties to present certificates — used for service-to-service authentication in microservices). AES-256 for data at rest. Key management is the domain’s hardest topic. Know the three cloud key ownership models: Provider-Managed Keys (provider controls the full key lifecycle), Bring Your Own Key (BYOK — customer generates and imports the master key, provider manages operations), and Hold Your Own Key (HYOK / Customer-Managed Keys — customer retains the root key and the provider never sees it). Hardware Security Modules (HSMs) provide tamper-resistant key storage — FIPS 140-2 Level 3 or higher for government and financial-sector requirements (AWS CloudHSM, Azure Dedicated HSM, GCP Cloud HSM).

Cloud Access Security Brokers (CASBs) enforce DLP, access control, and visibility between users and cloud applications. Deployment modes: API mode (out-of-band, for sanctioned SaaS apps with APIs — discovers data at rest, enforces policies post-upload), forward proxy mode (intercepts traffic from unmanaged or BYOD devices), and reverse proxy mode (intercepts traffic to managed SaaS apps from managed devices — inline enforcement without agent installation). Data residency and sovereignty: data physically stored in an EU region is subject to GDPR regardless of the data subject’s nationality; US-headquartered providers may be subject to CLOUD Act compelled disclosure orders for data stored outside the US; Standard Contractual Clauses (SCCs) are the legal mechanism for lawful EU-to-third-country transfers post-Schrems II.

Domain 3 — Cloud Platform and Infrastructure Security (17%)

The shared responsibility boundary for physical security means the customer has zero access to and zero responsibility for the provider’s data centre physical controls (badge access, CCTV, environmental). What the customer gets instead are third-party audit attestations: SOC 2 Type II (operational effectiveness of controls over a defined period — typically 6 or 12 months), ISO 27001 (ISMS implementation and risk management), PCI DSS (payment card environment requirements), and FedRAMP (US government cloud security authorisation at Low, Moderate, or High impact levels). The exam tests which audit report type is appropriate for which compliance question.

Cloud network security: Virtual Private Cloud (VPC) for logically isolated network segments. Security Groups are stateful (connection tracking allows return traffic automatically) and apply to individual resources. Network ACLs are stateless (must explicitly allow inbound AND outbound, evaluated in numbered rule order) and apply to subnets. Microsegmentation applies controls at the workload level rather than the network perimeter — security groups, Kubernetes NetworkPolicy, or service mesh (Istio, Linkerd with mTLS between all pods). Zero Trust Network Access (ZTNA) replaces the VPN perimeter model: every access request is authenticated and authorised based on identity, device health, and context, with no implicit trust from network location. The three Zero Trust principles: verify explicitly, use least-privilege access, and assume breach.

Penetration testing rules of engagement: AWS, Azure, and GCP all publish customer authorisation policies permitting testing of customer-owned assets. Testing provider-owned shared infrastructure — hypervisors, physical network equipment, multi-tenant data centre components — is prohibited. Know the difference between a vulnerability scan (automated enumeration of potential weaknesses) and a penetration test (active exploitation of discovered weaknesses under controlled conditions), and between both and a red team exercise (full-scope adversary simulation including physical and social engineering).

Domain 4 — Cloud Application Security (17%)

Secure SDLC in cloud environments: SAST (Static Application Security Testing — source code analysis, runs pre-deployment, detects injection vulnerabilities, hardcoded credentials, insecure APIs), DAST (Dynamic Application Security Testing — running application analysis, detects authentication bypass, misconfigurations, injection in runtime), and IAST (Interactive AST — instruments the running application from within, combining SAST and DAST coverage). Software Composition Analysis (SCA) for open-source dependency vulnerability detection and SBOM (Software Bill of Materials) generation — both are explicitly in scope for cloud supply chain security questions. The OWASP Top 10 and the OWASP API Security Top 10 are testable: injection, broken authentication, sensitive data exposure, XXE, broken access control, security misconfiguration, XSS, insecure deserialization, vulnerable components, and insufficient logging.

Identity and access management for cloud applications: OAuth 2.0 (authorisation framework — grants third-party apps scoped access to an HTTP service without exposing credentials; the client receives a short-lived access token), OpenID Connect (OIDC adds an authentication layer on top of OAuth 2.0 — provides an ID token with user identity claims in JWT format), and SAML 2.0 (XML-based standard for enterprise SSO — used in federated identity scenarios between an identity provider and service providers). The exam tests which protocol is appropriate for a given scenario: SAML for enterprise federation, OIDC for modern app authentication, OAuth 2.0 for API authorisation delegation. Serverless security: least-privilege execution roles (no wildcard permissions on Lambda or Azure Functions), secure environment variable management (use Secrets Manager or Key Vault, not plaintext environment variables), and dependency pinning to prevent supply chain substitution attacks.

Domain 5 — Cloud Security Operations (16%)

Cloud SOC fundamentals. SIEM collection from cloud-native audit sources: AWS CloudTrail (API-level activity across all services — management events and data events), Azure Monitor / Entra ID Sign-in logs, GCP Cloud Audit Logs (Admin Activity, Data Access, System Event, Policy Denied). Immutable logging is a CCSP requirement: CloudTrail log file integrity validation uses SHA-256 hashing and RSA digital signatures to detect tampering. Centralise logs from all accounts into a dedicated security account S3 bucket with Object Lock (WORM) and deny-delete policies applied to member accounts — the CCSP exam models this as the standard enterprise pattern. Threat detection with cloud-native services: AWS GuardDuty (ML-based anomaly detection against VPC Flow Logs, DNS logs, and CloudTrail), Azure Defender for Cloud (workload protection with threat intelligence), GCP Security Command Center (asset discovery, vulnerability reporting, threat detection). CSPM (Cloud Security Posture Management) continuously audits configurations against CIS Benchmarks and compliance frameworks — detects publicly accessible S3 buckets, unrestricted security group rules, and MFA gaps before attackers find them.

Incident response in cloud environments follows the NIST SP 800-61 lifecycle (Preparation, Detection and Analysis, Containment/Eradication/Recovery, Post-Incident Activity) with cloud-specific adaptations. Forensic disk imaging uses EBS volume snapshots or Azure managed disk snapshots — the running instance is not shut down during acquisition (snapshot is taken at the storage layer). Network forensics uses VPC Flow Logs (L3/L4 metadata: source IP, destination IP, port, protocol, bytes, packets — no L7 payload) and VPC traffic mirroring for full packet capture on specific instances. Chain of custody in cloud: the customer has no access to provider hardware, so all evidence must come from cloud APIs, audit logs, customer-controlled storage, and vendor-supplied attestations — the exam tests whether you know where forensic evidence can and cannot be obtained.

Domain 6 — Legal, Risk and Compliance (13%)

Privacy law is heavily tested. GDPR: applies to processing personal data of EU residents regardless of where processing occurs; six lawful bases (consent, contract, legal obligation, vital interests, public task, legitimate interest); data subject rights (access, erasure, portability, restriction, objection); breach notification within 72 hours to the supervisory authority. CCPA: applies to California-resident data at businesses meeting revenue or data volume thresholds; opt-out of sale rights; no right to erasure for data required by law. HIPAA: US health data — covered entities and business associates; PHI protected in all forms; Business Associate Agreement (BAA) required for cloud providers processing PHI. PCI DSS v4.0: 12 requirements across six control objectives for payment card data environments; SAQ (Self-Assessment Questionnaire) for smaller merchants vs ROC (Report on Compliance) for large merchants and service providers.

Cloud-specific legal considerations: jurisdiction (data stored in a country is subject to that country’s laws, but the provider’s HQ jurisdiction may also compel disclosure via mechanisms like the US CLOUD Act); right to audit (contractual provisions allowing the customer to review provider controls or receive SOC 2 Type II reports in lieu of direct audit — most providers grant report access but not physical site access); exit strategy (data portability, standard formats, export windows — must be negotiated before signing, not during a migration crisis). Risk frameworks: ISO 27005 (information security risk management), NIST RMF SP 800-37 (Prepare, Categorize, Select, Implement, Assess, Authorize, Monitor), and FAIR (Factor Analysis of Information Risk — quantitative model using loss event frequency and loss magnitude for financial risk expression). The exam expects you to distinguish which framework is appropriate for which stakeholder and decision context.