Table of Contents
TL;DR
Every executive who comes to me for a cybersecurity book wants to write a technical book. What they need is a book aimed at their real audience, which is almost never technical people. I bring 33 years in technology, decades of security work, PCI audits, breach response, and a credited rewrite of an industry-standard security book, plus 54+ books ghostwritten. The combination matters: a security book by someone who has to have the field explained to them reads exactly like what it is.
When an executive approaches me about a cybersecurity book, the first conversation is almost always the same conversation, and it is not about security. It is about audience. 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. The instinct is understandable: technical depth is what they are proud of, and the book is meant to prove they have it.
Then I ask who the book is for, and the real answer is never “engineers.” It is customers for a consulting practice. It is boards and CEOs who approve security budgets. It is the managers who decide promotions and the committees who book speakers. Those readers do not 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, load-bearing, and invisible from the surface.
The IoT book that taught me the fight
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, not a lab. 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 would fight that battle harder and earlier, because I have watched the pattern across dozens of technical books since. 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 rather than backbone. My digital transformation, metaverse, AR/VR, and AI books all follow that architecture, and it is the architecture, not the topic, that makes them perform.
Why the ghostwriter’s field knowledge matters
Here is the part specific to security. A ghostwriter without security experience can transcribe your expertise, but transcription is not the job. The job includes knowing which of your war stories carries weight, which acronym needs unpacking and which would insult the reader, which claims will get you quietly mocked by practitioners, and, critically in this field, which details should never appear in print at all. I do not 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.
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 do not need the field explained. I need only their piece of it, which shortens interviews, sharpens questions, and produces a book that reads like it was written by someone who was there. 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 I interview a security executive
The process behind these books is worth describing, because it is where the field experience pays. When I interview a client, I am not asking “tell me about cybersecurity.” I am asking the questions that surface the material a security book actually 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 surface stories they had not 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 are reading practices exactly that protocol on my own history, which is a live demonstration of the tradecraft your book would receive.
What a credible security book requires
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.
Get those right and a security book does what a credential cannot: it walks into rooms before you do and argues your expertise to the exact people who can act on it.
If that is the book you have in mind, my cybersecurity ghostwriting process covers how the engagement runs from first interview to published book, and the broader ghostwriting service page covers structure and investment. Bring the war stories. I will know which ones belong in print, and exactly how much of them to leave out.
For more from this series, see the The Cybersecurity Hub: breaches, audits, and hard-won security lessons from four decades in the trenches.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.