How to Answer an Enterprise Customer's Security Questionnaire

Why customers send them

Larger organisations must manage the risk their suppliers bring. EU rules push this further: NIS2 requires in-scope companies to address supply chain security, taking into account each direct supplier's vulnerabilities and security practices (Article 21(2)(d) and (3)), DORA requires financial entities to assess ICT providers before contracting (Article 28(4)), and GDPR requires controllers to use only processors that provide sufficient guarantees (Article 28(1)). The questionnaire is how they collect that evidence about you.

What they ask

Questionnaires vary, and many are based on standard sets such as the Cloud Security Alliance's CAIQ or Shared Assessments' SIG, but they cover the same ground:

Area	Typical questions
Governance	Security policy, who is responsible, risk assessments, staff training
Access control	Multi-factor authentication, least privilege, access reviews, leavers
Data protection	Encryption at rest and in transit, data location, retention, GDPR, sub-processors
Infrastructure	Hosting provider, network security, logging and monitoring, vulnerability management, patching
Secure development	Code review, dependency scanning, separation of environments
Incident response	Incident plan, how fast you would notify the customer, past incidents
Business continuity	Backups, restore testing, recovery time
Assurance	Certifications (ISO 27001, SOC 2), penetration tests, insurance

How to answer

1. Never say yes to something you do not do

Answers often end up as commitments in the contract. A false "yes" is a liability; an honest "partially, planned for Q2" rarely loses a deal. Buyers expect small companies to have gaps; they look for awareness and a plan.

2. Answer the intent, briefly

"Do you encrypt data at rest?" deserves one sentence: what is encrypted, with what, and who manages the keys. Short, specific answers read as competent; long generic ones read as copied.

3. Turn gaps into a plan

For each "no", give a compensating control and a date: "We do not yet run an annual external penetration test. We run weekly automated vulnerability scans and plan a third-party test before 31 March." Then do it.

4. Attach evidence, not promises

Your information security policy (or a summary of it).
An architecture or data-flow overview, without secrets.
Your incident response plan summary and the notification time you can commit to.
A list of sub-processors with locations, and your data processing agreement.
Certificates or reports you have: ISO 27001 certificate, SOC 2 report under NDA, a pentest summary letter.

5. Mark what is confidential

Share detailed reports under NDA and keep vulnerability details out of the spreadsheet. A summary letter from the tester is usually enough.

When they ask for a penetration test

If you have never had one, say so and offer what you have (automated scanning, a recent internal review), plus a date for an external test. When you commission one:

Scope it to what the customer cares about: the application and API they will use, the hosting environment and authentication.
Ask for a summary letter suitable for customers, as well as the full report.
Fix the findings and ask for a retest, so the letter shows remediated issues.

Make the next one fast

Keep an answer library: one spreadsheet of standard answers, each with evidence and an owner.
Review it every six months and whenever a policy or provider changes.
Publish a short security page (a trust page) covering the common questions, and link it in sales emails.
Track which questions you could not answer "yes" to; that list is your security roadmap.

Know your gaps first: the free Cybersecurity Maturity Assessment and Cyber Risk Score show where you stand before a customer asks.

Start from tested answers. The Cybersecurity Starter Pack includes a workbook of standard questionnaire answers with evidence and status columns, a penetration test scoping document, an incident response plan, an asset inventory and a 90-day security roadmap.