CCSP Master Guide 2026

What the CCSP credential covers

Certified Cloud Security Professional (CCSP) is an ISC2 credential for professionals applying information security expertise to cloud environments. It covers cloud security architecture, data protection, platforms and infrastructure, applications, operations, and legal, risk and compliance concerns. This is a professional cloud-security certification, distinct from the entry-level CC credential and from a vendor-specific cloud administrator exam. It tests judgment about security design, operating responsibilities and assurance across service providers and customers.

The current exam outline became effective August 1, 2026. It updates six domains and their weights. Use this version when selecting books, courses and practice resources; older resources may still teach relevant principles but organize or weight them differently. The updated outline includes foundational artificial intelligence and machine learning security considerations throughout the cloud-security body of knowledge.

The exam at a glance

CAT means item selection adapts during the session. The exact number of items varies, and candidates answer in sequence without skipping and returning later. Do not interpret item count or perceived difficulty as a pass signal. The score is scaled, so a practice percentage or guessed raw cutoff does not predict the official result.

Domain 1: Cloud Concepts, Architecture and Design

Domain 1 is 17 percent. It covers cloud definitions, essential characteristics, roles, service and deployment models, cloud reference architecture and security design. Candidates should understand elasticity, measured service, resource pooling and multi-tenancy, plus the implications of IaaS, PaaS and SaaS. Architecture decisions include portability, interoperability, availability, resiliency, privacy, performance, governance and vendor lock-in.

Security design incorporates key management, identity, network and virtualization controls, cloud threats, secure configuration, secure data lifecycle and business continuity and disaster recovery. Provider evaluation asks whether a service meets business, security, regulatory and assurance requirements. Cloud AI/ML topics include validating data sources, threat detection, security orchestration and ethical and regulatory concerns.

Example: a company is selecting a cloud service for a workload that must move providers within five years. Portability, interoperability, data export and termination terms matter alongside confidentiality. Choosing a provider solely by compute price ignores reversibility and operational dependency.

Domain 2: Cloud Data Security

Domain 2 is the largest at 20 percent. It follows data through discovery, classification, storage, use, retention and deletion. Candidates should recognize structured, unstructured and semi-structured data; data flows and location; and how labels guide access and handling. Security controls include encryption, hashing, tokenization, masking, anonymization, data-loss prevention, key and secret management, and information-rights controls.

Retention and deletion must account for legal holds and archiving. Auditability and traceability require useful event sources, identity and context, controlled log storage and evidence chain of custody. In AI/ML workloads, protect datasets and models and validate data sources. Classification and discovery help prevent sensitive data from entering an unapproved pipeline.

Example: a cloud analytics team discovers customer identifiers in an unstructured data lake. First locate and classify the records, then apply access and retention controls and determine whether the dataset is permitted for its intended analysis. Encrypting the bucket alone does not solve inappropriate access or retention.

Domain 3: Cloud Platform and Infrastructure Security

Domain 3 is 17 percent. It covers data-center environments, networks, compute, storage, virtualization and management planes. Secure design addresses tenant partitioning, physical and environmental resilience, logical access, risk assessment and protective controls. Candidates should understand how to plan continuity and recovery and how recovery time and recovery point requirements shape a design.

A cloud environment includes both provider-operated layers and customer-configured systems. Understand the responsibility boundary for the service in question. Infrastructure risks include misconfiguration, vulnerabilities, threats and attack paths across physical, virtual and management layers. Controls may include segmentation, authentication, audit collection, hardening, patching, backups and availability monitoring.

Example: an organization requires recovery within two hours and can lose no more than fifteen minutes of transaction data. Those business objectives guide architecture and replication choices; simply selecting a geographically separate Region does not prove that recovery meets them. Test the plan and validate application dependencies.

Domain 4: Cloud Application Security

Domain 4 is 16 percent. It covers secure development, threat modeling, secure coding, verification, software assurance, APIs, supply chains and cloud application architecture. Security should appear throughout requirements, design, implementation, test and maintenance. Candidates should recognize common vulnerabilities and the value of code review, testing, configuration management and validated dependencies.

Cloud application designs may use identity federation, single sign-on, MFA, secrets management, API gateways, web application firewalls, containers and service orchestration. Choose controls to match the risk: an API authorization flaw is not corrected by encrypting the storage volume; an exposed secret must be rotated and removed from the code and pipeline.

Example: a build pipeline downloads a third-party library from an unverified source. Supply-chain assurance includes checking authenticity, integrity, licensing and vendor risk, and controlling how dependencies enter releases. A secure software process reduces the chance that a vulnerability ships to production.

Domain 5: Cloud Security Operations

Domain 5 is 17 percent. It addresses how cloud infrastructure is built, operated, monitored, maintained and investigated. Topics include secure configuration of physical and virtual environments, access controls, network security, hardening, patch management, capacity and availability monitoring, backup and restore, management-plane operations and standards.

Operational controls also include change, incident, problem, release, deployment, configuration, service-level and continuity management. Digital forensics requires collecting, acquiring and preserving evidence. Security operations use monitoring, logs, threat intelligence, vulnerability assessment and penetration testing. Communicate appropriately with vendors, customers, partners and regulators.

