3.2 Evaluate Cloud Service Providers (Domain 1.5)

Certified Cloud Security Professional CCSP

Track your progress as you read

Finished sections get a check mark.

1 Introduction & Exam Overview

1.1 Current CCSP Exam Facts 1.2 CAT Format, Scoring & Logistics 1.3 Eligibility, Experience & Certification Maintenance

2 Domain 1: Cloud Concepts & Architecture Foundations

2.1 Cloud Computing Concepts (Domain 1.1) 2.2 Cloud Reference Architecture (Domain 1.2) 2.3 Security Concepts Relevant to Cloud (Domain 1.3)

3 Domain 1: Secure Design, CSP Evaluation & AI/ML

3.1 Design Principles of Secure Cloud Computing (Domain 1.4) 3.2 Evaluate Cloud Service Providers (Domain 1.5) 3.3 AI/ML in Cloud Security (Domain 1.6)

4 Domain 2: Data Concepts, Storage & Protection Technologies

4.1 Cloud Data Concepts (Domain 2.1) 4.2 Cloud Data Storage Architectures (Domain 2.2) 4.3 Data Security Technologies & Strategies (Domain 2.3)

5 Domain 2: Discovery, Classification & Information Rights Management

5.1 Data Discovery (Domain 2.4) 5.2 Data Classification (Domain 2.5) 5.3 Information Rights Management (Domain 2.6)

6 Domain 2: Retention, Auditability & AI/ML Data Protection

6.1 Retention, Deletion & Archiving (Domain 2.7) 6.2 Auditability, Traceability & Accountability (Domain 2.8) 6.3 AI/ML Data Protection (Domain 2.9)

7 Domain 3: Infrastructure Components, Data Center & Risks

7.1 Cloud Infrastructure Components (Domain 3.1) 7.2 Secure Data Center Design (Domain 3.2) 7.3 Infrastructure & Platform Risks (Domain 3.3)

8 Domain 3: Security Controls & Business Continuity / Disaster Recovery

8.1 Security Controls Implementation (Domain 3.4) 8.2 Business Continuity & Disaster Recovery (Domain 3.5)

9 Domain 4: Application Security Awareness & Secure SDLC

9.1 Application Security Training & Awareness (Domain 4.1) 9.2 Secure SDLC Process (Domain 4.2) 9.3 Apply Secure SDLC (Domain 4.3)

10 Domain 4: Software Assurance, Architecture & IAM

10.1 Cloud Software Assurance & Validation (Domain 4.4) 10.2 Verified Secure Software (Domain 4.5) 10.3 Cloud Application Architecture (Domain 4.6) 10.4 Identity & Access Management Solutions (Domain 4.7)

11 Domain 5: Build, Operate & Operational Controls

11.1 Build Physical & Logical Infrastructure (Domain 5.1) 11.2 Operate & Maintain Infrastructure (Domain 5.2) 11.3 Operational Controls & Standards (Domain 5.3)

12 Domain 5: Forensics, Stakeholder Communication & Security Operations

12.1 Digital Forensics Support (Domain 5.4) 12.2 Communication with Relevant Parties (Domain 5.5) 12.3 Manage Security Operations (Domain 5.6)

13 Domain 6: Legal Requirements, Privacy & Audit

13.1 Legal Requirements & Cloud Risks (Domain 6.1) 13.2 Privacy Requirements (Domain 6.2) 13.3 Audit Processes for Cloud (Domain 6.3)

14 Domain 6: Enterprise Risk Management & Cloud Contracts

14.1 Cloud Implications for Enterprise Risk (Domain 6.4) 14.2 Outsourcing & Cloud Contract Design (Domain 6.5)

3.2 Evaluate Cloud Service Providers (Domain 1.5)

Key Takeaways Explain This Topic AI

Evaluate CSPs by verifying them against defined criteria (security, privacy, compliance, resilience, transparency)—not by brand reputation alone.

ISO/IEC 27017 provides cloud-specific information security control guidance building on ISO/IEC 27002; use it as evaluation criteria context, not as a guarantee of risk-free service.

