How do I handle a security review that looks like it'll kill the deal?

Why Most Security Reviews Stall — and Why That Is Good News

Before you can fix the problem you have to diagnose it correctly, and the common diagnosis — "our security isn't good enough" — is usually wrong. IT's mandate is risk reduction, not deal velocity, and the friction you feel is that mandate doing its job. But the specific reasons a review dies are almost always operational, not architectural.

Reviews stall for a short, predictable list of reasons. The vendor goes silent for ten or more business days and the review simply loses momentum in the buyer's queue. The vendor's answers contradict each other across the questionnaire — the sub-processor list names a vendor the data-flow diagram doesn't show, or the breach-notification window says 72 hours in one place and "reasonable time" in another — and the reviewer loses trust in every other answer. Or the vendor admits, badly, that a table-stakes control is missing: no MFA on admin accounts, no immutable audit logs, no least-privilege IAM, no documented vulnerability-management SLA. That last one is the real kill signal. It is rarely the single gap that ends the deal; it is what the gap implies about operational maturity. A CISO who has reviewed dozens of vendors reasons that if you cannot answer the easy questions cleanly, the hard ones will be worse.

The good news hidden in this is that the failure modes are almost entirely within your control. You cannot conjure a FedRAMP authorization overnight, but you can absolutely answer within 48 hours, keep your artifacts internally consistent, and volunteer your gaps before they are found. Industry frameworks reinforce this framing. The NIST Cybersecurity Framework 2.0 organizes the decision around six functions — Govern, Identify, Protect, Detect, Respond, and Recover — and reviewers who can map your controls to those functions in plain language move quickly. When you present your program in the reviewer's own vocabulary, you convert an adversarial audit into a collaborative mapping exercise.

There is also a real, rising external pressure on the person across the table that you should account for rather than resent. The SEC's 2023 cybersecurity disclosure rule requires public companies to disclose material cybersecurity incidents, which raises the stakes on every vendor relationship a public buyer takes on. Cyber-insurance carriers increasingly condition coverage on documented vendor due diligence. Verizon's annual Data Breach Investigations Report has repeatedly highlighted the role of third parties and the supply chain in breaches. Put together, these mean the reviewer often carries a personal and organizational incentive to say "no" when in doubt. Your entire strategy should be built around one goal: removing the doubt as early as possible.

Front-Load Everything: The Day-One Security Packet

The most effective intervention happens before the formal review even opens. The instant security appears on the critical path, send a structured packet to the buyer's security or IT contact. This compresses the discovery phase — the part where the buyer's team figures out what to ask — from three or four weeks down to a handful of business days, because you have answered the discovery questions before they were formulated.

Assemble the packet from primary artifacts, not marketing collateral. A practical inventory:

• SOC 2 Type II report. Type II (which tests operating effectiveness over a 6–12 month window) carries far more weight than Type I (a point-in-time design opinion). If you only have Type I, say so and give the date your Type II observation window closes.
• Penetration test executive summary. Share the summary — scope, methodology, finding counts by severity, and remediation status — not the raw report. Raw reports contain internal context that is easily misread, and no mature vendor hands them out freely. Offer a walkthrough call if the buyer wants depth.
• A pre-completed standardized questionnaire. Fill out the Cloud Security Alliance's CAIQ (the questionnaire that maps to the Cloud Controls Matrix) or the Shared Assessments SIG/SIG Lite. Handing over a completed industry-standard questionnaire pre-empts the buyer's custom 300-question spreadsheet, which is what adds thirty-plus days to a cycle.
• Data-flow and architecture diagram. One page each. Show where customer data lives, how it moves, where it crosses trust boundaries, and where it is encrypted.
• Encryption and key-management specifics. State it concretely: encryption at rest and in transit using modern standards (for example AES-256 at rest and TLS 1.2 or higher in transit), where keys live, and whether customer-managed keys / bring-your-own-key are supported through a cloud KMS.
• Sub-processor list with locations. Every fourth-party you rely on, what data they touch, and where they operate. This is often the first thing a GDPR-conscious reviewer checks.
• Incident response summary. Your breach-notification commitment (GDPR Article 33 sets a 72-hour regulator-notification standard that many buyers expect vendors to mirror), plus recovery objectives (RTO/RPO) in plain numbers.
• Compliance mappings and certifications. ISO/IEC 27001 certificate, any HIPAA BAA template, PCI attestation if relevant, and a note on which frameworks you map to (NIST CSF, CIS Benchmarks).

Host these behind a trust portal so access is logged and versioned, and use a short, confident opener when you send it. Something like: *"Hi [name] — here's the security packet your team will eventually ask for: SOC 2 Type II, our latest pen-test executive summary, a completed CAIQ, our sub-processor list, and a BAA template. It's all on our trust portal. Happy to put our head of security on a 30-minute call to front-load any deep questions."* That message does three jobs at once — it demonstrates competence, it sets the scope of the review before IT can expand it, and it signals that you expect to pass.

