Selling Into Cybersecurity: Alert Fatigue, MTTR and Why the SOC Lead Doesn't Believe Your Category Anymore

The pitch that gets you hung up on

Here is the call I hear most often when I listen to reps dialling security accounts.

"Hi, I'm calling from [vendor]. We help security teams reduce risk and improve their security posture."

That call is over before the prospect has finished swallowing their coffee. Not because the rep sounds bad. The rep usually sounds fine. It is over because "reduce risk" is not a problem anyone in a SOC is having today. Risk is the abstraction the board talks about on Friday. It is not what is on the analyst's screen at 2am, and it is not what is keeping the SOC lead awake.

Selling software to security teams goes wrong in a very specific way. The category has been so heavily marketed to that the buyer has developed antibodies. They have sat through the same demo from four vendors in a quarter. They have been told they need a single pane of glass by every one of them. They have watched a tool they bought last year get shelved because nobody had the headcount to tune it. So when you open with the category-level promise, you are not making a claim, you are triggering a pattern match: this is one of those calls.

The fix is not a better hook. The fix is knowing what their day is actually made of, and saying something that could only come from someone who knows.

What the queue looks like at 2am

If you have never sat next to a Tier 1 analyst, here is the shape of it.

There is a queue. Alerts land in it from the EDR, from the SIEM correlation rules, from the email gateway, from cloud posture tooling, from whatever DLP thing legal made them buy. The queue does not empty. It is not designed to empty. The analyst works the top of it, triages, and the ones they cannot resolve get escalated to Tier 2 or 3.

Most of what lands in that queue is noise. Not malicious noise — benign, boring, explainable noise. A finance user logged in from a hotel in another country because they are at a conference. A developer ran a script that looks like credential enumeration because that is literally what the script does. A scanner the infra team stood up two weeks ago and forgot to tell anyone about. Each one of those takes a few minutes to close out. Multiply by the volume and you have an entire shift spent proving nothing happened.

That is alert fatigue. It is not that analysts are tired. It is that the work has become mechanical, and the human cost of mechanical work in a job where the stakes are supposedly existential is that people stop caring. The dangerous outcome is not a missed alert because someone was busy. It is a missed alert because someone had closed eighty similar ones as false positives that week and closed the eighty-first on autopilot.

Now layer on staffing. Security analysts are hard to hire and easy to lose. Tier 1 is often the entry role, which means the SOC lead is running a function where the people doing the highest-volume work are the least experienced and the most likely to leave in eighteen months. Every departure is a re-hire, a re-train, and a period where the queue backs up further.

And the SOC lead has a board deck due. Or a cyber insurance renewal. Or an auditor asking for evidence of control coverage. Those things are real and they eat the week.

So when you call and say "we help reduce risk," you are talking about a category. They are living inside an operations problem with a staffing crisis stapled to it. Those are not the same conversation.

The two numbers that actually move the conversation

Security buyers talk about a lot of things. Most of it is not measurable and they know it. There are two numbers a SOC lead can usually produce on demand and that they are usually measured on, and if your pitch does not touch one of them, you are selling into the abstract.

Mean time to respond

MTTR is the clock from detection to containment. Some teams split it — mean time to detect, mean time to acknowledge, mean time to respond, mean time to recover. Whatever the flavour, it is the number the SOC lead reports upward, because it is the one that translates into language an executive understands: how long is a bad thing loose in our environment before we stop it.

MTTR is also the number that reveals structure. If it is bad, ask where the time goes. Sometimes detection is fine and containment is slow because the SOC does not have authority to isolate a host without approval from the app owner. Sometimes triage is slow because the analyst has to pivot across four consoles to assemble context. Sometimes the number is fine on paper and the SOC lead does not trust it, because the clock only starts when an alert fires and they suspect plenty is not firing.

Ask about MTTR and then ask which part of it is the problem, and you have already had a more useful conversation than most vendors get.

False positive rate

The second number is the ratio of alerts that turn out to be nothing. It is the number that governs whether the team is doing security or doing data entry.

A high false positive rate is not just wasted hours. It is the reason detections get tuned down or disabled. Every SOC lead I have talked to has a story about a rule that was generating so much noise the team turned it off, and then a version of the thing that rule was watching for happened. That story is the actual fear. Not "we might get breached." Something much more specific: we might get breached through a hole we opened ourselves because we could not live with the noise.

If your product genuinely reduces that ratio, say so plainly and be ready to explain the mechanism. If it does not, do not pretend. The buyer will find out in a POC and you will have burned the account.

Everything else — posture scores, coverage percentages, framework alignment — is downstream. Useful for the board deck. Not what gets you a second meeting.

Who owns the pain and who owns the budget

This is where a lot of deals in security die quietly.

The person feeling the pain is usually the SOC manager or the director of security operations. They are hands-on enough to know exactly what is broken. They will have a real conversation with you. They will nod along. And they very often cannot sign anything.

The person with budget is usually the CISO, sometimes a VP of infrastructure, and increasingly a procurement or vendor management function that has been told to reduce the number of security contracts. That person's incentives are different. They are thinking about the tool sprawl they inherited, the renewal calendar, the audit, and whether adding another vendor makes their story to the CFO harder or easier.

Which means the SOC lead's yes is a technical yes, not a commercial one. And the CISO's yes is a portfolio decision that may have nothing to do with how good your detection logic is.

What I do with this is simple. I run the operational conversation with the person who has the pain, and I explicitly build the internal case with them. Not "can you introduce me to your CISO." More like: "When this gets to your CISO, what is the first objection? Is it budget, is it another agent on the endpoint, or is it that you already bought something meant to do this?" Then I help them answer that, in their language, and I ask what evidence they would need to make the argument stick.

