How to fill out a security questionnaire in Excel

A prospect sends you an Excel file with 200 security questions and a note saying their procurement team needs it back by Friday. If you are a founder, a CTO or a sales engineer at a small software company, this is probably not your day job. It is still your problem.

This guide covers how to work through a questionnaire in Excel without losing days to it, and without making mistakes that cause trouble later.

Step 1: Read the whole file before you type anything

Open the file and look at it before answering a single question. Check for:

• Multiple tabs. Many questionnaires put the real questions on a second or third tab, with instructions or a glossary on the first.
• Dropdowns. Some cells only accept values like Yes / No / N/A. Typing free text into them can break the buyer's own processing.
• Hidden columns and rows. Buyers sometimes hide columns for scoring or internal notes. Leave them alone.
• Merged cells and formulas. Section scores and totals often depend on formulas. Overwriting them can quietly change the result.
• Instructions. Look for the deadline, who to send it to, and whether they want evidence attached or only answers.

Save a copy of the original file untouched. You will want it if something goes wrong.

Step 2: Gather your source material first

Most of the time in a questionnaire goes to hunting for the right document, not to typing. Before you start, collect:

• Your security policies (access control, incident response, data retention and so on)
• Any audit report or certification you actually hold
• Previous questionnaires you have already answered
• A short description of your company: size, where data is stored, and which vendors process it

If a policy does not exist in writing, note that now. It is better to know before you are halfway through a section.

Step 3: Answer from documents, not from memory

This is the rule that matters most. Every answer should be backed by something you can point to: a policy, a setting, a report. If you answer from memory, two things can happen. You may say something that is not quite true, and the next person who fills in a questionnaire may answer the same question differently.

For each question, a good working method is:

1. Find the relevant document or setting.
2. Write the answer in plain, specific words.
3. Note where the answer came from, in a spare column or a separate log.

Security reviewers read these answers closely, and a wrong “Yes” is worse than an honest “No” or “Not currently.” If you cannot support an answer, flag it for someone to check rather than guessing. Our list of common questions with example answers shows what specific, supportable answers look like.

Step 4: Be honest about gaps

Some questions will describe things you do not have. Common examples for small companies are formal certifications, independent penetration tests, or a dedicated security team. Answer exactly what is true. A short, clear explanation of what you do instead is usually better received than a vague answer that sounds like a yes.

If you are unsure whether something counts, mark the row and ask the person who runs that system before you commit to a reply. For two of the most common gaps, see the SOC 2 question and the penetration test question.

Step 5: Keep your answers consistent

Questionnaires repeat themselves. The same question shows up in different words in different sections, and again in the next customer's file. Keep a simple library of approved answers: the question, the wording you settled on, and the source document. When the next questionnaire arrives, you start from answers you have already checked instead of from a blank cell.

A spreadsheet of past answers works. The habit matters more than the tool. Our guide to building a security answer library walks through it.

Step 6: Review before you send

Have a second person look at the answers, even if only for an hour. A reviewer does not need to be a security expert. They can catch inconsistencies, answers that do not match the question, and anything that reads as a promise your company cannot keep.

Then check the mechanics:

• Did the dropdowns keep valid values?
• Are the formulas and merged cells still intact?
• Are hidden columns still hidden?
• Is the file still in the format the buyer sent (.xlsx stays .xlsx)?

Send the file back in the same layout it arrived in. Buyers often load these files into their own process, and a rebuilt or reformatted file can create extra work for them.

Where the time goes, and what can help

Most of the effort is matching each question to the right source, copying answers into the buyer's layout, and keeping wording consistent across files. That is repetitive work, and it is easy to do badly by hand when you are in a hurry.

Rendro is built for this job with Excel (.xlsx) and CSV files. It drafts each answer only from your own documents, shows the source for every answer, marks the ones it can't support “Needs review” instead of guessing, and exports the buyer's original file filled in, with tabs, dropdowns, merged cells, hidden columns and formulas intact. You still review every answer before it goes out. It does not handle Word or PDF questionnaires, or questionnaires inside web portals.

A short checklist

• Copy the original file and keep it untouched
• Read every tab, and note dropdowns, hidden columns and formulas
• Collect policies and past answers before starting
• Answer from documents, with a source for each answer
• Be honest about gaps
• Reuse approved answers
• Get a second person to review
• Return the file in the same format and layout

For the bigger picture, start with how to answer a security questionnaire, step by step.