CAIQ

How to answer the CAIQ: a step-by-step guide for cloud vendors

A prospect has sent you the CAIQ — the Cloud Security Alliance's Consensus Assessments Initiative Questionnaire — and it looks like every other security spreadsheet until you notice the column asking who owns each control. That column is the whole point. This guide covers what makes the CAIQ different from a SIG or a custom questionnaire, and the sequence for answering it without misclassifying half your controls.

CAIQ vs SIG: same job, different lineage

The SIG is a general-purpose third-party risk questionnaire; the CAIQ is built specifically for cloud services. Every CAIQ question is generated from the CSA's Cloud Controls Matrix (CCM), a control framework written for the realities of multi-tenant infrastructure: virtualization, container orchestration, API security, tenant isolation. The current version, CAIQ v4, tracks CCM v4 — 17 domains, each question carrying a control ID like IAM-08 or DSP-10.

Practically, this means two things. First, your answers are portable: a cited answer keyed to CEK-03 answers that control for every buyer who sends a CAIQ, and maps cleanly to other frameworks via the CCM's published mappings. Second, the reviewer on the other side is probably cloud-literate — vague answers about "industry-standard encryption" land worse here than on a generic questionnaire.

The SSRM column: who actually owns each control

CAIQ v4's defining feature is the Shared Security Responsibility Model (SSRM) declaration. For each control, you state whether it is:

  • CSC-owned — you, the cloud service customer of your own providers, implement it yourself. Your code, your IAM policies, your key rotation.
  • CSP-owned (inherited) — your infrastructure provider implements it entirely. Physical data-center security on AWS is Amazon's control, not yours, and pretending otherwise reads as either confusion or padding.
  • Shared — both parties hold a piece. Encryption at rest is the classic case: the provider supplies the KMS, you decide what gets encrypted and who holds the keys.
  • Third-party — delegated to a subprocessor other than your CSP.

Getting SSRM ownership wrong is the most common CAIQ failure. Claiming you "own" physical security when you run on GCP tells the reviewer you don't understand your own stack. Marking everything "inherited" tells them you don't run anything. The honest distribution — a mix, with shared controls explained in a sentence — is what an experienced reviewer expects to see.

STAR Registry Level 1: answer once, in public

The CAIQ has an exit most questionnaires don't: the CSA STAR Registry. At Level 1, you publish your completed CAIQ as a public self-assessment. Prospects who accept STAR entries — and a growing share of cloud-savvy procurement teams do — download your answers instead of sending you a spreadsheet. You answer the questionnaire once, on your own schedule, instead of once per deal under deadline pressure.

The trade-off is real: a published CAIQ is a public statement of your posture, including the gaps, and it needs maintenance as your stack changes. For a vendor fielding a few CAIQs a year, per-customer responses may be less work. For a vendor fielding one a month, Level 1 usually pays for itself quickly.

How to answer the CAIQ, step by step

  1. Confirm the version and edition. Check whether you've received CAIQ v4 or an older v3.1, and whether it's the full questionnaire or CAIQ-Lite. The control IDs differ between versions, and your answers should cite the IDs you were actually sent.
  2. Stand up an answer library before writing anything. Start from our free answer-library template and key each row to a CCM control ID instead of a SIG row. Every answer you write this week is one you reuse on the next CAIQ — and, via the CCM's cross-framework mappings, on most other questionnaires too.
  3. Mark SSRM ownership for every control before drafting answers. Go through the whole questionnaire tagging each control CSC-owned, CSP-inherited, shared, or third-party. Doing this as a separate pass keeps the classifications consistent — the most common review finding is ownership that contradicts itself between domains.
  4. Inherit provider attestations for everything CSP-owned. For inherited controls, cite the provider's evidence, not your own: AWS's SOC 2 and ISO certificates, Azure's compliance documentation, your CSP's own STAR entry. "Inherited from AWS; see AWS SOC 2 Type II, available under their Artifact program" is a complete, correct answer.
  5. Draft the controls you own, citing named tools and policies. For CSC-owned and shared controls, answer to what you actually run — the tool, the policy name, the cadence. Shared controls get one extra sentence stating which half is yours.
  6. Make the publish-or-respond decision. Once the CAIQ is complete, decide whether to submit it to this one buyer or publish it to the STAR Registry at Level 1. If this is your second or third CAIQ this year, the registry is probably the better return on the work you just did.

When the answer is no: closing CAIQ-specific gaps

CAIQ "no" answers cluster in the logging, identity, and vulnerability domains of the CCM — the provider-inherited rows are usually fine; the customer-owned rows are where gaps live. Each is deployable as an open-source component you keep:

  • Logging & monitoring (LOG): Managed Wazuh — your side of the shared-responsibility logging rows, with retention.
  • Identity & access (IAM): Managed Keycloak — SSO and MFA for the customer-owned identity controls.
  • Threat & vulnerability (TVM): Managed OpenVAS — the scanning cadence the TVM rows assume exists.

CAIQ-Lite: the triage edition

CAIQ-Lite cuts the full questionnaire down to a screening subset. Receiving it is information: the buyer considers you lower-risk, or is qualifying vendors before a deeper pass. Answer it with the same CCM-keyed library and the same SSRM discipline — if the deal progresses, the full CAIQ that follows will reuse most of the work, and inconsistencies between your Lite and full answers are exactly what reviewers grep for.

The general discipline — triage first, answer honestly, build the library as you go — is covered in our guide to answering security questionnaires; everything above is what's specific to the CAIQ. If the deadline is short and nobody on the team has mapped controls to the CCM before, ThinSky's Questionnaire Rescue drafts the whole thing, SSRM column included, in about 3 days.

Common questions.

What is the CAIQ questionnaire?

The CAIQ (Consensus Assessments Initiative Questionnaire) is the Cloud Security Alliance's standardized questionnaire for cloud service providers. It is generated directly from the CSA Cloud Controls Matrix, so every question carries a CCM control ID, and buyers use it to assess SaaS, PaaS, and IaaS vendors specifically.

What does SSRM mean in the CAIQ?

SSRM stands for Shared Security Responsibility Model. CAIQ v4 asks you to declare, per control, whether it is owned by you, inherited from your cloud provider, shared between you, or delegated to a third party. It is the column that distinguishes the CAIQ from every other questionnaire format.

What is the CSA STAR Registry?

STAR is the Cloud Security Alliance's public registry of provider assessments. At Level 1, you publish your completed CAIQ as a self-assessment that any prospect can download — answering the questionnaire once, in public, instead of once per customer. Level 2 adds third-party certification on top.

What is CAIQ-Lite?

CAIQ-Lite is a condensed subset of the full CAIQ, cut down for early-stage vendor screening. If you receive the Lite version, the buyer has classified you as lower risk or is doing a first pass — but your answers should still map to the same CCM control IDs, because the full version may follow.

Or skip the spreadsheet entirely.

Email us the questionnaire, the deadline, and a sentence about the deal — we reply with scope and a fixed quote within one business day.

Get questionnaire rescue →