Understanding the Security Questionnaire

A customer wants to know about your startup’s security practices

That big company wants to buy your little startup’s product. But, they’ve sent over a cringeworthy security questionnaire.

It has hundreds of mostly irrelevant questions about your product, technology, and company. Some of the requests are completely unreasonable. The customer won’t sign the contract until they see answers.

Or, maybe, they’re good questions, and you don’t have good answers yet.

For most startups, the questionnaire is the first time they’ve really considered their own security practices.

Does your startup have a security program?

A startup’s security journey can begin in many ways. For the unfortunate, it’s a breach. Others, it may already run deep in your team’s values. Maybe your product is literally about protecting something valuable, or maybe your executive board is already risk averse and has driven your concerns.

If you are only now starting to consider security at your company because of this questionnaire, be aware that a compliance driven origin to a security program can miss the point of why a security program is important.

Distraction, or call to action?

A small startup should value a ruthless approach to prioritization. When a customer comes along with opinions about how you should run your company, skepticism is healthy.

Behind the questionnaire is a good intention. Do not dismiss good intentions. Try to value your customer’s interest in how you manage risk, but don’t trip over yourselves to completely satisfy a questionnaire.

At the center of a vendor security process is a very complicated subject about your own risks, and we have to decompose it.

A questionnaire does not care about your actual risks.

A questionnaire appeals to the perceptions of risk by your customers, not your actual risks.

Customer security teams often project their own risks in the form of a prescribed list of specific controls. They usually apply the same prescription to every vendor they work with, regardless if it’s reasonable or applicable.

This often results in a theater of risk, and you can complete this questionnaire without having any tangible security at all. They may not even look at your answers.

That’s obviously not advisable.

You may feel a strategy of “sneaking past” the questionnaire by resolving only a few of the big ticket items they ask about. Some wordsmithing, rescoping, and copy pasted policies can take you the rest of the way.

• “Yes we just installed antivirus”
• “Yes we now have a firewall”
• “Yes we now have an information security policy”

…Deal closed!

However, there’s a cost. You can be damned sure they’re not asking about that Root AWS credential that lives on every server and laptop, or that unauthenticated, internet facing Jenkins server, or those plaintext copies of encrypted data being logged into your loggly account because of some exported variable in a stack trace you haven’t noticed. There’s no way for them to efficiently understand your actual risk and your actual security debt with a dumb questionnaire.

Upon thinking about this interaction, it breaks down to confusing how you express risk to a customer with your actual risk. It’s sort of like confusing a suit for professionalism, or lavish jewelry for wealth. A suit won’t make you a pro, and jewelry won’t make you rich. Passing a questionnaire in the short term will rarely mitigate much of your actual risks.

If a customer calls you up with a specific, thoughtful question about your security… it will likely not resemble those that appears on a questionnaire. In that case, take it seriously. This article is about the tradition of security questionnaires, not the specific concerns expressed by a customer.

You might not need to fill out this questionnaire.

An early reaction you will likely have is “We can’t fill out long, boutique questionnaires out for every potential customer.” Some examples of these questionnaires are upwards of a hundred pages long, so this makes sense.

Some companies outright reject all customer questionnaires. But again, this varies per sales team, product, and customer. You might not get away with that.

Instead, alternative approaches may satisfy a customer’s security process, and result in a contract, without filling out a questionnaire. You can:

• Share the summary from a security audit
• Show metrics from a bug bounty program
• Build an FAQ on the internal practices you want to brag about
• Host a vulnerability disclosure program. Share metrics on response time and push for bug bounty. Maybe commit to a special SLA to the customer.
• Offer an incident escalation channel with an SLA, and commit to assisting in any investigation they need.
• Offer a breach notification policy. Commit to early notification of a possible incident.
• Have an incident response policy, and an approach to risk management documented that you can share.
• Have an internal information security policy that you’ve committed to, so a customer can back off from imposing their own policies.
• Fill out the answers to a more reasonable security questionnaire, like the Google Vendor Security Questionnaire or the VSA questionnaire, and return them instead of the bespoke questionnaire per customer. Industry specific versions exist like shared assessments (for pay) are around too.

These are all examples that might avoid the questionnaire altogether with an approach that could better relate to risks you deem to be more important.

Your answers are only one part of passing the questionnaire.

It’s important to understand the challenges of the security team that is sending you this questionnaire.

The blocking authority a security team wields within a customer’s organization varies wildly at each company. For instance, some legal teams will not approve a contract without a security team sign off. In more extreme cases, a security team may even ask for a invasive audit involving access to your network or source code, or send a Big 4 auditor to your company. It is very common for a security team to “catch” vendor risk in progress by partnering with a contracts team or legal counsel to intercept the risk for them. This behavior is more likely to happen if your product carries larger risks to the customer as this kind of deal will surface and be inspected more thoroughly.