Connect the Engineers: Peer-to-Peer Trust Beats Paperwork

A recurring reason reviews die is that they are run entirely through the account executive, who cannot defend architecture decisions when a security engineer starts probing. The fix is structural: get your security engineer or CISO into a direct, thirty-minute conversation with theirs.

Peer-to-peer validation is the highest-trust signal in the process. A security engineer can look at your threat model, ask two pointed follow-ups, and form a judgment about whether you have a real security program in about half an hour — something a fifty-page RFI cannot convey. Prepare your engineer to bring real artifacts to that call: a one-page architecture diagram, the data-flow diagram, and a threat-model summary in a recognized methodology such as STRIDE or PASTA. Never bring slideware. The reviewer is not evaluating features; they are reading your artifacts to decide whether your program is genuine.

Coach your engineer on tone. The instantly disqualifying answer is the marketing-toned reassurance — "we take security very seriously," "security is in our DNA." Every experienced reviewer reads that phrase as a red flag, because it is what vendors say when they have nothing concrete. The credible answer is specific and occasionally admits limits: "We enforce SAML SSO and SCIM deprovisioning; we do not yet support customer-managed keys, but we offer per-tenant encryption with scoped key isolation, and CMK is on the roadmap for next quarter." Honesty about a gap, paired with a compensating control, builds more trust than a flawless-sounding non-answer.

This is also where you set response discipline. Assign one dedicated security contact on your side and commit to a 24–48 hour turnaround on every question. Nothing kills momentum like a question sitting unanswered while the buyer's other priorities crowd it out. A visible SLA — and hitting it — is itself evidence of an organized program.

Triage Ruthlessly: Solve the One Real Blocker

A security questionnaire can run to hundreds of line items, but the Pareto principle applies hard here: one or two controls actually decide the deal, and the rest are box-checks. Your job in the first review call is to identify which one or two.

The genuine blockers cluster around a small set: SAML/SSO enforcement, SCIM automated deprovisioning, audit-log export to the buyer's SIEM (Splunk, Microsoft Sentinel, Datadog), IP allowlisting, customer-managed or bring-your-own encryption keys, data-residency guarantees, and availability of a signed BAA for regulated data. When you find the blocker, treat it as the entire deal and everything else as noise. Demo the resolution — or a credible path to it — within 48 hours. If SSO enforcement is the blocker and you support it, show it live on the tenant. If audit-log export is the blocker, walk through the integration on a screen-share.

When your product genuinely cannot meet a control, say so on the first call and propose a compensating control immediately. If you cannot offer full BYOK, offer per-tenant key isolation with scoped access. If you cannot offer dedicated single-tenant infrastructure, offer logically isolated tenancy with documented separation. A compensating control is a well-understood concept in security governance — auditors accept them constantly — and proposing one signals that you speak the reviewer's language.

Wrap the triage in a Risk Acceptance and Remediation Schedule — a living document that lists every gap you know about, assigns a severity (Critical / High / Medium / Low), and proposes a remediation window (pre-close vs. post-close). Share it proactively at the kickoff. This inverts the dynamic entirely: instead of the reviewer hunting for issues and you defending, you arrive having already done the homework and having drawn the boundary yourself. Buyers' CISOs value this because it gives them a paper trail for their own auditors and insurers. A defensible cadence looks like: Critical items resolved within 30 days pre-close, High within 90 days post-close, Medium within six months, Low tracked but not gating. Use honest ranges tied to your actual engineering capacity — a fabricated date discovered later does more damage than the original gap ever would.

Contract Mechanics That Keep the Deal Alive

Sometimes the review surfaces a real issue that cannot be fully closed before the target close date. The answer is not to walk away or to over-promise — it is to move the risk into the contract in a way that protects both sides.

Phased remediation with a security holdback or escrow. Tie a portion of the payment to the completion of agreed post-close fixes. This is the commercial analog of the remediation schedule: the buyer is protected because money is contingent on you delivering the Critical and High items on time, and you are protected because the deal closes now rather than waiting on a 90-day fix. Keep the holdback proportional to the residual risk — a small, defined percentage tied to specific, dated deliverables, not an open-ended lever.

A "no-go" / material-defect termination clause. For genuine deal-killers, propose a clause that lets either party walk away without penalty if the review reveals a *material defect* that cannot be remediated within a defined window (commonly 60 days). This is a safety valve, not a poison pill, and it does something counterintuitive: it makes the buyer *more* willing to proceed, because they have a documented exit ramp for their auditors. The critical work is defining "material defect" precisely so the clause is neither toothless nor a hair-trigger. A workable definition: any finding that would trigger a mandatory breach notification under applicable law (GDPR, CCPA/CPRA, state breach-notification statutes, or SEC materiality standards), or any vulnerability rated Critical on the CVSS scale (roughly 9.0 or above) that affects customer data. A missing patch on a non-customer-facing internal server is not material; plaintext credentials in a public repository is. Most M&A and commercial counsel keep templates for this — ask yours to draft one rather than inventing language.

