Security Questionnaires Aren't Making Anyone Safer

Pierre-Paul Ferland -

Let's be brutally honest about what Third-Party Risk Management currently is: a soul-crushing bureaucratic charade that wastes everyone's time, kills business momentum, and miraculously manages to make security worse in the process.

If you're a TPRM professional who spends your days pushing Excel questionnaires and chasing vendors for "proper documentation", and "remediation" after applying a filter on the "No" questions (or perhaps you're playing chess with the vendor and some questions are formulated negatively, so "No" is the right answer, and you've got a macro doing the filtering!) this is your wake-up call. What you're doing isn't security. You're taking part in compliance theater.

And deep down, you already know it.

The Great Security Questionnaire Scam

Every day, thousands of security questionnaires fly across the internet like digital confetti. 300+ questions of mind-numbing minutiae, desperately trying to cram modern security practices into frameworks designed when client-server was cutting edge.

Here's the ugly truth about this process:

  • Vendors constantly make liberal interpretations of the questions in order to check "YES" because they want the sale;
  • Customers demand perfection on controls they themselves haven't implemented;
  • Everyone involved knows it's theater, but nobody's brave enough to say it;
  • The entire process creates precisely zero actual security

Meanwhile, actual business value gets strangled while people argue about whether a managed Kubernetes service meets the definition of "proper network segmentation."

The Questionnaire Time Capsule: Still Asking About Server Rooms in 2025

Your template was probably written by consultants who haven't touched actual technology in a decade. That's why it's still asking questions like:

  • "Do you enforce password rotation every 90 days?" while vendors are using hardware keys and biometrics with no passwords to rotate
  • "Describe your off-site backup process" to companies using active-active, multi-availability redundant data centers
  • "Detail your network segmentation" to teams running service meshes
  • "Outline your patch management schedule" to organizations using ephemeral infrastructure that redeploys automatically
  • "How do you secure remote access?" when they've implemented device certificates with continuous verification
  • "Describe your change approval board process" to teams shipping 1,000 microservice releases weekly with automated testing and instant rollbacks

But instead of acknowledging this disconnect, we've created an entire ecosystem designed to perpetuate the lie. Vendors can't educate hundreds of customers on why these questions are irrelevant, so they just say "YES" and move on. Security teams can't admit their templates are outdated without feeling like they're compromising, so they keep demanding compliance with frameworks designed for a bygone era.

"Security Parent Syndrome"

There are two parallel universes in B2B security. In one, providers build modern cloud infrastructure with zero-trust architectures, automated security controls, and continuous deployment. In the other, customers' security requirements still mandate physical audits of server rooms.

The fastest way to burn out a security professional? Force them to live at the intersection of these worlds.

This "Security Parent Syndrome" manifests in requirements that would be comical if they weren't so crippling:

  • On-site security audits for cloud providers ("Just let me schedule that physical audit with AWS real quick...")
  • Full background checks for every employee ("Because clearly, our video producer is the weak link in our zero-trust architecture")
  • Source code escrow for microservices ("Let me just package up these distributed cloud functions...")
  • Mandatory security training using customer slides ("Nothing says 'modern security' quite like skimming through another PowerPoint")
  • Bans on virtualization and open source ("Let's pretend we can do better than everyone")
  • Manual log review requirements ("Who needs AI-powered threat detection when you have humans manually reviewing logs?")

Add to that the truly bespoke requirements that don't scale for any vendor:

  • Individualized disaster recovery testing
  • Specific naming conventions for firewall rules
  • Approval for every deployment and patch update

It's not just outdated, it's dysfunctional. And it stems from fundamentally misaligned needs:

  • Enterprises need standardization across vendors
  • SaaS providers need standardization across customers

Just like security professionals burn out trying to protect everything perfectly, cloud providers burn out accommodating every enterprise's unique requirements. And nobody wins.

The Broken Incentives That Keep This Madness Going

The incentives in TPRM are so broken they would make an economist weep:

  • Vendors are incentivized to find any tweak imaginable to a question's sense to get to a "YES" any "NO" means endless "remediation" calls, no matter the requirement
  • TPRM teams are incentivized to find problems to justify their existence
  • Business units are incentivized to hide vendor relationships until the last minute to avoid TPRM delays
  • Everyone is incentivized to pretend everything is "critical" because admitting otherwise means your program isn't taken seriously

The result? A system where nobody can be opened. A vendor can't admit they do something differently than your template expects. A TPRM analyst can't admit some controls don't matter for certain types of vendors. A business can't admit they need this vendor regardless of security posture.

So we get what we've designed for: a broken system optimized for documentation rather than security.

Breaking Free

Most companies get third-party risk management catastrophically wrong. Assessors send questionnaires, collect checkmarks, and turn every "no" into a finding demanding remediation. Vendors, on their side, misunderstand the whole thing by saying: "Our hosting provider is secure, we're good". The cycle repeats: pushing vendors to implement security controls that don't fit their business, forcing them to shift priorities, wasting time on what amounts to compliance theater. Instead of trying to fix every vendor weakness through endless remediation calls, look inward:

  • If a vendor is terrible at security, don't waste months chasing them for improvements they'll never prioritize. Go to the business and tell them the truth: "This isn't a company we should build critical systems around. Don't tie your workflows to them. Don't invest too much energy here."
  • When a vendor is solid, shift the conversation: "Why aren't we using them more? If they're more secure than another tool we rely on, why not consolidate? Why not replace the weaker option and reduce our overall risk?"
  • And when you encounter a truly top-tier vendor, pay attention. Sometimes, the best security move isn't nitpicking... it's learning from them! What are they doing that you aren't? What can you bring into your own systems?

Third-party risk isn't about making every vendor perfect. It's about knowing where to push, where to contain, and where to learn. And maybe, it's about having the HUMILITY to admit we don't have all the answers, that our requirements aren't the one-size-fits-all solution to every security problem.

A Better Way Forward

Security isn't one-size-fits-all. There's no single "RIGHT" way to do security. But you already know that.

The solution to our TPRM nightmare requires acknowledging some uncomfortable truths:

  1. Modern security is about architecture, not checklists
  2. Scale requires standardization on both sides
  3. Perfect security is impossible, resilience isn't
  4. Trust comes from transparency, not control

To enterprises: Stop trying to force cloud-native vendors into on-premises security models. To vendors: Stop "yessing" on questionnaires just to make the sale. To TPRM professionals: Stop pretending your Excel spreadsheet constitutes actual security.

Instead:

  • Focus on the risks that actually matter for your business relationship
  • Adapt your requirements to modern architectures
  • Embrace the reality that different vendors solve security differently
  • Prioritize transparency over checkbox compliance

The real skill in TPRM isn't collecting YESes and closing gaps on the NOs. It's understanding what truly needs protection and having the HUMILITY to admit there's more than one way to get there.

TPRM should be about managing actual risk, not manufacturing paperwork. It should help businesses make informed decisions about their vendor relationships, not obstruct those relationships with security theater.

Which kind of TPRM program are you running?