Tyler Bowman · October 15, 2026

How to Sell to CISOs: A Practical Guide

CISOs aren't hard to sell to because they hate vendors. They're hard to sell to because their job is to doubt claims, and most sales outreach is unsupported claims. If you want a CISO's time, stop treating them as a target and start treating them as someone who will check every statement you make.

This guide covers what works: how to research, how to open, how to run discovery, how to deal with the buying group, and how to tell if your deal is real. No scripts. Just practices you can apply this week.

Understand what a CISO is actually accountable for

Before you write a word, get clear on the job. A CISO is accountable for managing risk to the business with limited budget, limited headcount and a board that wants simple answers to complicated questions. Some report to the CIO, some to the CEO, some to the general counsel. That reporting line changes what they care about and who else is involved in the decision.

Most CISOs are dealing with some mix of:

Too many tools their team can't fully run.
Too few people to operate the tools they have.
Pressure to explain risk in business terms to executives and the board.
Regulatory and customer obligations: audits, questionnaires, contract requirements.
Incidents and near misses that reset priorities overnight.

Notice what's not on the list: "a new platform." Adding a vendor adds work. Your product has to remove more work or more risk than it creates, and you have to show that with evidence the CISO accepts.

Do the research before you reach out

Most CISO outreach fails at the first sentence because it could have gone to anyone. "I noticed you're the CISO at Acme" isn't research.

Useful research answers four questions:

What changed? New CISO, acquisition, expansion into a regulated market, a public incident, a new compliance requirement, a large hiring push in security. Change is what opens budget.
What do they likely run? Job postings, public case studies, conference talks and partner pages often show the stack. Don't pitch a replacement for something you're only guessing they use.
Who owns the problem you solve? Often it's not the CISO day to day. It might be a director of security operations, the head of GRC, or a cloud security lead.
What have they said in public? Talks, podcasts, posts, interviews. If a CISO has publicly explained how they think about a problem, use their framing, not yours.

One rule matters more than the rest: if you can't find a fact, don't make it up. Saying "it looks like you're consolidating your SOC tooling" when they aren't tells the CISO you didn't do the work. A short, accurate email beats a long, confident, wrong one.

Lead with a specific why-now, not a product

The best first message to a CISO answers one question: why this, why me, why now?

A weak open:

We help security teams reduce alert fatigue with AI-powered detection. Do you have 15 minutes?

A stronger one:

Saw you're hiring three SOC analysts after the expansion into the EU. Teams in that spot usually hit a wall on after-hours triage before the new hires are productive. We help close that gap. Worth comparing notes on how you're covering it now?

The second version names a real trigger, states a likely consequence, and asks a question that's easy to answer. It doesn't claim to know their problem. It offers a hypothesis they can confirm or reject. CISOs respond to being treated as experts.

Practical rules for outreach:

One idea per message. Not three value props.
No unverifiable numbers. "Cut MTTR by 80%" invites "prove it" or gets ignored. If you have a real, referenceable customer result, name the source.
No fake urgency. Security buyers know the difference between a real threat and a quarter-end push.
A person sends it. Automated sequences to security leaders are easy to spot and hurt your brand. Use automation for research and drafts, then have a rep read every message before it goes out.

Run discovery that gets their numbers, not your pitch

When you get the meeting, the goal isn't the demo. The goal is evidence you'll need later to build a business case the CISO can defend.

Good discovery questions for security leaders:

"How are you covering this today, and what does it cost you in people and time?"
"What happens if this doesn't get fixed this year? Who notices?"
"How will you decide between doing nothing, building it, or buying something?"
"Who else has to agree, and what will each of them care about?"
"How do you report this risk to leadership now?"

Write down their answers in their words. "Our two senior analysts spend most nights on triage" is worth more than any benchmark you bring. When you build the proposal, the numbers should be theirs.

Map the buying group early

You don't sell a security purchase to one person. Expect some combination of:

The CISO, who usually sets direction and may or may not sign.
Security engineering or operations, who will run the product and can quietly stop it.
IT and infrastructure, who own the integration work.
GRC or compliance, who care about audit and evidence.
Procurement and legal, who will send you a security questionnaire and a contract redline.
Finance or the CIO, who may control the budget.

Ask early, and directly, who the economic buyer is. "Who signs off on a purchase like this, and what do they need to see?" is a normal question. Reps avoid it because they're afraid of the answer. Not asking is how deals die in "Proposal."

Also expect your company to be evaluated as a security risk. Have your own security documentation, data-handling answers and integration permissions ready before procurement asks. A vendor that can say exactly what it reads and what it writes in each connected system gets through review faster.

Make the proof-of-concept a test with a pass mark

Security buyers often want a POC. That's fair, but an open-ended POC is where security deals go to die. Before you start, agree in writing:

What success looks like, in the customer's metrics.
Who will judge it and when.
What happens if it passes: the next step, the timeline, who signs.

If the buyer won't agree to success criteria, the POC is research for them, not a buying step. That's useful to know early.

Know whether the deal is real

This is where most security pipelines break down. A CISO who's engaged and positive isn't the same as a deal that will close. Before a deal moves to proposal, you should be able to say yes to questions like:

Have we identified the economic buyer, and have they been involved?
Do we know the decision criteria and how they'll be weighted?
Have we captured the customer's own metrics for the problem?
Is there a real reason to act this quarter, and is it theirs, not ours?

If the answer is no, the deal isn't at proposal, whatever the CRM says. This is the core of the CRAFT method: a deal moves forward on evidence. In CRAFT, the platform refuses the stage change until those facts are on record, and a manager override is logged. You can run the same discipline in a spreadsheet. What matters is that someone enforces it.

Respect their time after the deal too

CISOs talk to each other, constantly. The way you handle the deal you lose, the renewal, and the implementation all get discussed in rooms you're not in. Don't overpromise in the sales cycle to win a deal that becomes a reference against you. The long game in security sales is reputation.

A short checklist

Before you contact a CISO:

I know what changed at this company.
I know who owns the problem day to day.
Every claim in my message is something I can back up.
A person read the message before it went out.

Before you call it a real opportunity:

Economic buyer identified.
Decision criteria known.
Customer metrics captured, in their words.
Buying group mapped.
POC (if any) has written success criteria.

Where CRAFT fits

CRAFT is the sales platform for cybersecurity teams. Its agents do the research, find the why-now and draft the outreach, and reps decide what gets sent. Deal stages are gated on the evidence above. If you want to see it on one of your own deals, book a time with Tyler.