Security Questionnaire

Artifact

A review document a prospective customer sends before signing, asking item by item how their data will be stored and protected, which the vendor fills in and returns.

Why it exists

When companies kept their files on their own servers, there was less to check. You bought a tool, installed it on your own machines, and the data stayed inside your building, where securing it was your own problem. Products delivered over the web inverted that. Contracts and HR records now sit on somebody else's servers, and how that company handles them is not something you can see.

Which left the security reviewer at the buying company in the same bind every time. A team files a request to adopt a tool, the reviewer has to approve or reject it, and there is nothing to base the decision on. Ask the sales rep and the answer is that security is taken very seriously. That sentence cannot explain, after an incident, why the approval was given. So reviewers delayed or objected, and deals with every commercial term settled stopped right there.

A security questionnaire converts that conversation into items. Instead of asking whether security is taken seriously, it asks where data is stored, whether it's encrypted in transit, and which employees can see customer data. The answers exist in writing, so the person who approved can point at what they relied on, and the vendor can't quietly revise its story later. It moves verification from trust onto record.

What goes in it

Item counts vary widely by company — some run around 40, others past 300. What gets asked falls into roughly seven groups.

  1. Organization and policy — who owns security, whether written policies exist, whether staff receive training. This group is really asking whether the company has assigned this work to a process or to a person.
  2. Access control — which employees can see customer data, and when that access is granted and revoked. Questions like how many days it takes to disable a departing employee's account live here.
  3. Data storage — which country the servers are in, whether data is encrypted at rest and in transit, and where backups are kept and for how long. Buyers with data residency obligations weigh the storage location especially heavily.
  4. Development security — what gets checked before code is deployed. Application security is the name for this group, covering the work of making code and services hold up against attack.
  5. Incident response — how many hours pass before the customer is notified of a breach, and through what channel. Answers here have to be specific numbers, so this group stalls a vendor who hasn't prepared them.
  6. Subprocessors — which external services the vendor uses and whether customer data reaches them. A list of every downstream vendor touching customer data is a common request.
  7. Certifications — whether the vendor holds something like SOC 2 or ISMS-P. SOC 2 is a US standard under which an external auditor verifies a service company's security controls; ISMS-P is the Korean equivalent. Holding one lets a report stand in for a sizable block of items.

Most items want a yes or no plus an explanation. A no isn't automatically disqualifying. Attach a date by which it will be true and it often passes, while a bare yes with no explanation is what makes a reviewer stop and dig.

Who writes it and who reads it

The document itself is written by the buyer. A security reviewer keeps a standard internal template and sends it as-is whenever an adoption request comes up. Which is why a vendor selling one product receives a different form from every account. About half the items overlap everywhere; the rest reflect that company's particular situation.

The vendor fills it in, but not the sales rep alone, because the answers live with engineering and security. A sales engineer usually owns the task — the role that handles technical questions and demos — maintaining a bank of previous answers and routing only genuinely new items to the engineering team. Without that bank, every questionnaire gets answered from scratch and a single round trip consumes two weeks.

Three people read the result. The buyer's security reviewer works through the answers item by item, legal checks them against the security clauses in the contract, and procurement files them as the basis for approval. Their attention differs enough that short, factual answers travel best. Long explanations invite legal to ask for that sentence in the agreement.

How it sounds at work

"Commercial terms are settled. All that's left is a 180-item security questionnaire — answers should take about ten days."

Reporting what remains in the process and how many days it costs.

"That item is still a no, so I answered it with the quarter we plan to have it in place."

Handling a gap as a dated commitment rather than claiming something untrue.

"If you have a SOC 2 report, you can skip these twenty-three items."

Letting a certification stand in for a block of questions.

At Pagedeck this document arrives in nearly every contract with a company above 200 employees. Sofia receives it and passes it to Theo, who fills in what the answer bank covers and flags the genuinely new items separately. More than five new items and a meeting gets booked that week with Grace in the room, because some of those items require setting a policy that doesn't exist yet.

The answer bank gets reviewed every six months. When the product changes, old answers drift away from the facts, and submitting them in that state comes back later as a contract breach.

What people get wrong

The most common mistake is treating it as a formality that a quick pass will clear. There are many items and they repeat, so the impression is understandable. But the readers cross-check the answers against each other. Claim strict access control in group 2 and leave the subprocessor list in group 6 blank, and the inconsistency is plainly visible. Once a set of answers reads as unreliable, the item count grows, and a process that would have taken ten days stretches to a month.

The other mistake is assuming a certification removes the need to answer at all. An audited report exists, so it feels like it should substitute for the whole thing. But a certification only substitutes for the overlapping items. Questions that come from the nature of that buyer's own data — a requirement not to store anything in a particular country, for instance — appear in no report. Lean on a certification to avoid submitting and the reviewer reads it as dodging the items you'd struggle with, which makes the remaining review harder, not easier.

Easily confused with

TermWhat it refers toHow it differs from a security questionnaire
Vendor assessmentThe whole process of checking an external tool or supplier's securityIt's the name of a process. The questionnaire is one document exchanged inside it

Where to go next

Related terms

Last updated 2026-09-16