Security reviews · July 2026 · 7 min read

Why security reviews kill revenue, and how growing companies stay ahead of them

By Manoj Kurmi, Founder at Sorila · LinkedIn. Manoj is building Sorila and researching how growing B2B companies complete customer security reviews.

A deal can look solid until the buyer sends the security questionnaire: a long spreadsheet covering encryption, retention, access control, subprocessors, and incident response.

For teams without a dedicated security or GRC function, that file becomes a scramble. Engineering, a founder, whoever owns compliance, and sometimes outside counsel all get pulled in. Meanwhile the sales cycle waits.

What these questionnaires usually are

Buyers often send a custom workbook, or they reuse a standardized third-party risk questionnaire. Two common industry instruments are:

Even when the file is “custom,” many rows still echo those control domains: cryptography, access management, privacy, availability, and incident response. The operational problem for a growing company is the same either way: extract the questions, find trustworthy answers, and return the buyer’s file without inventing commitments.

The cost is more than calendar time

Speed is the visible problem. Questionnaires sit unanswered, follow-ups stack up, and close dates slip.

The quieter problem is quality. When several people edit the same sheet over weeks, you often get:

  • Answers in one section that contradict another.
  • Last year's responses that no longer match the product.
  • "Yes" answers to commitments engineering cannot support.
  • No record of who approved what, or where the evidence lives.

Hypothetical: how a deal-blocking answer goes wrong

The following is a clearly labeled hypothetical, not a customer story. It focuses on an incident-notification commitment, a different risk than encryption scope. For a worked encryption example, see Evidence before eloquence.

Hypothetical question

“Do you notify customers of security incidents within 24 hours?”

Weak answer copied from last year

“Yes. We notify all affected customers within 24 hours of any security incident.”

Where the contradiction comes from:

  • Policy: Incident Response Policy v1.4 says the on-call lead notifies affected customers “without undue delay” after Legal confirms the event is a customer-impacting incident. It does not promise a fixed 24-hour clock from first alert.
  • SOC 2 report: The Trust Services Criteria for CC7.4 require a defined incident-response program that includes communication as appropriate (AICPA 2017 Trust Services Criteria, CC7.4). The report in this hypothetical describes that a plan exists and was tested. It does not attest to a contractual 24-hour customer notification SLA.
  • Old questionnaire: Last year’s “Yes / 24 hours” was written by a sales engineer under deadline pressure, before Legal reviewed notification wording.

Safer cited answer

“We notify affected customers without undue delay after an event is confirmed as a customer-impacting security incident, per Incident Response Policy v1.4, §6.2. We do not commit to a fixed 24-hour notification SLA from first detection. Timing also depends on any customer-specific contract terms.”

The weak answer can unblock a cell in the spreadsheet and still create later risk: a diligence follow-up, a MSA redline that hard-codes 24 hours, or an incident where the team cannot meet what was promised. That is how a questionnaire answer turns into a revenue and liability problem, not just a compliance one.

What is changing in the question set

We are not claiming a measured industry-wide shift in when questionnaires arrive in the sales cycle. What we can say from public guidance is that the subject matter keeps expanding. NIST’s Generative AI Profile (AI 600-1) recommends updating procurement and vendor-assessment due diligence for generative AI to include privacy, security, intellectual property, and related risks. Growing companies often face that breadth of questioning before they can staff a full GRC team.

Enterprise trust centers and compliance suites exist for related work, but they are often built for broader programs. When the immediate need is finishing the spreadsheet in front of you, a lighter review workflow can be a better fit than a long platform implementation.

What works instead

Teams that keep deals moving without building a compliance org overnight tend to share a few habits:

  • One approved answer library: current responses tied to evidence, not a pile of old exports in Drive.
  • Work in the buyer's file: fill the original spreadsheet instead of rebuilding it elsewhere.
  • Review risk before send: flag commitments that product or engineering cannot stand behind.
  • Reuse completed work: each finished review feeds the next one, rather than starting from scratch.

What Sorila is being designed to do

Sorila is under active development. It is designed to help growing B2B teams get the questionnaire done, attach evidence, and get a human sign-off before answers go out. See what Sorila's security questionnaire software handles at launch.

Join the design partner program if you'd like early access.

Sources