Answering a customer's security questionnaire as an SME

The first security questionnaire arrives with the first customer large enough to have a procurement function: 80 to 300 questions in a spreadsheet, a two-week deadline, and a contract that waits on the answers. For a ten-person company it can eat a founder’s week. This guide is how to answer it once properly, so that the second and the tenth take an afternoon: build the record, reuse it, never promise what you cannot show, and name who approves.

Why they ask

Your customer is doing what its own regulation requires. Under GDPR Article 28(1) a controller may only use processors “providing sufficient guarantees”, and Article 5(2) requires it to show it checked. Under NIS2 Article 21(2)(d), entities in scope must manage supply-chain security, including the relationship with each direct supplier, and Article 21(3) tells them to consider “the overall quality of products and cybersecurity practices of their suppliers”. Financial customers add DORA: Articles 28 to 30 of Regulation (EU) 2022/2554 require them to assess every ICT third-party provider before contracting and to write specific provisions into the contract. Customers deploying AI systems have Article 26 of the EU AI Act to think about and will ask about yours. The questionnaire is their evidence file; your answers become part of it, which is why the content matters more than the speed.

Build the record once

Most questionnaires — the CSA’s CAIQ, Shared Assessments’ SIG, a customer’s own spreadsheet — ask the same forty facts in different words. Write those facts down once, where your team can find them, with a date and a source for each:

• Company and roles. Legal entity; who owns security and data protection; whether you have a DPO and why or why not (Article 37).
• Hosting and location. Where production and backups run, in which country, with which provider; whether anything leaves the EU and EEA and under which mechanism.
• Sub-processors. The list with country and purpose — see the sub-processor guide. Your sub-processors are your suppliers; keep them in one register so the questionnaire answer and your Article 30 record cannot drift apart.
• Access control. MFA for staff, role-based access, joiner and leaver process, how many people can reach production.
• Encryption. In transit and at rest, which algorithms, who holds the keys.
• Logging, vulnerability management, incident response. What is logged and for how long; scanning and patch cadence; last penetration test; the runbook and the breach notification window you give customers.
• Business continuity. Backup frequency and retention, last restore test, RTO and RPO.
• Development. Code review, separation of environments, secrets handling.
• Certifications and audits. Which you hold, which you do not, and what you can share instead.
• Data subject rights and portability. How you support deletion and export, including the Data Act export for business customers.
• AI. Which features use AI, which provider, where inference runs, whether customer data trains anything, how output is labelled.

Each fact carries a source: the policy, the configuration, the contract, the report. An answer you cannot trace to a source is one you will re-derive next time and cannot defend if asked.

Reuse it

Keep every answer you have sent, with the question it answered, the date and the approver. When the next questionnaire arrives, match its questions to the library first, then to the record, and write new text only for what is genuinely new. Two rules keep the library trustworthy. Re-date on reuse: an answer approved in March describes March, and before you send it in September someone confirms it still holds — the confirmation is what you record. Answer the question asked: “Do you encrypt data at rest?” gets a yes and the algorithm, not a paragraph on security culture. Reviewers score hundreds of these; the plain answers get through.

What never to promise

A questionnaire is a representation to a customer. Overstating in it is worse than admitting a gap, because a gap can be closed and an overstatement becomes a contract problem. Never write:

• A certification you do not hold. “ISO 27001 aligned” is not certified. Name the controls you implement and offer the evidence.
• An absolute. “We have never had a security incident” or “our systems cannot be breached”. Say what you detect, how you respond and how you notify.
• A location you cannot vouch for. “All data stays in the EU” is true only if every sub-processor’s processing does. Check the list before you write it.
• Recovery figures you have not tested. An RTO of four hours is a test result, not an aspiration.
• Commitments that belong in a contract. Unlimited liability, indemnities, audit on demand, a notification window shorter than your DPA’s. Point to the contract; the questionnaire is not where terms are made.
• Anything about a supplier you have not read. If your hosting provider’s security page is the source, quote it and name it.

Where the honest answer is “no” or “not yet”, say so, with the mitigation and a dated plan. Procurement teams reject vagueness far more often than a documented gap.

Who approves

Every answer that leaves the company is approved by a named person with the authority to make the representation — a founder, the CTO, whoever owns security. Drafting can be anyone’s job, or a tool’s; approval cannot. Record the approver and date on each answer, keep the final file you sent, and treat it as a version of your record. If a fact changes afterwards — a new sub-processor, a moved region — the record changes, and you know which customers were told what.

How Maditon does this

Maditon treats a questionnaire as a document to answer from a record, not a form to type into. You upload the customer’s file — XLSX, DOCX, CSV or PDF — and it keeps the question identifiers, sections and order, then drafts an answer to every question it can from your compliance profile, your supplier register, your systems and services and the answers you approved before, naming the source of each. A question the record cannot answer is marked needs input, never guessed. Documents you marked private are never used for drafts; the workspace tells you when a supplier or system you rely on has one, so you check that agreement by hand. Nothing leaves until a named user has approved it, question by question, and approved answers are exported in the customer’s own file layout.

Read How do I answer a customer’s security questionnaire with Maditon? and What is a private document in Maditon?, or upload the questionnaire that is waiting in the app.