No one likes security questionnaires. Companies hate them so much that they often have a boilerplate version they send to every vendor regardless of use cases and type of service provided. Vendors hate them so much that they spend hours complaining about them and trying to find ways to dodge them.

As someone who’s built and run security programs in startups and enterprises and has been working in the trenches of cybersecurity for a decade and a half, I’d be sympathetic about this, but adamant that people had to grit their teeth and get through it anyway – if it actually did the job. After all, no one likes going to the dentist, but that’s not a good reason to avoid it.

The trouble with security questionnaires is that they don’t do the job. They aren’t making companies more secure. They don’t give the necessary clarity and transparency. And even worse than that, the fact that we keep relying on them is actually counterproductive to our core missions.

It’s time to rethink.

Unpacking Why Security Questionnaires Are Terrible

“Oh great, a security questionnaire! We love those, they’re fantastic, we’ll get right on it and give you precise, tailored answers in a few days.” ~ said no one, ever. 

I can’t count the number of times I’ve been at a conference and had a discussion session or a chat end up turning into a venting/mutual support session about how much everyone hates security questionnaires, and that’s a trend I’ve seen equally from the supplier side and from the buyer side. 

There are some things that come up repeatedly. I want to spend most of this article on aspects that I think don’t get enough attention, but here’s a list of the main issues that are well known and about which there seems to be broad agreement:

  • Security questionnaires are long and time-consuming for everyone involved, leading to fatigue and inaccuracy or carelessness on all sides
  • Security questionnaires are rarely tailored to the relevant company, service or product
  • Answers are often from an approved list of template responses, also not tailored to the company sending the questionnaire, and often not updated frequently enough.
  • Security questionnaires are not updated often enough either, so they frequently fail to address the reality of the company’s infrastructure or the wider security environment
  • Because there’s a legal element around compliance and covering bases, jargon and convoluted sentence structures are often present

The thing to note about all of these factors is not that they’re annoying (although that may be true too) but that they make the process much, much less effective and relevant. People are asking and answering the wrong questions – and sometimes even the wrong kind of questions – in the wrong ways. 

Why We’re Trying to Automate Something Bad

Given the huge friction and frustration involved in the questionnaire process, it makes sense that there are a lot of platforms out there now trying to streamline it for everyone involved through automation. 

The logic goes that if security questionnaires are a fact of life, and we can’t avoid them as either companies or vendors, then at least we can try to make the whole process less painful and more efficient for everyone involved. 

I think that’s a noble motivation. The goal is to save a lot of time and effort so that it can be better spent. Among other things, it can be spent on elements of a security program that really reduce risk. That’s great. 

The problem with this approach is that it not only accepts questionnaires as the status quo, it helps entrench and validate that. But with automation, what you’re really doing is taking something bad, and reimagining it to work at scale. If two wrongs don’t make a right, then two hundred or two thousand wrongs certainly don’t.

Why We Keep Doing Them Anyway

Given that security questionnaires don’t really help on the security side of things – and the industry is broadly agreed that this is the case – the question is, why do we keep relying on them anyway?

Some of the answer is that they’ve become the accepted checkbox exercise to ensure compliance requirements are met. Whichever certification you’re going for, the chances are they’ll have some requirements around third party risk management. So you need to make sure you’ve got processes in place that you can point to when someone asks you about that. Security questionnaires check that box. 

Security questionnaires feel like an obvious fit for the compliance challenge because the compliance requirements are typically not prescriptive. In fact they’re generally fairly vague. Instead of, for example, mandating SSO or MFA, or background checks, and so on, how companies assess third party risk is left very much open-ended from a compliance standpoint. Really going through the process of thinking through what your organization needs to know about third party providers and how to manage that risk is a lot of pressure and requires a lot of thought, whereas questionnaires are easy and are sometimes even purchased off a shelf. 

Moreover, a security questionnaire allows for ambiguity and is something companies feel in control of, because they can change the questions in it whenever they want even though in practice it doesn’t happen often.

There’s an extent to which security questionnaires make us all feel just a little in control. How do we measure security when it comes to third party risk? We do our own audits. We audit ourselves. It’s all in our hands. And if everyone is doing it, then we don’t want to be the outlier in case that looks irresponsible.

Why The Incentives Are Out of Whack

Security questionnaires usually happen as part of a sales cycle. 

That’s logical, because that’s the point when a company needs to get to know a prospective vendor and check that they’re a safe supplier. Especially if the vendor is going to need access to the company’s systems or data, it’s vital to understand how their own security processes and protections work in order to understand any risks associated with the relationship.

So far, so good.

The problem is, by the time the sales engagement gets to the point of security questionnaires, nobody wants to say no. No one in this process wants a vendor to fail because of the security questionnaire.

The vendor wants the deal to close:

  • The account executive wants the deal to close, because they’ve invested a lot of time already and they want the commission and to hit their KPI targets.
  • The engineers or product or security folks on the vendor side want the deal to close, because enabling sales in this way is part of their job (sometimes as actual KPIs) and growth through attracting new business is good for the company. 
  • The executives or other leadership who may have to sign off on answers on the vendor side want the deal to close, because they want the company to grow under their direction. 

Here’s the bit that people often miss. The company also wants the deal to close:

  • The team who wants to purchase the product or service wants to start using it, sooner rather than later. That’s why they kicked this whole thing off in the first place. 
  • The security team evaluating the answers to the questionnaire don’t want to be naysayers, blocking things all the time. They want to be business enablers. If they aren’t, they’ll lose internal trust and influence. 
  • The leadership who might be brought in want the process sorted quickly. A lot of time has already been invested, and if there’s agreement that this tool is necessary, they want it sorted so that not having it doesn’t impact smooth operations and results. 

On a pragmatic level, everyone involved with the company understands that you can’t block things too often or demand changes too often, because if that happens the result is that teams start trying to go around security teams and measures, and you end up with a mess of shadow IT, no transparency, processes being circumvented etc. If the organization has a habit of throwing rocks into the path of the water of its business functionality, the water eventually just goes around the rock. 

So the answers get spun in the most positive way possible, even if that’s not entirely accurate, the organization doesn’t really learn what it needs to know, and no one has any incentive to change this. 

Why We Should Stop Relying on Security Questionnaires

When the incentives are out of whack, a model of self-attestation just doesn’t make sense. It’s the lowest possible bar of security review that you could possibly trust. And yet, somehow, organizations with impressive, deep protective internal securities policies and practices accept this lowest possible bar when it comes to third party risk management. 

What really gets me about it, though, is that it’s almost always an entirely pointless exercise. Say the questionnaire does actually turn up a gap. So what?

If you’ve uncovered a gap between your expectations, as a company, and the vendor’s expectations about their practice, the chances are that there’s absolutely nothing you can do about it. This isn’t your company. It isn’t your budget. It’s another organization, another budget, another set of executives and priorities and roadmap. 

The most you can do is tell someone about it, inside your organization and the supplier’s. You can threaten not to work with that team. But if that’s the path you take, you may need to start taking it frequently, because in reality there are probably gaps quite often. If you insist on this approach too often, you’ll lose credibility within your own organization because you’re preventing people from doing their jobs effectively with the tools they need. Eventually you might even have to leave your organization. 

Extremely large organizations, with valuable partnerships, may be able to enforce changes on a vendor, but this is an exception rather than a rule. For most companies, the reality is that security questionnaires simply don’t do the job.

It’s time to say goodbye to questionnaires. They waste a lot of time, cause a lot of frustration, discourage accurate assessments of real risk, and cause organizations to have an unrealistically positive impression of their own security ecosystem. They’re not just ineffective, they’re counterproductive. And they should stop.