On the other end, a security team may be entirely powerless in their vendor process. The questionnaire may be sent out as a courtesy to your contact’s security peers, but it may not even be checked after it’s returned to your customer.

As a seller, you could try a polite “no, we don’t answer these” and you may still have the deal. Yes, this is calling their bluff. This bluff happens especially often when the customer is already paying for your product, or if they have a rabid internal demand waiting for it.

Sometimes, you might be the only vendor that exists to solve a customer problem. They will usually pass you through regardless of how bad your security is, but obviously shouldn’t be considered a good thing.

Ultimately, even if you have horrible security, the questionnaire process helps the customer’s team manage risk, even if you’re creating a bunch of it for them.

The lesson here is that your success with security questionnaires has little to do with your security, regardless of the strategy you eventually take towards it.

Questionnaires at scale begin a compliance conversation

Your leadership will eventually see a backlog of failed or disrupted sales due to security conversations, or at least friction in their sales pipeline that slows conversations down.

It’s reasonable to expect a sales process will not manually complete every security questionnaire that comes through. You have probably arrived at “how can we skip the security team review” (or at least automate it) question independently.

This usually pushes a company to seek help through a compliance standard, like a SOC 2 report issued from the AT 101 audit standard. Also common is ISO 27001:2013 certification. To obtain one of these reports, you work with a CPA or certified auditor who applies the method you’ve chosen, and you’re left with a deliverable piece of sales collateral.

An audit process requires external consultants to complete, and requires time in months and money in the tens of thousands of dollars.

When accomplished, the hope is that this may end the security related friction in customer conversations and unlock conversations with companies that required a certification as a prerequisite to even talk to you. You would ship off a document that represents your security program well to satisfy the customer, and you move to close a deal faster.

This is often wrong. Even with compliance projects accomplished, you may still have customer friction. Again, this friction varies per industry, customer, and product.

• Company with a SOC 2 report may still have to satisfy a customer security team’s questionnaire.
• Maybe you’re PCI compliant, but you may have to prove security controls outside of a payment environment.
• None of this may matter, and they may ask to fully audit you anyways. I’ve been involved with full, open box, source code audits of products that cost more to execute with a consulting firm that the product itself. In this case, no level of certification matters.

It’s important to really think of compliance as a factor in a negotiation. But, it’s also important to think of compliance compared to your actual concerns about risk.

Preferring a risk management approach to compliance

Many people who operate in the compliance space will freely say that they do not work on security. They feel strongly that the compliance space is a totally different beast. I have mixed opinions on this.

Despite being guided by prescriptive compliance approaches, you can still orient your compliance activities towards the risks you prefer. You don’t have to abandon compliance, or cheat through it completely.

When you are interviewing for a job, you are representing your capability for the reward of employment. When you ask someone out, you are hoping they have the best version of yourself in their mind before answering.

It is entirely possible to lie on your resume and land a job. It is entirely possible to be a heartless sociopath who convinced someone to join you to dinner and a movie.

If you refuse to express your strengths, you do not get the job. If you choose not to flaunt your worthiness as a mate, you do not get the date.

If you choose not to play the questionnaire game to all, you’ll lose out on business. You do not get the business.

What is missing is an honest approach to compliance. You want a compliance program to accurately express your already existing methods to manage risk, assuming you have them. And if you don’t, this may be where you begin.

This is challenging due to compliance frameworks that are often prescribed. They will corrupt your internal prioritization of risks, which you have to thoughtfully defend yourself against. For instance, you may feel distracted by writing strange documentation or deploying antivirus to meet a checkbox when you really need to focus on centralized logging, a much more valuable problem. These compliance driven decisions can really twist you up.

This is why it is important not to rush into compliance and to be highly thoughtful of how customer security demands will influence your company. It matters if you stray too far from actually representing something truthful underneath.

Expressing your security program proactively.

Outside of compliance programs and questionnaires are companies that will publicly brag about their efforts to secure their customer’s data. It’s easiest to see this by example. Amazon has the gold standard, describing the investment they make into security and allowing you to download their compliance documents, but also a lot of “extra credit” claims outside of their compliance program. Looker and Square and Slack and Google have built these out as well.

As your sales team communicates more frequently with customers, you’ll know what is important to proactively communicate.

Conclusion

Questionnaires and compliance processes should not distract you from your natural ability to prioritize risk. We’ve discussed some of the ways to focus on the expression of risk to create space for our own, more preferred ways to mitigate risk.

Ultimately as a startup, you should prefer to deeply understand this process so you can ruthlessly prioritize the real value underneath, which is an honest approach to risk. You have many tools, including compliance programs, contractual guarantees, and intentionally created security marketing, to help you stay closer to actual risk management instead of blindly filling out questionnaires.

@magoo

I write security stuff on medium.