Cybersecurity · Discovery Call
Discovery Call Questions for Cybersecurity: A 25-Minute Playbook for Diagnosing a SOC Before You Pitch It
Your prospect is a Director of Security Operations who has four Tier-1 analysts, roughly 12,000 alerts a day coming out of the SIEM, and a Friday afternoon ritual where the queue gets bulk-closed to get back to zero. He took your call because your first touch mentioned alert-to-incident ratio instead of "AI-powered zero trust." He has twenty-five minutes and a standup at the top of the hour. He is also, professionally, a person who evaluates strangers for risk. Every question you ask lands as either "this person understands my environment" or "this person is doing recon."
That second read is why cybersecurity discovery goes wrong differently than other industries. Security buyers do not fill silence with feelings. They give you short, accurate, deliberately unhelpful answers — "it's a lot," "more than I'd like," "I'd have to check" — and they will not volunteer their false positive rate to someone who hasn't earned it. They will also test you: a stray "XDR" where "EDR" belongs, or a question about their SOAR that reveals you think SOAR runs before triage rather than after, and the rest of the call is polite.
So the job is not to extract numbers. It is to demonstrate, question by question, that you already know how the machine breaks — the three noisy rules that generate half the volume, the log source they chose not to onboard because the licence is priced per GB per day, the privileged access review finding that has reopened for three consecutive SOC 2 cycles — and let them correct your understanding. Correcting you is how a security person tells you the truth. Below is the time budget, the question set, and the exact language for the moments where these calls usually die.
The discovery call script
Say it in your own words. The structure is the part that matters.
- 1
0:00–2:00 — The Frame (do not re-pitch)
"Thanks for clearing the time. Quick frame so I don't waste it: when we traded emails you said your Tier-1 queue is running around twelve thousand a day across four analysts and that most of it is the same handful of rules. That's the only thing I want to dig into today. I'm going to ask more than I tell for the first fifteen minutes. I'm not going to show you a screen — I'd honestly rather tell you this isn't a fit than burn a demo slot on you and a technical person who then finds out it's not. Still good for twenty-five? And before I start — is there anything you want to make sure we hit, so I don't run us out of clock?" [Write their answer down. If they say "I mostly want to know how you handle our data," you are on a security review call, not a discovery call, and you should say so out loud and re-plan.]
- 2
2:00–6:00 — Layer 1 to Layer 2: open the thread, then get to mechanism
Pick ONE opener. Not five. • "Walk me through what a Monday morning looks like in the queue — start to finish, from what's sitting there when the day shift logs in." • "When you said the queue gets zeroed out on Fridays — what does that actually look like on a bad week?" • "What made this something you're looking at now rather than last year?" Then three follow-ups on the same thread before you change subject: • "Which rules are generating the volume? Is it a handful of detections or is it spread?" • "Who wrote those? Is detection engineering a named person or is it whoever has time?" • "When Tier-1 bulk-closes, what's the actual mechanic — select-all in the console, a SOAR playbook, a saved query?" • "Where does the MDR sit in that? Are they looking at the same queue or a filtered view?" • "Walk me through the last one that got missed. What happened?" That last question is the whole call. If they answer it, you're at layer two.
- 3
6:00–11:00 — Layer 3: cost, with the second beat
Never ask "is that a problem?" Ask for numbers and then ask how they know. • "Roughly what's your alert-to-incident ratio right now — alerts in versus things that got a ticket and a real investigation?" • "What percentage of alerts get auto-closed or bulk-closed in a given week? Ballpark is fine." • "What's MTTD looking like on the ones you did catch — and is that number measured or estimated?" • "How do you know?" — ask this after any number. If they can't source it, that's a finding: the problem is invisible above them and you'll need to help build the case. • "How many alerts per analyst per shift is that working out to?" • "What's dwell time on the last confirmed incident — from first foothold to when someone read the alert?" Then the adjacent cost thread: • "What's your SIEM priced on — GB per day or EPS? Where are you against the cap?" • "Are there log sources you've decided not to onboard because of ingest cost? Which ones?" That second question surfaces a known visibility gap they are already uncomfortable about. Let the answer sit.
- 4
11:00–16:00 — Layer 4: the stake (whose name is on it)
• "Who's feeling that most — is it your Tier-1 leads, or is it landing on you?" • "Whose number is MTTD, formally? Yours, or does it roll up to the CISO's board pack?" • "What did you commit to — and to whom — the last time this came up?" • "When the board asks 'are we protected against ransomware,' what goes on the slide today?" • "Is there anything in the cyber insurance renewal or the next SOC 2 cycle that touches this — EDR coverage percentage, log retention, anything you have to attest to?" • "How long have the open reqs been open?" • "If this is exactly the same in twelve months, what's the conversation you're having with your CISO?" Then count to three. Do not talk. The sentence after the pause — "honestly, I lost my best detection engineer to a vendor in March and I'm not backfilling him" — is the one you put in the CRM verbatim.
- 5
Minute 6 trap — "So what do you guys actually do?"
30 seconds, tied to what they just said, then hand the ball back: "Short version — we sit at the ingest point, before your SOAR, and collapse duplicates and known-benign into one thing your Tier-1 reads. Agentless, read-only API against the SIEM you already own. That's it. But I'd be guessing at whether it matters until I know one more thing: when your analysts bulk-close on Friday, is that a queue-depth decision or a shift-handover decision?" If they push a second time, give a clean 60 seconds — no logos, no funding — then: "Can I go back to the three rules you mentioned? That's the part I'm not clear on." Almost everyone lets you.
- 6
16:00–20:00 — Qualify the path (not BANT recited)
• "If you decided this was worth doing, what actually happens next in your shop? Who gets pulled in — does this go through your CISO, or is detection tooling yours to call?" • "Who owns third-party risk here? Is TPRM sitting under GRC or under you?" • "Have you tried to fix the alert volume before? What happened?" — the graveyard of the last tuning project or the MDR that didn't work is your real competition. • "What's forcing timing — SIEM renewal, the audit cycle, insurance renewal, headcount?" • "Is this a line item that already exists — detection tooling, SOC platform — or would it need to get created?" • "What happens if you just keep running it the current way through next year?"
- 7
20:00–23:00 — Targeted relevance, 90 seconds, only what they raised
"Two things from what you described, then I'll stop. One: the three rules doing your volume — that's the case we're built for. We deduplicate and cluster at ingest so your analyst reads one item with eighteen instances attached instead of eighteen items. Nothing is deleted. Everything stays queryable and retained for whoever audits you. Two: you said you're not onboarding your SaaS audit logs because of GB-per-day cost. That's the second-order thing — if alert volume drops, the renewal conversation with your SIEM vendor changes, and that's usually a different budget line than mine. What I'm not going to claim is that we'd catch something your MDR wouldn't. I don't know that yet, and neither do you."
- 8
Playback — in their words, before you close
"Let me make sure I've got it, and tell me what I got wrong. Twelve thousand a day, four analysts, and three rules — the DNS one, the impossible-travel one, and the endpoint quarantine one — are doing most of it. Tier-1 bulk-closes Friday afternoon to hand over a clean queue. The one that hurt was the credential-stuffing hit in April that sat unread for nine days, and dwell time on that is now in your quarterly to the CISO. You've got two reqs open seven months and you're not backfilling the detection engineer who left. The forcing function is the SIEM renewal in Q3. Did I miss anything, or get anything wrong?"
- 9
23:00–25:00 — Close a dated, named, specific next step
"Based on that, the useful next thing isn't a demo. It's forty-five minutes with you and whoever owns your detection content — you mentioned Priya — where we take a thirty-day export of alert metadata, no payloads, no PII, and replay it. You tell us three incidents from that window where you already know the outcome. We show you what would have surfaced first and what would have been collapsed. If we miss one you caught, that's a real answer and you've lost an afternoon. I've got Tuesday at 2 or Thursday at 10. Which one?" Then confirm out loud: who's on it (name them), what you'll bring (SOC 2 Type II, data flow diagram, subprocessor list, sent today), what they'll bring (the metadata export scope, the three incident IDs). Send the invite before you hang up.
How the call actually sounds
Prospect on the left, the rep on the right.
Rep
Thanks for the time. Quick frame — you said in email that your Tier-1 queue is running about twelve thousand a day across four analysts and it's mostly the same handful of rules. That's all I want to dig into. I'll ask more than I tell for the first fifteen minutes, and I'd rather tell you this isn't a fit than book you a demo. Still good for twenty-five?
Buyer
Twenty-two now, I've got a standup. And before you go further — I'm not going to give you numbers on our detection coverage or our incident history on a first call. That's not personal, that's just where I sit.
Rep
Completely fair, and I'd have the same rule. Nothing I ask needs a real number — orders of magnitude are fine, and if a question's out of bounds just say next. Can you walk me through what Monday morning looks like? What's sitting in the queue when day shift logs in?
Buyer
A lot. It's a queue. They work it. Look, I'll be straight with you — I've had four of these calls this quarter and every one of them was an AI triage layer that was going to fix my false positive rate. What's actually different here?
Rep
I'm not going to claim a category, so let me just ask the one question that decides it. Last week, roughly — alerts in the queue versus things that became an actual incident with a ticket. Is that ratio worse than about a hundred to one?
Buyer
Worse. Considerably worse. That's not a secret, that's true of every SOC our size.
Rep
It is. So the interesting part isn't the ratio, it's what your team does with it. When Tier-1 bulk-closes to get the queue back to zero — what's the actual mechanic? Select-all in the console, a SOAR playbook, a saved search?
Buyer
It's a saved filter and a bulk disposition. And to be clear, they're not closing blind. There's a documented rationale per rule. That's in our runbooks and it's been through audit.
Rep
Understood — so it's a governed decision, not a shortcut. Which rules are carrying the volume? Is it a handful of detections or is it spread across the content library?
Buyer
Three, mostly. Impossible travel, a DNS beaconing rule that was never tuned properly after we onboarded the new cloud accounts, and an EDR quarantine notification that fires on the same six service accounts every night.
Rep
The DNS one that was never tuned after the cloud onboarding — who'd own retuning that today?
Buyer
That's the problem. My detection engineer left in March. Went to a vendor for a thirty percent bump. The req's been open since. So retuning content is currently me, on evenings, or it's nobody.
Rep
So the backlog isn't triage capacity, it's content ownership. What does that mean for anything you've committed upward — does MTTD roll into your CISO's board pack, or is it yours?
Buyer
It's in the quarterly. And this year there's a second column, because insurance renewal wants EDR coverage as a percentage of known assets and I can't produce that number without a two-week reconciliation across three overlapping endpoint tools. So I'm going to be standing there with a number I can't fully defend.
Rep
(three seconds of silence)
Buyer
...And honestly the thing I think about is April. We had a credential-stuffing hit that sat in a bulk-closed batch for nine days. We caught it, we contained it, nobody's in trouble. But the dwell time number is in that same quarterly, and the auditors will see it in the SOC 2 cycle. Third year we've had a finding in that neighbourhood.
Rep
That's the thing that matters, and I appreciate you saying it. Last two questions on process, then I'll tell you what I think and let you go. If you decided this was worth testing — not buying, testing — what happens next in your shop? Does it go to your CISO, or is detection tooling yours to call?
Buyer
I can call a technical evaluation. I cannot call a purchase, and anything that touches our data goes through GRC with a full TPRM questionnaire, which is six weeks minimum. And I'm going to tell you now, we're not deploying an agent to five thousand endpoints for a pilot. That risk review alone is a quarter.
Rep
There's no agent — read-only API against the SIEM you already ingest into, so that's a data-handling review, not an endpoint deployment. Different form, shorter one. I'll send the SOC 2 Type II, the data flow diagram and the subprocessor list today so GRC can start their six weeks in parallel. Here's what I'd propose while that runs: forty-five minutes with you and whoever's covering detection content now, we take a thirty-day export of alert metadata — no payloads, no PII — and you give me three incidents from that window where you already know the outcome. Including April, if you want. We show you what would have surfaced first and what would have collapsed. If we miss one you caught, you've lost an afternoon and I'll say so. Tuesday at two, or Thursday at ten?
Buyer
Thursday. Bring the data flow diagram to that call too, not just to GRC — I want to read it myself before my team touches anything.
Objections you will hear
What they say, and what you say back.
| Objection | How to answer it |
|---|---|
| “Every vendor says AI-powered zero trust. You've got ten seconds to be different.” | Fair. I'm not going to claim a category. One question: how many alerts hit your queue last week, and how many became incidents? If that ratio is worse than about a hundred to one, you have a triage problem, not a detection problem, and that's the only thing I do. If your ratio is fine, I'll hang up. |
| “Adding your agent to 5,000 endpoints? The risk review alone takes a quarter.” | Agreed, and I'd fail that review too. There's no agent — we read from the SIEM you already ingest into, via API, read-only. No kernel driver, no change window, no golden image rebuild, nothing fighting your EDR on the same host. The security review is a data-handling review, not an endpoint deployment, which is usually a different and much shorter form. |
| “We already have a SIEM, a SOAR, and an MDR. Where does this even sit?” | In front of all three. Your SOAR runs playbooks on alerts after somebody decides they matter; your MDR is billing you on volume it has to look at. We sit at the ingest point and collapse duplicates and known-benign into one thing your analyst reads. Fastest way to know if that's real is a two-week replay against last month's alerts — no production change, nothing in the path. |
| “Send me a SOC 2 Type II, a pen test report, and fill out our third-party risk questionnaire, then we'll talk.” | Sending all three today, plus the data flow diagram and subprocessor list so your GRC team doesn't have to chase us for them. While that's in the queue — can we do thirty minutes with whoever owns your detection content? The security review takes six weeks either way. I'd rather it run in parallel with the people who'd actually use this than sequentially after them. |
| “We're not buying anything until Q3. Budget's committed.” | Understood — I'm not asking for budget. What I want is to be the thing you already validated when Q3 arrives, instead of starting a cold POC in July. Quick question though: what's the ingest number your SIEM renewal is priced on, GB per day? If alert volume drops the way it does elsewhere, that renewal conversation changes, and that's usually a different budget line than mine. |
| “Prove it in our environment. Everyone's demo looks great on their own data.” | That's the only proof I'd trust either. Give us a thirty-day export of alert metadata — no payloads, no PII — and we'll replay it against incidents you already know the outcome of. We'll show you what your analysts would have skipped and what would have surfaced first. If we miss one you caught, that's a real answer and you've lost an afternoon. |
| “If we cut alerts and miss something, that's my job. Nobody gets fired for reading too many alerts.” | They get fired for dwell time, and reading twelve thousand alerts a day is how dwell time happens. Nothing gets deleted — everything stays queryable and retained for the auditor. We change what's presented first, not what exists. And you set the suppression rules; we don't auto-close anything you haven't approved in writing. |
| “I'm not sharing our alert volumes or incident history with a vendor on a first call.” | Same rule I'd have. Nothing I'm asking needs a real number — orders of magnitude work, and if a question's out of bounds just say next and I'll move. If it helps, I can go first: here's what a four-analyst SOC at your ingest volume usually looks like, and you tell me where I'm wrong. Correcting me is more useful to both of us than me guessing. |
Questions reps ask about this call
- What are the best discovery call questions for cybersecurity buyers who won't share numbers?
Ask for mechanism instead of magnitude. "Which three rules generate most of your volume?" and "when Tier-1 bulk-closes, what's the actual mechanic — saved filter, SOAR playbook, select-all?" get answered when "what's your false positive rate?" doesn't. Security buyers protect metrics but talk freely about process, because process isn't sensitive. You can also go first: state what a SOC their size typically looks like and invite them to correct you. Correction is how security people tell you the truth.
- Which metrics should I anchor a cybersecurity discovery call on?
Pick two, not eight. Alert-to-incident ratio and dwell time do the most work on a SOC Manager or Director of Security Operations call, because one describes the daily pain and the other describes what gets them in front of the audit committee. For a CISO, swap in EDR and log-source coverage as a percentage of known assets — that's the number cyber insurance renewal asks for. For a call driven by SIEM renewal, anchor on ingest volume in GB per day against the licence cap. Alerts per analyst per shift and unfilled req age are your bridge to the headcount conversation.
- How do I handle 'so what do you actually do?' at minute six without pitching?
Give thirty seconds tied to something they already said, then hand the ball back with a question. "Short version: we sit at the ingest point, before your SOAR, and collapse duplicates and known-benign into one item your Tier-1 reads. Agentless, read-only API. But I'd be guessing at whether that matters until I know — when your team bulk-closes on Friday, is that a queue-depth decision or a shift-handover decision?" If they push twice, give a clean sixty seconds with no logos and no funding history, then ask to go back to their layer-two detail.
- Who should be on a cybersecurity discovery call, and who do I need for the next one?
First call is usually a Director of Security Operations, SOC Manager, or an IT Director who owns security with no dedicated CISO. They can call a technical evaluation but rarely a purchase. The second call needs the Head of Detection Engineering or a Security Engineering Manager — whoever owns the detection content — because they will decide whether your claims are credible. Director of GRC & Compliance shows up for the TPRM questionnaire and SOC 2 Type II review, which runs in parallel, not after. The VP of Security Operations or CISO enters when there's a defensible number and a renewal or audit date attached to it.
- What's a good next step to close a cybersecurity discovery call on?
A dated replay, not a demo. "Forty-five minutes with you and whoever owns detection content. We take a thirty-day export of alert metadata — no payloads, no PII — you give us three incidents from that window where you already know the outcome, and we show you what would have surfaced first and what would have collapsed. If we miss one you caught, that's a real answer." Offer two specific times, name the attendees out loud, and commit to sending the SOC 2 Type II, data flow diagram and subprocessor list the same day so the six-week security review starts immediately rather than after the next meeting.
- How do I practise these calls before running them live?
Run them against a roleplay buyer configured as a difficult Director of Security Operations: refuses to give metrics on call one, has taken four AI-triage vendor calls this quarter, tests you on whether SOAR runs before or after triage, and blocks on agent deployment and TPRM. Drill the three specific moments that break real calls — the minute-six "what do you do," the three-second silence after they mention a missed incident, and the close at minute twenty-three. On DrillCall you can replay the same buyer until the layered follow-ups come out without a script in front of you.