Preparing your app for an enterprise security questionnaire

If you sell software to larger companies, sooner or later a deal will pause while the customer's security team sends you a questionnaire. It might be a spreadsheet with a few hundred rows, a standardized format such as the SIG or the CAIQ, or a web portal from a vendor-risk platform. For a small company, the first one can feel overwhelming. It doesn't need to be, if you prepare before it arrives.

This guide covers what security reviewers are looking for, the practices that answer most questions, and how to assemble a set of documents you can reuse for every deal. It isn't legal advice, and it doesn't replace a formal audit if your customers require one.

What reviewers are actually trying to learn

Security questionnaires look like checklists, but the reviewer is answering a few broad questions: what data of ours will you hold, how could it leak or be lost, and would you notice and tell us if it did. Answers that are specific and consistent build trust. Answers that are vague, or that claim everything is perfect, invite follow-up questions.

Honesty matters more than a perfect score. Reviewers expect smaller vendors to have gaps. A clear answer such as "not yet; planned for next quarter, with this compensating control in the meantime" is often acceptable. A false yes discovered later can end a relationship, and because questionnaire answers are frequently referenced in contracts, it can create real liability.

The practices that answer most questions

Most questionnaires cover the same core areas. If you have reasonable, documented practices in each, you can answer the majority of questions directly.

Access control

• Single sign-on with multi-factor authentication for all staff accounts: email, source control, the cloud console and production tools.
• Least-privilege roles, with production access limited to the people who need it and reviewed periodically.
• A documented process for removing access on the day someone leaves.

Data protection

• Encryption in transit with TLS for all traffic, and encryption at rest for databases, file storage and backups, which major cloud providers support natively.
• A clear inventory of what customer data you store, where it lives and how long you keep it.
• Backups that are tested by actually restoring them, on a schedule.

Secure development

• Code review on every change before it is merged.
• Automated tests and dependency vulnerability scanning in continuous integration.
• Separate staging and production environments, with no production customer data in development.
• Secrets kept in a secrets manager, never committed to source code.

Monitoring and incident response

• Centralized logs for authentication and administrative actions, retained for a defined period.
• Alerting on errors and downtime, with a named person responsible for responding.
• A written incident response plan that says who decides, who communicates and how quickly affected customers are notified.

Vendors

• A list of subprocessors, the third-party services that touch customer data, with what each one does and where it operates.
• A short review of each critical vendor's own security posture, repeated when contracts renew.

Documents to prepare in advance

A handful of documents will answer a large share of any questionnaire and can be shared under NDA. Writing them once saves days on every deal that follows.

• A security overview: a few pages describing your architecture, hosting, data flows and the practices above, in plain language.
• A policy set covering access control, acceptable use, incident response, business continuity, vendor management and data retention. Keep each policy short and true to what you actually do.
• A data flow diagram showing where customer data enters, where it is stored and which subprocessors receive it.
• An architecture diagram of your production environment.
• Your privacy policy and a data processing agreement template, since many enterprise customers will ask for one.
• Evidence of testing, such as the summary of an independent penetration test, if you have had one.

Build an answer library

Questionnaires repeat themselves. After the first one, save every answer in a shared document or spreadsheet organized by topic, with the date each answer was last confirmed accurate. When the next questionnaire arrives, most of the work is matching questions to existing answers and checking that nothing has changed.

Assign one person to own the library and review it every few months, and whenever your infrastructure changes. Inconsistent answers given to different customers are a common and entirely avoidable problem.

Certifications and audits

Some buyers will ask for a SOC 2 report or ISO 27001 certification. These are formal attestations performed by independent firms, and they involve months of preparation and ongoing cost. Whether you need one depends on your customers. Many mid-market buyers will accept a well-documented questionnaire and a security overview, especially for a first contract. Some enterprise buyers require an audit report before signing.

The practices described above are the foundation an audit examines, so the work isn't wasted if you pursue one later. Ask prospects early whether an audit report is a hard requirement, so it doesn't surprise you at the end of a long sales cycle.

Handling the questionnaire itself

1. Read the whole questionnaire before answering, and ask the customer which sections apply to the service you are providing.
2. Answer from your library where possible, and mark anything that doesn't apply with a short reason.
3. Be specific. Name the controls and tools rather than writing "industry standard".
4. Where you have a gap, say so, describe any compensating control and give a realistic plan.
5. Have one person review every answer for consistency before sending.
6. Keep a copy of exactly what you submitted to each customer, because it may become part of the contract.

Where we fit

When we build software for clients who sell to larger companies, we document the architecture, data flows and security practices of what we deliver as part of the project, written so it can be reused in your security reviews. Our own practices are described on our security page.