A vendor security questionnaire is the first real audit most startups ever face, and it arrives at the worst possible moment: your first enterprise deal, or your first regulated buyer, right when the team is six people and nobody owns compliance. The deal is real, the questions are hundreds of rows long, and every honest answer feels like it costs you the contract.
Generic advice on this topic is unhelpful in a specific way. It tells you to "get SOC 2" and stop worrying. That misses what is actually happening. In 2026 the questionnaire is no longer a procurement formality; for a bank in Singapore or a financial entity in the EU it is how the buyer discharges a legal obligation, and their own regulator will read the answers. Your report satisfies part of it and never all of it.
This post covers what those questionnaires now ask, why regulated buyers cannot simply waive them, and how a small team answers honestly without either lying or losing. Where I am stating practitioner judgement rather than published requirement, I have labelled it inline.
Quick context: what changed by 2026
Three things moved at once. Questionnaire content expanded to cover AI and operational resilience, not just encryption and access control. Regulators in Singapore and the EU turned third-party due diligence into a documented, submitted, auditable artefact rather than a private judgement call. And the chain got longer: buyers now ask about your subcontractors with the same seriousness they ask about you.
The practical consequence for a lean team is that ad-hoc answering does not scale. The same questions arrive in different formats from every buyer, the answers must agree with each other, and a contradiction between last quarter's response and this quarter's is a finding. What follows is the order I would work through it.
1. Identify which questionnaire you were actually sent
Before answering a single row, work out what is in front of you. The two dominant standard formats are the Standardized Information Gathering questionnaire from Shared Assessments, which covers third-party risk across every vendor type, and the Consensus Assessments Initiative Questionnaire from the Cloud Security Alliance, which is cloud-specific and maps one-to-one onto the Cloud Controls Matrix. CAIQ v4 carries 261 questions and adds explicit Shared Responsibility Model columns, so it asks not only whether a control exists but who owns it, you or your cloud provider.
SIG comes in tiers, from a shorter Lite through a full Core that runs into the hundreds of questions, and access is a paid Shared Assessments subscription on the issuing side. The third category is the bespoke spreadsheet a buyer's security team wrote themselves, which is usually a subset of the other two with local additions.
This matters because the underlying controls overlap heavily. One well-built answer serves SIG, CAIQ and most bespoke sheets. Identifying the format tells you which mapping to reach for, not how much new work to do.
Takeaway: name the format and its parent framework before answering, and you convert three projects into one.
2. The 2026 SIG asks about AI, and most small teams have no answer
Shared Assessments published its 2026 SIG update with AI governance and operational resilience codified as standard content rather than optional extras, including mappings to ISO/IEC 42001, the AI management system standard. The questionnaire now walks the AI lifecycle: what data trains or fine-tunes a model, how the model is deployed, how bias and drift are monitored, and what happens to customer data sent to a third-party model provider.
Startups get caught here for an ordinary reason. The product ships an LLM feature, the feature calls a hosted model API, and nobody has written down whether prompts containing customer data leave the tenancy, whether the provider trains on them, or which contract governs that. The control exists in someone's head or in a settings toggle nobody documented.
Fixing it is cheap relative to its weight in a review. Write one page: every model or AI service you call, what data reaches it, the data-retention and training terms in that provider's agreement, and who approved the integration. That page answers most of the new AI block and doubles as your ISO 42001 starting point if a buyer later asks for one.
Takeaway: your AI features are now in scope for vendor review; inventory them before a buyer forces you to.
3. When a Singapore bank asks, it is discharging a legal duty
If your buyer is a Singapore bank, the questionnaire is downstream of MAS Notice 658, which took effect on 11 December 2024, alongside the revised Guidelines on Outsourcing. The Notice requires banks to perform due diligence on service providers and their subcontractors, to include specific terms in outsourcing agreements, to maintain an outsourcing register, and to obtain customer consent where subcontracting involves disclosure of customer information.
Two details change how you should respond. Diligence is not one-and-done: it must happen before the service is received and again within the first 24 months, or at a board-approved frequency, whichever is earlier. So expect to be re-assessed, and expect your answers to be compared against the previous set. Second, the trigger that raises the bar is whether the arrangement is a material ongoing outsourced relevant service or involves customer information reaching you. A read-only analytics tool and a system holding customer records are not treated alike.
Practitioner opinion: asking the buyer which of those two triggers applies to you is the single highest-value question you can ask in the kickoff call. It tells you whether you are facing a light review or a full one, and buyers answer it readily because their own controls turn on it.
Takeaway: ask early whether you are material or customer-information-touching; the answer sets the entire scope.
4. Under DORA you are a row in a register, and so are your subcontractors
Selling to an EU financial entity puts you inside the Digital Operational Resilience Act. Article 28(3) requires the financial entity to maintain a register of information covering every contractual arrangement for ICT services, including provider details, service scope, locations, criticality classification and the subcontracting chain supporting critical or important functions. Registers are reported to competent authorities annually, and the European Supervisory Authorities ran a voluntary dry run before the regime went live precisely because the data quality was expected to be difficult.
What this means for a small vendor is unglamorous and specific. Your buyer needs structured facts about you in a fixed schema: legal entity identifier, country of your headquarters, the countries where the service is performed and where data is stored, and the identity of every subcontractor in the chain that supports the function. Free-text prose does not fit their form.
Give them the fields directly. A short "regulatory data sheet" listing entity name and identifiers, hosting regions, data locations, and your named subcontractors saves the buyer's third-party risk team a week and makes you visibly easier to onboard than the competitor who sent a PDF.
Takeaway: publish your register fields as structured data; it is the cheapest procurement advantage available to a small vendor.
5. "No, and here is the date" beats a soft yes
The strongest answer a small team can give to a control it has not implemented is a plain no with a compensating control and a committed date. The weakest is a yes that a follow-up call unwinds. Reviewers read hundreds of these; ambiguity is the pattern they are trained to pull on, and one unwound yes contaminates every other answer you gave.
The format that works is three sentences. State the current position without hedging. Name what stands in for the missing control today, with the specific mechanism, not a category. Give a date and an owner. For example: no formal SIEM today; CloudTrail and application logs go to a dedicated logging account with 400-day retention and alerting on root and IAM policy changes; managed SIEM onboarding is scheduled for Q4 with the CTO as owner.
Practitioner opinion: reviewers approve gaps with dates far more often than teams expect, and almost never approve a control they discover was overstated. The honest no also protects you contractually, because a questionnaire answer typically survives into the agreement as a representation.
Takeaway: answer every gap as position, compensating control, date and owner; never as a qualified yes.
6. Build one answer library, not twenty questionnaires
The scaling move is to stop treating each questionnaire as a document and start treating it as a query against a library you own. Write control statements once, each with a stable identifier, the evidence that proves it, the date it was last verified, and a named owner. Then map each statement to the frameworks the questionnaires derive from, primarily the Cloud Controls Matrix, since CAIQ is CCM restated as questions.
Keep it in version control next to the code, not in a spreadsheet on someone's laptop. Plain markdown files in a repository give you review, history and blame for free, which is exactly what you need when a buyer asks why an answer changed between assessments. A pull request that updates a control statement is also the natural place to attach the new evidence.
The payoff compounds. The first questionnaire costs you two weeks. The fifth costs a day, because the work is selecting and adapting existing statements rather than reconstructing the truth about your own systems each time.
Takeaway: control statements in git with owners and verification dates; questionnaires become assembly, not archaeology.
7. Deflect inbound with a trust page and a free STAR listing
Once the library exists, publish the safe subset. A public trust page carrying your architecture summary, hosting regions, subprocessor list, encryption posture, incident contact and current certifications answers a large share of first-round questions before anyone emails you.
Then submit a CAIQ to the CSA STAR Registry at Level 1. Level 1 is a self-assessment, it is free, and the listing is public; you keep it current with an annual update. It is not an audit and no buyer will mistake it for one, but it is a dated, public, structured statement of your controls, which is more than most pre-revenue vendors can show. CSA also offers a paid Valid-AI-ted variant that machine-checks the submission for completeness and consistency if you want a stronger signal later.
Practitioner opinion: the trust page earns its keep in sales cycle time rather than in security. It moves the questionnaire from the start of the deal, where it stalls momentum, to the end, where it is a formality.
Takeaway: publish the trust page first, then take the free STAR Level 1 listing; both are one-time work that answers questions repeatedly.
8. Your subcontractors are now the question
Both MAS Notice 658 and DORA push diligence past you and into whoever you depend on. That includes your cloud provider, but the parts that catch teams out are the smaller ones: the transactional email service, the error tracker holding stack traces with customer identifiers, the support desk, the analytics tool, the model API. Each one is a subprocessor if customer data reaches it.
Build the list before you are asked. For each entry record what the vendor does, exactly what data reaches it, where that data is processed, whether a data processing agreement is signed, and what happens to your service if the vendor disappears. That last column is the operational resilience question underneath the compliance one, and it is worth answering for yourself regardless of who is asking.
Flow-down is the other half. Regulated buyers expect the security and audit terms in your contract to reach your subcontractors, so check that your own vendor agreements do not silently stop those obligations at the first hop.
Takeaway: maintain a subprocessor list with data, location, agreement status and failure impact; it is requested in nearly every regulated review.
9. The evidence pack, and what you can push back on
Answers get verified. Assemble the artefacts once and keep them current: a one-page architecture and data-flow diagram, proof that MFA is enforced on all human access, your logging and retention configuration, a dated restore test result, your access review record, your incident response runbook with contact paths, and your most recent penetration test or vulnerability scan output. Seven artefacts cover the overwhelming majority of evidence requests.
Push back where the ask does not fit the risk. Practitioner opinion: on-site audit rights against a six-person remote team, uncapped liability, and one-hour incident notification clauses are all negotiable, and the way to negotiate them is to offer the substitute rather than refuse. Offer a documented remote walkthrough instead of a site visit. Offer a liability cap tied to contract value. Offer notification without undue delay and no later than a window you can genuinely hit, given that you have no follow-the-sun rotation.
What you should never negotiate is accuracy. A commitment you cannot meet is worse than a gap you disclosed, because the first is a breach and the second is a roadmap item.
Takeaway: keep seven artefacts current, negotiate scope by offering substitutes, and never trade accuracy for speed.
Summary: the questionnaire landscape and what each piece demands
| What arrives | Who issues it | What it really tests | Your one-time investment |
|---|
| CAIQ v4 | Cloud Security Alliance | Cloud controls plus who owns each one | Control statements mapped to CCM |
| SIG Lite or Core | Shared Assessments subscriber | Broad third-party risk, now AI and resilience | Same library, plus an AI inventory |
| Bespoke spreadsheet | Buyer's security team | Local concerns on a standard base | Answer library reuse |
| MAS-driven review | Singapore bank or FI | Materiality and customer-information handling | Scope question asked at kickoff |
| DORA register request | EU financial entity | Structured facts and the subcontract chain | Regulatory data sheet |
| Evidence request | Any reviewer, second round | Whether the answers were true | Seven-artefact evidence pack |
What to do at your stage
Early, one to five engineers, first enterprise conversation. Two things this month. Write the subprocessor list and the AI inventory, because they are pure documentation and they unblock the two newest question blocks. Then publish a trust page with hosting regions, encryption posture and an incident contact. Skip the certifications conversation entirely until a buyer names one.
Growing, five to twenty engineers, deals stalling on security review. Stand up the answer library in git with owners and verification dates, and submit CAIQ to STAR Level 1 so there is a public, dated statement of your controls. Assemble the evidence pack and run one access review so the artefact exists with a real date on it. This is the stage where the investment pays back within two deals.
Regulated buyers in the picture. Ask every financial-sector prospect which regime drives their review and whether you are material or customer-information-touching. Build the regulatory data sheet for DORA registers, check that audit and security terms flow down to your own vendors, and get the certification your buyers actually name rather than the one that sounds most impressive.
If you want a second pair of eyes on what your current answers would survive, that is what a short outside review is good at: reading your real cloud configuration against the controls a questionnaire claims, before a buyer's reviewer does it for you. MatrixGard runs a free cloud posture check covering identity, logging, data handling and recovery, and returns a written report. Start it from the cloud security checklist on the homepage.
About the author
Avinash S is the founder of MatrixGard, a fractional DevSecOps practice that acts as the cloud, infrastructure and security team for early-stage startups, funded or bootstrapped, across India, Singapore, the UAE, the US and the UK. He works on cloud cost, platform stability and security posture for teams too small for a dedicated platform hire and too exposed to keep postponing one.
Methodology note
Every regulatory and framework claim here comes from a named public source, linked inline: MAS Notice 658 and its December 2024 effective date from the Monetary Authority of Singapore; the register of information and subcontracting obligations from DORA Article 28 and the European Supervisory Authorities' dry-run announcement; questionnaire structure from the Cloud Security Alliance's CAIQ and STAR Registry documentation and from Shared Assessments' published 2026 SIG update. Statements reflecting judgement rather than published requirement are labelled practitioner opinion inline. No client engagements, deal outcomes, customer names or private assessment data appear anywhere in this post, and no figures have been estimated or invented.
