Safeguard
Security Guides•

Eight red flags in a vendor's security questionnaire answers

Spot weak or evasive answers in a returned security questionnaire: vague wording, copy paste, missing scope and unexplained not applicable replies.

Safeguard Security Team
3 min read

The strongest warning signs in a returned questionnaire are vague answers, answers that do not match the question, missing scope, unexplained "not applicable" replies and a refusal to share any evidence. One flag is a prompt for a follow-up. Several in one document mean you should slow down.

1. Every answer is "yes"

Real programs have gaps. A questionnaire with no partial answers, no roadmap items and no comments usually means someone optimized for speed. Ask which three controls the vendor is still improving.

2. Answers that dodge the question

If you ask "do you encrypt customer data at rest?" and the answer is "we take security seriously," that is a non-answer. Re-ask the exact question and request a yes or no first, explanation second.

3. Policy language where practice is needed

"We have a policy for access reviews" does not say whether reviews happen. Ask for the date of the last review and who signed it.

4. Scope is missing

Look for what the answer actually covers. A certificate may apply to one product or one office, not the service you buy. Ask: does this cover the exact service and the hosting locations we will use?

5. Unexplained "not applicable"

Some controls truly do not apply. Each should come with a reason. A blank "N/A" on incident response or logging is worth a call.

6. Mismatched answers

Compare the answers with the vendor's public security page, privacy policy and subprocessor list. If one says data stays in one region and another lists subprocessors elsewhere, ask which is correct.

7. Evidence is refused or delayed forever

Vendors often protect internal documents, and an NDA is reasonable. A blanket refusal to show anything, even a redacted extract, is different. Ask for the smallest evidence that would settle the point.

8. Copy and paste leftovers

Another customer's name in a comment, a mismatched date, or an answer that refers to a product you did not ask about. These suggest the answer library is stale. They do not prove a weak program, but they do tell you the answers may be old.

What to do with the flags

  1. Write the follow-up question for each flag, one sentence each.
  2. Set a reply date.
  3. Record what the vendor said, not what you assumed.
  4. Decide in advance which flags block purchase and which only need a fix by a date.

Keep the tone factual. The vendor is often one overworked security person.

Quick check

Is one red flag enough to reject a vendor?

Rarely. Ask the follow-up first. Reject when the issue is serious and the vendor cannot or will not address it.

What if the vendor cannot share evidence for confidentiality reasons?

Ask for a redacted extract, a screen share, or review under NDA. A complete refusal is a flag in itself.

Last reviewed: 19 October 2026.

Never miss an update

Weekly insights on software supply chain security, delivered to your inbox.

Self-healing security runs on Safeguard.

Your first fix PR is minutes away.

No sales call required, even your agent can complete the purchase over MCP.