PCI DSS applies when cardholder data is stored, processed, or transmitted; cloud customers must still define scope, responsibilities, and evidence even when using a CSP.

Common Criteria (ISO/IEC 15408) evaluates IT products/systems against a Protection Profile or Security Target; FIPS 140-2 (and its successor lineage) validates cryptographic modules.

Compare CSPs with assurance artifacts (certifications, attestations, pen-test summaries, CSA CAIQ/CCM mappings, SLAs, data-location disclosures) while never inventing certifications a provider does not hold.

Last updated: July 2026

Evaluating CSPs: Criteria Before Contracts

Domain 1.5 is deliberately short on the outline but high impact in practice: evaluate Cloud Service Providers (CSPs) using objective verification against criteria and system/subsystem product certifications . CCSP candidates must know what to ask for, what those artifacts prove, and what they do not prove. Marketing language such as "enterprise-grade security" is not an evaluation result.

Verification Against Criteria

Start with a requirements-driven checklist tied to your risk appetite, regulatory profile, and architecture. Typical evaluation criteria categories:

Criteria area What you verify Example evidence

Security controls Control framework alignment, vulnerability management, logging, IAM model ISO/IEC 27001 ISMS certification, SOC 2 Type II, CSA STAR, CCM mapping

Cloud-specific security Multi-tenancy isolation, virtualization security, customer-CSP split ISO/IEC 27017 alignment, architecture whitepapers, CAIQ responses

Privacy Roles (controller/processor), subprocessors, data residency, breach notice ISO/IEC 27018, GDPR DPAs, regional processing options

Resilience Availability design, DR capabilities, historical incidents SLA terms, status history, multi-region features, RTO/RPO options

Transparency & audit Right to audit, report access, scope limitations SOC reports under NDA, audit clauses, compliance portals

Operations & support Patch cadence, incident communication, shared responsibility matrix Runbooks, responsibility matrices, support tier definitions

Legal & commercial Liability caps, insurance, exit/data return, lock-in MSA/SLA/SOW, escrow, termination assistance

Verification means you obtain and review evidence that matches the scope of the service you will actually buy (region, service SKU, support tier). A certificate for a different product line or an expired report does not satisfy criteria for your workload.

ISO/IEC 27017 in Evaluation Context

ISO/IEC 27017 provides guidelines for information security controls applicable to the provision and use of cloud services, extending the ISO/IEC 27002 control set with cloud-specific guidance for both cloud service customers and CSPs. In evaluation:

Use 27017-oriented questions to probe shared responsibilities , isolation, admin operations, and monitoring in multi-tenant environments.

Treat a CSP's alignment or certification story involving ISO/IEC 27001/27017 as positive assurance , not as transfer of residual risk for your misconfiguration.

Map critical 27017-style themes (for example, shared roles and responsibilities, segregation in virtualized environments, alignment of security management) into your vendor questionnaire.

Do not claim on the exam that ISO/IEC 27017 alone "certifies the customer secure." It is criteria and guidance; effectiveness depends on implementation and on the customer's use of the service.

PCI DSS Context for Cloud

PCI DSS (Payment Card Industry Data Security Standard) applies to entities that store, process, or transmit cardholder data (CHD) or that can affect the security of the cardholder data environment (CDE). In cloud:

Scope follows the data and the systems that can impact CHD—not the marketing claim that a CSP is "PCI compliant" in the abstract.

Many CSPs publish PCI responsibility matrices and attestations for specific services. The customer must still implement required controls on the portions they own (for example, application code, identity, encryption configuration, logging retention they control).

Using a CSP service that is in-scope for the provider's attestation does not automatically make the customer's full application PCI compliant.

Exam mindset: evaluate whether the CSP's attested services, regions, and shared matrix match your CDE design; then close customer-owned gaps.

System and Subsystem Product Certifications

The outline explicitly calls out Common Criteria (CC) and Federal Information Processing Standard (FIPS) 140-2 as examples of system/subsystem product certifications used when evaluating components that may be embedded in cloud offerings or customer-controlled stacks.

