A customer sent us a security questionnaire. What do we do next?

Read the whole questionnaire before answering any of it. The questions that look simple near the top often depend on answers further down, and a section on incident notification or data location may raise a contract point that needs more time than the rest put together.

Note the deadline and the format. The deadline is the customer's, and if it cannot be met honestly, ask for more time now rather than on the due date; asking early gives the customer time to adjust its own plan. The format matters as much: a spreadsheet, a vendor risk portal, a form inside the customer's procurement system or a list of documents to upload each changes how the work is shared and how long answers can be.

Find out whether it is a standard questionnaire or the customer's own. Some customers send an industry questionnaire, such as the Cloud Security Alliance's CAIQ. The CAIQ is a set of yes or no questions in which a cloud provider documents which security controls exist, framed against the Cloud Controls Matrix [3]. A standard questionnaire is worth recognising because the work carries over: the next customer may send the same one, and the answers you write now, kept current, become your starting point.

Then name an owner for each area. Access and identity usually sit with engineering or IT, devices and staff rules with operations or people, incidents and continuity with whoever is on call, vendors with finance or operations, and privacy with whoever answers for personal data. One person coordinates and submits; each owner answers for their area and finds the evidence. Without an owner per section the questionnaire stalls on the first question nobody feels able to answer.

Every answer describes the control you actually run and the evidence you actually hold. That is the whole method, and it is the part that matters more than any wording. If access is removed when someone leaves, say how, by whom and how quickly it usually happens, and keep the record that shows it. If backups are taken daily and a restore was last tested in a given month, say that. If multi-factor authentication covers some systems and not others, name which.

An answer that describes what you plan to do as though you already do it, or that is borrowed from another company's questionnaire or a template, is an answer that is not true of your company. The customer may ask for the evidence behind an answer, or audit you later under a right in the contract. The completed questionnaire is often attached to or referred to in the contract. And after an incident, a customer rereads what you told it. A precise answer about a modest control holds up in all three; a broad answer about a control you do not run holds up in none.

Short, specific answers with the owner, the frequency and the record named are also quicker for a reviewer to accept than long ones that restate the question.

Send the answers first, in the customer's format, with every question answered and every gap dated. Then send the documents the questionnaire asked for, named the way the questionnaire names them, so the reviewer can match each document to its question without asking. Send only what was asked for at this stage; evidence of operation, such as an access review or a restore test log, usually follows when the reviewer asks for it, and is often shared on a call or through a portal rather than by email, because it can contain internal detail.

Mark documents as confidential, check that the versions you send carry a date, an owner and an approval, and keep a copy of exactly what was sent and when. Keep the final answers in one place you can find again: the next questionnaire will ask most of the same questions, and answers kept current are much quicker to reuse than answers rebuilt.

The time a questionnaire takes depends less on its length than on whether the answers already exist. When the policies are written and the records are kept, answering is mostly a matter of finding and pasting. When they are not, the questionnaire becomes the project that writes them, and the deadline it carries is set by the customer's procurement calendar rather than by the work.

Four things slow it most. There is no owner, so questions sit unanswered. Evidence has to be found, because nobody knew which record proved which control. Answers are written aspirationally and then rewritten when someone checks them against practice, which costs twice. And the documents the customer asked for do not exist, or exist only as templates that no longer match what the company does.

The first two can be dealt with early, by naming owners and agreeing where records live. The last two take longer, and the honest move is to tell the customer the date the documents will be ready rather than send something that is not true.

PolicyDrafters drafts the information security policy set: six documents drafted against ISO/IEC 27001:2022 Annex A and the security criteria of the AICPA Trust Services Criteria used in SOC 2 reports, reviewed by our legal team and delivered in Word and PDF. When you name the questionnaire in the intake and send it once we reply, the set is drafted so that each question in it has a clause to point at, and the control table in each document lists the questions that document answers. The first draft takes twelve working days from a complete intake, and the set is $1,200 to $2,500, fixed before we start.

The set is the policy layer. It does not supply the evidence that the controls operate, which is your access reviews, logs, tickets and test records, and it does not write the questionnaire answers. If the questionnaire's deadline is sooner than the set can be ready, answer it honestly now, with each missing document listed as a gap and its date, and send the documents when they arrive. For a SaaS company, answers written truthfully the first time are the starting point for the second questionnaire.