The Security Blog Nobody Asked For (But Somebody Had to Write)

Most security content isn't written for people like me. And if you've found your way here, I suspect it isn't written for people like you either.

It's written for organizations with a twenty-person security team and a seven-figure tooling budget. It's written by analysts at research firms who study the field from a distance, or by vendors whose threat landscape always seems to require whatever product they happen to sell. The advice is technically correct, often genuinely smart, and almost entirely useless if you're the one person at a fifty-person company who's supposed to make it real.

I've spent years reading security blogs and conference talks that assume a reality I don't live in. "Build a threat hunting program." With whom? "Implement a zero trust architecture." With what budget? "Staff a 24/7 SOC." I can't even get a dedicated security hire approved for next year.

The practical, honest content about doing this work without enterprise resources — the content about judgment calls, trade-offs, and what "good enough" actually means when you're operating with real constraints — that content barely exists. So I started writing it.

Who I Am

I run security and compliance at a small software company. I also do engineering work, vendor risk management, policy writing, architecture reviews, and about four other things depending on the week. There is no security team. There's me, a set of frameworks I've adapted to our size, and a lot of decisions made with imperfect information under time pressure.

I'm not a former Big Four consultant. I didn't spend a decade at a Fortune 500 building a program with unlimited resources and then write a book about it. My experience is the opposite: figuring out how to build something defensible with real constraints, real trade-offs, and a calendar that doesn't have "focus on security" blocked out as a full-time occupation.

That context shapes everything I write here. I'm not observing this work from the outside. I'm doing it, every week, alongside everything else.

What You'll Find Here

If you've ever sat in a meeting and heard "are we compliant?" used as a synonym for "are we secure?" — and felt the gap between those two questions in your chest — you'll find something useful here.

If you've ever stared at a compliance framework designed for a 10,000-person enterprise and tried to figure out what a proportionate version looks like at your scale — I write about that.

If you've ever needed to explain risk to a leadership team that doesn't speak in CVEs and threat models, and had to find the right language on the fly — I write about that too.

Here's what the blog covers:

Security in practice. Building and running a security program without a security team. Risk assessments that aren't theater. Incident response plans that people actually read. The stuff between the frameworks and reality.

The compliance-security tension. How to satisfy auditors without letting compliance become a substitute for actual security. How to make evidence a byproduct of real controls instead of a separate workstream. Where the frameworks help and where they create false confidence.

Speaking to leadership. Translating security risk into business language. Having the budget conversation. Saying no without being the bad guy. Earning trust by being honest about what's good enough and what isn't.

Developer-friendly security. Security concepts that belong in the engineering workflow, not in a gate before deployment. Building guardrails instead of gatekeeping. Making the secure path the easy path.

The human side. Multi-hat leadership. Context switching. Imposter syndrome when you're three roles deep and none of them came with a playbook. The culture and philosophy underneath the technical work.

How I Write

You won't find vendor recommendations here. I'm not going to tell you what tool to buy. If you want product comparisons, there are plenty of analysts who do that well.

What I write is practical. It comes from doing the work, not from studying it. I try to be honest about what I don't know, where I've made mistakes, and where the "right" answer depends on context that no blog post can give you. I'd rather tell you how I think about a problem than hand you a prescriptive checklist that won't survive contact with your specific reality.

I try to publish weekly. Some posts are tactical — here's a process, a template, a framework adapted for small teams. Others are reflective — here's what I've learned, what I got wrong, what I'd tell someone earlier in this path. The mix is intentional. This work isn't just technical, and pretending it is would make the blog less useful than it should be.

The Invitation

I didn't start this blog to broadcast into the void. I started it because the most useful conversations I've had about this work have been with other people navigating the same challenges: other accidental CISOs, multi-hat leaders, developers who ended up owning security because nobody else would.

If that's you, I want to hear from you. Push back on what I write. Share what's working at your company. Ask the questions you can't ask your leadership team. The comment section is open, and I read everything.

And if you're just getting started in this role, or if security landed on your desk last month and you're not sure where to begin, stick around. I've been where you are. The learning curve is steep, but you're not climbing it alone.

New posts go up weekly. Subscribe if you want them in your inbox, or just check back when something in the archive catches your eye. Either way — welcome.