A couple of times a month the same file lands in my inbox. A spreadsheet, somewhere between 150 and 300 rows, three columns: question, yes or no, comment. It is the security questionnaire that a client’s procurement team or security team sends before signing. We answer it in a day, sometimes less, and almost always with documentation that was already written.
That should worry whoever sent it. If a vendor completes two hundred security questions in a day without breaking a sweat, what the questionnaire measured was their ability to keep paperwork tidy. The risk the organisation was trying to assess went untouched.
I lead the engineering team at SMARTFENSE and I sign off on those answers, so I have a fairly clear view of which questions force us to show something real and which ones get answered with a PDF. Verizon’s 2026 DBIR puts software vulnerabilities as the starting point of 31% of breaches, ahead of stolen credentials. Every platform you add to your organisation is somebody else’s software that runs on your data, and the questionnaire is the one moment in the buying process when you get to look inside.
What does a vendor security questionnaire actually measure?
A vendor security questionnaire is the instrument an organisation uses, before signing a contract, to assess what risk it takes on by connecting a third party to its data, its identities and its systems. That is the stated intent.
In practice, the standard format measures documentation maturity, which correlates with vendor size far more than with security posture. A large vendor with a dedicated compliance team answers any questionnaire beautifully, whether or not there are effective controls behind it. A small one with impeccable engineering can come off badly because it lacks the document that formalises what it already does.
The useful distinction, when you are on the evaluating side, is to separate three planes. What the vendor declares (a ticked box). What it can prove if you ask (a certificate, a contract). And what you can verify yourself. The traditional questionnaire never leaves the first plane, and that is where it loses almost all of its value.
Why does a certification answer less than it seems to?
Certifications are necessary and there is no reason to work with a vendor that holds none. The problem shows up when the conversation ends at the logo.
What decides whether a certification is useful to you is its scope. A certificate has a declared perimeter, and that perimeter may cover the full production platform or only the corporate office and its administrative processes. Both look identical as a logo. Asking what fell inside the scope, what fell outside and when it was issued tells them apart in a minute.
The same goes for the service model. If the vendor runs on someone else’s infrastructure, some of the controls you are asking about are not theirs. The honest answer to “how do you control physical access to your data centre?” is often that the cloud provider owns that control and evidences it with its own certification. Pushing for an in-house answer there only gets you a worse answer.
On our side, the seals we hold and their scope are published and verifiable, including the qualification granted by Spain’s Centro Criptológico Nacional for handling sensitive information under the Esquema Nacional de Seguridad (the Spanish national security framework for public sector systems). The fact that they are published is information too. If you have to email someone to find out which ones a vendor holds, you have already learned something.
Which five questions actually tell vendors apart?
These are the five that, when they reach us, force us to show how the platform is built. None of them can be answered with a generic document.
- What exactly is the scope of your certification, and what was left out? A vendor that knows its own scope says it from memory. One that replies with the certificate attached and no comment probably never read its scope.
- Who on your team can see my people’s data, and what gets logged when they do? Support access exists on every platform. What changes from one to another is whether that access is recorded in a way the customer can audit afterwards.
- What happens to my data the day the contract ends? You need to pin down the deletion timeline, the export format, what stays in backups and for how long. It is the most frequently skipped question and the most expensive one when the moment arrives.
- How is a person’s access revoked, and how quickly? If offboarding depends on someone doing it by hand in the platform, you have a structural gap. If it propagates from your corporate directory, you do not.
- Who are your subprocessors, and how do I find out when they change? Your vendor has vendors. Contracting the first one implies accepting the ones behind it, so the list and the notification mechanism are part of the agreement.
All five ask how a control behaves in a specific case, rather than whether the control exists. It is worth building the rest of the evaluation on that same logic, which fits the decision framework for choosing a platform.
How do you verify an answer without taking the vendor’s word for it?
The proof of concept or trial period is the best moment to verify, and almost nobody uses it for that. These four checks fit in an afternoon:
Ask for the live demonstration. Create a test user, revoke it, and ask to see the audit record of both actions. If the record shows who did it, when and from where, the questionnaire answer was true.
Look for the subprocessor list without asking. If it is a public page the vendor maintains, there is a process behind it. If they have to put it together for you, that process does not exist yet.
Check whether service status is public. A status page you can reach without credentials says more about a vendor’s operational culture than three paragraphs about its continuity plan.
Ask for the data processing agreement before signing. Reading it with time changes the negotiation. Reading it afterwards only tells you what you agreed to.
Which questions add nothing?
Three families take up half the file and produce no signal at all.
The yes-or-no ones with no evidence attached. “Do you have antivirus?”, “do you have a password policy?”. Nobody answers no, so the question does not discriminate between two candidates and only adds rows.
The ones that request full internal policies. Receiving a vendor’s entire access management document generates a lot to read and very little information about whether that policy is applied. Asking for a case works better: how the last administrator offboarding was executed.
And the ones that ignore the service model, such as the data centre case above, produce formally correct and materially empty answers.
Trim those three families and the questionnaire drops to thirty or forty questions and starts being useful for comparing candidates.
How do we answer those five questions?
I will take the same five, because asking them without answering them would be awkward.
The scope of our seals is published on the page linked above, with the detail of what each one covers.
On who sees the data and what gets logged, the platform runs an audit log protection system that records end-user actions, administrative user actions and the system’s own actions, with records that cannot be deleted or hidden. A record the vendor can edit does not work as evidence, and that distinction makes support access auditable. Where the line sits with surveillance of an employee is something we cover separately, in monitoring and the expectation of privacy.
On access revocation, the point is not to depend on manual work. Authentication is delegated to the organisation’s identity provider via SAML 2.0 and the roster stays aligned through the directory, so offboarding someone in the corporate system closes their access. The full flow is in how automatic SSO integration works end to end, and why we connect through standard interfaces instead of installing components in the client’s environment is in why we integrate via API and not an agent.
On data at contract termination and subprocessors, both live in the GDPR centre, with the data processing agreement and a public subprocessor policy. Service status is also available without credentials.
None of these answers is exotic. They are the ones any vendor should be able to give without preparing anything, which is exactly why they work as a filter.
Frequently asked questions
What is a vendor security questionnaire?
It is the instrument an organisation uses, before signing a contract, to assess what risk it takes on by connecting a third party to its data, its identities and its systems. It is usually sent during the buying process and forms part of third party risk management.
How many questions should it have?
Fewer than it usually does. Thirty or forty questions asking for evidence of specific cases discriminate between candidates better than two hundred yes-or-no boxes, and they can actually be reviewed.
Does a certification replace the questionnaire?
No, because what determines its usefulness is the scope. Two certificates carrying the same logo can cover very different perimeters, so it is worth asking what fell inside, what fell outside and when it was issued.
What is a subprocessor and why does it matter?
It is a third party your vendor contracts that also processes your personal data, such as cloud infrastructure or an email service. It matters because contracting the vendor means accepting its whole chain, and you should be able to consult the list and be notified when it changes.
When is the best moment to verify what the vendor answered?
The trial period. That is when you can create a user, revoke it and ask for the audit record of those actions, which checks several questionnaire answers at once.
If you are evaluating a security awareness platform and would rather start with the answers than with the product demo, the GDPR centre and the trust seals page are open. In the end the simplest test is that one, that the material is available before you ask for it.
Leave a Reply