The security questionnaire trap
Most vendor security assessments follow a familiar pattern. You send a hundred-question spreadsheet. They check boxes. You review their SOC 2 report. Everyone signs off. Six months later, you read about their breach in the news.
The problem is not that vendors are dishonest. The problem is that standard assessments measure documentation, not security. A vendor can have perfect compliance paperwork and terrible operational practices. Or they can have solid security but terrible incident response.
This post identifies the questions that reveal actual risk, not just policy maturity.
Questions about incident response
How a vendor responds to incidents matters more than their prevention claims. Prevention fails. Response determines damage.
What is your incident response time commitment? Look for specific SLAs: notification within 24 hours of confirmed compromise, not "as soon as reasonably possible."
Who makes the decision to notify customers? If notification requires legal review and executive approval, you will learn about breaches late. The decision should be operational, not political.
Do you conduct tabletop exercises? Vendors who practice incident response perform better during real incidents. Ask for the frequency and scope of their exercises.
Can you provide a sanitized incident report from a past event? This reveals more than any questionnaire. Look for transparent discussion of what went wrong and what changed.
Questions about access control
Vendor access to your systems and data is a major attack vector. Assess how they control that access.
How do your employees access customer data? Look for least privilege: access only to specific customers, only when required, only for defined time periods. Avoid vendors where any employee can access any customer data.
What logging exists for customer data access? You want immutable audit logs that capture who accessed what, when, and from where. These logs should be available to you on request.
How quickly can you revoke all access for a terminated employee? The answer should be under one hour. Longer suggests manual processes that create windows of vulnerability.
Do you allow remote access to production systems? If yes, understand the controls: MFA, session recording, just-in-time approval, and monitoring.
Questions about security culture
Security culture predicts behavior better than policies predict behavior.
How do you train employees on security? Look for continuous, practical training rather than annual compliance videos. Ask for examples of recent training topics.
What is your security team to employee ratio? Ratios below 1:100 suggest potential understaffing. Ratios above 1:20 may indicate inefficiency. Context matters by industry.
Who reports to whom? The security leader should report to an executive with authority, not buried in IT. Security needs organizational independence.
What was your last significant security investment? Vendors who have not invested recently may be coasting on outdated practices.
Questions about business continuity
Vendor failure can be as damaging as vendor compromise.
What is your data backup and recovery capability? Look for defined RPO (Recovery Point Objective) and RTO (Recovery Time Objective). These should be contractually binding.
What happens if you are acquired? Understand data handling in acquisition scenarios. Some vendors sell customer data as an asset.
What is your exit process for departing customers? Data deletion, access revocation, and transition assistance should be defined and tested.
Do you have a disaster recovery plan tested within the last year? Untested plans are assumptions, not capabilities.
The vendor risk assessment checklist
Use this framework for consistent evaluation:
- Incident response commitments defined with specific SLAs
- Access controls follow least privilege with comprehensive logging
- Security culture demonstrated through training and organizational structure
- Business continuity plans tested with defined recovery objectives
- Compliance certifications validated (not just checked)
- Subprocessor and fourth-party risks identified
- Contract includes security requirements and audit rights
- Ongoing monitoring process defined (not just annual review)
- Risk rating assigned based on data sensitivity and access level
- Executive sponsor identified for critical vendor relationships
Red flags to watch for
Some responses should trigger deeper investigation:
"We have never had a security incident." Either they are lying, or they lack detection capability. Every organization has security incidents.
"Our security is handled by our cloud provider." Cloud security is a shared responsibility. Vendors cannot outsource accountability.
"We cannot share that information." Security through obscurity is not a strategy. Vendors should be transparent about their controls.
"We meet all industry standards." Compliance is the floor, not the ceiling. Ask what they do beyond compliance requirements.
Ongoing monitoring, not point-in-time assessment
Vendor risk is not static. A vendor who was secure last year may be compromised this year. Establish ongoing monitoring:
Quarterly check-ins: Review any incidents, changes to security posture, or personnel changes in security leadership.
Threat intelligence monitoring: Subscribe to alerts about your vendors. News of breaches should reach you from your vendor, not Twitter.
Right to audit: Reserve the right to audit critical vendors. Use it periodically, even if just to verify documentation accuracy.
Exit planning: Always know how you would replace a critical vendor. Vendor concentration creates systemic risk.
Third-party risk management is not about perfect assessment. It is about informed risk acceptance and continuous monitoring. Ask the questions that matter, and pay attention to the answers that reveal culture, not just compliance.
Disclaimer: This post is for educational and informational purposes only and does not constitute legal, compliance, or professional security advice.