You Should Prioritize Writing as a Security Engineer
Cybersec Café #81 - 08/16/25
For the past year and 80 posts here at the Cybersec Café, I’ve preached the same mantra: get technical, sharpen your programming skills, and deepen your technical expertise to set yourself apart as a security engineer.
But today, I’m flipping the script. I’m here to talk about something very different - writing.
Now, I know what you might be thinking: Writing? As a security engineer? We’re supposed to write code, give security recommendations, and enforce security best practices - where does writing words fit into that equation?
Or maybe you’re running toward the tech industry because you hate writing or thought you were bad at it.
Don’t worry, same here - writing was by far my worst subject in school. If you asked my old teachers, they’d probably agree.
But I’m lucky that early in my career I figured out the impact that being a quality writer can make on your work. That’s one of the primary reasons I started this newsletter, to improve. And here I am, a year and a half into writing a weekly newsletter.
So how did I get here? And why do I believe writing is one of the most underrated skills for a security engineer?
Why Writing?
At first, writing seems almost contradictory to an engineering role. After all, engineers are judged on technical chops - system design, debugging, and complex coding interviews.
But here’s the thing - clear and concise writing is criminally underrated in tech, and can be a major differentiator.
Ryan Peterman put it well in a LinkedIn post:
“Distinguished engineers at Meta make upwards of $3M per year. Every diff description, launch post, or directional doc [these engineers] write is crystal clear. I don’t need to work in their domain to understand what they say.”
Think about it. Who doesn’t appreciate a well explained design document? Or a detailed, easy-to-follow bug bounty report? Or even just a thoughtfully written ticket?
Money aside, writing is just part of modern engineering. Building systems isn’t just pounding out code and writing tests - it’s planning, documenting, and communicating ideas before a single line even gets written.
And from a personal perspective, writing forces you to organize your thoughts. If you can lay them out clearly on the page, you’ll communicate more clearly when you speak too. That’s a skill every engineer benefits from.
I’m a firm believer that you don’t even need to be a great writer. Just an above-average one can have a massive impact on your effectiveness as a security engineer.
And here’s how.
Real-World Writing for Security Engineers
Requirements Documents
Ah yes - the trusted requirements doc. I’m not going to lie - the first time I had to write one back in university for my senior design project, I thought it was a complete waste of time.
But little did I know, it would save me an incredible amount of time down the road.
At its core, a requirements doc defines the scope of a project and the features needed for it to be considered a success. In other words: it sets the success criteria.
If done well, it makes the project crystal clear to all stakeholders and acts as a guardrail against scope creep.
But let’s be real - if your company’s current approach is to throw projects at the wall, iterate quick, and see what sticks, then requirements docs probably aren’t part of your workflow.
But if you’re serious about building something meaningful, then requirements docs become less of a formality and more of an opportunity to align cross-functionally.
Skip this step, and you’ll waste far more time later trying to fix misaligned expectations, rather than taking that extra time to spell it out and discuss first.
Technical Design Documents
Once you’ve nailed down the what and why in your requirements doc, the next step is the how. That’s where the technical design document comes in.
The purpose of a design doc is simple: think through your solution before you build it. Taking the extra time saves you from painful redesigns, costly mistakes, and the dreaded “rip it all out and start over” scenario.
Benefits of design docs really shine through when it comes to peer review. Sharing it gives others a chance to strengthen your work before it’s set in stone:
Infrastructure teams can validate architecture.
Security team members can flag risks.
Network engineers can ensure efficient data flows.
DevOps can review for any CI/CD implications.
Product can confirm it still solves the right problem.
Not every project will need this level of rigor. A small internal tool might not warrant a 10-page design doc. But if you’re building a complex system, this is where the serious work begins.
Vendor Evaluation Documents
These days, no matter what kind of product you’re looking at, there are dozens of competing vendors - each with their own strengths, weaknesses, and trade-offs.
Business best practice is always to evaluate multiple options before committing to the one that best fits your organization’s needs. And the best way to keep that process organized is with a vendor evaluation document.
A vendor evaluation doc lets you clearly outline what each product brings to the table, where it falls short, and how it stacks up against your defined requirements (yep, those requirements again….).
By putting everything on paper, you strip away emotion and shiny marketing pitches, and instead make decisions based on the facts.
A good evaluation allows you to quantify your options against your requirements - that way you’re not left with gut feelings, you’re left with data-backed decisions.
You may not be writing vendor evaluation later in your career, but early on? Expect to write quite a few.
Prepare for a career in Cybersecurity, one sip at a time with The Security Sip. With rapidly evolving threats and technologies, many struggle to gain the right skills and experience to break into the cybersecurity industry. This course is designed to transform beginners into industry-ready professionals over 12 sections, 85 modules, and 155 exercises. Check it out!
Pull Requests & Tickets
Pull Requests (or Merge Requests) are part of daily life anywhere code is written.
They’re how changes make their way into production, and the quality of your PRs says a lot about your professionalism as an engineer.
At minimum, your PR should include a clear title describing what it does, break down commits in a way that’s easy to follow (or squash them if needed), and include a description that provides relevant business and technical context.
PRs are usually tied back to tickets, which act as the main artifact for work efforts by attaching relevant conversations, documents, and supporting materials. If done well, this makes it possible to verify that the code does exactly what it’s supposed to.
If you’ve ever had to review a RP labeled “Bug Fixed” with a description of “Fixed bugs in the process,” you know how painful bad documentation can be.
A vague PR isn’t just annoying for reviewers - it’s a nightmare later when something breaks and you’re trying to figure out what changed and why.
Well-written PRs save time, reduce mistakes, and make rollback scenarios easier. Think of it as documentation for your future self (or whoever inherits your code).
Bug Bounty Reports
This one’s a bit of a more niche, but one I’ve studied quite a bit.
Last year, I spent 100 days reading and dissecting a different bug bounty report every day (you can dig deep into my Twitter archives if you want to see). After going through that many, one thing became painfully obvious when it came to those achieving high payouts, and those getting minimum bounties.
Let me explain.
I previously worked at a company with an in-house bug bounty program. Although I wasn’t the primary triager, I saw plenty of submissions and even had the opportunity to sit in during some payout discussions. What stood out to me was how much the writing quality influenced the reward:
A technically valid report that was confusing, incomplete, or hard to reproduce? Minimum payout.
A report with clear reproduction steps but no stated impact? A bit more.
A polished report with step-by-step instructions, a clearly articulated impact, and a working proof of concept? That was top payout every time.
Why? To reward hunters who made the work of fixing bugs easier, and to incentivize them to continue hunting on the program.
Clarity, reproducibility, and impact were just as valuable as the technical finding itself. I can’t speak for every bug bounty program out there, but I’d bet most follow a similar philosophy.
What I learned is simple: if you want to maximize both payouts and your credibility, learn to write bug reports that are clear, concise, and impossible to misinterpret.
Runbooks
Runbook is kind of a catch-all term in security, but at its core it’s simple: a runbook tells you exactly what to do in a specific situation to achieve a specific outcome.
They come in all flavors - alert triage, routine processes, incident response - but the guiding principle is always the same: speed, accuracy, and reliability.
When someone grabs your runbook, it’s usually not during a calm, controlled moment. It’s during a high-stress situation where mistakes are costly.
The last thing you want is ambiguity.
If your instructions are unclear, outdated, or missing steps, the entire point of the runbook is lost. That means writing matters. Every runbook should:
Start with a clear purpose.
Spell out each step unambiguously.
Account for branching logic (e.g., if this fails, then do that).
Think of runbooks as automation for humans. They should be so well written that anyone on your team, even someone half-asleep at 3am, can follow them to the letter and get the right result.
Incident Response Documentation
Quality IR documentation is one of those things that you don’t appreciate until you’re in the middle of an incident where it makes all the difference.
For smaller incidents, you can usually scrape by with a loose process and verbal updates on an incident bridge.
But when that time comes when multiple teams get involved and the situation becomes increasingly difficult to manage - clear, well-structured documentation becomes a lifeline.
Good documentation speeds up onboarding for new SMEs - Instead of wasting an hour digging through Slack threads or waiting on a call for context, they can immediately understand the scope of the incident, their responsibilities, and the current state.
That hour saved could be the difference in resolving the incident faster.
It also streamlines executive communication. Providing a crisp status report is often time consuming: What happened? What’s been done? What’s next?
But when details are already documented in a central, organized way, reporting becomes simple.
Ultimately, strong IR documentation removes guesswork. It gives everyone clarity on their role, reduces overhead, and frees people to focus on the incident itself - not on catching up or chasing information.
The Cybersec Café Discord is officially live! Join a growing community of cybersecurity professionals who are serious about leveling up. Connect, collaborate, and grow your skills with others on the same journey. From live events to real-world security discussions — this is where the next generation of defenders connects. Join for free below.
Clarity is Your Competitive Advantage
At the core of everything we’ve covered is one theme: communication.
Strong writing doesn’t just help you document your work - it makes your ideas land.
It helps you collaborate, persuade and lead. When it’s time to push for a solution, the clarity of your words will often determine whether your ideas gain traction or get lost.
If you’ve ever faced unnecessary pushback, endless revisions, or a rocky transition from a legacy tool, remember this: the responsibility for clarity lies with the sender, not the receiver.
For engineers, writing is more than a soft skill. The better you write, the more influence you have. And the more influence you have, the more impact you make.
Securely Yours,
Ryan G. Cox
P.S. The Cybersec Cafe follows a weekly cadence.
Each week, I deliver a Deep Dive on a cybersecurity topic designed to sharpen your perspective, strengthen your technical edge, and support your growth as a professional - straight to your inbox.
. . .
For more insights and updates between issues, you can always find me on Twitter/X or my Website. Let’s keep learning, sharing, and leveling up together.
Ryan, I completely agree with your points and the importance of clarity not only as a competitive advantage but as a solid service. I got my Masters in Engineering and wasn't able to write basic English sentences when I took my first couple of jobs many years ago. Then I was fortunate to work for someone who taught me how to write, and here I am as a professional freelance writer with two books and thousands of magazine articles with my byline. Thanks for this post.