Logpoint is a cybersecurity platform with six product areas: SIEM, SOAR, Director, Integrations, UEBA, and Security Research. Each has its own team, release cadence, and documentation needs, all maintained through docs.logpoint.com.I worked across all six over two years.
I Installed Everything Before I Wrote About It
When I arrived, the docs were a mess for a simple reason: they were built on somebody's word. A developer said a feature worked this way, a Product Owner said it was meant to, and that became the page. Nobody had checked it from the customer's side of the screen.So I started checking. Every new ISO update went onto a VM I ran myself. Not the demo instance, not the screenshot an engineer sent over: a fresh install, following the steps I was about to publish. If the install guide was wrong, I found out before a customer did.Plugins got the same treatment. I pointed a log generator at each one and watched what it actually parsed, what it dropped, and what it did with input nobody had planned for. A plugin page that says "normalizes Windows event logs" is a claim. I wanted to see the claim hold.When an integration needed a particular device sending it logs, I set that device up. It's slow. It's also the only way to know whether the page describes the product or describes the meeting where the product was planned.Then I asked questions. Not "what does this button do," but the awkward ones: what happens if this field is empty, why does this release behave differently from the last one, is this the intended result or just the result.More than once the answer was uncomfortable. Product had described one thing; development had built another. A user would reach for one action and the software would do something else. I couldn't document both, so I got QA and Product in the same room to decide which one the product actually was. That wasn't me being difficult. A writer is often the first person to use a feature the way a customer will, slowly and literally, and that's exactly when the gaps show.I also talked to support. They knew where customers were getting stuck long before any of it showed up in a ticket count, and their "people keep asking about this" was usually a page I hadn't written yet, or one I'd written wrong.I broke SIEM detection rules on purpose until I understood what happens when they misfire. If a product needed exploring to document accurately, I explored it rather than waiting for an engineer to walk me through it.This made transitions between teams fast. I already understood the security domain and the documentation system. The specifics of each product area were the only ramp-up needed.
Cross-Regional Communication
Logpoint operates across multiple countries. Engineering teams, product teams, and customers were spread across different regions and time zones.Effective communication here meant understanding requirements precisely, even compressed into a Slack message or a Zendesk ticket from someone whose first language wasn't English. Extracting what was needed, confirming understanding, and producing documentation that matched intent on the first pass. The result: fewer revision cycles and fewer misunderstandings.
Why Security Documentation Is Different
Most documentation tolerates imprecision. If a SaaS onboarding guide has a slightly outdated screenshot, the user figures it out. If a security product's vulnerability report has an imprecise detail, the consequences are different. Compliance audits fail. Customers lose trust. Security teams make decisions based on what you wrote.Every sentence had to be verifiable. Every claim had to trace back to an engineering source: a Product Owner, a QA report, a developer's confirmation.
LaTeX Reports and Compliance-Grade Writing
Product Vulnerability Reports and Security Testing Guides were written in LaTeX. This was a formatting and versioning requirement for enterprise compliance: precise, reproducible, and auditable documents.Working with the SecOps team on these reports shaped how I approach all technical writing. When the reader is a security auditor, clarity is not a nice-to-have. Ambiguity in a vulnerability report doesn't cause confusion; it causes risk.
Security Research Editorial Work
Logpoint's Security Research team published blogs on threat analysis, detection methods, and emerging attack patterns. My role was editorial: proofreading, restructuring for clarity, and reviewing for originality.Security researchers often assume context their audience doesn't have. The job was bridging that gap: making analysis accessible without dumbing it down, ensuring each piece was technically sound and structurally clear.
Customer Support as a Documentation Feedback Loop
I handled customer technical inquiries through Zendesk. When the same question came in three times, the documentation had failed. Repeated support tickets became documentation bugs: fix the docs so the next person doesn't need to ask.
What I Took From This
Documentation at scale is a systems problem. The most valuable technical writer isn't the one who writes the best prose; it's the one who can move between teams, learn fast, communicate precisely across regions, and show up when there's a gap.
