Security reviews · Practical guide
Your first enterprise security questionnaire: what engineering should prepare
Prepare your first buyer security review with an answer owner, current evidence and an honest gap list. A practical guide for European B2B software teams.
The questionnaire arrives while your team is trying to ship the product. Some questions belong to engineering, some to operations, and a few need a decision from a founder.
Before writing answers, establish what the buyer actually needs. Ask which questions block the purchase, what evidence they accept, and when they need it. A certificate request and a request for evidence of access reviews are different pieces of work. Agree the scope before spending a week on the wrong one.
Put an owner next to each answer
One person should coordinate the response. That does not make them responsible for every control.
Assign the access questions to whoever operates identity and production access. Give recovery questions to the person who can show a restore test. Route contract and privacy questions to the person authorized to answer them.
Record an owner, a source and a review date for each answer. An answer copied from last year's spreadsheet still needs someone to confirm it is true today.
Start with evidence you can stand behind
Work through the questions that could stop the deal. For many software teams, useful starting points are production access, backups and recovery, incident handling, and suppliers that handle customer data. The buyer's actual requirements determine the final list.
For each question, distinguish a documented process from evidence that the process happened. A backup policy explains the intention. A dated restore-test record supports a different claim: that someone tested recovery for a defined system.
Keep the supporting record near the answer. Give it a date and scope. If the evidence covers one environment, do not describe it as proof for every environment.
Write the gap down
“Planned” is a useful answer when it is accurate. “Implemented” is a problem when nobody can show it.
Record what is missing, who owns the next action, and what would demonstrate completion. If the buyer requests a commitment, the person authorized to make it should approve the wording and date.
Do not invent a certification deadline or promise that a tool will make you compliant. The work depends on your systems, obligations and the buyer's requirements.
Share less, with a clear purpose
Evidence can contain personal data, infrastructure details or confidential information. A questionnaire is not permission to send every internal record.
Review each attachment. Use an approved sharing route, restrict access to the people who need it, and redact unrelated details. If personal data is involved, consider the purpose and lawful basis before disclosure. GDPR's data-minimisation principle requires personal data to be adequate, relevant and limited to what is necessary; its security requirements also matter when sharing it. European Commission: data minimisation and security obligations.
Keep the useful work after the deal
When the review closes, keep the answers connected to their sources and owners. Record the commitments you made. Set the next review around the control or evidence, rather than waiting for another questionnaire to arrive.
That gives the next buyer review a better starting point. It also makes gaps visible while there is still time to act on them.
Kaamos≥ connects systems, risks and audit evidence so a small software team and its agents can prepare work for human review. See how the product is organized, or talk through your next security review with a founder.
Put your security work in motion.
Book a meeting