Answering a Security Questionnaire, No Security Team

A client's procurement or legal team just sent you a spreadsheet with 40 questions about penetration tests, vulnerability management, and encryption standards, and you're a two-person shop with no security team. Here's the short version.

You don't need SOC 2 or an in-house security team to pass a vendor questionnaire — you need honest, specific answers backed by real evidence, and a recent third-party security assessment is the single most useful piece of evidence you can attach.

The rest of this guide walks through the questions you'll actually see, explains what each one is really trying to find out, and gives you wording you can copy and adapt without lying or stalling the deal.

Why they're asking at all

A vendor security questionnaire exists because your client's company is on the hook if you get breached and their customer data leaks through your systems. It's not personal, and it's rarely read as closely as it feels — most of the time it's a compliance checkbox for their legal or procurement team, and a junior analyst is scoring it against a rubric. Vague answers or silence look worse than an honest "we're small, here's what we actually do."

If you're wondering whether you even need a security audit to win the contract: usually no single audit is required, but having something concrete to point to turns a stalled email thread into a five-minute approval.

Decoding the common questions

"Do you conduct regular penetration testing?"

What they're really checking: has anyone other than your own developers tried to break into your app, and did you fix what they found?

Honest answer if you haven't: say so, then show what you have done. "We do not run a continuous penetration testing program. We had a manual security assessment performed on [date] covering [scope], and remediated the findings; the report is attached." A single recent manual audit report is far stronger evidence than a vague "yes" with nothing to show for it — reviewers can tell the difference immediately when they ask for the report and you can't produce one.

"Describe your vulnerability management process"

This is asking: when a new bug or CVE comes out, how do you find out, and how fast do you patch it? You don't need a formal SLA document to answer this honestly. A real small-team process might be: "We use [hosting platform]'s automatic security updates for the OS and dependencies, run npm audit / composer audit before each release, and subscribe to security advisories for our main frameworks. Critical issues are patched within days of disclosure." Write down what you actually do — most reviewers just want proof there's a process, not a specific tool stack.

"Do you have a SOC 2 report or ISO 27001 certification?"

SOC 2 is an audit of your internal controls over months, done by a licensed CPA firm, and it typically costs many thousands of dollars — it's built for companies with dozens of employees and dedicated compliance staff, not a five-person SaaS. If you don't have one, say so plainly and offer the closest honest substitute:

• A recent manual security audit report of your actual product (not a generic company-wide audit)
• Your cloud provider's own compliance attestations (AWS, GCP, and Azure all publish SOC 2 / ISO reports for their infrastructure — you inherit some of that coverage)
• A written summary of your access controls, encryption, and backup practices

Saying "we're not SOC 2 certified, but here's our latest audit report and our cloud provider's compliance documentation" answers the underlying concern without pretending to have something you don't.

"How do you encrypt data in transit and at rest?"

This one you can usually answer with total confidence. In transit: "All traffic is served over HTTPS/TLS 1.2+; HTTP requests are redirected to HTTPS." You can verify and strengthen this by checking your site against our free security headers checker — it'll confirm whether Strict-Transport-Security is set (a good baseline value is max-age=31536000; includeSubDomains) and flag missing headers like Content-Security-Policy or X-Content-Type-Options: nosniff. At rest: most managed databases (RDS, Cloud SQL, MongoDB Atlas, Supabase) encrypt storage by default — check your provider's dashboard and state the actual mechanism, e.g. "AES-256 encryption at rest, managed by [provider]."

"Do you have an incident response plan?"

They want to know that if something goes wrong, you won't go silent for two weeks. It doesn't need to be a 20-page document. A short, real answer works: "If we detect a security incident, we isolate the affected system, assess scope, notify affected customers within 72 hours, and document the root cause and fix." If you've never had to think this through, write it down now, before you need it — it's the cheapest item on this list to fix.

"Who has access to production data, and how is access managed?"

List it honestly: how many people, whether you use unique logins and multi-factor authentication, whether you revoke access when someone leaves. "Two team members have production access, both via MFA-protected accounts; access is reviewed quarterly and revoked immediately on offboarding" is a complete, credible answer even for a tiny team.

"We ran a scanner once" is not the same as a real audit

A lot of small teams have, at some point, pointed an automated scanner at their site and gotten a clean report. That's worth mentioning, but be precise about what it proves: automated scanners check for known signatures — outdated software versions, missing headers, common misconfigurations. They can't chain together a business-logic flaw, test whether one customer can see another customer's data, or notice that a password-reset flow leaks account existence. If you want the actual mechanics of the difference, our guide to manual vs. automated penetration testing breaks it down. A questionnaire reviewer who's seen a few hundred of these can usually tell "we ran a free scanner" from "a person actually tested this," so don't oversell the scanner result — describe it accurately and pair it with something stronger if you can.

What to actually attach to the questionnaire

If you want one document that answers the penetration-test question, the vulnerability-management question, and half the encryption question at once, get a manual audit done and attach the report. It doesn't need to be an enterprise-grade, multi-week engagement to be credible — it needs to be recent, specific to your actual site, and written by a human who tested it, not a script.

Before you spend anything, you can get a free read on where you stand: run a free passive security check to see obvious exposures, or check your email setup with our email spoofing tool if the questionnaire also asks about phishing/domain protection (SPF/DKIM/DMARC records are a common follow-up question). If you want to understand pricing before committing, our breakdown of penetration test costs explains why enterprise pentests run into five figures and where a productized manual audit fits underneath that.

The bottom line

Don't lie, don't leave fields blank, and don't pretend a free scanner result is a penetration test. Answer every question with what's actually true about your setup, back the big claims with real evidence where you have it, and fix the gaps you can fix cheaply (headers, MFA, a written incident plan) before you submit. For the one question you probably can't answer honestly yet — proof of a real security test — a manual audit is the fastest, cheapest way to close that gap.

If you want that evidence in hand before your next questionnaire lands, Circuit is a $49 one-time manual audit: a real engineer tests your site and hands you a written report with severity ratings and exact fixes — something you can attach directly to a vendor questionnaire instead of leaving the field blank.