CSA CCM gap assessment: what the audit misses and why it matters
Geert WarmenbolApril 29, 2026
TL;DR
29% of organizations with a current CSA STAR self-assessment still fail basic external vulnerability scans — compliance documentation and actual control effectiveness are measuring different things.
The average cloud provider CAIQ response is customized only 11% from the vendor template. That means 89% of your vendor assessment is the vendor''s marketing copy, not your environment.
CCM-IAM domains get the most audit attention and the most findings in real assessments — not because IAM is hard to understand, but because the shared responsibility line is where both sides assume the other is handling it.
Point-in-time STAR Level 2 audits have a structural problem: a cloud environment that passed in Q1 can drift into material non-compliance by Q3 with no triggering event. No framework requires you to catch that drift.
The post-quantum harvesting risk sits completely outside current CCM control objectives. Attackers storing encrypted cloud traffic today for future decryption is not a theoretical concern — the tooling exists and the economics already work.
Shadow APIs — endpoints not in any registry, not in any CAIQ response, not tested by any auditor — show up in 14% of Vulnox cloud assessments. CCM-TVM-01 does not address them.
The audit passed. Three weeks later, the breach happened.
A 60-person fintech in Amsterdam completed its CSA STAR Level 2 assessment in February. Independent auditor, full CAIQ review, SOC 2 bridge letter, the works. The CISO sent the certificate to the enterprise sales team the same afternoon. Six weeks later, an attacker was moving laterally inside their AWS environment via a misconfigured IAM role attached to a Lambda function — a function that had been deployed after the audit scope was frozen. The function was not in the CAIQ. The IAM role was not in the audit sample. The auditor never saw it. The CCM was technically satisfied. The breach was real.
That gap — between the date the evidence was collected and the date the attacker walked in — is not a failure of the framework. It is a structural property of how point-in-time assessments work. The CCM tells you what controls should exist. It does not tell you what happens to those controls on day 47 after the audit closes. Every organization treating STAR certification as a security guarantee is making a category error, and most of them do not realize it until something goes wrong.
The numbers that should make compliance teams uncomfortable
29%
Of CSA CCM-compliant organizations fail basic external vulnerability scans when tested independently after certification. Source: Vulnox assessment data, 2024–2025, across 80+ cloud environment reviews.
11%
Average customization rate of cloud provider CAIQ template responses. The other 89% is the vendor''s own characterization of their controls, applied wholesale to your shared-responsibility boundary. Source: Vulnox assessment data, 2024.
14%
Percentage of Vulnox cloud assessments that surface at least one exploitable shadow API — an endpoint not in any documentation, not registered in any CAIQ response, and not in scope for any auditor review. Source: Vulnox assessment data, 2024–2025.
12%
Percentage of MFA-protected login attempts that were bypassed at a STAR Level 1 certified fintech client due to default Okta Global Session Policy configuration permitting browser session reuse. The auditor had marked CCM-IAM-07 as satisfied. Source: Vulnox client engagement, 2024.
197
Control objectives in CCM v4 across 17 domains. Zero of them explicitly address AI-generated API surface discovery or post-quantum cryptographic harvesting — two attack vectors with active tooling as of 2025.
How CCM gap assessment actually works — and where the process breaks
A CSA CCM gap assessment maps your current security controls against the 197 objectives across 17 domains. The CAIQ is the questionnaire vehicle — 300+ yes/no questions where ''yes'' requires evidence: policy documents, screenshots, logs, configuration exports. The STAR program then layers assurance levels on top: Level 1 is self-attestation, Level 2 is third-party audit (typically bridged to SOC 2 or ISO 27001), Level 3 is continuous monitoring with real-time risk scoring.
The break points are not in the framework design. They are in three places that no framework document will tell you about.
First: evidence collection timing. Auditors accept evidence within a defined window — typically 12 months. A firewall rule screenshot from nine months ago satisfies the control. Whether that rule still exists today is not the auditor''s problem. For fast-moving cloud environments where infrastructure is code and deployments happen daily, nine-month-old evidence is archaeological.
Second: scope definition. Auditors review what is in scope. Cloud environments contain things that are not in scope — new services, shadow IT, developer sandboxes, third-party integrations added mid-year. The CAIQ does not ask ''what are all the things not in this questionnaire.'' It asks about the things you told it to ask about. A Lambda function deployed after scope freeze is invisible to the entire process.
Third: shared responsibility ambiguity at the control level. CCM-IAM-01 requires identity and access management. The cloud provider satisfies their portion — the IAM service exists and works. The customer satisfies their portion — they have an IAM policy document. Neither party is responsible for the gap between the policy document and the actual role assignments in production. That gap is where the misconfigured Lambda lives.
Example
CCM-DSP-07 requires data classification and handling procedures. A client''s CAIQ response listed their data classification policy — a 40-page document approved by the board. The auditor marked it satisfied. When Vulnox reviewed the actual S3 bucket configurations, 23 buckets containing customer PII were tagged ''internal'' rather than ''confidential'' because the team that built the data pipeline had not read the classification policy. The policy existed. The control objective was ''satisfied.'' The PII was accessible to any authenticated IAM principal in the account.
Run aws s3api list-buckets --query ''Buckets[].Name'' --output text | xargs -I{} aws s3api get-bucket-tagging --bucket {} 2>/dev/null to pull all bucket tags and cross-reference against your data classification matrix. Do it quarterly. Do not wait for the next audit cycle.
CCM vs ISO 27001 vs SOC 2: what each one actually tests
CSA CCM / STAR
Cloud-native control language, shared responsibility model explicitly addressed, maps to other frameworks. STAR Level 2 typically bridged to SOC 2 or ISO 27001 rather than standalone. Self-assessment at Level 1 is entirely self-reported with no verification obligation.
Best for vendor due diligence — the CAIQ gives you a structured question set to fire at cloud providers. Weakest for internal assurance because Level 1 is unverifiable and Level 2 inherits whatever scope limitations exist in the bridged audit.
ISO 27001
Broad ISMS scope, not cloud-specific. Requires risk treatment plans and continual improvement. Third-party certification with surveillance audits every year and full recertification every three. Controls in Annex A are high-level; cloud-specific implementation guidance comes from ISO 27017, which is supplementary.
Better for enterprise customers who want a recognized mark with ongoing assurance. Surveillance audits catch some drift that point-in-time assessments miss. Does not address cloud-native constructs like function-level IAM roles, container registries, or serverless event triggers.
SOC 2 Type II
Tests control effectiveness over a defined observation period (minimum six months). Trust Services Criteria are auditor-interpreted, not prescriptive. Scope is explicitly defined and limited. The report covers what happened during the period — not what is happening now.
The gold standard for US enterprise buyers. Type II observation period is the closest thing to continuous assurance in standard attestation practice. Still subject to scope exclusion problems. A SOC 2 report covering production does not cover the dev environment where the misconfigured IAM role started.
What Vulnox found across cloud assessments that clients did not expect
Assessment base: 80+ cloud environment assessments across fintech, healthcare, logistics, and SaaS providers in Europe and the US, 2022–2025.
STAR Level 1 certification with active MFA bypass
A fintech client in the payments sector held a current CSA STAR Level 1 self-assessment with CCM-IAM-07 marked satisfied. Their MFA implementation used Okta with default Global Session Policy settings that permitted browser-based session reuse after initial authentication. Testing showed approximately 12% of simulated login attempts could bypass MFA using captured session cookies from a previous authenticated session. The CAIQ response had documented ''MFA enforced for all users.'' That was technically accurate. ''Enforced'' and ''effective'' are not the same thing.
Self-assessment CAIQ responses reflect policy intent, not control effectiveness. An organization can accurately answer ''yes'' to CCM-IAM-07 while running a configuration that makes MFA functionally optional for any attacker with a network position.
Shadow API exposure invisible to CCM review
14% of Vulnox cloud assessments surface at least one exploitable API endpoint not present in any documentation, not registered in the API gateway, and therefore not in scope for any CCM control review. These endpoints typically emerge from deprecated microservices not fully decommissioned, developer testing endpoints promoted to production without change control, or third-party integrations that register their own endpoints during setup. CCM-TVM-01 addresses vulnerability and patch management — it does not address the attack surface you do not know exists.
A gap assessment against CCM v4 will not find what it is not looking for. Running your own API discovery before any CCM assessment — using traffic analysis on your load balancer or API gateway logs rather than documentation — changes the scope of what gets assessed.
Data classification policy satisfied, data classification practice absent
In multiple engagements across healthcare and fintech clients, Vulnox found a consistent pattern: CCM-DSP controls satisfied at the policy level, violated at the configuration level. A data handling policy existed, was board-approved, and was submitted as CAIQ evidence. Actual storage resource tagging — S3 buckets, Azure Blob containers, GCS buckets — reflected the tagging conventions of the teams that built the pipelines, not the classification scheme in the policy. The engineers had not read the policy. No process enforced alignment between policy language and infrastructure tags.
CCM DSP domain controls are satisfied by document existence, not by operational implementation. The 197 control objectives do not include ''verify that engineering teams are aware of and have implemented the stated policies.'' That verification is outside the framework.
What CCM v4 does not cover and auditors rarely flag
AI-generated attack surface discovery
An attacker can fine-tune an open-source model on publicly available cloud provider documentation, GitHub-sourced IAM policy examples, and API reference material, then use it to generate candidate API requests targeting undocumented parameters and edge cases in cloud services. This produces exploitable requests that no signature-based scanner would generate and no CCM control objective would prevent. CCM-TVM-01 covers vulnerability management against known vulnerabilities. It has no mechanism for unknown attack surface generated by adversarial AI tooling. This is not a future risk — the tooling exists today and requires no specialized capability to run.
Post-quantum cryptographic harvesting
CCM-IAM-05 addresses cryptographic controls and key management. It does not address the harvest-now-decrypt-later attack pattern where an attacker captures TLS session data from cloud API traffic today, stores it, and waits for quantum decryption capability to mature. Healthcare organizations with 10-year data retention requirements under HIPAA are structurally creating future exposure. The encrypted data they are obligated to retain is the inventory an attacker would want. No current CCM control requires post-quantum cryptography readiness or addresses this specific threat model.
Lateral movement inside VPC after perimeter breach
Network security controls in CCM''s IVS domain address perimeter controls, segmentation, and traffic monitoring. Auditors routinely mark IVS controls satisfied when firewall rules and security groups are correctly configured. What most audits do not test: what an attacker can reach if they compromise a single EC2 instance or Lambda function inside the VPC. A client put this exactly: ''We spent a fortune on Palo Alto firewalls, and our auditor said we passed the network security section. But when I asked if they tested lateral movement inside the VPCs if someone bypassed the perimeter, they said that was out of scope.'' It was out of scope because the CCM control did not require it. That is not the same as not being a risk.
Inherited compliance assumptions in multi-cloud deployments
When an organization runs workloads across AWS, Azure, and GCP simultaneously, each cloud provider submits a separate CAIQ. What no CAIQ covers: the integration layer. Data flowing from AWS S3 through an Azure Function to a GCP BigQuery dataset crosses three CAIQ boundaries. The controls at each boundary are documented. The controls governing transit between boundaries are not the responsibility of any single provider, and no CCM assessment methodology requires a unified view of the cross-cloud data path.
What clients say when CCM assessments fail to deliver — and what is actually happening
''The cloud provider gave us a pre-filled CAIQ. We submitted it. The auditor accepted it. We have no idea if any of it is true for our specific configuration.''
Root cause:Cloud provider CAIQ responses describe the provider''s infrastructure and shared-responsibility obligations — accurately, in most cases. They do not describe your configuration of that infrastructure. An AWS CAIQ response confirms that AWS IAM exists and functions as designed. It says nothing about whether your IAM policies follow least privilege, whether MFA is enforced for your root account, or whether your S3 buckets are publicly accessible. The 11% average customization rate means organizations are submitting 89% vendor marketing copy as their compliance evidence. Auditors accept it because the CCM control objective is written at a level of abstraction where the vendor response is technically sufficient.
''We passed our STAR Level 2 audit four months ago. Our pen test last month found a critical. How is that possible?''
Root cause:STAR Level 2 audits have a defined evidence window, typically the 12 months prior to the audit close date. The critical finding in the pen test likely involved a service, configuration, or integration that was deployed after the evidence was collected, or was not in the audit scope. Auditors are not wrong to accept in-scope evidence. The organization is wrong to assume that ''passed'' means ''currently secure.'' These are different claims. One is about a historical snapshot. The other is about present state. No compliance certification makes the second claim.
''Our auditor told us our IAM controls were compliant. Six weeks later we had an attacker in the environment through a Lambda IAM role. Did the auditor miss something?''
Root cause:Probably not, and that is the uncomfortable answer. The Lambda function was likely deployed after the audit scope was frozen. The IAM role was not in the sample. The auditor reviewed what they were shown and marked the controls they reviewed as satisfied. CCM does not require auditors to discover infrastructure you did not include in scope. Scope definition is the client''s responsibility. Most organizations define scope based on what they know about, which means new services — especially those created outside formal change control — are systematically excluded.
Where CCM compliance is heading — two predictions with evidence signals
By 2027, at least one major cloud data breach involving a CCM-compliant organization will be attributed specifically to a shadow API endpoint — triggering regulatory scrutiny of CAIQ completeness requirements.
14% shadow API exposure rate across current assessments, combined with zero CCM control objectives addressing unknown API surface, means this is a frequency question, not an existence question. The attack tooling to discover and exploit undocumented API endpoints is commodity. When a STAR-certified organization explains to a regulator that their API inventory was incomplete and their auditor never tested for it, the gap in the framework will become a compliance enforcement story.
Confidence: highNo major regulatory enforcement action citing API inventory gaps at a CCM-certified organization by end of 2027 — at which point the prediction fails and the attack pattern is being contained by other means.Post-quantum cryptographic readiness will be added as an explicit CCM control objective domain before 2028, driven by NIST PQC standard finalization and EU regulatory pressure on cloud providers.
NIST finalized its first post-quantum cryptography standards in August 2024. The EU''s NIS2 Directive requires member states to address emerging risks. CSA has historically added CCM domains in response to regulatory pressure — AI security controls were not in v3 and are nascent in v4. The structural pressure for a CCM PQC domain is building from multiple directions simultaneously.
Confidence: mediumCSA CCM v5 released without a post-quantum cryptography domain, or released after 2028.
Further Reading
Gap Analysis
framework gap analysisDigital Footprint
digital footprint analysisWhat is Gap Analysis in Compliance
understanding gap analysisNational Vulnerability Database Home
National Vulnerability DatabasePCI Security Standards Council
PCI Security Standards Council
Frequently Asked Questions
How do I perform a CSA CCM gap assessment without relying on cloud provider CAIQ templates?
Pull your actual infrastructure configuration first — AWS Config, Azure Policy compliance reports, GCP Asset Inventory — before touching the CAIQ. Map what you find to CCM domains yourself. Cloud provider CAIQ templates are customized only 11% on average across Vulnox assessments, meaning 89% of a template-only submission reflects vendor marketing, not your environment. Evidence should come from your configuration exports, not from a pre-filled questionnaire.
Why did we pass a STAR Level 2 audit but still get breached?
STAR Level 2 audits assess evidence collected within a defined window — typically 12 months prior to audit close. Any infrastructure deployed after scope freeze is invisible to the assessment. A Lambda function with a misconfigured IAM role deployed three weeks after audit close is not an auditor failure; it is a scope gap. The audit certified your environment as it existed during the evidence window, not as it exists today. Point-in-time certification and present-state security are different claims.
What CCM domains get the most findings in real cloud assessments?
IAM domains (CCM-IAM) surface the most findings in Vulnox assessments, followed by DSP (Data Security and Privacy) and IVS (Infrastructure and Virtualization Security). IAM findings concentrate at the shared responsibility boundary — both the cloud provider and the customer satisfy their CAIQ obligations, and the misconfiguration lives in the gap between them. DSP findings typically involve policy documents that exist but have not been operationalized in actual storage resource tagging or data handling procedures.
What does a shadow API have to do with CSA CCM compliance?
Shadow APIs — endpoints not in any documentation, API gateway registry, or CAIQ response — appear in 14% of Vulnox cloud assessments. CCM-TVM-01 covers vulnerability management against known vulnerabilities. It has no control objective requiring organizations to discover API endpoints they do not know exist. An auditor reviewing TVM-01 will assess the vulnerability management program you describe. They will not perform independent API discovery. Running traffic analysis against your load balancer or API gateway logs before any CCM assessment is the only way to find what is not in your documentation.
How does CSA CCM compare to SOC 2 for cloud vendor due diligence?
Use CCM and the CAIQ for vendor due diligence — the structured question set maps directly to cloud-specific shared responsibility boundaries in a way SOC 2 Trust Services Criteria do not. Use SOC 2 Type II for assurance about a vendor's internal control effectiveness over time, since the six-month-minimum observation period captures operational behavior rather than point-in-time evidence. The practical problem with both: scope exclusions. A SOC 2 Type II report covering production does not cover the dev environment where most misconfigurations originate.
What is the post-quantum risk that CCM does not address?
CCM-IAM-05 covers cryptographic controls and key management. It does not address harvest-now-decrypt-later attacks, where an adversary captures encrypted cloud API traffic today and stores it pending future quantum decryption capability. Healthcare organizations under HIPAA with 10-year data retention requirements are structurally accumulating the exact encrypted data inventory an attacker would target. No current CCM v4 control requires post-quantum cryptography readiness assessments or addresses this threat model. NIST finalized its first PQC standards in August 2024; CCM has not yet responded.
How long does a CSA CCM gap assessment take and how can it be shortened?
A thorough CCM gap assessment covering all 17 domains typically runs four to eight weeks depending on environment complexity and evidence availability. The largest time sink is evidence collection, particularly when engineering teams have not maintained policy-to-configuration traceability. Automating configuration exports from AWS Config, Azure Policy, and GCP Asset Inventory before the assessment starts cuts collection time by roughly half. The second largest time sink is CAIQ customization — treating cloud provider templates as a starting point rather than a submission cuts the risk of submitting inaccurate responses, but adds review time upfront.
Related Articles
GovRAMP Moderate authorization: why the Significant Change Request process catches providers off guard
GovRAMP Moderate is the first tier where you need a government sponsor, annual 3PAO reassessment, and a Significant Change Request process that can pause normal product releases for months. Most providers who stall post-authorization were not prepared for what maintaining Moderate status actually costs operationally.
GovRAMP Low+ authorization: the impact level that punishes providers who get the CUI boundary wrong
GovRAMP Low+ is where providers handling limited Controlled Unclassified Information land — or discover they should not be there. The defining failure is not a missing control. It is a CUI boundary that was drawn before anyone asked what data the government actually sends through the system.
GovRAMP High authorization: why FIPS-validated crypto and personnel security controls catch providers off guard
GovRAMP High is where cloud providers discover that having strong encryption is not the same as having FIPS 140-2 validated encryption — and that distinction alone has derailed authorizations from vendors who passed every other control family. The architectural constraints at High are qualitatively different from every lower tier.
Ready to Secure Your Digital Assets?
Get a comprehensive vulnerability assessment for your website today.