Terms and valuation as a last resort. If the review genuinely reprices the risk — a real, uncovered exposure that changes the value of what is being bought — be prepared to adjust terms or valuation to reflect it. This is honest deal-making, not capitulation, and it is preferable to either walking or papering over a risk that will resurface. Reserve it for cases where the risk is real and quantifiable, not for negotiating theater.

Throughout, keep security embedded in the deal team rather than bolted on as a legal or AE afterthought. When security engineering is present from the first review call, the contract mechanics above are drafted from a position of understanding rather than fear.

The Bear Case: When the Kill Is Real

Proactive transparency recovers most reviews, but not all of them. Recognizing the genuinely unwinnable cases early saves you weeks of wasted cycles and preserves the relationship for a future, better-fit deal.

Accreditation you simply don't hold. Regulated buyers may require FedRAMP authorization, CMMC certification, HITRUST, PCI-DSS Level 1, or region-specific accreditations. No amount of front-loading substitutes for a missing authorization. If you lack it, name it on the first call and offer a real path: a roadmap with dates, resale through an already-authorized partner, or scoping the deal to non-regulated business units that don't trigger the requirement.

Sovereign-data requirements without regional infrastructure. Data-residency and sovereignty rules — driven by GDPR and the Schrems II ruling in the EU, and comparable regimes elsewhere — can be unsolvable without local infrastructure. Pretending otherwise destroys trust the moment it's discovered. Be explicit about what you can and cannot do (for example, offering pseudonymization plus Standard Contractual Clauses where full in-region residency isn't yet available), or pivot to a regional reseller who does have local infrastructure.

Procurement theater. Sometimes the review exists to justify a build-vs-buy decision that has already been made internally, or to slow-walk a deal the buyer has quietly deprioritized. The tell is telling: the questions grow vague and repetitive rather than specific, the questionnaire balloons past a couple hundred items with no forward progress, and no one will commit to a decision date. Counter by escalating to the economic buyer and asking for a written close-date dependency. If it's genuinely stalled, get out fast — don't burn engineering cycles answering theater.

Category-wide risk aversion after a public breach. When a prominent breach hits your category, buyers' CISOs can become categorically cautious about the whole sector for six to twelve months, regardless of your individual posture. You either wait out the cycle or pivot to a less-exposed division or buyer.

The CISO as budget hostage. Extending a security review is one of the cleanest ways for a buyer to stall a deal they want to defer for budget reasons. Again the tell is vague, repetitive questions. Escalate to the economic buyer with a clear close-date dependency; if the deal is truly deprioritized, disengage cleanly rather than chasing it.

The meta-lesson across all five: the trap is treating security as a legal or AE workflow to be managed with reassuring language. IT trusts IT. Embed security engineering early, answer with specifics, and be honest about limits — and reserve your energy for the reviews that are winnable rather than the ones that are theater.

A 14-Day Playbook

Concrete sequencing turns the principles above into action. This is a template you can compress or stretch to the deal's real timeline.

Days 1–2. Send the security packet and the trust-portal link the moment the review is flagged. Include the completed CAIQ/SIG Lite and the opener that offers a 30-minute architecture call. Assign your single dedicated security contact and communicate the 24–48 hour response SLA in writing.

Days 3–5. Run the peer-to-peer security engineering call. Bring the one-page architecture diagram, data-flow diagram, and STRIDE/PASTA threat-model summary. In that call, identify the one or two real blockers and separate them from the box-checks. Deliver the Risk Acceptance and Remediation Schedule at or right after this call.

Days 6–8. Demo the resolution of the primary blocker live, or present the compensating control if the product can't meet it directly. Answer every outstanding questionnaire item within the SLA. Keep answers internally consistent — cross-check the sub-processor list against the data-flow diagram before sending.

Days 9–11. Negotiate the contract mechanics: phased remediation schedule, security holdback tied to specific dated deliverables, and — only if a genuine material-defect risk exists — the no-go clause with a precise materiality definition. Loop in commercial counsel with the standard templates.

Days 12–14. Confirm reviewer approval with the documented paper trail (schedule, questionnaire, meeting notes). If a Critical item remains, tie it to a pre-close fix or the holdback. If the review is revealing itself as theater or an unwinnable accreditation gap, make the call to escalate or disengage rather than sliding into an open-ended cycle.

