When an executive approaches me about a cybersecurity book, the first conversation is almost always about audience, and security barely comes up. They arrive wanting to write a technical book, and this is true whether the subject is security, digital transformation, or any technical field. Deep dives, architectures, maybe code. I understand the instinct, because technical depth is what they’re proud of and the book is meant to prove they have it. It’s also the surest way I know to write a book the people who matter will never finish.
Then I ask who the book is for, and the answer is customers for a consulting practice. It’s boards and CEOs who approve security budgets. It’s the managers who decide promotions and the committees who book speakers. Those readers don’t want the bit-and-byte level. They want to understand what security means for their business, told by someone who has clearly mastered the depths without drowning them in it. Technical detail belongs in the book the way rebar belongs in concrete: everywhere, essential, and invisible from the surface.
What did an early IoT book teach me about security books?
One of my earliest ghostwriting projects was an IoT book for a client whose goal was attracting the attention of management. The manuscript kept drifting technical, and I kept having to pull him back: strip this section, simplify that one, your reader runs a division.
He wanted the technical content in; I wanted his goal achieved. He landed on enough of a balance that the book worked, and it delivered exactly what he was after: promotions, speaking engagements, standing.
Today I’d fight that battle harder and earlier, because every technical book I’ve worked on since has shown me the same pattern. The books that generate speaking invitations and client pipelines are pitched a couple of layers above the technology, with the technical substance as supporting evidence instead of backbone. My digital transformation, metaverse, AR/VR, and AI books all follow that architecture, and the architecture is what makes them perform, whatever the topic.
Why does a ghostwriter’s security knowledge matter?
A ghostwriter without security experience can transcribe your expertise, and transcription is the smallest part of the job. The rest is knowing which of your war stories matters, which acronym needs unpacking and which would insult the reader, which claims will get you mocked by practitioners, and, critically in this field, which details should never appear in print at all. I don’t name companies in my own security stories; specifics are reconnaissance for attackers, even old ones.
An executive’s book needs a writer who applies that discretion instinctively, because the author’s name is on the cover when the OPSEC failure surfaces. A writer who lets a network map’s worth of detail into print because it made a chapter feel authoritative has failed the client, and the client is the one who answers for it in front of the board.
My background covers the span this field requires. 33 years in technology. Infrastructure leadership at a major national retailer. Eight years of PCI audits, breach response from network worms through modern supply-chain attacks, NIST documentation engagements, and a credited role as contributing author and technical editor of the 2020 edition of Cyberheist, KnowBe4’s book on cybercrime. When a client tells me their story, I don’t need the field explained.
I need only their piece of it, which shortens interviews, sharpens questions, and produces a book that reads like someone who was there wrote it. Because between the two of us, someone was.
Executives want to write a technical book. The book that builds careers is aimed at the people who fund and promote them.Share on X
How do you interview a security executive?
An executive’s book needs a writer who applies that discretion instinctively, because the author’s name is on the cover when the OPSEC failure surfaces.
The process behind these books is worth describing, because it’s where the field experience pays. When I interview a client, I’m not asking “tell me about cybersecurity.” I’m asking the questions that unearth the material a security book runs on: which incident do you still think about, what did the audit find that the report softened, what did the fix really cost versus what the budget said, what would you tell the executive about to make your mistake.
Those questions only occur to an interviewer who has stood in the incidents himself, and clients consistently tell me the interviews turn up stories they hadn’t thought about in years, because nobody had ever asked from inside the experience.
Then the discretion protocol shapes what the stories become on the page. Every anecdote gets stripped to its operative details: the industry stays, the company goes; the architecture pattern stays, the product names go; the lesson keeps its teeth while the reconnaissance value drops to zero. The article you’re reading practices exactly that protocol on my own history, a live demonstration of the tradecraft your book would receive.
My take
Choose a ghostwriter who knows the field well enough to know what to leave out. Your security book is aimed at people who aren’t technical, and your peers will still read it looking for mistakes. Strip every story to its operative details. Keep the industry and drop the company. Keep the architecture pattern and drop the product names. A writer who lets a network map’s worth of detail into print gives attackers free reconnaissance, and the board will want answers from you about it.
What does a credible security book require?
From the podcast
Cesar Dongo-Soria has thirty years in trade compliance and finds the same gap in the executive suite, on Leaders and Their Stories:
I noticed that a lot of executives don’t know, or aren’t familiar, or they don’t want to know that they’re liable for their shipments.Don’t want to know is the important clause. A book that pretends the exposure is technical instead of personal won’t be believed by anyone who has read the regulation.
Three things, in order. An audience decision made before the outline: who funds, promotes, or hires you, and what do they need to believe after reading? War stories with the specificity trimmed to safe and the lessons intact, because stories are what readers retain and cite. And restraint: the discipline to keep the technical depth in a supporting role, visible enough to prove mastery, never so dense it changes who can finish the book.
| Requirement | What it means | Without it |
|---|---|---|
| Audience decision first | Before the outline, decide who funds, promotes, or hires you, and what they must believe after reading. | A technical book the people who matter never finish. |
| War stories, trimmed to safe | Keep the lessons readers retain; strip the details that give attackers reconnaissance. | An OPSEC failure surfaces with the author’s name on the cover. |
| Restraint | Technical depth stays in a supporting role, visible enough to prove mastery. | A book engineers skim and executives never open. |
Get those right and a security book does what a credential can’t: it walks into rooms before you do and argues your expertise to the exact people who can act on it. Get them wrong and you’ve spent months on a book engineers skim and executives never open, and real field experience deserves better than that.
If that’s the book you have in mind, my cybersecurity ghostwriting process covers how the engagement runs from first interview to published book, and the wider ghostwriting service page covers structure and investment. Bring the war stories. I’ll know which ones belong in print, and exactly how much of them to leave out. For more from this series, see The Cybersecurity Hub: breaches, audits, and hard-won security lessons from 33 years in the trenches. If you’re weighing a security book, the Book Discovery Intensive settles who it’s for before a chapter is written.
Security leaders know the field and rarely have time for a manuscript. The Ghostwriting Advantage is my guide to getting your book written for you by someone who has ghostwritten 54+ books.
Frequently Asked Questions
- Search Victim-Owned Websites, Technique T1594, MITRE ATT&CK