Common Criteria (ISO/IEC 15408)

Common Criteria is an international framework for evaluating the security functionality and assurance of IT products and systems against a Security Target (ST) and, often, a Protection Profile (PP) .

Concept Meaning for CSP evaluation
Target of Evaluation (TOE) The product/system boundary under evaluation
Protection Profile (PP) Implementation-independent security requirements for a product class
Security Target (ST) Implementation-specific claims for a particular product

Evaluation Assurance Level (EAL) (traditional scale) Depth of assurance activities (higher is not automatically "more secure" for your use case)

Certificate / certification report Independent lab evaluation under a national scheme

How to use CC correctly: If a CSP or appliance claims CC certification, verify the exact product version , TOE scope , and PP/ST claims . A firewall CC certificate does not certify the entire public cloud control plane. CC says the evaluated configuration met stated claims under the evaluation—not that every deployment is correctly configured.

FIPS 140-2 (Cryptographic Modules)

FIPS 140-2 is a U.S. government standard for validating cryptographic modules (hardware, software, firmware, or hybrid). Modules are validated at security levels (1–4) with requirements for cryptographic algorithms, key management, physical security (for hardware), and operational environment.

Notes for modern practice and the exam:

Organizations still encounter FIPS 140-2 language widely in contracts and product docs; the validation program has evolved (including FIPS 140-3 transition in the broader ecosystem). For CCSP, understand the role : independent validation that a crypto module meets specified security requirements.

"FIPS-validated module" is stronger than "uses FIPS-approved algorithms" in a non-validated implementation—wording matters in RFPs and architecture reviews.

Cloud HSMs, VPN gateways, TLS libraries, and disk-encryption stacks may advertise FIPS module validation; confirm mode of operation (FIPS mode enabled) and that your workload actually invokes the validated module path.

Comparing CSPs Using Assurance Artifacts (Without Inventing Claims)

Build an apples-to-apples comparison workbook. For each shortlisted CSP and service:

Identity the service boundary (which SKU, region, support plan).

Collect artifacts : ISO certificates (scope statements), SOC 1/2/3 or ISAE reports, PCI AOC/ROC summaries as applicable, FedRAMP or other government authorizations if relevant, CSA Cloud Controls Matrix (CCM) mappings, Consensus Assessments Initiative Questionnaire (CAIQ) answers, pen-test executive summaries, bug-bounty transparency, SLA/SLO definitions, data residency maps, subprocessors lists.

Score against your criteria with evidence links and expiration dates.

Document residual risks and required compensating customer controls.

Never invent a certification, expand a certificate's scope, or assume a subsidiary's cert covers another product line.

Artifact Useful for Common limitation
ISO/IEC 27001 certificate ISMS existence and external audit Scope may exclude the exact service/region

SOC 2 Type II Operating effectiveness over a period Point-in-time controls outside report window; NDA limits sharing

PCI DSS attestation Card data environments Service-specific; customer scope remains
CC certificate Product security claims Narrow TOE; version-specific
FIPS 140-2/140-3 validation Crypto module strength Must run in validated mode; not whole-system security
CSA STAR / CAIQ Cloud control transparency Self-attestation levels vary; still need review
SLA Availability/performance remedies Credits ≠ security; exclusions for shared responsibility failures
Evaluation Workflow for Exam Scenarios

Typical stem patterns:

Regulated workload → prioritize attestations matching the regulation (for example, PCI matrix + SOC + regional controls), not generic awards.

Cryptographic assurance → look for FIPS-validated modules and key-management design, not "AES is used" alone.

High-assurance government or product procurement → Common Criteria PP/ST match may appear.

Vendor comparison → systematic criteria + current artifacts + residual risk; reject options that rely on unverifiable claims.

Red flags: expired reports, vague "aligned with" language without certificates, refusal to provide any third-party assurance for enterprise-sensitive workloads, scope statements that omit the services you will use, and pressure to accept marketing decks in place of independent evaluation.

Domain 1.5 skill in one sentence: demand evidence, read the scope, map shared responsibility, and score residual risk—without fabricating certifications.