Why I started this publication
I started this publication because I kept returning to the same topic: documentation.
During my time working as a technical writer in cybersecurity, I was often surprised by the role documentation seemed to play within organizations. It appeared everywhere, yet it was often treated as a secondary concern.
The more I observed this, the more questions I had. Blue Team Tech Writing exists because I want to explore those questions.
I am not an expert
I am not a seasoned security practitioner, nor am I the most experienced technical writer in the field. My perspective comes from working as a technical writer in cybersecurity and spending time around the people, processes, and technologies that make up defensive security programs.
That exposure gave me enough context to notice certain patterns, but not enough to claim expertise on the questions this publication aims to explore.
So why write about them?
Because worthwhile questions do not become less worthwhile simply because the person asking them lacks all the answers.
I do not see myself as an authority on these subjects. If anything, I see myself as someone trying to connect people and ideas. My hope is that I can contribute something useful to the conversation.
I have more questions than answers
The more I thought about documentation, the more questions I found myself asking. What started as an observation—that documentation often seems to be treated as a compliance requirement rather than an operational asset—quickly turned into a much larger set of questions.
For example:
- Is documentation a security control?
- If so, what kind of control is it?
- Can documentation reduce risk in the same way automation reduces risk, by reducing reliance on memory and individual expertise?
- How many security controls depend on undocumented assumptions, and are there controls that effectively exist only because people remember them?
I also find myself thinking about organizational knowledge:
- If an analyst discovers something important and nobody records it, has the organization actually learned anything?
- Is “tribal knowledge” simply a euphemism for undocumented operational risk?
- If a new employee cannot discover something on their own, does the organization truly know it?
- At what point does poor documentation become a business continuity issue rather than merely an inconvenience?
There are practical questions as well:
- What distinguishes documentation that satisfies an auditor from documentation that helps an operator?
- Why does documentation so often get deferred until after the work is complete?
- Is documentation a lagging indicator of organizational maturity, or can it actively contribute to maturity over time?
I do not have answers to these questions. In many cases, I am not even sure I am asking the right ones. But they seem worth exploring.
I want to hear from practitioners and technical writers
Many of the questions raised in this issue cannot be answered through reading alone. They require the perspectives of people who have encountered these problems in practice.
Practitioners and technical writers often approach documentation from different angles, but both groups have valuable experience to contribute.
Practitioners understand the realities of operating security programs, responding to incidents, managing tools, and making decisions under pressure. Technical writers bring expertise in organizing information, maintaining knowledge, and helping people find and use what they need.
I suspect some of the most interesting insights exist at the intersection of those perspectives. Bringing those viewpoints together is one of the goals of this publication.
This publication is an experiment
More specifically, it is an attempt to investigate a set of questions that I find increasingly difficult to ignore.
I suspect documentation plays a larger role in defensive security than it is often given credit for. I suspect there are lessons to be learned from the way organizations create, maintain, share, and lose operational knowledge. I suspect there are connections between documentation, resilience, continuity, onboarding, and day-to-day operations that are worth exploring.
At this point, however, they remain suspicions.
Rather than trying to present definitive answers, I would rather approach these questions as an investigation.
For now, the experiment is simple: ask good questions, follow the evidence, and see where it leads.
What I might be wrong about
The biggest assumption behind this publication is that documentation matters more than many organizations treat it. That suspicion is what led me to start asking these questions in the first place.
It may also be wrong.
I may be overestimating the role documentation plays in defensive security programs. It is possible that documentation is often downstream of other factors rather than a driver of them.
Good documentation may be the result of healthy teams, mature processes, and experienced practitioners rather than a cause of those things. If that’s the case, I want to understand it.
If experienced SOC analysts consistently tell me that documentation is not where their biggest operational problems originate, that would challenge some of my assumptions. If I encounter mature security programs that succeed with minimal formal documentation, that would be worth examining. If technical writers tell me that I am overstating the role of documentation, I want to hear why.
One of my goals with this publication is not to defend a predetermined conclusion. I am interested in following the evidence wherever it leads.
What comes next
I personally have a lot of work to do before I have anything worth contributing to this conversation. There is more reading to do, more to learn about security controls and defensive security programs, and more importantly, more people to learn from.
Over the coming months, I’d like to explore those questions through a variety of formats.
Some issues may be simple roundups of interesting articles, discussions, and resources. Others may focus on a single topic or question. I’d also like to publish documentation reviews, interviews with practitioners and technical writers, and collections of resources that others may find useful.
If this publication succeeds at all, I hope it becomes a place where ideas, examples and experiences can be collected and revisited rather than rediscovered from scratch.
If this publication succeeds at all, I hope it becomes a place where ideas, examples, and experiences can be collected and revisited rather than rediscovered from scratch.
For now, the direction it takes will depend on what I learn, who I meet, and what conversations emerge along the way. If any of these questions resonate with you, I’d be glad to hear from you.