Example: an engineer must patch a production cloud cluster. Follow change control, test the patch, ensure a recovery path and monitor the deployment. Emergency changes may use a defined expedited process, but undocumented direct changes can create configuration drift and impair investigation.

Domain 6: Legal, Risk and Compliance

Domain 6 is 13 percent. It covers cloud-specific legal and privacy issues, audit, enterprise risk and contract design. Data location can create jurisdictional obligations. A cloud customer must know its controller, processor, owner, custodian and steward roles; identify notification responsibilities; and perform privacy impact assessments where required. Regulations depend on the facts and jurisdiction, so avoid assuming a provider’s certification automatically satisfies the customer’s compliance duties.

Cloud audit must account for virtualized and distributed environments, provider assurance reports, audit scope limitations, stakeholder involvement and evidence access. Contracts should address service levels, security requirements, data ownership, audit rights, termination, portability, breach communication, subcontractors and vendor viability. Risk can be avoided, mitigated, transferred, shared or accepted by the authorized decision-maker.

Example: a provider offers a SOC report but excludes a service feature used by the customer. The report alone does not show that the customer’s entire workload is covered. Review the scope, exceptions, complementary user controls and gaps, then decide what additional evidence or controls are needed.

Certification experience and Associate pathway

To become a CCSP, ISC2 requires five years of cumulative full-time IT experience, including three years in cybersecurity and one year in one or more current CCSP domains. A post-secondary bachelor’s or master’s degree in computer science, IT or a related field may satisfy up to one year. CSA’s CCSK can substitute for one year. Only one year may be waived. An active CISSP can substitute for the entire experience requirement.

Part-time work and internships may count under ISC2’s specific rules. A candidate without the required experience may pass the exam and become an Associate of ISC2, then has six years to earn the five years of experience. Passing the exam and satisfying the certification experience requirement are separate stages. An active CISSP pathway waives the CCSP experience prerequisite, but other application and maintenance requirements still apply.

Registration, fees and retakes

The standard CCSP exam price is US $599 in the Americas and Asia Pacific regions shown in the ISC2 pricing table. EMEA and UK prices are listed in local currencies; taxes depend on testing location. The exam code is generally valid for 365 days. A published reschedule fee is US $50 and a cancellation fee US $100, subject to current appointment rules. Each attempt is paid unless a product explicitly includes an additional attempt.

ISC2 retake rules permit up to four attempts within a 12-month period, with waits of 30 days after the first attempt, 60 after the second, and 90 after the third or later attempt. After passing, a candidate who meets experience applies for certification and follows the endorsement and Code of Ethics requirements. Maintenance for CCSP includes 90 CPE credits per three-year cycle, including at least 60 Group A credits; the remaining 30 may be Group A or Group B; the current annual AMF for a non-CC-only member is US $135.

How to prepare

Start with the August 1, 2026 outline. Identify weak domains, then study architecture, data lifecycle, platform controls, application security, operations and legal-risk topics in connected scenarios. CCSP questions often require selecting the best cloud security decision across technical and organizational boundaries. Build comparison notes for provider/customer duties, encryption versus access control, BC versus DR, and a SOC report versus full workload assurance.

1. Map each current domain task to a resource and label your knowledge strong, uncertain or new.
2. Study cloud service and deployment models and how responsibilities shift across them.
3. Practice data classification, lifecycle, encryption, logging, retention and legal-hold decisions.
4. Apply secure design and operational controls to cloud architecture and application scenarios.
5. Review privacy, jurisdiction, audit-scope, provider-contract and enterprise-risk cases.
6. Practice timed one-way decisions for CAT and explain why distractors fail.

The exam is professional-level and wide-ranging. Focus on selecting controls that match business context, provider service model, data sensitivity, legal obligations and operational constraints. Do not memorize one provider’s product list as a substitute for cloud-neutral security reasoning.

Apply the shared responsibility model to architecture choices

Cloud security responsibilities vary with the service category. In IaaS, the customer manages more of the operating system, application and network configuration. In PaaS, the provider manages more of the platform but the customer remains responsible for application logic, identities, data and settings. SaaS shifts still more operational layers to the provider, while the customer retains governance over users, data, configuration and contractual obligations. Confirm the actual service terms rather than relying on a generic diagram.

A customer selecting a managed data warehouse may reduce patching work, but still must control who can query sensitive datasets, where data is copied, how keys are managed, and what retention rules apply. A provider's infrastructure certification does not mean the customer's configuration is secure or compliant. Identify each actor and asset in the workload before assigning responsibility.

Work a data lifecycle example

Imagine a healthcare analytics team receives records from multiple business units and stores them in a cloud data lake. Discovery identifies where personal and health data exist. Classification assigns sensitivity labels. Access policies restrict use to approved analytic roles. Encryption protects data at rest and in transit, while key access remains controlled. A data-loss prevention or tokenization approach may reduce exposure in downstream datasets.

The team also needs a retention schedule, deletion process, legal-hold capability and logs that identify who accessed or changed records. If analysts train an AI model, the team should validate source quality, restrict training data and consider model privacy. Encrypting the data lake is valuable but does not replace classification, access governance, retention or auditability.

