In brief
The problem. A customer has sent you a spreadsheet called the CAIQ: 283 questions from the Cloud Security Alliance, and nobody at your company owns security.
What most people do. They treat it as an exam: answer "Yes" to as much as possible, from scratch, for this one customer, and do it all again for the next one.
What works instead. Read the instructions CSA ships with it. "No" is a defined answer, there's a column for handing controls to your cloud provider, and the finished file can be published in CSA's registry for free. Answer it once, in three passes: inherit, own, admit.
The file arrives as an attachment with a long name, something like CAIQv4.1.0-star_security_questionnaire. You open it and scroll. Audit and assurance. Cryptography and key management. Twenty-eight questions about data centre security, for a company whose servers you have never seen because they belong to Amazon.
The usual reaction is to treat it like a pass-or-fail exam: find a "Yes" for every row, or something that sounds like one. That's a lot of work, and the result is worse than it needs to be.
The CAIQ isn't an exam. It's a standard form for describing who does what in a cloud supply chain, and its own instructions say so. It's built to be answered once, honestly, with "No" and "our cloud provider does this" as normal answers, and then published, so your next customer gets a link instead of a spreadsheet.
What the CAIQ actually is
CAIQ stands for Consensus Assessments Initiative Questionnaire. The Cloud Security Alliance (CSA) publishes it alongside its Cloud Controls Matrix, a catalogue of cloud security controls. The current version, released in January 2026, has 207 controls in 17 domains, and CAIQ v4.1 turns them into 283 yes-or-no questions. The previous version, v4.0, had 261. CSA accepts both until December 2027, so if your customer sent the older file, use it.
Customers like it because it's a known standard: they don't have to write their own questions, and they can compare your answers with every other vendor's. You can download it from CSA without an account.
The questions aren't spread evenly. Here's how the 283 break down in v4.1 (counted from CSA's file):
| Domain | Questions | Domain | Questions |
|---|---|---|---|
| Datacenter security | 28 | Business continuity and resilience | 19 |
| Data security and privacy | 24 | Identity and access management | 19 |
| Cryptography and key management | 23 | Logging and monitoring | 19 |
| Human resources | 20 | Supply chain management | 19 |
| Security incident management | 16 | Infrastructure security | 15 |
| Threat and vulnerability management | 15 | Endpoint management | 15 |
| Application and interface security | 13 | Change control and configuration | 12 |
| Governance, risk and compliance | 10 | Audit and assurance | 8 |
| Interoperability and portability | 8 |
The biggest domain, datacenter security, is mostly about physical buildings, power and environmental controls. If you run on AWS, Azure or Google Cloud, almost none of it is yours to operate.
The two columns most people never read
Each row has four columns to fill in. The first two matter most.
"CSP CAIQ Answer": Yes, No or NA. CSA's instructions in the file define all three. "Yes" means the part of the control the question covers is met. "No" means it's in scope and not met, and then you assign who is responsible and can explain why it isn't done and what will be done about it. "NA" means it doesn't apply to the service being assessed. In other words, the form expects "No", and asks you to say what happens next.
"SSRM Control Ownership". SSRM is CSA's shared security responsibility model. For every row you pick who owns the control, from six options:
| Option | What it means (paraphrasing CSA) |
|---|---|
| CSP-owned | You (the cloud service provider) do it, entirely |
| CSC-owned | Your customer does it, entirely |
| 3rd-party outsourced | A provider in your supply chain does it; CSA's example is "an IaaS provider". You remain fully accountable |
| Shared CSP and CSC | You and your customer share it |
| Shared CSP and 3rd-party | You and your provider share it; you remain accountable |
| Not Determined | It doesn't apply to anyone, or you're not sure who owns it |
The other two columns, "CSP Implementation Description" and "CSC Responsibilities", are marked optional but recommended. They're where your answer becomes believable: what you do, and what you need your customer to do.
Read together, these columns describe a small SaaS company's situation exactly. You built the application. A cloud provider runs the buildings, the hardware and much of the infrastructure. Your customer manages their own users. The CAIQ has a box for each of those facts.
Why it's built this way
The CAIQ was designed for cloud providers of every size, and almost all of them sit on top of someone else's infrastructure. CSA added the ownership column in version 4 to address the "lack of understanding of the shared responsibility model", which it called one of the biggest sources of risk in the cloud.
So the providers you build on answer the same questionnaire, and many publish theirs. AWS publishes its completed CAIQ on its website. Microsoft publishes CAIQ-based self-assessments for Azure, Dynamics 365 and Office 365 through CSA's registry. When a control is your provider's, your answer can point to theirs.
Customers reviewing you know this, and they don't expect a 30-person company to run its own data centre. What they're checking is whether you know which parts are yours.
Inherit, own, admit: answering the CAIQ in three passes
Don't answer the file top to bottom. Go through it three times, once for each kind of answer.
Pass 1: Inherit. Mark every control your cloud provider runs: physical security, hardware disposal, power, most of the datacenter domain, parts of infrastructure security and business continuity. Answer "Yes", choose "3rd-party outsourced" or "Shared CSP and 3rd-party", and in the description name the provider, the region and where their evidence lives. Inheriting a control doesn't hand off the accountability. CSA is explicit that you stay "fully accountable", so say which provider you use and why you trust it.
Pass 2: Own. Answer what you do yourself: access to production, MFA, code review, backups, encryption settings, onboarding and offboarding, your own vendors. These are "CSP-owned" or "Shared CSP and CSC". Write each description as a claim someone could check, and where your customer has a part to play (managing their own users, configuring SSO), say so in "CSC Responsibilities".
Pass 3: Admit. Whatever is left is a gap. Answer "No", assign the owner, and use the description to say what you do instead and when it will change. Don't reach for "NA" to hide a gap: NA means out of scope, and a reviewer can tell the difference.
Here's what that looks like for a hypothetical 30-person SaaS company on AWS (illustrative examples, with the questions paraphrased):
| Question topic | Answer | Ownership | Description |
|---|---|---|---|
| Physical access to data centres is controlled | Yes | 3rd-party outsourced | Hosted on AWS in eu-west-2. Physical security is operated by AWS; see AWS's published CAIQ and its SOC 2 report via AWS Artifact. |
| MFA for administrative access | Yes | CSP-owned | MFA enforced at our identity provider for all staff. Production access only through SSO; no shared accounts. |
| Customer user access is managed | Yes | Shared CSP and CSC | We provide SSO and MFA settings. Customer admins add, remove and review their own users. |
| Security logs are centrally monitored | No | CSP-owned | No dedicated monitoring tool yet. Authentication and admin events are logged and retained for 90 days, with alerts on failed admin logins. A central log tool is planned for Q2 2027. |
The last row is the useful one. It's honest, specific and shows a plan, and it's exactly what CSA's own instructions ask a "No" to contain.
apimade, a Hacker News commenter who says they regularly help companies get through these reviews, suggests starting the same way: "Start by pre-filling your own CAIQ v4 with an earnest 'we don't do this' or 'we haven't even thought about this' attempt." Then fix what's cheap to fix, and own the rest.
Answer it once, then publish it
Most companies fill in a CAIQ, attach it to an email, and start again when the next customer sends one. The CAIQ is meant to be reused.
Submitting your completed CAIQ to CSA's STAR Registry, its public list of cloud security self-assessments, is called STAR Level 1. According to CSA's pricing guide, it costs nothing. An optional automated review, Valid-AI-ted, costs $595 and is free for CSA members. When we checked in November 2026, 2,883 organisations were listed. Listings expire, so treat it as a document you update, not a one-off.
You don't have to publish it to get the benefit. Even kept private, one maintained CAIQ becomes the source for every other questionnaire you're sent, because most of them ask the same things in a different order. One Hacker News commenter who had to deal with exactly this put it plainly: "Pick some sort of standard, for example CAIQ and have an always-up-to-date version of it. You'd be surprised how many customers would accept it if you tell them 'hey - we use a standard - is this acceptable?'"
If you have a public security page, link the CAIQ from it.
The hard case: when it isn't enough
Two warnings.
Some customers will still send their own questionnaire. One commenter whose company had a SOC 2 Type II report and a CAIQ described pointing a customer to both: "they told us to still fill the questionnaire..." A finished CAIQ doesn't always get you out of the work. It turns the work into copying and adjusting answers you already have, instead of researching them from scratch.
Don't build things just because a row asks about them. The CAIQ covers everything a cloud provider might do, so some questions won't fit your product. Thomas Ptacek, a well-known security engineer, was blunt about this: "Please don't do any extra engineering for your wiki project simply because it appears on the Cloud Security Alliance CAIQ worksheet." Answer "No" or "NA" truthfully, and spend engineering time on the gaps your customers actually care about.
Your first week
| Day | Do this |
|---|---|
| 1 | Download the version your customer sent (or v4.1) from CSA. Ask the customer for the real deadline and whether your security page or existing reports can cover any sections. |
| 2 | Inherit: find your cloud provider's published CAIQ or SOC 2 report. Mark every control they run, with the provider and region in the description. |
| 3–4 | Own: answer what you do yourself, each description written as a claim someone could check. Note what your customer is responsible for. |
| 5 | Admit: answer the gaps "No", with what you do instead and a date. One person rereads every answer for consistency, then send it with a short note listing your gaps up front. |
After that, keep the file. Update it when something changes, and decide whether to list it in the STAR Registry.
283 questions sounds like an exam. It's really a form that asks you to say, honestly, who does what, and you only need to fill it in once.
Sources
- Cloud Security Alliance, CCM v4.1 and CAIQ v4.1 download (CAIQ v4.1.0 file: question counts, answer definitions and ownership options are from its Introduction tab)
- Cloud Security Alliance, The CSA Cloud Controls Matrix v4.1 (2025)
- Cloud Security Alliance, CCM v4.1 transition timeline (2026)
- Cloud Security Alliance, CAIQ v4 released: changes from v3.1 (2021)
- Cloud Security Alliance, STAR Program Pricing Guide (2026) and STAR Registry
- AWS, Cloud Security Alliance compliance page
- Microsoft, CSA STAR Self-Assessment
- Hacker News comments: temikus (2023), mathie25 (2021), apimade (2026), tptacek (2026)