The Cloud Controls Matrix (CCM): Manual vs. AI-Assisted Vendor Assessment

Most teams that assess cloud vendors already have a general idea of the Consensus Assessment Initiative Questionnaire (CAIQ) and Cloud Controls Matrix (CCM). However, you may not have a good answer for what it takes to run that assessment. Turning a vendor's trust center page, SOC 2 report, and security policy into a structured, defensible view of CCM control coverage is a different problem entirely. That's the part this article is about: what mapping evidence to it looks like today, and where an AI-assisted alternative changes the equation.

If you want a more comprehensive look at CAIQ first, read our full breakdown. This article extends on that.

What CCM and CAIQ cover, briefly

CAIQ is the Cloud Security Alliance's (CSA) standardized, industry-accepted way for a cloud provider to document its security posture in a consistent, comparable format. CCM is the underlying control framework CAIQ maps to.

Both are actively maintained, which matters for anyone building a mapping process around them. CSA released CCM v4.1 in January 2026, succeeding v4.0.13. The current CAIQ v4.1 maps 283 yes-or-no questions to the 17 domains of CCM, up from 261 in the prior v4.0.13 release.

Those domains span the working surface of a cloud service. Identity and access management, cryptography and key management, data center security, logging and monitoring, supply chain management, and threat and vulnerability management are all in scope, among others. CSA is accepting submissions built on either v4.0.x or v4.1 through the Security, Trust, Assurance, and Risk Registry until the end of 2027, meaning both versions are still in circulation. That last point turns out to matter more than it might seem.

Why mapping CAIQ and CCM evidence is harder than it looks

On paper, CAIQ and CCM assessment sounds straightforward. You get the vendor's evidence, check it against the domains, and note what's covered. In practice, three things make that harder than it looks:

• The evidence is scattered and unstructured: A single vendor's evidence set might include a trust center page, a SOC 2 report, an ISO 27001 certificate, a penetration test summary, and a handful of policy documents. Each is in a different format and written for a different audience. None of them are pre-organized around the domain structure of CCM. Someone has to read all of it and, paragraph by paragraph, decide which parts speak to which control.
• A completed CAIQ isn't the same as verified evidence: A fully answered CAIQ can create more work than a collection of raw documents. Every answer on a CAIQ is the vendor's own "yes" or "no" self-attestation against a control. It isn't independent proof that the control exists or works.
• Evidence and versions both go stale: Certificates expire. The SOC 2 review periods lapse. And, right now, a vendor might hand over a CAIQ built on an older release — v3.1, or the still-widely-used v4.0.13 — while your own program has already moved to v4.1's updated domains and question set. Multiply that across a portfolio of vendors reassessed on different cycles, and it's common to end up with a spreadsheet where no one is entirely sure which version of which framework any given row of evidence maps to.

Here’s what running a CCM assessment by hand often looks like. You start with the CCM and CAIQ spreadsheet or an internal evidence-mapping tracker. You then request or collect the vendor’s security documents, such as a SOC 2 report, an ISO 27001 certificate, policies, a penetration test summary, or a completed CAIQ. 

You read through each document and manually map relevant evidence back to the applicable CCM domains and controls. Next, you’ll flag controls where the evidence is missing, unclear, or insufficient. Then, you’ll need to draft a follow-up questionnaire or email to close the gaps and wait for the vendor to respond. Finally, you’ll need to update the tracker, reassess the evidence, and repeat the process until the team has enough confidence to make a risk decision.

Each step sounds reasonable in isolation, but the problem is what happens at scale. This process doesn't scale beyond a handful of vendors before it becomes a bottleneck. It's inconsistent between analysts — two people reviewing the same SOC 2 report may tag it against different controls, with no easy way to reconcile the difference later. And, critically, analysts have to redo almost all of it if the same vendor is reassessed against a different framework.

None of this reflects badly on the analysts doing it. It's what happens when a genuinely useful, evidence-based approach to assessment runs into the limits of a spreadsheet and a shared drive.

The AI-assisted alternative

The alternative starts the same way, with the vendor's existing evidence, but changes what happens next. Apply a CCM UpGuard Security Profile to the vendor, then upload or link the same evidence set: trust center documentation, the SOC 2 report, and the penetration test summary. From there, AI-assisted document parsing reads that evidence and maps it directly to CCM domains and controls, and the individual checks under each. Every check gets marked as covered, partially covered, or not covered. What took hours to do manually now takes minutes, resulting in a more thorough, check-level view than most manual reviews can produce.

The gap questionnaire that follows covers only what the AI-assisted review flagged as missing, not a full CAIQ resend. That matters beyond just saving the analyst's time: vendors respond faster to a short, specific ask than to a long, generic one. Roughly one in three vendors respond to these targeted gap questionnaires in under two days. Five pointed questions create far less vendor fatigue than a 283-question form landing in someone's inbox for the third time in a year.

Once the team reviews the evidence and closes any gaps, generating the framework-aligned risk assessment report takes less than 60 seconds. The output is a stakeholder-ready, fully written and structured report that brings together the in-scope evidence, risk management activities, control coverage details, and an overall assessment summary. 

What happens when the vendor needs to be reassessed against a different framework later

This is where the two approaches diverge most, and it's the part worth planning around before it becomes urgent. In the manual model, reassessing a vendor originally evaluated on CAIQ and CCM against NIST SP 800-53 because a new contract requirement or regulatory driver calls for it usually means starting the evidence review almost from scratch. Analysts built the spreadsheet tags around the structure of CCM; they don't automatically mean anything in a different framework's control set.

An evidence model built around an underlying layer of controls, checks, and questions, rather than one tied to a single static questionnaire, handles this differently. Because UpGuard Vendor Risk maps evidence at the underlying level, relevant control coverage can carry over across supported frameworks where the underlying mappings genuinely apply.

That's a significantly narrower claim than evidence transfers automatically and completely. Some controls in a new framework won't have an equivalent in the old one, and those will still need fresh evidence or a follow-up. But for the coverage that does map across, a vendor assessed at intake on CAIQ and CCM and later reassessed on NIST SP 800-53 doesn't have to reduce every piece of evidence the team has already reviewed and verified; that part’s instant.

See it applied to a real evidence set

Reading about check-level evidence mapping is one thing. Watching it run against a trust center page and SOC 2 report is another. Take a walkthrough of UpGuard Vendor Risk’s Security Profiles to see how a CAIQ and CCM assessment moves from uploaded evidence to a framework-aligned report.