A short(-ish) guide on information security writing

Disclaimer: I'm not a professional writer. All the issues I talk about here are ones that I have encountered throughout my career, and the things I recommend are ones that have personally helped me at one point or another. YMMV.

Whether you’re compiling incident notes at 3 AM, drafting a post-mortem report for the board or helping the marketing department to craft a blog post that will generate near endless riches for your employer - we may like it or not, the ability to produce qualitative writing is as much a vital skill when working in information security as your technical prowess.

I have had to do it for a while now, and as part of my writing I made a lot of errors, mistakes, and sub-par choices. I also learned a lot of things and got better practice. This post contains some tips, recommendation and (hopefully common and not just affecting me) pitfalls to be aware of in order to make writing for information security purposes as comfortable, effective, and efficient as possible.

Mind the gap - and bridge it!

When writing a report security professionals serve as a sort of translator between the technical world and others, especially business stakeholders. This can be a challenging endeavor

• Reduce technical jargon: It's almost unavoidable to use some technical jargon, but drowning your audience in words they've never heard before doesn't make you sound mysterious and cool. Using the phrase "A security vulnerability could let attackers steal user data" conveys a very similar message to "XSS vulnerability in our SaaS app could let attackers steal user data", but ensures that even a busy executive with barely any technical knowledge can understand what you're trying to say.
  
  Try to bridge abstract "cyber" concepts to real-life references that non-tech folks can relate to. For instance, describe multi-factor authentication as "showing ID to verify who you are, not just using your password". Comparing a firewall to a "digital security fence" or referring to phishing as "online scam emails" makes the issue tangible. Analogies can demystify threats and emphasize why they matter in terms that are more familiar to most people.
• Simplify, but don't dumb things down: Using short sentences and common words helps with clarity, but it's important to avoid sounding condescending. Similarly, as mentioned above, overly complex language might impress a few people, but it will alienate at least as many readers. The goal is always to convey the meaning of technical findings, not to show off vocabulary or any weird form of perceived superiority.
• Focus on impact and actions: When communicating to mixed audiences, emphasize what the technical facts mean for them. Translate technical outcomes into business risk: e.g. "Sensitive customer records could be exposed, leading to compliance penalties". Highlight the implications and recommended actions, rather than just the technical cause. Doing so helps non-technical readers see the urgency and relevance of your message.
• Encourage questions and feedback: I know, I know. I too am tired of answering the same questions I've answered repeatedly over the last decade or so. But still, bridging a gap is a "two-way street". Invite your audience to ask for clarification if some things are unclear to them. Ask them to provide feedback on how you could improve.
  
  A receptive tone and a willingness to explain builds trust and ensures your message was understood, or gives your message the chance to be understood. By fostering dialogue, in meetings or in writing, you confirm that both tech and non-tech stakeholders walk away with the same understanding of security issues.

However, in order for people to be able to ask questions and to provide feedback, you first need to give them something they are interested in enough in order to even care - which is why telling a compelling story is as vital in writing about / for information security as it is in other writing disciplines.

Make it a story, make it compelling

In the last list above I spoke about impact and actions, about the necessity to get people to do things about security issues. The problem is that if you're not a technical person or have no regular contact with information security, dry facts and log data alone seldom inspire action.

Storytelling techniques that you'd think are reserved for novels can in fact turn an incident or an analysis into a narrative that engages readers and provokes a response. Hopefully the right one. Which is why good security writing often follows a narrative arc - it sets the scene, introduces a conflict, and resolves it with lessons or recommendations. Here are a few tips that help with that:

