Index ¦ Archives ¦ Atom

Startups and security questionnaires

Get me off this never-ending hamster wheel of pain

As a startup with a product/service, your potential customers want you to solve their problems & deliver value. However, they also have to consider how your product/service might affect the security of their business and data.

One often maligned way of doing this is the humble security questionnaire. It's not all fun and games, as a search for tweets will tell you.

Inevitably:

  • Most larger enterprises will have their own custom Excel workbook (probably with some pretty gnarly embedded macros!)
  • The enterprise you talked to today will have a slightly-different set of very-similar questions as the enterprise from last week.
  • Half of the asks won't appear relevant to your product/service, or will feel like complete overkill.
  • You'll need to get responses to this thing submitted by last Friday.
  • There will be 10 other more-important fires to fight or skirmishes to engage.

Why do they inflict this pain on me?

There are several underlying reasons for the painful questionnaire you're currently working through:

  • Some degree of due-diligence must be performed during vendor selection to protect customer data / company IP / etc.
  • Compliance requirements often include third-party security review.
  • Companies actually care about vendor security, because it affects their own exposure.

Three framing questions...

  1. What is the delivery model for the product/service I'm selling? (Packaged software presents different security concerns to cloud/SaaS.)
  2. What 'special' data types does my product/service touch? (For example, payment card information or health information.)
  3. What is the market/industry that I'm selling into? Are there any specific security standards or regulations associated with this market/industry? (A government agency will take a very different approach to another startup.)

More generally, how might your product/service introduce security exposures or weaknesses into a customer's environment? What might they be concerned about? What have you already done to reduce this risk?

How can I minimize the pain?

This will depend on your more specific answers to the questions above. The 'typical' methods for demonstrating security/compliance have some variation across both product/service types, data protection jurisdiction, and market/industry categories.

Generally though, here are some options to work through over time as your product/service & organization matures:

  1. Engage with the customer. In a bigger company, they'll likely be trying to help you through a "vendor review process". Sometimes, by helping the buyer better understand your product/service, you can cut down on requirements or reduce the load of the review process. (They may have a different set of questions depending on your answer to #1 above, for example. Or for [reason x], you may be able to skip the process entirely.)

  2. Copy-paste-and-tweak. Turn on your favorite productivity playlist & churn it out. Over time, you'll find that you build out a set of standard-enough responses that you'll have most of what you need for any given response written already.

    • Make use of "N/A", where appropriate. They can always come back to you if for clarification (and often won't).
    • Sometimes, you'll have to answer negatively - I've generally found it's better to be honest than ummm optimistic.
    • Often, you'll need to submit supporting evidence that might include policy documents, scan/test results, and more.
    • Recurring gaps may be considered for inclusion in your roadmap (although remember that your customer's risks & priorities most likely don't align with your own).
  3. Address security on your website and write a security whitepaper. The sooner you do this, the better. I've found that good security content and a proactively-submitted whitepaper that goes into depth regarding a vendor's security controls can help siphon off a percentage of assessment requests. Examples of these are Slack (web, whitepaper), Zapier (web), and Crisp (web) . You may find this set of questions useful as a starting point.

  4. Prepare responses to more-broadly-used formats. If you're providing cloud services, the Cloud Security Alliance STAR Self-Assessment (also referred to as the CAIQ) may be a good place to start. Other options might be the Vendor Security Alliance Questionnaire, Center for Internet Security Controls, or SIG (which has a cost). Ask your potential customers if there are certain formats that they accept.

  5. Get a penetration test. This is more easily done than an audit, and can help provide a potential customer with third-party assurance regarding the secuity of your product/service. Assess, prioritize, and actually fix any real risks that are identified during this process.

  6. Consider adopting a tool to streamline your response process, for example Whistic or Loopio.

  7. Get an audit. Probably a SOC 2 for a start, although again your audit selection will depend on your answer to the framing questions above. You thought responding to questionnaires was bad? Audits can be worse. Only take this step when you & your business are ready for the level of pain that audits bring.

  8. You're never done with just one audit. Repeat the same one you did last year, and even consider adding another audit target to your compliance efforts.

Does the pain ever go away?

Not really. If you grow into a massive enterprise like Microsoft or AWS then you're less exposed to individual asks, but you'll likely have a multi-million dollar compliance program (Microsoft, AWS) generating some arbitrary number of reports periodically to demonstrate your commitment to security.

Going forwards:

  • Security is important, even for startups. Do it smart. Ensure you have a programmatic approach to security & compliance. Hire smart, assign ownership, centralize efforts, standardize documentation, track operation, audit effectiveness.

  • Develop a unified set of security controls that incorporate all your sources of security/compliance requirements. This provides a single point of reference and helps standardize the approach between individuals/teams/products/services. Pre-canned options exist but I've found custom to be the way to go.

  • Consider adopting tools to support your security/compliance program. Comply from strongDM is one such example, and at the other end of the spectrum I've heard some pretty horrible things about Archer (enterprise-grade is a thing). For facilitating vendor-facing programs, Google VSAQ looks interesting and Qualys SAQ is another option.

I don't believe you, please take away the pain.

Others may be more useful than I. Check out:

Happy securitying!

© Jamie Finnigan; opinions my own and not my employers. Built using Pelican. Modified from theme by Giulio Fidente on github.