Answering a security questionnaire with no security team

A security questionnaire shows up when a bigger customer, insurer, or partner wants to do business with you but their own procurement or risk team requires proof you won’t be the weak link in their supply chain. It might be a formal SIG or CAIQ, or it might be a spreadsheet someone in their legal department cobbled together from three other questionnaires. Either way, it lands in your inbox with a deadline and anywhere from forty to three hundred questions, and there’s rarely anyone internally whose job it is to answer it.

The three common formats you’ll run into

Most questionnaires fall into one of three shapes. The SIG (Standardized Information Gathering questionnaire), built by Shared Assessments, is the long-form version larger enterprises use — SIG Lite runs roughly 100–150 questions, the full SIG can run past 300, covering everything from HR background checks to encryption standards. The CAIQ (Consensus Assessments Initiative Questionnaire), from the Cloud Security Alliance, shows up if you sell any kind of SaaS, cloud-hosted, or API-connected product; it maps to the CSA’s Cloud Controls Matrix and leans heavily on cloud infrastructure and data-handling questions.

The third — and most common for a small business — is a custom spreadsheet built in-house by the customer’s IT, legal, or compliance team. These borrow language from SIG and CAIQ but are shorter, less standardized, and sometimes include questions that don’t quite apply to a company your size, like a question about physical data center access controls when you’re on shared cloud hosting. Don’t skip those — answer them as they actually apply to your setup rather than leaving the row blank.

Why it landed with no warning

The purpose of a security questionnaire is risk transfer and documentation. The company sending it isn’t singling you out; their own auditors, cyber insurer, or a framework like SOC 2 or ISO 27001 requires them to show they vetted every vendor who touches their data or systems before signing a contract. That check usually triggers automatically once a deal crosses a dollar threshold or a vendor gets access to customer data. Treat it as a normal, procedural step in closing the deal, not a red flag about your security — but also not something to rush through with guesses.

Before you write a single answer, read the whole document once and sort every question into one of three buckets. This alone cuts the work in half, because most of a questionnaire doesn’t actually require you to have a security team — it requires you to honestly describe what you already do.

Bucket 1: questions about your website or application

These are questions like “Is your application tested for vulnerabilities by a third party?” or “Do you enforce MFA for administrative access?” — anything describing your live site, app, or infrastructure. A reviewer can often independently verify pieces of it, like SSL configuration or exposed subdomains, with free tools in under a minute, so a vague or inflated answer here is the fastest way to get flagged for follow-up. This is the bucket where you want real, dated evidence behind every answer, not a best guess.

Bucket 2: questions about company policy and process

Questions like “Do you have a written information security policy?” or “Do employees receive security awareness training?” fall here. For a small business, most of these are answerable honestly in a sentence or two, and if you genuinely don’t have a policy yet, writing one is usually an afternoon of work — it doesn’t need to be long, it needs to be true, dated, and something you’ll actually follow.

Bucket 3: the ones you can’t answer yet

Some questions will have an honest answer of “we don’t do this yet.” Don’t skip these or guess. Flag every one as you go — how you answer this bucket is different from the first two, covered next.

Reviewers who process these questionnaires for a living read dozens a month, and they’re trained to discount an unverified “yes” with nothing behind it. What actually moves a technical answer from “we’ll follow up” to “approved” is evidence — something dated, specific, and tied to your actual domain.

What “evidence” means to the person reading it

It’s not a policy document that restates “we take security seriously.” It’s a dated report from an actual test: what was checked, what was found, how severe it was, and what was done about it. A manual security audit produces exactly this — a written report naming each finding’s severity, the evidence for it, and the exact fix steps taken, tied to your real domain (see a real sample report for what one looks like). That single document answers a large share of Bucket 1 questions on its own.

Turning findings and fixes into questionnaire answers

When a question asks “has your application been tested for vulnerabilities, and when?”, the strongest answer is a specific date, the scope tested, and a one-line summary — not “yes” and not silence. Counterintuitively, a report that shows findings which were then fixed is often more convincing than “no issues ever found,” because it demonstrates you actually look. If a specific question asks for a formal penetration test report rather than general audit evidence, that’s a narrower ask — see a customer asked for a pentest report? for how to handle that version directly.

For everything in Bucket 3, resist the urge to either guess “yes” or leave the row blank. Both look worse than an honest gap paired with a plan.

The three-part honest answer

Structure every gap answer the same way: state what’s actually true today, in plain language, with no hedging. State any compensating control that’s real, even if informal. Then state the plan and a real date. That third part is what turns a gap into a non-issue for most reviewers — they’re checking whether you’re aware of your own risk and moving on it, not whether every control is already in place.

What not to do

Never write “Yes” for a control you can’t actually back up if someone calls to ask a follow-up question — many of these questionnaires are attached to a contract clause that lets the customer audit you later. If you’re unsure whether something counts as “in place,” answer “Partial” or “In progress” and explain the specific limitation in a sentence rather than rounding up to yes.

Regardless of format, nearly every questionnaire groups its questions into the same handful of sections. Here’s what a small business with no dedicated security team can realistically and honestly say for each.

• Access control — name the actual number of admin accounts, confirm whether MFA is on and where it isn’t yet, and describe your real offboarding step, even if it’s simple.
• Data handling — most small businesses on managed cloud hosting can honestly answer encryption-in-transit questions with “yes, TLS is enforced site-wide.” Retention and deletion are usually the real gap.
• Incident response — a minimal, honest plan names who gets notified first, how you’d detect something wrong, and what customer notification would look like.
• Vulnerability management — whether your site has ever been tested, how often, and how quickly you patch. A dated audit report answers this directly.