• Ensure your narrative has a structure: Approach reports and summaries like a story with a beginning, middle, and end. Identify the "characters" in your security story (perhaps the protagonist is a tool or your security team, and the antagonist is the threat actor or a piece of malware). Outline the struggle or challenge (e.g. an intrusion that evaded defenses) and build a timeline of events to walk the reader through what happened. On top of engaging the reader, this structure keeps your writing focused and purposeful.
• Define the theme or goal: Every good story has a theme or a key message. Decide what the central takeaway is (e.g. "No one is immune to phishing!" or "Timely detection can prevent major damage!"). Let this theme guide which details to include. Always have a goal for your writing, I can't stress this enough. Know what you want the reader to feel or do after reading, because that's how you get them to implement a fix or approve a budget.
• Make it personal Evoke empathy and emotions: Facts inform, but emotions motivate. To persuade action on security issues, make the reader feel something. For example (when appropriate of course), tell the story of an incident from the victim's viewpoint to invoke urgency or empathy. This especially helps when trying to get people on something routine that they usually tend to ignore, such as a regularly occurring alert that has at least a reasonable chance of being a false positive. In those cases, data alone is rarely enough.
• Show, don't just tell: Instead of simply listing facts, weave them into the storyline. For instance, rather than a bullet saying "Malware executed at 03:00 a.m.", write "At 03:00 a.m., the incident sprang to life: a malware silently executed and began siphoning data".
  
  Wording it like this paints a picture. Use quotes, timelines, or brief anecdotes from the investigation to add, for lack of a better word, "realism". A compelling narrative can transform mundane details into a case study that readers remember.
• Balance story with substance: While storytelling can help a lot, always remain truthful and evidence-based. You can interpret the fact, but you must never fabricate them. The narrative should enhance understanding of the evidence, not replace it. Always ensure that every claim in your story is backed by your analysis or data.
  
  A similar balancing approach has to be made regarding to tone. On one hand it's important, especially when writing post-incident reports, to acknowledge the challenges your audience faces. An empathetic tone shows that you appreciate the human element. But at the same time, it's still a professional report. Never forget that.

Even knowing all of these things, writing is still not always an easy process for me. There are a tons of pitfalls that I regularly fall into and accidentally sabotage my own writing. Which is what I want to talk about in the next section of this post.

Don't fall into the same holes I fell into!

Knowing your audience, preparing a storyline, knowing what to write and how to write it are big steps into the right direction. But there's still plenty of mistakes you can - or, if you're like me, do - make in the process of actually writing things.

• Aimless writing / lack of focus: If you're writing away aimlessly, chances are that you aren't going to answer the core question of your readers. If you are aimless, your readers will get lost to. As will the key message that you are trying to convey.
  
  To spot aimless writing, ask yourself "Can I summarize the main point of a paragraph in one sentence?" - if that's not the case you might be writing aimlessly. In a training class I took on writing the recommendation was to always have a clear objective before starting to write, and then to regularly compare and ensure that every section and every paragraph serves that purpose.
  
  For myself I found that non-practical. Doing it while I'm writing breaks my flow, doing it afterwards potentially means that I have to rewrite everything. I mostly try to walk a middle ground. Whenever I pause to think about wording or grammar, I take the time to "check in" with myself to see if I'm still "feeling" what I'm writing.
• Overuse of passive voice: Passive voice can muddy the clarity of who performed an action, as I mentioned above. It often sneaks into security reports, perhaps to sound formal or to avoid assigning blame (e.g. "Policies were violated" is passive - it doesn’t say who violated them).
  
  While passive constructions are not grammatically incorrect, overusing them makes writing less engaging and more ambiguous. There are scenarios in security writing where passive voice might well be appropriate - for instance, if you truly don’t know the actor ("The file was modified at 12:00 UTC" when you haven’t determined who did it). But use it sparingly.
• Zombie words: I talked about unnecessary jargon above, but there's more to it than potentially confusing the audience. If you writing contains a lot of lifeless, overused words, chances are that you accidentally add a lot of clutter without added clarity.
  
  They drag down your prose and make sentences harder to parse. Cliché phrases like, for example, "state of the art" or "paradigm shift" similarly lull a reader into skimming. To avoid this, favor plain verbs and descriptions. For example, use "we implemented encryption" rather than "implementation of encryption mechanism". Fresh, concrete language keeps your writing alive.
  
  As one guide on writing I enjoyed put it: "When writers shoot up verbs with nouns and adjectives, they create zombie words... These ghastly creatures...sound dead".
  
  Similarly, "wordiness" is an issue. Unnecessary words dilute the impact of your message. We often pad our writing with phrases like "in order to" (where "to" suffices) or say "due to the fact that" instead of "because". Extraneous adverbs and filler words (very, basically, actually, etc.) sneak in too. When correcting and editing your writings, be ruthless. Trim unnecessary (metaphorical) fat.
