CCSP Exam Domains

The current CCSP outline has six domains

The CCSP exam outline effective August 1, 2026 organizes cloud-security knowledge into six domains. Their weights guide study priorities, but they do not guarantee that a particular adaptive exam form will contain an exact percentage of items from each domain. The exam expects candidates to connect technical safeguards with data sensitivity, service boundaries, operations, law and business requirements.

Domain 1: Cloud Concepts, Architecture and Design

Domain 1 covers cloud definitions, roles, essential characteristics, service categories and deployment models. Know how SaaS, PaaS and IaaS shift operational duties, and how public, private, hybrid, community and multicloud patterns affect governance. Architecture decisions also involve portability, interoperability, reversibility, availability, privacy, performance, service levels and vendor exit.

Security concepts include identity and access control, key management, network security, virtualization, containers, serverless services, isolation, patching and hardening. The outline also includes secure design, business continuity and disaster recovery, business impact analysis, provider evaluation and foundational AI and machine-learning security. A provider certification is evidence about a defined product or scope; it is not a substitute for checking whether the service fits the customer’s requirements.

Worked decision: a company expects to change providers within several years. The design review should include data export, interface compatibility, termination assistance, versioning and the time needed to migrate. Encryption matters, but it does not solve lock-in or prove that the workload can move. Use the stated exit requirement to evaluate architecture and contract choices together.

AI topics cross architecture and data protection

The current outline includes foundational AI and machine-learning concerns in more than one domain. In architecture, candidates should recognize cloud threat detection and analysis, validating data sources, security orchestration and response, ethical concerns and regulatory duties. In data security, the outline turns to privacy and security of data sets and models, including validation and verification. The exam tests security judgment around these systems; it does not require candidates to build a model.

For example, an organization sends customer documents to a hosted AI service to summarize support cases. Review what data enters the service, whether the provider retains or trains on it, who can access prompts and outputs, and how sources and results are validated. Architecture and vendor terms affect the service choice; classification, privacy and lifecycle controls govern the data. If the system produces a wrong answer, validation and human oversight matter alongside confidentiality.

Domain 2: Cloud Data Security

Domain 2, the largest at 20%, follows data through discovery, classification, storage, use, retention, archiving and deletion. It includes structured, semi-structured and unstructured data, data flows, data dispersion and data location. The candidate should understand why an organization first needs to know what data exists and how sensitive it is before selecting controls.

The outline covers storage architectures, encryption, cryptographic keys, hashing, masking, anonymization, tokenization, data-loss prevention, secrets and certificates, information-rights management and auditability. Retention must account for business and legal needs. A legal hold can restrict deletion, while a normal retention schedule should still remove data when the permitted period ends. Data events need useful identity and context, protected logs, traceability and, where needed, chain of custody.

Worked decision: a data lake combines customer records with clickstream files. Discovery and classification identify sensitive fields in both structured tables and unstructured objects. The team can then restrict access, apply masking to an analytics view, define retention, and preserve an authorized legal hold. Encrypting the storage is useful, but it does not tell the team what is present or who should use it.

Domain 3: Cloud Platform and Infrastructure Security

Domain 3 covers physical environments, networks and communications, compute, virtualization, storage and the management plane. The outline includes logical tenant partitioning, access controls, facility and environmental design, power and connectivity resilience, infrastructure risk assessment, vulnerabilities, risk treatment, logging and security controls. Candidates need to identify which layer a scenario describes and who operates it.

Business continuity and disaster recovery are tied to business requirements, including Recovery Time Objective and Recovery Point Objective. An RTO concerns the target time to restore a service; an RPO concerns the acceptable amount of data loss measured in time. A cloud architecture should be tested against both. A backup that has never been restored is not evidence that the recovery objective can be met.

Worked decision: a transaction system must resume quickly and cannot lose much recent data. The service owner sets the business objectives. Architects then choose replication, backups, alternate capacity and restoration procedures, and test restoration. A generic statement that the provider is highly available does not demonstrate that the customer’s workload and data meet those objectives.

Domain 4: Cloud Application Security

Domain 4 follows the secure software development lifecycle from business requirements and design through coding, testing, release and maintenance. It includes threat modeling, cloud-specific risks, secure coding, configuration and version control, security testing, abuse cases and software assurance. Common testing approaches include static, dynamic, interactive and composition analysis; understand what each can reveal and what it cannot prove on its own.

