The Vendor Security Questionnaire Is Theater. Ask Better Questions.

The spreadsheet arrived on a Tuesday with a five-day turnaround. Three hundred and twelve rows. It came back on Thursday with three hundred and eleven yeses and one N/A. The vendor’s compliance team ran it through an RFP automation tool, accepted an eighty percent auto-match rate, pasted boilerplate into the rest, and returned it. Your security team filed it in a SharePoint drive and checked a box in Jira. Nobody who understands the vendor’s actual architecture read the document.

The questionnaire is a liability artifact, not a risk artifact. Its real function is to give the approver a defensible file. When a breach happens three years later, the document helps general counsel prove the vendor violated the agreement. It does nothing to recover deleted records or explain the downtime to the board. You are not evaluating the vendor’s security posture. You are evaluating their compliance software.

Every question on the standard spreadsheet is a policy question, and policy questions have a yes. “Do you have an access review process?” Yes. “Do you encrypt data at rest?” Yes. A SOC 2 report describes controls over a system; it does not describe which of the vendor’s support engineers in which country can pull your rows on a Tuesday. A firewall does not stop a tier-two support rep who needs to query the production database to close a ticket.

The row that matters is usually around row 140, asking about production access. It is answered with a statement that access is restricted to authorized personnel. During the technical demonstration, ask the sales engineer to show the interface their support team uses to troubleshoot a customer issue. Watch what happens when they pull up a test account. If there is a “Login As” button next to every user profile and no requirement for the customer to approve the session, their support reps can see your unencrypted payload. The spreadsheet said yes to restricted access. The screen share told the real story.

The data-flow diagram attached to the proposal shows one hosting region. The sub-processor list, maintained at a URL in the data processing agreement, includes a separate service for support tickets and an OCR tool for document parsing. The primary vendor is just the interface. Your data is distributed across a supply chain of APIs. If the OCR sub-processor is compromised, they have 72 hours to notify the primary vendor. The primary vendor spends another 48 hours determining which customers were affected. By the time the primary vendor notifies you, your data has been exposed for five days. A sub-processor list is a URL until it is an exhibit in the master services agreement.

Ask a vendor whether they have an incident response plan and you will get a yes. Ask them when they last used it and you will get a meeting. Do not ask if they have a plan. Ask for the timeline from their last major outage. When was the detection, what was the interval to customer notification, and what changed in the codebase afterward? If they claim they have had zero incidents in the past two years, they lack monitoring. If it took them four days to tell the last customer, it will take them four days to tell you.

Legal asks for notice within 24 hours. The vendor’s draft says 24 hours after they confirm an incident affecting the customer. The teams spend more time arguing over the definition of the word confirm than on the number of hours. Ask what starts the notification clock before negotiating how long it runs. “Notify without undue delay” is not a number of hours.

The exit questions expose the architecture. Ask what happens when you leave and you learn who holds the data, in what format, at what cost, and for how long after you stop paying. Vendors who answer the first 299 rows in a day will stall on row 300. When a customer decides not to renew, the vendor points to the data portability section of the questionnaire, which says yes. They then provide a single 400-gigabyte JSON blob containing three years of unstructured activity logs with no schema documentation. Egress is billed per gigabyte. Ninety days after the contract ends, the backups still exist. The deletion certificate is a PDF with a logo and no name. An export is not an exit plan until someone has checked what it contains.

The security review ends when the contract starts, which is exactly backwards. The answers need to survive the sales cycle. If it is not in the contract, you do not have it. The standard questionnaire is a floor, not a ceiling. Fill it out to satisfy procurement. Then attach a supplement of operational questions and make the answers contractual.

The questions that change a purchase decision require nouns. You need to know which roles at the vendor can read or modify your data in production, whether those people are employees or contractors, and which countries they operate from. You ask for the access log for the last quarter. You request the current sub-processor list as of today, detailing what each one does and where it processes data. You ask who the security contact is when the account team is unavailable, requiring a phone number rather than a portal link. You ask which of these answers the vendor can support with a document, a log, or a screenshot by Friday. Finally, you require the name and role of the person who answered the supplement, and if it was the account team, the name of the person who reviewed it.

Ownership on the customer side is usually split. Security owns the questionnaire, procurement owns the contract, the application team owns the data, and the vendor manager owns the relationship. The risk lives in the gaps between those four. One name must own the service after signature, or it is nobody. At renewal, the same questionnaire receives the same answers with a new date. The vendor’s environment changed twice. Your data classification changed once. Nothing in the standard process compares the two. The renewal trigger should re-ask the core operational questions, not the standard spreadsheet.

The standard questionnaire measures the vendor’s process maturity in producing questionnaires. The actual risk lives in the gap between the policy documented on paper and the support engineer who can log into your production tenant.