• Common language and grammar issues: Small grammar mistakes or misused words can distract from your content and undermine your credibility. Mixing up affect and effect, using it’s (contraction) when you mean its (possessive), or inconsistent capitalization of terms (is it Endpoint Detection and Response or endpoint detection and response?) - these little errors add up.
  
  I know it's boring, but always proofread for spelling and grammar problems before you hit "publish". Don't rely solely on spellcheck, especially for technical terms and acronyms (which many dictionaries won’t know). If writing is not your strongest skill, consider using tools like grammar checkers or having a colleague review for clarity.
  
  Consistency is also part of good writing: if your report refers to an entity, use the same term throughout (don’t call it Active Directory in one place and the domain in another without explanation). Clean, correct language ensures readers focus on your message, not your mistakes.

Forensic Writing

You might have already guessed it, but forensic writing is an entirely different beast. Contrary to blog posts or other more "creative" forms of writing, when dealing with incident investigations, digital evidence taking, or analysis of malware, writing must be rigorous and precise.

I don't have as much experience with forensic writing, but keeping the following points in mind helped me on the occasions I had to engage in it:

• Take detailed case notes during the entirety of the investigation process: Good forensic writing starts long before you even start the process of writing a report. In order to be able to produce a good writing product you need to have source material available - hence why it's vital to contemporaneous notes throughout your analysis.
  
  These notes should record every significant step, command, observation, or decision in your investigation. Even if they aren't, treat your notes as they will be read in court or (an even scarier thought) another investigator.
  
  Include (at least rough) timestamps and context for your actions (e.g. "2025-01-07 12:30 UTC - exported data point xyz from machine abc for further analysis"). The notes you are taking serve two purposes. On one hand they preserve facts, so you don't have to rely on memory months later. On the other hand they make writing your final report so much easier. As someone who didn't value notes at the beginning of my career, let me tell you .. my reports used to be a disorganized mess.
• Plan and scope before you start writing: Before you start typing away furiously, take a step back and plan the report's scope and structure. Remember what the goal of the investigation was and what questions you have to answer.
  
  For example, if the objective of your investigation was to determine if any systems are currently compromised by a certain strain of malware, make sure that you stay focused on that. As tempting as it might be, don't turn things into a full security audit.
  
  Similarly, think about the structure of your report beforehand. Planning your sections in advance helps with understanding the story you need to tell. I know it sounds weird, but investigation reports especially benefit from storytelling, because they can be quite bland.
• As short as possible, as long as necessary: If you have read one of my posts before, you might have noticed that I'm not exactly good at keeping things short, something that has been a professional challenge for me for ages. Long-winded reports aren't necessarily better, especially executives tend to, from my experience, appreciate brevity.
  
  Tailor the length and depth to your audience. A client paying for a compromise assessment might expect more background and method, whereas an internal report for your own SOC might skip those and focus on the results instead.
  
  In any case, clarity and completeness are the goals. Say everything that needs to be said, but nothing more. Extraneous tangents or filler text can easily obscure key findings.
• Be clear, objective, and formal: One things I like the most about writing as a private person is that I get to decide how I write. I can pick whatever tone I'm comfortable with, I can pick the format I'm comfortable with, and my priority - as much as I'm happy if someone is able to take something useful away from my posts - is personal enjoyment.
  
  However, you should stick to a formal tone and precise wording when writing in a professional capacity, especially when you are writing a report that will be consumed by others.
  
  Write in active voice to clearly identify actors and actions (e.g. "The attacker created a new user account" rather than "A new user account was created"). Active voice makes it clear who did what, which is important when describing incidents. Avoid emotionally charged language and speculation. If you absolutely have to speculate, label it clearly - but stick to verifiable facts wherever possible. Every claim that's not clearly a speculation should trace back to evidence. Being factually rigorous not only strengthens your report, but it lends you credibility as an expert.

