A cold email to a CISO is, by definition, an unsolicited message from an unknown sender asking for a response, which is also the definition of the thing a CISO spends their career training the company to ignore. That is the whole problem with a cold email to a CISO, and most vendors make it worse: a tracking link, a PDF attachment, a subject line with urgency in it, and an opening about breaches. Each of those is a phishing indicator, and the CISO's own mail gateway may quarantine the email before a human sees it. What gets read is plain text, with no link and no attachment, that references a real change in their world, a new regulation, a peer's public incident, a job posting on their team, and offers to go through their vendor risk process rather than around it. The three templates below are built to that standard. The prompt after them finds the signal and checks your draft for anything a security filter would flag.
What a CISO is measured on, and what they delete
A CISO is measured on the absence of incidents, audit outcomes, time to detect and remediate, vendor risk, and how well they explain all of it to a board that understands none of it. They read email on a laptop, at a desk, with a security team screening the inbox, and their mail gateway rewrites or quarantines links before they ever see them. Their filter is threat modeling applied to your email: an unknown sender, a link, urgency, an attachment, and an emotional hook are the five signals they teach employees to report, and a vendor email carrying three of them is reported, not read. They delete anything that leads with fear, anything that says 'AI' in place of a mechanism, and anything that skips their vendor risk process. They reply to plain text that names a regulation or a peer's public incident and asks to be assessed.
Cold email to a CISO: three templates
All three are plain text with no link and no attachment, on purpose; keep it that way. Pick by the signal: a regulation with a date, a backlog you can infer from their hiring, or a peer CISO whose board metric they would recognize.
Subject: {{regulation}} and third-party evidence
{{first name}}, with {{regulation, e.g. DORA / NIS2 / the SEC incident disclosure rule}} in force from {{date}}, the {{specific requirement, e.g. four-day materiality decision}} is the part most security teams are still working out.
We produce the evidence trail for that decision: {{one-line mechanism}}, mapped to your {{framework}} controls. Acme Observe's CISO ran their first {{requirement}} against it in {{timeframe}}.
No link on purpose. If it is worth a look, I will send our SOC 2 report and questionnaire through whichever process you prefer.Subject: the questionnaire backlog
{{first name}}, most security teams your size carry a vendor questionnaire queue measured in weeks, and every week in it is a business team buying around you.
We answer them from your control evidence, so the analyst reviews instead of writes: {{one-line mechanism}}. Northwind Freight's security team took questionnaire turnaround from {{before}} to {{after}} without adding headcount.
Plain text, no link, on purpose. Reply "queue" and I will send our own completed questionnaire first, so you can assess us before we talk.Subject: how Harlow Logistics cut time to remediate {{result}}
{{first name}}, Harlow Logistics' CISO had what the GRC analyst posting on your careers page suggests you have: more findings than people to close them, and a board asking why the number is not zero.
They deployed {{product}} to {{one-line mechanism}} and mean time to remediate dropped {{result}} over {{timeframe}}. Their CISO presented it as the board metric that quarter.
I have their write-up and our security package ready to go through your vendor process. Which would you want first?{{regulation}} and third-party evidence
the questionnaire backlog
how Harlow Logistics cut time to remediate {{result}}
your GRC analyst posting
no link in this one
{{framework}} evidence for the {{month}} auditPlain text, no link, no attachment, no urgency, and an explicit offer to go through their vendor risk process first; a CISO who catches your email carrying two phishing indicators will report it, and their gateway will remember your domain.
Personalize these to the account, not just the persona
Security leaders read a cold email as a threat sample first and a pitch second, and the template only works once it names a real regulation, incident, or hiring signal from their world. That research is real work, and so is scrubbing the draft of anything a mail gateway or a suspicious analyst would flag. Paste the template with the prompt and let Claude do both before you send.
You are writing a cold email to the CISO of {{company}} ({{company URL}}) for {{my company}}, which sells {{one-line description}} and maps to {{framework, e.g. SOC 2, ISO 27001}} controls.
First, find one legitimate signal: a regulation that applies to their industry and region, with its effective date; a publicly reported incident at a peer company (never at {{company}} itself); a GRC or security job posting on their careers page; or a published trust page. Cite the source.
Then rewrite the template below. Line one names that signal without fear or urgency. One mechanism, stated plainly. No link, no attachment, no calendar, no tracking; the ask is permission to send our security package through their vendor process. Body under 90 words, plain text. Use {{customer proof}} exactly as stated.
Then audit the draft: list anything a mail gateway or a security analyst would flag as a phishing indicator and rewrite to remove it. Give me three subject lines with no urgency words.
TEMPLATE:
{{paste the template}}Write cold email at scale with Claude
- B2B cold email templates skill →The Claude skill that writes cold email in your brand voice with the banned-word list and the one-idea rule baked in.
- Cold email from a value prop prompt →The copy-paste prompt version: one value prop in, one specific email out.
- Personalize cold email with Clay and Claude →The use case that runs these templates across a whole list with real enrichment data.
Frequently asked questions
How do you write a cold email to a CISO without it looking like phishing?
Remove every phishing indicator before you write the pitch: no link, no attachment, no urgency in the subject, no emotional hook about breaches, and a sender domain that matches your company. Then open with a legitimate signal, a regulation with a date, a peer's public incident, a posting on their team, and state one mechanism plainly. Ask for permission to send your security package through their vendor risk process. That ask does two things: it shows you know how they buy, and it gives their analyst a task they already know how to do.
Should you mention a recent breach in a cold email to a security leader?
A peer's public incident, yes, as a signal, without drama. Their own incident, never, and their industry's incident with an implied 'you could be next' is just as bad, because fear is the tactic phishing uses and the CISO reads it that way. The test is whether your line one would be a reasonable thing to say to them at a conference. 'Since the {{peer}} disclosure, most teams are re-checking {{control}}' passes. 'Are you prepared for the next attack?' gets you reported. Cite the public source and move to the mechanism in the next sentence.
Who should you email in security besides the CISO?
The person who owns the problem your product solves, which is rarely the CISO. GRC managers own questionnaires and audit evidence, security engineering owns tooling, and the SOC lead owns detection and response. Job postings on the careers page tell you which team is hiring, and therefore which one has the pain. Email that owner with the same rules, plain text and no links, and mention you have written to the CISO. The CISO's usual good outcome is a forward to that person anyway; emailing both with consistent notes shortens the loop by a week or two.