Security questionnaires: how to answer once and reuse everywhere

The bank's procurement team has sent a 200-row spreadsheet, the contract is waiting on it, and your head of engineering is answering it from scratch for the third time this quarter. Every security questionnaire feels new, even though most of the questions are not.

This guide is for founders, CTOs, security leads and sales engineers at UK B2B tech firms selling into banks, insurers and other regulated buyers. It explains why those buyers have to send a security questionnaire, and how to build one answer library and one evidence pack that answer most of the next one before it arrives.

What is a security questionnaire?

A security questionnaire is the due-diligence form a customer sends to check a supplier's security and compliance before signing or renewing. Regulated buyers are required to do this due diligence. The fix is one maintained answer library with evidence behind every answer: answer standard questionnaires from it, and point buyers to a trust centre for the rest.

The questions arrive in many shapes, but they ask about the same things: how you control access, protect data, manage suppliers, handle incidents and recover from outages. Underneath the wording, a questionnaire asks one question: can this buyer rely on you?

That is why the work repays doing once, properly. The answers change slowly. The formats change every time.

Why do regulated buyers send security questionnaires?

Regulated buyers send security questionnaires because their regulators require due diligence on the suppliers they rely on. The FCA's SYSC 8, the PRA's supervisory statement SS2/21 and, for EU financial entities, DORA all expect a firm to assess a supplier before contracting and to keep overseeing it. The questionnaire is how that assessment gets its evidence.

Each regime puts the duty on the buyer, and the buyer passes the questions on to you:

• FCA SYSC 8. SYSC 8.1 requires the firms it covers to exercise due skill, care and diligence when outsourcing critical or important operational functions (SYSC 8.1.7). SYSC 8.1.8 sets conditions, including that the service provider discloses any development that may materially affect its ability to perform, and protects confidential information.
• PRA SS2/21. SS2/21 expects banks and insurers to carry out due diligence that, for material outsourcing, considers a provider's ICT controls and security, its sub-outsourced providers, and whether it can show certified adherence to recognised standards and provide certificates and documentation on request.
• DORA. For EU banks, insurers and investment firms, DORA has applied since 17 January 2025. Article 28 requires due diligence on prospective ICT providers and a register of information covering every ICT contract. Article 29 adds a concentration risk assessment, and Article 30 lists the terms the contract must contain.

So the buyer is not being difficult. Its compliance team needs a record that it asked the right questions, got answers and judged them.

What the buyer does with your answers follows from that. Under DORA, it feeds a register it must make available to its regulator on request. Under SS2/21 paragraph 8.9, for material outsourcing, the PRA expects it to assess whether your certificates and reports are adequate, rather than assume that having them is enough. Your answers become part of the buyer's own regulatory file, and that file is only as good as what you told them.

What formats do security questionnaires come in?

Security questionnaires come in three main formats: a bespoke spreadsheet written by the buyer, a questionnaire inside the buyer's supplier portal, and a standard questionnaire such as the CSA's CAIQ or the SIG. Bespoke and portal questionnaires are the most common. A standard questionnaire, offered by you, can sometimes replace them.

The CSA describes the CAIQ as a set of yes or no questions a cloud customer may ask a cloud provider to check compliance with the Cloud Controls Matrix. Version 4.1 was released in January 2026, and a completed copy is also what a provider submits for a STAR Level 1 self-assessment.

We recommend asking, on the first call, whether the buyer will accept a standard questionnaire. The worst outcome of asking is a no.

How do you build a security questionnaire answer library?

Build a security questionnaire answer library by grouping past questions into families, writing one approved answer for each, and linking each answer to the evidence that proves it. Give every answer a named owner and a review date. The library then answers most of the next questionnaire, and shows which answers have gone stale.

Start from the last three or four questionnaires you answered. Paste every question into one sheet, then sort them by what they are really asking about. We recommend these families as a starting set:

1. Governance, policies and roles
2. Risk management
3. Asset management and data classification
4. Access control and authentication
5. Encryption and key management
6. Secure development and change management
7. Vulnerability management and penetration testing
8. Logging, monitoring and incident response
9. Business continuity and disaster recovery
10. Suppliers and subprocessors
11. Data protection, data location and retention
12. People: screening, training and leavers

Within each family, many questions turn out to be one question in different words. "Do you enforce multi-factor authentication?" and "Describe how users authenticate to production" share one approved answer, written once and adapted at the edges.

Each library entry needs the same fields:

Some answers will be no. Write those as carefully as the yes answers. We recommend a set pattern: state the no plainly, describe the compensating control, and give a date if a change is planned. For example: "We do not hold SOC 2. Our ISO 27001 certificate covers the platform, and we can share the Statement of Applicability under NDA."

A clear no with a compensating control is a better answer than a vague yes.

What evidence pack answers most security questionnaire questions?

The evidence pack that answers most security questionnaire questions holds your certificates, the ISO 27001 Statement of Applicability, your SOC 2 report shared under NDA, a penetration test summary, your core policies and your subprocessor list. Sent together at the start, the pack answers many questions outright and makes the rest shorter.

