How to Run a Technical Discovery Call for Security Deals

The discovery call is where deals are won or lost — and most SEs do not realize it. By the time you get to the demo, the technical evaluation, or the proof of concept, the trajectory of the deal has already been set by the quality of your discovery.

A strong discovery call does three things: it qualifies whether the deal is real, it maps the customer’s environment and pain to your solution, and it establishes you as a trusted technical advisor rather than a vendor. A weak discovery call — one where you ask surface-level questions and jump to solutioning too early — produces proposals that miss the mark, demos that do not resonate, and POCs that go nowhere.

This post gives you a structured framework for running technical discovery calls on cybersecurity deals. It includes the 5-phase call structure, a checklist of 25 questions organized by security domain, and techniques for qualifying technical fit in the first 30 minutes.

The 5-Phase Discovery Structure

Every discovery call should follow this arc. The phases build on each other — do not skip ahead.

Phase 1: Context (5 minutes)

Objective: Understand who is in the room, what their roles are, and what prompted this conversation.

This phase is about orientation. You need to know who you are talking to, what they care about, and why they agreed to this meeting.

What to say:

• “Before we dive in, can you help me understand your role and what you’re responsible for day to day?”
• “What prompted this conversation? Was there a specific event, a project, or a business initiative that’s driving this?”
• “Who else on your team would be involved in evaluating a solution like this?”

What you are really doing: Identifying whether you are talking to the economic buyer, the technical evaluator, the end user, or the champion. Each role requires a different conversation.

Phase 2: Current State (10 minutes)

Objective: Map the customer’s existing security architecture, tools, and team structure.

This is the phase where you build your mental model of their environment. Do not assume anything. Ask.

What to say:

• “Walk me through your current security stack — what tools are you running today for [relevant domain]?”
• “How is your security team structured? How many people, and who handles [detection/response/engineering]?”
• “What does your environment look like? On-prem, cloud, hybrid? How many endpoints, users, locations?”

What you are really doing: Identifying what they already have (potential integration points or rip-and-replace scenarios), how mature their program is, and how much operational burden they carry.

Phase 3: Pain (15 minutes)

Objective: Identify specific, measurable problems the customer is experiencing with their current approach.

This is the most important phase. Surface-level pain (“we need better visibility”) is not actionable. You need to dig to specific, quantifiable problems.

What to say:

• “What’s broken? What’s the thing that keeps coming up in your team meetings or in conversations with leadership?”
• “When was the last time you had a security incident or a close call? What happened, and what did it expose?”
• “If I talked to your SOC analysts, what would they tell me is the most frustrating part of their day?”

What you are really doing: Finding the business case. Pain is what justifies the purchase. No pain, no deal. The deeper and more specific the pain, the stronger the deal.

Phase 4: Impact (10 minutes)

Objective: Quantify the business impact of the pain. What does it cost them — in money, time, risk, or reputation?

What to say:

• “When that incident happened, what was the business impact? Downtime, data loss, customer notification?”
• “How much time does your team spend on [manual process they described]? What else could they be doing?”
• “What’s the risk if this problem doesn’t get solved in the next 6-12 months?”

What you are really doing: Building the ROI narrative. You need numbers — hours wasted, incidents missed, compliance penalties risked — that you can put in a proposal to justify the investment.

Phase 5: Vision (5 minutes)

Objective: Align on what success looks like and establish next steps.

What to say:

• “If we fast-forward 12 months and this problem is solved, what does your team’s day look like?”
• “What would a successful evaluation of a solution look like for you? What do you need to see?”
• “Based on what we’ve discussed, I think a tailored demo focusing on [specific areas] would be the best next step. Does that make sense?”

What you are really doing: Setting up the next meeting with a clear agenda driven by their stated needs, not your standard demo script.

The 25 Must-Ask Questions: Organized by Security Domain

Copy this list. Use it as a checklist during every discovery call. You will not ask all 25 in a single call — select the ones relevant to the deal. But having the full list ensures you never forget a critical question.

Environment and Architecture (Questions 1-5)

• 1. What does your environment look like today — on-prem data centers, public cloud (which providers?), hybrid, multi-cloud?
• 2. How many total endpoints are in your environment, and what is the breakdown between managed (corporate) and unmanaged (BYOD, contractor)?
• 3. What operating systems are in your environment, and what is the approximate distribution (Windows, macOS, Linux, mobile)?
• 4. How many total users, and how many of those are privileged accounts (domain admins, cloud admins, database admins)?
• 5. Do you have operational technology (OT) or industrial control systems (ICS) in your environment?

Network Security (Questions 6-10)

• 6. How is your network segmented today? Do you have micro-segmentation in place, or is it primarily VLAN-based?
• 7. What is your current remote access architecture — VPN, ZTNA, or both? How many remote users do you support?
• 8. What is your east-west traffic visibility like? Can you see lateral movement between segments?
• 9. Where are your network security enforcement points — perimeter firewall, internal firewalls, cloud-native security groups?
• 10. Are you inspecting encrypted traffic (TLS/SSL decryption) anywhere in your network?

Identity and Access (Questions 11-15)

• 11. What is your identity provider? Are you using Active Directory, Azure AD/Entra ID, Okta, or something else?
• 12. Is MFA deployed across all users, or only specific groups? What MFA methods are in use?
• 13. How do you manage privileged access — do you have a PAM solution deployed, and what does it cover?
• 14. How do you handle third-party and contractor access to your systems?
• 15. Have you had any credential-related incidents (compromised passwords, pass-the-hash, Kerberoasting)?

Cloud Security (Questions 16-19)

