3.2 Evaluate Cloud Service Providers (Domain 1.5)

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:

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).

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:

1. Identity the service boundary (which SKU, region, support plan).
2. 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.
3. Score against your criteria with evidence links and expiration dates.
4. Document residual risks and required compensating customer controls.
5. Never invent a certification, expand a certificate's scope, or assume a subsidiary's cert covers another product line.

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.