We recommend keeping these in one place, current and ready to send:

• Certificates. ISO 27001, Cyber Essentials and any others, with the certification body, scope and expiry date visible. If you are still working towards ISO 27001, our guide to the ISO 27001 certification process sets out what the certificate proves and when you will have it.
• Statement of Applicability. It lists the ISO 27001 Annex A controls you need, whether each is implemented and why any are excluded, which maps neatly onto questionnaire families. Share it under NDA.
• SOC 2 report. A SOC 2 report is not meant for general distribution, so share it under NDA. The AICPA describes a SOC 3 report as general use and freely distributable, so publish that if you have one. Our guide to the SOC 2 report explains what buyers read in it.
• Penetration test summary. The tester, the date, the scope and the status of findings. Send a summary or letter rather than the full report.
• Policies. Information security, access control, incident response and business continuity, at least.
• Subprocessor list. Under UK GDPR Article 28(2), a processor needs the controller's authorisation to engage another processor and, under general authorisation, must tell the controller about changes. Buyers ask for the list for that reason.

The pack works because it matches what the buyer's regulator expects it to collect. SS2/21 asks buyers to consider certificates and documentation, and DORA Article 30 asks for contract terms on where data is processed and how it is protected. A pack that leads with those answers several sections of a questionnaire at once.

How do you answer an incoming security questionnaire step by step?

Answer an incoming security questionnaire in six steps: triage it, reuse library answers, write answers for the gaps, review them, sign off, and update the library. The library does most of the work. The people you need spend their time on new questions and on judgement, not on retyping last month's answers.

1. Triage. Confirm the deadline, the scope (which product, which data) and the format. Ask whether a standard questionnaire or your evidence pack would replace any part. Assign one coordinator.
2. Reuse. Match each question to a library family and paste the approved answer. Adjust scope words so the answer fits this product and this buyer.
3. Gap answers. Send questions with no library match to the owner of the nearest family. If a draft comes from a tool or an AI assistant, a named person checks it against the evidence before it goes further.
4. Review. A second person reads every answer that is new, changed or a no. They check that each claim is true today and that the evidence exists.
5. Sign-off. A director or the security lead approves the final answers. Buyers rely on them in their own regulatory records, so the sign-off is not a formality.
6. Update the library. Add each new answer, phrasing and evidence link. The next questionnaire starts from a larger library.

An answer nobody owns has no review date, so it quietly goes stale.

How do you keep security questionnaire answers true over time?

Keep security questionnaire answers true by reviewing each one on a set cadence, re-checking answers whenever something they describe changes, and never stating more than your evidence supports. A library that drifts out of date is worse than no library, because it repeats yesterday's facts with today's signature.

We recommend three habits:

• A review cadence. Each owner reviews their family at least every six months, and after each certificate renewal or SOC 2 report.
• Change triggers. Some events reopen answers straight away: a new cloud provider or data location, a new subprocessor, a security incident, a failed control, a policy change or a lost certification. SYSC 8.1.8 requires the FCA firms it covers to make sure their providers disclose developments that may materially affect performance, so tell affected buyers as well as updating the library.
• No over-claiming. Answer for what is true and evidenced now. "Planned for Q3" is an honest answer; "yes" for a control still being built is not.

Timing matters for reports too. If a buyer's review falls after your SOC 2 report period ends, a SOC 2 bridge letter covers the gap, and the library should say which period each report covers.

A questionnaire answer is a promise in writing. Treat it like one.

Can a trust centre cut down repeat security questionnaires?

A trust centre can cut down repeat security questionnaires by publishing your standing answers and evidence in one place buyers can check. Public material, such as certificates and policy summaries, sits in the open. Reports such as SOC 2 sit behind an NDA. Many buyers then need only their remaining questions answered.

A trust centre is the answer library's public face. It works best when it is fed from the same approved answers and evidence, so the two never disagree.

The PRA points the same way. Among its expectations for certificates and reports, SS2/21 encourages the use of online, real-time reporting tools where available. A trust centre does not remove the buyer's duty to assess you, but it gives them current material to assess.

How to build and run one is a topic of its own, covered on our trust centre page.

What are the common mistakes with security questionnaires?

The common mistakes with security questionnaires are answering from scratch each time, answering yes to controls that are planned but not working, sending AI-drafted answers no one has checked, letting answers drift from the evidence, and sharing restricted reports without an NDA. Each one either wastes time or creates a claim the buyer may rely on later.

• Starting from a blank sheet. Each fresh answer is a chance to contradict the last one you gave the same buyer.
• Saying yes to a plan. A control on the roadmap is not a control. Answer with the plan and its date.
• Unchecked drafts. Tools and AI assistants can suggest answers from your library. A person still checks every answer against the evidence before it is sent.
• Answers without evidence. If the buyer asks for proof and you cannot find it, the answer was a guess.
• Loose reports. A SOC 2 report or full penetration test report emailed without an NDA is out of your control.
• One person holds it all. If a single engineer is the library, the library leaves when they do.

Frequently asked questions