My father worked in IT for over thirty years, and growing up around that shaped how I thought about computers. The earliest memory I have is sitting in my father's lap as he does something on his computer. One of the oldest photos I have is of me sitting on a chair in front of a computer. I grew up idolizing him. I switched to Linux when I was 12, by myself. I taught myself scripting, picked up programming basics, and spent more time in a terminal than most adults I knew. I have memories of sitting on the roof at 13 with my laptop, trying to crack my neighbor's WiFi with aircrack-ng (they were aware of my endeavors).
However, growing up in a politically volatile neighborhood (Lyari) also made me politically aware and literate from a young age. With that, I developed an interest in political science and philosophy. I sat my A levels in economics and sociology, and I did not look back. For the next few years, the technical side of my life became just a habit rather than a professional direction.
Then I realized I do not have to choose one or the other. I can carry on doing both. Today, I am an academic and technical editor. The social sciences gave me the writing skills: reading long blocks of dense theory, explaining abstract concepts in plain language, writing long analytical essays. And I understand technical concepts well enough to work with them seriously. I thought of synthesizing both.
When I started building a technical writing portfolio, cybersecurity documentation felt like a natural place to go. Not because I had operational experience, but because I had grown up adjacent to that world. I understood the culture, the tooling, and the mindset, even if I had never worked a SOC shift. I knew I wanted to cover security documentation. Security teams produce some of the most consequential written work in any organization, and most of it is poorly structured, inconsistently formatted, or written for the person who already knows the answer rather than the person who needs to act.
The question was whether my background was enough to write something credible.
Here is what the process actually looked like.
Start With What You Actually Know
My Linux experience gave me a foundation that pure writers would not have. I understood what ps aux, netstat, and journalctl output looks like. I knew what a suspicious cron job entry means, and why volatile state needs to be captured before anything else. I was not guessing at the commands or pretending to understand the output.
That is not the same as operational experience, but it is not nothing either. It meant I could write the procedural steps accurately and understand why their order matters.
Research the Structure Before the Content
Before writing a single line of the playbook, I spent time reading publicly available incident response frameworks, SANS documentation, and real SOC runbooks that organizations have open-sourced. I was not looking for content to copy. I was looking to understand what a well-structured investigation workflow looks like, what sections it needs, and what decisions an analyst has to make at each stage.
The structure I settled on followed the investigation sequence: volatile state capture first, then process and network analysis, then persistence checks, then evidence preservation and chain of custody. Each section answers a specific question the analyst needs to answer before moving to the next.
Get It Verified by Someone Who Has Done the Work
This is the part that mattered most. My brother is a DFIR professional. I gave him the draft and asked him to read it as if he were walking into an actual incident. He approved it on the first read, with only minor notes.
That verification step is what separates a document that looks like a playbook from one that would actually hold up in use. I could not have provided that myself. Knowing that I needed it, and finding someone qualified to provide it, was part of the work.
What the Process Taught Me About Security Documentation
Most security documentation fails for the same reasons most documentation fails: it assumes too much prior knowledge, it buries critical steps inside walls of prose, and it is written for the person who already knows the answer rather than the person who needs to act under pressure.
A good investigation playbook is not a knowledge dump. It is a decision support tool. Every section should answer a specific question, every step should have a clear expected output, and the analyst should never have to wonder what to do next.
That principle does not require operational experience to apply. It requires understanding how people use documents under pressure, which is what technical writers are supposed to be good at.
The Playbook Is in My Portfolio
If you want to see the finished document, it is in my technical writing portfolio on GitHub. I am happy to discuss the structural decisions behind it in the comments.
Top comments (0)