Why questionnaires fall short for vendor risk

Dropbox, like most modern companies, relies on third-party vendors for everything from HR workflows to sales, marketing, and IT. Those vendors sit inside the company’s security perimeter, so they need appropriate scrutiny based on the risk they pose. The traditional tool for that scrutiny—the security questionnaire—has proven largely ineffective in practice. Answers tend to be vague, hard to verify, and often favor vendors who can sound good rather than vendors who actually run good security programs. The result is a lot of back-and-forth, delays for internal stakeholders, and little useful signal.

Dropbox’s response was to move its core security requirements out of the questionnaire and into the vendor contract itself. The company has published its model security legal terms on GitHub, freely available for anyone to use and modify. The idea is that broader adoption of contractual security standards will push vendors to treat security as a priority rather than a checkbox exercise.

Principles behind the contractual approach

The model terms are not meant to be a perfect, exhaustive checklist. Instead, they follow four principles:

  • Encourage transparency. A permissive vulnerability disclosure policy (VDP) that welcomes security research is treated as a hallmark of a mature security program.
  • Prioritize decision-making speed. The process should give stakeholders a faster outcome than questionnaires did, while quickly surfacing failure modes that can be addressed and iterated on.
  • Protect Dropbox and security researchers. In a SaaS world, vendors are inside the perimeter. Dropbox needs legal cover to test vendor security and to protect external researchers who might find bugs affecting Dropbox, given how broad and complex anti-hacking laws have become.
  • Walk the talk. Dropbox should be able to commit to the same standard it demands from vendors. Requirements stay flexible—capturing the spirit of security best practices rather than rigid prescriptions like “you must use CVSS for severity.”

Shifting these requirements into legal terms made sense for several practical reasons. Dropbox already had to impose security and privacy obligations on vendors, so the contract language needed periodic revision anyway. Putting security requirements into the contract also centralizes them in one format, avoiding the overhead of a separate questionnaire process.

More importantly, the contract secures legal authorization for Dropbox and its bug bounty participants to conduct careful, good-faith security testing. That is a meaningful improvement over the “snapshot in time” limitation of a single initial penetration test. It also lets Dropbox incentivize external researchers to report bugs found in vendors, either through Dropbox’s own bounty program or by topping up a vendor’s existing payouts. Concrete bug reports give Dropbox data points if it needs to argue for cancelling a contract or mitigating risk some other way.

There is also a signal in how vendors respond. Engaging a vendor’s legal team directly produces less bluffing than a sales-led questionnaire discussion. If a vendor flatly refuses to agree to certain provisions, that refusal is itself useful information about their commitment to security and where to dig deeper.

Early results

The initial returns from the experiment are encouraging. Vendors who signed the new terms have already produced concrete outcomes:

  • One vendor discovered missing two-factor authentication on an important surface and contractually committed to fixing it—a finding that likely would not have surfaced through a standard questionnaire.
  • Vendors under these terms are in scope for Dropbox’s live hacking events, such as the previously documented H1-3120 event, which led to discovery and quick patching of an RCE-class vulnerability in a vendor.
  • Vendors coming under the Dropbox bug bounty umbrella—even those with their own private programs—have received dozens of high-value vulnerability reports, including XSS, CSRF, IDOR, and SQLi findings. Some were serious; finding and patching them is in everyone’s interest.

On the flip side, Dropbox has declined to do business with vendors who rejected significant portions of the security terms. Refusal to commit to transparency and researcher protection is treated as a red flag that a vendor’s security posture falls below the company’s standards.

A starting point for the industry

Dropbox acknowledges the approach is not perfect—it is still iterating on the language, scope, and how to handle vendors who sign on but fail to improve after demonstrating poor security practices. But the company sees contractual security requirements as the right direction for the industry.

The model language is published for others to experiment with. Dropbox cannot provide legal advice and recommends working with your own legal team to adapt the terms to your specific needs. Feedback and pull requests are welcome; the hope is that standardized, well-tested legal templates for vendor security will emerge over time.