Answering "Dumb Security Questionnaires"
Oct 07, 24
I want to be explicit: you only earn the moral high ground on security questionnaires if you are running a tight ship. This blog is not advice on lying to your customers about how much risk you’ll put them in. Nor is it permission to focus more on gaming security questionnaires than nailing your security program. It’s definitely not an excuse to deride or disdain the humans on either side of this broken process.
Security questionnaires…
The equivalent of the awkward small talk at the beginning of a sales call, but instead of local sports you’re spending hours fielding questions about touring your data center … after 15 mentions of your cloud-native architecture.
Dumb Security Questionnaires is a Latacora blog post offering a send up of this problem. Jamie Finnigan also rounds up numerous tweets maligning the process as part of Startups and security questionnaires.
Alex Smolen gave a recent perspective over on the Modern Security Podcast. To put words in his mouth, security questionnaires are currently a low-signal bureaucratic chore.
Spend enough time in the security questionnaire mines, and you’ll see wonders such as:
- questions featuring Cold War-era acronyms
- requirements derived from 80s government procurement paperwork
- screenshots of paper forms that someone scanned before the invention of color
- leading questions on questionable security practices like Phishing Simulation or IDS appliances for your cloud environment
Five years later, the only progress we seem to have made is using LLMs to write questionnaires, LLMs to answer them, and LLMs to assess the responses.
🤑 There are emerging options for buying your way out of a lot of this pain, even for small startups. Historically, large companies could hire armies of Big 4 consultants to run their vendor risk programs. Companies like SecurityPal and Repliance now manage these questionnaires as a service. Automation, often AI powered, is a competitive field with entrants like Vanta, Conveyor, and Stacksi. These vendors should be applying this posts’ tips on your behalf!
There is misery on all sides of this. The sales team has enough problems without you conscientious objecting to their prospective customers’ process. However, so long as you are not the long peg in the sales cycle, there is some flexibility to play with here.
Work with your sales organization. Develop boundaries and a customer profile. Get set up to recognize signs a prospect is not the right customer for you.
You’re a small startup so your prospective customer should understand the limitations of your security program. If they don’t, they are not the right customer for you.
Work-Bench: Security For Enterprise Startups To Scale & Sell
Preempt
To combat security questionnaires, build customer trust proactively.
To put your security posture at the center of your value proposition, start by preparing your sales team with proactive security collateral. The basics include a whitepaper, a “trust center” or “security” page on your site, and a compliance or audit posture (such as SOC2 or ISO27001).
Putting these in place can satisfy most customers, without relying on a questionnaire. To get the most value, make sure you move the default response for a questionnaire to “check out the materials first,” to give customers a chance to self-solve. You can also augment this with some of the “standard” questionnaires … but there are more and more of these every year.
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.
Jamie Finnigan: Startups and security questionnaires
Common “Dumb” Questions and Smart Answers
Before we talk about clean and dirty tricks for handling questionnaires, let’s highlight two common time sucks in questionnaires.
The first is when you get asked about adherence to a framework that either doesn’t apply to your business directly, you don’t find useful, or even that you’ve never heard of. In those situations, the best thing to do is say what framework(s) you use, and ideally why. Saying “No” invites more back and forth, and misses the chance to offer a “good enough” answer. If you’re doing this, just make sure you’re aligned to something well known and not “Johnny’s Framework for Cyber.”
Do you adhere to TISAX?
As a U.S based firm in the financial services industry, we adhere to PCI-DSS and maintain SOC2 certification.
The second is when you get asked leading questions about “best practices” that are outdated or out of line with your perspective on security. Common examples would be requiring commodity DLP software, phishing simulation, employee monitoring, or legacy antivirus. You have multiple options here:
- You can say no. In this case, I recommend considering whether there is a negative impact from the request, or it’s just suboptimal. If complying doesn’t increase risk or harm your program, it may not be worth resisting. If you do have a strong stance, consider creating materials to explain your perspective, with authoritative citations and information on other mitigating controls.
- You can say no, but hedge on “exploring” or “considering” implementation in the mid to long term.
- You can take on the request, and make a concrete commitment to implement the necessary details.
If you decide to change your security program in response to customer requests, make sure you’ve aligned with the business on a cut line and costs. Don’t change your program for anything but the largest and most strategic deals.
Clean and Dirty Tricks
There are some basic tips to get you through a questionnaire unscathed:
Answers should be “satisfying but unobjectionable”
It’s okay not to answer questions if they are irrelevant, and it’s okay to say no sometimes. Frankly, if a questionnaires is just “yes”es down the line I start to get suspicious.
Always answer in good conscious and good faith
This can include focusing on high level answers, without diving into details where reasonable programs might diverge. For example, if asked “do you have SLAs for patching high risk vulnerabilities,” you don’t need to volunteer your risk rating process or the actual SLA! If you’re able to answer the letter of a question, don’t try to guess at the spirit. Try to find a way to “yes,” from some perspective of the question, and if they dive deeper you can clarify later.
Tune the specificity of your answer
… to that of the question. Sometimes this produces extremely dumb answers. “Yes, we have a policy for that.” But they’re completely correct, and delivered professionally, and the customer will ask follow ups if they need to.
Anticipate objectionable answers
… and proactively add a little color. If you need to give a “No” where you have a known gap, try to highlight why the risk is acceptable. For example: “The question asked whether we remediate all vulnerabilities - some low-risk findings get accepted”.
Take advantage of “implicit hand-offs”
… away from the questionnaire process. For example, “to be established contractually” is a great answer for SLAs and similar quantitative elements. This gives your risk management counterpart the ability to think “oh, this is now in Legal’s inbox, and I can go on with my life.” And it moves any disagreements into a place where decisions are made much more thoughtfully by the business (hopefully)!
Use layers of indirection where helpful
… referring off to specific audits or controls that meet the spirit of the question. For example, you’ll frequently get asked about usage of an IPS in cloud environments. GuardDuty is generally enough to meet this even if it’s debate-ably in that category. Skip convincing every customer of this and just reference your e.g. PCI audit, to show you convinced the auditor.
The Politics Around Questionnaires
It takes immense political capital to block a project that has strong internal sponsorship. There are generally a tiny subset of questions that actually are dealbreakers. Try to get a feel for these generally to your customers, and specifically to a given deal. Your answers are just one input to closing a deal. The person reviewing it in larger companies is unlikely to have direct blocking authority.
Don’t neglect the difference between a questionnaire and a contract. Commitments to explore improvements are not legally binding unless they make their way into a contract. Dropbox at one point explored pushing questionnaire elements directly into contracts, however this isn’t pervasive beyond a few key terms.