How to answer a security questionnaire when you have no security team

It arrives as an attachment. Forty to two hundred rows, a column for your answer, a column for evidence, and a deadline that is somehow already this week. The person who sent it is not trying to make your life difficult; they are following a procurement process, and every vendor gets the same file. But for a team with nobody whose job is security, the questionnaire is the moment the deal either slows down or dies.

This is how to get through it, and how to be ready for the next one before it comes.

What the questionnaire is actually asking

Strip away the vocabulary and every security questionnaire asks four things:

1. Do you know what you have? Which systems hold our data, where they run, who can reach them.
2. Do you check it? Has anyone tested it, how often, and what did they find.
3. Do you fix what you find? How fast, and how do we know.
4. Will you tell us if something goes wrong? Incident handling, notification, who to call.

Every row maps to one of those. "Do you perform regular penetration testing?" is question two. "Describe your vulnerability management process" is question three. "Do you hold SOC 2 Type II?" is all four, delegated to an auditor. Once you see the four questions behind the rows, the spreadsheet stops being a wall and becomes a form.

The answers that end the conversation

Before the good answers, the ones to avoid. Reviewers read hundreds of these. They are not looking for a perfect vendor; they are looking for the ones that will be a problem later.

• "N/A" on a question that clearly applies. It reads as "we did not understand the question" or "we hoped you would not check". Both are worse than "not yet".
• Claiming a certification you do not have, or one that is "in progress" with no date. This gets checked, and it is the one answer that turns a slow deal into a dead one.
• "We follow industry best practices." It says nothing. A reviewer will either ignore it or ask for the document that proves it, and there is no document.
• Silence on incidents. "We have never had a security incident" is a claim about the past that nobody can verify. "Here is what we would do" is a plan they can read.

What an honest small-team answer looks like

You do not need a security team to give good answers. You need true ones, specific ones, and a small amount of evidence. Row by row, the pattern is the same: say what you do, say how often, attach the thing.

"Do you perform penetration testing?"

The old honest answer was "no, not yet", and it lost deals. The better honest answer, if it is true: "Yes. Our external attack surface, APIs and application are tested continuously, on every production change, with findings verified and fixed. The most recent report is attached." That sentence answers question two and half of question three, and the attachment is the evidence column.

"Describe your vulnerability management process."

Write it in four lines. Where findings come from (testing, dependency alerts, reports from users). How they are rated (what counts as critical). How fast each level is fixed (critical within days, high within the sprint, the rest scheduled). Where the record lives (your issue tracker, a dashboard). A reviewer would rather read four true lines than a policy document copied from a template.

"Are you SOC 2 / ISO 27001 certified?"

If you are not, say so, and say what you have instead. "Not at this stage. Our controls are documented here, our infrastructure runs on providers that hold these certifications (attached), and our application is tested continuously (report attached)." Most buyers under a certain contract size accept that. The ones that do not were going to require the certification regardless, and you now know that before spending the audit budget.

"Do you have an incident response plan?"

Write one this afternoon if you have not. One page: who is on call, how you assess severity, who you notify and within what time, where you write down what happened. It does not need to be long. It needs to exist, and it needs to be the same document every time someone asks.

Being ready before the next one

The second questionnaire is easy if you kept the answers to the first. The trick is to stop treating it as a one-off and keep a small, living folder:

• The last test report, dated, with what was found and what was fixed. If testing runs continuously, this is always recent.
• The four-line vulnerability process.
• The one-page incident plan.
• Your providers' compliance pages, bookmarked.
• A short description of what data you hold, where, and who can access it. You will be asked this on every questionnaire and by every investor.

With that folder, the spreadsheet takes an afternoon. Without it, it takes the week, and the deal goes to whoever answered first.

Orja is built to keep the first item in that folder always current: continuous penetration testing for small teams, with a report you can attach the same day someone asks. If a questionnaire is sitting in your inbox right now, put in your domain and the first report is free.