Cloud Security Frameworks Compared: Choosing and Layering CCM, ISO, CIS, C5 and NIST

Cloud security teams are asked to "align with a framework", but the six documents most often named answer six different questions, and picking the wrong one leaves either your own configuration or your provider's controls unexamined. The CSA Cloud Controls Matrix, ISO/IEC 27017, ISO/IEC 27018, the CIS Controls Cloud Companion with CIS Benchmarks, the German BSI C5 catalogue and NIST SP 800-210 overlap in places, but they differ in who they are written for, whether they can be certified or attested, and how technical they get. This guide compares them side by side, explains what each one actually protects against and where it falls short, and shows how to layer them into one cloud control set with a worked example. It is for cloud security architects, GRC leads and procurement teams. Single-framework detail lives in the linked guides; this page is about choosing and combining. Status of each document was checked on the publisher's site in November 2026.

Key takeaways

• Two questions, two kinds of framework. "Is my provider secure?" is answered by provider assurance (CCM with STAR, ISO/IEC 27017 and 27018 certificates, C5 attestations); "Is my own cloud estate secure?" is answered by customer-side controls and configuration baselines (CCM customer guidance, CIS, NIST SP 800-210).
• CCM is the best crosswalk hub. CSA CCM v4.1 has 197 control objectives in 17 domains, states whether the provider or the customer should implement each one, and ships machine-readable mappings to other standards.
• ISO/IEC 27017 and 27018 ride on ISO/IEC 27001. They extend ISO/IEC 27002 guidance for cloud services and for public cloud PII processors; you are certified to ISO/IEC 27001 with them in scope, not to them alone.
• C5 is an attestation with tested operating effectiveness. The BSI issues no certificate; public accountants report under ISAE 3000, and a Type 2 report shows whether controls worked over a period, including the controls customers must run themselves.
• Configuration is where breaches happen. None of the provider frameworks checks your tenant; CIS Benchmarks and a posture tool do, and that is where most cloud incidents start.

Short answer

Use CSA CCM as your master control list and supplier questionnaire, because it covers both sides of the shared responsibility model and maps to the others. Ask providers for ISO/IEC 27001 certificates with ISO/IEC 27017 (and ISO/IEC 27018 where they process personal data) in scope, or a C5 Type 2 report where German public sector or health rules apply or where you want tested evidence. Harden your own accounts, subscriptions and projects with CIS Benchmarks, prioritised through the CIS Controls v8 Cloud Companion Guide. Use NIST SP 800-210 when designing access control for a cloud system you build or operate. Most organisations need at least one from each group.

The frameworks at a glance

CSA Cloud Controls Matrix

What it protects against: gaps in the shared responsibility split. CCM's domains run from Audit and Assurance to Universal Endpoint Management and include Identity and Access Management (IAM), Cryptography, Encryption and Key Management (CEK), Logging and Monitoring (LOG) and Supply Chain Management, Transparency and Accountability (STA). For each control the CSA indicates which actor should implement it, and the implementation guidelines describe what providers should do and, in places, what customers should do.

How it is used: as the internal control catalogue, as a supplier questionnaire (the Consensus Assessments Initiative Questionnaire, CAIQ, now built into the CCM as yes or no questions), and as a mapping hub through its JSON and YAML bundle. Providers publish CAIQ responses in the STAR Registry; Level 2 adds a third-party ISO/IEC 27001 certification or SOC 2 attestation.

Failure modes: treating a Level 1 self-assessment as independent assurance; adopting all 197 objectives without scoping, so the catalogue becomes shelfware; and ignoring the customer-owned half of each control. Licensing also matters: the CSA states internal use needs no licence, but commercial use such as embedding it in products or consulting needs one.

Choose it when you need one list that covers provider and customer duties and maps to ISO, NIST and PCI. See the Cloud Security Alliance CCM and STAR Guide.

ISO/IEC 27017

What it protects against: unclear provider and customer duties inside a certified ISMS. The 2026 edition gives guidance for implementing information security controls for cloud services, extending ISO/IEC 27002 with cloud-specific guidance and additional controls for both customers and providers, across public, private and hybrid clouds.

How it is used: providers include it in ISO/IEC 27001 certification scope; customers use the customer-side guidance to write their own cloud policies and the shared responsibility matrix.

Failure modes: reading a provider's certificate as covering your tenancy (it does not), not checking which edition a certificate cites now that the 2026 edition is out, and not checking the statement of applicability and scope (which services and regions).