---

Addendum: Short-Form Communication

Even though it's not specific to information security it's something that applies to our field as well. Not all the communication you are going to engage in professionally is going to be a formal report.

In fact, much of the critical exchange of information happens in quick emails, ticket updates, or chat messages during an incident. Which is precisely why short-form writing needs to be similarly concise and clear, as misunderstandings in a fast-paced situation (think initial minutes of responding to a developing incident) can have significant consequences in the long run. Here are some things that have helped me in the past:

• Bottom Line Up Front (BLUF): Originating from a communication document released by the United States Army, BLUF is about stating the most important point first; in an email or a chat, don't bury the lede. Start with a clear statement of the key message or required action.
  
  For example, an email to a manager might start with "Critical: Malware outbreak contained on 5 servers. No sign of data loss for the time being. Here's what happened and what we're doing next ..". Starting to communicate that way might feel weird in the beginning, because we are used to writing our emails in a certain, somewhat standardized "professional style".
  
  But from my experience, people - especially ones who are not directly involved or are sitting in a position where they are tasked with keeping an overview of events - appreciate it when you summarize the conclusion or request in the opening line.
  
  BLUF allows someone skimming an email to immediately grasp its importance and priority. After the BLUF, continue being efficient in your communication by providing only the necessary supporting details or context.
• Be direct, be specific: Similarly to BLUF, stating clearly what you need or what the recipient needs to know helps a lot, especially in incident situations.
  
  For example, if you require approval or input, pose the question explicitly (e.g. "Please approve the blocking of XYZ on the firewall."). If you are providing an update, highlight what's changed (e.g. "New finding: the malware spread to two additional hosts").
  
  Avoid long preambles or overly polite cushioning. That can easily end up obscuring the main point. Professional courtesy is, allegedly, good. But rambling is not. Get to the point - you can do it politely, but you must do it quickly.
  
  At the same time, do not sacrifice clarity for brevity. While brevity is valued, never omit critical information that could lead to a misunderstanding. A good rule of thumb is to write your message(s), then reread them from the recipient's perspective. If there's any room for confusion, refine it.
• Maintain Professional Tone in Chats: Even though I just said that being polite is something that you can do, rather than something that you must do, being professional in your communication matters here as well.
  
  Write respectfully and clearly, even when sending rapid updates. Avoid slang or sarcasm that could be misread. It's sometimes challenging to find the balance, but adding a brief courtesy or clarity can help. For example, instead of just saying "need logs now", say "Could you upload the firewall logs? They're ASAP needed for investigation.".
  
  It's normal that tensions run high during an incident bridge call or chat. Your writing should inject calm clarity, not confusion or offense. Always remember that chat transcripts might be saved with incident documentation - you don't want crude jokes read out in court.
• Use formatting to ensure readability: Even in a short message, be it in chat or an email, if you have multiple points or questions, consider using bullet points or numbered lists. A brief, well-organized email with key points listed is far easier to parse than a chunky paragraph. In chat channels, where formatting options are often limited, you can still break messages into multiple lines or use text highlighting for key terms to make them stand out. For example:

Incident XYZ Update $TIMESTAMP - Action Required

* Scope: 3 new workstations have been infected - all isolated.
* Impact: No evidence of data exfiltration for the time being.
* **Action Needed**: Approve notifying affected employees (draft message attached, please respond to this message with comments)
* Next Update: 60 Minutes

• Make use of acknowledgments and confirmations: Things can get lost in communication, especially in rapid short-form exchanges. Past experience has showed me that it helps to acknowledge receipt and understanding.
  
  A quick "Got it, will do" closes the loop and gives everyone confidence that the message was received. This might seem minor, or even unnecessary, but it's been a game changer for me.