When an IT or security contact joins the call, accuracy matters more than speed. A confident wrong answer can end a deal or create a problem after signing. A clear "I will confirm that in writing" does neither.
This guide helps sellers prepare for technical reviews: what to gather beforehand, how to answer the common questions, how to handle ones you cannot answer and how to practise. It is about sales conversation skills. It is not legal or security advice, and what you may state about your own product must come from your company's approved documents. Names are fictional.
Know what you may say
Before any call with a security reviewer, collect from your own company:
- Approved documents. A security overview, data-handling summary, subprocessor list or certificate, if your company has them. Use only what is approved for customers.
- A named expert. Someone in engineering or security whom you can bring to the call or ask afterwards.
- A list of claims you must not make. For example, do not say "fully secure" or "compliant with everything". Use the exact wording from the approved documents.
- Honest gaps. If your company does not hold a certification the buyer asks about, you need to say so plainly.
If you are unsure whether you may share something, do not improvise. Ask first.
What reviewers usually ask
Security and IT questions vary, but they cluster around a few themes:
| Theme | Typical question | What a good answer includes |
|---|---|---|
| Data | "Where is our data stored, and who can see it?" | Location, who has access, link to the approved document |
| Access | "How do users sign in, and can we control roles?" | What the product supports today, not what is planned |
| Retention | "How long do you keep data and can we delete it?" | The documented period and the deletion process |
| Subprocessors | "Which third parties handle our data?" | The approved list, with a way to see updates |
| Incidents | "What happens if something goes wrong?" | The documented process and contact route |
| Documentation | "Can we see a certificate or report?" | What exists, what does not, and when it can be shared |
Do not answer from memory when the exact wording matters. Say "I want to give you the exact wording" and share the document.
A structure for answering
Use four short steps:
- Restate the question to be sure you understood: "You're asking whether our staff can see customer recordings, is that right?"
- Answer what you know, in plain words, and only that.
- Point to the document: "That's described in our data overview. I'll send it today."
- Check: "Does that answer it, or is there a related concern?"
Reviewer (Ms Adeyemi, Fabrikam Ltd): "Where is our data stored?"
Seller: "Let me check I'm answering the right thing: you mean the location of the servers that hold your data?"
Reviewer: "Yes."
Seller: "The location is stated in our data overview, and I'd rather give you the exact wording than paraphrase it. I'll send it today, and if you have a specific region requirement, tell me now so I can raise it with our team."
When you do not know
"I don't know" is a professional answer when followed by a plan.
"I don't know that detail, and I don't want to guess. I'll ask our security lead and send you a written answer by Thursday. Is there anything else you'd like me to include in that?"
Then do it. Write the question down, name the owner and send the answer by the date. A missed promise damages trust more than the original gap.
When the answer is "no"
If the product does not do something, say so directly and, where true, say what it does instead.
"We don't offer that today. What we do provide is [approved capability]. Whether that's enough for your requirement is your call, and I'd rather you know now."
Do not promise a future feature unless your company has formally committed to it and you are allowed to say so. A roadmap hint presented as a commitment can cause serious problems later.
Keeping the commercial thread
A technical review is part of a sale, not a separate event. Make sure the call ends with:
- A list of open questions, with owners and dates.
- The next step for the buying process: "Once you've reviewed the documents, shall we meet next Thursday to go through remaining points?"
- A summary email the same day, listing what you promised.
For wording, see recap and confirm on sales calls and how to ask for the next step.
Tone with technical reviewers
- Respect the role. The reviewer's job is to find problems; do not take questions personally.
- Do not hide gaps. Reviewers talk to each other, and a hidden gap tends to surface.
- Do not oversell. Avoid "best-in-class" and similar phrases. State what is true.
- Stay calm if the questions are hard. A steady pace shows you take them seriously.
Practise it
- List the six questions you fear most from an IT reviewer. Write the approved, accurate answer to each, or "I do not know; ask X".
- Answer them aloud, using the four-step structure. Time each one: under 30 seconds.
- Ask a colleague to play a sceptical reviewer and interrupt with follow-ups.
- Run the DIRI AI scenario technical security review of the solution by voice. Its goal is to gather relevant information without unnecessary pressure. Afterwards, check whether you made any statement you could not source.
FAQ
Should the salesperson answer security questions alone?
Answer what you know from approved material and bring in a specialist for the rest. A seller who tries to answer everything risks stating something inaccurate.
What if the buyer asks for a certificate we do not have?
Say so plainly, explain what you can provide instead, and let the reviewer decide. Do not imply that a certification is in progress unless your company confirms it.
How do I prepare quickly for a technical review?
Read the approved documents, list the likely questions and note who can answer the ones you cannot. Our five-minute sales call prep shows a fast checklist you can adapt.
Related: Multi-threading accounts by phone, MEDDIC discovery call questions, Sales call checklist.