Supply-chain topics include vendor assessment, third-party software, licensing, authenticity, integrity and verified open-source components. Application architecture can use API gateways, web application firewalls, load balancers, sandboxing and cryptography. These components do not correct every application flaw. A WAF may filter some traffic, but object-level authorization still has to be enforced in the application.

Worked decision: a team’s build pipeline imports a library from an unverified source. The first question is whether the dependency is authentic, intact, licensed and approved. A vulnerability scan may identify a known weakness, but provenance and integrity checks address whether the component is the one the team intended to use. Secure delivery combines these safeguards with testing and controlled release.

Domain 5: Cloud Security Operations

Domain 5 addresses secure configuration and daily operation of cloud services, including physical and virtual controls, change and configuration management, continuity, incident and problem management, release and deployment, service levels, availability and capacity. Security operations include monitoring controls, collecting and analyzing logs, threat intelligence, vulnerability assessment, penetration testing, incident response, communication and digital forensics.

A cloud investigation may depend on provider logs, customer identity events, API activity and application records. Evidence collection must preserve integrity and document who handled it. Communication with the provider, customer, partner or regulator follows assigned roles and legal obligations. A fast response is not necessarily a sound response if it destroys evidence or expands the outage.

Worked decision: an administrator’s account creates an unfamiliar export job. The team should follow its incident plan, preserve the relevant activity records, determine whether the account and job are authorized, and contain access through approved procedures. Immediately deleting the job or rebuilding the environment could erase evidence before the scope is understood.

Domain 6: Legal, Risk and Compliance

Domain 6 includes cloud-specific legal risk, privacy, jurisdiction, eDiscovery, forensics, audit methods, assurance reports, gap analysis, policy, stakeholders and industry requirements. A cloud service can store or process data across locations, and the customer’s obligations may depend on the data, contract, service and applicable law. Do not assume that a provider’s default region resolves every legal question.

Audit evidence needs a scope check. Identify which services and locations a report covers, the reporting period, exceptions, complementary customer controls and any excluded subprocessors. A SOC or other assurance report can support a review, but it is not a blanket certification of every feature or customer configuration. Contract clauses should address audit access, data return and deletion, incident notification, service levels, location and termination support where relevant.

Worked decision: a customer uses one managed feature that is excluded from a provider report. The report cannot establish assurance for that feature. The reviewer should seek relevant evidence, assess the customer’s own controls and record the gap. The important question is whether the evidence covers the actual service and control objective, not whether the provider has a familiar report title.

Separate privacy, residency and assurance questions

Several legal and technical ideas can appear in one scenario but answer different questions. Data residency asks where information is stored or processed. Privacy asks how personal information is collected and used. Contract terms allocate obligations between the customer and provider. An audit report describes a defined assurance scope. Choosing a region may address one requirement, but does not by itself establish lawful processing, suitable customer controls or complete audit coverage.

Imagine a provider processes support recordings in more than one region, while the contract permits a subprocessor and the assurance report covers only the core service. The reviewer should identify the applicable data and obligations, map locations and subprocessors, check the report’s exclusions, and decide what additional evidence or contract terms are needed. Do not collapse the analysis into “choose a local region” or “the provider has an audit report.”

How the domains combine in a scenario

A migration of regulated customer records may test all six domains at once. Architecture asks whether the service model, portability and shared responsibilities fit. Data security asks how to discover, classify, encrypt, retain and delete the records. Infrastructure asks about network paths and recovery. Application security asks how APIs and dependencies are protected. Operations asks who monitors access and handles incidents. Legal and compliance asks whether locations, contracts and assurance evidence cover the use.

When several domains seem relevant, use the question’s requested action to choose the best answer. “Before selecting a provider” points toward evaluation and contract evidence. “After detecting an export” points toward operations and incident handling. “At the end of the retention period” points toward lifecycle policy and deletion, subject to legal hold. Many controls may ultimately be needed, but an exam item tests one decision in the scenario.

Use weights without treating them as quotas

Domain 2 has the largest average weight at 20%, while Domain 6 is 13%. That makes data security a reasonable priority in a study plan, but it does not justify skipping legal, risk and compliance topics. The remaining domains each represent a substantial part of the outline. The exam uses adaptive delivery and does not promise candidates an identical item distribution.

For each domain, learn the vocabulary, map it to a decision and explain a concrete example. If you can define tokenization but cannot distinguish it from masking in a data-use scenario, revisit the control’s purpose. If you can name an audit report but cannot inspect scope and exceptions, practice reading assurance claims critically. This approach builds usable understanding across the blueprint.