• 16. Who is responsible for cloud security — is it the security team, the DevOps team, or shared?
• 17. How do you manage cloud workload security — CSPM, CWPP, CNAPP, or native cloud tools?
• 18. What does your CI/CD pipeline look like, and where does security fit in the development process?
• 19. How do you handle secrets management across your cloud environments?

Endpoint and Detection (Questions 20-22)

• 20. What is your current endpoint security solution, and how satisfied are you with its detection and response capabilities?
• 21. What is your mean time to detect (MTTD) and mean time to respond (MTTR) for security incidents?
• 22. Do you have a SOC — internal, outsourced (MSSP/MDR), or hybrid?

Compliance and Risk (Questions 23-25)

• 23. What compliance frameworks are you subject to — PCI, HIPAA, SOC 2, NIST, ISO 27001, CMMC, other?
• 24. When is your next audit, and what are the gaps you are most concerned about?
• 25. Has the board or executive leadership set specific security or compliance mandates with deadlines?

Red Flags vs. Green Flags: Is This Deal Real?

During discovery, you are simultaneously qualifying the deal. Here is what to look for.

The two-red-flag rule: If you identify two or more red flags during discovery, flag it to your AE immediately. The deal needs requalification before you invest more SE time.

Taking Notes That Translate to a Technical Proposal

Your discovery notes are the raw material for your technical proposal. If your notes are disorganized, your proposal will be too. Use this structure:

Discovery Summary Template

CUSTOMER: [Company Name]
DATE: [Call Date]
ATTENDEES: [Names, Titles]
SE: [Your Name]
AE: [AE Name]

ENVIRONMENT:
- Users: [count]
- Endpoints: [count, OS breakdown]
- Cloud: [providers, workload count]
- Locations: [count, geographic spread]
- OT/ICS: [yes/no, details]

CURRENT SECURITY STACK:
- Endpoint: [product, satisfaction level]
- Network: [product, satisfaction level]
- Identity: [provider, MFA status]
- SIEM/XDR: [product, satisfaction level]
- Cloud Security: [product, satisfaction level]

PAIN POINTS (ranked by severity):
1. [Specific pain point with quantified impact]
2. [Specific pain point with quantified impact]
3. [Specific pain point with quantified impact]

COMPLIANCE REQUIREMENTS:
- Frameworks: [list]
- Next audit date: [date]
- Known gaps: [list]

DECISION PROCESS:
- Technical decision-maker: [name, title]
- Economic buyer: [name, title]
- Timeline: [evaluation and decision dates]
- Budget: [allocated, amount if known]
- Competition: [other vendors in evaluation]

NEXT STEPS:
- [Action item with date]
- [Action item with date]

PROPOSED SOLUTION FOCUS:
- [How your product maps to their pain points]
- [Key use cases to demonstrate in demo]
- [Integration points with existing stack]

Fill this out within 15 minutes of ending the discovery call. Send it to your AE for alignment. Use it as the foundation for your demo agenda and technical proposal.

Qualifying Technical Fit in the First 30 Minutes

You do not need to wait until the end of the call to know whether your product is a fit. By minute 30, you should have answers to these five qualification questions:

1. Environment compatibility: Does the customer’s environment (OS, cloud provider, architecture) match your product’s supported platforms?

2. Integration requirements: Can your product integrate with their existing tools, or does it require a rip-and-replace they are not prepared for?

3. Scale match: Is their environment within your product’s supported scale (endpoints, users, data volume)?

4. Use case alignment: Do their primary pain points map to your product’s strengths, or are they asking for capabilities that are your product’s weaknesses?

5. Operational readiness: Does the customer have the team and processes to operationalize your product, or will they need managed services?

If the answer to any of these is a clear no, surface it early. “Based on what you’ve described, I want to be transparent — our platform handles X and Y really well, but Z is a gap. Let me think about whether we can address that through integration or if a different approach would be better.” Honesty about fit builds trust and saves everyone time.

The Post-Discovery Huddle

Within 24 hours of the discovery call, hold a 15-minute huddle with your AE. Cover:

1. Deal qualification: Is the deal real based on what we learned? What are the green flags and red flags?
2. Technical fit: Can we solve their problem? Where are the gaps?
3. Demo strategy: What should we show them? What should we NOT show them (features that don’t map to their needs)?
4. Proposal strategy: What is the recommended solution scope? What integrations need to be highlighted?
5. Competitive positioning: Who else are they evaluating, and what is our differentiation story?

This huddle is where SE and AE align on deal strategy. Without it, the SE builds a technically accurate proposal that misses the business context, and the AE sells a business case that does not map to the technical reality.

Key Takeaways

1. Discovery is a structured process, not a conversation. Follow the five phases. Do not skip from context to solutioning.

2. Pain is the product. If you leave discovery without quantified, specific pain points, you do not have what you need to build a compelling proposal.

3. Qualify early and honestly. The two-red-flag rule saves SE time and focuses effort on deals that will close.

4. Your notes are your proposal foundation. Use the template. Fill it out immediately after the call.

5. Never demo during discovery. Discovery is about listening. Demos are about showing. Mixing them produces mediocre results for both.

The best SEs in the industry are not the ones who give the best demos. They are the ones who run the best discovery calls — because great discovery makes great demos inevitable.

Related Posts in This Series

• Handling the 5 Most Common Security Objections — What to do when discovery surfaces objections you need to overcome
• MITRE ATT&CK Framework Explained for Solutions Engineers — Use ATT&CK to frame threat-informed discovery questions
• Translate a Pen Test Report Into a Sales Opportunity — Turn a pen test finding into a discovery-driven conversation
• How to Position SASE to a CISO — Tailor your discovery approach when the buyer has consolidation fatigue
• The AM’s Guide to Cybersecurity Terminology — Help your AM partner prepare for discovery with the right vocabulary