GM!
The buyer's security team sends a questionnaire. The AE marks most answers “Yes” from a previous deal, asks engineering about two difficult questions, and tells the champion approval should be straightforward.
Then the buyer asks for the actual evidence behind an encryption claim. The document describes a different product tier. Legal now wants an exception, and the close date still assumes security has cleared.
The operating question is: Which claims can this buyer verify for the product and scope they are buying today?
Security review is not a box the seller checks. It is a buyer decision path with its own evidence standard. If a claim outruns its proof, the forecast absorbs the gap later.
Start with the buyer's actual request
Ask for the questionnaire, required artifacts, deadline, reviewer, and the environment in scope. A request for a SOC 2 report is different from a question about how customer data moves through a specific integration. Do not answer both with the same generic security deck.
Clarify whether the buyer needs a document for its records, a control mapped to its policy, or a risk acceptance decision. Those outcomes require different work and different owners.
Log the request as a live review only when a buyer-side reviewer or process owner is identifiable. A champion's guess that “security will be fine” is not a review status.
Build a claim-and-proof record
For each material security assertion, keep five fields next to the opportunity:
Buyer requirement. Quote the control or question, including the system, data type, and use case in scope. Do not reduce “regional storage for customer records” to “data residency.”
Proposed answer. State exactly what the product does now, not what a roadmap item or a different tier might do.
Evidence. Link the current approved artifact: report, policy excerpt, architecture note, contract clause, or a written answer from the control owner. Note its scope and date.
Owner and status. Name the security, product, legal, or implementation owner who can approve the response. Use confirmed, needs clarification, exception requested, or cannot meet—not “in progress” for every unanswered item.
Buyer disposition and date. Record whether the reviewer accepted the answer, requested more proof, or escalated an exception. Include the next buyer review date if confirmed.
This is a claim-and-proof record. It is not a second security questionnaire. It is the short operating layer that keeps sales answers tied to approved evidence and buyer decisions.
A completed seller answer is not a completed buyer review.
Test the scope before reusing an answer
Illustrative scenario: a SaaS vendor has an approved answer saying customer data is encrypted at rest. The buyer plans to connect a third-party analytics export and asks how exported records are protected and retained.
The old answer may be true for data inside the core platform. It does not necessarily describe the export, the third party's controls, or the customer's retention setting. The AE should not copy the old “Yes” into the new answer and call the item closed.
Ask the control owner to define the boundary: where does the vendor's responsibility end, what can the buyer configure, and which part is outside the approved evidence? Then give the buyer a scoped answer and ask whether it satisfies the requirement.
If it does not, the next step is an explicit exception or change in solution design—not another reassuring email.
Put exceptions in the forecast conversation
Some buyers will accept a gap with a compensating control or written risk acceptance. Others cannot. Sales should not decide which case applies on the buyer's behalf.
For each exception, record the requirement, the gap, the proposed mitigation, the buyer's decision owner, and the date that decision is expected. Separate a vendor action (“send architecture diagram”) from a buyer action (“security lead reviews and approves the exception”).
A close date that depends on buyer risk acceptance should be conditional until that owner and decision path are confirmed. This is a forecast judgment, not an instruction to push every security-heavy deal out of the quarter.
An exception without a decision owner is an unresolved requirement, not a workaround.
Set a response rhythm, not a scramble
Keep approved evidence in a controlled library with owner, product scope, and review date. When the buyer asks a new question, route it to the right control owner once; do not solicit three inconsistent Slack answers and pick the most optimistic one.
Have the AE send a concise response register to the buyer's reviewer: answered with artifact, awaiting vendor clarification, awaiting buyer decision. Confirm which items could block approval and when the buyer expects to review them. If the reviewer will not engage directly, ask the champion to relay the questions and label the path unconfirmed.
Do not claim the review is cleared because all vendor documents were submitted. Clearance is a buyer disposition, not a submission receipt.
Weekly action
Choose one deal with an active security request. Pick its three material claims and write the buyer requirement, scoped answer, approved proof, internal owner/status, and buyer disposition on one page.
Ask the reviewer or process owner which item could block approval. Escalate any unsupported claim to the control owner before the AE sends another answer. If an exception is needed, put its buyer decision owner and date into the deal review.
Leave forecast confidence conditional until the buyer confirms the path.
— Pipeline Playbook