Two disciplines carry the whole playbook: speed (never go silent, always beat the SLA) and consistency (every artifact tells the same story). Those two habits alone recover the majority of reviews that would otherwise die of friction rather than of substance.

FAQ

What is the single most important thing I can do to prevent a security review from killing my deal?

Proactively share your primary security artifacts — SOC 2 Type II, ISO 27001 certificate, penetration test executive summary, and a completed standard questionnaire — before the buyer's team asks for them. Most reviews stall on information gaps and slow responses rather than on real security flaws, so removing the gap in week one eliminates the most common cause of death. Pair the artifacts with a fast, consistent response cadence and you have addressed the two failure modes that account for most stalled reviews.

How do I handle a buyer who demands access to my raw penetration test report?

Offer the executive summary — scope, methodology, finding counts by severity, and remediation status — rather than the raw report. Raw reports contain internal context that is easily misinterpreted and that no mature vendor circulates freely; declining to share it is a sign of maturity, not evasion, as long as you offer a substantive alternative. If the buyer pushes for depth, propose a read-only walkthrough session where your security engineer talks through the findings and remediation live. That satisfies the legitimate need to verify without handing over a document that will be misread.

What should I do if the buyer's CISO seems personally motivated to say "no"?

Recognize that the incentive is real: cyber-insurance conditions, SEC disclosure obligations for public buyers, and personal accountability all push a reviewer toward caution when in doubt. Rather than fighting it, remove the doubt with concrete evidence — certifications, a clear incident-response plan, and a direct call between your security lead and theirs. Peer-to-peer validation between engineers is the strongest trust signal available, because it lets the reviewer form a judgment about your actual program instead of guessing from a questionnaire.

How can I speed up a security review that's dragging on for weeks?

Assign one dedicated security contact, commit to a 24–48 hour response SLA, and pre-fill a standardized questionnaire like the CAIQ or SIG Lite so the buyer doesn't build a custom 300-item spreadsheet from scratch. Then identify the one or two controls that actually block the deal and drive those to resolution while treating the rest as box-checks. If the questions grow vague and repetitive rather than specific, that is often a sign the delay is procurement theater — escalate to the economic buyer with a written close-date dependency.

What if the review uncovers a real vulnerability in my product?

Be transparent immediately: acknowledge the finding, share a remediation plan with an honest timeline, and offer a compensating control or workaround for the interim. Buyers respect demonstrated action far more than a flawless-sounding non-answer, and most will proceed when they see a credible, dated path to a fix. Capture it formally in your Risk Acceptance and Remediation Schedule so the reviewer has a paper trail for their own auditors — and if the issue is genuinely material and can't close before the target date, move it into a phased-remediation contract term or a security holdback.

How do I handle a buyer who insists on a full on-site audit?

Propose a virtual audit with live screen-sharing and document review first, since it is faster and lower-cost for both sides and satisfies most legitimate verification needs. If the buyer still requires an on-site visit — which is more common in heavily regulated industries — schedule it within about two weeks and prepare a tight agenda so the day is productive. Delays in scheduling read as disorganization and can themselves stall the deal, so treat the logistics with the same responsiveness you apply to the questionnaire.

Sources

• National Institute of Standards and Technology — Cybersecurity Framework 2.0: https://www.nist.gov/cyberframework
• Cloud Security Alliance — Consensus Assessments Initiative Questionnaire (CAIQ) and Cloud Controls Matrix: https://cloudsecurityalliance.org/research/cloud-controls-matrix/
• AICPA — SOC 2 / System and Organization Controls suite of services: https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2
• U.S. Securities and Exchange Commission — Cybersecurity Risk Management, Strategy, Governance, and Incident Disclosure (final rule): https://www.sec.gov/newsroom/press-releases/2023-139
• Verizon — Data Breach Investigations Report (DBIR): https://www.verizon.com/business/resources/reports/dbir/
• OWASP — Application Security Verification Standard: https://owasp.org/www-project-application-security-verification-standard/
• Shared Assessments — Standardized Information Gathering (SIG) questionnaire: https://sharedassessments.org/sig/
• FedRAMP — Federal Risk and Authorization Management Program: https://www.fedramp.gov/

Related on PULSE

• [What's the right way to do a follow-up after a demo when the buyer says "we'll get back to you"?](/knowledge/q1138)
• [The CRO says they'll adopt our tool, but their team will use a competitor internally anyway. How do we prevent a multi-vendor install that ruins our ROI?](/knowledge/q332)
• [What's the right pricing-governance model for a founder-led company in a highly competitive vertical where rigid discount authority could kill deal velocity?](/knowledge/q9550)
• [How is the 2027 vendor consolidation wave forcing RevOps to kill data silos between CDP and CRM?](/knowledge/q16582)
• [How Do I Kill a Substitution-of-Premises Clause?](/knowledge/q13834)