Design recovery around business requirements

Recovery Time Objective (RTO) expresses the maximum target duration to restore a service after disruption. Recovery Point Objective (RPO) expresses the acceptable amount of data loss measured in time. They are business requirements that influence replication, backup frequency, architecture cost and recovery testing. A low RPO can require more frequent or continuous data replication, while a low RTO can require ready alternate capacity.

For example, an online payment system with an RPO of minutes and RTO of one hour requires a different design from an archive that can be unavailable for several days. A secondary region is only useful if identity, network, key management, dependencies and operational staff can support failover. Test the full application recovery path, not just the database backup.

Evaluate a cloud provider beyond certifications

Provider due diligence considers the service’s security controls, audit evidence, geographic locations, subcontractors, support model, financial viability, exit options and incident communications. An independent report helps, but review its scope, period, exceptions and complementary customer controls. A control assessed in one service may not cover a different product or configuration.

Contracts should address data ownership and return, deletion after termination, audit rights, service levels, breach notice, subprocessors, evidence access, eDiscovery support and jurisdiction. A customer should preserve portability and understand what happens if the provider exits a market or the relationship ends. A low price can create material transition costs if data export and application redesign are difficult.

Cloud application threat modeling example

An application exposes a public API that accepts an order ID and returns customer details. Threat modeling identifies spoofing or unauthorized access, information disclosure and possible abuse. Controls can include strong authentication, object-level authorization, rate limiting, input validation, logging and security tests in the software lifecycle. A web application firewall may help with certain traffic patterns, but it does not correct an authorization bug in the API logic.

For a containerized service, review image provenance, configuration, secrets, network isolation and patching responsibilities. Use controlled build pipelines and verified dependencies. An AI feature that summarizes customer records adds questions about input data, output handling, model provider use, logging and privacy. Apply the same security lifecycle: define requirements, model threats, implement controls, test and monitor.

A candidate's study priorities

CCSP preparation is demanding because it connects architecture, data, application development, operations and legal risk. If you are strongest in engineering, spend time on contracts, audit scope, privacy and risk ownership. If you are strongest in governance, build confidence in cloud service models, IAM, data lifecycle, secure software and recovery architecture. The exam blueprint weights each domain, but individual experience determines where extra study helps most.

Use provider-neutral scenarios whenever possible. Ask how the answer changes for SaaS versus IaaS, who controls the data, what evidence proves a control operates, how the system recovers, and which contract term protects the business requirement. This reasoning is more durable than memorizing one vendor’s console steps, which the CCSP outline does not require as a product-specific implementation exam.

Connect assurance evidence to customer controls

A provider’s independent assessment can support a customer’s assurance program, but the customer must read the scope. Identify the services and period covered, exceptions, subservice organizations and complementary user controls. A report about infrastructure does not necessarily test the customer’s application configuration or access reviews. The customer should document the gap and decide whether another control, audit or contractual assurance is needed.

For example, a financial institution uses a managed platform whose report assumes the customer encrypts a particular data field and restricts administrator access. Those customer controls must be implemented and evidenced. The provider report is one input to risk assessment, not a substitute for the customer’s own control operation.

Follow a cloud-data protection case end to end

Consider a company collecting user activity logs for fraud analysis. It discovers and classifies the data, identifies personal identifiers, restricts access to the analysis team, encrypts records and manages keys separately. It sets retention and deletion periods, but preserves records on legal hold when required. Event logs identify who queried data and when. If records train a model, the company validates data sources, limits sensitive inputs and evaluates model and dataset security.

Each step addresses a different point in the lifecycle. Encryption does not determine whether the collection is lawful. A retention schedule does not prevent unauthorized queries. Logging does not guarantee that data is correctly classified. CCSP asks candidates to integrate controls rather than select one technology for every data-security concern.

Architect application security across delivery

A cloud-native application might use containers, APIs, an identity provider and a managed database. Secure requirements define who can access each function and how data is handled. Threat modeling identifies spoofing, tampering, information disclosure and privilege escalation risks. The pipeline validates code and dependencies, scans images, manages secrets and controls releases. At runtime, logging, API authorization, rate limits and incident procedures support operations.

A WAF can block some malicious requests but cannot repair flawed object-level authorization in application code. A secure development lifecycle combines design, testing and operations controls. A vendor library should be assessed for provenance and vulnerability exposure; simply encrypting the build artifact does not establish software integrity.

Make business recovery requirements testable

A service owner sets RTO and RPO based on business impact. Architects then choose availability zones, backup frequency, replication and alternate capacity to meet those needs. Operations tests recovery, verifies data consistency and checks identity and key dependencies. Legal and risk teams confirm that data location and recovery arrangements remain acceptable. A cloud recovery plan should also identify who may declare a disaster and how customers or regulators are notified.

If a system depends on a provider-specific managed service, portability and termination planning matter. Data-export time, proprietary interfaces, contract exit assistance and deletion evidence can affect recovery from a provider failure. Resilience therefore includes operational and contractual design, not only redundant compute.