That is a different motion from multithreading for the sake of it. You are not going around the SOC lead. You are arming them. The discovery call structure I use for security accounts puts most of its weight here, because diagnosing the SOC is only half the job — the other half is diagnosing how a purchase actually happens inside that org.

The credibility traps

Security buyers disqualify vendors fast, on signal rather than substance. Here are the ones I see cost reps the meeting.

Leading with "AI-powered"

Every security product now claims AI. The SOC lead has heard it from the SIEM, the EDR, the email gateway, and the tool that sorts their tickets. It has stopped carrying information. Worse, it now carries negative information, because the products that leaned hardest on it were often the ones that generated the most unexplainable alerts.

If your product uses machine learning in a way that matters, describe what it does, not what it is. "It clusters related alerts so the analyst triages an incident instead of nine alerts" is a claim. "AI-powered alert triage" is a slogan. One of those survives contact with a technical buyer.

Naming a recent breach in your opener

Do not do this. "You've probably seen what happened at [company] last month — I wanted to reach out because..." reads as fear-selling, and security people find fear-selling distasteful in a way that other buyers do not. Many of them know someone who worked at the breached company. The industry is small. You are using a colleague's worst quarter as a cold call hook.

It also signals that you have nothing specific to say about their environment, so you reached for the news. If you want to reference an attack pattern, reference the technique, not the victim. Talking about how a specific identity-based technique is showing up in environments like theirs is a professional observation. Naming the logo is a cheap one.

Pitching consolidation to someone mid-consolidation

"We can replace three of your tools" is a strong message to a team that has decided to consolidate and has not started. It is a terrible message to a team that is nine months into a painful migration, because you are asking them to add a project to a year that is already broken.

You cannot know which one you are talking to unless you ask. So ask, early: "Where are you in your tooling roadmap right now — are you adding, replacing, or in the middle of ripping something out?" The answer changes your whole pitch. Mid-migration, the winning message is usually we make the thing you already committed to work better, not we replace it.

The single pane of glass

Just retire it. Everyone has promised it. Nobody has delivered it. Saying it out loud marks you as someone who read the category page and not the customer.

Three questions that prove you have talked to a SOC before

Credibility in this market is not built by knowing acronyms. It is built by asking questions that only make sense if you understand the operational reality. These three do a lot of work for me.

"What's the split between Tier 1 and Tier 2 right now, and where does the queue back up?" This asks about structure and bottleneck in one move. Every SOC has a pinch point. Some are drowning at triage. Some triage fine and have three senior people who are the only ones who can close anything complex. The answer tells you which problem you are actually selling into.

"Which detection have you tuned down or turned off because of the noise?" This is the question that changes the temperature of the call. It presumes something they have all done and rarely say out loud, and it presumes it without judgement. If they answer honestly, you are in a real conversation. If they deflect, you have learned they do not trust you yet, which is also useful.

"When something real does fire, who has authority to contain it without asking permission?" Response time is often a governance problem wearing an ops costume. This question surfaces that immediately, and it separates you from every rep who assumes the SOC can just isolate a machine.

None of these are clever. They are just questions you cannot ask convincingly unless you have thought about the job. That is the whole bar. The cold call script I use to get a SOC leader to give up 25 minutes is built around getting to one of these fast, because the opener is only there to buy you the right to ask.

When they already own a SIEM they hate

This is the most common qualification scenario in the category, and it is where most reps mis-read the situation.

The SOC lead will tell you the SIEM is a problem. It is expensive, ingest costs are unpredictable, the query language is painful, nobody has time to maintain the content packs. You hear this and think: displacement opportunity.

It usually is not. That SIEM is load-bearing. It is where the log retention lives, which means it is where the audit evidence lives, which means legal and compliance have a stake in it. It has a multi-year contract. Somebody senior championed it and is still at the company. Ripping it out is a program, not a purchase, and no SOC lead who is short-staffed is volunteering to run that program this year.

So the qualification question is not "are they unhappy with the SIEM." They are. Everyone is. The question is: what can change without touching the SIEM contract?

Sometimes the answer is a lot. If the pain is triage speed and analyst churn, you can improve both while every log keeps flowing to the same place. If the pain is ingest cost, there may be room to change what gets sent without changing where it lands. If the pain is that detection content is stale, that is a content and tuning problem, not a platform problem.

And sometimes the answer is nothing, in which case you should find that out on the first call rather than the fourth. Ask when the SIEM renews. Ask who owns that relationship. Ask whether anyone has floated replacing it and what happened to that conversation. If the renewal is two years out and the CISO who bought it is still in the chair, you are selling alongside it, not instead of it — and your entire narrative should reflect that.

The same logic applies once you are already inside an account. Expanding into a SOC is less about new capability and more about proving the last thing you sold them did not add work, which is why the upsell conversation in security has to start with adoption evidence rather than roadmap.

What I would do next

If I were ramping on a security patch tomorrow, I would not start with the product deck. I would spend a day reading incident write-ups and SOC job descriptions, because job descriptions tell you what the team is actually short of. Then I would write out my opener, my three diagnostic questions, and my answer to "we already have a SIEM," and I would say them out loud until they stopped sounding like a script.

That last part is the part almost nobody does. Reading a script is not practice. Saying it to a live human who pushes back is practice, and in a market where the buyer disqualifies you on tone in the first ten seconds, tone is the skill. That is why I built DrillCall — so a rep can run the SOC conversation, get interrupted, get the "we already looked at this category" objection, and be bad at it in private instead of on a real dial. If you are going into security accounts this quarter, rehearse the first thirty seconds until it is boring, then go make the calls.