What to Ask Your Vendors About Security

Most businesses treat vendor security as a procurement checkbox: does the vendor have a SOC 2? Is there an NDA? The actual security questions — the ones that reveal whether a vendor's access to your systems represents a managed risk or an unexamined one — rarely get asked until after an incident makes them urgent.

Every vendor with access to your systems, your data, or your infrastructure extends your attack surface. Their security discipline is effectively part of your security posture. The questions below are the ones worth asking before the contract is signed, not after.

About access and access management

What level of access do you need to our systems, and why? The answer to this question should be specific and minimal. A vendor who needs read access to a specific data set should not have write access to your entire database. Vendors who can't articulate why they need the access they're requesting may have more access than they've thought carefully about.

How is access controlled when your team members change? Employee turnover at a vendor means former employees may retain access credentials unless there's a disciplined offboarding process. Ask specifically about how quickly access is revoked when someone leaves and whether there have been incidents where access persisted longer than intended.

Do you use multi-factor authentication for access to our systems? MFA should be table stakes for any vendor with access to production environments or sensitive data. If the answer is "no" or "it's optional," that's a significant gap.

About data handling

Where does our data live, and who has access to it? Cloud region matters for regulated industries (HIPAA, data residency requirements). Personnel access to production data should be limited and logged. Knowing the answer protects you; not knowing means you can't assess the risk.

How is data encrypted at rest and in transit? TLS 1.2 or higher for transit; AES-256 or equivalent for storage. These are current industry minimums, not advanced requirements. A vendor unable to answer this question concretely hasn't thought carefully about data security.

What happens to our data when we end the relationship? Data deletion timelines, data return formats, and confirmation of deletion should be specified in the contract, not left to verbal assurance. The question also reveals whether the vendor has a clear data lifecycle policy or handles this on a case-by-case basis.

About incident response

What is your process if you detect a breach affecting our data? The answer should include a notification timeline (ideally 24-72 hours), a designated contact for security incidents, and a documented incident response process. "We'll let you know" is not a process. In regulated industries, your own compliance obligations may depend on how quickly you learn about a vendor breach.

Have you had security incidents in the past 24 months? What happened? A vendor who has had a breach and handled it well — with rapid detection, transparent communication, and process improvement — may be more trustworthy than one claiming a perfect record. How they answer tells you about their culture. Refusal to discuss is a data point.

About their security practices

Do you conduct penetration testing or independent security audits? When was the last one? Regular third-party security audits are the difference between a vendor that asserts security and one that verifies it. Frequency matters: annual is the minimum for production systems handling sensitive data.

What framework do you use for security management? SOC 2 Type II, ISO 27001, NIST CSF — these aren't the only valid approaches, but asking the question reveals whether security is a managed program or a collection of ad-hoc practices. A vendor who can't name a framework they use is likely in the latter category.

These questions pair naturally with the broader technology partner evaluation process — vendor security due diligence is a component of fit assessment, not a separate conversation. The vendors who handle these questions well are typically the ones whose security posture is something they think about, not something they perform for procurement.

Good technology partners don't treat security as a service line. It's a consequence of how they build. The questions above are how you tell the difference from the outside — before the access is granted, not after.

---

For vendors who ship software dependencies into your stack, lockfile scanning is a concrete due diligence step you can run yourself. Vekt scans npm, PyPI, Cargo, Go, and 18 other ecosystems against CVE databases and malicious package advisories — 50 scans per day free, CI-ready with JSON output.

Related reading

• What Happens When You Get Hacked: A Realistic Timeline
• What Your Vendors' Security Posture Actually Means for You
• Building a Security Culture When Everyone Thinks It's IT's Job
• The Problem with Generic Tech Recommendations
• If the Recommendation Came Before the Questions, It's Not Advisory

Frequently asked questions about vendor security assessment

What if a vendor refuses to answer security questions?

Refusal is a signal. Some vendors cite confidentiality concerns about specific implementation details — that's legitimate. But refusing to confirm that MFA is in use, or that data is encrypted in transit, or that they have an incident response process, is not a confidentiality concern. It's either a gap they don't want to disclose or a culture that treats security questions as adversarial. Neither is a good sign.

Is SOC 2 compliance sufficient assurance?

SOC 2 Type II certification confirms that a vendor's security controls were operating effectively during the audit period — typically six to twelve months. It's meaningful and worth requiring for vendors handling sensitive data. It's not a guarantee of current security posture, and it doesn't answer the relationship-specific questions (how is your access managed, what data do you retain). Treat SOC 2 as a baseline, not a complete answer.

How should vendor security requirements change for regulated industries?

The threshold rises with the sensitivity of the data and the regulatory framework. HIPAA-covered entities have specific BAA (Business Associate Agreement) requirements for vendors handling PHI. PCI DSS compliance requires vendor assessments for any vendor in the cardholder data environment. Cannabis businesses operating across state lines face a patchwork of data handling requirements. In regulated industries, the vendor security conversation needs to start with what the regulatory requirements actually specify, not just general best practices.

Who at our company should be responsible for vendor security assessments?

The person responsible for the vendor relationship should own the initial security questions, ideally with input from whoever manages your technical infrastructure. For businesses without internal security expertise, a fractional security advisor or a managed technology partner who handles vendor assessment as part of their scope is a practical alternative to building the capability in-house.