If your organization sells into the enterprise, "cloud security standards" isn't an abstract phrase — it's the list of frameworks a customer's security team pastes into a vendor questionnaire before they'll sign. ISO/IEC 27001:2022, NIST CSF 2.0, and the CIS Benchmarks/Controls are the three most commonly referenced, and each has changed meaningfully in the last three years: ISO cut its control set from 114 to 93 and added a technological theme in October 2022, NIST added an entirely new "Govern" function in February 2024, and CIS pushed Controls v8.1 in June 2024 with explicit software supply chain language. CNAPP vendors like Wiz have built entire product lines mapping cloud misconfigurations to these frameworks' controls — but posture scanning only covers part of what the newest revisions actually require. This post breaks down what each standard now demands, where cloud posture tooling alone falls short, and what a program that actually satisfies an auditor looks like.
What are the main cloud security standards, and how do they differ?
The three standards enterprises ask about most are ISO/IEC 27001:2022, NIST CSF 2.0, and the CIS Benchmarks/Controls, and they differ in what they certify versus what they merely guide. ISO/IEC 27001:2022 is a certifiable standard — an accredited auditor issues a certificate valid for three years, and it defines an Information Security Management System (ISMS) built around 93 controls organized into four themes: organizational (37), people (8), physical (14), and technological (34). NIST CSF 2.0, released February 26, 2024, is not certifiable; it's a voluntary risk-management framework organized around six functions — Govern, Identify, Protect, Detect, Respond, Recover — that companies use to structure a program and communicate maturity to regulators or boards. CIS is different again: the CIS Critical Security Controls (v8.1, June 2024) is a prioritized 18-control checklist for general security hygiene, while the CIS Benchmarks are hundreds of platform-specific hardening guides (CIS AWS Foundations Benchmark v3.0, CIS Azure Foundations Benchmark, CIS Kubernetes Benchmark) that CNAPP tools like Wiz scan against directly. A company can be ISO 27001 certified, self-assess against NIST CSF, and run CIS Benchmark scans simultaneously — they're not mutually exclusive, and most enterprise security questionnaires now ask about all three.
Why did NIST CSF 2.0 add a whole new "Govern" function in 2024?
NIST added Govern because the first decade of CSF adoption showed that technical controls fail without organizational accountability behind them, and the update makes that accountability its own pillar rather than a subsection. CSF 1.1 (2018) had five functions — Identify, Protect, Detect, Respond, Recover — that read as a technical maturity ladder. CSF 2.0, published after a multi-year public comment process, sits Govern at the center of the wheel, covering organizational context, risk management strategy, roles and responsibilities, policy, and — notably for this audience — supply chain risk management as its own category (GV.SC). That category asks organizations to identify, prioritize, and assess suppliers and third-party partners, and to have a process for responding when a supplier has a security incident. For cloud-native companies, this is the clause that turns "we scan our cloud accounts" into "we can also show who built the software running in them, and how" — a question a Govern-function auditor will now ask explicitly rather than treat as out of scope.
What does ISO/IEC 27001:2022's Annex A actually require for software development?
ISO/IEC 27001:2022 requires organizations to secure their development lifecycle under Annex A control 8.25 ("Secure development life cycle"), and it's paired with 8.28 ("Secure coding") and 8.29 ("Security testing in development and acceptance") to form a cluster assessors increasingly focus on. Control 8.25 requires rules for secure development to be established and applied to software and systems, covering the full lifecycle from design through decommissioning — not a point-in-time scan. Organizations already certified under the 2013 version had until October 31, 2025 to complete a mandatory transition audit to the 2022 controls, and auditors report that the technological theme (which bundles 8.25, 8.28, 8.29, plus 5.23 for cloud service security and 8.9 for configuration management) is where transition audits find the most gaps, because it's the newest material relative to the 2013 baseline most ISMS teams were built around. A CNAPP dashboard showing clean cloud configuration doesn't answer 8.25's question of whether the code deployed into that configuration went through a documented, reviewed, and tested build process — that evidence has to come from somewhere else.
Where do CNAPP platforms like Wiz fall short on these frameworks' newest requirements?
Platforms like Wiz fall short because they were architected around agentless cloud posture and workload scanning, which maps cleanly to CIS Benchmarks and the infrastructure-facing controls in ISO and NIST but not to the software supply chain provenance those same frameworks now require. Wiz's compliance dashboard is genuinely strong at mapping misconfigurations to framework controls — it's one of the product's headline features, and Google's announcement of its $32 billion acquisition of Wiz in March 2025 (the largest cybersecurity acquisition on record, still pending regulatory close) only reinforces how central that posture-to-compliance mapping has become to the CNAPP category. But NIST CSF 2.0's GV.SC supply chain category, ISO 27001's 8.25/8.28/8.29 cluster, and the CIS Software Supply Chain Security Guide (first published in 2022, expanded in its 2024 update) all ask questions a cloud-posture scanner structurally can't answer: which commit produced this artifact, who reviewed it, what dependencies does it pull in, and did the build pipeline itself get compromised before the workload ever reached the cloud account Wiz is scanning. Teams relying on CNAPP alone typically end up bolting on a separate SBOM tool and a separate CI/CD security tool to answer those questions, then manually reconciling three dashboards' worth of evidence for a single audit.
How much does misalignment with these standards actually cost?
Misalignment costs organizations both in lost deals and in breach exposure, and the two compound each other. On the breach side, IBM's Cost of a Data Breach Report 2024 put the global average incident cost at $4.88 million, and breaches attributed to supply chain compromise carried a higher-than-average cost and a longer average time to identify and contain — over 280 days combined in IBM's dataset for supply-chain-linked incidents. On the deal side, enterprise procurement teams increasingly gate vendor onboarding on ISO 27001 certification or a completed SOC 2 report before a contract can proceed, and a failed transition audit (the October 2025 ISO 27001:2022 deadline caught a meaningful number of organizations still running 2013-era controls) can mean a lapsed certificate mid-sales-cycle. CIS Benchmark misconfigurations carry their own direct cost: cloud misconfiguration remains one of the top root causes cited in cloud breach post-mortems year over year, and the fix for a benchmark failure is usually cheap — the cost is in not knowing it existed until an auditor or an attacker found it first.
What does a program that satisfies all three standards actually look like?
A program that satisfies ISO 27001:2022, NIST CSF 2.0, and CIS simultaneously runs cloud posture scanning and software supply chain controls as one evidence trail, not two. In practice that means CIS Benchmark scanning against your cloud provider's foundations benchmark (AWS v3.0, Azure, GCP) feeding the same reporting layer as your SBOM and build-provenance data, so a single control — say, ISO 8.25 or NIST GV.SC-04 — can be answered with one export instead of a screenshot from each tool. Mature programs also track this continuously rather than seasonally: CIS recommends automated compliance checks running on every deployment, not a quarterly manual review, and NIST CSF 2.0's Govern function explicitly expects risk management to be an ongoing process with defined roles, not an annual audit-week scramble. The organizations that pass transition audits and RFP security reviews without friction are the ones that can produce, on request, a mapping from a specific control number to a specific piece of evidence — a scan result, a signed commit, a build log — rather than reconstructing that mapping from memory when an assessor asks.
How Safeguard Helps
Safeguard is built to close exactly the gap that CNAPP-first tools like Wiz leave open: the software supply chain evidence that ISO/IEC 27001:2022's 8.25/8.28/8.29 cluster, NIST CSF 2.0's GV.SC category, and the CIS Software Supply Chain Security Guide all now expect. Instead of stopping at cloud posture, Safeguard maintains a continuous software bill of materials and build-provenance record for every application, mapping directly to the "where did this code come from and who reviewed it" question that a technological-theme ISO audit or a NIST Govern-function review will ask and that cloud configuration scans were never designed to answer. That evidence is designed to sit alongside — not replace — the CIS Benchmark and cloud posture data a platform like Wiz already produces, so teams don't have to rip out their CNAPP investment to close the supply chain gap; Safeguard's findings are built to feed the same audit trail rather than create a fourth dashboard to reconcile. For compliance teams heading into an ISO 27001:2022 transition audit, a NIST CSF 2.0 maturity assessment, or a CIS-based enterprise security questionnaire, that means a single, queryable mapping from control number to evidence — SBOM snapshots, provenance records, remediation timestamps — instead of assembling it by hand under deadline pressure.