5 Critical Security Questions to Ask Every New Vendor

A vendor with a SOC 2 badge on their homepage isn’t automatically a safe vendor. That badge tells you almost nothing about the scope of the audit, how recent it was, or whether the data security controls actually match what you’re trusting them to protect. The organizations that get burned by vendor risk usually aren’t the ones who skipped due diligence entirely – they’re the ones who stopped at “yes, we’re SOC 2 compliant” and never asked what that actually means.

Vendor-caused breaches aren’t rare. According to the 2018 Ponemon Institute report “Data Risk in the Third-Party Ecosystem,” 59% of organizations had experienced a data breach caused by a vendor or third party. That number hasn’t gotten less relevant. Here are five questions that separate vendors with real security programs from vendors with good marketing.

1. Can we see the full SOC 2 Type II report, not a summary?

Many vendors provide a certificate, a letter, or a one-page executive summary. However, none of these details are informative. You should get a full report, specifically a Type II report rather than a Type I report. Type I confirms controls existed at a service organization as of a specified date. Type II confirms the operating effectiveness of controls at a service organization throughout a specified period, usually between six and twelve months.

When a vendor hands you a Type II report, look to see which of the five Trust Services Criteria it measures against. AICPA has organized SOC 2 into five key categories – security, availability, processing integrity, confidentiality, and privacy. Not all vendors are audited against all five categories. If you’re using a vendor for financial data but they have only been measured against “security” and “availability”, there’s a meaningful gap there, and you should treat their report as a proxy, not a conclusion.

Also, make sure to look at the independent auditor’s report (the auditor’s opinion), and the statement regarding the effectiveness of the service organization’s controls. The words “qualified opinion” or “the following exceptions were noted in testing” should be concerning to you, but they’re on a different page than the executive summary.

2. What’s your incident response plan, and will you commit to a notification window?

Every data security vendor will say they have a plan and that they’ll call you soon after. Fewer can give you a specific number when you ask “How many hours?” For most, it’s enough if you go from being confident they have a plan to realizing that you aren’t sure. That’s a good moment to ask for a draft of their plan.

Many contracts now specify 72 hours, mirroring breach notification laws like GDPR, but the number itself matters less than whether it’s written into the contract rather than just described in a sales call. Ask if the plan has been tested. A plan that’s never run through a tabletop exercise, or hasn’t handled a real incident, is a theoretical exercise in creative writing. Ask when the last test happened and what changed afterward. Vendors with mature programs will have an answer ready. Vendors without one will get vague fast.

3. Who are your subprocessors, and are they covered by your SOC 2 report?

Many data security buyers skip this question, but it creates the biggest blind spot. A vendor’s SOC 2 report covers the vendor’s environment, but likely doesn’t cover the subprocessors – the cloud hosting provider, the analytics tool, the customer support platform – that also touch your data.

Ask for a current list of subprocessors and how the vendor vets them. Does the vendor require SOC 2 reports from its own vendors? Does it conduct its own reviews, or just take the vendor’s word for it? A vendor that can’t answer this clearly is passing risk down a chain they don’t fully control.

This is also where a structured review process shines. Rather than simply reading a report and hoping for the best, run the vendor’s disclosures against a soc 2 compliance checklist that maps their report against the trust services criteria related to your risk profile. It turns a stack of PDFs into a decision you can actually defend later, to a client, an auditor, or your own leadership.

4. What happens to our data after the contract ends?

You can inquire about how long the vendor retains data by default, whether encryption at rest and in transit is standard or optional, and what measures they actually take to destroy your data once a contract ends or you request deletion.

Ask for details. For instance, “We delete your data” is not a concrete response, but “Data is purged from production within 30 days and from backups within 90, with destruction logs available on request” is. If the vendor is unable to outline the details, it’s likely they haven’t implemented the process, and they are just stating an intention.

5. How often do you test your own security, and what’s your insurance coverage?

A SOC 2 report provides insights into the controls implemented by a service organization at a specific point in time or during a specific period. This isn’t synonymous with continuous testing, however. For a more holistic view, inquire about how often the vendor performs penetration testing, the frequency of vulnerability scanning, and the service level agreements related to remediating any issues that are discovered. A vendor that tests quarterly and patches critical issues within a few days is clearly working under a different model than a vendor that tests annually and can go months before they’re able to address a vulnerability.

Also, don’t be afraid to inquire about the vendor’s cyber liability insurance policy. While many vendors may have a policy in place, the specific coverage limits and exclusions can vary widely. In fact, the exclusions within a policy are often more important than the existence of the policy itself. A policy that specifically excludes vendor-related incidents or breaches of a subprocessor may not be of much aid to you when you need it.

Treat SOC 2 as a starting point, not a finish line

None of these questions are designed to catch vendors doing something wrong. They’re designed to separate vendors who can produce evidence from vendors who can only produce assurances. A gap assessment against your own risk requirements, built from real answers to these five questions, gives you something a badge on a website never will: a defensible reason for the data security decision you made.