Choose it when you already run ISO/IEC 27001 and want cloud controls in the same management system. See the ISO/IEC 27017 Cloud Security Controls Guide.

ISO/IEC 27018

What it protects against: misuse of personal data by a cloud processor. The 2025 edition gives guidelines for protecting PII in public clouds acting as PII processors, extending ISO/IEC 27002.

How it is used: as evidence in processor due diligence alongside contract terms; it is not a controller framework and does not replace a data protection impact assessment.

Failure modes: assuming it covers the controller's own duties, accepting it for a private or community cloud it was not scoped for, and stopping at the certificate without checking sub-processor, data location and deletion commitments in the contract.

Choose it when a public cloud provider processes personal data for you. See the ISO/IEC 27018 Cloud PII Protection Guide.

CIS Controls v8 Cloud Companion and CIS Benchmarks

What it protects against: customer-side misconfiguration and missing hygiene. The Cloud Companion Guide applies the CIS Controls to cloud environments, noting that cloud systems carry different assumed security responsibilities from traditional IT. CIS Benchmarks are consensus-developed configuration recommendations for more than 25 vendor product families, including foundations benchmarks for the three largest cloud platforms (listed alphabetically above).

How it is used: the Controls give priority (Implementation Groups); the Benchmarks give concrete settings such as logging, root or global administrator use, storage access and network exposure, which posture management tools check automatically.

Failure modes: benchmark scores treated as risk scores, Level 2 settings applied without testing and then rolled back wholesale, benchmark versions not tracked as platforms change, and no coverage of identity hygiene beyond what the benchmark checks.

Choose it when you need to secure your own accounts and prove it with measurable configuration results. See the CIS Benchmarks Guide and Cloud Security Posture Management (CSPM) Guide.

BSI C5

What it protects against: unverified provider claims. C5 specifies minimum requirements for secure cloud computing and is assessed through a standardised examination and report. According to the BSI C5 FAQ, there is no C5 certification; public accountants issue attestations under ISAE 3000 or IDW PS 860. A Type 1 report checks control design; a Type 2 report also tests operating effectiveness over the period, and C5 expects Type 2 after an initial audit. Reports must include corresponding controls that customers or subcontractors must operate.

Versions: C5:2026 splits criteria into subcriteria, adds "sharpening" and "complement" additional criteria, is compatible with EUCS level Substantial, and is published for the first time as machine-readable YAML. The BSI FAQ states it applies to engagements with dates after 1 June 2027 (Type 1) or periods beginning on or after that date (Type 2), with earlier adoption allowed.

Failure modes: filing the report without reading exceptions and deviations, skipping the corresponding customer controls, and assuming C5 is a legal requirement everywhere (the BSI describes it as generally recommendatory, mandated through the federal minimum standard and some sector rules).

Choose it when you serve German federal or health sector customers, or want tested evidence rather than a certificate. See the Germany BSI C5 Guide and the EU Cybersecurity Act and EUCS Guide.

NIST SP 800-210

What it protects against: poorly designed authorisation in cloud systems. SP 800-210, General Access Control Guidance for Cloud Systems (July 2020), describes the access control characteristics of cloud systems and gives guidance for IaaS, PaaS and SaaS. The models are treated as hierarchical: IaaS guidance also applies to PaaS and SaaS, while each model has its own access control focus.

How it is used: as a design reference for platform and product teams building multi-tenant services or internal platforms, alongside NIST SP 800-53 Rev. 5 controls such as AC-2 and AC-3.

Failure modes: using it as a compliance checklist (it is guidance with no assessment scheme), and not updating it with current cloud identity patterns such as workload identity federation, which post-date its publication.

Choose it when you design or review access control for a cloud system, not when you need supplier assurance.

Head-to-head comparison

Layering them into one control set

1. Pick the hub. Use CCM v4.1 as the master list, scoped to your service models. Mark each objective provider-owned, customer-owned or shared, using the CCM ownership indication as a starting point.
2. Map provider evidence. For provider-owned objectives, record which evidence covers them: ISO/IEC 27001 certificate with ISO/IEC 27017 and 27018 in scope, SOC 2 report, C5 report or STAR entry. Note the edition, scope, services and regions.
3. Import corresponding customer controls. Copy every complementary or corresponding customer control from provider reports into your own customer-owned list. These are commitments you are assumed to meet.
4. Bind customer controls to settings. For customer-owned IAM, logging, storage and network objectives, attach CIS Benchmark recommendations and run them in a posture tool in report-only mode first.
5. Design access with SP 800-210. For systems you build, review tenancy isolation and authorisation against SP 800-210 and the AC family in SP 800-53 Rev. 5.
6. Test and roll back safely. Enforce benchmark settings by environment ring (sandbox, non-production, production), keep exceptions with an owner and expiry, and keep a documented rollback for each preventive policy.
7. Review annually and on change. The BSI asks customers to obtain and analyse C5 reports yearly; apply the same cadence to all provider evidence and when a new edition (for example ISO/IEC 27017:2026 or C5:2026) appears.

Where identity fits

In every framework the customer-side identity controls carry the most risk: cloud administrator accounts, service accounts, access keys, workload identities and federated roles. Provider certificates say nothing about them. The Snowflake customer breach is the clearest example: accounts without MFA, with credentials unrotated for years and without network restrictions, were accessed with stolen passwords while no platform flaw was found. Map CCM IAM objectives to your own Cloud IAM Review Checklist and include non-human identities explicitly.

Decision criteria

Small versus large organisations: a small organisation gets most value from one benchmark enforced well and a short supplier questionnaire. A large organisation needs CCM as a hub, a common control framework that maps it to its other obligations (see the Common Control Framework Template), and automated evidence collection.

Worked scenario: a SaaS company entering the German market

A UK SaaS company runs on one hyperscaler, holds ISO/IEC 27001 and SOC 2, and wins a German statutory health insurer as a prospect.

1. Gap check: it maps its ISO/IEC 27001 controls to C5 criteria using CCM as the bridge, then reviews which C5 criteria its hyperscaler's own C5 report covers and which corresponding customer controls that report lists.
2. Customer-side hardening: it enforces the platform's CIS foundations benchmark in its production accounts, starting in report-only mode, and fixes administrator MFA, logging and key rotation findings first.
3. Privacy: it extends its ISO/IEC 27001 scope to include ISO/IEC 27017 and ISO/IEC 27018 controls, since it processes insured persons' data as a processor.
4. Attestation: it commissions a C5 Type 1 report for the first period, then Type 2, and decides whether to examine against C5:2026 early given the 1 June 2027 date.
5. Outcome: one control set, four evidence outputs (ISO certificate, SOC 2, C5 report, CAIQ in STAR), with every customer-owned control tied to a measurable setting.

Detection and measurement

Log provider evidence expiry dates and alert 90 days before a certificate or report lapses. Feed posture findings into the same ticketing and risk register as audit findings so they are measured once.

Framework mapping

Common failure patterns

• Certificate by association: assuming a provider's ISO/IEC 27017 certificate or C5 report covers your configuration. It covers the provider's controls only.
• Unread reports: filing SOC 2 or C5 reports without reviewing exceptions, scope and corresponding customer controls.
• Self-assessment as assurance: accepting a STAR Level 1 CAIQ in place of independent evidence for a critical supplier.
• Edition drift: controls mapped to ISO/IEC 27017:2015 or C5:2020 with no plan for the 2026 editions.
• Benchmark theatre: chasing a pass percentage while long-lived access keys and unused administrator roles remain.
• Framework overload: adopting all six in full rather than one hub with mapped evidence, so teams answer the same question six times.

Practitioner checklist

• Choose CCM v4.1 (or an existing common control framework) as the single hub and scope it to your service models.
• Record provider, customer or shared ownership for every control.
• Collect independent provider evidence and note edition, scope, services and regions.
• Import every corresponding customer control from provider reports and assign an owner.
• Enforce the relevant CIS foundations benchmark, starting in report-only mode, with ringed rollout and rollback.
• Review cloud identities, including non-human ones, against CCM IAM objectives.
• Use SP 800-210 for access design reviews of systems you build.
• Track C5:2026 and ISO/IEC 27017:2026 transitions and review provider evidence yearly.

Standards and references

• Cloud Security Alliance: Cloud Controls Matrix
• Cloud Security Alliance: STAR Program
• ISO: ISO/IEC 27017 Information security controls based on ISO/IEC 27002 for cloud services
• ISO: ISO/IEC 27018 Protection of PII in public clouds acting as PII processors
• BSI: C5 Criteria Catalogue FAQ
• NIST: SP 800-210 General Access Control Guidance for Cloud Systems
• CIS: CIS Controls v8 Cloud Companion Guide
• CIS: CIS Benchmarks

Related NHI Mgmt Group resources: Cloud Security Guide · Third-Party Attestation Comparison Map · Cybersecurity Frameworks Compared Guide · Cloud IAM Role Design Standard Template